3、 Assessment content
The DRM technology and products in this document include: DRM server components, DRM client runtime environment, DRM client devices, DRM client applications, DRM system, and video digital watermarking technology and other digital media content copyright protection related technologies and products.
The evaluation content of this document is to assess the functionality, standard compliance, security, and other aspects of the above-mentioned DRM technology and products based on the evaluation criteria.
4.1 DRM Server Components
DRM server component evaluation refers to the evaluation of components such as live content encryption, on-demand content encryption, key management, key gateway, and content authorization(drm license server).
4.1.1 Live content encryption component
1. It should support one or more of real-time TS, HLS, DASH, CMAF and other live content encryption and encapsulation;
2. It should support video encoding formats such as AVS+, AVS2, H.264, H.265, etc;
3. It should support applying for encryption keys for live streaming content through key management;
4. It should support live streaming encryption keys to be updated at a configurable frequency;
5. The encryption delay for live streaming should not exceed 500ms;
6. It should support a second level key update frequency;
7. The encryption of live streaming content should comply with the provisions of Sections 6.1.1 and 6.2 of GY/T 333-2020;
8. The application for encryption keys for live streaming content should comply with the provisions of Section 7.1 of GY/T 333-2020;
9. The public and private keys of the live content encryption component should be generated in the hardware password module, and the private key should be securely stored in the hardware password module;
10. Encryption, decryption, signature and other cryptographic functions should be implemented in the hardware cryptographic module;
11. The private key, content encryption key, session key, temporary key, etc. of the live content encryption component should not expose plaintext outside the hardware password module;
12. The hardware password module should comply with the second or higher security level specified in GB/T 37092-2018 Information Security Technology Password Module Security Requirements, and have a commercial password product certification certificate;
13. It should have a hardware password module recognition mechanism, and the service should be stopped when the hardware password module is removed;
14. It should have a software component integrity verification mechanism, and the service should be stopped after the software component is tampered with;
15. It should support secure logging and log review, and any operation including software upgrades, software component modifications, illegal tampering, hardware password module removal, etc. should be securely recorded;
16. It should have a security upgrade mechanism and be able to promptly perform security repairs in the event of new security risks or vulnerabilities.
4.1.2 Encryption component for on-demand content
1. It should support one or more of the content encryption packages such as TS files, HLS, DASH, CMAF, etc;
2. It should support video encoding formats such as AVS+, AVS2, H.264, H.265, etc;
3. It should support applying for encryption keys for on-demand content through key management.
4. The encryption of on-demand content should comply with the provisions of 6.1.2 and 6.2 in GY/T 333-2020;
5. The management of encryption tasks for on-demand content should comply with the provisions of 6.3 in GY/T 333-2020;
6. The application for encryption key for on-demand content should comply with the provisions of 7.2 in GY/T 333-2020;
7. The public and private keys of the on-demand content encryption component should be generated in the hardware password module, and the private key should be securely stored in the hardware password module;
8. Encryption, decryption, signature and other cryptographic functions should be implemented in the hardware cryptographic module;
9. The private key, content encryption key, session key, temporary key, etc. of the on-demand content encryption component should not expose plaintext outside the hardware password module;
10. The hardware password module should comply with the second or higher security level specified in GB/T 37092-2018 Information Security Technology Password Module Security Requirements, and have a commercial password product certification certificate;
11. It should have a hardware password module recognition mechanism, and the service should be stopped when the hardware password module is removed;
12. It should have a software component integrity verification mechanism, and the service should be stopped after the software component is tampered with;
13. It should support secure logging and log review, and any operation including software upgrades, software component modifications, illegal tampering, hardware password module removal, etc. should be securely recorded;
14. It should have a security upgrade mechanism and be able to promptly perform security repairs in the event of new security risks or vulnerabilities.
4.1.3 Key Management Component
1. It should support receiving and processing content encryption key applications;
2. It should support secure storage management of content encryption keys;
3. It should support synchronizing content encryption keys to the key gateway.
4. Live streaming key management should comply with the provisions of 7.1 in GY/T 333-2020;
5. The management of on-demand keys should comply with the provisions of 7.2 in GY/T 333-2020.
6. The public and private keys of the key management component should be generated in the hardware password module, and the private key should be securely stored in the hardware password module;
7. Encryption, decryption, signature and other cryptographic functions should be implemented in the hardware cryptographic module;
8. Key management components such as private keys, content encryption keys, session keys, temporary keys, etc. should not expose plaintext outside the hardware password module;
9. It should have a content encryption key repository to achieve secure storage, backup, and import/export of content encryption keys;
10. The hardware password module should comply with the second or higher security level specified in GB/T 37092-2018 Information Security Technology Password Module Security Requirements, and have a commercial password product certification certificate;
11. It should have a hardware password module recognition mechanism, and the service should be stopped when the hardware password module is removed;
12. It should have a software component integrity verification mechanism, and the service should be stopped after the software component is tampered with;
13. It should support secure logging and log review, and any operation including software upgrades, software component modifications, illegal tampering, hardware password module removal, etc. should be securely recorded;
14. It should have a security upgrade mechanism and be able to promptly perform security repairs in the event of new security risks or vulnerabilities.
4.1.4 Key Gateway Component
1. It should support receiving and processing key management for live/on-demand content encryption key requests;
2. It should support secure storage management of live/on-demand content encryption keys;
3. It should support receiving and processing content authorization live/on-demand content encryption key requests.
4. Key synchronization should comply with the provisions of 9.2 in GY/T 277-2019;
5. The key query should comply with the provisions of 9.3 in GY/T 277-2019.
6. The public and private keys of the key gateway component are generated in the hardware password module, and the private key should be securely stored in the hardware password module;
7. Encryption, decryption, signature and other cryptographic functions should be implemented in the hardware cryptographic module;
8. The private key, content encryption key, session key, temporary key, etc. of the key gateway component should not expose plaintext outside the hardware password module;
9. It should have a content encryption key repository to achieve secure storage, backup, and import/export of content encryption keys;
10. The hardware password module should comply with the second or higher security level specified in GB/T 37092-2018 Information Security Technology Password Module Security Requirements, and have a commercial password product certification certificate;
11. It should have a hardware password module recognition mechanism, and the service should be stopped when the hardware password module is removed;
12. It should have a software component integrity verification mechanism, and the service should be stopped after the software component is tampered with;
13. It should support secure logging and log review, and any operation including software upgrades, software component modifications, illegal tampering, hardware password module removal, etc. should be securely recorded;
14. It should have a security upgrade mechanism and be able to promptly perform security repairs in the event of new security risks or vulnerabilities.
4.1.5 Content Authorization Component
1. Should support receiving and processing DRM client live/on-demand content authorization license requests.
2. It should support requesting encryption keys for live/on-demand content from the key gateway.
3. Content authorization license requests/responses shall comply with the provisions of Chapter 8 of GY/T 277-2019.
4. The key query should comply with the provisions of 9.3 in GY/T 277-2019.
5. The public and private keys of the content authorization component should be generated in the hardware password module, and the private key should be securely stored in the hardware password module.
6. Encryption, decryption, signature and other cryptographic functions should be implemented in the hardware cryptographic module.
7. The private key, content encryption key, session key, temporary key, etc. of the content authorization component should not expose plaintext outside the hardware password module.
8. The hardware password module should comply with the second or higher security level specified in GB/T 37092-2018 Information Security Technology Password Module Security Requirements, and have a commercial password product certification certificate.
9. It should have a hardware password module recognition mechanism, and the service should be stopped when the hardware password module is removed;
10. It should have a software component integrity verification mechanism, and the service should be stopped after the software component is tampered with;
11. It should support secure logging and log review. Any operation, including software upgrades, software component modifications, illegal tampering, hardware password module removal, etc., should be securely recorded;
12. It should have a security upgrade mechanism and be able to promptly perform security repairs in the event of new security risks or vulnerabilities.
4.2 DRM Client Devices
1. Should support the application for authorization licenses for live/on-demand content;
2. It should support the analysis of authorization licenses for live/on-demand content;
3. It should support secure decryption, decoding, playback, and output of live/on-demand content.
4. The decryption of live streaming content should comply with the provisions of 6.1.1 and 6.2 in GY/T 333-2020;
5. The decryption of on-demand content should comply with the provisions of 6.1.2 and 6.2 in GY/T 333-2020;
6. Content authorization license requests/responses shall comply with the provisions of Chapter 8 of GY/T 277-2019;
7. DRM clients should comply with the provisions of Chapter 10 of GY/T 277-2019;
8. The DRM client interface should comply with the provisions of Appendix C of GY/T 277-2019;
9. The interface of the DRM client runtime environment should comply with the provisions of Appendix D in GY/T 277-2019.
10. The DRM client functional module should run securely in the DRM client runtime environment, which should have the ability to protect the integrity of the DRM client functional module. If the DRM client functional module is tampered with, it should stop working;
11. The DRM client runtime environment should securely protect values with confidentiality requirements and values with integrity requirements. If values with integrity requirements are tampered with, the DRM client functional module should be stopped;
12. Protected content should be securely decrypted, decoded, played, and output in the DRM client execution environment in accordance with the requirements of the content authorization license;
13. For content that requires DRM protection, terminal devices should not bypass the DRM client function;
14. Terminal devices should have the ability to upgrade DRM client security. When new security vulnerabilities arise, the DRM client should be able to be upgraded in a timely manner, and there should be no vulnerabilities within the official 6-month period.
4.3 DRM Client Application
1. Should support the application for authorization licenses for live/on-demand content;
2. It should support the analysis of authorization licenses for live/on-demand content;
3. It should support secure decryption, decoding, playback, and output of live/on-demand content;
4. The decryption of live streaming content should comply with the provisions of 6.1.1 and 6.2 in GY/T 333-2020;
5. The decryption of on-demand content should comply with the provisions of 6.1.2 and 6.2 in GY/T 333-2020;
6. Content authorization license requests/responses shall comply with the provisions of Chapter 8 of GY/T 277-2019;
7. DRM clients should comply with the provisions of Chapter 10 of GY/T 277-2019;
8. The DRM client interface should comply with the provisions of Appendix C of GY/T 277-2019;
9. The interface of the DRM client runtime environment should comply with the provisions of Appendix D in GY/T 277-2019.
10. The DRM client functional module should run securely in the DRM client runtime environment, which should have the ability to protect the integrity of the DRM client functional module. If the DRM client functional module is tampered with, it should stop working;
11. The DRM client runtime environment should securely protect values with confidentiality requirements and values with integrity requirements. If values with integrity requirements are tampered with, the DRM client functional module should be stopped;
12. Protected content should be securely decrypted, decoded, played, and output in the DRM client execution environment in accordance with the requirements of the content authorization license;
13. For content that requires DRM protection, terminal devices should not bypass the DRM client function;
14. Terminal devices should have the ability to upgrade DRM client security. When new security vulnerabilities arise, the DRM client should be able to be upgraded in a timely manner, and there should be no vulnerabilities within the official 6-month period.
4.3 DRM Client Runtime Environment
The DRM client runtime environment is divided into three security levels: software security level, hardware security level, and enhanced hardware security level. Software security level refers to the implementation of some or all DRM client runtime environments based on software security mechanisms; The hardware security level refers to the DRM client runtime environment implemented based on hardware security mechanisms; Enhancing hardware security level refers to the requirement that the DRM client's secure operating environment should have side channel attack defense, forensic watermarking, and other functions based on the hardware security level.
The evaluation of DRM client runtime environment includes:
1. The interface API of the DRM client runtime environment should comply with the provisions of Appendix D of GY/T 277-2019;
2. The DRM client runtime environment should have security capabilities such as secure boot, secure upgrade, secure storage, secure memory, secure video path, and password calculation.
4.4 DRM Operating System
The evaluation of DRM operating system includes:
1. DRM system server function evaluation;
2. DRM system server standard compliance assessment;
3. DRM client application software functionality and standard compliance assessment;
4. DRM system compliance assessment, mainly including: DRM server system components should pass the DRM server component assessment, DRM client devices and DRM client applications should pass the assessment, and DRM server and DRM client should deploy DRM server and DRM client certificates issued by DRM trust management agencies;
5. DRM system security management assessment;
6. DRM system security level assessment.
4.5 Video Digital Watermarking Technology
The evaluation of video digital watermarking technology includes:
1. Evaluation of video digital watermarking function;
2. Robustness evaluation of video digital watermarking technology;
3. Quality assessment of video content embedded with digital watermarking
AAA: Security Assessment Type
(1) DCE: DRM Client Runtime Environment
(2) DCD: DRM client device
(3) DCS: DRM client application
(4) CES: Content Encryption Component
(5) KMS: Key Management Component
(6) KGW: Key Gateway Component
(7) CAU: Content Authorization Component
(8) DSS: DRM Server System
(9) E2E: DRM Operating System
(10) VWM: Video Digital Watermark
2. BB: Safety level
(1) SW: Software Security Level
(2) HW: Hardware Security Level
(3) EH: Enhance hardware security level
(4) NA: Not applicable
3. CCCC: Entrusting institution code.
4. DDDDDD: Evaluation application number, which is an internal number of the evaluation agency, with a coding rule of year+month.
5. EE: The technology or product number applied for evaluation by the commissioning agency, and the laboratory's annual sequential number for the commissioning agency.
Note: DRM technology and product evaluation service related documents use this number as the unique identifier.
5、 Evaluation process
The workflow of DRM technology and product evaluation is shown in Figure 6-1.
1. Evaluation consultation
The commissioning agency that intends to apply for DRM technology and product evaluation can consult the laboratory on DRM technology and product evaluation matters; The laboratory provides the "DRM Technology and Product Evaluation Guide" to the commissioning institution, answers questions related to evaluation, and provides evaluation application suggestions based on the actual needs of the commissioning institution.
2. Application preparation
The commissioning agency shall provide the laboratory with the "DRM Technology and Product Evaluation Application Form" and the necessary documentation for the evaluation in accordance with the "DRM Technology and Product Evaluation Guidelines" based on the laboratory's recommendations.
Note: The evaluation application for DRM client devices and DRM client applications with accompanying DRM client functions must also submit the 'DRM Client Robustness Checklist'.
3. Apply for review
The laboratory conducts an application review of the "DRM Technology and Product Evaluation Application Form" submitted by the commissioning agency and the required documents for the evaluation application. The review examines whether the commissioning agency's evaluation application meets the evaluation conditions. If it does not meet the requirements, the commissioning agency should be advised to terminate the application in a timely manner. If it preliminarily meets the requirements, the commissioning agency should reply with the number of the "DRM Technology and Product Evaluation Application Form" submitted by the commissioning agency and form a "DRM Technology and Product Evaluation Application Confirmation Form", and notify the commissioning agency and laboratory to sign an evaluation service agreement.
Note: This process can be communicated via work email, and the commissioning agency does not need to submit a paper and stamped version of the DRM Technology and Product Evaluation Application Form.
4. Agreement signing
The laboratory provides an evaluation agreement template for the commissioning agency. After the legal departments of both parties confirm, the laboratory signs the evaluation service agreement according to the application process for signing the agreement with a seal; When the entrusted institution signs the service agreement, it should also submit the stamped version of the "DRM Technology and Product Evaluation Application Form" and attach the relevant technical documents in paper form for filing.
Note:
(1) The first application for DRM client runtime environment evaluation requires signing the "DRM Client SDK Integration Adaptation Authorization License Agreement";
(2) The first application for DRM client device evaluation and DRM client application evaluation with DRM client SDK must be accompanied by the signing of the DRM Client SDK Production and Manufacturing License Agreement.
5. Start evaluation
The laboratory communicates with the commissioning agency to confirm the evaluation content, evaluation cases, and evaluation schedule, forms an evaluation project work plan, and officially launches the evaluation.
6. Implementation evaluation
The laboratory carries out document evaluation, laboratory evaluation, on-site evaluation and other related evaluation work according to the evaluation project work plan, and forms corresponding evaluation record forms, which are jointly signed and confirmed by laboratory evaluators and commissioned institution personnel.
7. Evaluation and review
The laboratory organizes an evaluation and review meeting to review the evaluation records, form evaluation conclusions, and archive the evaluation process and conclusions in the form of evaluation and review meeting minutes.
8. Report preparation
The laboratory prepares an evaluation report based on the evaluation application form, technical documents provided by the commissioning agency, evaluation application confirmation form, evaluation record form, evaluation review meeting minutes and other documents, using the evaluation report template.
9. Report review
The laboratory reviews the initial draft of the report, and after the review is approved, it is signed by the report preparer, evaluator, and reviewer.
10. Report issuance
The laboratory prepares seal application materials according to the report issuance seal application, which are signed by the report approval personnel for seal approval. After approval, the original document is stamped and sent to the commissioning agency, while completing internal archiving and information entry management.
