TM nShield Security Policy CI PHE R nShield F3 4000, nShield F3 2000, nShield F3 500, nShield F3 2000 for NetHSM, nShield F3 500 for NetHSM in FIPS 140-2 level 3 mode TM CI PHE R Version: 2.2.3 Date: 3 June 2008 © Copyright 2008 nCipher Corporation Limited, Cambridge, United Kingdom. Reproduction is authorised provided the document is copied in its entirety without modification and including this copyright notice. nCipherTM, nForceTM, nShieldTM, nCoreTM, KeySafeTM, CipherToolsTM, CodeSafeTM, SEETM and the SEE logo are trademarks of nCipher Corporation Limited. nFast® and the nCipher logo are registered trademarks of nCipher Corporation Limited. All other trademarks are the property of the respective trademark holders. nCipher Corporation Limited makes no warranty of any kind with regard to this information, including, but not limited to, the implied warranties of merchantability and fitness to a particular purpose. nCipher Corporation Limited shall not be liable for errors contained herein or for incidental or consequential damages concerned with the furnishing, performance or use of this material. Patents UK Patent GB9714757.3. Corresponding patents/applications in USA, Canada, South Africa, Japan and International Patent Application PCT/GB98/00142. Version: 2.2.3 Date: 03 June 2008 2008 nCipher Corporation Limited, Cambridge, United Kingdom. nShield Security Policy v 2.2.3 2 Contents TM CI PHE R Chapter 1: Purpose 5 Introduction 5 Module Ports and Interfaces 9 Excluded Components 10 Environmental Failure Protection 11 Roles 12 Unauthorised 12 User 12 nCipher Security Officer 12 Junior Security Officer 13 Services available to each role 14 Keys 30 Security Officer's key 30 Junior Security Officer's key 30 Long term signing key 31 Module signing key 31 Module keys 31 Logical tokens 31 Share Key 32 Impath keys 32 Key objects 33 Session keys 33 Archiving keys 34 Certificate signing keys 34 Firmware Integrity Key 34 Firmware Confidentiality Key 35 nCipher Master Feature Enable Key 35 Rules 36 Identification and authentication 36 Procedures to initialise a module to comply with FIPS 140-2 Level 3 38 Procedures to initialise a module to comply with FIPS 140-2 Level 2 39 Operating a level 2 module in FIPS mode 40 To return a module to factory state 40 To create a new operator 40 To authorize the operator to create keys 41 To authorize an operator to act as a Junior Security Officer 41 To authenticate an operator to use a stored key 42 To authenticate an operator to create a new key 42 Physical security 43 nShield Security Policy 2.2.3 3 TM CI PHE R Checking the module 43 Strength of functions 44 Attacking Object IDs 44 Attacking Tokens 44 Key Blobs 45 Impaths 45 KDP key provisioning 45 Derived Keys 45 Self Tests 47 Firmware Load Test 47 Supported Algorithms 49 FIPS approved algorithms: 49 Non-FIPS approved algorithms 50 nCipher addresses 52 nShield Security Policy 2.2.3 4 Chapter 1: Purpose CI PHE R TM Introduction nShield tamper resistant Hardware Security Modules are multi-tasking hardware modules that are optimized for performing modular arithmetic on very large integers. The modules also offer a complete set of key management protocols. The nShield Hardware Security Modules are defined as multi-chip embedded cryptographic modules as defined by FIPS PUB 140-2. NVRAM RTC SEE Potting EMC Accelerator Crypto level Overall Unit ID Model Number nShield F3 4000 nC4033P-4K0 Yes Optional Yes B Broadcom 3 4851 nShield F3 2000 nC4033P-2K0 Yes Optional Yes B Broadcom 3 4851 nShield F3 500 nC4133P-500 Yes Optional Yes B Broadcom 3 4851 nShield F3 2000 for nC4033P-2K0N Yes Optional Yes B Broadcom 3 NetHSM 4851 nShield F3 500 for nC4133P-500N Yes Optional Yes B Broadcom 3 NetHSM 4851 The units are identical in operation and only vary in the processing speed and the support software supplied. All modules are now supplied at build standard "N" to indicate that they meet the latest EU regulations regarding ROHS. This release introduces the nShield F3 500. This model replaces the nShield F3 500 which cannot be produced due to the EU Reduction of Hazardous Substances directive. To determine which module you have examine the PCI interface. If the module has a 64-bit interface it is covered by this certificate. The nShield F3 2000 is fitted inside the nCipher NetHSM 2000 and provides all the security functions for this appliance. The nShield F3 500 is fitted inside the nCipher NetHSM 500. nShield Security Policy 2.2.3 5 TM CI PHE R Introduction The NetHSM is shown below. The following figure shows the module mounted inside the NetHSM nCipher also supply modules to third party OEM vendors for use in a range of security products. The module runs 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 NewEnquiry service which reports the version of firmware currently loaded. nShield Security Policy 2.2.3 6 TM CI PHE R Introduction The validated firmware versions is 2.33.60. The module can be initialised to comply with the requirements for Roles and Services at either level 2 or level 3 · When initialized in level 2 mode the firmware version is 2.33.60-2 (level 2 mode) and the level 2 certificate applies. · When initialized in level 3 mode the firmware version is 2.33.60-3 (level 3 mode) and the level 3 certificate applies. The initialization parameters are reported by the NewEnquiry and SignModuleState 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: http://www.nCipher.com. nShield modules have on-board non-volatile memory. There are services that enable memory to be allocated as files. Files have Access Control Lists that determine what operations can be performed on their contents. nShield modules have on-board Real-time clock. nShield modules include a technology called, the Secure Execution Environment (SEE). This enables operators to load a SEE machine. A SEE machine is operator written code that implements a specific Software Interrupt interface. This enables operators to implement non- cryptographic code in a protected memory space on the module that is outside the logical security boundary. SEE code is executed in a protected environment. Whenever the SEE machine is running the nCore kernel is locked. Whenever the nCore kernel is active the SEE machine is locked. The SEE machine is excluded from the requirements of FIPS PUB 140-2. While the SEE machine is active the module is running in a non-FIPS mode. The SEE machine has no direct access to objects stored on the module. In order to use cryptographic functions it must submit a job to the nCore kernel using the nCore API. The testing shows that the interface between the nCore kernel and the SEE machine is secure and that a malicious SEE machine cannot gain access to objects protected by the nCore kernel. Before a operator can send commands to the SEE machine they must create an instance called a SEE World. A SEE World is treated as a separate operator by the module and must present the correct authentication before they can submit commands to the nCore kernel. nShield modules are supplied with the SEE functions disabled. In order to use these functions the customer must purchase a feature-enable certificate enabling the functions for a specific module. The SEE feature is export controlled and therefore is not available in some territories. nShield Security Policy 2.2.3 7 TM CI PHE R Introduction All payShield modules are supplied with a SEE licence that enables them to run the nCipher Secure payments Processing library which supports a number of payments specific algorithms and functions which provide support for 3-D Secure, EMV (Europay, MasterCard, Visa) and PIN processing. The module can be connected to a computer running one of the following operating systems: · Windows · Solaris · HP-UX · AIX · Linux x86 · FreeBSD x86 Windows XP Professional SP2 and a Debian Linux distribution with kernel version 2.2.26 were used to test the module for this validation. nShield Security Policy 2.2.3 8 TM CI PHE R Module Ports and Interfaces Module Ports and Interfaces The following table lists the logical interfaces to the module and how they map to physical interfaces. Logical Physical Interface Interface Data In PCI bus, Serial Interface, 16-way header Data Out PCI bus, Serial Interface, 16-way header Control In PCI bus, Temperature Sensor, PSU Monitor, Reset Switch, Mode Switch, 16-way header Status Out PCI bus, 16-way header,LED Power PCI bus nShield Security Policy 2.2.3 9 TM CI PHE R Excluded Components Excluded Components The following components are excluded from FIPS 140-2 validation: · Standard 64-bit PCI interface · 9-way D-type Serial connector · Mode switch · Reset switch · Status LED · 16-way header · DIP switches · SEE machine · Heat sinks nShield Security Policy 2.2.3 10 TM CI PHE R Environmental Failure Protection Environmental Failure Protection The nShield module offers protection from over and under voltage and over and under temperature. The module is designed to operate in a PCI bus drawing power from the PCI 5V rail. If the power on this rail fall below about 4.5V the PSU monitor shuts the module down, clearing all loaded keys. The PSU monitor will not allow the module to restart until sufficient voltage is applied, going through the standard power on procedure, including clearing all memory and performing all self tests. If the voltage is increased to around 8V the power supply will continue to perform normally: drawing proportionally less current. Above 8.5V the power supply's over voltage protection device will trigger and all input power will be shorted to earth. This protect the module's cryptographic circuitry from damage. However, as the power supply is potted, it cannot be replaced and the module is therefore irreversibly destroyed. The module has an on-board temperature sensor mounted close to the processors. If this sensor reaches seventy degrees centigrade or drops to zero degrees centigrade the module is put into its error state. The module turns off all communication on external buses and the Status LED flashes the Morse pattern SOS T (... --- ... -). The module can only be reset from an error state by turning the power supply off and back on - which for a PCI module means turning off power to the host computer. The module performs all normal power on procedures including clearing all memory and performing all self tests. nShield Security Policy 2.2.3 11 TM CI PHE R Roles Roles The module defines the following roles: Unauthorised All connections are initially unauthorized. if the module is initialized in level 3 mode, an unauthorized operator is restricted to status commands, and commands required to complete authorization protocol. User An operator enters the user role by providing the required authority to carry out a service. The exact accreditation required to preform 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 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 a Security Officer authorizing the action. Some actions including writing tokens always require a certificate. nCipher Security Officer The nCipher Security Officer (NSO) is responsible for overall security of the module. The nCipher 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 nCipher 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 KeyID for this key to authorize a command. nShield Security Policy 2.2.3 12 TM CI PHE R Roles Junior Security Officer Where the nCipher Security Officer want to delegate responsibility for authorizing an action they can create 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 KeyID of this key, and if required the certificate signed by KNSO that delegates authority to the key, to authorize a command. 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. nShield Security Policy 2.2.3 13 TM CI PHE R Services available to each role Services available to each role For more information on each of these services refer to the nCipher Developer's Guide and nCipher Developer's Reference. nShield Security Policy 2.2.3 14 TM CI PHE R Services available to each role The following services provide authentication or cryptographic functionality. The functions available depend on whether the operator is in the unauthenticated role, the user or junior security officer (JSO) roles, or the nCipher Security Officer (NSO) role. 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. Note Algorithms marked with an asterisk are not approved by NIST. If the module is initialised in its level 3 mode, these algorithms are disabled. If module is initialized in level 2 mode, the algorithms are available. However, if you choose use them, the module is not operating in FIPS approved mode. 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 / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Bignum Yes Yes Yes Performs simple mathematical No access to Operation operations. keys or CSPs Change Share No pass pass Updates the pass phrase used to Sets the pass [SHA-1 and PIN phrase phrase encrypt a token share. The pass phrase for a AES or Triple phrase supplied by the operator share, uses DES] is not used directly, it is first module key, hashed and then combined with uses share key, the module key. To achieve this uses module the command decrypts the key, creates existing share using the old share share key, uses key derived from old pass new share key, phrase, module key and smart exports card identity. It then derives a encrypted new share key based on new pass share, erases phrase, module key and smart old share card identity, erases old share from smart card and writes a new share encrypted under the new share key. nShield Security Policy 2.2.3 15 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Channel Open No handle, handle, Opens a communication channel Uses a key AES, DES*, ACL ACL which can be used for bulk object Triple DES, encryption or decryption. Arc Four*, Channels using DES* or Triple Aria*, DES in CBC mode use the Camellia*, Broadcom 5821 to perform the SEED*, encryption. Channel No handle handle Performs encryption / decryption Uses a key AES, DES*, Update on a previously opened channel. object Triple DES, The operation and key are Arc Four*, specified in ChannelOpen. Aria*, Camellia*, SEED*, CheckUserAC No handle handle Determines whether the ACL Uses a key L associated with a key object object allows a specific operator defined action. Clear Unit Yes Yes Yes Zeroises all loaded keys, tokens Zeroizes All and shares. Clear Unit does not objects. erase long term keys, such as module keys. Create Buffer No cert cert Allocates an area of memory to Uses a key AES, DES*, [handle [handle load data. If the data is object Triple DES, ] ] encrypted, this service specifies Arc Four*, the encryption key and IV used. Aria*, This service is feature enabled. Camellia*, The decrypt operation is SEED* performed by LoadBuffer Create SEE No handle handle Creates a SEE World, passing in No access to World cert cert the initialization data stored in a keys or CSPs buffer. This command checks the DSA signatures on the buffer using the public key provided. It also specifies whether debugging is allowed or not. Enabling debugging requires a certificate from the nCipher Security Officer. nShield Security Policy 2.2.3 16 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Decrypt No handle, handle, Decrypts a cipher text with a Uses a key AES, DES*, ACL ACL stored key returning the plain object Triple DES, text. Arc Four*, Aria*, Camellia*, SEED*, Diffie- Hellman, ECDH, RSA*, ElGamal*, KCDSA* Derive Key No handle, handle, The nCipher DeriveKey service Uses a key AES, RSA, ACL ACL provides functions that the FIPS object, create a EC-DH, 140-2 standard describes as key new key EC_MQV, wrapping and split knowledge - object. Triple DES, it does not provide key derivation PKCS #8*, in the sense understood by FIPS TLS key 140-2. Creates a new key object derivation, from a variable number of other XOR, DLIES keys already stored on the (D/H plus module and returns a handle for Triple DES or the new key. This service can be D/H plus used to split, or combine, AES), Aria*, encryption keys. Arc Four*, This service is used to wrap keys Camellia*, according to the nCipher KDP so DES*, SEED*, that a key server can distribute the wrapped key to micro-HSM devices. Destroy No handle handle Removes an object, if an object Erases a All has multiple handles as a result Impath, of RedeemTicket service, this SEEWorld, removes the current handle. logical token, or any key object. Duplicate No handle, handle, Creates a second instance of a Creates a new All ACL ACL key object with the same ACL key object. and returns a handle to the new instance. Encrypt No handle, handle, Encrypts a plain text with a Uses a key AES, DES*, ACL ACL stored key returning the cipher object Triple DES, text. RSA*, ElGamal*, Arc Four*, Aria*, Camellia*, SEED*, KCDSA* nShield Security Policy 2.2.3 17 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Erase File level 2 cert yes Removes a file, but not a logical No access to only token, from a smart card or keys or CSPs software token. Erase Share level 2 cert yes Removes a share from a smart Erases a share only card or software token. Existing Client yes yes yes Starts a new connection as an No access to existing client. keys or CSPs Export No handle, handle, If the unit is operating in FIPS Exports a Level 2 mode - ACL ACL mode this operation is only [public] key Any key type available for public keys - see object. Level 3 mode - Operating a level 2 module in RSA, DSA, FIPS mode on page 40. ECDSA, If the unit has been initialized to Diffie- comply with FIPS 140-2 level 3 Hellman, El- roles and services and key Gamal and management, this service is only ECDH public available for public keys. keys Feature Enable No cert cert Enables a service. Uses the [DSA] This requires a certificate signed public half of by the nCipher Master Feature the nCipher Enable key. Master Feature Enable Key Firmware yes yes yes Reports firmware version. No access to HMAC Authenticate Performs a zero knowledge keys or CSPs challenge response protocol based on HMAC that enables a operatr to ensure that the firmware in the module matches the firmware supplied by nCipher. The protocol generates a random value to use as the HMAC key. Foreign Token No handle handle Sends an ISO-7816 command to Uses a bypass Command a smart card over the channel channel. (Bypass) opened by ForeignTokenOpen. Foreign Token No FE, FE Opens a channel to foreign smart Creates a Open (Bypass) cert card that accepts ISO-7816 bypass commands. This service cannot channel. 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. nShield Security Policy 2.2.3 18 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User FormatToken level 2 cert yes Formats a smart card or software May use a [AES, Triple only token ready for use. module key to DES] create challenge response value Generate Key level 2 cert yes Generates a symmetric key of a Creates a new AES, Triple only given type with a specified ACL symmetric key DES, Arc and returns a handle. object. Sets the Four*, Aria*, Optionally returns a certificate ACL and Camellia*, containing the ACL. Application DES*, SEED*. data for that [DSA] object. Optionally uses module signing key and exports the key generation certificate. Generate Key level 2 cert yes Generates a key pair of a given Creates two Diffie- Pair only type with specified ACLs for new key Helman, DSA, each half or the pair. Performs a objects. Sets ECDSA, EC- pair wise consistency check on the ACL and DH, EC-MQV, the key pair. Returns two key Application RSA, handles. data for those ElGamal*, Optionally returns certificates objects. KCDSA* [DSA] containing the ACL. Optionally uses module signing key and exports two key generation certificates. Generate KLF No FE FE Generates a new long term key. Erases the [DSA] module long term key, creates new module long term key. Generate level 2 cert yes Creates a new logical token, Uses module [AES or Triple Logical Token only which can then be written as key. Creates a DES] shares to smart cards or software logical token. tokens Get ACL No handle, handle, Returns the ACL for a given Exports the ACL ACL handle. ACL for a key object. nShield Security Policy 2.2.3 19 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Get No handle, handle, Returns the application Exports the Application ACL ACL information stored with a key. application Data data of a key object. Get Challenge yes yes yes Returns a random nonce that can No access to be used in certificates keys or CSPs Get Key Info No handle handle Superseded by GetKeyInfoEx Exports the retained for compatibility. SHA-1 hash of a key object Get Key Info No handle handle Returns the hash of a key for use Exports the Extended in ACLs SHA-1 hash of a key object Get Logical No handle handle Superseded by Exports the [SHA-1] Token Info GetLogicalTokenInfoEx retained SHA-1 hash of for compatibility. a logical token. Get Logical No handle handle Returns the token hash and Exports the [SHA-1] Token Info number of shares for a logical SHA-1 hash of Extended token a logical token. Get Module yes yes yes Returns a hashes of the Security Exports the [SHA-1] Keys Officer's key and all loaded SHA-1 hash of module keys . KNSO and module keys. Get Module yes yes yes Returns a handle to the public Exports the [DSA] Long Term half of the module's signing key. public half of Key this can be used to verify key the module's generation certificates and to long term key. authenticate inter module paths. Get Module yes yes yes Returns the public half of the Exports the [DSA] Signing Key module's signing key. This can public half of be used to verify certificates the module's signed with this key. signing key. Get RTC yes yes yes Reports the time according to the No access to on-board real-time clock keys or CSPs Get Share yes yes yes Returns the access control list for Exports the ACL a share ACL for a token share on a smart card. nShield Security Policy 2.2.3 20 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User GetSlot Info yes yes yes Reports status of the physical Uses a module [AES, Triple token in a slot. Enables an key if token is DES] operator to determine if the formatted with correct token is present before a challenge issuing a ReadShare command. response If the token was formatted with a value. challenge response value, uses the module key to authenticate the smart card. Get Slot List yes yes yes Reports the list of slots available No access to from this module. keys or CSPs GetTicket No handle handle Gets a ticket - an invariant Uses a key identifier - for a key. This can be object, logical passed to another client or to a token, Impath, SEE World which can redeem it SEEWorld. using RedeemTicket to obtain a new handle to the object, Get World No handle handle Returns a list of the keys used to Uses a Signers sign a SEEWorld identified by SEEWorld the key hash and the signing object. mechanism used. This command can only be called from inside the SEE world. Hash yes yes yes Hashes a value. No access to HSA-160*, keys or CSPs MD5*, RIPEMD 160*, SHA-1, SHA-256, SHA-384, SHA-512 Impath Get No handle handle Reports status information about Uses an Info an impath Impath, exports status information. Impath Key FE FE FE Creates a new inter-module path Creates a set [DSA and Exchange and returns the key exchange of Impath keys Diffie Begin parameters to send to the peer Hellman] module. AES, Triple- DES Impath Key No handle handle Completes an impath key Creates a set [DSA and Exchange exchange. Require the key of Impath Diffie Finish exchange parameters from the keys. Hellman, AES, remote module. Triple-DES] Impath No handle handle Decrypts data with the Impath Uses an [AES or Triple Receive decryption. key. Impath key. DES] nShield Security Policy 2.2.3 21 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Impath Send No handle handle Encrypts data with the impath Uses an [AES or Triple encryption key. Impath key. DES] Import level 2 cert yes Loads a key and ACL from the Creates a new Level 2 mode - only host and returns a handle. key object, sets Any key type If the unit is operating in FIPS the key value, Level 3 mode - mode at level 2, this operation ACL and App RSA, DSA, must only be used for public data. Diffie- keys - see Operating a level 2 Hellman, module in FIPS mode on page 40 ECDSA or If the unit has been initialized to ECDH public comply with FIPS 140-2 level 3 keys roles and services and key management, this service is only available for public keys. Initialise init init init Initializes the module, returning Erases keys, [DSA] it to the factory state. This clears Creates KM0 all NVRAM files, all loaded keys and KML and all module keys and the module signing key. 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 may issue such certificates to indicate that a module is a genuine nCipher module. This key is not used to encrypt any other data. Load Blob No handle handle Loads a key that has been stored Uses module AES, Triple in a key blob. The operator must key, logical DES or RSA first have loaded the token or key token, or and AES used to encrypt the blob. archiving key, creates a new key object. nShield Security Policy 2.2.3 22 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Load Buffer No handle handle Loads signed data into a buffer. No access to Several load buffer commands keys or CSPs may be required to load all the data, in which case it is the responsibility of the client program to ensure they are supplied in the correct order. Requires the handle of a buffer created by CreateBuffer. Load Logical yes yes yes Allocates space for a new logical Uses module [AES or Triple Token token - the individual shares can key DES] then be assembled using ReadShare or ReceiveShare. Once assembled the token can be used in LoadBlob or MakeBlob commands. Make Blob No handle, handle, Creates a key blob containing the Uses module AES, Triple ACL ACL key and returns it. The key object key, logical DES or RSA to be exported may be any token or and AES algorithm. archiving key, exports encrypted key object. Mod Exp yes yes yes Performs a modular No access to exponentiation on values keys or CSPs supplied with the command. Mod Exp CRT yes yes yes Performs a modular No access to exponentiation on values, keys or CSPs supplied with the command using Chinese Remainder Theorem. Module Info yes yes yes Reports low level status No access to information about the module. keys or CSPs This service is designed for use in nCipher's test routines. NewClient yes yes yes Returns a client id. No access to keys or CSPs New Enquiry yes yes yes Reports status information. No access to keys or CSPs No Operation yes yes yes Does nothing, can be used to No access to determine that the module is keys or CSPs responding to commands. nShield Security Policy 2.2.3 23 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User NVMem No cert yes Allocates an area of non-volatile No access to Allocate memory as a file and sets the keys or CSPs ACLs for this file. This command can now be used to write files protected by an ACL to a smart card NVMem Free No cert yes Frees a file stored in non-volatile No access to memory. This command can now keys or CSPs be used to write files protected by an ACL to a smart card NVMem List yes yes yes Reports a list of files stored in No access to the non-volatile memory. keys or CSPs This command can now be used to list files protected by an ACL on a smart card NVMem No cert, ACL Performs an operation on a file No access to Operation ACL stored in non-volatile memory. keys or CSPs Operations include: read, write, increment, decrement, etc. This command can now be used to write files protected by an ACL to a smart card Random yes yes yes Generates a random number for No access to Number use in a application using the on- keys or CSPs board random number generator. There are separate services for generating keys. The random number services are designed to enable an application to access the random number source for its own purposes - for example an on-line casino may use GenerateRandom to drive its applications. Random Prime yes yes yes Generates a random prime. This No access to uses the same mechanism as is keys or CSPs used for RSA and Diffie- Hellman key generation. The primality checking conforms to ANSI X9.31. nShield Security Policy 2.2.3 24 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Read File level 2 cert yes Reads a file, but not a logical Reads a file, token, from a smart card or but not a software token. logical token, from a smart This command can only read card or files without ACLs. software token. This command can only read files without ACLs. No access to keys or CSPs Read Share yes yes yes Uses pass [SHA-1, AES Reads a share from a physical phrase, module or Triple DES] token. key, creates share key, uses Once sufficient shares have been share key, loaded recreates token- may creates a require several ReadShare or logical token. ReceiveShare commands. Receive Share No handle, handle, Takes a share encrypted with Uses an [AES, Triple encrypt encrypt SendShare and a pass phrase and Impath key, DES] ed ed uses them to recreate the logical uses pass share share token. - may require several phrase, module ReadShare or ReceiveShare key, creates commands share key, uses share key, creates a logical token Redeem Ticket No ticket ticket Gets a handle in the current name Uses a key space for the object referred to object, logical by a ticket created by GetTicket. token, Impath, or SEEWorld Remove KM No cert yes Removes a loaded module key. Erases a module key SEE Job No cert yes Sends a command to a SEE No access to World. keys or CSPs nShield Security Policy 2.2.3 25 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Set ACL No handle, handle, Sets the ACL for an existing key. Sets the ACL ACL The existing ACL for the key Access must allow the operation. Control List for a key object Set No handle, handle, Stores information with a key. Sets the Application ACL ACL application Data data stored with a key object Set KM No cert yes Loads a key object as a module Uses a key AES, Triple key. object, sets a DES module key Set NSO Perm init init No Loads a key hash as the nCipher Sets the [SHA-1 hash Security Officer's Key and sets nCipher of DSA key] the security policy to be followed Security by the module. This can only be officer's key performed while the unit is in the hash. initialisation state. Set RTC No cert yes Sets the real-time clock. No access to keys or CSPs Set SEE No cert handle Loads the contents of a buffer Uses a public DSA, Triple Machine handle (created by CreateBuffer / key provided DES MAC, LoadBuffer) as the SEE machine in buffer HMAC for this module. This command checks the signatures on the buffer. Sign No handle, handle, Returns the digital signature or Uses a key RSA, DSA, ACL ACL MAC of plain text using a stored object ECDSA, key. Triple DES MAC, HMAC, KCDSA* Sign Module No handle, handle, Signs a certificate describing the Uses the [DSA] State ACL ACL modules security policy, as set by module SetNSOPerm signing key Send Share No handle, handle, Reads a logical token share and Uses an [AES, Triple ACL ACL encrypts it under an impath key Impath key, DES] for transfer to another module exports where it can be loaded using encrypted ReceiveShare share. Statistics yes yes yes Reports the statistics available. No access to Enumerate keys or CSPs Tree nShield Security Policy 2.2.3 26 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Statistic Get yes yes yes Reports a particular statistic. No access to Value keys or CSPs Trace SEE No cert yes Reports debugging output from a No access to World SEE World. keys or CSPs Update monito monito monito These commands are used in the Uses Firmware [DSA, Triple Firware r r r update firmware service. Integrity Key DES] Service The individual commands are and Firmware (Calls required to load the candidate Confidentiality Programming firmware image in sections small Keys. Begin enough to be transported by the Sets Firmware Programming interface. Integrity Key Begin Chunk nCipher supply the LoadROM and Firmware Programming utility for the administrator to Confidentiality Load Block use for this serice. This utility Keys. Programming issues the correct command End Chunk sequence to load the new Programming firmware. End) The module will only be operating 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. Verify No handle, handle, Verifies a digital signature using Uses a key RSA, DSA, ACL ACL a stored key. object. ECDSA, Triple DES MAC, HMAC, KCDSA* Write File level 2 cert yes Writes a file, but not a logical No access to token, to a smart card or software keys or CSPs token. Note these files do not have an ACL, use the NVMEM commands to create files with an ACL. nShield Security Policy 2.2.3 27 TM CI PHE R Services available to each role Command / Role Description Key/CSP Key types Service access Unaut JSO / NSO h User Write Share No cert handle Writes a new share to a smart Sets pass [AES, Triple handle card or software token. The phrase, uses DES, SHA-1] number of shares that can be module key, created is specified when the creates share, token is created. All shares must uses pass be written before the token is phrase and destroyed. module key, creates share key, uses module key, uses share key, exports encrypted share. 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, SEEWorld. 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 or SEEWorld. ACL 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 signature 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 encrypt the share. The module key with which the pass phrase was combined must also be present. cert An operator can only perform this service if they are in possession of a certificate from the nCipher Security Officer. This certificate will reference a key. The module verifies the signature on the certificate before permitting the operation. FE This service is not available on all modules. It must be enabled using the FeatureEnable service before it can be used. nShield Security Policy 2.2.3 28 TM CI PHE R Services available to each role Code Description level 2 only These services are available to the unauthenticated operator only when the module is initialized in it FIPS 140-2 level 2 mode. The module can be initialized to comply with FIPS 140-2 level 3 roles and services and key management by setting the FIPS_level3_compliance flag. If this flag is set: · the Generate Key, Generate Key Pair and Import commands require authorization with a certificate signed by the nCipher Security Officer. · the Import command fails if you attempt to import a key of a type that can be used to Sign or Decrypt messages. · the GenerateKey, GenerateKeyPair, Import and DeriveKey operations will not allow you to create an ACL for a secret key that allows the key to be exported in plain text. encrypted The ReceiveShare command requires a logical token share encrypted using an Impath key. created share by the SendShare command. ticket The RedeemTicket command requires the ticket generated by GetTicket. init These services are used to initialise the module. They are only available when the module is in the initialisation mode. To put the module into initialisation mode you must have physical access to the module and put the mode switch into the initialisation setting. In order to restore the module to operational mode you must put the mode switch back to the Operational setting. monitor These services are used to reprogram the module. They are only available when the module 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. nShield Security Policy 2.2.3 29 TM CI PHE R Keys Keys For each type of key used by the nShield and nCipher modules, the following section describes the access that a operator has to the keys. The nShield and nCipher modules refers to keys by their handle, an arbitrary number, or by its SHA-1 hash. Security Officer's key The nCipher Security officer's key must be set as part of the initialisation process. This is a public / private key pair that the nCipher 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 Security Officer. If you use the standard tools supplied by nCipher to initialise the module, then this key is a DSA key stored as a key blob protected by a logical token on the Administrator Card Set. If a customer writes their own tools to initialise the module, they can choose between RSA, DSA or KDSA, and are responsible for ensuring the private half of this key is stored securely. Junior Security Officer's key Because the nCipher Security Officer's key has several properties, it is good practice to delegate authority 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 nCipher 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 UseAsCertificate permissions, then they cannot delegate authority. nShield Security Policy 2.2.3 30 TM CI PHE R Keys If you use the standard tools supplied by nCipher to initialise the module, then this key is a DSA key stored as a key blob protected by a logical token on the Administrator Card Set. If a customer writes their own tools to initialise the module, they can choose between RSA, DSA or KDSA, and are responsible for ensuring the private half of this key is stored securely. Long term signing key The nShield and nCipher modules stores a 160 bit random number in the EEPROM provided by the Dallas 4320. This data is combined with a discrete log group stored in the module firmware to produce a DSA key. This key can be reset to a new random value by the GenerateKLF service. 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 module that can be included in a PKI certificate chain. nCipher may issue such certificates to indicate that a module is a genuine nCipher module. Module signing key When the nShield and nCipher modules is initialized it automatically generate a DSA key pair that it uses to sign certificates. 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 under some other key. This key is only ever used to verify that a certificate was generated by a specified module. Module keys Module keys are AES or Triple DES used to protect tokens. The nShield and nCipher 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 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. 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. nShield Security Policy 2.2.3 31 TM CI PHE R Keys 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 module key is exported the logical token - the Triple DES key 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 and written to a physical 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. Share Key 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 an nCipher 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 the approved pRNG function 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. 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. Impath keys An impath is a secure channel between two modules. To set up an impath two modules perform a validated key-exchange, currently using Diffie- Hellman. nShield Security Policy 2.2.3 32 TM CI PHE R Keys The key exchange parameters are signed by the modules signing key Once the modules have validated the signatures the module derives four symmetric keys using a protocol based on SHA-1. Currently symmetric keys are Triple DES. 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 DRAM. Key objects Keys used for encryption, decryption, signature verification and digital signatures are stored in the module as objects in the object store in DRAM. All key objects are identified by a random identifier that is specific 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 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. 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. nShield Security Policy 2.2.3 33 TM CI PHE R Keys Archiving keys It is sometimes necessary to create an archive copy of a key, protected by another key. Keys may be archived using: · Triple DES keys · A combination of Triple DES and RSA keys. In this case a random Triple DES key is created which is used to encrypt working key and then this key is wrapped by the RSA key. · An integrated encryption scheme using Diffie-Hellman or RSA and AES or Triple DES. When a key is archived in this way it is stored with its ACL When you generate or import the archiving, 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. 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 nCipher 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 nCipher Security Officer. Firmware Integrity Key All firmware is signed using a DSA key pair. A module only loads new firmware 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 DRAM as part of the start up procedure. nShield Security Policy 2.2.3 34 TM CI PHE R Keys Firmware Confidentiality Key All firmware is encrypted using Triple DES to prevent casual decompilation. The encryption key is stored at nCipher's offices and is in the firmware. The firmware is stored in flash memory when the module is switched off, this is copied to DRAM as part of the start up procedure. nCipher Master Feature Enable Key For commercial reasons not all nCipher modules offer all services. Certain services must be enabled separately. In order to enable a service the operator presents a certificate signed by the nCipher Master Feature Enable Key. This causes the module to set the appropriate bit in the EEPROM.. The nCipher Master Feature Enable Key is a DSA key pair, The private half of this key pair is stored at nCipher's 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 DRAM as part of the start up procedure. nShield Security Policy 2.2.3 35 TM CI PHE R Rules Rules Identification and authentication Communication with the nShield and nCipher modules is performed via a server program running on the host machine, using standard inter process communication, using sockets in UNIX operating system, named pipes under Windows NT. In order to use the module the operator must first log on to the host computer and start an nCipher enabled application. The application connects to the nCipher server, 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 connection. The authorization required for each service is listed in the section Services available to each role on page 14. An operator cannot access any service that accesses CSPs without first presenting a smart card, or software token. The nShield and nCipher modules performs 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. 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 sufficient 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 nCipher Security Officer, who is identified by a public key pair created when the module is initialized. It is not possible to change the 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. nShield Security Policy 2.2.3 36 TM CI PHE R Rules 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. Access Control List All key objects have an Access Control List (ACL). The operator must specify the ACL when they generate or import the key. The ACL lists every operation that can be performed with the key - if the 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 nCipher server 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. Object re-use All objects stored in the module are referred to by a handle. The module's memory management functions 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. nShield Security Policy 2.2.3 37 TM CI PHE R Rules 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 processing commands and no further replies are returned. In the error state the unit does not respond to commands. The unit must be reset. 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 items are excluded from FIPS 140-2 validation as they are not security relevant see Excluded Components on page 10 Status information The module has an 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 NetHSM this information can be displayed on the LCD on the NetHSM's front panel. Procedures to initialise a module to comply with FIPS 140-2 Level 3 The nCipher enabled application must perform the following services, for more information refer to the nCipher Security Officer's Guide and Technical Reference Manual. 1 Put the mode switch into the initialisation position and restart the module nShield Security Policy 2.2.3 38 TM CI PHE R Rules 2 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 "Strict FIPS 140 Mode" = Yes. - Using new-world specify the -F flag in the command line 3 The tool prompts you to insert cards and to enter a pass phrase for each card. 4 When you have created all the cards, reset the mode switch into the operational position and restart the module. If a module is initialised in level 3 mode · Keysafe displays Strict FIPS 140-2 Mode" = Yes in the information panel for that module. · The command line tool Enquiry include StrictFIPS in the list of flags for the module Procedures to initialise a module to comply with FIPS 140-2 Level 2 The nCipher enabled application must perform the following services, for more information refer to the nCipher Security Officer's Guide and Technical Reference Manual. 1 Put the mode switch into the initialisation position and restart the module 2 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 2 mode you must - Using Keysafe select the option "Strict FIPS 140 Mode" = No - Using new-world do NOT specify the -F flag in the command line 3 The tool prompts you to insert cards and to enter a pass phrase for each card. 4 When you have created all the cards, reset the mode switch into the operational position and restart the module. If a module is initialised in level 2 mode · Keysafe displays Strict FIPS 140-2 Mode" = No in the information panel for that module. nShield Security Policy 2.2.3 39 TM CI PHE R Rules · The command line tool Enquiry does NOT include StrictFIPS in the list of flags for the module Operating a level 2 module in FIPS mode To be operating in Level 2 FIPS Mode, only FIPS Approved cryptography can be used in FIPS Mode. Use of any Non-FIPS Approved algorithms, except for those for which the CMVP allowed in FIPS Mode (See Supported Algorithms Section), means that the module would not be operating in FIPS Mode. In order to comply with FIPS mode the operator must not generate private or secret keys with the ExportAsPlain ACL entry; nor should they use the Import service to import such keys in plain text. An operator can verify that a key was generated correctly using the nfkmverify utility supplied by nCipher. This utility checks the ACL stored in the key-generation certificate. To return a module to factory state This clears the Security Officer's key, the module signing key and any loaded module keys. 1 Fit the initialisation link and restart the module 2 Use the Initialise command to enter the Initialisation state. 3 Load a random value to use as the hash of the Security Officer's key. 4 Set Security Officer service to set the Security Officer's key and the operational policy of the module. 5 Remove the initialisation link and restart the module. 6 After this operation the module must be initialized correctly before it can be used in a FIPS approved mode. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. To create a new operator 1 Create a logical token. 2 Write one or more shares of this token onto software tokens. nShield Security Policy 2.2.3 40 TM CI PHE R Rules 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. To authorize the operator to create keys 1 Create a new key, with an ACL that only permits UseAsSigningKey. 2 Export this key as a key blob under the operator's token. 3 Create a certificate signed by the nCipher Security Officer's key that: 4 includes the hash of this key as the certifier 5 authorizes the action GenerateKey or GenerateKeyPair depending on the type of key required. 6 if the operator needs to store the keys, enables the action MakeBlob, limited to their token. 7 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. To 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 nCipher Security Officer's key includes the hash of this key as the certifier 9 authorizes the actions GenerateKey, GenerateKeyPair nShield Security Policy 2.2.3 41 TM CI PHE R Rules 10 authorizes the actions GenerateLogicalToken, WriteShare and MakeBlob, these may be limited to a particular module key. 11 Give the Junior Security Officer the software token, any pass phrases used, the key blob and certificate. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. To 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. 4 The operator can now perform the services specified in the ACL for this key. 5 To assume Security Officer role load the Security Officer's key using this procedure. The 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. To 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 Security Officer with the GenerateKey, GenerateKeyPair or MakeBlob command. nCipher supply a graphical user interface KeySafe and a command line tool new-world that automate these steps. nShield Security Policy 2.2.3 42 TM CI PHE R Physical security Physical security All security critical components of the module are covered by epoxy resin. The module has a clear button. Pressing this button put 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 critical parameters, module keys, module signing key and Security Officer's key can be cleared by returning the module to the factory state, as described above. Checking the module To ensure physical security, make the following checks regularly: · Examine the epoxy resin security coating for obvious signs of damage. · The smart card reader is directly plugged into the module 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 evidence provided by the appliance. nShield Security Policy 2.2.3 43 TM CI PHE R Strength of functions Strength of functions Attacking Object IDs Connections are identified by a ClientID, a random 32 bit number. Objects are identified by a KeyID - this should be renamed ObjectID as it can now be used for more than just keys but retains its old name for code compatibility reasons. 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 random 32 bit numbers. 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 that the required chance of 1 in 1,000,000 (~2-20) Attacking 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 than 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: · not leaving the smart card in the reader 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. · 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 recreate 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. · 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 168-bit 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. nShield Security Policy 2.2.3 44 TM CI PHE R Strength of functions Key Blobs Key blobs are used to protect keys outside the module. There are two formats of blob - indirect and direct. Direct blobs are used for token and module key protected blobs. indirect blobs are used by the nCipher Security World for key-recovery and for pass-phrase recovery. Direct blobs use a Integrated encryption scheme, which takes a 168 or 256 bit key and a nonce and uses SHA-1 to derive a triple-DES or AES encryption key, used for encryption and a HMAC key, used for integrity. Indirect key, take the public half of a 1024-bit RSA key and a none as the input, and derive the keys from this. Both forms provide at least 80-bits of security. Impaths Impaths protect the transfer of encrypted shares between modules. When negotiating an Impath, the module verifies a 1024-bit DSA signatures to verify the identity of the other module. It then uses 1024-bit Diffie-Hellman key exchange to negotiate a 168-bit triple-DES encryption keys used to protect the channel. This provides a minimum of 80-bits of security for the encrypted channel. Note The shares sent over the channel are still encrypted using their share key, decryption only takes place on the receiving module. 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. 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. nShield Security Policy 2.2.3 45 TM CI PHE R Strength of functions 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 symmteric key into separate Components are raw byte blocks. components for split knowledge key export PKCS8 wrapping Encrypts a key using a pass phrase. Not available in FIPS 140-2 level 3 mode PKCS8 unwrapping Decrypts a wrapped key using a Not available in FIPS 140-2 level 3 pass phrase. mode SSL3 master key derivation Setting up a SSL session Not available in FIPS 140-2 level 3 mode TLS master key derivation Setting up a TLS session Key Wrapping Encrypts one key object with May use any supported encryption another to allow the wrapped key to mechansim that accepts a be exported. byteblock. The operator must ensure that they chose a wrapping key that has an equivalent strength to the key being transported. If the module is initialized in its level 3 mode all non-approved key wrapping and key establishment mechanisms are disabled. nShield Security Policy 2.2.3 46 TM CI PHE R Self Tests 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. 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: · An operational test on hardware components · An integrity check on the firmware, verification of a SHA-1 hash. · A statistical check on the random number generator · Known answer and pair-wise consistency checks on all algorithms and pRNG · 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- Initialisation, Uninitialised or Operational state; depending on the position of the mode switch and the validity of the the EEPROM contents. While it is powered on, the module continuously monitors the temperature recorded by its internal temperature sensor. If the temperature is outside the operational range it enters the error state. The module also continuously monitors the hardware RNG and the approved SHA-1 based pRNG. 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. 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. Firmware Load Test When an administrator loads new firmware, the module reads the candidate image into working memory. It then performs the following tests on the image before it replaces the current application: · The image contains a valid signature which the module can verify using the Firmware Integrity Key · The image is encrypted with the Firmware Confidentiality Key stored in the module. nShield Security Policy 2.2.3 47 TM CI PHE R Self Tests · 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 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. nShield Security Policy 2.2.3 48 TM CI PHE R Supported Algorithms Supported Algorithms FIPS approved algorithms: · AES Certificate #599, ECB, CBC and CMAC modes GCM Mode Vendor Affirmed · Triple DES Certificate #570 Double and triple length keys Approved for Federal Government Use - Modes are CBC and ECB · Triple DES MAC Triple-DES Certificate #570 vendor affirmed · DSA Certificate #233 · ECDSA Certificate #64 · RSA Certificate #274 · SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 Certificate #648 · HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384 and HMAC SHA- 512 Certificate #309 · Random Number Generator (FIPS 186-2 Change Notice 1 SHA-1 and FIPS 186-2 RNG General Purpose RNG) Certificate #340 nShield Security Policy 2.2.3 49 TM CI PHE R Supported Algorithms Non-FIPS approved algorithms Note Algorithms marked with an asterisk are not approved by NIST. If the module is initialised in its level 3 mode, these algorithms are disabled. If module is initialized in level 2 mode, the algorithms are available. However, if you choose to use them, the module is not operating in FIPS approved mode. Symmetric · Aria* · Arc Four (compatible with RC4)* · Camellia* · CAST 6 (RFC2612)* · DES* · SEED (Korean Data Encryption Standard) - requires Feature Enable activation* Asymmetric · Diffie-Hellman (key agreement, key establishment methodology provides between 80 and 256 bits of encryption strength) · El Gamal * (encryption using Diffie-Helman keys) · Elliptic Curve Diffie-Hellman (key agreement, key establishment methodology provides 192-bits of encryption strength); · RSA (key wrapping, key establishment methodology provides between 80 and 256 bits of encryption strength) · KCDSA - requires Feature Enable activation* · EC-MQV (key establishment methodology provides between 80 and 256 of encryption strength) Hash · HAS-160 - requires Feature Enable activation* · MD5 - requires Feature Enable activation* · RIPEMD 160* nShield Security Policy 2.2.3 50 TM CI PHE R Supported Algorithms · Tiger* MAC · HMAC (MD5, RIPEMD160, Tiger)* Other · SSL*/TLS master key derivation · PKCS #8 key wrapping*. Note TLS key derivation is approved for use by FIPS 140-2 validated modules - though there is as yet no validation test. MD5 may be used within TLS key derivation. nShield Security Policy 2.2.3 51 nCipher addresses TM CI PHE R nCipher Corporation Ltd. nCipher Inc. Cambridge, UK Boston Metro Region, USA Jupiter House 92 Montvale Avenue, Suite 4500 Station Road Stoneham, MA 02180 Cambridge USA CB1 2JD UK Tel: +44 (0) 1223 723600 Tel: 800-NCIPHER 800-6247437 +1 (781) 994 4000 Fax: +44 (0) 1223 723601 Fax: +1 (781) 994 4001 E-mail: sales@ncipher.com E-mail: sales@us.ncipher.com Internet addresses Web Site: http://www.ncipher.com/ Support: http://www.ncipher.com/support/ Online Documentation: http://active.ncipher.com/documentation/ Note nCipher also maintain international sales offices. Please contact the UK, or the US, head office for details of your nearest nCipher representative.