Security Policy nShield F3 10+, nShield F3 500+, nShield F3 6000+, nShield F3 500+ for nShield Connect+, nShield F3 1500+ for nShield Connect+, nShield F3 6000+ for nShield Connect+ in FIPS 140-2 level 3 mode Version: 5.0 Date: 25 April 2019 Copyright 2019 nCipher Security Limited. All rights reserved. Copyright in this document is the property of nCipher Security Limited. It is not to be reproduced, mod- ified, adapted, published, translated in any material form (including storage in any medium by electronic means whether or not transiently or incidentally) in whole or in part nor disclosed to any third party without the prior written permission of nCipher Security Limited neither shall it be used otherwise than for the purpose for which it is supplied. Words and logos marked with ® or ™ are trademarks of nCipher Security Limited or its affiliates in the EU and other countries. Mac and OS X are trademarks of Apple Inc., registered in the U.S. and other countries. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. Information in this document is subject to change without notice. nCipher Security Limited makes no warranty of any kind with regard to this information, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. nCipher Security Limited shall not be liable for errors contained herein or for incidental or consequential damages con- cerned with the furnishing, performance or use of this material. Where translations have been made in this document English is the canonical language. Security Policy Page 2 of 50 Contents 1 Purpose 6 2 Ports and Interfaces 9 3 Roles 10 3.1 Unauthenticated 10 3.2 User 10 3.3 nShield Security Officer 10 3.4 Junior Security Officer 11 4 Services available to each role 12 4.1 Terminology 27 5 Keys 29 5.1 nShield Security Officer's key 29 5.2 Junior Security Officer's key 29 5.3 Long term signing key 29 5.4 Module signing key 30 5.5 Module keys 30 5.6 Logical tokens 30 5.7 Share keys 31 5.8 Impath keys 31 5.8.1 nShield Remote Administration Token Secure Channel 31 5.9 Key objects 32 5.10 Session keys 32 5.11 Archiving keys 32 5.12 Certificate signing keys 33 5.13 Firmware Integrity Key 33 5.14 Firmware Confidentiality Key 34 5.15 Master Feature Enable Key 34 5.16 DRBG Key 34 6 Rules 35 6.1 Identification and authentication 35 6.1.1 Access Control 35 6.1.2 Access Control List 35 Security Policy Page 3 of 50 6.1.3 Object re-use 36 6.1.4 Error conditions 36 6.1.5 Security Boundary 36 6.1.6 Status information 37 6.2 Procedures to initialize a module to comply with FIPS 140-2 Level 3 37 6.2.1 Verifying the module is in level 3 mode 37 6.3 Return a module to factory state 37 6.4 Create a new operator 38 6.5 Authorize the operator to create keys 38 6.6 Authorize an operator to act as a Junior Security Officer 39 6.7 Authenticate an operator to use a stored key 39 6.8 Authenticate an operator to create a new key 39 7 Physical security 40 7.1 Checking the module 40 8 Strength of functions 41 8.1 Object IDs 41 8.2 Tokens 41 8.3 Key Blobs 41 8.4 Impaths 42 8.4.1 nShield Remote Administration Token Secure Channel 42 8.4.2 KDP key provisioning 43 8.4.3 Derived Keys 43 9 Self Tests 45 9.1 Firmware Load Test 45 10 Supported Algorithms 46 10.1 FIPS approved and allowed algorithms: 46 10.1.1 Symmetric Encryption 46 10.1.1.1 AES 46 10.1.1.2 Triple-DES 46 10.1.2 Hashing and Message Authentication 46 10.1.2.1 AES CMAC 46 10.1.2.2 AES GMAC 46 10.1.2.3 HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384 and 46 Page 4 of 50 Security Policy HMAC SHA-512 10.1.2.4 SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 46 10.1.2.5 Triple-DES MAC 46 10.1.3 Signature 46 10.1.3.1 DSA 46 10.1.3.2 ECDSA 47 10.1.3.3 RSA 47 10.1.4 Key Establishment 47 10.1.4.1 Diffie-Hellman 47 10.1.4.2 Elliptic Curve Diffie-Hellman 47 10.1.4.3 RSA 47 10.1.4.4 AES 47 10.1.4.5 EC-MQV 47 10.1.5 Key Derivation 47 10.1.6 Other 47 10.1.6.1 Deterministic Random Bit Generator 47 10.2 Non-FIPS approved algorithms 48 10.2.1 Symmetric 48 10.2.2 Asymmetric 48 10.2.3 Hashing and Message Authentication 48 10.2.4 Key wrapping/Key transport 48 10.2.5 Non-deterministic entropy source 48 10.2.6 Other 48 Contact Us 49 Europe, Middle East, and Africa 49 Americas 49 Asia Pacific 49 Security Policy Page 5 of 50 1 Purpose 1 Purpose nCipher nShield tamper evident and tamper responsive Hardware Security Modules provide support for the widest range of cryptographic algorithms, application programming interfaces (APIs) and host oper- ating systems, enabling the devices to be used with virtually any business application—from identity man- agement, web services and database encryption to tokenization, PKI services and strong authentication. The following figure shows the nCipher nShield cryptographic module: The nShield F3 is also fitted in the nCipher nShield Connect, which is shown below: The nShield Hardware Security Modules are defined as multi-chip embedded cryptographic modules as defined by FIPS PUB 140-2. Security Policy Page 6 of 50 1 Purpose Unit ID Model Number Real Time Clock (RTC)NVRA- M Secure Exe- cution Envir- onment (SEE) Potting (epoxy resin) EMC clas- sification Crypto Accel- erator Overall FIPS level nShield F3 6000+ nC4433E- 6K0 Yes Optional Yes B Yes 3 nShield F3 500+ nC4433E- 500 Yes Optional Yes B Yes 3 nShield F3 10+ nC4033E- 010 Yes Optional Yes B None 3 nShield F3 6000+ for nShield Connect+ nC4433E- 6K0N1 Yes Optional Yes B Yes 3 nShield F3 1500+ for nShield Connect+ nC4433E- 1K5N2 Yes Optional Yes B Yes 3 nShield F3 500+ for nShield Connect+ nC4433E- 500N3 Yes Optional Yes B Yes 3 The units are identical in appearance and operation and only vary in the processing speed. All modules are supplied at build standard “N” or later to indicate that they meet the latest EU regulations regarding ROHS. nCipher also supply modules to third party OEM vendors for use in a range of security products. The modules run firmware provided by nCipher. There is the facility for the administrator to upgrade this firmware. In order to determine that the module is running the correct version of firmware they should use the New Enquiry service which reports the version of firmware currently loaded. The validated firm- ware version is 2.61.2-3, . 1This module is embedded in the nShield Connect 6000+ appliance with model number NH2068 2This module is embedded in the nShield Connect 1500+ appliance with model number NH2061 3This module is embedded in the nShield Connect 500+ appliance with model number NH2054 Page 7 of 50 Security Policy 1 Purpose The initialization parameters are reported by the New Enquiry and Sign Module State services. An operator can determine which mode the module is operating in using the KeySafe GUI or the command line utilities supplied with the module, or their own code - these operate outside the security boundary. The modules must be accessed by a custom written application. Full documentation for the nCore API can be downloaded from the nCipher web site. The modules have on-board non-volatile memory. There are services that enable memory to be alloc- ated as files. Files have Access Control Lists that determine what operations can be performed on their contents. nShield modules have an on-board Real-time clock. The module can be connected to a computer running one of the following operating systems: l Windows l Solaris l HP-UX l AIX l Linux x86 / x64 Windows was used to test the module for this validation. Section Level 1. Cryptographic Module Specification 3 2. Cryptographic Module Ports and Interfaces 3 3. Roles, Services, and Authentication 3 4. Finite State Model 3 5. Physical Security 3 6. Operational Environment N/A 7. Cryptographic Key Management 3 8. EMI/EMC 3 9. Self-Tests 3 10. Design Assurance 3 11. Mitigation of Other Attacks N/A Overall FIPS Level 3 Security Policy Page 8 of 50 2 Ports and Interfaces 2 Ports and Interfaces The module has the following physical ports: l PCIe bus (data input/output, control input, status output and power). The services provided by the module are transported through this interface. l Status LED (status output) l Mode switch (control input) l Clear button (control input) l PS/2 serial connector and 14-pin header (data input/output) for connecting a smartcard reader. The actual physical connectors are outside the cryptographic boundary and the PCB traces coming from those connectors transport the signals into the module's cryptographic boundary. Security Policy Page 9 of 50 3 Roles 3 Roles The module defines the following roles: Unauthenticated, User, nShield Security Officer and Junior Security Officer. The nShield Security Officer and Junior Security Officer roles are equivalent of FIPS 140-2 Crypto-Officer role. 3.1 Unauthenticated All connections are initially unauthenticated. An operator in the unauthenticated role does not have access to handles or tickets required to provide access to the CSPs of authenticated users. 3.2 User An operator assumes the user role by providing the required authority to carry out a service. The exact accreditation required to perform each service is listed in the table of services. In order to perform an operation on a stored key, the operator must first load the key blob. If the key blob is protected by a logical token, the operator must first load the logical token by loading shares from smart cards. If the module is initialized in level 3 mode, the user role requires a certificate from the nShield Security Officer to import or generate a new key. This certificate is linked to a token protected key. Once an operator in the user role has loaded a key they can then use this key to perform cryptographic operations as defined by the Access Control List (ACL) stored with the key. Each key blob contains an ACL that determines what services can be performed on that key. This ACL can require a certificate from an nShield Security Officer authorizing the action. Some actions including writing tokens always require a certificate. 3.3 nShield Security Officer The nShield Security Officer (NSO) is responsible for overall security of the module. The nShield Security Officer is identified by a key pair, referred to as KNSO. The hash of the public half of this key is stored when the unit is initialized. Any operation involving a module key or writing a token requires a certificate signed by KNSO. The nShield Security Officer is responsible for creating the authentication tokens (smart cards) for each operator and ensuring that these tokens are physically handed to the correct person. An operator assumes the role of NSO by loading the private half of KNSO and presenting the ObjectID for this key to authorize a command. Security Policy Page 10 of 50 3 Roles 3.4 Junior Security Officer Where the nShield Security Officer want to delegate responsibility for authorizing an action they can cre- ate a key pair and give this to their delegate who becomes a Junior Security Officer (JSO). An ACL can then refer to this key, and the JSO is then empowered to sign the certificate authorizing the action. The JSO's keys should be stored on a key blob protected by a token that is not used for any other purpose. In order to assume the role of JSO, the operator loads the JSO key and presents the ObjectID of this key, and if required the certificate signed by KNSO that delegates authority to the key, to authorize a com- mand. A JSO can delegate portions of their authority to a new operator in the same way. The new operator will be a JSO if they have authority they can delegate, otherwise they will assume the user role. Page 11 of 50 Security Policy 4 Services available to each role 4 Services available to each role This section describes all the services supported by the module. The functions available depend on whether the operator has assumed the unauthenticated role, the user or junior security officer (JSO) roles, or the nShield Security Officer (NSO) role. The reader can refer to the Terminology table at the end of this section for an explanation of the terms used. For each operation it lists the supported algorithms. Algorithms in square brackets are not under the operator's control. Algorithms used in optional portions of a service are listed in italics. Algorithms marked with an asterisk are not approved by NIST. In the approved mode of oper- ation these algorithms are disabled. Key Access Description Create Creates a in-memory object, but does not reveal value. Erase Erases the object from memory, smart card or non-volatile memory without revealing value Export Discloses a value, but does not allow value to be changed. Report Returns status information Set Changes a CSP to a given value Use Performs an operation with an existing CSP - without revealing or changing the CSP Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO Bignum Oper- ation Yes Yes Yes Performs simple mathematical operations. No access to keys or CSPs Change Share PIN No pass phrase pass phrase Updates the pass phrase used to encrypt a token share. The pass phrase supplied by the operator is not used directly, it is first hashed and then combined with the module key. To achieve this the command decrypts the existing share using the old share key derived from old pass Sets the pass phrase for a share, uses module key, uses share key, uses module key, creates share key, uses new share key, [SHA-1 and AES or Triple DES] Security Policy Page 12 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO phrase, module key and smart card identity. It then derives a new share key based on new pass phrase, module key and smart card identity, erases old share from smart card and writes a new share encrypted under the new share key. exports encryp- ted share, erases old share Channel Open No handle, ACL handle, ACL Opens a communication chan- nel which can be used for bulk encryption, decryption, signing or hashing. Uses a key object SHA-1, SHA- 224, SHA- 256, SHA- 384, SHA- 512 RSA, DSA, ECDSA, Triple DES MAC, HMAC, KCDSA* Channel Update No handle handle Performs encryption, decryption, signing or hashing on a pre- viously opened channel. The operation and key are specified in ChannelOpen. Uses a key object SHA-1, SHA- 224, SHA- 256, SHA- 384, SHA- 512 RSA, DSA, ECDSA, Triple DES MAC, HMAC, KCDSA* Clear Unit Yes Yes Yes Causes the module to reset and will trigger the Self-tests. Zero- ises all loaded keys, tokens and shares. Clear Unit does not erase long term keys, such as module keys. Zeroizes objects. All Create Buffer No cert Yes Allocates an area of memory to load data. If the data is encryp- Uses a key object AES, Triple DES Page 13 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO ted, this service specifies the encryption key and IV used. The decrypt operation is performed by LoadBuffer Decrypt No handle, ACL handle, ACL Decrypts a cipher text with a stored key returning the plain text. Uses a key object AES, Triple DES Derive Key No handle, ACL handle, ACL The DeriveKey service provides functions that the FIPS 140-2 standard describes as key wrapping and split know- ledge - it does not provide key derivation in the sense under- stood by FIPS 140-2. Creates a new key object from a variable number of other keys already stored on the module and returns a handle for the new key. This service can be used to split, or combine, encryption keys. This service is used to wrap keys according to the KDP so that a key server can distribute the wrapped key to micro-HSM devices. Uses a key object, create a new key object. AES, AES key wrap, RSA, EC-DH, EC-MQV, Triple DES*, TLS key derivation*, XOR, DLIES (D/H plus Triple DES or D/H plus AES), Destroy No handle handle Removes an object, if an object has multiple handles as a result of RedeemTicket service, this removes the current handle. Erases a SEEWorld, impath, logical token, or any key object. All Duplicate No handle, ACL handle, ACL Creates a second instance of a key object with the same ACL and returns a handle to the new instance. Creates a new key object. All Security Policy Page 14 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO Dynamic Slot Create Asso- ciation Yes Yes Yes Creates a slot association used to reserve and identify a dynamic slot for use by this cli- ent. No access to keys or CSPs Dynamic Slot Exchange APDUs No handle handle Exchange Application Protocol Data Units with the remote Java- card. Uses secure channel integ- rity and con- fidentiality keys [AES, AES- CMAC, ECDH, ECDSA] Dynamic Slots Configure Yes Yes Yes Instructs a module to recon- figure itself to have the given number of dynamic smartcard slots. No access to keys or CSPs Dynamic Slots Configure Query Yes Yes Yes Queries a module to determine whether it has had its dynamic slots configured. No access to keys or CSPs Encrypt No handle, ACL handle, ACL Encrypts a plain text with a stored key returning the cipher text. Uses a key object AES, Triple DES Erase File No cert Yes Removes a file, but not a logical token, from a smart card or soft- ware token. No access to keys or CSPs Erase Share No cert Yes Removes a share from a smart card or software token. Erases a share Export No handle, ACL handle, ACL If the unit has been initialized to comply with FIPS 140-2 level 3 roles and services and key man- agement, this service is only available for public keys. Exports a [pub- lic] key object. RSA, DSA, ECDSA, Dif- fie-Hellman, El-Gamal and ECDH public keys Fail Yes Yes Yes Causes the module to enter a failure state. No access to keys or CSPs Feature Enable No cert cert Enables a service. This requires a certificate signed by the Master Feature Enable key. Uses the public half of the Master Feature Enable Key [DSA] File Copy No cert, ACL ACL Copies a file. You can only copy files in their entirety. Requires No access to keys or CSPs Page 15 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO file copying permission, and per- mission to create the file on the target device. File Create No cert Yes Creates a file on the given device. The file is created with the size given in the file argu- ment, and is initially filled with zeroes. The file must not exist. This prevents overwriting and race conditions. No access to keys or CSPs File Op No cert, ACL ACL Does an operation on a file, e.g. read, write, delete. Requires that the file's ACL permit the operation. No access to keys or CSPs Firmware Authenticate Yes Yes Yes Reports firmware version. Per- forms a zero knowledge chal- lenge response protocol based on HMAC that enables a oper- ator to ensure that the firmware in the module matches the firm- ware supplied by nCipher. The protocol generates a ran- dom value to use as the HMAC key. No access to keys or CSPs HMAC Foreign Token Command No handle handle Sends an ISO-7816 command to a smart card over the channel opened by ForeignTokenOpen. No access to keys or CSPs Foreign Token Open No FE, cert FE Opens a channel to foreign smart card that accepts ISO- 7816 commands. This service cannot be used if the smart card has been formatted using FormatToken. The channel is closed when the card is removed from the reader, or if the handle is destroyed. This service is feature enabled. No access to keys or CSPs Format Token No cert Yes Formats a smart card or soft- ware token ready for use. May use a mod- [AES, Triple DES] Security Policy Page 16 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO ule key to cre- ate challenge response value Generate Key No cert Yes Generates a symmetric key of a given type with a specified ACL and returns a handle. Optionally returns a certificate containing the ACL. The data generated by this oper- ation is not a CSP until it has been bound to an authorized user by protecting it with a token. Creates a new symmetric key object. Sets the ACL and Applic- ation data for that object. Optionally uses module signing key and exports the key gen- eration cer- tificate. AES, Triple DES Generate Key Pair No cert Yes Generates a key pair of a given type with specified ACLs for each half or the pair. Performs a pair wise consistency check on the key pair. Returns two key handles. Optionally returns certificates containing the ACL. The data generated by this oper- ation is not a CSP until it has been bound to an authorized user by protecting it with a token. Creates two new key objects. Sets the ACL and Application data for those objects. Option- ally uses mod- ule signing key and exports two key generation certificates. Diffie-Hell- man, DSA, ECDSA, EC-DH, EC-MQV, RSA Generate Logical Token No cert Yes Creates a new logical token, which can then be written as shares to smart cards or soft- ware tokens. On creation the token is not a CSP as it does not protect any sensitive data. Uses module key. Creates a logical token. [AES or Triple DES] Get ACL No handle, handle, Returns the ACL for a given Exports the ACL Page 17 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO ACL ACL handle. for a key object. Get Application Data No handle, ACL handle, ACL Returns the application inform- ation stored with a key. Exports the application data of a key object. Get Challenge Yes Yes Yes Returns a random nonce that can be used in certificates No access to keys or CSPs Get Key Info No handle handle Superseded by GetKeyIn- foExtended, retained for com- patibility. Exports the SHA-1 hash of a key object Get Key Info Extended No handle handle Returns the hash of a key for use in ACLs Exports the SHA-1 hash of a key object Get Logical Token Info Extended No handle handle Returns the token hash and number of shares for a logical token Exports the SHA-1 hash of a logical token. [SHA-1] Get Logical Token Info No handle handle Returns the token hash and number of shares for a logical token Exports the SHA-1 hash of a logical token. [SHA-1] Get Module Keys Yes Yes Yes Returns a hashes of the nShield Security Officer's key and all loaded module keys. Exports the SHA-1 hash of KNSO and mod- ule keys. [SHA-1] Get Module Long Term Key Yes Yes Yes Returns a handle to the public half of the module's signing key. this can be used to verify key generation certificates and to authenticate inter module paths. Exports the pub- lic half of the module's long term signing key. [DSA, ECDSA] Get Module Signing Key Yes Yes Yes Returns the public half of the module's signing key. This can be used to verify certificates signed with this key. Exports the pub- lic half of the module's sign- ing key. [DSA] Get Module State Yes Yes Yes Returns unsigned data about the current state of the module. No access to keys or CSPs Get RTC Yes Yes Yes Reports the time according to No access to Security Policy Page 18 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO the on-board real-time clock keys or CSPs Get Share ACL Yes Yes Yes Returns the access control list for a share Exports the ACL for a token share on a smart card. Get Slot Info Yes Yes Yes Reports status of the physical token in a slot. Enables an oper- ator to determine if the correct token is present before issuing a ReadShare command. If the token was formatted with a challenge response value, uses the module key to authenticate the smart card. Uses a module key if token is formatted with a challenge response value. [AES, Triple DES] Get Slot List Yes Yes Yes Reports the list of slots available from this module. No access to keys or CSPs Get Ticket No handle handle Gets a ticket - an invariant iden- tifier - for a key. This can be passed to another client or to a SEE World which can redeem it using RedeemTicket to obtain a new handle to the object, Uses a key object, logical token, impath, SEEWorld. Hash Yes Yes Yes Hashes a value. No access to keys or CSPs SHA-1, SHA- 224, SHA- 256, SHA- 384, SHA- 512 Impath Get Info No handle handle Reports status information about an impath Uses an Impath, exports status information. Impath Key Exchange Begin FE FE FE Creates a new inter-module path and returns the key exchange parameters to send to the peer module. Creates a set of Impath keys [DSA and Dif- fie Hellman] AES, Triple- DES Impath Key No handle handle Completes an impath key Creates a set of [DSA and Dif- Page 19 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO Exchange Fin- ish exchange. Require the key exchange parameters from the remote module. Impath keys. fie Hellman, AES, Triple DES] Impath Receive No handle handle Decrypts data with the Impath decryption key. Uses an Impath key. [AES or Triple DES] Impath Send No handle handle Encrypts data with the impath encryption key. Uses an Impath key. [AES or Triple DES] Import No cert Yes Loads a key and ACL from the host and returns a handle. The data generated by this oper- ation is not a CSP until it has been bound to an authorized user by protecting it with a token. If the unit has been initialized to comply with FIPS 140-2 level 3 roles and services and key man- agement, this service is only available for public keys. Creates a new key object to store imported key, sets the key value, ACL and App data. Initialise Unit init init init Initializes the module, returning it to the factory state. This clears all NVRAM files, all loaded keys and all module keys and the module signing key. This can only be performed when the module is in initialization mode. It also generates a new KM0 and module signing key. The only key that is not zeroized is the long term signing key. This key only serves to provide a cryptographic identity for a module that can be included in a PKI certificate chain. nCipher Erases all keys, Creates KM0 and KML [DSA] Security Policy Page 20 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO may issue such certificates to indicate that a module is a genu- ine nShield module. This key is not used to encrypt any other data. Insert Soft Token Yes Yes Yes Allocates memory on the mod- ule that is used to store one or more logical shares or other Token data objects. No access to keys or CSPs Load Blob No handle handle Loads a key that has been stored in a key blob. The oper- ator must first have loaded the token or key used to encrypt the blob. Uses module key, logical token, or archiv- ing key, creates a new key object. Triple DES and SHA-1 or AES, DH, or RSA plus AES, SHA-1, and HMAC SHA-256 (256 bit key) or HMAC SHA-1 (160 bit key) Load Buffer No handle handle Loads signed data into a buffer. Several load buffer commands may be required to load all the data, in which case it is the responsibility of the client pro- gram to ensure they are sup- plied in the correct order. Requires the handle of a buffer created by CreateBuffer. No access to keys or CSPs Load Logical Token yes yes yes Allocates space for a new logical token - the individual shares can then be assembled using ReadShare or ReceiveShare. Once assembled the token can be used in LoadBlob or MakeBlob commands. Uses module key [AES or Triple DES] Page 21 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO Make Blob No handle, ACL handle, ACL Creates a key blob containing the key and returns it. The key object to be exported may be any algorithm. Uses module key, logical token or archiv- ing key, exports encrypted key object. Triple DES and SHA-1 or AES, DH, or RSA plus AES, SHA-1, and HMAC SHA-256 (256 bit key) or HMAC SHA-1 (160 bit key) Mod Exp Yes Yes Yes Performs a modular expo- nentiation on values supplied with the command. No access to keys or CSPs Mod Exp CRT Yes Yes Yes Performs a modular expo- nentiation on values, supplied with the command using Chinese Remainder Theorem. No access to keys or CSPs Module Info Yes Yes Yes Reports low level status inform- ation about the module. This ser- vice is designed for use in nCipher' test routines. No access to keys or CSPs New Enquiry Yes Yes Yes Reports status information (Show Status). No access to keys or CSPs No Operation Yes Yes Yes Does nothing, can be used to determine that the module is responding to commands. No access to keys or CSPs NVMem Alloc- ate No cert Yes Allocates an area of non-volatile memory as a file and sets the ACLs for this file. This command can now be used to write files protected by an ACL to a smart card No access to keys or CSPs NVMem Free No cert Yes Frees a file stored in non-volat- ile memory. This command can No access to keys or CSPs Security Policy Page 22 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO now be used to write files pro- tected by an ACL to a smart card NVMem List Yes Yes Yes Reports a list of files stored in the non-volatile memory or pro- tected by an ACL on a smart card. No access to keys or CSPs NVMem Oper- ation No cert, ACL ACL Performs an operation on a file stored in non-volatile memory. Operations include: read, write, increment, decrement, etc. This command can now be used to write files protected by an ACL to a smart card No access to keys or CSPs Random num- ber Yes Yes Yes Generates a random number for use in a application using the on-board random number gen- erator. There are separate services for generating keys. The random number services are designed to enable an application to access the ran- dom number source for its own purposes - for example an on- line casino may use Gen- erateRandom to drive its applic- ations. Uses DRBG key [AES] Random prime Yes Yes Yes Generates a random prime. This uses the same mechanism as is used for RSA and Diffie-Hell- man key generation. The prim- ality checking conforms to ANSI X9.31. Uses DRBG key [AES] Read File No Yes Yes Reads a file, but not a logical token, from a smart card or soft- Reads a file, but Page 23 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO ware token. This command can only read files without ACLs. not a logical token, from a smart card or software token. This command can only read files without ACLs. No access to keys or CSPs Read Share Yes Yes Yes Reads a share from a physical token. Once sufficient shares have been loaded recreates token- may require several ReadShare or ReceiveShare commands. Uses pass phrase, module key, creates share key, uses share key, cre- ates a logical token. [SHA-1, AES or Triple DES] Receive Share No handle, encrypted share handle, encrypted share Takes a share encrypted with SendShare and a pass phrase and uses them to recreate the logical token. - may require sev- eral ReadShare or ReceiveShare commands Uses an Impath key, uses pass phrase, module key, creates share key, uses share key, cre- ates a logical token [AES, Triple DES] Redeem Ticket No ticket ticket Gets a handle in the current name space for the object referred to by a ticket created by GetTicket. Uses a key object, logical token, impath, or SEEWorld. Remove KM No cert Yes Removes a loaded module key. Erases a mod- ule key Remove Soft Token Yes Yes Yes Removes a soft token. Copies the updated shares to the host and deletes them from the mod- ule's memory. No access to keys or CSPs Secure Exe- No cert cert Support for SEE machines. No access to Security Policy Page 24 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO cution Envir- onment (SEE) control SEE machines are outside the FIPS boundary. keys or CSPs Send Share No handle, ACL handle, ACL Reads a logical token share and encrypts it under an impath key for transfer to another mod- ule where it can be loaded using ReceiveShare Uses an impath key, exports encrypted share. [AES, Triple DES] Set ACL No handle, ACL handle, ACL Sets the ACL for an existing key. The existing ACL for the key must allow the operation. Sets the Access Control List for a key object Set Application Data No handle, ACL handle, ACL Stores information with a key. Sets the applic- ation data stored with a key object Set KM No cert Yes Loads a key object as a module key. Uses a key object, sets a module key AES, Triple DES Set NSO Perm init init No Designates a key hash as the nShield Security Officer's Key and sets the security policy to be followed by the module. This can only be performed while the unit is in the initialization state. Sets the identity of the nShield Security officer's key. [SHA-1 hash of DSA key] Set RTC No cert Yes Sets the real-time clock. No access to keys or CSPs Sign No handle, ACL handle, ACL Returns the digital signature or MAC of plain text using a stored key. Uses a key object RSA, DSA, ECDSA, Triple DES MAC, HMAC Sign Module State No handle, ACL handle, ACL Signs a certificate describing the modules security policy, as set by SetNSOPerm. Uses the mod- ule signing key [DSA] Statistic Get Yes Yes Yes Reports a particular statistic. No access to Page 25 of 50 Security Policy 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO Value keys or CSPs Statistics Enu- merate Tree Yes Yes Yes Reports the statistics available. No access to keys or CSPs Update Firm- ware monitor monitor monitor This service is used in the update firmware service. nCipher supply the LoadROM util- ity for the administrator to use for this service. This utility issues the correct command sequence to load the new firm- ware. The module will only be oper- ating in a FIPS approved mode if you install firmware that has been validated by NIST / CSE. Administrators who require FIPS validation should only upgrade firmware after NIST / CSE issue a new certificate. The monitor also checks that the Version Sequence Number (VSN) of the firmware is as high or higher than the VSN of the firmware currently installed. Uses Firmware Integrity Key and Firmware Confidentiality Keys. Sets Firmware Integrity Key and Firmware Confidentiality Keys. [DSA, AES] Verify No handle, ACL handle, ACL Verifies a digital signature using a stored key. Uses a key object. RSA, DSA, ECDSA, Triple DES MAC, HMAC Verify Cer- tificate Yes Yes Yes Verifies a certificate. If the cer- tificate (including any del- egation chain) verifies correctly, then the command succeeds. Access to keys? [ECDSA pub- lic keys] Write File No cert Yes Writes a file, but not a logical token, to a smart card or soft- ware token. No access to keys or CSPs Security Policy Page 26 of 50 4 Services available to each role Command / Service Role Description Key/CSP access Key types Unauth JSO / User NSO Note these files do not have an ACL, use the NVMEM com- mands to create files with an ACL. Write Share No cert, handle handle Writes a new share to a smart card or software token. The num- ber of shares that can be cre- ated is specified when the token is created. All shares must be written before the token is des- troyed. Sets pass phrase, uses module key, cre- ates share, uses pass phrase and module key, cre- ates share key, uses module key, uses share key, exports encrypted share. [AES, Triple DES, SHA-1] 4.1 Terminology Code Description No The operator can not perform this service in this role. yes The operator can perform this service in this role without further authorization. handle The operator can perform this service if they possess a valid handle for the resource: key, channel, impath, token, buffers. The handle is an arbitrary number generated when the object is created. The handle for an object is specific to the operator that created the object. The ticket services enable an operator to pass an ID for an object they have created to another operator. Page 27 of 50 Security Policy 4.1 Terminology Code Description ACL Access Control List. The operator can only perform this service with a key if the ACL for the key permits this service. The ACL may require that the operator present a certificate signed by a Security Officer or another key. The ACL may specify that a certificate is required, in which case the module verifies the sig- nature on the certificate before permitting the operation. pass phrase An operator can only load a share, or change the share PIN, if they possess the pass phrase used to derive the share. The module key with which the pass phrase was com- bined must also be present. cert An operator can only perform this service if they are in possession of a certificate from the nShield Security Officer. This certificate will reference a key. The module verifies the sig- nature on the certificate before permitting the operation. FE Feature Enable. This service is not available on all modules. It must be enabled using the FeatureEnable service before it can be used. encrypted share The ReceiveShare command requires a logical token share encrypted using an Impath key created by the SendShare command. ticket The RedeemTicket command requires the ticket generated by GetTicket. init These services are used to initialize the module. They are only available when the module is in the initialization mode.To put the module into initialization mode, either physically move the mode switch to the Initialization setting and use the Clear Unit command / service to clear the module, or invoke the Clear Unit command / service using a command line utility specifying Initialization as a parameter. In order to restore the module to operational mode you must put the mode back to the Operational setting. monitor These services are used to reprogram the module. They are only available when the mod- ule is in the monitor mode.To put the module into monitor mode you must have physical access to the module and put the mode switch into the monitor setting. In order to restore the module to operational mode you reinitialize the module and then return it to operational state. Security Policy Page 28 of 50 5 Keys 5 Keys For each type of key used by the nShield modules, the following section describes the access that an operator has to the keys. nShield modules refer to keys by their handle, an arbitrary number, or by its SHA-1 hash. 5.1 nShield Security Officer's key The nShield Security officer's key must be set as part of the initialization process. This is a public / private key pair that the nShield Security Officer uses to sign certificates to authorize key management and other secure operations. The SHA-1 hash of the public half of this key pair is stored in the module EEPROM . The public half of this key is included as plain text in certificates. The module treats anyone in possession of the private half of this key as the nShield Security Officer. If you use the standard tools supplied by nCipher to initialize the module, then this key is a DSA key stored as a key blob protected by a logical token on the Administrator Card Set. 5.2 Junior Security Officer's key Because the nShield Security Officer's key has several properties, it is good practice to delegate author- ity to one or more Junior Security Officers, each with authority for defined operations. To create a Junior Security Officer (JSO) the NSO creates a certificate signing key for use as their JSO key. This key must be protected by a logical token in the same manner as any other application key. Then to delegate authority to the JSO, the nShield Security Officer creates a certificate containing an Access Control List specifying the authority to be delegated and the hash of the JSO key to which the powers are to be delegated. The JSO can then authorize the actions listed in the ACL - as if they were the NSO - by presenting the JSO key and the certificate. If the JSO key is created with the Sign permission in its ACL, the JSO may delegate parts of their authority to another key. The holder of the delegate key will need to present the certificate signed by the NSO and the certificate signed by the JSO. If the JSO key only has UseAsCer- tificate permissions, then they cannot delegate authority. If you use the standard tools supplied by nCipher to initialize the module, then this key is a DSA key stored as a key blob protected by a logical token on the Administrator Card Set. 5.3 Long term signing key The nShield modules store one 160-bit and one 256-bit random number in the EEPROM . Security Policy Page 29 of 50 5 Keys The 160-bit number is combined with a discrete log group stored in the module firmware to produce a DSA key. The 256-bit number is used as the private exponent of a ECDSA key using the NIST P521 curve. It can be used to sign a module state certificate using the SignModuleState service and the public value retrieved by the non-cryptographic service GetLongTermKey. This is the only key that is not zeroized when the module is initialized. This key is not used to encrypt any other data. It only serves to provide a cryptographic identity for a mod- ule that can be included in a PKI certificate chain. nCipher may issue such certificates to indicate that a module is a genuine nCipher module. 5.4 Module signing key When the nShield module is initialized it automatically generates a 3072-bit DSA2 key pair that it uses to sign certificates. Signatures with this key use SHA-256. The private half of this pair is stored internally in EEPROM and never released. The public half is revealed in plaintext, or encrypted as a key blob. This key is only ever used to verify that a certificate was generated by a specified module. 5.5 Module keys Module keys are AES or Triple DES used to protect tokens. The nShield modules generates the first module key KM0 when it is initialized. This module key is guaranteed never to have been known outside this module. KM0 is an AES key. The nShield Security Officer can load further module keys. These can be generated by the module or may be loaded from an external source. Setting a key as a module key stores the key in EEPROM . Module keys can not be exported once they have been assigned as module keys. They may only be exported on a key blob when they are initially generated. 5.6 Logical tokens A logical token is an AES or Triple DES key used to protect key blobs. Logical tokens are associated with module keys. The key type depends on the key type of the module key. When you create a logical token, you must specify parameters, including the total number of shares, and the number or shares required to recreate the token, the quorum. The total number can be any integer between 1 and 64 inclusive. The quorum can be any integer from 1 to the total number. A logical token is always generated randomly, using the on-board random number generator. While loaded in the module logical tokens are stored in the object store. Tokens keys are never exported from the module, except on physical tokens or software tokens. When a logical token is exported the logical token - the key data plus the token parameters - is first encrypted with a module key. Then the encrypted token is split into shares using the Shamir Threshold Sharing algorithm, even if the total number of shares is one. Each share is then encrypted using a share key (which may require knowledge of a passphrase to derive - see Share keys) and written to a physical Page 30 of 50 Security Policy 5.7 Share keys token - a smart card - or a software token. Logical tokens can be shared between one or more physical token. The properties for a token define how many shares are required to recreate the logical token. Shares can only be generated when a token is created. The firmware prevents a specific share from being written more than once. Logical tokens are not used for key establishment. 5.7 Share keys A share key is used to protect a logical token share when they are written to a smart card or software token that is used for authentication. The share key is created by creating a message comprised of a secret prefix, Module key, Share number, smart card unique id and an optional 20 bytes supplied by the operator (expected to be the SHA-1 hash of a pass phrase entered into the application), and using this as the input to a PRNG to form a unique key used to encrypt the share - this is either an AES or Triple DES key depending on the key type of the logical token which is itself determined by the key type of the module key. This key is not stored on the module. It is recalculated every time share is loaded. The share data includes a MAC, if the MAC does not verify correctly the share is rejected. The share key is not used directly to protect CSPs nor is the Share Key itself considered a CSP. It is used for authentication only. The logical token needs to be reassembled from the shares using Shamir Threshold Sharing Scheme and then be decrypted using the module key. Only then can the logical token be used to decrypt application keys. 5.8 Impath keys An impath is a secure channel between two modules. To set up an impath two modules perform a key-exchange, using 3072-bit Diffie-Hellman. The Diffie Hellman operations has been validated in CVL Cert. #516. The CVL Cert. #516 is not fully compliant to SP 800-56A as the key derivation function has not been tested. Currently symmetric keys are AES or Triple DES. AES is used if both modules use 2.50.16 or later firm- ware, Triple DES is used where the other module is running older firmware. The four keys are used for encryption, decryption, MAC creation, MAC validation. The protocol ensures that the key Module 1 uses for encryption is used for decryption by module 2. All impath keys are stored as objects in the object store in SRAM. 5.8.1 nShield Remote Administration Token Secure Channel A Secure Channel is a secure channel between a Remote Administration token (Javacard) and a mod- ule. To set up a secure channel two modules perform a key-exchange, using Elliptical Curve Diffie-Hellman with P-521 curves, to negotiate a 256-bit AES encryption and MAC keys used to protect the channel. The key exchange parameters for each module are signed by that module’s signing key. Once the mod- ules have validated the signatures the module derives four symmetric keys for cryptographic operations using an approved SP 800-108 Key Derivation Function. Security Policy Page 31 of 50 5 Keys Currently symmetric keys are AES-256. The four keys are used for encryption, decryption, MAC cre- ation, MAC validation. The protocol ensures that the remote administration token key used for encryption is used for decryption by the module. All secure channel keys are stored as objects in the object store in SRAM. 5.9 Key objects Keys used for encryption, decryption, signature verification and digital signatures are stored in the mod- ule as objects in the object store in RAM. All key objects are identified by a random identifier that is spe- cific to the operator and session. All key objects are stored with an Access control List or ACL. The ACL specifies what operations can be performed with this key. Whenever an operator generates a key or imports a key in plain text they must specify a valid ACL for that key type. The ACL can be changed using the SetACL service. The ACL can only be made more permissive if the original ACL includes the ExpandACL permission. Key objects may be exported as key blobs if their ACL permits this service. Each blob stores a single key and an ACL. The ACL specifies what operations can be performed with this copy of the key. The ACL stored with the blob must be at least as restrictive as the ACL associated with the key object from which the blob was created. When you load a key blob, the new key object takes its ACL from the key blob. Working key blobs are encrypted under a logical token. Key objects may also be exported as key blobs under an archiving key. The key blob can be stored on the host disk or in the module NVRAM. Key objects can only be exported in plain text if their ACL permits this operation. If the module has been initialized to comply with FIPS 140-2 level 3 roles and services and key management the ACL for a private or secret key cannot include the export as plain service. An operator may pass a key reference to another operator - or to a SEE World - using the ticketing mechanism. The GetTicket mechanism takes a key identifier and returns a ticket. This ticket refers to the key identifier - it does not include any key data. A ticket can be passed as a byte block to the other operator who can then use the RedeemTicket service to obtain a key identifier for the same object that is valid for their session. As the new identifier refers to the same object the second operator is still bound by the original ACL. 5.10 Session keys Keys used for a single session are generated as required by the module. They are stored along with their ACL as objects in the object store. These may be of any supported algorithm. 5.11 Archiving keys It is sometimes necessary to create an archive copy of a key, protected by another key. Keys may be archived using: l Three-key Triple DES keys (used for unwrapping legacy keys and wrapping public keys only). l A combination of three-key Triple DES and RSA keys (unwrapping legacy keys only). In this case a random 3-Key Triple DES key is created which is used to encrypt working key and then this key is wrapped by the RSA key. l A key encapsulation mechanism using RSA. Page 32 of 50 Security Policy 5.12 Certificate signing keys 3072-bit RSA is used to establish a secret from which encryption keys are generated. The holders of the public and private halves of the RSA key must already exist in the module as operators. The keys generated are either AES or Triple-DES keys, for the purpose of protecting other keys. AES is used by default as of firmware version 2.50.16. (with Triple-DES available for legacy pur- poses). Once the key agreement process is complete, the module uses an additional keyed hashing pro- cess to protect the integrity of the nCore Key object to be archived, which is comprised of the key type, key value and Access Control List. This process uses HMAC SHA-256 by default. (with HMAC SHA-1 available for legacy purposes). l A key encapsulation mechanism using Diffie Hellman: 3072-bit Diffie-Hellman, which is allowed for use in the Approved mode, is used to establish a secret from which encryption keys are generated. Both parties in the Diffie-Hellman key agree- ment process exist in the module as operators. The keys generated are either AES or Triple-DES keys, for the purpose of protecting other keys. AES is used by default as of firmware version 2.50.16. (with Triple-DES available for legacy purposes). Please note that the Diffie-Hellman private key must be stored externally on the smartcard, if the archived keys are to be retrieved at a later time. Once the key agreement process is complete, the module uses an additional keyed hashing pro- cess to protect the integrity of the nCore Key object to be archived, which is comprised of the key type, key value and Access Control List. This process uses HMAC SHA-256 by default. (with HMAC SHA-1 available for legacy purposes). Although provided by the firmware, this option is currently not used by any nCipher tools. Other third party applications external to the module, may take advantage of this option, at the discretion of the developer. When a key is archived in this way it is stored with its ACL. When you generate or import the archiving key, you must specify the UseAsBlobKey option in the ACL. The archiving key is treated as any other key object. When you generate or import the key that you want to archive you must specify the Archival options in the ACL. This options can specify the hash(es) of the allowed archiving key(s). If you specify a list of hashes, no other key may be used. 5.12 Certificate signing keys The ACL associated with a key object can call for a certificate to be presented to authorize the action. The required key can either be the nShield Security Officer's key or any other key. Keys are specified in the ACL by an identifying key SHA-1 hash. The key type is also specified in the ACL although DSA is standard, any signing algorithm may be used, all nCipher tools use DSA. Certain services can require certificates signed by the nShield Security Officer. 5.13 Firmware Integrity Key All firmware is signed using a 3072-bit DSA2 key pair. Signatures with this key use SHA-256. Security Policy Page 33 of 50 5 Keys The module checks the signature before new firmware is written to flash. A module only installs new firm- ware if the signature decrypts and verifies correctly. The private half of this key is stored at nCipher. The public half is included in all firmware. The firmware is stored in flash memory when the module is switched off, this is copied to RAM as part of the start up procedure. 5.14 Firmware Confidentiality Key All firmware is encrypted using AES to prevent casual decompilation. The encryption key is stored at nCipher' offices and is in the firmware. The firmware is stored in flash memory when the module is switched off, this is copied to RAM as part of the start up procedure. 5.15 Master Feature Enable Key For commercial reasons not all devices in the nShield family of HSMs offer all services. Certain services must be enabled separately. In order to enable a service the operator presents a certificate signed by the Master Feature Enable Key. The Master Feature Enable Key is a DSA key pair. The private half of this key pair is stored at nCipher' offices. The public half of the key pair is included in the firmware. The firmware is stored in flash memory when the module is switched off, this is copied to RAM as part of the start up procedure. 5.16 DRBG Key DBRG stands for Deterministic Random Bit Generator. The module uses the CTR_DRBG from SP 800-90A with a 256-bit AES key. This key is seeded from the on board entropy source whenever the module is initialized and is reseeded according to SP 800- 90A with a further 1024 bits of entropy after every 2048-bytes of output. This key is only ever used by the DRBG. It is never exposed outside the module. The DRBG internal state is contained within the DRBG mechanism boundary and is not accessed by non-DRBG functions or by other instances of any DRBG. For CTR DRBG, the values of V and Key (SP 800-90A) are the ’secret values’ of the internal state. Page 34 of 50 Security Policy 6 Rules 6 Rules 6.1 Identification and authentication Communication with the modules is performed via a server program running on the host machine, using standard inter process communication, using sockets in UNIX operating systems, named pipes under Windows. In order to use the module the operator must first log on to the host computer and start an nShield enabled application. The application connects to the hardserver, this connection is given a client ID, a 32- bit arbitrary number. Before performing any service the operator must present the correct authorization. Where several stages are required to assemble the authorization, all the steps must be performed on the same con- nection. The authorization required for each service is listed in the section "Services available to each role" on page 12. An operator cannot access any service that accesses CSPs without first presenting a smart card, or software token. The nShield modules perform identity based authentication. Each individual operator is given a smart card that holds their authentication data - the logical token share - in an encrypted form. All operations require the operator to first load the logical token from their smart card. 6.1.1 Access Control Keys are stored on the host computer's hard disk in an encrypted format, known as a key blob. In order to load a key the operator must first load the token used to encrypt this blob. Tokens can be divided into shares. Each share can be stored on a smart card or software token on the computer's hard disk. These shares are further protected by encryption with a pass phrase and a module key. Therefore an operator can only load a key if they possess the physical smart cards containing suf- ficient shares in the token, the required pass phrases and the module key are loaded in the module. Module keys are stored in EEPROM in the module. They can only be loaded or removed by the nShield Security Officer, who is identified by a public key pair created when the module is initialized. It is not pos- sible to change the nShield Security Officer's key without re-initializing the module, which clears all the module keys, thus preventing access to all other keys. The key blob also contains an Access Control List that specifies which services can be performed with this key, and the number of times these services can be performed. These can be hard limits or per authorization limits. If a hard limit is reached that service can no longer be performed on that key. If a per- authorization limit is reached the operator must reauthorize the key by reloading the token. All objects are referred to by handle. Handles are cross-referenced to ClientIDs. If a command refers to a handle that was issued to a different client, the command is refused. Services exist to pass a handle between ClientIDs. 6.1.2 Access Control List All key objects have an Access Control List (ACL). The operator must specify the ACL when they gen- erate or import the key. The ACL lists every operation that can be performed with the key - if the Security Policy Page 35 of 50 6 Rules operation is not in the ACL the module will not permit that operation. In particular the ACL can only be altered if the ACL includes the SetACL service. The ACL is stored with the key when it is stored as a blob and applies to the new key object created when you reload the blob. The ACL can specify limits on operations - or groups of operations - these may be global limits or per authorization limits. If a global limit is exceeded then the key cannot be used for that operation again. If a per authorization limit is exceeded then the logical token protecting the key must be reloaded before the key can be reused. An ACL can also specify a certifier for an operation. In this case the operator must present a certificate signed by the key whose hash is in the ACL with the command in order to use the service. An ACL can also list Operator Defined actions. These actions do not permit any operations within the module, but can be tested with the CheckUserAction service. This enables SEE programs to make use of the ACL system for their own purposes. For example payShield uses this feature to determine the role of a Triple-DES key within EMV. An ACL can also specify a host service identifier. In which case the ACL is only met if the hardserver appends the matching Service name. This feature is designed to provide a limited level of assurance and relies on the integrity of the host, it offers no security if the server is compromised or not used. ACL design is complex - operators will not normally need to write ACLs themselves. nCipher provide tools to generate keys with strong ACLs. 6.1.3 Object re-use All objects stored in the module are referred to by a handle. The module's memory management func- tions ensure that a specific memory location can only be allocated to a single handle. The handle also identifies the object type, and all of the modules enforce strict type checking. When a handle is released the memory allocated to it is actively zeroed. 6.1.4 Error conditions If the module cannot complete a command due to a temporary condition, the module returns a command block with no data and with the status word set to the appropriate value. The operator can resubmit the command at a later time. The server program can record a log of all such failures. If the module encounters an unrecoverable error it enters the error state. This is indicated by the status LED flashing in the Morse pattern SOS. As soon as the unit enters the error state all processors stop pro- cessing commands and no further replies are returned. In the error state the unit does not respond to commands. Recorded error status codes may be queried without interaction with the module. The unit must be reset. 6.1.5 Security Boundary The physical security boundary is the plastic jig that contains the potting on both sides of the PCB. All cryptographic components are covered by potting. There is also a logical security boundary between the nCore kernel and the SEE. Some components are excluded from FIPS 140-2 validation as they are not security relevant see "Ports and Interfaces" on page 9. Page 36 of 50 Security Policy 6.1.6 Status information 6.1.6 Status information The module has a status LED that indicates the overall state of the module. The module also returns a status message in the reply to every command. This indicates the status of that command. There are a number of services that report status information. Where the module is fitted inside an nShield Connect, this information can be displayed on the LCD on the nShield Connect’s front panel. 6.2 Procedures to initialize a module to comply with FIPS 140-2 Level 3 The nShield enabled application must perform the following services, for more information refer to the nShield User Guide. Put the module into initialization mode by calling the Initialize Unit command. Use either the graphical user interface KeySafe or the command line tool new-world. Using either tool you must specify the number of cards in the Administrator Card Set and the encryption algorithm to use, Triple-DES or AES. To ensure that the module is in Level 3 mode you must Using Keysafe select the option “FIPS 140 Mode level 3 compliant” = Yes ; or Using new-world specify the -F flag in the command line The tool prompts you to insert cards and to enter a pass phrase for each card. When you have created all the cards, put the module back into operational mode as described in Chapter 4. 6.2.1 Verifying the module is in level 3 mode An operator can verify that the module is operating in level 3 mode by verifying the following: Keysafe displays “Strict FIPS 140-2 Level 3 = Yes” in the information panel for that module. The command line tool nfkminfo include StrictFIPS in the list of flags for the module 6.3 Return a module to factory state 1. Put the mode switch into the initialization position Pull the Initialization pin high and restart the mod- ule. 2. Use the Initialise command to enter the Initialization state. 3. Load a random value to use as the hash of the nShield Security Officer's key. 4. Set nShield Security Officer service to set the nShield Security Officer's key and the operational policy of the module. 5. Put the mode switch into the operational position Pull the Initialization pin low and restart the mod- ule. Security Policy Page 37 of 50 6 Rules 6. After this operation the module must be initialized correctly before it can be used in a FIPS approved mode. Placing the module in factory state: l destroys any loaded Logical tokens, Share Keys, Impath keys, Key objects, Session keys l erases the current Module Signing Key and generates a fresh one. l erases all current Module Keys, except the Well Known Module Key l Generates a new Module Key Zero l sets nShield Security Officer's key to a known value l this prevents the module from loading any keys stored a key blobs as it no longer possesses the decryption key. Returning the module to factory state does not erase the Firmware Confidentiality Key, the Long Term Signing Key or the public halves of the Firmware Integrity Key, of the Master Feature Enable Key: as these provide the cryptographic identity of the module and control loading firmware. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. 6.4 Create a new operator 1. Create a logical token. 2. Write one or more shares of this token onto software tokens. 3. For each key the operator will require, export the key as a key blob under this token. 4. Give the operator any pass phrases used and the key blob. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. 6.5 Authorize the operator to create keys 1. Create a new key, with an ACL that only permits UseAsCertificate. 2. Export this key as a key blob under the operator's token. 3. Create a certificate signed by the nShield Security Officer's key that: l includes the hash of this key as the certifier. l authorizes the action OriginateKey depending on the type of key required. 4. Give the operator the key blob and certificate. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. Page 38 of 50 Security Policy 6.6 Authorize an operator to act as a Junior Security Officer 6.6 Authorize an operator to act as a Junior Security Officer 1. Generate a logical token to use to protect the Junior Security Officer's key. 2. Write one or more shares of this token onto software tokens 3. Create a new key pair, 4. Give the private half an ACL that permits Sign and UseAsSigningKey. 5. Give the public half an ACL that permits ExportAsPlainText 6. Export the private half of the Junior Security Officer's key as a key blob under this token. 7. Export the public half of the Junior Security Officer's key as plain text. 8. Create a certificate signed by the nShield Security Officer's key includes the hash of this key as the certifier l authorizes the actions GenerateKey, GenerateKeyPair l authorizes the actions GenerateLogicalToken, WriteShare and MakeBlob, these may be limited to a particular module key. 9. Give the Junior Security Officer the software token, any pass phrases used, the key blob and cer- tificate. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. 6.7 Authenticate an operator to use a stored key 1. Use the LoadLogicalToken service to create the space for a logical token. 2. Use the ReadShare service to read each share from the software token. 3. Use the LoadBlob service to load the key from the key blob. The operator can now perform the services specified in the ACL for this key. To assume nShield Security Officer role load the nShield Security Officer's key using this procedure. The nShield Security Officer's key can then be used in certificates authorising further operations. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. 6.8 Authenticate an operator to create a new key 1. If you have not already loaded your operator token, load it as above. 2. Use the LoadBlob service to load the authorization key from the key blob. 3. Use the KeyId returned to build a signing key certificate. 4. Present this certificate with the certificate supplied by the nShield Security Officer with the Gen- erateKey, GenerateKeyPair or MakeBlob command. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. Security Policy Page 39 of 50 7 Physical security 7 Physical security All security critical components of the module are covered by epoxy resin. The module hardness testing was only performed at a single temperature and no assurance is provided for Level 3 hardness conformance at any other temperature. The module has a clear button. Pressing this button puts the module into the self-test state, clearing all stored key objects, logical tokens and impath keys and running all self-tests. The long term security crit- ical parameters, nShield Security Officer's key, module keys and module signing key can be cleared by returning the module to the factory state, as described above. 7.1 Checking the module To ensure physical security, make the following checks regularly: l Examine the epoxy resin security coating for obvious signs of damage. l The smart card reader is directly plugged into the module or into a port provided by any appliance in which the module is integrated and the cable has not been tampered with. Where the module is in an appliance the security of this connection may be protected by the seals or other tamper evid- ence provided by the appliance. Security Policy Page 40 of 50 8 Strength of functions 8 Strength of functions 8.1 Object IDs Connections are identified by a ClientID, a random 32 bit number. Objects are identified by an ObjectID again this is a random 32 bit number. In order to randomly gain access to a key loaded by another operator you would need to guess two ran- dom 32 bit numbers. There are 264 possibilities therefore meets the 1 in a 106 requirement. The module can process about 216 commands per minute - therefore the chance of succeeding within a minute is 216 / 264 = 2-48 which is significantly less than the required chance of 1 in 105 (~2-17) 8.2 Tokens If an operator chooses to use a logical token with only one share, no pass phrase and leaves the smart card containing the share in the slot then another operator could load the logical token. The module does not have any idea as to which operator inserted the smart card. This can be prevented by: l not leaving the smart card in the reader l if the smart card is not in the reader, they can only access the logical token by correctly guessing the ClientID and ObjectID for the token. l requiring a pass phrase When loading a share requiring a pass phrase the operator must supply the SHA-1 hash of the pass phrase. The hash is combined with a module key, share number and smart card id to recre- ate the key used to encrypt the share. If the attacker has no knowledge of the pass phrase they would need to make 280 attempts to load the share. The module enforces a five seconds delay between failed attempts to load a share. l requiring more than one share If a logical token requires shares from more than one smart card the attacker would have to repeat the attack for each share required. Logical tokens are either 3-Key Triple DES keys or 256-bit AES keys. Shares are encrypted under a combination of a module key, share number and card ID. If you could construct a logical token share of the correct form without knowledge of the module key and the exact mechanism used to derive the share key the chance that it would randomly decrypt into a valid token are 2-168 or 2-256. 8.3 Key Blobs Key blobs are used to protect keys outside the module. There are two formats of blob - indirect and dir- ect. If the module is configured with AES module key, the blobs used for token and module key protected keys take a 256 bit AES key and a nonce and uses SHA-1 to derive a AES encryption key, used for encryption and a HMAC SHA-1 key, used for integrity. Security Policy Page 41 of 50 8 Strength of functions If the module is configured with Triple DES module key, the blobs used for token and module key pro- tected keys use Triple DES and SHA-1 for encryption and integrity. If the module is initialized in a fresh security world, the blobs used for key-recovery and for pass-phrase recovery take the public half of a 3072-bit RSA key and a nonce as the input, and uses SHA-256 to derive a 256-bit AES encryption key, used for encryption and a HMAC SHA-256 key, used for integrity. If the module is enrolled into an old security world created before the release of 2.50.16 firmware, the blobs used for key-recovery and for pass-phrase recovery take the public half of a 1024-bit RSA key and a nonce as the input, and uses SHA-1 to derive a 3-Key triple-DES or 256-bit AES encryption key - depending on the option selected for the module key - and a HMAC SHA-1 key, used for integrity. This mode of operation is non-approved. The firmware also supports key blobs based on an integrated encryption scheme using Diffie Hellman to establish a master secret and HMAC SHA-256 for integrity and AES in CBC mode for encryption, or HMAC SHA-1 for integrity and Triple DES in CBC mode for encryption. However, this option is currently not used by any nCipher tools. All schemes used in SP 800-131A compliant security worlds offer at least 112-bits of security. Legacy security worlds, which offer at least 80-bits of security, operate in non-approved mode. 8.4 Impaths Impaths protect the transfer of encrypted shares between modules. When negotiating an Impath, provided both modules use 2.50.16 or later firmware, the module verifies a 3072-bit DSA signatures with SHA-256 hashes to verify the identity of the other module. It then uses 3072-bit Diffie-Hellman key exchange to negotiate a 256-bit AES encryption and MAC keys used to pro- tect the channel. This provides a minimum of 128-bits of security for the encrypted channel. Otherwise, both modules use 1024-bit DSA signatures to verify the identity of the other module. Then they perform a 1024-bit Diffie-Hellman key exchange to negotiate a 3-Key triple-DES encryption keys used to protect the channel. This provides a minimum of 80-bits of security for the encrypted channel. The module will be operating in a non-approved mode when 1024-bit DSA signatures are used. The shares sent over the channel are still encrypted using their share key, decryption only takes place on the receiving module. 8.4.1 nShield Remote Administration Token Secure Channel The Secure Channel protects the transfer of encrypted shares between a Remote Administration token and module. When negotiating a Secure Channel the module verifies a ECDSA P-521 signature with SHA-512 hashes to verify the identity of the other module. It then uses ECDH key exchange to negotiate 256-bit AES encryption and MAC keys used to protect the channel. This provides a minimum of 256-bits of security for the encrypted channel. Page 42 of 50 Security Policy 8.4.2 KDP key provisioning The shares sent over the channel are still encrypted using their share key, decryption only takes place on the receiving module. 8.4.2 KDP key provisioning The KDP protocol used to transfer keys from a module to a micro HSM uses 1024-bit DSA signatures to identify the end point and a 2048-bit Diffie-Hellman key exchange to negotiate the Triple-DES or AES keys used to encrypt the keys in transit providing a minimum of 100-bits of security for the encrypted channel. 8.4.3 Derived Keys The nCore API provides a range of key derivation and wrapping options that an operator can choose to make use of in their protocols. For any key, these mechanisms are only available if the operator explicitly enabled them in the key's ACL when they generated or imported the key. The ACL can specify not only the mechanism to use but also the specific keys that may be used if these are known. Mechanism Use Notes Key Splitting Splits a symmetric key into separate com- ponents for export Components are raw byte blocks. SSL/TLS master key derivation Setting up an SSL/TLS session Non-compliant. The protocols SSL, TLS shall not be used when operated in FIPS mode. In particular, none of the keys derived using this key derivation function can be used in the Approved mode. Key Wrap- ping Encrypts one key object with another to allow the wrapped key to be exported. May use approved or allowed mechanisms that accept a byteb- lock. The operator must ensure that they chose a wrapping key that has an equivalent strength to the key being transported. The operator must ensure that they chose a wrapping key that has an equivalent strength to the key being transported. Key wrapping using Triple-DES is non-compliant. Secure Channel Key Deriv- ation Derivation of encryption and authentication keys for the secure channel NIST SP 800-108 KDF Security Policy Page 43 of 50 8 Strength of functions In level 3 mode you can only use key wrapping and key establishment mechanisms that use approved algorithms. Page 44 of 50 Security Policy 9 Self Tests 9 Self Tests When power is applied to the module it enters the self test state. The module also enters the self test state whenever the unit is reset, by pressing the clear button or by sending the Clear Unit command. In the self test state the module clears the main RAM, thus ensuring any loaded keys or authorization information is removed and then performs its self test sequence, which includes: l An operational test on hardware components l An integrity check on the firmware, verification of a SHA-1 hash l A statistical check on the random number generator l Known answer checks as required by FIPS 140-2. l Verification of a MAC on EEPROM contents to ensure it is correctly initialized. This sequence takes a few seconds after which the module enters the Pre-Maintenance, Pre-Initialization, Uninitialized or Operational state; depending on the position of the mode switch and the validity of the EEPROM contents. The module also runs continuous random number generator tests on the hardware entropy source and the approved AES-256 based DRBG. If either fail, it enters the error state. When firmware is updated, the module verifies a DSA signature on the new firmware image before it is written to flash. The module also performs pairwise-consistency checks when generating asymmetric key-pairs. In the error state, the module’s LED repeatedly flashes the Morse pattern SOS, followed by a status code indicating the error. All other inputs and outputs are disabled. 9.1 Firmware Load Test When new firmware is loaded, the module reads the candidate image into working memory. It then per- forms the following tests on the image before it replaces the current application: l The image contains a valid signature which the module can verify using the Firmware Integrity Key l The image is encrypted with the Firmware Confidentiality Key stored in the module. l The Version Security Number for the image is at least as high as the stored value. Only if all three tests pass is the new firmware written to permanent storage. Updating the firmware clears the nShield Security Officer's key and all stored module keys. The module will not re-enter operational mode until the administrator has correctly re-initialized it. Note that if the module's firmware is updated to a different version, this results in the loss of the current CMVP validation of the module. Security Policy Page 45 of 50 10 Supported Algorithms 10 Supported Algorithms 10.1 FIPS approved and allowed algorithms: 10.1.1 Symmetric Encryption 10.1.1.1 AES Certificate #3420 ECB, CBC, GCM (externally generated IVs are non-compliant) and CMAC modes 10.1.1.2 Triple-DES Certificate #1931 ECB and CBC modes (encryption with two-key Triple DES is non-compliant) 10.1.2 Hashing and Message Authentication 10.1.2.1 AES CMAC AES Certificate #3420 10.1.2.2 AES GMAC AES Certificate #3420 10.1.2.3 HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384 and HMAC SHA-512 Certificate #2178 10.1.2.4 SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 Certificate #2826 10.1.2.5 Triple-DES MAC Triple-DES Certificate #1931 vendor affirmed (MAC generation with two-key Triple DES is non-compliant) 10.1.3 Signature 10.1.3.1 DSA Certificate #964 FIPS 186-4: Signature generation and verification (Signature generation is non-compliant for SHA-1, and for keys less than 2,048 bits.) Modulus 1024-bits, Sub-group 160-bits Modules 2048-bits, Sub-group 224-bits Modules 2048-bits, Sub-group 256-bits Modules 3072-bits, Sub-group 256-bits Security Policy Page 46 of 50 10 Supported Algorithms 10.1.3.2 ECDSA Certificate #695 FIPS 186-4: Signature generation and verification (Signature generation is non-compliant for SHA-1, and for values of n less than 224 bits, and for the curves P-192 K-163 and B-163.) P-192 P-224 P-256 P-384 P-521 K-163 K-233 K-283 K-409 K-571 B-163 B-233 B-283 B-409 and B-571 Curves 10.1.3.3 RSA Certificate #1752 FIPS 186-4: Key generation; RSASSA PKCS1_V1_5 and RSASSA-PSS signature generation and veri- fication (Signature generation with SHA-1 or keys sizes 1024 bits or 4096 bits is non-compliant.) Modulus 1024 - 4096 bits with SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 10.1.4 Key Establishment 10.1.4.1 Diffie-Hellman Diffie-Hellman (CVL Cert. #516, key agreement; key establishment methodology provides between 112 and 256 bits of encryption strength; non-compliant less than 112 bits of encryption strength) 10.1.4.2 Elliptic Curve Diffie-Hellman EC Diffie-Hellman (CVL Cert. #532, key agreement; key establishment methodology provides between 112 and 256 bits of encryption strength; non-compliant less than 112 bits of encryption strength) 10.1.4.3 RSA RSA (key wrapping, key establishment methodology provides between 112 and 256 bits of encryption strength; non-compliant less than 112 bits of encryption strength) 10.1.4.4 AES KTS (Cert. #3446, key wrapping; key establishment methodology provides between 128 and 256 bits of encryption strength) 10.1.4.5 EC-MQV ECMQV (key agreement; key establishment methodology provides between 112 and 256 bits of encryp- tion strength; non-compliant less than 112 bits of encryption strength) 10.1.5 Key Derivation SP 800-108 Key Derivation #56 in Counter Mode. 10.1.6 Other 10.1.6.1 Deterministic Random Bit Generator Certificate #825 SP 800-90A using Counter mode of AES-256 Page 47 of 50 Security Policy 10.2 Non-FIPS approved algorithms 10.2 Non-FIPS approved algorithms Algorithms marked with an asterisk are not approved by NIST. If the module is initialized into the approved mode of operation, these algorithms are disabled. 10.2.1 Symmetric l Aria* l Arc Four (compatible with RC4)* l Camellia* l CAST-256 (RFC2612)* l DES* l SEED (Korean Data Encryption Standard) - requires Feature Enable activation* 10.2.2 Asymmetric l El Gamal * (encryption using Diffie-Hellman keys) l KCDSA (Korean Certificate-based Digital Signature Algorithm) - requires Feature Enable activ- ation* l RSA encryption and decryption* (Same RSA implementation as used for key wrapping) 10.2.3 Hashing and Message Authentication l HAS-160 - requires Feature Enable activation* l MD5 - requires Feature Enable activation* l RIPEMD 160* l Tiger* l HMAC (MD5, RIPEMD160, Tiger)* 10.2.4 Key wrapping/Key transport Triple-DES CBC mode* (key wrapping; non-compliant) 10.2.5 Non-deterministic entropy source Non-deterministic entropy source, used to seed approved random bit generator. 10.2.6 Other SSL*/TLS master key derivation (non-compliant). The protocols SSL, TLS shall not be used when oper- ated in FIPS mode. In particular, none of the keys derived using this key derivation function can be used in the Approved mode. PKCS #8 padding*. Security Policy Page 48 of 50 Contact Us Contact Us Web site: https://www.ncipher.com Support: https://help.ncipher.com Email Support: support@ncipher.com Online documentation: All of our user guides can be accessed via the Support Portal You can also contact our Support team by telephone, using the following numbers: Europe, Middle East, and Africa United Kingdom: +44 1223 723 711 One Station Square Cambridge CB1 2GA Americas Toll Free: +1 833 425 1990 Fort Lauderdale: +1 954 953 5229 Sawgrass Corporate Center, Building A 13800 Northwest 14th Street, Suite 130, Sunrise, FL 33323 Asia Pacific Hong Kong: +852 3461 3088 10/F, V-Point, 18 Tang Lung Street Causeway Bay Hong Kong Security Policy Page 49 of 50 About nCipher Security Today’s fast moving digital environment enhances customer satisfaction, gives competitive advantage and improves operational efficiency. It also multiplies the security risks. nCipher Security, a leader in the general purpose hardware security module (HSM) market, empowers world-leading organizations by delivering trust, integrity and control to their business critical information and applications. Our cryptographic solutions secure emerging technologies – cloud, IoT, blockchain, digital payments – and help meet new compliance mandates, using the same proven technology that global organizations depend on today to protect against threats to their sensitive data, network communications and enterprise infrastructure. We deliver trust for your business critical applications, ensuring the integrity of your data and putting you in complete control – today, tomorrow, at all times. www.ncipher.com