Network Security Services (NSS) Cryptographic Module Version

Transcription

1 Network Security Services () Cryptographic Module Version FIPS Security Policy Level 1 Validation Wind River Systems, Inc. Version 1.2 Last Update:

2 Table of Contents 1 Introduction Purpose Audience Reference Cryptographic Module Specification (140-2 Section 4.1) Description of Module Platform List Modes of Operation Description of FIPS Approved Mode Non-NIST Recommended Elliptic Curve Cryptographic Module Boundary Physical Cryptographic Boundary Logical Cryptographic Boundary Cryptographic Module Ports and Interfaces (140-2 Section 4.2) Physical Interface Logical Interfaces PKCS #11 (Cryptoki) API Data Output during Self test Roles, Services, and Authentication (140-2 Section 4.3) Roles Specification of Maintenance Role Services Approved Services Operator Authentication Role-Based Authentication Clearing of Previous Authentications on Power Off Protection of Authentication Data Initialization of Authentication Mechanism Change of Authentication Data Strength of Authentication Mechanism Concurrent Operators Access Control Policy Cryptographic Keys and CSPs Finite State Model Physical Security (140-2 Section 4.5) Operational Environment (140-2 Section 4.6) Applicability... 32

3 8.2 Solution Single Operator mode of Operation Configuration of Discretionary Access Control Software Integrity Test Cryptographic Key Management (140-2 Section 4.7) Key/CSP Storage Key and CSP List Key/CSP Generation Key/CSP Establishment Key/CSP Entry and Output Key/CSP Zeroization Random Number Generation Self-Tests (140-2 Section 4.9) Power-Up Tests (140-2 Section 4.9.1) Cryptographic Algorithm Test Software/Firmware Integrity Test Conditional Tests (140-2 Section 4.9.2) Continuous Random Number Generator Test Pair-wise Consistency Test Critical Function Test Design Assurance (140-2 Section 4.10) Configuration management Delivery and Operation Security Rules Development Guidance Documents Mitigation of Other Attacks Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) Sample Cryptographic Module Initialization Code... 41

