Sony Security Module Security Policy Document Version 1.0.0 Sony Corporation FIPS 140-2 Non-Proprietary Copyright 2010© Sony Corporation May be reproduced only in its original entirety [without revision] Sony Corporation Sony Security Module Security Policy Version 1.0.0 TABLE OF CONTENTS 1.  MODULE OVERVIEW .................................................................................................................... 3  2.  SECURITY LEVEL ........................................................................................................................... 5  3.  MODES OF OPERATION................................................................................................................ 6  APPROVED MODE OF OPERATION ...............................................................................................................................6  4.  PORTS AND INTERFACES ............................................................................................................ 7  5.  IDENTIFICATION AND AUTHENTICATION POLICY............................................................ 8  ASSUMPTION OF ROLES ..............................................................................................................................................8  6.  ACCESS CONTROL POLICY ........................................................................................................ 9  ROLES AND SERVICES ................................................................................................................................................9  DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS) ......................................................................................11  DEFINITION OF PUBLIC KEYS:..................................................................................................................................11  DEFINITION OF CSPS MODES OF ACCESS ................................................................................................................12  7.  OPERATIONAL ENVIRONMENT .............................................................................................. 14  8.  SECURITY RULES ......................................................................................................................... 14  9.  PHYSICAL SECURITY POLICY ................................................................................................. 16  PHYSICAL SECURITY MECHANISMS .........................................................................................................................16  OPERATOR ACTIONS ................................................................................................................................................16  10.  POLICY ON MITIGATION OF OTHER ATTACKS ............................................................ 17  11.  DEFINITIONS AND ACRONYMS ........................................................................................... 17  12.  REVISION HISTORY ................................................................................................................ 18  May be reproduced only in its original entirety [without revision] Page 2/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 1. Module Overview The Sony Security Module (SSM) is a multi-chip embedded cryptographic module that is encased in a hard opaque commercial grade metal case. The cryptographic boundary is defined as the entire metal case perimeter, including all hardware, software, and firmware encapsulated within. The interfaces are all traces that cross the cryptographic boundary. The primary purpose of the Sony Security Module is to provide decryption, decoding/encoding of audio/video data for the digital cinema projector system in which it is used. The diagram below provides an illustration of the cryptographic module, along with the intended cryptographic boundary. Top Bottom Figure 1 – Image of the Cryptographic Module The SSM is validated hardware version 1.1.0 / firmware version 1.1.0. May be reproduced only in its original entirety [without revision] Page 3/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 The SSM firmware configurable hierarchy is as follows: Firmware version 1.1.0 Nios version 01.01.22 CTU version 02.05 PAD version 03.06.02 Figure 2 – SSM firmware configuration May be reproduced only in its original entirety [without revision] Page 4/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 2. Security Level The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS 140-2. Table 1 - Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 3 Module Ports and Interfaces 2 Roles, Services and Authentication 3 Finite State Model 2 Physical Security 3 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A May be reproduced only in its original entirety [without revision] Page 5/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 3. Modes of Operation Approved mode of operation The module is designed to continually operate in a FIPS approved mode of operation. A FIPS non-approved mode of operation is not supported. The cryptographic module supports the following FIPS approved cryptographic algorithms:  AES with 128 bit key (as per FIPS-197) - CBC mode of operation - Certificates : #901 and #1470 - ECB mode of operation - Certificate : #902  SHA-1 with 160 bit hash value (as per FIPS 180-3) - Certificates : #882 and #1330  SHA-256 with 256 bit hash value (as per FIPS 180-3) - Certificate : #882  RSA Key Generation and Signature Generation/Verification with 2,048 bit keys (as per PKCS#1 v1.5) - Certificate : #724  ANSI X9.31 RNG using TDES-2Key (as per ANSI X9.31) - Certificate : #517  FIPS 186-2 RNG using SHA-1 (as per FIPS 186-2) - Certificate : #804  HMAC-SHA-1 with 160 bit key (as per FIPS 198) - Certificates : #865 and #866 In addition to the above algorithms, the module employs the following FIPS non-approved algorithms that are to be used in the FIPS approved mode of operation.  RSA only for key wrapping. (Key establishment methodology provides 112-bits of encryption strength)  HMAC-MD5 for the pseudo random function in TLS 1.0.  NDRNG for the seeding of the above RNG By verifying that the firmware versions identified using the 'Get Status' service match each of the validated firmware component versions listed in Section 1, the operator can be assured that the module is in the Approved mode. May be reproduced only in its original entirety [without revision] Page 6/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 4. Ports and Interfaces The SSM’s physical interfaces are the traces that cross the perimeter of the physical cryptographic boundary. These traces support the following logical interfaces required by FIPS 140-2:  Data Input  Data Output  Status Output  Control Input  Power Input In addition, the module receives power from an outside source and thus supports a power input interface. The module has six status output interfaces. The operator can identify the status of the SSM by monitoring those interfaces. May be reproduced only in its original entirety [without revision] Page 7/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 5. Identification and Authentication Policy Assumption of roles The SSM shall support two distinct operator roles (User and Crypto-Officer). The cryptographic module shall enforce the separation of roles using identity-based operator authentication. The operator is authenticated using the RSA 2048 signature verification algorithm or an ID and password. Table 2 - Roles and Required Identification and Authentication Role Type of Authentication Authentication Data  RSA Digital Certificate User Identity-based operator authentication (Field)  ID and Password  RSA Digital Certificate Crypto-Officer Identity-based operator authentication (Factory)  ID and Password Table 3 - Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism RSA Digital Certificate The authentication is based on RSA 2048, which has an equivalent strength of 112-bits1. Therefore, the probability Verification with which a random attempt will succeed or a false acceptance will occur is 2-112, which is less than 1/1,000,000. There is a 10msec delay after each trial which limits the number of attempts per minute. The probability of a random attempt successfully authenticating to the module within one minute is also 1.16E-30, which is less than 1/100,000. ID and Password The SSM accepts 64 possible characters and a minimum 8- Verification characters for a Password, and the probability with which a random attempt will succeed or a false acceptance will occur is 2-48, which is less than 1/1,000,000. There is a 10msec delay after each trial which limits the number of attempts per minute. The probability of a random attempt successfully authenticating to the module within one minute is also 2.13E-11, which is less than 1/100,000. 1 Reference SP800-57 May be reproduced only in its original entirety [without revision] Page 8/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 6. Access Control Policy Roles and Services Table 4 - Crypto-Officer Specific Service Service Description Control Data Sets AES shared key and Public Key Certificate Firmware Update Updates the firmware of the module* User Control Edits a user ID and Password Generate RSA Key Generates a RSA Key pair Zeroization Destroys all Critical Security Parameters * Note: If a non-FIPS validated firmware version is loaded onto the module, then the module is no longer a FIPS validated module. Table 5 - Crypto-Officer and User Common Service Service Description KDM Control Controls KDM (import, Clear) Playback Controls the playback of Contents (Video and Audio) Set Time Sets the RTC time Get Time Obtains the RTC time Get Status Obtains the status of the module as well as the version number External Security Control Obtains the status of external devices connected to SSM. Sign Data Signs data Get Session Data Decrypts the data needed to establish a TLS session Get Random Number Provides a random number Get Certificate Obtains a certificate Set Log Sets external log data May be reproduced only in its original entirety [without revision] Page 9/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 Service Description Get Log Obtains log data Changes the personal password (C.O. can change all user Change Password passwords) Contents Validate Validates DCP Table 6 - Unauthenticated Service Service Description Show Status Obtains the module status May be reproduced only in its original entirety [without revision] Page 10/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 Definition of Critical Security Parameters (CSPs) The following are CSPs contained in the module:  Contents Encryption Keys (CEK) – AES key used to decrypt media data.  Content Integrity Key(CIK) – The HMAC seed key used to check the integrity of contents.  Key Encryption Key (KEK) – AES key used to protect RSK, DPK, and TPK.  Device Link Key (DLK) – AES key used to protect a channel with the SSM Control Procedure.  Temporary Device Link Key (TDLK) – Temporary AES key used to protect a channel with the SSM Control Procedure.  TLS Session Key (TSK) – The AES key established in TLS.  TLS MAC Secret (TMACS) – The HMAC key established in TLS.  RSA Signing Key (RSK) – RSA private key for the generation of a digital signature for the log data.  Device Private Key (DPK) – RSA private key used to decrypt wrapped cryptographic keys entered into the module.  TLS Private Key (TPK) – RSA private key for TLS.  TLS Premaster Secret (TPS) – The parameter used for key establishment in TLS.  TLS Master Secret (TMS) – The parameter used for key establishment in TLS.  PRF State(PS) – The internal state used for key establishment in TLS.  Authentication Secrets (AS) – The User and Crypto-Officer password used to authenticate the operator.  Seed and Seed Key (SSK) – The secret values necessary for the FIPS approved RNG. Definition of Public Keys: The following are the public keys contained in the module:  SSM Manufacturer Public Key – RSASSA 2048 public key used to verify a certificate chain of trust.  SSM Trusted Public Key – RSASSA 2048-bit public key used to verify a certificate chain of trust.  RSA Verifying Key – RSASSA public key corresponded to the RSA Signing Key. May be reproduced only in its original entirety [without revision] Page 11/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0  Public Key for F/W Upgrade – RSASSA public key used to verify the digital signature over the firmware image to be upgraded.  Operator Public Key – RSAES public key used to authenticate operators.  Device Public Key – RSAES public key corresponded to the Device Private Key.  TLS Public Key – RSAES public key corresponded to the TLS Private Key. Definition of CSPs Modes of Access Table 7 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as follows:  Generate (G) : the CSP is generated using the approved RNG.  Use (U) : the CSP is used to perform cryptographic operations within its corresponding algorithm.  Entry (E) : the CSP is entered into the module.  Output (O) : the CSP is output from the module.  Zeroize (Z) : the CSP is destroyed. Table 7 - CSP Access Rights within Roles & Services Role Service CSPs C.O. User KEK(E), DLK(E,U), TDLK(U), TSK(U), TMACS(U), X Control Data RSK(U), DPK(U), TPK(U) DLK(U), TDLK(U), TSK(U), TMACS(U) Firmware X Update DLK(U), TDLK(U), TSK(U), TMACS(U), AS(E,Z) X User Control KEK(U), DLK(U), TDLK(U), TSK(U), TMACS(U), Generate X RSK(G), DPK(G), TPK(G), SSK(U) RSA Key CEK(Z), CIK(Z), KEK(Z), DLK(Z), TDLK(Z), TSK(Z), X TMACS(Z), RSK(Z), DPK(Z), TPK(Z), TPS(Z), TMS(Z), Zeroization PS(Z), SSK(Z) CEK(E,Z), DLK(E,U), TDLK(U), DPK(U), TSK(U), X X KDM Control TMACS(U), SSK(U) May be reproduced only in its original entirety [without revision] Page 12/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 Role Service CSPs C.O. User CEK(U), CIK(G,U,Z), DLK(U), TDLK(U), TSK(U), X X Playback TMACS(U), SSK(U) DLK(U), TDLK(U), TSK(U), TMACS(U) X X Set Time DLK(U), TDLK(U), TSK(U), TMACS(U) X X Get Time DLK(U), TDLK(U), TSK(U), TMACS(U) X X Get Status DLK(U), TDLK(U), TSK(U), TMACS(U) External X X Security Control DLK(U), TDLK(U), TSK(U), TMACS(U), RSK(U) X X Sign Data DLK(U), TDLK(U), TSK(U), TMACS(U) Get X X Session Data DLK(U), TDLK(U), TSK(U), TMACS(U), SSK(U) X X Get Random Number DLK(U), TDLK(U), TSK(U), TMACS(U) X X Get Certificate DLK(U), TDLK(U), TSK(U), TMACS(U) X X Set Log DLK(U), TDLK(U), TSK(U), TMACS(U) X X Get Log DLK(U), TDLK(U), TSK(U), TMACS(U), AS(E,U) X X Change Password DLK(U), TDLK(U), TSK(U), TMACS(U) X X Contents Validate - - Show Status * TPS, TMS, and PS are generated, used and zeroized in TLS establishment. May be reproduced only in its original entirety [without revision] Page 13/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 7. Operational Environment The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because the module does not contain a modifiable operational environment. 8. Security Rules The Sony Security Module was designed with the following security rules in mind. These rules are comprised of both those specified by FIPS 140-2 and those derived from Sony’s company policy. 1. The cryptographic module shall provide two distinct operator roles. These are the User role, and the Crypto-Officer role. 2. The cryptographic module shall provide identity-based authentication. 3. When the module has not been placed in an authenticated role, the operator shall not have access to any cryptographic services. 4. The cryptographic module shall perform the following tests : A. Power-up Self-Tests: 1. Cryptographic algorithm tests (for each implementation) : a. AES 128 CBC Encryption/Decryption Known-Answer Test b. AES 128 ECB Encryption/Decryption Known-Answer Test c. ANSI X9.31 RNG Known-Answer Test d. FIPS 186-2 RNG Known-Answer Test e. SHA-1 Known-Answer Test f. SHA-256 Known-Answer Test g. HMAC-SHA-1 Known-Answer Test h. RSA PKCS#1 v1.5 Signature Generation/Verification Known-Answer Test i. RSA OAEP Pair-wise Consistency Test j. RSA PKCS#1 v1.5 Pair-wise Consistency Test 2. Firmware Integrity Test (CRC-32) 3. Critical Functions Test: a. RAM Check (SD-RAM, DP-RAM) B. Conditional Self-Tests: 1. Continuous Random Number Generator (RNG) test a. RNG (ANSI X9.31 RNG and FIPS 186-2 RNG) b. NDRNG May be reproduced only in its original entirety [without revision] Page 14/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 2. RSA Pair-wise Consistency Test (if internal generation is being done) 3. Firmware Load Test (RSA Digital Signature Verification) 5. The operator shall be capable of commanding the module to perform the power-up self- test using recycling power. 6. Data output shall be inhibited during self-tests, zeroization, and error states. 7. Data output shall be logically disconnected from key generation processes. 8. Status information shall not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 9. The module supports multiple concurrent operators of up to two operators. 10. The module shall not support a bypass capability or a maintenance interface. 11. If a non-FIPS validated firmware version is loaded onto the module, then the module is ceases to be a FIPS validated module. 12. 2-key TDES is used in DRNG only, and is not used to encrypt data. 13. HMAC-MD5 is only used in TLS, and is not used to verify any other data. May be reproduced only in its original entirety [without revision] Page 15/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 9. Physical Security Policy Physical Security Mechanisms The Sony Security Module is a multi-chip embedded cryptographic module with the following physical security mechanisms:  Production-grade components,  The enclosure does not have a removable cover, door or ventilation slits,  The enclosure is opaque and provides tamper evidence,  The enclosure is sufficiently hard, providing tamper resistance in accordance with FIPS 140-2 level 3 physical security requirements. Operator Actions Due to the intended deployment environment for the module, Sony defers the physical inspection criteria to the end user of the cryptographic module. Any such inspection shall be based on the customer security policy, in particular with regards to the inspection frequency. Table 8 - Inspection/Testing of Physical Security Mechanisms Physical Security Recommended Frequency Inspection/Test Guidance Mechanisms of Inspection/Test Details Unexpected chips, scratches, Hard Non-Removable To be determined or deformation of the metal Enclosure by the end user case May be reproduced only in its original entirety [without revision] Page 16/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 10. Policy on Mitigation of Other Attacks The module was not designed to mitigate other attacks. Therefore, this section is not applicable. Table 9 - Mitigation of Other Attacks Other Attack Mitigation Mechanism Specific Limitations N/A N/A N/A 11. Definitions and Acronyms Term Definition Advanced Encryption Standard AES Critical Security Parameter CSP Counter Tampering & Tamper Detection Unit CTU Digital Cinema Initiative DCI Digital Cinema Package DCP Deterministic RNG DRNG Electromagnetic Interference / Electromagnetic Compatibility EMI / EMC Hash-based Message Authentication Code HMAC Key Delivery Message KDM Embedding processer that runs within the PAD (FPGA) Nios Optimal Asymmetric Encryption Padding OAEP FPGA that processes video and audio data PAD Public Key Cryptography Standards PKCS Pseudo Random Function PRF Random Number Generator RNG Rivest-Shamir-Adleman RSA Real Time Clock RTC Secure Hash Algorithm SHA Sony Security Module SSM Triple Data Encryption Standard TDES Transport Layer Security TLS May be reproduced only in its original entirety [without revision] Page 17/18 Sony Corporation Sony Security Module Security Policy Version 1.0.0 12. Revision History Date Version Description Sep. 28, 2010 1.0.0 Initial release May be reproduced only in its original entirety [without revision] Page 18/18