The nForce module security policy
nForce SCSI 75, nForce SCSI 150, nForce SCSI 300
Date: 14 March 2006
Version: 1.1.42
© Copyright 2006 nCipher Corporation Limited, Cambridge, United Kingdom.
Reproduction is authorised provided the document is copied in its entirety without modification and
including this copyright notice.
nCipher™, nForce™, nShield™, nCore™, KeySafe™, CipherTools™, CodeSafe™, SEE™ 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.
nCipher
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42i
Contents
Chapter 1: Purpose 1
Roles 2
Services available to each role 3
Non Cryptographic services 4
FIPS 140-1 services 7
Keys 12
Rules 15
Algorithms 19
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.421
Chapter 1: Purpose
The nForce secure e-Commerce accelerator is a multi-tasking hardware module that is optimized for
performing modular arithmetic on very large integers. The nForce module also offers a complete set of
key management protocols.
The nForce modules: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 are FIPS 140-1 level 2 stand-
alone devices. The units are identical in operation and only vary in the processing speed.
The module runs firmware provided by nCipher. There is the facility for the user 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. The validated
firmware versions are 1.77.100.
The module can be initialized to comply with the roles and services section at either level 2, role based
authorization, or level 3, identity based authorization. See “To comply with FIPS 140-1 level 3 roles and
services and key management” on page 16. The initialization parameters are reported by the NewEnquiry
and SignModuleState services.
The module offers some general services that do not involve stored keys and are therefore excluded from
FIPS 140-1. While the module is executing these services it is operating in a non-FIPS 140-1 mode.
The nForce module connects to the host computer via a SCSI bus. The nForce module must be accessed
by a custom written application. Full documentation for the nCipher API can be downloaded from the
nCipher web site: http://www.ncipher.com.
The nForce module stores keys on the hard disk of the host computer in encrypted form called key blobs.
The nForce module can be connected to a computer running one of the following operating systems:
• Windows NT 4.0 for Intel
• Windows 2000
• Solaris
• HP-UX
• AIX
• Linux x86
• FreeBSD x86
Windows NT was used for the validation.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.422
nCipher Roles
Roles
The nForce module defines the following roles:
User
All users initially connect to the nForce module in the User role. In this role the user can load previously
created tokens and use these to load keys from key blobs. Once they have loaded a key they can then use
it 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
user and ensuring that these tokens are physically handed to the correct person.
A user assumes the role of NSO by loading the private half of KNSO and presenting the KeyID for this
key to authorize a command.
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 user loads the JSO key and presents the KeyID of this key, and if
required the certificate singed by KNSO that delegates authority to the key, to authorize a command.
A JSO can delegate portions of their authority in the same way.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.423
nCipher Services available to each role
Services available to each role
The module offers non-cryptographic services, which are excluded from FIPS 140-1 and cryptographic
services, which are FIPS 140-1 validated. These services are described in the next section.
For more information on each of these services refer to the nCipher Developer’s Guide and nCipher
Developer’s Reference.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.424
nCipher Services available to each role
Non Cryptographic services
Status information
The following services display non cryptographic information about a module and are available to any
user without authentication:
• Enquiry
Returns status information
• Firmware authenticate
Performs a zero knowledge challenge response protocol that enables a user to ensure that the
firmware in the module matches the firmware supplied by nCipher.
• Get module long term key
Returns the public half of the module’s long term key. This can be used to verify certificates signed
with this key.
• Get module signature key
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.
• Get slot list
Returns the list of slots available from this module.
• Module Info
Returns low level status information about the module. This service is designed for use in nCipher’s
test routines.
• NoOp
Does nothing, can be used to determine that the module is responding to commands.
• Pause for notifications
This service enables the module to communicate with the nCipher server.
• Statistics enumerate tree
Lists the statistics available.
• Statistic get values
Returns a particular statistic.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.425
nCipher Services available to each role
The status of the module is also indicated by the LED on the front panel.
Module state
The following services change the module state.
• Fail
A test service that causes the module to fail.
• Clear unit
Clears the module - equivalent to pressing the clear button.
• Initialise unit
Causes a module in the pre-initialisation state to enter the intiailisation state.
• Maintenance
Causes a module in the pre-maintenance state to enter the maintenance state.
Note The nCipher server will only issue these commands if the user is connected with Administrator privileges.
State Description
Power Off Off
Self Test On
Pre Maintenance One short flash followed by a long pause
Maintenance Two short flashes followed by a long pause
Pre Initialisation One long flash followed by a long pause
Initialisation Two long flashes followed by a long pause
Operational
On regularly blinking off. The length of time the LED is on reduces with the
current load.
Error
Three long flashes followed by a pause, three short flashes followed by a pause,
three long flashes followed by a longer pause, an error code and a long pause.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.426
nCipher Services available to each role
Arithmetic
The following services perform basic mathematics and are available without authentication:
• Bignum operations
Performs simple mathematical operations.
• Hash
Hashes a value
• Modular exponentiation
Performs a modular expoentiation on values supplied with the command.
• Modular exponentiation using CRT
Performs a modular expoentiation on values, supplied with the command using Chinese Remainder
Theorem.
• Random number
Generates a random number for use in a application.
• Random prime
Generates a random prime.
Note There are separate services for generating keys. These 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.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.427
nCipher Services available to each role
FIPS 140-1 services
The following services provide user authentication or cryptographic functionality:
Command/
Service
Role
Description
Unauth
User
/
JSO
NSO
ChangeSharePIN -
pass
phrase
pass
phrase
Updates the pass phrase used to encrypt a token share.
The pass phrase supplied by the user is not used directly,
it is first hashed and then combined with the module key.
ChannelOpen -
handle,
ACL
handle,
ACL
Opens a communication channel which can be used for
bulk encryption.
ChannelUpdate - handle handle Performs encryption on a previously opened channel.
Decrypt -
handle,
ACL
handle,
ACL
Decrypts a cipher text with a stored key returning the
plain text.
DeriveKey -
handle,
ACL
handle,
ACL
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.
Destroy - handle handle
Removes an object, if an object has multiple handles as a
result of RedeemTicket service, this removes the current
handle.
Duplicate -
handle,
ACL
handle,
ACL
Creates a second instance of a key with the same ACL
and returns a handle to the new instance.
Encrypt -
handle,
ACL
handle,
ACL
Encrypts a plain text with a stored key returning the
cipher text.
EraseFile level 2 cert yes
Removes a file, but not a logical token, from a smart card
or software token.
EraseShare level 2 cert yes Removes a share from a smart card or software token.
ExistingClient yes yes yes Starts a new connection as an existing client.
Export -
handle,
ACL
handle,
ACL
Exports a key in plain text. If the unit has been initialized
to comply with FIPS 140-1 level 3 roles and services and
key management, this service is only available for public
keys.
FeatureEnable - cert cert
Enables a service.
This requires a certificate signed by the nCipher Master
Feature Enable key.
FormatToken level 2 cert yes Formats a smart card or software token ready for use.
GenerateKey level 2 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 nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.428
nCipher Services available to each role
GenerateKeyPair level 2 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
GenerateKLF - FE FE Generates a new long term key.
GenerateLogicalToken level 2 cert yes
Creates a new logical token, which can then be written
as shares to smart cards or software tokens
GetACL -
handle,
ACL
handle,
ACL
Returns the ACL for a given handle.
GetAppData -
handle,
ACL
handle,
ACL
Returns the application information stored with a key.
GetChallenge yes yes yes Returns a random nonce that can be used in certificates
GetKeyInfo - handle handle Superseded by GetKeyInfoEx
GetKeyInfoEx - handle handle Returns the hash of a key for use in ACLs
GetLogicalTokenInfo - handle handle Superseded by GetLogicalTokenInfoEx
GetLogicalTokenInfoEx - handle handle
Returns the token hash and number of shares for a
logical token
GetShareACL yes yes yes Returns the access control list for a share
GetSlotInfo yes yes yes
Returns status of the physical token in a slot. Enables a
user to determine if the correct token is present before
issuing a ReadShare command.
GetTicket - handle handle
Gets a ticket - an invariant identifier - for a key. This can
be passed to another client which can redeem it using
RedeemTicket
ImpathGetInfo - handle handle Returns information about an impath
ImpathKXBegin yes yes yes
Creates a new inter-module path and returns the key
exchange parameters to send to the peer module.
ImpathKXFinish - handle handle
Completes an impath key exchange. Require the key
exchange parameters from the remote module.
ImpathReceive - handle handle
Decrypts application data with the impath decryption
key.
ImpathSend - handle handle Encrypts application data with the impath encryption key.
Import level 2 cert yes
Loads a key and ACL from the host and returns a handle.
Exports a key in plain text. If the unit has been initialized
to comply with FIPS 140-1 level 3 roles and services and
key management, this service is only available for public
keys.
Command/
Service
Role
Description
Unauth
User
/
JSO
NSO
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.429
nCipher Services available to each role
InsertSoftToken yes yes yes
Loads a software token from the host disk and ‘inserts’ it
into a slot. Automatically run by the server.
LoadBlob - handle handle
Loads a key that has been stored in a key blob. The user
must first have loaded the token or key used to encrypt
the blob.
LoadLogicalToken yes yes yes
Allocates space for a new logical token - the individual
shares can then be assembled using ReadShare or
SwallowShare. Once assembeld the token can be used in
LoadBlob or MakeBlob commands
MakeBlob -
handle,
ACL
handle,
ACL
Creates a key blob containing the key and returns it.
NewClient yes yes yes Returns a client id.
ReadFile yes yes yes
Reads a file, but not a logical token, to a smart card or
software token.
ReadShare yes yes yes
Reads a share from a physical token. Requires Once
sufficient shares have been loaded recreates token
RedeemTicket ticket ticket ticket
Gets a handle in the current name space for the object
referred to by a ticket. Redeeming a ticket authorizes the
user to use that key.
RemoveKM - cert yes Removes a loaded module key.
RemoveSoftToken server server server
Removes a software token from an emulated slot and
writes it to the host disk.
SetACL -
handle,
ACL
handle,
ACL
Sets the ACL for an existing key. The existing ACL for
the key must allow the operation.
SetAppData -
handle,
ACL
handle,
ACL
Stores information with a key.
SetKM - cert yes Loads a key as a module key.
SetKNSO nFast, init nFast, init -
Superseded by SetNSOPerm. Although this command
can still be used it cannot authorize recently added
services added.
SetNSOPerm nFast, init nFast, init -
Loads a key hash as the nCipher 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 initialisation state.
Sign -
handle,
ACL
handle,
ACL
Returns the digital signature of plain text using a stored
key.
SignModuleState -
handle,
ACL
handle,
ACL
Signs a certificate describing the modules security policy,
as set by SetNSOPerm
Command/
Service
Role
Description
Unauth
User
/
JSO
NSO
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
10
nCipher Services available to each role
SquirtShare -
handle,
ACL
handle,
ACL
Reads a logical token share and encrypts it under an
impath key for transfer to another module where it can
be loaded using SwallowShare
SwallowShare -
handle,
encrypted
share
handle,
encrypted
share
Takes a share encrypted with SquirtShare and uses it to
recreate the logical token. Requires the handle for the
impath that encrypted the share.
Verify -
handle,
ACL
handle,
ACL
Verifies a digital signature using a stored key.
WriteFile - cert yes
Writes a file, but not a logical token, to a smart card or
software token.
WriteShare - cert yes
Writes a new share to a smart card or software token.
The number of shares that can be created is specified
when the token is created. All shares must be written
before the token is destroyed.
Code Description
- The user can not perform this service in this role.
yes The user can perform this service in this role without further authorization.
handle
The user 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 user that created the object.
The ticket services enable a user to pass an ID for an object they have created to another user
ACL
The user can only perform this service with a key if the ACL for the key permits this service. The
ACL may require that the user present a certificate signed by a Security Officer or another key.
token or key
A user can only load a key blob if they have previously loaded the token or key used to encrypt
the blob.
pass phrase
A user 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
A user can only perform this service if they are in possession of a certificate from the nCipher
Security Officer. This certificate can be tied to a specific key, and hence to a specific smart card.
FE
This service is not available on all modules. It must be enabled using the FeatureEnable service
before it can be used.
Command/
Service
Role
Description
Unauth
User
/
JSO
NSO
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
11
nCipher Services available to each role
nFast A user can only perform this service is they are logged into the host computer as the user nFast.
level 2
The module can be initialized to comply with FIPS 140-1 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 Generate Key, Generate Key Pair, Import and Derive Key operations will not allow you to
create an ACL for a secret key that allows the key to be exported in plain text.
Code Description
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
12
nCipher Keys
Keys
For each type of key used by the nForce module, the following section describes the access that a user
has to the keys.
The nForce module 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 nCipher Security Officer is responsible for this key. If it is generated by the module it may be
exported as a key blob under a token.
The public half of this key is included as plain text in certificates.
Long term signing key
The nForce module can store a 160 bits 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 set 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 Get Long Term
Key.
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 nForce module is initialized it automatically generate a key pair that it uses to sign certificates.
The private half of this pair is stored internally in EEPROM and never released. The pubic 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 used to protect tokens. The nForcemodule generates the first module key KM0 when it
is initialized. This module key is guaranteed never to have been known outside this module.
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 protected by an archiving key when they are initially generated.
Logical tokens
A logical token is a Triple DES key used to protect key blobs.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
13
nCipher Keys
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. These
are protected by a module key and optional pass phrase. Additionally a logical token may be shared over
several physical and/or software tokens, with each share protected by a share key.
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. A share may be further protected using a pass phrase. The pass phrase is combined with a module
key, the share number and the smart card id to form a unique Triple DES key used to encrypt the share.
This Triple DES key is not stored on the module. It is recalculated every time share is loaded.
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 Helman but
with provision to use other key exchange algorithms if any are added to the module.
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 SRAM.
Key objects
Keys used for encryption, decryption, signature verification and digital signatures are stored in the
module as objects in the object store in SRAM. All key objects are identified by a random identifier that
is specific to the user 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 you generate a key or import a key in plain text you 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 there 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.
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-1 level 3 roles and services and key management the ACL for a
private or secret key cannot include the export as plain service.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
14
nCipher Keys
A user may pass a key to another user 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 user 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 user 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.
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.
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 SRAM as part of the start up procedure.
Firmware Confidentiality Key
All firmware is encrypted 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 SRAM 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 user presents a certificate signed by the nCipher Master
Feature Enable Key. This causes the module to set the appropriate bit in the Dallas EEPROM.
The private half of this key is stored at nCipher’s offices.
The public half is included in the firmware. The firmware is stored in flash memory when the module is
switched off, this is copied to SRAM as part of the start up procedure.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
15
nCipher Rules
Rules
Identification and authentication
All communication with the nForce module 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 user 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 120-
bit arbitrary number.
Before performing any service the user must present the correct authorization. Where several stages are
required to assemble the authorization, all the steps must be performed on the same connection.
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 user 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 a user 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 user must reauthorize the key by reloading the token.
All objects are referred to by handle. Handles are cross-referenced to client IDs. 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.
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.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
16
nCipher Rules
Error conditions
If the nForce 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 user can resubmit
the command at a later time. The server program can record a log of all such failures.
If the nForce 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.
Physical security
Security Boundary
The security boundary is the steel case.
The following items are excluded from FIPS 140-1 validation as they are not security relevant.
• SCSI termination fuse
• power connector
• jumper block
• smart card interface board
• anti-spark capicators
To comply with FIPS 140-1 level 3 roles and services and key management
The nCipher enabled application must perform the following services, for more information refer to the
nCipher Security Officer’s Guide and Technical Reference Manual.
To initialise a module
1 Fit the initialisation link and restart the module
2 Use the Initialise command to enter the Initialisation state.
3 Generate a key pair to use a Security Officer’s key.
4 Generate a logical token to use to protect the Security Officer’s key.
5 Write one or more shares of this token onto software tokens.
6 Export the private half of the Security Officer’s key as a key blob under this token.
7 Export the public half of the Security Officer’s key as plain text.
The nForce module is enclosed in a steel case made of three pieces of 1 mm steel.
The unit is sealed with tamper evident seals from Advantage technology.
In order to prevent access to the unit via the ventilation slots, the slots in the base and lid are offset so that
there is no straight line path though the two sets of slots.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
17
nCipher Rules
8 Use the Set Security Officer service to set the Security Officer’s key and the operational policy of the
module. In order to comply with FIPS 140-1 level 3 roles and services and key management you must
set at least the following flags:
• NSOPerms_ops_ReadFile
• NSOPerms_ops_WriteFile
• NSOPerms_ops_EraseShare
• NSOPerms_ops_EraseFile
• NSOPerms_ops_FormatToken
• NSOPerms_ops_GenerateLogToken
• NSOPerms_ops_SetKM
• NSOPerms_ops_RemoveKM
• NSOPerms_ops_StrictFIPS140
9 Keep the tokens and key blobs safe.
10 You can create extra module keys in order to distinguish groups of users.
11 You may want to create working keys and user authorization at this stage.
12 Remove the initialisation link and restart the module.
To create a new user
1 Create a logical token.
2 Write one or more shares of this token onto software tokens.
3 For each key the user will require, export the key as a key blob under this token.
4 Give the user any pass phrases used and the key blob.
To authorize the user to create keys
1 Create a new key, with an ACL that only permits UseAsSigningKey. This action may need to be
authenticated.
2 Export this key as a key blob under the users token.
3 Create a certificate signed by the nCipher Security Officer’s key that:
• includes the hash of this key as the certifier
• authorizes the action GenerateKey or GenerateKeyPair depending on the type of key required.
• if the user needs to store the keys, enables the action MakeBlob, limited to their token.
4 Give the user the key blob and certificate.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
18
nCipher Rules
To authorize a user 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,
• Give the private half an ACL that permits Sign and UseAsSigningKey.
• Give the public half an ACL that permits ExportAsPlainText
4 Export the private half of the Junior Security Officer’s key as a key blob under this token.
5 Export the public half of the Junior Security Officer’s key as plain text.
• Create a certificate signed by the nCipher Security officer’s key includes the hash of this key as the
certifier
• authorizes the actions GenerateKey, GenerateKeyPair
• authorizes the actions GenerateLogicalToken, WriteShare and MakeBlob, these may be limited to a
particular module key.
6 Give the Junior Security Officer the software token, any pass phrases used, the key blob and certificate.
To authenticate a user 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 user can now perform the services specified in the ACL for this key.
Note 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.
To authenticate a user to create a new key
1 If you have not already loaded your user 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.
The nCipher modules security policy: nForce SCSI 75, nForce SCSI 150, nForce SCSI 300 v1.1.42
19
nCipher Algorithms
Algorithms
FIPS approved algorithms:
Non-FIPS approved algorithms
• CAST 5 (RFC2144)
• CAST 6 (RFC2612)
• Rijndael (AES)
• Blowfish
• Twofish
• Serpent
• Arc Four (compatible with RC4)
• El Gamal
• Diffie-Helman
• MD5
• MD2
• SHA-256
• SHA-384
• SHA-512
• RIPEMD 160
• HMAC (MD2, MD5, SHA-256, SHA-384, SHA-512, RIPEMD160)
• XOR (used in some key derivation mechanisms).
DES Certificate #24
DES MAC Compliant with FIPS 113
Verified implementation functions: genblk_signbegin,genblk_verifybegin,
genblk_macdata, genblk_signend,genblk_verifyend.
Triple DES Certificate #34
Double and triple length keys
Approved for Federal Government Use - Modes are CBC and ECB
Triple DES MAC Compliant with FIPS 113
Verified implementation functions: genblk_signbegin,genblk_verifybegin,
genblk_macdata, genblk_signend,genblk_verifyend
DSA/SHA-1 Certificate #11
RSA Vendor Affirmed to PKCS #1
HMAC SHA-1 Vendor Affirmed