4 List of Tables Table 1 Security Level... 8 Table 2 Platforms... 8 Table 3 FIPS approved cryptographic algorithms with certificate numbers... 9 Table 4 Non-approved cryptographic functions Table 5 Asymmetric Establishment techniques allowed in a FIPS approved mode Table 6 Non-NIST Recommended Curves Table 7 Roles Table 8 Approved Services Table 9 States Table 10 Transitions Table 11 Key Storage Table 12 Cryptographic Algorithm Tests (ref: fipstest.c, PKCS #11 FIPS Power-Up Self Test). 35 Table 13 Mitigation of Attacks...39 Wind River Systems Inc. Version 1.2 Page 4 of 43

5 Revision history Version Change date Author(s) Changes to previous version atsec First version atsec Addressed CMVP comments atsec Addressed CMVP comments Wind River Systems Inc. Version 1.2 Page 5 of 43

6 1 Introduction This document is the nonproprietary FIPS security policy for the Cryptographic Module to meet FIPS level 1 requirements. This Security Policy details the secure operation of the Cryptographic Library as required in Federal information Processing Standards Publication (FIPS 140-2) as published by the National Institute of Standards and Technology (NIST) of the United States Department of Commerce. 1.1 Purpose This security policy describes the services provided by the Library cryptographic module. It provides precise specification of cryptographic security, the cryptographic module user (organization or individual operator), and the capabilities, protections, and access rights they will have when using the cryptographic module. This document also provides information about the delivery of the module and the steps required to bring it in an Approved mode of operation. 1.2 Audience This document is required as a part of the FIPS validation process. It describes the Cryptographic Module in relation to FIPS It is intended for security officers, developers, system administrators, and end-users. 1.3 Reference The software module this security policy describes is a port to new platforms of the module previously certified as # The Network Security Services () Cryptographic Module (Extend ECC) Version , FIPS Non- Proprietary Security Policy (validation number 1279) developed by Sun Microsystems Inc, Red Hat Inc and Mozilla Foundation Inc. The following prior module specification documentation and publications are also relevant to this module: [CMFP] C. Percival, "Cache Missing for Fun and Profit," [FIPS_140] Federal Information Processing Standards Publication, FIPS PUB Security Requirements for Cryptographic Modules, [FIPS_CKM] Mozila wiki, Section 7: Cryptographic Key Management [FIPS_OE] Mozilla wiki, FIPS Operational Environment [FIPS_FSM] Mozilla wiki, Section 4: finite Sate Model [FIPS_MS] Mozilla wiki, FIPS Module Specification [FIPS_PUST] Mozilla wiki, Power-Up Self-Tests [FIPS_RS] Mozilla wiki, FIPS Roles and Services [IG] NIST, Implementation Guidance for FIPS PUB and the Cryptographic Module Validation Program, [_CM3.12.4] Source code of Cryptographic Module provided by Wind River Systems Inc. [PKCS11] RSA Laboratories, PKCS #11 v2.20: Cryptographic Token Interface Standard, ( [PCCRS] N. Ferguson and B. Schneier, Practical Cryptography, Sec "Checking RSA Signatures", p. 286, Wiley Publishing, Inc., [RTAP] D. Boneh and D. Brumley, "Remote Timing Attacks are Practical," [SP_1279] Sun Microsystems Inc, Red Hat Inc, Mozilla Foundation Inc, Network Security Services () Cryptographic Module (Extend ECC) Version , FIPS Non-Proprietary Security Policy Level 2 Validation, Wind River Systems Inc. Version 1.2 Page 6 of 43

7 [SP800-57P1] NIST Special Publication , Recommendation for Key Management Part 1: General (Revised), March 2007 [TAIDHRD] P. Kocher, "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems," CRYPTO '96, Lecture Notes In Computer Science, Vol. 1109, pp , Springer- Verlag, ( Wind River Systems Inc. Version 1.2 Page 7 of 43

8 2 Cryptographic Module Specification (140-2 Section 4.1) The following sections describe the cryptographic module specifications. 2.1 Description of Module The cryptographic module is an open-source, software only, general-purpose cryptographic library available for free under the Mozilla Public License, the GNU General Public License, and the GNU Lesser General Public License. The cryptographic module consists of APIs based on the industry standard PKCS #11 version 2.20 [PKCS11]. The following table shows the overview of the security level for each of the eleven sections of validation. Table 1 Security Level Security Component Security Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles, Services and Authentication 2 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 Platform List The cryptographic module has been tested on the following configuration: Wind River Linux Secure 1.0 The module has been tested on the following platforms: Table 2 Platforms Model Operating System and Version x86_64 Nehalem Xeon 5500 Wind River Linux Secure 1.0 x86_64 Pentium core2 duo Wind River Linux Secure Modes of Operation The cryptographic module operates in two modes of operations: a FIPS approved mode and a non-fips approved mode. If the cryptographic module is initialized by calling the standard PKCS #11 function C_GetFunctionList and the API functions are called via the function pointers in that list, then the application selects the non-fips approved mode by default. In non-fips mode, the non-approved API function NSC_Initilize initializes the PKCS #11 library and NSC_Finalize indicates that an application is done with the PKCS #11 library. Wind River Systems Inc. Version 1.2 Page 8 of 43

9 In order to operate in the FIPS approved mode, the application must follow the security rules listed in Section and initialize the module properly. The application must call the API functions via an alternative set of function pointers - see Section for details. 2.4 Description of FIPS Approved Mode In the FIPS approved mode, the module will support the following FIPS approved security function: Table 3 FIPS approved cryptographic algorithms with certificate numbers Cryptographic Algorithm Validation Certificate# Usage Keys/CSPs Triple-DES (SP , Appendix E OF SP A) AES (FIPS 197, SP A) DSA (FIPS with Change Notice 1) RSA (PKCS#1 v2.1) ECDSA (FIPS with Change Notice 1) SHS (FIPS 180-3) HMAC (FIPS 198) 949 TECB(e/d; KO 1,2); TCBC(e/d; KO 1,2) 1374 ECB(e/d; 128,192,256); CBC(e/d; 128,192,256) 450 PQG(gen) MOD(1024); PQG(ver) MOD(1024); KEYGEN(Y) MOD(1024); SIG(gen) MOD(1024); SIG(ver) MOD(1024); 673 ALG[RSASSA-PKCS1_V1_5]; SIG(gen); SIG(ver); 1024, 1536, 2048, 3072, 4096, SHS: SHA- 1, SHA-256, SHA-384, SHA PKG: CURVES( P-256 P-384 P- 521 ) PKV: CURVES( P-256 P-384 P- 521 ) SIG(gen): CURVES( P-256 P-384 P-521 ) SIG(ver): CURVES( P-256 P-384 P-521 ) 1256 SHA-1 (BYTE-only) SHA-256 (BYTE-only) SHA-384 (BYTE-only) SHA-512 (BYTE-only) 807 HMAC-SHA1 (Key Sizes Ranges Tested: KS<BS KS=BS KS>BS ) HMAC-SHA256 ( Key Size Ranges Tested: KS<BS KS=BS KS>BS ) HMAC-SHA348 ( Key Size Ranges Tested: KS<BS KS=BS Secret Key Secret Key Private and public key Private and public key Private and public key N/A Secret key Wind River Systems Inc. Version 1.2 Page 9 of 43

10 KS>BS ) HMAC-SHA512 ( Key Size Ranges Tested: KS<BS KS=BS KS>BS ) DRBG (NIST SP ) 49 [Hash_DRBG: SHA-256] Seed The module will support the following non-approved cryptographic functions: Table 4 Non-approved cryptographic functions Algorithm Validation Certificate Usage Keys/CSPs MD5 N/A Hashing N/A MD2 N/A Hashing N/A RC2 N/A Encryption and Decryption Symmetric key RSA N/A Encryption and Decryption for key wrapping Asymmetric keys RC4 N/A Encryption and Decryption Symmetric key DES N/A Encryption and Decryption Symmetric key SEED N/A Encryption and Decryption Symmetric key CAMELLIA N/A Encryption and Decryption Symmetric key ECDSA N/A ANSI X binary, SEC 2 prime, SEC 2 binary curves - see Section for a complete list of the non-nist approved curves Asymmetric keys Warning: s should not use these non-approved cryptographic functions in the FIPS approved mode of operation. The cryptographic module uses the following key establishment techniques in the FIPS approved mode of operation: Table 5 Asymmetric Establishment techniques allowed in a FIPS approved mode Algorithm Key size Strength of mechanism/ algorithm [bits of security] Diffie-Hellman (key agreement) public key of sizes bits see caveat below ECDH (key agreement) elliptic curve key sizes of bits see caveat below RSA (PKCS #1, key wrapping) RSA key sizes of bits see caveat below Note: Refer to Section of [SP800-57P1] for information regarding the strengths of security of the asymmetric key establishment techniques. CAVEATS: Wind River Systems Inc. Version 1.2 Page 10 of 43

11 Since the cryptographic module allows a key establishment method to establish a cryptographic key that is stronger than the key establishment method, the following warnings are required by Section 7.5 of the implementation guidelines of [IG]: Diffie-Hellman (key agreement, key establishment methodology provides between 80 bits and 112 bits of encryption strength) ECDH (key agreement, key establishment methodology provides between 80 bits and 256 bits of encryption strength) RSA (PKCS #1, key wrapping, key establishment methodology provides between 80 bits and 192 bits of encryption strength) MD5 for use in TLS only Non-NIST Recommended Elliptic Curve The Extend ECC version of cryptographic module implements the NIST recommended as well as non-nist recommended curves. Table 6 Non-NIST Recommended Curves Curve Family ANSI X binary curves SEC 2 prime curves SEC 2 binary curves Curve Name c2pnb163v1, c2pnb163v2, c2pnb163v3, c2tnb191v1, c2tnb191v2, c2tnb191v3, c2tnb239v1, c2tnb239v2, c2tnb239v3,c2tnb359v1, and c2tnb431r1 secp160k1, secp160r1, secp160r2, secp192k1, secp224k1, and secp256k1 sect163r1, sect193r1, sect193r2, and sect239k1 Although Section 1.6 of FIPS Implementation Guidance permits the use of non-nist recommended curves in the FIPS-Approved mode, we recommend that these curves should not be used in the FIPS approved mode of operation. The following table lists non-nist recommended curves implemented by the Extend ECC version of the cryptographic module, which are not to be used in the FIPS approved mode. 2.5 Cryptographic Module Boundary The physical module boundary is a surface of the case of the platform. The logical module boundary is depicted in the software block diagram. Wind River Systems Inc. Version 1.2 Page 11 of 43

12 2.5.1 Physical Cryptographic Boundary (1,2,3,4) (2,4) (1,2,3,4) (1,2,4) (1,2) (2,4) (3) (3) Figure 1 Physical Cryptographic boundary diagram For figure 1, the labels 1, 2, 3, and 4 correspond to Data In, Data Out, Control In, and Status Out dataflows, respectively. Wind River Systems Inc. Version 1.2 Page 12 of 43

13 2.5.2 Logical Cryptographic Boundary Figure 2 Logical Cryptographic boundary diagram The arrows in Figure 2 depict the flow of information throughout the module. Since the interfaces between the module and the external operating environment, and the interfaces between the internal components of the module are all programmatic interfaces, the control, data, and status inputs and outputs flow closely in parallel. This is the case since each function implemented in the module has input and output parameters that pass control, data, and status information through the API interfaces. Wind River Systems Inc. Version 1.2 Page 13 of 43

14 The cryptographic module requires the Netscape Portable Runtime (NSPR) libraries. NSPR provides a cross-platform API for non-gui operating system facilities, such as threads, thread synchronization, normal file and network I/O, interval timing and calendar time, atomic operations, and shared library linking. NSPR also provides utility functions for strings, hash tables, and memory pools. NSPR consists of the following shared libraries/dlls: libplc4.so libplds4.so libnspr4.so NSPR is outside the cryptographic boundary because none of the NSPR functions are securityrelevant. Wind River Systems Inc. Version 1.2 Page 14 of 43

15 3 Cryptographic Module Ports and Interfaces (140-2 Section 4.2) The Cryptographic module is a software implementation only. This means it does not include any hardware or firmware components. All the input to the module is processed via function arguments. All the output is returned to the caller either as return codes or as updated memory objects pointed to by some of the arguments. 3.1 Physical Interface The physical interfaces of the cryptographic module are the physical ports, physical covers, doors or openings, manual controls, and physical status indicators of the general purpose computer it runs on. 3.2 Logical Interfaces The logical interfaces use library functions which exchange the encrypted data, keys, and all control information through calls. The module uses different input and output function arguments to differentiate between data input, data output, control input and status output. Similarly, it uses different buffers for input and output data. The module performs zeroization of the input buffer that contains security related information. The cryptographic module includes the following logical interfaces: Data input interface: Password, cryptographic keys (encrypted or plaintext), initialization vectors, plaintext data, cipher text, and signed data supplied to and processed by a cryptographic module is via function input argument. Data output interface: Cryptographic keys (encrypted or plaintext), initialization vectors, plaintext data, cipher text, and digital signatures received via function output argument from the module. Control input interface: The control interfaces consist of control data such as algorithms, module settings, commands specified by input arguments, and function calls to control the operation of the module. Status output interface: This interface indicates the status of the module such as function return codes, error codes, or output arguments PKCS #11 (Cryptoki) API PKCS# 11 (Cryptoki) API is one of the logical interfaces of the cryptographic module that provides access to the module. The module has three PKCS # 11 tokens. The FIPS PKCS # 11 token allows applications using the cryptographic module to operate in a strictly FIPS mode. Functions of FIPS PKCS# 11 API are listed in Table 8. The other two tokens implement the non-fips approved mode of operation. Data Output in Error State All data via the data output interface is restricted when the cryptographic module is in the error state. The error state is tracked by the Boolean state variable sftk_fatalerror. All the PKCS # 11 function that output data via the data output interface use this state variable and, if it is true, return the CKR_DEVICE_ERROR error code. In the error state, the functions which are responsible for restart, shutdown, and re-initialization of the module or output status information can be invoked. These functions are as follows: FC_GetFunctionList FC_Initilize FC_Finalize FC_GetSlotList Wind River Systems Inc. Version 1.2 Page 15 of 43

16 FC_GetSlotInfo FC_GetTokenInfo FC_InitToken FC_CloseSession FC_CloseAllSessions FC_WaitForSlotEvent FC_GetInfo Descriptions of above listed functions are provided in Table Data Output during Self test All data via the data output interface is suppressed when FC_Initialize function of the cryptographic module is performing self-tests. Wind River Systems Inc. Version 1.2 Page 16 of 43

17 4 Roles, Services, and Authentication (140-2 Section 4.3) The following sections describe the authorized roles, services associated with the module and the authentication policy. 4.1 Roles The cryptographic module supports the two authorized roles for operators i.e. user and a Crypto Officer. This security policy introduces a new implicit role called Everyone and it is responsible for all the public services specified in Section Please note that this role is not defined in [FIPS-RS]. Table 7 Roles Role Responsibilities and Services (see list provided in Section 4.2) Crypto Officer Everyone (not an authorized role for operators) Utilizes secure services Provides access to all cryptographic and general- purpose services (except installation of module) Provides access to all keys stored in the private key database Retrieval, updating, and deletion of keys from the private key database Installation of module Control the access before and after the installation Management of physical access to the computer, execution of cryptographic module code Management of security facilities provided by the operating system Responsible for Public Services such as module initialization Random number generation Parallel function management The cryptographic module uses a role-based approach for accessing services by authenticating to the module, an operator assumes a role and gains access to the services accessible by that role. Please refer to section 4.4 for information on role-based operator authentication. 4.2 Specification of Maintenance Role The cryptographic module does not have a maintenance role. Hence, this section is not applicable. 4.3 Services The following section describes the approved services with respect to the applicable FIPS requirements Approved Services The Cryptographic module consists of the following types of services: Public Services: The public services do not require user authentication and/or access to CSPs. Message digesting services are public only when CSPs are not accessed. These services are mapped to the role Everyone. Private Services: The private services require user authentication as these services access CSPs (for example, FC_GenerateKey, FC_GenerateKeyPair) Wind River Systems Inc. Version 1.2 Page 17 of 43

18 See Table 8 for specification of the services. It contains each service as an API function, associated role, service type, and type of access to the cryptographic keys and Critical Security Parameters (CSPs). CSPs contain security related information (for example secret and private cryptographic keys, and authentication data such as passwords and PINs) whose disclosure or modification can compromise the security of cryptographic module. The access types are denoted as follows: R stands for Read W stands for Write Z stands for Zeroize Service Category FIPS specific Module Initialization General Purpose Slot and Token Management Table 8 Approved Services Role Function Name Description CSPs Access type Everyone FC_GetFunctionList Everyone FC_InitToken Crypto Officer FC_InitPIN Everyone FC_Initialize Everyone FC_Finalize Everyone FC_GetInfo Everyone FC_GetSlotList Everyone FC_GetSlotInfo Everyone FC_GetTokenInfo Everyone FC_WaitForSlotEvent In FIPS approved none - mode, it returns the list of function pointers Initializes or password and reinitializes a token all keys Initializes the user's password password (sets the user's initial password) Initializes the module library for the FIPS Approved mode of operation. This function provides the powerup self-test service. none - Finalizes (shuts down) the module library Obtains general information about the module library Obtains a list of slots in the system all keys none - none - Obtains information none - about a particular slot Obtains information none - about the token. This function provides the Show Status service. This function is not supported by the cryptographic module. Z W Z none - Wind River Systems Inc. Version 1.2 Page 18 of 43

19 Service Category Session Management Object Management Role Function Name Description CSPs Access type Everyone FC_GetMechanismList Everyone FC_GetMechanismInfo FC_SetPIN Everyone FC_OpenSession Obtains a list of mechanisms (cryptographic algorithms) supported by a token none - Obtains information none - about a particular mechanism Changes the user's password password Opens a connection none - (session) between an application and a particular token FC_CloseSession Closes a session keys of the session Everyone FC_CloseAllSessions Everyone FC_GetSessionInfo closes all sessions with a token Everyone FC_GetOperationState Saves the state of the cryptographic operation in a session. This function is only implemented for message digest operations. Everyone FC_SetOperationState Restores the state of the cryptographic operation in a session. This function is only implemented for message digest operations. all keys Obtains information none - about the session. This function provides the Show Status service. none - none - Everyone FC_Login Logs into a token password R FC_Logout Logs out from a none - token FC_CreateObject Creates an object original key R FC_CopyObject Creates a copy of new key W an object FC_DestroyObject Destroys an object key Z RW Z Z Wind River Systems Inc. Version 1.2 Page 19 of 43

20 Service Category Encryption and Decryption Message Digesting Role Function Name Description CSPs Access type FC_GetObjectSize Obtains the size of an object in bytes FC_GetAttributeValue Obtains an attribute value of an object FC_SetAttributeValue Modifies an attribute value of an object FC_FindObjectsInit FC_FindObjects FC_FindObjectsFinal FC_EncryptInit FC_Encrypt FC_EncryptUpdate FC_EncryptFinal FC_DecryptInit FC_Decrypt FC_DecryptUpdate FC_DecryptFinal Everyone FC_DigestInit Everyone FC_Digest Everyone FC_DigestUpdate Initializes an object search operation key key key none - Continues an object keys matching search operation the search criteria Finishes an object search operation Initializes an encryption operation none - encryption key Encrypts single-part encryption key data Continues a multiple part encryption operation Finishes a multiple part encryption operation Initializes a decryption operation encryption key encryption key encryption key Decrypts singlepart encrypted encryption key data Continues a multiple part decryption operation Finishes a multiple part decryption operation Initializes a message digesting operation Digests single-part data FC_DigestKey Continues a multipart message encryption key encryption key none - none - Continues a none - multiple part digesting operation key R R W R R R R R R R R R R Wind River Systems Inc. Version 1.2 Page 20 of 43

21 Service Category Signature and Verification Key Management Role Function Name Description CSPs Access type (see the note at the end of the table) Everyone FC_DigestFinal FC_SignInit FC_Sign FC_SignUpdate FC_SignFinal FC_SignRecoverInit FC_SignRecover FC_VerifyInit FC_Verify FC_VerifyUpdate FC_VerifyFinal FC_VerifyRecover FC_GenerateKey digesting operation by digesting the value of a secret key as part of the data already digested Finishes a multiple part digesting operation none - Initializes a signing/hmac keyr signature operation Signs single-part data signing/hmac keyr Continues a signing/hmac keyr multiple part signature operation Finishes a multiple part signature operation signing/hmac keyr Initializes a RSA signing key R signature operation, where the data can be recovered from the signature Signs single-part RSA signing key R data, where the data can be recovered from the signature Initializes a verification operation Verifies a signature on single-part data Continues a multiple part verification operation Finishes a multiple part verification operation Verification/HMAC R key verification/hmac R key verification/hmac R key RSA verification key Verifies a signature RSA verification on single-part data, key where the data is recovered from the signature Generates a secret key key (used by TLS to generate premaster R R W Wind River Systems Inc. Version 1.2 Page 21 of 43

22 Service Category Dual-function cryptographic operations Random Number Generation Parallel Function Management Role Function Name Description CSPs Access type FC_GenerateKeyPair FC_WrapKey FC_UnwrapKey FC_DeriveKey secrets) Generates a public/private key pair. This function performs the pair wise consistency tests. Wraps (encrypts) a key Unwraps (decrypts) a key Derives a key from a base key (used by TLS to derive keys from the master secret) key pair wrapping key key to be wrapped W R R Unwrapping key R Unwrapping key W base key derived key FC_DigestEncryptUpdateContinues a multiple part digesting and encryption operation encryption key R FC_DecryptDigestUpdateContinues a decryption key R multiple part decryption and digesting operation FC_SignEncryptUpdate Continues a signing/hamc keyr multiple part signing and encryption key R encryption operation FC_DecryptVerifyUpdateContinues a decryption key R multiple part decryption and verification/ verify operation HMAC key R Everyone FC_SeedRandom Everyone FC_GenerateRandom Mixes in additional mixed-in seed seed material to the random number generator FC_GetFunctionStatus A legacy function, which simply returns the value 0x (function not Generates random initial seed, data. This function random values performs the for key material continuous random number generator test. R W none - RW RW Wind River Systems Inc. Version 1.2 Page 22 of 43

23 Service Category Role Function Name Description CSPs Access type FC_CancelFunction parallel) A legacy function, which simply returns the value 0x (function not parallel) none - Note: The message digesting functions (except FC_DigestKey) don't require the user to assume an authorized role because they do not use any keys. FC_DigestKey computes the message digest (hash) of the value of a secret key; therefore the user needs to assume the role for this service. 4.4 Operator Authentication The following sections describe the authentication policy of the Cryptographic module Role-Based Authentication The cryptographic module uses role-based authentication to control access to the module. To perform sensitive services using cryptographic module, the user must log into the module and perform authentication procedure using a password. This password is used to encrypt and decrypt private key of the user. However, a discretionary access control is used to protect all other information (for example, the public key certificate database). See Section for details regarding the discretionary access control. Note: For Security Level 1, a cryptographic module is not required to employ authentication mechanisms to control access to the module Clearing of Previous Authentications on Power Off When the process accessing the cryptographic module terminates or the general purpose computer is powered off, the result of authentications in the memory are automatically cleared Protection of Authentication Data The cryptographic module stores a verifier for the user s password in the key database. The module verifies the password by deriving a Triple-DES key from the password, using an extension of the PKCS #5 PBKDF1 key derivation function with an 16-octet salt, an iteration count of 1, and SHA-1 as the underlying hash function, decrypting the stored encrypted password checkstring with the Triple-DES key, and comparing the decrypted string with the known password check-string. It is computationally infeasible to acquire a password from the verifier. This mechanism protects against unauthorized disclosure and modification of the user s password Initialization of Authentication Mechanism The operator implicitly assumes a Crypto Officer role when installing the cryptographic module library files. Once the library files are installed, the Crypto Officer calls the function FC_InitPIN to set the operator's initial password. Please note that it is not necessary to call FC_InitToken to initialize the cryptographic module. The cryptographic module is initialized automatically when FC_Initialize is called for the first time. The Crypto Officer may call FC_InitToken to re-initialize the cryptographic module. When the cryptographic module is accessed for the first time, it does not use a factory-set or default password to authenticate the operator. Hence, login mechanism of the general purpose computer is used to control access to the module before it is initialized. If the general purpose computer is not protected with a system login password, procedural controls or physical access control must be used to control access to the computer before the module is initialized. Wind River Systems Inc. Version 1.2 Page 23 of 43

24 4.4.5 Change of Authentication Data A Function FC_SetPIN is called with both the old password and new password as arguments to change the password by the user Strength of Authentication Mechanism The cryptographic module enforces the following requirements on password change or initialization in the FIPS approved mode: The password must be seven characters long The password must contain characters from three or more character classes. There are five characters classes: digits (0-9), ASCII lowercase letters, ASCII uppercase letters, ASCII nonalphanumeric characters (such as space and punctuation marks), and non-ascii characters. Note: If the first character of the password is an ASCII uppercase, or the last character of the password is a digit, then neither the uppercase letter nor the digit is counted towards its character class. Probability of guessing the correct password randomly Assumptions: The password is at least seven characters long and the characters of the password are independent with each other. The probability of guessing an individual character of the password is less than 1/10. The probability of a successful password guess is less than (1/10) ^ 7= 1/10,000,000. In the FIPS approved mode, after each failed authentication attempt, the cryptographic module introduces a one-second delay before returning to the caller. This mechanism allows at most 60 authentication attempts during a one minute period. Therefore, the probability of a successful password guess is less than 0.6* (1/100,000) Concurrent Operators The cryptographic module does not allow concurrent operators. Please note that on a multiuser operating system; this rule is enforced by making the certificate and private key databases readable and writable to the owner of the files only. Wind River Systems Inc. Version 1.2 Page 24 of 43

25 5 Access Control Policy This section identifies CSPs and cryptographic keys that the user has access to while performing a service and the type of access the user has to the CSPs. 5.1 Cryptographic Keys and CSPs In the FIPS- Approved mode, the cryptographic module employs the following cryptographic keys and CSPs: AES secret keys (128-bit, 192-bit and 256-bit) may be stored in the memory or private database (key3.db, key4.db) Triple-DES secret keys (168-bit) may be stored in the memory or private database (key3.db, key4.db) DSA public and private keys (1024-bit) may be stored in the memory or private database (key3.db, key4.db) Diffie-Hellman public and private keys ( bit) may be stored in the memory or private database (key3.db, key4.db) RSA public and private keys ( bit) may be stored in the memory or private database (key3.db, key4.db) EC public and private keys (160 bits or higher) may be stored in the memory or private database (key3.db, key4.db) HMAC keys (size must be greater than or equal to half the size of hash function output) may be stored in the memory or private database (key3.db, key4.db) Hash_DRBG (SHA 256): Hash DRBG entropy bit value externally-obtained for module DRBG; stored in plaintext in volatile memory. Hash DRBG V value - Internal Hash DRBG state value; stored in plaintext in volatile memory. Hash DRBG C value - Internal Hash DRBG state value; stored in plaintext in volatile memory TLS pre-master secret used in deriving the TLS master secret (48 byte) and TLS master secret shared between the peers in TLS connections, used in the generation of symmetric cipher keys, IVs, and MAC secrets for TLS (48 byte) may be stored in the memory Authentication data (passwords) may be stored in the private key database (key3.db, key4.db) The module stores all cryptographic keys, CSPs, and plaintext data in the database. The module permits only the owner of the files to read and modify the database with proper authentication. Note: The private key database (key3.db, key4.db) mentioned above are outside the cryptographic boundary. Also, the module does not implement the TLS protocol. Rather, it implements the cryptographic mechanism, such as the TLS-specific key generation and derivation operations, which can be used to implement the TLS protocol. Wind River Systems Inc. Version 1.2 Page 25 of 43

26 6 Finite State Model The state transition diagram of cryptographic module is shown below: Figure 6.1 State transition diagram of cryptographic module In the FIPS-Approved mode, when the application calls the FC_Initialize function of the cryptographic module, the state changes and power up self tests are performed. If the self-test is successful, the module is considered to be initialized and enters an operational state of the FIPS approved mode. Please refer to Section 10 for a description of power up self test. If the module enters an error state, then in order to recover from the error state, it needs to shutdown (transition 3.0) and re-initialized (transition 1.1). If the data and control inputs are valid and the module performs the service successfully, the module outputs the requested data or status information and returns CKR_OK. If the data and control inputs are invalid or the module encounters an error (for example, running out of memory) when performing a service, the module does not output any data and simply returns an Wind River Systems Inc. Version 1.2 Page 26 of 43

27 appropriate error code (for example, CKR_HOST_MEMORY, CKR_TOKEN_WRITE_PROTECTED, CKR_TEMPLATE_INCOMPLETE, or CKR_ATTRIBUTE_VALUE_INVALID). The following table shows various states of cryptographic module: Wind River Systems Inc. Version 1.2 Page 27 of 43

28 Table 9 States State Label State Mnemonic State Descriptor 1.X Power Off Host computer is powered off. The initial state 1.A Inactive Host computer is up and running. Distinct Indicator Host computer's power light is off. Host computer's power light is on. 1.B Power up Self test cryptographic module library initialization for the FIPS approved mode has been initiated. This state performs library initialization, software integrity test, and power-up self-tests. The FC_Initialize call is executing. 1.C Public Services cryptographic module library has been initialized for the FIPS approved mode and its self-tests have passed. Services that do not require logging in to the module are available. Public services can be invoked. Private services fail with the error code CKR_USER_NOT_LOGGED_IN. 2 Services Operator has successfully logged in to assume the role and has access to all the services provided by the FIPS approved mode of the cryptographic module. All services can be invoked. 3 Error The FIPS approved mode of the cryptographic module either has failed a conditional test while performing a service or has failed a power-up or operatorinitiated self-test. No further cryptographic operations will be performed. Only FC_Finalize, FC_InitToken, FC_CloseSession, FC_CloseAllSessions, FC_WaitForSlotEvent, and the "get info" functions (FC_GetFunctionList, FC_GetInfo, FC_GetSlotList, FC_GetSlotInfo, and FC_GetTokenInfo) can be invoked. FC_Initialize fails with the error code CKR_CRYPTOKI_ALREADY_INITIALIZED. All other functions fail with the error code CKR_DEVICE_ERROR. 5.B Non- FIPS mode The non-fips approved mode of the cryptographic module has been activated. This is a composite state whose sub-states are not relevant to FIPS NSC_Initialize has been called successfully. All other NSC_xxx functions may be called. Wind River Systems Inc. Version 1.2 Page 28 of 43

29 Transition# Current State Next State Table 10 Transitions Input Event 1.0 Power Off Inactive Host computer is powered up 1.1 Inactive Power Up Self Test 1.2 Power Up Self Test 1.3 Power Up Self Test 1.4 Public Services 1.5 Public Services 1.6 Public Services 1.7 Public Services 2.1 Service 2.5 Service 2.6 Service Public Services Error Error Services Public Services FC_Initialize called Successful library initialization, software integrity test, and powerup self-tests Software integrity test or power-up self-test failure Conditional self-test (continuous random number generator test) failed while performing a service (random number generation) login succeeded login failed Output Event None Opens the databases. Powerup self-tests initiated. FC_Initialize sets the internal Boolean state variable sftk_fatalerror to false and returns CKR_OK FC_Initialize sets the internal Boolean state variable sftk_fatalerror to true and returns CKR_DEVICE_ERROR The function (FC_SeedRandom or FC_GenerateRandom) sets the internal Boolean state variable sftk_fatalerror to true and returns CKR_DEVICE_ERROR FC_Login sets the internal Boolean state variable isloggedin to true and returns CKR_OK FC_Login returns a nonzero error code (for example, CKR_PIN_INCORRECT) Inactive FC_Finalize called FC_Finalize returns CKR_OK Public Services logout requested FC_Logout sets the internal Boolean state variable isloggedin to false and returns CKR_OK Inactive FC_Finalize called FC_Finalize returns CKR_OK Error Conditional self-test (continuous random number generator test or pair-wise consistency test) failed while performing a service (random number generation or key pair generation) The function (FC_SeedRandom, FC_GenerateRandom, or FC_GenerateKeyPair) sets the internal Boolean state variable sftk_fatalerror to true and returns CKR_DEVICE_ERROR or CKR_GENERAL_ERROR 3.0 Error Inactive FC_Finalize called FC_Finalize returns CKR_OK 4.0 Any State other than Power Off Power Off Host computer is powered off None Wind River Systems Inc. Version 1.2 Page 29 of 43

30 Transition# Current State Next State 5.1 Inactive Non-FIPS mode 5.2 Non-FIPS mode Input Event NSC_Initialize called Output Event Opens the databases. NSC_Initialize returns CKR_OK Inactive NSC_Finalize called NSC_Finalize returns CKR_OK Wind River Systems Inc. Version 1.2 Page 30 of 43

31 7 Physical Security (140-2 Section 4.5) The cryptographic module is a security level 1 software module and offers no physical security. Wind River Systems Inc. Version 1.2 Page 31 of 43

32 8 Operational Environment (140-2 Section 4.6) The following sections describe the operational environment of the cryptographic module. 8.1 Applicability The cryptographic module has a general purpose, modifiable operational environment. For security level 1, it uses the following commercially available operating systems: Wind River Linux Secure Solution Single Operator mode of Operation In order to use the cryptographic module at security level 1, there may be multiple users, but only one user at a time should use the module. For a note on concurrent users, please refer to Section Configuration of Discretionary Access Control In order to restrict access to stored cryptographic software and programs, the user should set the file mode permissions so that all users can execute the library files, but only the files' owner can modify the files (write, replace, and delete) during the installation of the cryptographic Library. For more information regarding access to the cryptographic keys, CSPs, and plaintext data, refer to Section Software Integrity Test Refer to Section Wind River Systems Inc. Version 1.2 Page 32 of 43

33 9 Cryptographic Key Management (140-2 Section 4.7) The following sections describe the key management of the cryptographic module. 9.1 Key/CSP Storage The cryptographic module does not store any password (for example, the password for password-based encryption, or the private key database password) on the disk in plaintext. At security level 1, the module limits the operating system to a single operator mode of operation. The cryptographic keys are stored as follows: Table 11 Key Storage Type of key Private and secret keys Public keys and certificate Temporary (session) keys Storage Private key database Private key and certificate database Memory (RAM) The OS protects all the cryptographic keys stored in the private key database and certificate database from unauthorized disclosure, modification, and substitution. When the public keys are stored in the memory, the OS protects them from unauthorized disclosure, modification, and substitution. The following keys are used internally by the module and are not visible to the operator: The Triple-DES key used to encrypt the secret keys and private keys is derived from the user's password and it is stored in the private key database. The 1024-bit DSA public keys for the software integrity test are stored along with the DSA signatures in the.chk files for the softoken (PKCS #11), libnssdbm3, and freebl shared libraries/dlls. The DSA domain parameters (prime p, subprime q, base g) and public key (y) are stored in a straight binary format (not DER encoded). 9.2 Key and CSP List Refer to Section 5.1 for the list of cryptographic keys and CSPs. 9.3 Key/CSP Generation The cryptographic module uses the FC_GenerateKey function to generate secret keys and domain parameters, and the FC_GenerateKeyPair function to generate public/private key pairs. The cryptographic module generates keys with at most 256 bits of security (refer to table 2 in Section of NIST Special Publication (SP) Part 1), Therefore, compromising the security of the key generation method (for example, guessing the seed value to initialize the Approved RNG) requires at least as many operations as determining the value of the generated key. The following approved key generation methods are used by the module: The Approved RNG specified as Algorithm Hash_DRBG of SP is used to generate cryptographic keys (for example, secret keys for symmetric key algorithms and HMAC) used by the approved and non-approved security functions. DSA public and private keys are generated using the method specified in FIPS with Change Notice 1. RSA public and private keys are generated using the method specified in PKCS #1. ECDSA public and private keys are generated using the method specified in ANSI X The prime numbers that are generated for both RSA and DSA are tested using the Miller-Rabin test (FIPS Appendix 2.1. A Probabilistic Primality Test). Wind River Systems Inc. Version 1.2 Page 33 of 43

34 9.4 Key/CSP Establishment Please refer to Table 5 in Section 2.4 for information regarding Key/CSPs establishment techniques. 9.5 Key/CSP Entry and Output The cryptographic module does not use either manual or electronic key entry and output methods or support entry of the seed key during key generation. The module uses the following automated key transport methods: The FC_UnwrapKey function enters an encrypted secret or private key into the module. The FC_WrapKey function outputs an encrypted secret or private key from the module. In the FIPS approved mode of operation, the encrypted secret and private keys, entered into or output from the module are encrypted using one of the following approved algorithms: Triple-DES AES Key Wrapping using RSA keys Note: A password based encryption is not FIPS approved. Hence, the AES or Triple-DES key derived from a password, the encrypted secret or private key is considered to be in plaintext form. 9.6 Key/CSP Zeroization The cryptographic module performs key zeroization to clear the memory area pre-occupied by the private key, secret key and password. The passwords are automatically zeroized by the module after use. All plaintext secret and private keys are zeroized when: The module is shutdown with a FC_Finalize call The module switches between the FIPS and non-fips modes with a NSC_Finalize/FC_Initialize or FC_Finalize/NSC_Initialize call sequence The module is reinitialized with a FC_InitToken call A plaintext secret or private key is zeroized when it is deleted with a FC_DestroyObject call A standard C library function PORT_memset/memset ( ) is used to zeroize memory used by plaintext secret and private keys and passwords. The PORT_ZFree( ) function is used to free and zeroize the memory which is allocated from heap. 9.7 Random Number Generation The cryptographic module uses only the Approved RNG, implementing Algorithm Hash_DRBG of NIST SP to generate cryptographic keys used by an approved security function. The certificate number of RNG obtained through the Cryptographic Algorithm Validation Program (CAVP) is #49. Wind River Systems Inc. Version 1.2 Page 34 of 43

35 10 Self-Tests (140-2 Section 4.9) FIPS requires that the module perform self-tests to ensure the integrity of the module and the correctness of the cryptographic functionality at start up. In addition, some functions require continuous verification of the function, such as the random number generator. All of these tests are listed and described in this section Power-Up Tests (140-2 Section 4.9.1) The following tests are performed each time the cryptographic module starts and must be completed successfully for the module to operate in the FIPS approved mode Cryptographic Algorithm Test Table 12 Cryptographic Algorithm Tests (ref: fipstest.c, PKCS #11 FIPS Power-Up Self Test) Algorithm Modes / Operation Test Triple-DES CBC (encrypt/decrypt) KAT (Known Answer Test) AES- 128, AES-192, AES-256, ECB (encrypt/decrypt) CBC (encrypt/decrypt) KAT KAT SHA-1, SHA-256, SHA-384, SHA-512 hash KAT HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 RSA RSA-SHA-256/-SHA-384/-SHA-512 DSA ECDSA keyed hash (296 bit key) encrypt/decrypt (1024-bit modulus n), signature generation (2048-bit modulus n) signature verification (2048-bit modulus n) key pair generation (1024-bit prime modulus p) signature generation (1024-bit prime modulus p) signature verification (1024-bit prime modulus p) signature generation (Curve P-256; the Extend ECC version of the module also tests Curve K-283) signature verification (Curve P-256; the Extend ECC version of the module also tests Curve K-283) KAT KAT KAT KAT KAT KAT KAT KAT KAT RNG N/A KAT Note: Cryptographic algorithms whose outputs vary for a given set of inputs (DSA and ECDSA) are tested using a known-answer test. The message digest algorithms have independent knownanswer tests. Wind River Systems Inc. Version 1.2 Page 35 of 43

36 Software/Firmware Integrity Test A software integrity test is performed on the libraries of the cryptographic module. DSA is used as the approved authentication technique for the integrity test. If the test fails, then the module immediately enters the error state Conditional Tests (140-2 Section 4.9.2) The following sections describe the conditional tests supported by the cryptographic module Continuous Random Number Generator Test The cryptographic module performs a continuous random number generator test, whenever the pseudorandom number generator is invoked Pair-wise Consistency Test The cryptographic module performs a pair-wise consistency test, whenever the RSA, DSA, and/or ECDSA key pair generation is invoked Critical Function Test No other critical function test is performed on power up. Wind River Systems Inc. Version 1.2 Page 36 of 43