FIPS 140-2 Security Policy SafeZone FIPS Cryptographic Module INSIDE Secure B.V. (formerly a division of AuthenTec Inc.) Boxtelseweg 26A 5261 NE Vught The Netherlands Phone: +31-73-6581900 Fax: +31-73-6581999 INSIDE Secure Corporate Headquarters 41 Parc Club du Golf 13856 Aix-en-Provence, France Phone: +33 (0)4 42 39 63 00 2013-03-15 Revision C Software Version 1.0.3 Document Number: 001-921100-407 Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 1 of 27 1 Introduction .................................................................................................................. 3 1.1 Purpose................................................................................................................ 4 1.2 Security level ...................................................................................................... 4 1.3 Glossary .............................................................................................................. 5 2 Ports and Interfaces ...................................................................................................... 6 3 Roles, Services, and Authentication ............................................................................ 7 3.1 Roles and Services .............................................................................................. 7 3.1.1 User Role ........................................................................................................ 7 3.1.2 Crypto-officer Role ......................................................................................... 8 3.2 Authentication Mechanisms and Strength .......................................................... 9 4 Secure Operation and Security Rules ........................................................................ 10 4.1 Security Rules ................................................................................................... 10 4.2 Physical Security Rules..................................................................................... 11 4.3 Secure Operation Initialization Rules ............................................................... 11 5 Definition of SRDIs (Security Relevant Data Items) Modes of Access .................... 12 5.1 FIPS Approved and Allowed algorithms .......................................................... 12 5.2 Cryptographic Keys, CSPs, and SRDIs ............................................................ 15 5.3 Access Control Policy ....................................................................................... 19 5.4 Algorithm details .............................................................................................. 23 5.4.1 NIST SP 800-108: Key Derivation Functions .............................................. 23 5.4.2 NIST SP 800-132: Password-Based Key Derivation Function .................... 23 5.4.3 NIST SP 800-38D: Galois/Counter Mode .................................................... 23 5.4.4 NIST SP 800-90: Deterministic Random Bit Generator............................... 24 6 Self Tests.................................................................................................................... 25 6.1 Power-Up Self-Tests ......................................................................................... 25 6.2 Conditional Self tests ........................................................................................ 26 7 Mitigation of Other Attacks ....................................................................................... 27 Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 2 of 27 FIPS 140-2 Security Policy SafeZone FIPS Cryptographic Module 1 Introduction SafeZone FIPS Cryptographic Module is a FIPS 140-2 Security Level 1 validated software cryptographic module from AuthenTec/INSIDE Secure. This module is a toolkit that provides the most commonly used cryptographic primitives for a wide range of applications, including primitives needed for VPN (Virtual Private Network), TLS (Transport Layer Security), DAR (Data-At-Rest), and DRM (Digital Rights Management) clients. SafeZone FIPS Cryptographic Module is a software-based product with a custom, small-footprint API (Application Programming Interface). The cryptographic module has been designed to provide the necessary cryptographic capabilities for other AuthenTec/INSIDE Secure products. However, it can also be used stand-alone in custom-developed products to provide the required cryptographic functionality. The module is primarily intended for embedded products with a general-purpose operating system. Figure 1: SafeZone FIPS Cryptographic Module Cryptographic Boundary Physical Cryptographic Boundary Logical Cryptographic Boundary Data Output Persistent ROM RAM Storage Data Input SafeZone FIPS Lib Control Input Peripherals CPU Status Output Remote Devices Power Supply For FIPS 140-2 purposes, SafeZone FIPS Cryptographic Module is classified as a multi-chip standalone cryptographic module. Within the logical boundary of SafeZone FIPS Cryptographic Module is the libsafezone-sw-fips.a object code library, also known as SafeZone FIPS Lib. The physical cryptographic boundary of Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 3 of 27 the module is the enclosure of a general-purpose computing device executing the application that embeds the SafeZone FIPS Cryptographic Module. The SafeZone FIPS Cryptographic Module (v1.0.3) has been tested for validation on the following platforms: Processor / Tested Platform Operating System 1 ARM Cortex-A9 (ARMv7) / Pandaboard Linux /kernel 2.6 (Ubuntu 11.04) (single-user mode) ARM Cortex-A9 (ARMv7) / Pandaboard Android/2.3 (single-user mode) ARM Cortex-A9 (ARMv7) / Pandaboard Android/4.0 (single-user mode) Compliance is maintained for all of the above operating system platforms on which the binary executes unchanged. The module has been confirmed by the vendor to be operational on the following platforms, for which the module can be recompiled according to FIPS 140-2 Implementation Guidance G.5. Implementation Guidance G.5 Recompilation Processor Operating System ARM Cortex-M3 (ARMv7) FreeRTOS (single-user mode) 1.1 Purpose The purpose of this document is to describe the secure operation of the SafeZone FIPS Cryptographic Module including the initialization, roles, and responsibilities of operating the product in a secure, FIPS-compliant manner. 1.2 Security level The cryptographic module meets the overall requirements applicable to Level 1 security of FIPS 140-2. 1 Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. All other brands and product names are trademarks or registered trademarks of their respective owners. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 4 of 27 Security Level Security Requirements Specification Level Cryptographic Module Specification 1 Module Ports and Interfaces 1 Roles, Services, and Authentication 1 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self-Tests 1 Design Assurance 1 Mitigation of Other Attacks N/A 1.3 Glossary Term/Acronym Description AES Advanced Encryption Standard API Application Programming Interface CMVP Cryptographic Module Validation Program (FIPS 140) CSP Critical Security Parameter DRM Digital Rights Management DSS Digital Signature Standard EC Elliptic Curve FIPS Federal Information Processing Standard KEM Key-Encapsulation Mechanism (See NIST SP 800-56B) SHS Secure Hash Standard SRDI Security Relevant Data Item Triple-DES Triple Data Encryption Standard VPN Virtual Private Network Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 5 of 27 2 Ports and Interfaces As a software-only module, the SafeZone FIPS Cryptographic Module provides an API logical interface for invocation of FIPS140-2 approved cryptographic functions. The functions shall be called by the referencing application, which assumes the operator role during application execution. The API, through the use of input parameters, output parameters, and function return values, defines the four FIPS 140- 2 logical interfaces: data input, data output, control input and status output. Logical API Interfaces Data Input The data read from memory area(s) provided to the invoked function via parameters that point to the memory area(s). Control Input The API function invoked and function parameters designated as control inputs. Data Output The data written to memory area(s) provided to the invoked function via parameters that point to the memory area(s). Status Output The return value of the invoked API function. Power Interface Not accessible via the API. The power interface is used as applicable on the physical device. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 6 of 27 3 Roles, Services, and Authentication The SafeZone FIPS Cryptographic Module supports the Crypto Officer and User roles. The operator of the module will assume one of these two roles. Only one role may be active at a time. The Crypto Officer role is assumed implicitly upon module installation, uninstallation, initialization, zeroization, and power-up self-testing. If initialization and self-testing are successful, a transition to the User role is allowed and the User will be able to use all keys and cryptographic operations provided by the module, and to create any CSPs (except Trusted Root Key CSPs which may only be created in the Crypto Officer role). The four unique run-time services given only to the Crypto Officer role are the ability to initialize the module, to set-up key material for Trusted Root Key CSP(s), to modify the entropy source, and to switch to the User role to perform any activities allowed for the User role. The SafeZone FIPS Cryptographic Module does not support concurrent operators. 3.1 Roles and Services The module does not authenticate the operator role. 3.1.1 User Role The User role is assumed once the Crypto Officer role is finished with module initialization and explicitly switches the role using the FL_LibEnterUserRole API function. The User role is intended for common cryptographic use. The full list of cryptographic services available to the User role is supplied in chapter 5 of this document. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 7 of 27 Service Description All services except installation, All standard cryptographic operations of initialization, entropy source nomination, the module, such as symmetric and creation of Trusted Root Key CSPs. encryption, message authentication codes, and digital signatures. The User role may also allocate the key assets and load values for any of these cryptographic purposes. The SafeZone FIPS Cryptographic Module also provides a ‘Show Status’ service (API function FL_LibStatus) that can be used to query the current status of the cryptographic module. A macro based on FL_LibStatus is provided (FL_IS_IN_APPROVED_MODE), which returns true if the module is currently in an approved mode of operation. 3.1.2 Crypto-officer Role The Crypto Officer role can perform all the services allowed for the User role plus a handful of additional ones. Separate from the run-time services of the module, the tasks of installing and uninstalling the module to and from the host system imply the role of a Crypto Officer. The four run-time services available only to the Crypto Officer are initializing the module for use, creating key material for Trusted Root Key CSPs, modifying the entropy source, and switching to the User role. Service Description All services allowed for User role See above. Initialization Loading and preparing the module for use. Trusted Root Key creation Load key material into the module for local security purposes (FL_RootKeyAllocateAndLoadValue). Entropy Source Select the provider of the external entropy source. (FL_RbgInstallEntropySource). Uses the FL_LibEnterUserRole API Switch to the User Role function to switch to User role. Installation When the module is installed to a host system. Uninstallation When the module is removed from a host system. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 8 of 27 3.2 Authentication Mechanisms and Strength FIPS 140-2 Security Level 1 does not require role-based or identity-based operator authentication. The SafeZone FIPS Cryptographic Module will not authenticate the operator. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 9 of 27 4 Secure Operation and Security Rules In order to operate the SafeZone FIPS Cryptographic Module securely, the operator should be aware of the security rules enforced by the module and should adhere to the rules for physical security and secure operation. 4.1 Security Rules To operate the SafeZone FIPS Cryptographic Module securely, the operator of the module must follow these instructions: 1. The operating environment that executes the SafeZone FIPS Cryptographic Module must ensure single operator mode of operation to be compliant with the requirements for the FIPS 140-2 Level 1. 2. The operator must not call ptrace or strace functions, or run gdb or other debugger when the module is in the FIPS mode. 3. If the hardware platform has a connector for an external debugger (for example JTAG), that connector must not be used while the module is in FIPS mode. 4. The SafeZone FIPS Cryptographic Module keeps all CSPs and other protected objects in Random Access Memory (RAM). The operator(s) must only use these objects via the handles provided by the SafeZone FIPS Cryptographic Module. It is not permissible to directly access these objects in the memory. 5. The operator must not call functions provided by the SafeZone FIPS Cryptographic Module that are not explicitly specified in the appropriate guidance document for User or Crypto Officer. 6. When using cryptographic services provided by the SafeZone FIPS Cryptographic Module, the operator must follow the appropriate guidance for each cryptographic algorithm. Although the cryptographic algorithms provided by the SafeZone FIPS Cryptographic Module are recommended or allowed by NIST, secure operation of these algorithms requires thorough understanding of the recommendations and appropriate limitations. 7. The SafeZone FIPS Cryptographic Module aims to be flexible and therefore it includes support for cryptographic algorithms or key lengths that are considered secure only until 2013 according NIST SP 800-131A. It is the responsibility of the SafeZone FIPS Cryptographic Module user to ensure that algorithms or key lengths are not used anymore once they are deprecated. 8. Some of the implemented cryptographic algorithms offer key lengths exceeding the current NIST specifications. Such key lengths must not be used, unless following newer guidance from NIST. a. RSA Key Pair Generation provided by the module (FIPS 186-3 B.3.6) is only FIPS-approved for RSA modulus sizes of 1024 bits, 2048 bits and 3072 bits. It is not permissible to generate keys using other RSA modulus sizes. b. For RSA Signature Generation using modulus sizes 1536 bits or 4096 bits the RSA private key must be provided by the operator, and RSA Key Pair Generation must not be used. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 10 of 27 9. The Crypto Officer must ensure that the Trusted Root Key has sufficient entropy to meet all FIPS 140-2 requirements for its usage in the module. 4.2 Physical Security Rules The physical device on which the SafeZone FIPS Cryptographic Module is executed must follow the physical security rules applicable to the purpose of the device. The SafeZone FIPS Cryptographic Module is software-based and does not provide physical security. 4.3 Secure Operation Initialization Rules The SafeZone FIPS Cryptographic Module must be linked with an application to become executable. The software code of the module (the libsafezone-sw- fips.a object code library) is linked with an end application producing an executable application for the target platform. The application is installed in a platform-specific way, e.g. when purchased from an application store for the platform. In some cases there is no need for installation, e.g. when a mobile equipment vendor includes the application with the equipment. The SafeZone FIPS Cryptographic Module must be initialized using the FL_LibInit API function and it must be ensured that the FL_LibInit returns FLR_OK (constant value 0), which signifies a successful module initialization. The SafeZone FIPS Cryptographic Module does not support operator authentication and thus does not require any authentication itself. The SafeZone FIPS Cryptographic Module is always in FIPS-approved mode once initialized and thus no action is required to pick the mode of operation either. Usually, the module does not require any special set-up or initialization except for installation. The module is designed to be used only in FIPS-approved mode and does not provide functions for initialization in non-FIPS mode. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 11 of 27 5 Definition of SRDIs (Security Relevant Data Items) Modes of Access This chapter specifies security relevant data items as well as the access control policy that is enforced by the SafeZone FIPS Cryptographic Module. Each SRDI is held in the asset store accompanied by a security usage policy. The policy is set when the asset is allocated with FL_RootKeyAllocateAndLoadValue, FL_AssetAllocate or FL_AssetAllocateBasic. When the asset is accessed for use in a cryptographic operation, the policy is tested to ensure that the asset is eligible for the requested use. A policy typically consists of the allowed algorithm(s), the allowed strength of the algorithm, and the direction of the operation (encryption or decryption). 5.1 FIPS Approved and Allowed algorithms The SafeZone FIPS Cryptographic Module implements the following FIPS-approved algorithms: Algorithm Implementation Details Algorithm Certificate RSA 1024, 1536, 2048, 3072, and #1061 FIPS 186-2 4096 bit keys; PKCS #1 v1.5 and PSS RSA 1024, 2048, and 3072 bit #1061 FIPS 186-3 keys; PKCS #1 v1.5 and PSS DSA P=1024/N=160, #648 FIPS 186-3 P=2048/N=224, P=2048/N=256, P=3072/N=256 ECDSA NIST P-192, P-224, P-256, #299 FIPS 186-2/3 P-384 and P-521 curves AES 128, 192, 256 bit keys; #2041 FIPS 197, ECB, CBC, CTR mode NIST SP 800-38A AES CCM 128, 192, 256 bit keys #2041 NIST SP 800-38C AES GCM 128, 192, 256 bit keys #2041 NIST SP 800-38D XTS-AES 256, 512 bit keys #2041 NIST SP 800-38E (128-bit or 256-bit encryption strength) Triple-DES 192 bit keys; ECB and CBC #1318 NIST SP 800-67 mode CMAC 128, 192, 256 bit keys #2041 NIST SP 800-38B Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 12 of 27 Algorithm Implementation Details Algorithm Certificate HMAC 80-512 bit keys; SHA-1, #1240 FIPS 198-1 SHA-224, SHA-256, SHA- 384, SHA-512 SHS SHA-1, SHA-224, SHA- #1787 FIPS 180-3 256, SHA-384, SHA-512; BYTE only DRBG AES-256-CTR with df #203 NIST SP 800-90 KEM 1024, 1536, 2048, 3072, and N/A, Vendor-affirmed NIST SP 800-56B 4096 bit keys; RSA-KEM- KWS-basic; vendor affirmed; key-wrapping; key establishment methodology provides between 80 and 150 bits of encryption strength OAEP 1024, 1536, 2048, 3072, and N/A, Vendor-affirmed NIST SP 800-56B 4096 bit keys; RSA-OAEP; vendor affirmed; key- wrapping; key establishment methodology provides between 80 and 150 bits of encryption strength PBKDF2 with SHA-1, SHA-256 N/A, Vendor-affirmed NIST SP 800-132 KDF 80-512 bit keys; SHA-1, N/A, Vendor-affirmed NIST SP 800-108 SHA-224, SHA-256, SHA- Key derivation 384, SHA-512, AES- methodology provides CMAC; vendor affirmed; between 80 and 256 bits counter, feedback and of encryption strength. double pipeline modes TLS-PRF Key Derivation N/A, Vendor-affirmed NIST SP 800-135 FFC Diffie-Hellman Key Agreement Primitives; CVL: #21 primitive; 1024, 2048, 3072 bit Key establishment A part of NIST SP modular Diffie-Hellman methodology provides 800-56A groups between 80 and 128 bits of encryption strength. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 13 of 27 Algorithm Implementation Details Algorithm Certificate ECC CDH primitive; Key Agreement Primitives; CVL: #21 A part of NIST SP NIST P-192, P-224, P-256, Key establishment 800-56A P-384 and P-521 curves methodology provides between 80 and 256 bits of encryption strength. The cryptographic module supports the following non-approved algorithms in the approved mode of operation as allowed: Algorithm Algorithm Type Utilization RSA Encryption Key Transport; (RSA Cert. #1061) (PKCS #1 v1.5) 1024, 1536, 2048, 3072, and Key establishment 4096 bit keys methodology provides between 80 and 150 bits of encryption strength. AES Key Wrap Key Wrapping (AES Cert. #2041) 128, 192, 256 bit keys Key establishment methodology provides between 128 and 256 bits of encryption strength MD5 Message Digest; This function is only allowed as a part of an approved key transport scheme (e.g. TLS 1.0 or TLS 1.1). /dev/random Non-Approved RBG The entropy source for NIST SP 800-90 DRBG. The SafeZone FIPS Cryptographic Module is intended for products where FIPS 140- 2 approved algorithms are used. AuthenTec/INSIDE Secure also provides solutions for customers that need software or hardware based implementations for non- approved cryptographic algorithms, such as Camellia and C2. However, to ensure that SafeZone FIPS Cryptographic Module remains the most convenient solution for products required to be FIPS 140-2 approved, it does not implement these algorithms. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 14 of 27 5.2 Cryptographic Keys, CSPs, and SRDIs While operating in a FIPS-compliant manner, the asset store within the SafeZone FIPS Cryptographic Module may contain the following security relevant data items (depending on which keys will be used by the user): Zeroization ID Algorithm Size Description Origin Storage Method General Keys/CSPs AES AES 128, 192, 256 Key created for the Crypto Officer, Plaintext Power-off, Encryption including bits purposes of User in RAM FL_AssetFree, Key modes encrypting and/or FL_LibUnInit ECB, CBC, decrypting data using and CTR AES algorithm AES CCM AES CCM 128, 192, 256 Key created for the Crypto Officer, Plaintext Power-off, Encryption bits purposes of User in RAM FL_AssetFree, Key authenticated FL_LibUnInit encryption and/or decryption of data using AES and CCM algorithms AES GCM AES GCM 128, 192, 256 Key created for the Crypto Officer, Plaintext Power-off, Encryption bits purposes of User in RAM FL_AssetFree, Key authenticated FL_LibUnInit encryption and/or decryption of data using AES and GCM algorithms XTS-AES XTS-AES 256, 512 bits Key created for the Crypto Officer, Plaintext Power-off, Encryption purposes of User in RAM FL_AssetFree, Key encrypting and/or FL_LibUnInit decrypting data using AES algorithm in XTS mode Triple-DES Triple-DES 196 bits Key created for the Crypto Officer, Plaintext Power-off, Encryption purposes of User in RAM FL_AssetFree, Key encrypting and/or FL_LibUnInit decrypting data using Triple-DES algorithm CMAC Key CMAC + 128, 192, 256 Key created for the Crypto Officer, Plaintext Power-off, AES bits purposes of User in RAM FL_AssetFree, generating and FL_LibUnInit verifying CMAC authentication codes CMAC Verify CMAC + 128, 192, 256 Key created for the Crypto Officer, Plaintext Power-off, Key AES bits purpose of verifying User in RAM FL_AssetFree, CMAC authentication FL_LibUnInit codes KDF Key NIST SP 80-512 bits Key created for the Crypto Officer, Plaintext Power-off, Derivation key 800-108 + purpose of deriving User in RAM FL_AssetFree, HMAC or other keys as specified FL_LibUnInit CMAC in NIST SP 800-108. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 15 of 27 Zeroization ID Algorithm Size Description Origin Storage Method TLS-PRF NIST SP 80-512 bits Key created for the Crypto Officer, Plaintext Power-off, Key 800-135 purpose of key User in RAM FL_AssetFree, Derivation Key derivation using FL_LibUnInit TLS1.0 key derivation function presented in NIST SP 800-135. HMAC Key HMAC + 80-512 bits Key created for the Crypto Officer, Plaintext Power-off, SHS purposes of User in RAM FL_AssetFree, generating and FL_LibUnInit verifying HMAC authentication codes HMAC Verify HMAC + 80-512 bits Key created for the Crypto Officer, Plaintext Power-off, Key SHS purpose of verifying User in RAM FL_AssetFree, HMAC authentication FL_LibUnInit codes RSA Signing RSA Private 1024, 1536, Private key for the Crypto Officer, Plaintext Power-off, Key Key (CRT) 2048, 3072, purpose of signing User in RAM FL_AssetFree, 4096 bits data using RSA with FL_LibUnInit (modulus size) PKCS#1v1.5 or PSS padding. DSA Signing DSA Private P=1024/N=160, Private key for the Crypto Officer, Plaintext Power-off, Key Key P=2048/N=224, purpose of signing User in RAM FL_AssetFree, P=2048/N=256, data using DSA FL_LibUnInit P=3072/N=256 algorithm. Includes associated domain parameters. ECDSA ECDSA P-192, Private key for the Crypto Officer, Plaintext Power-off, Signing Key Private Key P-224, purpose of signing User in RAM FL_AssetFree, P-256, data using ECDSA FL_LibUnInit P-384, algorithm P-521 AES Key- AES 128, 192, 256 Key created for the Crypto Officer, Plaintext Power-off, Wrapping Key bits purposes of key User in RAM FL_AssetFree, wrapping and FL_LibUnInit unwrapping using AES Key Wrap algorithm Diffie-Hellman Diffie- P=1024/N=160, Private value for the Crypto Officer, Plaintext Power-off, Private Value Hellman P=2048/N=224, purpose of key User in RAM FL_AssetFree, P=2048/N=256, agreement using FL_LibUnInit P=3072/N=256 Diffie-Hellman algorithm. Includes associated domain parameters. EC Diffie- EC Diffie- P-192, Private value for the Crypto Officer, Plaintext Power-off, Hellman Hellman P-224, purpose of key User in RAM FL_AssetFree, Private Value P-256, agreement using FL_LibUnInit P-384, Elliptic Curve Diffie- P-521 Hellman algorithm. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 16 of 27 Zeroization ID Algorithm Size Description Origin Storage Method KEM RSA Private 1024, 1536, Private key for the Crypto Officer, Plaintext Power-off, Unwrapping Key (CRT) 2048, 3072, purpose of User in RAM FL_AssetFree, Key 4096 bits transporting keys FL_LibUnInit using RSA with KEM as specified in NIST SP 800-56B OAEP RSA Private 1024, 1536, Private key for the Crypto Officer, Plaintext Power-off, Unwrapping Key (CRT) 2048, 3072, purpose of User in RAM FL_AssetFree, Key 4096 bits transporting keys FL_LibUnInit using RSA with OAEP as specified in NIST SP 800-56B RSA RSA Private 1024, 1536, Private key for the Crypto Officer, Plaintext Power-off, Unwrapping Key (CRT) 2048, 3072, purpose of User in RAM FL_AssetFree, Key 4096 bits transporting keys FL_LibUnInit using RSA with PKCS #1 v1.5 padding (also known as RSA Encryption) Trusted Keys Trusted Root NIST SP 256 bits Key used for deriving Crypto Officer Plaintext Power-off, Key 800-108 other keys as per in RAM FL_AssetFree, KDF NIST SP 800-108. FL_LibUnInit Can only derive ‘Trusted KDK’ and ‘Trusted KEKDK’ keys. Trusted KDK NIST SP 256 bits Key used for deriving Crypto Officer, Plaintext Power-off, 800-108 other keys as per User in RAM FL_AssetFree, KDF NIST SP 800-108. FL_LibUnInit Trusted NIST SP 256 bits Key used for Crypto Officer, Plaintext Power-off, KEKDK 800-108 wrapping keys with User in RAM FL_AssetFree, KDF combination of NIST FL_LibUnInit + SP800-108 KDF and AES AES Key Wrap. (Key Wrap) Other CSPs DRBG state: CTR_DRBG 256 bits Key for DRBG used Entropy source Plaintext Power Off, Key 256-bits for random number in RAM FL_LibUnInit with and key/key pair derivation generation purposes. function DRBG state: V CTR_DRBG 128 bits V value for DRBG Entropy source Plaintext Power Off, 256-bits used for random in RAM FL_LibUnInit with number and key/key derivation pair generation function purposes. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 17 of 27 Zeroization ID Algorithm Size Description Origin Storage Method Public Keys Software ECDSA / NIST P-224 Public key used by Embedded in the Plaintext none Integrity Public Verify Power-on Software software in Key Integrity to ensure the persistent integrity of the storage Cryptographic Module. RSA RSA Public 1024, 1536, Public key for the Crypto Officer, Plaintext Power-off, Verification Key 2048, 3072, purpose of verifying User in RAM FL_AssetFree, Key 4096 bits signed data using FL_LibUnInit modulus size RSA with PKCS #1 v1.5 or PSS padding. Not considered sensitive or CSP. DSA DSA Public P=1024/N=160, Public key for the Crypto Officer, Plaintext Power-off, Verification Key P=2048/N=224, purpose of verifying User in RAM FL_AssetFree, Key P=2048/N=256, signed data using FL_LibUnInit P=3072/N=256 DSA algorithm. Includes associated domain parameters. Not considered sensitive or CSP. ECDSA ECDSA P-192, Public key for the Crypto Officer, Plaintext Power-off, Verification Public Key P-224, purpose of verifying User in RAM FL_AssetFree, Key P-256, signed data using FL_LibUnInit P-384, ECDSA algorithm. P-521 Not considered sensitive or CSP. Diffie-Hellman Diffie- P=1024/N=160, Public value for the Crypto Officer, Plaintext Power-off, Public Value Hellman P=2048/N=224, purpose of key User in RAM FL_AssetFree, P=2048/N=256, agreement using the FL_LibUnInit P=3072/N=256 Diffie-Hellman algorithm. Includes associated domain parameters. Not considered sensitive or CSP. EC Diffie- EC Diffie- P-192, Public value for the Crypto Officer, Plaintext Power-off, Hellman Public Hellman P-224, purpose of key User in RAM FL_AssetFree, Value P-256, agreement using the FL_LibUnInit P-384, Elliptic Curve Diffie- P-521 Hellman algorithm. Not considered sensitive or CSP. KEM RSA Public 1024, 1536, Public key for the Crypto Officer, Plaintext Power-off, Wrapping Key Key 2048, 3072, purpose of User in RAM FL_AssetFree, 4096 bits transporting keys FL_LibUnInit using RSA with KEM as specified in NIST SP 800-56B. Not considered sensitive or CSP. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 18 of 27 Zeroization ID Algorithm Size Description Origin Storage Method OAEP RSA Public 1024, 1536, Public key for the Crypto Officer, Plaintext Power-off, Wrapping Key Key 2048, 3072, purpose of User in RAM FL_AssetFree, 4096 bits transporting keys FL_LibUnInit using RSA with OAEP as specified in NIST SP 800-56B. Not considered sensitive or CSP. RSA Wrapping RSA Public 1024, 1536, Public key for the Crypto Officer, Plaintext Power-off, Key Key 2048, 3072, purpose of User in RAM FL_AssetFree, 4096 bits transporting keys FL_LibUnInit using RSA with PKCS #1 v1.5 padding (also known as RSA Encryption). Not considered sensitive or CSP. All the cryptographic keys and other security relevant materials handled by the module can be zeroized by using the cryptographic module, with the exception of the Software Integrity Public Key that is used in the self-test to validate the module. There are three ways to zeroize a key: individual keys can be explicitly zeroized using the FL_AssetFree function call, all keys are zeroized once the module is uninitialized (FL_LibUnInit) or encounters error state, and (as all the keys handled by the module except the Software Integrity Public key are stored in RAM memory), the keys can also be zeroized by turning the power off. The main difference between normal and Trusted Keys is that Trusted Keys do not allow the User role to pick the key material to use, but the keys can only be derived from the trusted root key provided by the Crypto Officer role. The primary use of trusted keys is wrapping and unwrapping other keys for purposes of persistent storage outside the SafeZone FIPS Cryptographic Module. Trusted Keys do not provide any additional security for FIPS purposes. They merely are identifiers for the keys derived from the trusted root key. 5.3 Access Control Policy The module allows controlled access to the SRDIs contained within it. The following table defines the access that an operator or an application has to each SRDI while operating the SafeZone FIPS Cryptographic Module in a given role performing a specific service (command). The permissions are categorized as a set of four separate permissions: read [R] (the SRDI can be read by this operation), write [W] (the SRDI can be written by this operation), execute [X] (the SRDI can be used in this operation), and delete [D] (the SRDI will be zeroized by this operation). If no permission is listed, then an operator outside the SafeZone FIPS Cryptographic Module has no access to the SRDI. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 19 of 27 The operations are presented in the three following tables: for secret keys, private keys, and public keys. The operations which are not appropriate for a specific key type have been omitted. TLS-PRF Key Derivation key Security Relevant Data Item Triple-DES Encryption Key AES GCM Encryption Key AES CCM Encryption Key XTS-AES Encryption Key KDF Key Derivation key AES Key-Wrapping Key SafeZone FIPS Cryptographic Module DRBG state: Key / V AES Encryption Key HMAC Verify Key CMAC Verify Key Trusted Root Key Trusted KEKDK SRDI/Role/Service Access Policy Trusted KDK HMAC Key CMAC Key Secret Keys Role/Service User role or Crypto Officer Role Show Status (FL_LibStatus) DDDDDDD D D DD D DDD D Zeroize (FL_LibUnInit) On-demand self-test (FL_LibSelfTest) Create Key (FL_AssetAllocate, WWWWWWW W W WW W FL_AssetAllocateBasic, FL_AssetLoadValue) WWWWWWW W W WW W Copy Key (FL_AssetCopy) DDDDDDD D D DD D DD Delete Key (FL_AssetFree) Examine Key (FL_AssetShow, FL_AssetCheck) WWWWWWW W W WW W XW Generate Key (FL_AssetLoadRandom) Bulk Encryption/Decryption (FL_CipherInit, X XX FL_CipherContinue, FL_CipherFinish) Authenticated Encryption/Decryption with Associated Data (FL_EncryptAuthInitRandom, FL_EncryptAuthInitDeterministic, FL_CryptAuthInit2, FL_CryptAuthContinue, XX FL_EncryptAuthFinish, FL_EncryptAuthPacketFinish, FL_DecryptAuthFinish) MAC Generation (FL_MacGenerateInit, X X FL_MacGenerateContinue, FL_MacGenerateFinish) MAC Verification (FL_MacVerifyInit, XX XX FL_MacGenerateContinue, FL_MacGenerateFinish) Digest Generation (FL_HashInit, FL_HashContinue, FL_HashFinish, FL_HashFinishKeep, FL_HashSingle) DRBG Random Number Generation XW (FL_RbgGenerateRandom) XW DRBG Reseeding (FL_RbgReseed) W W W W W W W XW W W W W Key Derivation (FL_KeyDeriveKdk) TLS-PRF Key Derivation (FL_KeyDeriveKdk, W W W W W W W W XW W W W FL_DeriveTlsPrf) RRRRRRR R R R R XR AES Key Wrapping (FL_AssetsWrapAes) 2 Function may only be used for AES-CCM encryption, in particular the function shall not be used for AES-GCM encryption. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 20 of 27 TLS-PRF Key Derivation key Security Relevant Data Item Triple-DES Encryption Key AES GCM Encryption Key AES CCM Encryption Key XTS-AES Encryption Key KDF Key Derivation key AES Key-Wrapping Key SafeZone FIPS Cryptographic Module DRBG state: Key / V AES Encryption Key HMAC Verify Key CMAC Verify Key Trusted Root Key Trusted KEKDK SRDI/Role/Service Access Policy Trusted KDK HMAC Key CMAC Key Secret Keys Role/Service WWWWWWW W W W W XW AES Key Unwrapping (FL_AssetsUnwrapAes) Trusted Root Key Derivation X WW (FL_TrustedKdkDerive, FL_TrustedKekdkDerive) Trusted KDK Key Derivation WWWWWWW W W WW W X (FL_TrustedKeyDerive) RRRRRRR R R RR R X Trusted Key Wrapping (FL_AssetWrapTrusted) Trusted Key Unwrapping WWWWWWW W W WW W X (FL_AssetUnwrapTrusted) WWWWWWW W W WW W PBKDF2 Key Derivation (FL_KeyDerivePbkdf2) Crypto-officer Role Entropy Source Installation W (FL_RbgInstallEntropySource) Create Trusted Root Key W (FL_RootKeyAllocateAndLoadValue) EC Diffie-Hellman Private Value Diffie-Hellman Private Value Security Relevant Data Item SafeZone FIPS Cryptographic Module OAEP Unwrapping Key KEM Unwrapping Key RSA Unwrapping Key ECDSA Signing Key DRBG state: Key / V SRDI/Role/Service Access Policy DSA Signing Key RSA Signing Key Private Keys Role/Service User role or Crypto Officer Role Show Status (FL_LibStatus) DDDDDDDD D Zeroize (FL_LibUnInit) On-demand self-test (FL_LibSelfTest) Create Key WWWWWWWW (FL_AssetAllocate, FL_AssetAllocateBasic, FL_AssetLoadValue) WWWWWWWW Copy Key (FL_AssetCopyValue) DDDDDDDD Delete Key (FL_AssetFree) Examine Key (FL_AssetShow, FL_AssetCheck) XW Generate Key (FL_AssetLoadRandom) W W W W W W W W XW Generate Key Pair (FL_AssetGenerateKeyPair) Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 21 of 27 EC Diffie-Hellman Private Value Diffie-Hellman Private Value Security Relevant Data Item SafeZone FIPS Cryptographic Module OAEP Unwrapping Key KEM Unwrapping Key RSA Unwrapping Key ECDSA Signing Key DRBG state: Key / V SRDI/Role/Service Access Policy DSA Signing Key RSA Signing Key Private Keys Role/Service DSA/Diffie-Hellman Domain Parameter and Key Pair Generation W W XW (FL_AssetGenerateKeyPair) X X X XW Signature Generation (FL_HashSignFips186, FL_HashSignPkcs1Pss) R R R R R R R R AES Key Wrapping (FL_AssetsWrapAes) W W W W W W W W AES Key Unwrapping (FL_AssetsUnwrapAes) R R R R R R R R Trusted Key Wrapping (FL_AssetWrapTrusted) W W W W W W W W Trusted Key Unwrapping (FL_AssetUnwrapTrusted) W W W W W W W W PBKDF2 Key Derivation (FL_KeyDerivePbkdf2) X Diffie-Hellman Key Agreement (FL_DeriveDh) X Elliptic Curve Diffie-Hellman Key Agreement (FL_DeriveDh) EC Diffie-Hellman Public Value Software Integrity Public Key Diffie-Hellman Public Value Security Relevant Data Item SafeZone FIPS Cryptographic Module ECDSA Verification Key DSA Verification Key RSA Verification Key OAEP Wrapping Key DRBG state: Key / V KEM Wrapping Key RSA Wrapping Key SRDI/Role/Service Access Policy Public Keys Role/Service User role or Crypto-Officer Role Show Status (FL_LibStatus) D D D D D D D D D Zeroize (FL_LibUnInit) X On-demand self-test (FL_LibSelfTest) Create Key (FL_AssetAllocate, FL_AssetAllocateBasic, W W W W W W W W FL_AssetLoadValue) W W W W W W W W Copy Key (FL_AssetCopyValue) D D D D D D D D Delete Key (FL_AssetFree) RX RX RX RX RX RX RX RX Examine Key (FL_AssetShow, FL_AssetCheck) W W W W W W W W XW Generate Key Pair (FL_AssetGenerateKeyPair) DSA/Diffie-Hellman Domain Parameter and Key Pair W W XW Generation (FL_AssetGenerateKeyPair) X X X X X X X X Public Key Validation (FL_AssetCheck) Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 22 of 27 EC Diffie-Hellman Public Value Software Integrity Public Key Diffie-Hellman Public Value Security Relevant Data Item SafeZone FIPS Cryptographic Module ECDSA Verification Key DSA Verification Key RSA Verification Key OAEP Wrapping Key DRBG state: Key / V KEM Wrapping Key RSA Wrapping Key SRDI/Role/Service Access Policy Public Keys Role/Service DSA/Diffie-Hellman Domain Parameter Verification X X (FL_AssetCheck) Signature Verification X X X (FL_HashVerifyFips186, FL_HashVerifyPkcs1Pss) X Diffie-Hellman Key Agreement (FL_DeriveDh) Elliptic Curve Diffie-Hellman Key Agreement X (FL_DeriveDh) Crypto-officer Role X XW Module Initialization (FL_LibInit) 5.4 Algorithm details Some of the FIPS Publications or NIST Special Publications require that the Cryptographic Module Security Policy mentions important configuration items for those algorithms. 5.4.1 NIST SP 800-108: Key Derivation Functions All three key derivation functions, Counter Mode, Feedback Mode and Double- Pipeline Iteration Mode are supported. 5.4.2 NIST SP 800-132: Password-Based Key Derivation Function The key derived using NIST SP 800-132 shall only be used for storage purposes. Both options presented in NIST SP 800-132 for deriving the Data Protection Key from the Master Key are supported. The SafeZone FIPS Lib does not limit the length of the passphrase used in NIST SP 800-132 PBKDF key derivation. The upper bound for the strength of passwords usually used is between 5 or 6 bits per character. Thus, for security over 64 bits, the passwords must generally be longer than 12 characters. 5.4.3 NIST SP 800-38D: Galois/Counter Mode The FIPS 140-2 Implementation Guidance A.5 applies to AES-GCM usage with this module. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 23 of 27 Item 1 in IG A.5 forbids using the FL_CryptAuthInit function for encryption with AES GCM. The FL_CryptAuthInit function is still used for decryption. The operator must use the FL_EncryptAuthInitRandom function if random IV generation (IG A.5 item 2) is required, or in case of deterministic IV generation (IG A.5 item 3), the FL_EncryptAuthInitDeterministic function. Note: If IV is generated internally in a deterministic manner, then FIPS 140-2 Implementation Guidance A.5: Item B3 applies: In case a module’s power is lost and then restored, the key used for the AES GCM encryption/decryption must be re- distributed. 5.4.4 NIST SP 800-90: Deterministic Random Bit Generator By default, the SafeZone FIPS Cryptographic Module DRBG uses /dev/random as the entropy source on platforms that provide such an entropy device. This entropy generation path is merely a convenience default. The quality of entropy coming from /dev/random is not measured by the SafeZone FIPS Cryptographic Module. If Crypto Officer uses /dev/random as entropy source, it is up to Crypto Officer to configure it suitably to provide reasonable security. Crypto Officer can provide an entropy function which overrides the default entropy source. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 24 of 27 6 Self Tests 6.1 Power-Up Self-Tests The SafeZone FIPS Cryptographic Module includes the following power-up self tests:  Software Integrity Test (using ECDSA Verify with NIST P-224)  KAT test for SHA-1  KAT test for SHA-512  KAT test for HMAC SHA-256  KAT test for AES encryption (CBC, 128-bit key)  KAT test for AES decryption (CBC, 128-bit key)  KAT test for AES encryption (CCM, 128-bit key)  KAT test for AES decryption (CCM, 128-bit key)  KAT test for AES encryption (GCM, 128-bit key)  KAT test for AES decryption (GCM, 128-bit key)  KAT test for AES encryption (XTS, 128-bit key strength)  KAT test for AES decryption (XTS, 128-bit key strength)  KAT test for CMAC, 192-bit key  KAT test for Triple-DES encryption (CBC, 192-bit key)  KAT test for Triple-DES decryption (CBC, 192-bit key)  KAT for RSA 2048-bit (PKCS #1 v1.5)  KAT for DSA (signing P=2048/N=256; verification P=1024/N=160)  KAT for ECDSA Signing (NIST P-224)  KAT for RSA Key Wrapping 2048-bit (RSA-OAEP)  KAT for Diffie-Hellman  KAT for EC Diffie-Hellman  AES-CTR-256 DRBG self-test The self-tests are invoked automatically when the SafeZone FIPS Cryptographic Module is initialized with the FL_LibInit API function. Any error during the power-up self tests will result in a module transition to the error state. There are two possible ways to recover from the error state:  Reinitializing the module with the API function sequences FL_LibUnInit and FL_LibInit.  Power-cycling the device and reinitialize the module with the API function FL_LibInit. The FL_LibStatus API function can be used to obtain the module status. It returns FL_STATUS_INIT when the module has not yet been initialized and FL_STATUS_ERROR when the module is in error state. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 25 of 27 As it is recommended to self-test cryptographic components (like DRBG) frequently, the module provides the capability to invoke the self-tests manually (on demand) with the FL_LibSelfTest API function. The important difference between the manually invoked self-tests and the automatically invoked self-tests when initializing the module is that the manually invoked self-tests will not cause zeroization of the key material currently loaded in the module, providing the tests execute successfully. In general, if a self-test fails, the module will transition to the error state and the return value (status) of the invoked API function will be something other than FLR_OK, depending on the current situation. 6.2 Conditional Self tests The SafeZone FIPS Cryptographic Module contains the following conditional self- tests:  Pair-wise consistency check for key pairs created for digital signature purposes (DSA, FIPS 186-3)  Pair-wise consistency check for key pairs created for digital signature purposes (RSA, FIPS 186-3)  Pair-wise consistency check for key pairs created for digital signature purposes (ECDSA, FIPS 186-3)  Continuous random number generator test.  Continuous random number generator test for non-Approved RBG /dev/random. The conditional self-tests for manual key entry and software/firmware load or bypass are not provided, as these are not applicable. Any error during the conditional self tests will result in a module transition to the error state. The ways to recover from the error state are listed in section 6.1. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 26 of 27 7 Mitigation of Other Attacks The module does not mitigate against any specific attacks outside the scope of FIPS 140-2. Non-proprietary security policy. This document may be freely distributed in its entirety without modification. Page 27 of 27