SmartMEDIA Recryptor

The SmartMEDIA Recryptor (smrecrypt) service is designed to re-encrypt MP4 chunks prepared for adaptive streaming (HLS or DASH) from one encryption scheme to another “on the fly”, i.e. without saving the re-encrypted copy to the repository. This saves disk space by storing only one copy of encrypted content (for example, for Widevine DRM). At the same time, players using a different content protection system (for example, Apple FairPlay DRM) can also decrypt and play this content. Currently, reencryption from the cenc scheme (AES-CTR) to the cbcs scheme (AES-CBC with template encryption) is supported according to the standard ISO/IEC 23001-7 “Common encryption in ISO BMFF files”.

SmartMEDIA Recryptor operates as an HTTP proxy server, processing client requests for MP4 chunks. It requests chunks over HTTP from the origin server (for example, from S3 storage) or from the local file system, parses MP4, receives encryption keys from the SmartLabs UDRM server, decrypts media samples, re-encrypts with another encryption scheme, generates an output MP4 file and passes it to the client over HTTP. The re-encryption is performed at each request for each client. The service does not have internal caching of chunks, so it may be advisable to cache content using a caching proxy server, for example, NGINX. Also cryptographic algorithms used in decrypting and encrypting data can create an increased load on the CPU. So it is recommended to use processors with hardware encryption support, for example, Intel AES New Instructions (AES-NI).

The service receives encryption keys from the SmartLabs UDRM server using the Custom Extension UDRM Decryption API. Since the standard API of the cloud Widevine DRM does not support content decryption on the server side (but only encryption), the SmartMEDIA Recryptor service can only be used with the SmartLabs UDRM key server and cannot receive keys directly from the cloud Widevine DRM (unlike the SmartMEDIA Conveyor service). The received encryption keys are cached to reduce the number of requests and the load on the key server.

To re-encrypt MP4 chunks “on-the-fly”, they must be recorded appropriately by the SmartMEDIA Conveyor service. In particular, Key ID and PSSH must be written to each MP4 chunk to request keys. When re-encrypting, the structure of Subsamples (BytesOfClearData/BytesOfProtectedData) remains unchanged, so the original chunks must be encrypted with this in mind. This may require certain recording setup in the SmartMEDIA Conveyor service (for details, see the service documentation). Also, MP4 chunks recorded by a third-party media server, in some cases, cannot be re-encrypted “on-the-fly” using the SmartMEDIA Recryptor service.

Command Line Parameters

–help, -h

Display help in the console and exit.

–version, -V

Display version in the console and exit.

–config, -c

Default value: config.json

The configuration file path.

–log-config, -l

Default value: config.log.json

The path to the logger configuration file.

Configuration File

Basic Parameters

interface, string 

IP address of the HTTP server to process incoming client requests for MP4 chunks.

port, integer 

Port of the HTTP server to process incoming client requests for MP4 chunks.

cbcs_crypt_byte_block, integer 

The number of encrypted blocks in the pattern for the cbcs encryption scheme. The sum of encrypted and open blocks in the pattern should be equal to 10. So it is enough to specify only the number of encrypted blocks and the pattern will be formed as [N:10-N]. The recommended pattern is [1:9]. For example, Apple FairPlay encryption uses this pattern.

file_source, section 

Contains either the ”http” element with the settings for accessing the HTTP server with files (for example, S3 storage), or the ”fs” element with the settings of the local file system storage. The storage settings should contain the basic part of the URI. To form the full URI of the file, the relative path received in the request from the client is added to it.

Settings of Local File System Storage

path, string 

The path to the root directory for receiving MP4 files.

Settings of HTTP Storage

base_uri

Type: строка

Base part of the HTTP storage URI.

timeout_sec, integer 

Timeout of an HTTP request to the file storage, in seconds.

key_source, section 

The section containing the settings for obtaining keys for encryption according to the Common Encryption (ISO/IEC 23001-7) standard.

signer_iv, HEX string 

The initialization vector (IV) for encrypting the message to the key server; the IV size must be 16 bytes.

signer_key, HEX string 

The key for encrypting the message to the server; the key size must be 32 bytes.

signer_name, string 

Signer ID to request the key server.

url, string 

URL for requesting keys via the UDRM Decryption API.

cache_size, integer 

The maximum number of keys that can be cached.

Example Configuration

JSON

{  “interface”:“0.0.0.0”,  “port”:4000,  “cbcs_crypt_byte_block”:1,  “file_source”: {    “http”: {      “base_uri”:“http://localhost:8080/hls/”,      “timeout_sec”:30    }  },  “key_source”: {    “url”:“http://10.65.50.66:8082/dapi/getkey”,    “signer_name”:“smldec”,    “signer_key”:“6e63cbfcc15b3d3ab2e64434b9729aabbd5c18b721e131d2ad1807e7eab4e633”,    “signer_iv”:“78a8a6671f3007da70e532f3d873ec3e”,    “cache_size”:50  } }