You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+51-1
Original file line number
Diff line number
Diff line change
@@ -21,6 +21,7 @@ All the **hands-on should be performed from the folder you cloned** this reposit
21
21
22
22
# Changelog
23
23
24
+
* added DRM system
24
25
* released version 1.0.0
25
26
* added simplified Chinese translation
26
27
@@ -736,11 +737,60 @@ HEVC has bigger and more **partitions** (and **sub-partitions**) options than AV
736
737
737
738
## Content protection
738
739
740
+
We can use **a simple token system** to protect the content. The user without a token tries to request a video and the CDN forbids her or him while a user with a valid token can play the content, it works pretty similarly to most of the web authentication systems.
The sole use of this token system still allows a user to download a video and distribute it. Then the **DRM (digital rights management)** systems can be used to try to avoid this.
745
+
741
746

742
747
743
-
[TODO]
748
+
In real life production systems, people often use both techniques to provide authorization and authentication.
DRM means Digital rights management, it's a way **to provide copyright protection for digital media**, for instance, digital video and audio. Although it's used in many places [it's not universally accepted](https://en.wikipedia.org/wiki/Digital_rights_management#DRM-free_works).
761
+
762
+
#### Why?
763
+
764
+
Content creator (mostly studios) want to protect its intelectual property against copy to prevent unauthorized redistribution of digital media.
765
+
766
+
#### How?
767
+
768
+
We're going to describe an abstract and generic form of DRM in a very simplified way.
769
+
770
+
Given a **content C1** (i.e. an hls or dash video streaming), with a **player P1** (i.e. shaka-clappr, exo-player or ios) in a **device D1** (i.e. a smartphone, TV, tablet or desktop/notebook) using a **DRM system DRM1** (widevine, playready or FairPlay).
771
+
772
+
The content C1 is encrypted with a **symmetric-key K1** from the system DRM1, generating the **encrypted content C'1**.
773
+
774
+

775
+
776
+
The player P1, of a device D1, has two keys (asymmetric), a **private key PRK1** (this key is protected<sup>1</sup> and only known by **D1**) and a **public key PUK1**.
777
+
778
+
> **<sup>1</sup>protected**: this protection can be **via hardware**, for instance, this key can be stored inside a special (read-only) chip that works like [a black-box](https://en.wikipedia.org/wiki/Black_box) to provide decryption, or **by software** (less safe), the DRM system provides means to know which type of protection a given device has.
779
+
780
+
781
+
When the **player P1 wants to play** the **content C'1**, it needs to deal with the **DRM system DRM1**, giving its public key **PUK1**. The DRM system DRM1 returns the **key K1 encrypted** with the client''s public key **PUK1**. In theory, this response is something that **only D1 is capable of decrypting**.
782
+
783
+
`K1P1D1 = enc(K1, PUK1)`
784
+
785
+
**P1** uses its DRM local system (it could be a [SOC](https://en.wikipedia.org/wiki/System_on_a_chip), a specialized hardware or software), this system is **able to decrypt** the content using its private key PRK1, it can decrypt **the symmetric-key K1 from the K1P1D1** and **play C'1**. At best case, the keys are not exposed through RAM.
0 commit comments