© Copyright 2016 Entrust. All rights reserved. Title: Product: Date: Revision: FIPS 140-2 (level 2) Cryptographic Module Security Policy Entrust Authority™ Security Kernel July 11, 2016 1.6 FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page ii www.entrust.com This document may be copied without the author’s permission provided that it is copied in its entirety without any modification. Entrust is a registered trademark of Entrust, Inc. in the United States and certain other countries. Entrust is a registered trademark of Entrust Limited in Canada. All other company and product names are trademarks or registered trademarks of their respective owners. The material provided in this document is for information purposes only. It is not intended to be advice. You should not act or abstain from acting based upon such information without first consulting a professional. ENTRUST DOES NOT WARRANT THE QUALITY, ACCURACY OR COMPLETENESS OF THE INFORMATION CONTAINED IN THIS ARTICLE. SUCH INFORMATION IS PROVIDED "AS IS" WITHOUT ANY REPRESENTATIONS AND/OR WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED, STATUTORY, BY USAGE OF TRADE, OR OTHERWISE, AND ENTRUST SPECIFICALLY DISCLAIMS ANY AND ALL REPRESENTATIONS, AND/OR WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT, OR FITNESS FOR A SPECIFIC PURPOSE. FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page iii www.entrust.com Table of Contents 1 About Entrust ...........................................................................................1 2 Introduction ..............................................................................................1 3 Cryptographic Module .............................................................................1 3.1 Validation .................................................................................................................. 1 3.2 Definition................................................................................................................... 1 3.3 Security Kernel.......................................................................................................... 4 3.4 Ports and Interfaces.................................................................................................. 4 4 Policies......................................................................................................4 4.1 Identification and Authentication Policy.................................................................... 4 4.2 Access Control Policy............................................................................................... 5 4.3 Physical Security Policy............................................................................................ 6 4.4 Mitigation of Other Attacks Policy............................................................................. 7 5 Cryptographic Algorithm Support ..........................................................7 6 Self Tests ................................................................................................12 7 Operator Guidance.................................................................................13 7.1 Assumptions ........................................................................................................... 13 7.2 Delivery, Installation and Initialization..................................................................... 13 7.3 Operator Responsibilities........................................................................................ 14 7.4 Module Interfaces ................................................................................................... 14 8 References..............................................................................................15 FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 1 www.entrust.com 1 About Entrust Entrust provides trusted solutions that secure digital identities and information for enterprises and governments in more than 2,000 organizations spanning 60 countries. Offering trusted security for less, Entrust solutions represent the right balance between affordability, expertise and service. These include SSL, strong authentication, fraud detection, digital certificates and PKI. For information, call 888-690-2424, e-mail entrust@entrust.com or visit www.entrust.com. 2 Introduction This document describes the Entrust Authority™ Security Kernel (BaseSK) cryptographic module nonproprietary security policy. This document is required for FIPS 140-2 validation. It describes the capabilities, protection, and access rights provided by the BaseSK. It contains a specification of the rules under which the BaseSK must operate. These rules were derived from the requirements in [FIPS]. This document helps individuals and organizations to determine whether the BaseSK will meet their security requirements. 3 Cryptographic Module 3.1 Validation The BaseSK validation is at FIPS 140-2 (level 2) overall. Section Section Title Level 1 Cryptographic Module Specification 2 2 Cryptographic Module Ports and Interfaces 2 3 Roles, Services, and Authentication 2 4 Finite State Model 2 5 Physical Security N/A 6 Operational Environment 2 7 Cryptographic Key Management 2 8 EMI/EMC 2 9 Self-tests 2 10 Design Assurance 2 11 Mitigation of Other Attacks N/A Table 1: Security Level By FIPS 140-2 Section 3.2 Definition The BaseSK (Software versions: 8.1sp1, 8.1sp1R2 and 8.1sp1R3) in FIPS 140-2 terminology is defined as a multi-chip standalone cryptographic module. The BaseSK was tested on the following hardware computing platform and OS. 1. Dell Optiplex 755 with: - Intel Core 2 Duo E8400 (64-bit, 3.0 GHz) 2. Microsoft Windows Server 2008 R2 Enterprise Edition - Common Criteria Report: http://www.commoncriteriaportal.org/files/epfiles/st_vid10390-vr.pdf The GPC and OS were installed and configured to be CC EAL2 compliant as specified in [OS]. For details on the platforms on which products that use the BaseSK are supported, refer to the Entrust Platform Support and Integration Center. FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 2 www.entrust.com “For Level 2 Operational Environment, a software cryptographic module will remain compliant with the FIPS 140-2 validation when operating on any GPC provided that the GPC incorporates the specified CC evaluated EAL2 (or equivalent) operating system/mode/operational settings or another compatible CC evaluated EAL2 (or equivalent) operating system with like mode and operational settings.†[IG Section G.5] The logical boundary of the cryptographic module is the API into which application software may call. The physical boundary of the cryptographic module is the physical case of the GPC in which it resides. See the following block diagrams for more detail. LEGEND: Logical Cryptographic Module Boundary/Interface Data Input/Output (Plaintext and Encrypted), Control Input, and Status Output Entrust Authority™ Security Kernel Application Software Optional Cryptoki P11 Library Cryptoki API BaseSK Cryptographic Module API Operating System User Interface Standard Functions Figure 1: Cryptographic module block diagram for software (Logical). FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 3 www.entrust.com LEGEND: Physical Cryptographic Module Boundary/Interface Internal Communication Pathway Data Input/Output (Plaintext and Encrypted), Control Input, and Status Output Data Input (Plaintext and Encrypted) and Control Input Data Output (Plaintext and Encrypted) and Status Output Power Input Micro- processor(s) System Memory Disk Drive USB Interface Serial Interface Parallel Interface Video Display Driver Keyboard Interface Mouse Interface Network Interface Optional PC Card Interface Power Supply Video Display Keyboard Mouse Network Optional PKCS11 Device Power Source USB Device Serial Device Parallel Device System Bus Figure 2: Cryptographic module block diagram for hardware (Physical). FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 4 www.entrust.com 3.3 Security Kernel The BaseSK implements cryptographic algorithms and provides cryptographic services through an application programming interface (API) that allows developers to integrate security into the applications they design. This API is the logical interface to the cryptographic module and is described in detail in the BaseSK documentation [API]. 3.4 Ports and Interfaces The BaseSK has the following mapping of logical interfaces to physical ports. FIPS 140-2 Interface Logical Interface Physical Interface Data Input Interface Input parameters of some APIs Ethernet/Network Port, USB Port, Parallel Port, Serial Port, PKCS 11 Port Data Output Interface Output parameters and/or return values of some APIs Ethernet/Network Port, USB Port, Parallel Port, Serial Port, PKCS 11 Port Control Input Interface Input parameters of some APIs and all API calls themselves Ethernet/Network Port, USB Port, Parallel Port,, Serial Port, PKCS 11 Port, Keyboard and Mouse Status Output Interface Output parameters and/or return values of some APIs Ethernet/Network Port, USB Port, Parallel Port, Monitor, Serial Port, PKCS 11 Port Power Interface Initialization function Power Interface Table 2: Mapping Logical Interfaces to Physical Ports 4 Policies 4.1 Identification and Authentication Policy FIPS 140-2 requires that roles be defined for operators of the cryptographic module. In order to perform a service using the cryptographic module the operator must first assume a role. The following mandatory roles from [FIPS] are implicitly supported by the BaseSK: User: “The role assumed to perform general security services, including cryptographic operations and other Approved security functions.†Crypto Officer: “The role assumed to perform a set of cryptographic initialization or management functions (e.g., module initialization, input/output of cryptographic keys and CSPs, and audit functions).†This cryptographic module uses role based authentication. Both the User and Crypto Officer roles are authenticated via password when the operator logs into the OS. As described in Section 4.2 Access Control Policy, the operator implicitly assumes either the User or Crypto Officer role for each call to a BaseSK API. Role Type of Authentication Authentication Data User Password Minimum 8 characters on the range [a-z,A-Z,0-9] Crypto Officer Password Minimum 8 characters on the range [a-z,A-Z,0-9] Table 3: Roles and Required Identification and Authentication FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 5 www.entrust.com Authentication Mechanism Strength of Mechanism Password The strength of the password authentication mechanism depends on the range from which the password is selected. When the OS is configured to require a minimum 8 character password on the range [a-z,A-Z,0-9] this mechanism provides 628 possibilities. During a one minute period, 628 /105 attempts are required for a one in 100,000 probability that one of the attempts will succeed. That would require more than 36 million operations per second and is not feasible on the GPC. (motivated by AS03.25, AS03.26, AS03.21) Table 4: Strengths of Authentication Mechanisms 4.2 Access Control Policy Each service offered by the cryptographic module has been assigned a role. To perform a service, the operator calls a cryptographic module API and by doing so implicitly assumes the assigned role. The operator can input/output data including cryptographic keys and critical security parameters (CSP) only through the parameters and the return value provided by the API. The access the operator has to cryptographic keys and CSPs (read/write/execute) is restricted by the API and how it operates on each value. The services that are provided to each authorized role are listed in the table below. The module does not support any unauthenticated services. Role Authorized Services Crypto Officer Module Initialization Module Self-Tests Module Status Key Generation User Perform Approved Security Function  Symmetric Cipher Encryption/Decryption  Digital Signature Generation/Verification  Hash Generation  Random Number Generation  MAC Generation/Verification  Key Transport (primitive)  Key Agreement (scheme/primitive) Perform Regular Function  Key Input/Output (logical port)  Key Derivation (primitive)  Modify Object  Query Object  Non-Cryptographic Operation  Cryptographic Operation  Identity Management  Zeroization Table 5: Services Authorized for Roles The access that each service provides to security-related information (keys and CSPs) is listed in the table below. FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 6 www.entrust.com Service Cryptographic Keys and CSPs Type(s) of Access (e.g., RWE) Module Initialization None None Module Self-Tests None None Module Status None None Key Generation AES enc/dec keys Triple-DES enc/dec keys Triple-DES integrity keys RSA signing keys RSA transport keys DSA signing keys ECDSA signing keys ECDH agreement keys DH agreement keys HMAC keys Execute Execute Execute Execute Execute Execute Execute Execute Execute Execute Execute Symmetric Cipher Encryption/Decryption AES enc/dec keys Triple-DES enc/dec keys Execute Execute Digital Signature Generation/Verification RSA signing keys DSA signing keys ECDSA signing keys Execute Execute Execute Hash Generation None None Random Number Generation Entropy String Random value Execute Read MAC Generation/Verification Triple-DES integrity keys HMAC keys Execute Execute Execute Key Agreement (scheme/primitive) ECDH agreement keys DH agreement keys Shared Secret Execute Execute Read Key Transport (primitive) RSA transport keys Execute Key Input/Output (logical port) AES enc/dec keys Triple-DES enc/dec keys Triple-DES integrity keys RSA signing keys RSA transport keys DSA signing keys ECDSA signing keys ECDH agreement keys DH agreement keys HMAC keys Read, Write Read, Write Read, Write Read, Write Read, Write Read, Write Read, Write Read, Write Read, Write Read, Write Read, Write Key Derivation (primitive) Secret Read, Write Modify Object None None Query Object None None Non-Cryptographic Operation None None Cryptographic Operation None None Identity Management None None Zeroization All CSPs Write Table 6: Access Rights to CSPs within Services 4.3 Physical Security Policy The cryptographic module is software-based and does not provide any physical security mechanisms. FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 7 www.entrust.com 4.4 Mitigation of Other Attacks Policy The cryptographic module is not designed to mitigate against attacks outside of the scope of FIPS 140-2.. Other Attacks Mitigation Mechanism Specific Limitations None N/A N/A Table 7: Mitigation of Other Attacks 5 Cryptographic Algorithm Support The following table contains the set of validated FIPS Approved algorithms (including appropriate algorithm validation certificates) that can be used in FIPS mode. Important: the overall bits of security of an algorithm depends both bits of security offered by the algorithm itself and bits of security by the key it is used with; the overall bits of security of the algorithm is always the lower of the two. * SHA-1 provides less than 80-bits of security when used in a digital signature algorithm; it provides only 69-bits of security strength against collisions and is thus not recommended for use in new applications. Table 8: FIPS-Approved Algorithms Algorithm (Bits of Security) Parameters (Bits of Security) Certificate Numbers Random Number Generation Algorithms DRBG using SHA512 N/A #167 and #405 Hash Algorithms SHS  SHA1 (80*)  SHA224 (112)  SHA256 (128)  SHA384 (192)  SHA512 (256) N/A #1689 and #2206 Symmetric Cipher Algorithms AES 128 bit (128) 192 bit (192) 256 bit (256) #1923 and #2631 Triple-DES 192 bit (112) #1253 and #1580 Digital Signature Algorithms FIPS 186-2 DSA  DSA-SHA1 (80*) DSA-1024 #610 and #794 FIPS 186-3 ECDSA EC-ansix9p192k1 (80) EC-P-192 (80) #275 and FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 8 www.entrust.com  ECDSA-SHA1 (80*)  ECDSA-SHA224 (112)  ECDSA-SHA256 (128)  ECDSA-SHA384 (192)  ECDSA-SHA512 (256) EC-brainpoolP192r1 (80) EC-brainpoolP192t1 (80) EC-ansix9p224k1 (112) EC-P-224 (112) EC-brainpoolP224r1 (112) EC-brainpoolP224r1 (112) EC-ansix9p256k1 (128) EC-P-256 (128) EC-brainpoolP256r1 (128) EC-brainpoolP256t1 (128) EC-P-384 (192) EC-brainpoolP384r1 (192) EC-brainpoolP384t1 (192) EC-P-521 (256) #454 FIPS 186-3 RSA  RSA-SHA1 (80*)  RSA-SHA224 (112)  RSA-SHA256 (128)  RSA-SHA384 (192)  RSA-SHA512 (256)  RSAPSS-SHA1 (80*)  RSAPSS-SHA224 (112)  RSAPSS-SHA256 (128)  RSAPSS-SHA384 (192)  RSAPSS-SHA512 (256) RSA-1024 (80) RSA-2048 (112) RSA-3072 (128) #992 and #1345 Key Agreement Schemes ECDH from SP800-56A - 6.1.2.2 Ephemeral Unified Model, C(2, 0, ECC CDH) - 6.2.2.2 One-Pass Diffie- Hellman, C(1, 1, ECC CDH) - 6.3.2 Static Unified Model, C(0, 2, ECC CDH) - (key agreement; key establishment methodology provides between 80 and 256 bits of encryption strength) EC-ansix9p192k1 (80) EC-P-192 (80) EC-brainpoolP192r1 (80) EC-brainpoolP192t1 (80) EC-ansix9p224k1 (112) EC-P-224 (112) EC-brainpoolP224r1 (112) EC-brainpoolP224r1 (112) EC-ansix9p256k1 (128) EC-P-256 (128) EC-brainpoolP256r1 (128) EC-brainpoolP256t1 (128) EC-P-384 (192) EC-brainpoolP384r1 (192) EC-brainpoolP384t1 (192) EC-P-521 (256) #15 and #111 SP 800-135 KDF X9.63 SHA-1 KDF Vendor Affirmed Message Authentication Code (MAC) Algorithms HMAC  HMAC-SHA1 (160)  HMAC-SHA224 (224)  HMAC-SHA256 (256)  HMAC-SHA384 (384) 80 bit (80) 112 bit (112) 128 bit (128) 192 bit (192) #1158 and 1628 FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 9 www.entrust.com  HMAC-SHA512 (512) 256 bit (256) Triple-DES MAC (64) 192 bit (112) Triple-DES Cert. #1253, vendor affirmed AES GCM 128 bit 192 bit 256 bit #1923 and #2631 The following table contains the set of FIPS Allowed algorithms (including appropriate key sizes) that can also be used in FIPS mode. Table 9: FIPS-Allowed Algorithms Algorithm Parameters (Bits of Security) Key Transport Primitives RSA  PKCS1-v1.5  PKCS1-v2 OAEP  (key transport; key establishment methodology provides between 80 and 128 bits of encryption strength) RSA-1024 (80) RSA-2048 (112) RSA-3072 (128) Digital Signature Algorithms FIPS 186-3 ECDSA  ECDSA-SHA1 (80*)  ECDSA-SHA224 (112)  ECDSA-SHA256 (128)  ECDSA-SHA384 (192)  ECDSA-SHA512 (256) EC-ansix9p160k1 (80) EC-ansix9p160r1 (80) EC-ansix9p160r2 (80) EC-brainpoolP160r1 (80) EC-brainpoolP160t1 (80) EC-brainpoolP320r1 (128) EC-brainpoolP320t1 (128) EC-brainpoolP512r1 (256) EC-brainpoolP512t1 (256) Key Agreement Primitives DH  (key agreement; key establishment methodology provides 80 or 112 bits of encryption strength) DH-1024 DH-1536 ECDH  standard primitive for the single pass scheme with X9.63 SHA-1 KDF.  modified (aka: cofactor) primitive for the single pass scheme with X9.63 SHA-1 KDF. EC-ansix9p160k1 (80) EC-ansix9p160r1 (80) EC-ansix9p160r2 (80) EC-brainpoolP160r1 (80) EC-brainpoolP160t1 (80) EC-ansix9p192k1 (80) EC-P-192 (80) EC-brainpoolP192r1 (80) EC-brainpoolP192t1 (80) FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 10 www.entrust.com  (key agreement; key establishment methodology provides between 80 and 256 bits of encryption strength) EC-ansix9p224k1 (112) EC-P-224 (112) EC-brainpoolP224r1 (112) EC-brainpoolP224r1 (112) EC-ansix9p256k1 (128) EC-P-256 (128) EC-brainpoolP256r1 (128) EC-brainpoolP256t1 (128) EC-brainpoolP320r1 (128) EC-brainpoolP320t1 (128) EC-P-384 (192) EC-brainpoolP384r1 (192) EC-brainpoolP384t1 (192) EC-brainpoolP512r1 (256) EC-brainpoolP512t1 (256) EC-P-521 (256) The following table contains the set of non-FIPS Approved algorithms that are implemented but must not be used when operating in FIPS mode, or if used, must not be considered to provide any security. Table 10: Non-FIPS-Approved Algorithms Algorithm Parameters Random Number Generation Algorithms FIPS 186-2 using SHA1 N/A Hash Algorithms MD2 N/A MD5 N/A RMD-160 N/A Symmetric Cipher Algorithms CAST 40 bit 48 bit 56 bit 64 bit CAST3 40 bit 48 bit 56 bit 64 bit CAST5 80 bit 128 bit (and sizes on the range 40-128 in 8 bit increments) DES 64 bit IDEA (compatible) 128 bit RC2 (compatible) 128 bit (and sizes on the range 40-128 in 8 bit increments) FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 11 www.entrust.com RC4 128 bit (and sizes on the range 40-128 in 8 bit increments) Digital Signature Algorithms DSA  DSA-SHA1 DSA-512 (and sizes on the range 512- 960 in 64 bit increments) RSA  RSA-MD2  RSA-MD5  RSA-RMD160 RSA-512 (and sizes on the range 512- 8192 in 8 bit increments) RSA  RSA-SHA1  RSA-SHA224  RSA-SHA256  RSA-SHA384  RSA-SHA512  RSAPSS-SHA1  RSAPSS-SHA224  RSAPSS-SHA256  RSAPSS-SHA384  RSAPSS-SHA512 RSA-512 RSA-4096 RSA-6144 (and sizes on the range 512- 8192 in 8 bit increments, except those listed in the Approved/Allowed section above) Key Transport Primitives RSA  PKCS1-v1.5  PKCS1-v2 OAEP RSA-512 (and sizes on the range 512- 8192 in 8 bit increments, except those listed in the Approved/Allowed section above) Key Agreement PAKE (password authenticated key exchange) with SPEKE (simple password exponential key exchange) as the underlying protocol. Using X963 KDF with SHA1 and supporting all symmetric keys ranging from 40 to 256 bit. DH With sizes on the range 256- 1536 in 8 bit increments. Message Authentication Code (MAC) Algorithms HMAC  HMAC-MD5  HMAC-RMD160  HMAC-SHA1  HMAC-SHA224  HMAC-SHA256  HMAC-SHA384  HMAC-SHA512 HMAC is supported with all symmetric keys ranging from 40 to 256 bit. HMAC-SHA-X is only non-Approved when used with a non-Approved key size. FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 12 www.entrust.com AES-DAC 128 bit 192 bit 256 bit CAST-DAC 40 bit 48 bit 56 bit 64 bit CAST3-DAC 40 bit 48 bit 56 bit 64 bit CAST5-DAC 80 bit 128 bit (and sizes on the range 40-128 in 8 bit increments) DES-DAC 64 bit IDEA-DAC (compatible) 128 bit RC2-DAC (compatible) 128 bit (and sizes on the range 40-128 in 8 bit increments) 6 Self Tests The cryptographic module contains the following self-tests to verify its correct operation; these tests are automatically run during initialization in the FIPS Approved Mode of operation. Power-On Self-Tests:  Software integrity test using Triple-DES-MAC  Cryptographic algorithm known-answer tests o Random Number Generation Algorithms:  DRBG using SHA512 o Hash Algorithms: (compute digest and compare to known value)  SHA1  SHA224  SHA256  SHA384  SHA512 o Symmetric Cipher Algorithms: (encrypt/decrypt and compare to known value)  AES-128  AES-192  AES-256  Triple-DES o Digital Signature Algorithms: (with known public key, confirm that known signature verifies; with known private key, confirm known signature is computed)  RSA-1024, RSA-SHA1  RSA-1024, RSAPSS-SHA1  DSA-1024, DSA-SHA1  EC-P-192, ECDSA-SHA1 o MAC Algorithms: (compute and compare to known value)  HMAC-SHA1  HMAC-SHA224 FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 13 www.entrust.com  HMAC-SHA256  HMAC-SHA384  HMAC-SHA512  AES GCM  Note: Triple-DES-MAC is not separately tested as permitted by [IG Section 9.1]. o Key Agreement: (with two known key-pairs, confirm that a known secret is derived)  DH-1024  ECDH (SP 800-56A), standard X9.63 SHA-1 KDF, EC-P-192 Note: Non-mandatory tests on Non-FIPS-Approved algorithms are also performed. Note: Known answer tests for the RSA Key Transport primitive are not required because these operations are tested during RSA conditional pair-wise consistency tests (permitted by AS09.18). Conditional Tests:  Random Number Generation Algorithm continuous tests: o DRBG using SHA512 o FIPS 186-2 using SHA1  Key Pair Generation pair-wise consistency tests o DSA-SHA1 digital signature sign/verify o ECDSA-SHA1 digital signature sign/verify o RSA digital signature sign/verify o RSA key transport encrypt/decrypt Note:  Digital signature algorithm pair-wise consistency tests are only required using one message digest algorithm; permitted by [IG Section 9.4]. 7 Operator Guidance 7.1 Assumptions The following assumptions are made about the operating environment of the cryptographic module:  Unauthorized reading, writing, or modification of the module’s memory space (code and data) by an intruder (human or machine) is not possible; this is prevented by the process memory management of the OS.  Replacement or modification of the legitimate cryptographic module code by an intruder (human or machine) is not feasible.  The module is initialized to the FIPS 140-2 mode of operation. 7.2 Delivery, Installation and Initialization The following steps must be performed in order to securely deliver, install and initialize the BaseSK cryptographic module in the FIPS 140-2 Approved mode of operation:  All BaseSK versioned source files [SRC] must be built and linked into a target application.  The target application must be designed such that when loaded into memory, without input from the operator, it automatically calls SK_Initialize(true) and then uses the SK_SoftwareAuthenticator object to verify its software integrity from a pre- FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 14 www.entrust.com computed MAC value stored in an ini file. Note that the SK_SoftwareAuthenticator is designed to internally call SK_RunAllSelfTests() as its last step.  The operator must acquire the target application and associated MAC value ini file through a medium at least as secure as download from https://secure.entrust.com (i.e. a trusted SSL download).  The OS on which the target application resides must enforce that passwords contain a minimum of 8 characters on the range [a-z,A-Z,0-9] and must enforce that login is required after each power-on of the GPC (motivated by AS03.25, AS03.26, AS03.21).  The target application must be launched (and as stated above will automatically perform software authentication and self tests). The BaseSK cryptographic module is now in the approved mode of operation and all cryptographic services are available. 7.3 Operator Responsibilities The operator must continually fulfill the following responsibilities to maintain the BaseSK cryptographic module in the FIPS 140-2 approved mode of operation:  Input and output of plaintext private keys, plaintext secret keys, or plaintext CSPs via any physical port of the module is prohibited.  Input and output of encrypted private keys, encrypted secret keys, or encrypted CSPs via any physical port of the module is only permitted when encrypted using an approved algorithm.  Non-FIPS-Approved Algorithms (see Table 10) must not be requested from the BaseSK cryptographic module.  No key generated by the cryptographic module shall be considered to offer more than 256-bits of security, regardless of its size. (motivated by VE07.13.01)  When performing ECDH o The bits of security of the EC key shall be at least as large as the bits of security of the key being agreed upon. o Ephemeral private keys shall be securely destroyed after a single use. o Static public keys shall  Be received over a trusted channel that asserts: The sender is the entity with whom ECDH should be performed. The sender possesses the matching private key. The sender does not use this key for other purposes.  Or a corresponding certificate shall be verified to confirm: The sender is the entity with whom ECDH should be performed, because their name is in the certificate. The sender possesses the matching private key, because the certification authority performed proof-of-possession when the cert was issued. The sender does not use this key for other purposes, because the keyUsage does not contain digitalSignature.  When performing "Static Unified Model" ECDH, the NonceU, IDU, IDV from SP800-56A shall be achieved by SK_KeyAgreeParams and the SK_Key::KeyAgree API. 7.4 Module Interfaces All physical ports are available to all operators of the module. Each BaseSK API that is part of the cryptographic module’s logical interface is included in [API] and labeled either “FIPS Role: User†or “FIPS Role: Crypto Officer†depending on the role that is implicitly assumed by calling it. All API arguments and return values are labeled as Data Input, Data Output, Control Input, or Status Output. The documentation for each API includes details on any relevant security events and/or parameters and which “FIPS Service†is being performed. FIPS 140-2 (Level 2) Cryptographic Module Security Policy - Entrust Authority™ Base Security Kernel 8.1sp1R3 © Copyright 2016 Entrust. All rights reserved. Page 15 www.entrust.com 8 References Author Title NIST [FIPS] FIPS PUB 140-2: Security Requirements For Cryptographic Modules, December 2002 (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) NIST [IG] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program, August 2010 (http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf) Entrust [API] FIPS 140-2 (level 2) Cryptographic Module API Documentation for the Entrust Authority™ Security Kernel Entrust [SRC] FIPS 140-2 (level 2) Cryptographic Module Source Distribution for the Entrust Authority™ Security Kernel Microsoft [OS] Microsoft Windows Common Criteria Evaluation (http://www.commoncriteriaportal.org/files/epfiles/st_vid10390-st.pdf)