Using Content Protection Systems (CAS / DRM)
SmartMEDIA can use third-party content protection systems (PlayReady, Widevine, etc.) to encrypt content before recording to the storage.
The content protection functionality is implemented in the components Conveyor, SmartCETS, vodconvert and cets. CAS/DRM access settings and file encryption parameters are specified in the components’ configuration files or in the utilities’ command line parameters.
SmartMEDIA encrypts DASH and HLS content with keys retrieved from CAS/DRM systems, indexes it, records encrypted content to the storage and delivers to the client devices. The encryption keys are stored only in the external CAS/DRM system, which transmits them securely to the subscriber device using proprietary protocols.
Depending on the end-user devices used, delivery protocols, media containers, and content security requirements (in particular, the DRM system), content encryption methods may also vary.
Encrypt Live and nDVR Content
HLS (AES-128)
HLS-AES encryption standard is supported for chunks recorded in the MPEG2-TS container. As a DRM server, Verimatrix Adaptive CAS or another server that implements the VCAS Scrambler HTTP protocol can be used.
The content is encrypted using the AES-CBC algorithm with a key length of 128 bits and PKCS#7 padding.
|
Some SmartTV models and possibly some other subscriber devices decrypt the stream incorrectly: PKCS#7 padding is not discarded, random “garbage” appears at the end of each chunk and that’s why the first TS packet of each followed chunk will be decoded incorrectly. As a workaround for this problem, you can enable the insertion of a PAT/PMT table to the beginning of each chunk. With this workaround applied, the first TS packet in each chunk will always be PAT, it will be decoded incorrectly and rejected by the TS demuxer, but media data will not be affected. For more information about adding PAT/PMT to the beginning of the chunk, see the document “SmartMEDIA Configuration Reference.” |
HLS and DASH with the ISOBMFF Container (MP4 Fragmented)
The ISO BMFF container supports ISO Common Encryption standard (cenc and cbcs schemes). SmartMEDIA services can interact with the key server through the Widevine Modular DRM Encryption API and SmartLabs UDRM Encryption API (which is an extension of the Widevine Modular DRM Encryption API).
Until the first key for the track is received, the SmartMEDIA Conveyor will skip all media data and won’t record the content of this track.
To improve the content security, Conveyor supports the periodic updates of encryption keys (key rotation).
Depending on the requirements of content owners and internal operator’s policies, the duration of the period of using one key can be adjusted from one second to the complete rotation disabling. It should be taken into account that the smaller rotation interval will increase security, but, as well, it will increase the load on the key generation servers (on the encryption side) and, especially, the license servers (from the client devices side).
Most DRM system vendors recommends to use different keys for different track types — at least, separate audio and video encryption keys. The reason of such enforcements is simple: on most modern devices video decryption path is implemented in hardware (and is secure by design), but audio decryption is still performed in software and can be the cause of encryption keys leaks.
|
Legacy Microsoft PlayReady DRM clients (PlayReady 2.x SDK and older) don’t support neither key rotation nor different keys for different track types. To avoid using the same encryption key for audio and video track and keep the same copy of the content for legacy PlayReady and more modern devices secure, some streaming services leave audio track clear. |
Encryption settings are specified in the drms section of the main SmartMEDIA Conveyor configuration file.
For the key rotation, the entire timeline can be divided into periods of fixed duration, each of these periods has an unique sequence number. The number of periods for which keys are requested within the single request to the key server is specified in the configuration parameter crypto_period_count (the default value is 5); the duration of one period should be defined in crypto_period_length parameter (by default — 1 hour).
Depending on the functionality and settings of the key generation server, the response may contain both the one PSSH for all periods (which in turn contains as many keys as requested), and various PSSHs for each period (each contains only one key).
|
Google WideVine Modular DRM cloud service supports only PSSH generation with one key per PSSH. |
For details about encryption settings, see the document “SmartMEDIA. Configuration Reference.”
HLS and RTSP for IPTV Systems (DVB Simulcrypt)
A stream already encrypted using DVB Simulcrypt standards can be injected to the SmartMEDIA Conveyor input. Recording is possible only in the MPEG2-TS container “as is”, without remultiplexing and other transformations in the stream.
This method is not standard for the HLS protocol, but it’s often used in IPTV systems that historically inherited the DVB CAS.
For more information on setting the “pass through” mode, see the document “SmartMEDIA Configuration Reference.”
Encryption of Multicast MPEG2-TS Content
The SmartCETS service and the cets utility encrypt MPEG-TS content in real time according to ISO/IEC 23001-9 (Common encryption of MPEG-2 transport streams). After receiving the list of input multicast streams, SmartCETS/cets requests encryption keys from the key server using the Common Encryption API for Widevine DRM (hereinafter Widevine API) or SmartLabs UDRM Encryption API. Encrypted content can be either written to a file, or broadcasted to a multicast group using the UDP protocol. For the SmartCETS service, the list of multicast groups of input streams for encryption along with other parameters must be specified in the configuration file. For the cets utility, all parameters are passed by command-line arguments.
The following formats are supported:
- Video: H.262, H.264, H.265;
- Audio: AAC / ADTS, AC3, DTS.
To improve the encryption security of streaming content, the SmartCETS service supports the periodic rotation of encryption keys. It requires using of SmartLabs UDRM Encryption API because of support of multiple keys in one PSSH.
The cets utility does not support the keys rotation.
The encryption and keys rotation settings are similar to the SmartMEDIA Conveyor service for encrypting the ISO BMFF container.
Configuring Steps
In the global section of the SmartCETS configuration file, you’ll need to set the values for key_server_url, signer_name, signer_key, signer_iv. Then, in the streams section, list content IDs, source URLs and destination URLs in udp://GROUP:PORT format .
Example:
|
{ “key_server_url”:“http://10.10.10.10/cenc/getkey”, “signer_name”:“cets”, “signer_key”:“1ae8ccd0e7985cc0b6203a55855a1034afc252980e970ca90e5202689f947ab9”, “signer_iv”:“d58ce954203b7c9a9a9d467f59839249”, “crypto_period_length”:“24h”, “crypto_period_count”:“3”, “key_request_policy”:“each_key_expires”, “smooth_transmission_by_pcr”:“true”, “packets_between_pssh”:200, “msec_between_audio_ecm”:50, “streams”: [ { “content_id_string”:“R24.ism”, “source_url”:“udp://239.65.40.4:5001”, “sink_url”:“udp://239.65.70.4:5001” }, { “content_id_string”:“CH_7_145_LOCAL”, “source_url”:“udp://239.253.7.145:1234”, “sink_url”:“udp://239.253.8.145:1234” }, { “content_id_string”:“CH_7_96_LOCAL”, “source_url”:“udp://239.253.7.96:1234”, “sink_url”:“udp://239.253.8.96:1234” } ] } |
VoD Encryption
Encryption of VoD content is performed by the utility vodconvert. Description of the vodconvert parameters is presented in the “Configuration Reference” section. Examples of vodconvert running can be found here.