HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy HW Revision: STM7007 © STMicroelectronics 2011 The document can be copied in its entirety without alteration. HC-SL3 SecPol Rev 1.1 Page 1 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Contents Introduction..................................................................................................................................... 3 Cryptographic Boundary................................................................................................................. 3 Cryptographic Algorithms .............................................................................................................. 3 Physical Ports and Logical Interfaces ............................................................................................. 4 Security rules .................................................................................................................................. 5 Identification and Authentication Policy ........................................................................................ 7 Access Control Policy..................................................................................................................... 9 Unauthenticated Services.............................................................................................................. 12 Physical Security Policy ............................................................................................................... 12 Mitigation of Other Attacks Policy............................................................................................... 12 Achieved level of security ............................................................................................................ 13 HC-SL3 SecPol Rev 1.1 Page 2 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Introduction The STMicroelectronics HardCache™-SL3/PC v2.1 Cryptographic Module (HW rev STM7007) is a single chip cryptographic module designed as a hardware accelerated encryption engine for computer and peripheral applications. The cryptographic module is targeted for PC applications including desktop client, laptop, and server systems. Benefits compared to competing hardware and software solutions include better overall system performance, low power, and tamper resistant hardware security. The cryptographic module is designed to be flexible, allowing administrative control of a wide range of features which simplify the security process to best fit an organization’s requirements. Cryptographic Boundary The cryptographic boundary is defined as the outer perimeter of the single chip IC packaging, with 32 pins exposed as physical ports. The following image defines the cryptographic boundary: Figure 1 Specification of Cryptographic Boundary Cryptographic Algorithms The cryptographic module supports the following Approved cryptographic algorithms: - AES 128, 192, 256 (ECB, CBC) Cert. #1068 - SHA-256, SHA-384, SHA-512 Cert. #1219 - HMAC-SHA-256, 384, 512 Cert. # 781 - TDES – 3keys (ECB, CBC) Cert. #798 - ECDSA Cert. #155 - RSA PKCS#1 v2.1, PSS ESMA (with SHA-256) Cert. #623 - ANSI X9.31 with AES-256 RNG Cert. #725 HC-SL3 SecPol Rev 1.1 Page 3 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy The cryptographic module supports the following non-Approved algorithms: In firmware: - RSA-2048 Decrypt PKCS#1 V2.1, OAEP (key wrapping; key establishment methodology provides 112 bits of encryption strength) - Non-approved hardware NDRNG (for seeding the Approved DRNG) Physical Ports and Logical Interfaces The cryptographic module support physical ports via 32 distinct pins, each with corresponding logical interfaces supported by the cryptographic module: data input, control input, data output, status output. Table 1 Specification of Cryptographic Module Physical Ports and Logical Interfaces Physical Port Logical Interface Pin 1: REFCLK+ Control Input Pin 2: REFCLK- Control Input Pin 3: 1.2V_PLL Power Pin 4: 1.2V TX Power Pin 5: PETp0 Data output, Status output Pin 6: PETn0 Data output, Status output Pin 7: 1.2V RX Power Pin 8: 2.5V Power Pin 9: PERn0 Data input, Control input Pin 10: PERp0 Data input, Control input Pin 11: 1.2V Power Pin 12: PP Control Input Pin 13: TDI Control input Pin 14: TRST# Control input Pin 15: PERST# Control input Pin 16: SS Data output, Status output Pin 17: 3.3V Power Pin 18: MOSI Data output, Status output Pin 19: MISO Data input, Control input Pin 20: SCLK Data output, Status output Pin 21: 2.5V Power Pin 22: rsvd N/A – disabled Pin 23: rsvd N/A – disabled Pin 24: CLKREQ# Status output Pin 25: PGOOD Control Input Pin 26: TDO N/A - disabled Pin 27: TCK N/A - disabled Pin 28: TMS N/A - disabled Pin 29: 1.2V Power HC-SL3 SecPol Rev 1.1 Page 4 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Physical Port Logical Interface Pin 30: 2.5V PLL Power Pin 31: GND_PLL Power Pin 32: REFRES Control Input Security rules The following specifies the security rules under which the cryptographic module shall operate: • The cryptographic module provides a single mode of operation that is FIPS approved. • Approved cryptographic algorithms shall be used to protect sensitive unclassified data. The cryptographic module shall not implement any Non-Approved cryptographic algorithms with the exception of RSA Decrypt for RSA based key transport and HW RNG for seeding the DRNG. • The cryptographic module design shall correspond to its finite state model and design specifications. • Critical security parameters shall be protected against unauthorized disclosure, modification and substitution. Public keys shall be protected against unauthorized modification and substitution. • The cryptographic module shall not allow the input or output of plaintext critical security parameters. • Logical separation between the data inputs, control inputs, data outputs, status outputs shall be enforced. The module shall receive power from an external source through its defined power ports. • While in an error state, the cryptographic module shall inhibit all data outputs, cease to provide cryptographic services, and shall provide an error status indication (error code: GPE_SELF_TEST_FAILED or GPE_STARTUP_FAILED). • All data outputs shall be inhibited during self-test conditions. Status information used to provide an indication of the results of self-tests shall not contain any CSPs, plaintext data, or other information that could be used to compromise the cryptographic module. • All data output paths shall be logically disconnected from the processes performing key generation and zeroization. • The cryptographic module shall not support manual key entry or split-knowledge processes. • A maintenance interface and maintenance role shall not be supported. • Cryptographic Officer, User and Storage Manager roles shall be supported. • Identity-based authentication shall be enforced for all services that utilize CSPs, utilize Approved security functions, and are otherwise security relevant. • Bypass capabilities, bypass states, and bypass tests shall not be supported. • Service inputs shall consist of all data or control inputs to the module that initiate or obtain specific services, operations, or functions. Service outputs shall consist of all data and status outputs that result from the services, operations, or functions initiated or obtained by service inputs. HC-SL3 SecPol Rev 1.1 Page 5 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy The feedback mechanism used during the authentication process shall not disclose any CSP • or other information that could be used to compromise the cryptographic module. Physical security provided by the cryptographic module via a hard enclosure that shall • prevent penetration to the depth of the underlying circuitry without having a high probability that the module is damaged to the extent that it no longer functions. The cryptographic module shall be constructed of production grade materials with standard passivation, tamper evidence, and shall be opaque within the visible spectrum. The cryptographic module shall include a non-modifiable operational environment. It shall • not be possible to physically or logically alter the executable instructions and logic that reside within the cryptographic boundary. Cryptographic keys shall be generated using the implemented Approved deterministic • random number generator. The design shall ensure that the seed and seed key input to the Approved RNG do not have the same value. The key generation process shall provide an equivalent computational resistance to attack of at least 256-bits of security. Intermediate key generation values shall not be output from the cryptographic module during the key generation process. Seed keys and cryptographic keys shall be entered into and output from the cryptographic • boundary in an encrypted form. A key-to-entity association shall be enforced for all keys that are entered into, output from, • and stored within the cryptographic boundary. The implemented zeroization techniques shall be performed in a time that is not sufficient to • compromise plaintext secret and private keys and CSPs. The cryptographic module shall conform to the EMI/EMC requirements specified by 47 • Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B (i.e., for home use). The cryptographic module shall support error states associated with each self-test and output • the expected error indicator upon entering into an error state resulting from a failed self-test. The following self-tests shall be supported: • Power up tests • Non-Approved hardware NDRNG continuous test • ANSI X9.31 with AES256 DRNG continuous test • HMAC-SHA-256 KAT • HMAC-SHA-512 KAT • AES 256 CBC encrypt/decrypt KAT • TDES 3 key CBC encrypt/decrypt KAT • RSA-2048 with SHA-256 signature generation/verification pairwise consistency test • ECDSA-256 signature generation KAT • ANSI X9.31 with AES256 DRNG KAT • HMAC-SHA-384 KAT • Critical functions test: RSA-2048 PKCS#1 V2.1, OAEP encrypt/decrypt pairwise consistency test HC-SL3 SecPol Rev 1.1 Page 6 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Conditional tests: • Non-Approved hardware NDRNG continuous test • ANSI X9.31 with AES256 DRNG continuous test • RSA PKCS#1 V2.1, OAEP encrypt/decrypt pairwise consistency test Upon successful completion of the power-up self-tests, the cryptographic module shall output • value 0 status; failure of any power-up self-test results in non-zero output status. The FIPS mode of operation indicator can be obtained through the “Get Capabilities” service which will return the following status: “fips140”. An operator can initiate the power-up self-tests on demand via power cycle or via a • command. Identification and Authentication Policy The cryptographic module supports a Cryptographic Officer and a User role through identity based authentication via HMAC verification using a 256-bit HMAC key. The cryptographic module also supports a Storage Manager role through identity based authentication via proof of possession of a 256-bit AES key through challenge/response. Table 2 Roles and Required Identification and Authentication (FIPS 140-2 Table C1) Type of Authentication Role Description Authentication Data The cryptographic officer manages the 256-bit HMAC key (CO Cryptographic Officer cryptographic module and enrolls Identity-based Session HMAC Key) users/identities. 256-bit HMAC key (User Users load keys and execute cryptographic User Identity-based Session HMAC Key) algorithms. 256-bit AES key (Storage Storage manager synchronizes the Storage Manager Identity-based Manager AES Key) cryptomodule with the host system. The strength of the implemented authentication mechanism exceeds the strength requirements imposed by FIPS 140-2. The following table declares the probabilities associated with random attempts, and multiple consecutive attempts within a one-minute period to subvert the implemented authentication mechanism. Table 3 Strengths of Authentication Mechanisms (FIPS 140-2 Table C2) Authentication Mechanism Strength of Mechanism HC-SL3 SecPol Rev 1.1 Page 7 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy HMAC verification The probability that a random attempt will succeed is 1 / 2^ 256. The probability of compromising the authentication mechanism through multiple consecutive attempt during a one minute period is 10000 / 2 ^ 256. AES Challenge/Response The probability that a random attempt will succeed is 1 / 2^ 256. The probability of compromising the authentication mechanism through multiple consecutive attempt during a one minute period is 10000 / 2 ^ 256. HC-SL3 SecPol Rev 1.1 Page 8 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Access Control Policy The following table itemizes all of the roles, services, cryptographic keys & CSPs, and types of access to the cryptographic keys & CSPs that are available to each of the authorized roles via the corresponding services. Definition of types of access: I: input O: output G: generate Z: zeroize U: use Table 4 Un-authenticated services Role Cryptographic Keys Type(s) of Services & CSPs Access None Self Test None None Get Capabilities None Get Status None None Z Zeroize cryptomodule All CSPs are zeroized None HC-SL3 SecPol Rev 1.1 Page 9 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Table 5 Services Authorized for Roles, Access Rights within Services (FIPS 140-2 Table C3, Table C4) Role Cryptographic Type(s) of Services Keys & CSPs Access User S.M. C.O. EK Public Key G,I,O EK Private Key G,I,O,U CO AES Seed Key I,O CO AES Nonce Key I,O Storage Manager AES key I,O Initialize Cryptographic X AES Root Seed Key G,U Module Random Number Pool G,U ANSI X9.31 DT Seed G,U ANSI X9.31 V Seed G,U AES Root Key G,U HMAC Root Key G,U CO AES Seed Key I,O,U CO AES Nonce Key I,O,U CO Session AES Key G,U Enroll Key X CO Session HMAC Key G,U User AES Seed Key I,O AES Root Key U HMAC Root Key U User AES Seed Key I,U User AES Nonce Key I,U Data Key I,U User Session AES Key G,U Enter Key and Execute X User Session HMAC Key G,U ANSI X9.31 DT Seed G,I,O,U ANSI X9.31 V Seed G,I,O,U AES Root Key U HMAC Root Key U User AES Seed Key I,O,U User AES Nonce Key I,O,U Data Key I,O User Session AES Key G,U Enter Key and Export X User Session HMAC Key G,U ANSI X9.31 DT Seed G,I,O,U ANSI X9.31 V Seed G,I,O,U AES Root Key U HMAC Root Key U Storage Manager AES Key I,U Authenticate Storage Manager AES Root Key U X HMAC Root Key U User AES Seed Key Z User AES Nonce Key Z Data Key Z Flush context X User Session AES Key Z User Session AES Key Z ANSI X9.31 DT Seed Z ANSI X9.31 V Seed Z HC-SL3 SecPol Rev 1.1 Page 10 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy User AES Seed Key O,Z User AES Nonce Key O,Z Data Key O,Z User Session AES Key G Save context X User Session AES Key G ANSI X9.31 DT Seed G,I,O,U ANSI X9.31 V Seed G,I,O,U AES Root Key U HMAC Root Key U User AES Seed Key I User AES Nonce Key I Data Key I User Session AES Key I Load context X User Session AES Key I ANSI X9.31 DT Seed I ANSI X9.31 V Seed I AES Root Key U HMAC Root Key U Description of the Services • Enter Key: Cryptographic Officer seals (i.e. enrolls) a User key and User authentication data. The key and authentication data inserted into the module via AES key wrap transport scheme. The output key is available to a User for subsequent use. • Enter Key and Execute: User loads his key into the cryptomodule in order to access services granted to both identity and the key kind; the following algorithms can be executed: • AES: User executes AES algorithm. • TDES: User executes TDES algorithm. • HMAC: User executes HMAC algorithm. • SHS: User executes Secure Hash Standard algorithm. • RSA Sign: User performs RSA PKCS#1 v2.1 PSS digital signature generation. • ECDSA: User executes ECDSA digital signature generation. • Change Seed Keys: User changes his own AES seed keys. • Enter Key and Export: User exports his key using AES key wrap transport. • Authenticate Storage Manager: Authenticates the Storage manager role. • Flush Key: Storage manager zeroizes a key currently loaded in the cryptographic module. • Save Context: Storage manager saves and zeroizes the key context currently loaded in the cryptographic module. • Load Context: Storage manager loads a key for which context has been previously saved by the Storage Manager. HC-SL3 SecPol Rev 1.1 Page 11 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy Unauthenticated Services The following services do not disclose, modify, or substitute CSPs, use an Approved security function, or otherwise affect the security of the cryptographic module. • Self Test: the cryptographic module performs all of the required power up self tests. • Get Capabilities: gives information about the state of the device. • Get Status: gives information about the state of non-security relevant hardware. • Zeroize: zeroize all CSPs. Physical Security Policy The physical security employed by the cryptographic modules consists of a production grade IC packaging that is hard, opaque, and tamper evident. The following table described the responsibilities and actions required by the operator to ensure that physical security is maintained. Table 6 Inspection/Testing of Physical Security Mechanisms (FIPS 140-2 Table C5) Recommended Physical Security Inspection/Test Guidance Frequency of Mechanisms Details Inspection/Test Hard, opaque, tamper Upon receipt Perform a thorough visual evident IC packaging inspection on all sides and angles of the enclosure for any signs of damage and malice including but not limited to scratches, scrapes, gouges, bent or broken pins, deterioration, discoloring. If any suspicious characteristics are observed, the cryptographic module is to be returned to the manufacturer. Mitigation of Other Attacks Policy Specify a security policy for mitigation of other attacks, including the security mechanisms implemented to mitigate the attacks. Table 7 Mitigation of Other Attacks (FIPS 140-2 Table C6) Other Attacks Mitigation Mechanism Specific Limitations man-in-the-middle session tracking with HMAC-SHA-256 integrity shared secret, rolling verification over nonces, handle and signed authenticated services messages HC-SL3 SecPol Rev 1.1 Page 12 HardCache™-SL3/PC v2.1 FIPS 140-2 Security Policy replay session tracking with HMAC-SHA-256 integrity shared secret, rolling verification over nonces, handle and signed authenticated services messages Achieved level of security Table 8 Achieved Level Of Security FIPS 140-2Security Requirements Area Level Cryptographic Module Specification 3 Cryptographic Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI/EMC 3 Self-tests 3 Design Assurance 3 Mitigation of Other Attacks 3 References • [AES Key Wrap] National Institute of Standards and Technology (NIST), AES Key Wrap Specification, 2001 November • [ANS X9.31 1998] American National Standard for Financial Services, Digital Signature Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) • [ANS X9.62 2005] American National Standard for Financial Services, Public Key Cryptography for the Financial Service Industry, ECDSA • [FIPS140] National Institute of Standards and Technology (NIST), Security Requirements for Cryptographic Modules, FIPS Pub 140-2, 2001 May • [FIPS 186] National Institute of Standards and Technology (NIST), Digital Signature Standard, FIPS Pub 186, 2006 March • [NIST SP800-56] National Institute of Standards and Technology (NIST), Recommendation for Pair- Wise Key Establishment Scheme • [NIST SP800-57] National Institute of Standards and Technology (NIST), Recommendation for Key Management – Part 1: General, NIST Special Publication 800-57, 2007 March • [NIST SP800-90] National Institute of Standards and Technology (NIST), Recommendation for Random Number Generation Using Deterministic Random Bit Generators • [NIST 931 RNG Ext] National Institute of Standards and Technology (NIST), Random Number Generator Based on ANSI X9.31 Appendix A.2.4 Using TDES and AES • [PKCS#1 v2.1] RSA Laboratories, RSA Cryptography Standard HC-SL3 SecPol Rev 1.1 Page 13