There are two main technical solutions for integrating ChinaDRM client into set-top boxes:
1) Plugin method: The system layer (such as MediaDRM Service) integrates DRM client plugins, and the applications use the system standard interface (such as MediaDRM) to call the DRM Plugin. The MediaPlayer and MediaCodec Based Player both should support DRM.
2) APP method: Integrate DRM client SDK within the application, without relying on system DRM capabilities.

The strategy for deploying DRM Client on set-top boxes is as follows:
1) For live-network set-top boxes (usually without TEE high security enabled), OS software level DRM plugins can be deployed through ROM update(if OTA is achievable). Chip and set-top box manufacturers generate new versions of ROM and distribute it to the set-top box through OTA. Before the ROM upgrade is completed, The APP Method is used, without relying on the system's DRM capabilities.
2) For newly manufactured set-top boxes, use the Plugin Method.TEE high security and DRM plugin both should be deployed by default.

Applications can adopt an adaptive strategy of selecting DRM clients through querying whether the system layer supports DRM plugin by the system standard API(such as MediaDRM) . If it supports, the terminal's built-in capabilities can be used directly, and if not, the APP's built-in client SDK capabilities can be used.

The workflow for IPTV set-top boxe to support ChinaDRM capability is as follows:
1) SOC manufacturer completes chip certification: integrates DRM client according to hardware level security and Plugin Method(MediaPlayer and MediaCodec Based Player both support DRM), and completes DRM Runtime Environment security assessment (ChinaDRM Lab provides assessment services).
2) Set-top box manufacturers complete device certification: compile and deploy DRM clients to the set-top box, burn DRM device certificates (testing), complete set-top box IPTV network access testing (DRM part), complete device(set-top box) security evaluation (ChinaDRM Lab provides evaluation services), and obtain an "evaluation filing number".
3) Multi party completion of business integration testing: Set-top box/video and audio service platform and other parties jointly complete the DRM integration testing.
4) Set-top box manufacturers produce set-top boxes: Set-top box manufacturers purchase DRM device certificates from the DRM Trust Authority(DTA) with the "evaluation filing number", burn the DRM device certificates on the set-top box production line, and supply them to the set-top box purchaser.

For the key request interface between the live broadcast encryption service and the key management service, please refer to GY/T333-2020 Digital rights management for video audio content distribution— Digital rights management system integration for digital cable television.
The interface between the live broadcast encryption service and the live broadcast channel management service will be published.

The interfaces between the on-demand encryption service and the on-demand content management service, such as task creation, query and deletion, as well as the key request interface between the on-demand encryption service and the key management service, please refer to GY/T333-2020 Digital rights management for video audio content distribution— Digital rights management system integration for digital cable television.

The key request interface between the content encryption service and the key management service, and the key synchronization interface between the key management service and the key gateway service, please refer to GY/T333-2020 Digital rights management for video audio content distribution— Digital rights management system integration for digital cable television.

① When encrypting the video encapsulated by TS and encoded by 264 and 265, pay attention to the following:
a. In order to prevent CEI from performing conflict conversion, it is recommended to avoid 0x00 00 00/01/02/03 for KeyID and IV values, and replace them if they occur.
b. 0 cannot appear at the end of the NAL (Network Abstract Layer) unit, because the start code of the NALU is 0x00 00 01. If 0 appears at the end, the NALU may be incorrectly truncated or recognized, thus affecting the correctness of the encryption, decryption and decoding processes. By analogy, if the last byte of the PES in the TS package is 0, 0xFF should be added at the end of the PES.
c. In order to avoid the player taking the first 0x00 (leftmost) in 0x00 00 00 01 as the last byte of the previous NALU, it is recommended that the encryption software uniformly modify the start code of the NALU to 0x00 00 01, and the modification method is to delete the first 0x00.
d. One CEI is inserted in front of each keyframe, and the CEI is inserted into the SEI. SEI can be separately packaged in one TS package.
e. The encryption should be performed according to the PES unit. After the first NAL belonging to the encryption range is found, the subsequent NAL will be used as the body of the first NAL. After encryption, the encryption range will be subject to unified anti ambiguity processing. The total length of the encrypted NAL should not exceed 4MB. If it exceeds the limit, a warning or error should be prompted to prevent the playback device from discarding the data that exceeds the limit during decryption.
f. In the encryption process, in addition to 0x00 00 00/01/02/03 of the encrypted value, the anti-collision conversion is required to 0x00 00 03 00/01/02/03, the last part of full encryption that is less than 16 bytes and the part of sampling encryption that is not encrypted also need to be anti-collision conversion. It is recommended that after the encryption of the NALU is completed, the encryption interval of the NALU should be uniformly converted for conflict prevention.
g. In order to prevent CEI from performing conflict conversion, it is recommended that ChinaDRM_descriptor avoid 0x00 00 00/01/02/03.
h. Add DRM information to the media: add ChinaDRM_descriptor to the PMT. The recommended value of its DRM_data_bytes field is the PSSH. If there is M3U8 file, add URI attribute in # EXT-X-KEY. In addition, add the CEI to the SEI.
② When the player decrypts and plays the encrypted video encapsulated by TS and encoded by 264 and 265 , the following matters should be noted:
a. If SEI already exists in the code stream, and additional SEI is added to add CEI during DRM encryption, the player should pay attention not to lose CEI information when processing SEI without CEI.
b. When processing CEI information in SEI, pay attention to the implementation to prevent ambiguous start code conflicts.
c. For the encrypted stream, there are exactly 16 bytes that are not encrypted at the end of the previous NAL. The start code of the next NAL is 0x00 00 00 01 (4 bytes). If the player improperly processes the left most 00 of the NAL start code as the end of the previous NAL, the last 16 bytes of the previous NAL will be decrypted incorrectly.

Whether to change the CEK should be comprehensively considered according to the content display mode and protection security level. A certain online movie uses hardware level protection in the first 20 days after its release (window period) and software level protection 20 days later (after the window period), so the program has DRM encryption at the initial stage and no need to re encrypt later, so there is no need to change the CEK. Another network movie uses hardware level protection during the window period. After the window period, 1080P and above resolution requires hardware level protection. 720P and below resolution allows software level protection. At least after the window period, 720P and below resolution media must be encrypted with a new CEK to avoid overlap with the CEK of 1080P and above resolution media.

It is recommended that the key rules of the license issued by the license server include client security level requirements, output rules, and any one or more consumption rules.

Please refer to standards, extensions are an object, where drmServerInfos is an array object.
"extensions":{
"drmServerInfos":[…],
"authenticationData":"base64 string"
}

The DRM license server should regularly access OCSP services and CRL services. The DRM server should query the status of the device certificate before issuing a license. The status of the device certificate can be obtained through the CRL provided by the DTA. The DRM license service shall check the validity period of the DRM client certificate and its superior (parent) certificate carried in the license request message before issuing a license. If the validity period of any certificate exceeds the validity period, it shall refuse to issue license.

The DRM client may judge the status of the server certificate before using the license. The real-time status of the DRM server certificate can be obtained by querying the OCSP response from the OCSP server.