privateserver™ hsm - electronic signature industry...

ARX | 855 Folsom St. Suite 939, San Francisco, CA 94107 | Tel. (415) 839-8161 | www.arx.com | [email protected]

PrivateServer™ HSM PCI-HSM v2.0 Security Policy May 2014

Document Version 1.2


Table of Contents

Notice ................................................................................................................................... 4

Trademarks ........................................................................................................................... 4

1. Overview .................................................................................................................... 5

1.1 Secure by Design ........................................................................................................................... 5

2. Modes of Operation ................................................................................................... 7

2.1 PCI Mode ....................................................................................................................................... 7

3. Security Functions and Key Management ................................................................... 8

3.1 Algorithms ..................................................................................................................................... 8

3.2 Key Management Schemes ........................................................................................................... 8

3.3 Secure Key Storage ........................................................................................................................ 9

4. Ports and Interfaces ................................................................................................. 10

4.1 Well Defined Ports....................................................................................................................... 10

5. Services .................................................................................................................... 12

5.1 Services Summary ....................................................................................................................... 12

5.2 Services and Roles ....................................................................................................................... 13

5.3 System Backup and Restoring ..................................................................................................... 14

5.4 Auditing ....................................................................................................................................... 15

5.5 PIN Block Translation ................................................................................................................... 15

6. Access Control Policy ................................................................................................ 17

6.1 Operator Roles ............................................................................................................................ 17

6.1.1 Supervisor (Crypto-Officer) Role.............................................................................................. 17

6.1.2 User/Application Role .............................................................................................................. 18

6.2 Identification and Authentication ................................................................................................ 18

6.2.1 RSA PKCS#1 Based Authentication .......................................................................................... 18

6.2.2 Password Based Authentication .............................................................................................. 19

6.2.3 Strengths of the Authentication Mechanisms ......................................................................... 19

7. Protected Items ........................................................................................................ 20

7.1 Initial Configuration ..................................................................................................................... 20


7.2 Critical Security Parameters ........................................................................................................ 20

8. Physical Security ....................................................................................................... 23

8.1 Deployment ................................................................................................................................. 23

8.2 Environmental Conditions ........................................................................................................... 23

8.3 Environmental Failure Conditions ............................................................................................... 23

8.4 Tamper Detection........................................................................................................................ 23

8.5 Module Inspection ...................................................................................................................... 23

9. Security Rules ........................................................................................................... 25

9.1 Self Tests ..................................................................................................................................... 25

9.1.1 Power-Up Self Tests................................................................................................................. 25

9.1.2 Periodic Self Tests .................................................................................................................... 25

9.1.3 Conditional Self Tests .............................................................................................................. 25

9.2 PrivateServer Decommission ....................................................................................................... 26

9.3 Key Replacement of Critical Server Keys ..................................................................................... 26

9.4 Additional Security Procedures ................................................................................................... 26


Notice This document contains information that is proprietary to ARX (Algorithmic Research Ltd).

ARX reserves the right to revise this publication and make any changes without obligation to notify any person of such revisions and changes.

For further information, contact ARX at the addresses below, or contact your local distributor.

Trademarks PrivateServer HSM, CoSign, CryptoKit, PrivateCard, and PrivateWire are trademarks of ARX Other names are trademarks or registered trademarks of respective owners and are used solely for identification purposes. Export license required.


1. Overview PrivateServer is a multi-chip, high-capacity, network-attached Hardware Security Module (HSM).

Contained within a secure, tamper-responsive steel case, the PrivateServer performs high-speed

cryptographic operations while protecting sensitive data. All keys and critical security parameters are

protected within the cryptographic boundary by the physical security mechanisms of the module.

PrivateServer delivers a validated-secure environment for cryptographic operations, data encryption and

key management.

The PrivateServer supports various cryptographic algorithms including AES for encryption and SHA-256

for hashing. It can be used to securely store secret/private keys and has the ability to maintain an internal

key database. The PrivateServer performs all cryptographic operations internally, and through self-tests it

ensures that these operations are functioning correctly. There is no room for error when protecting

mission critical data.

Advanced security features, such as strong user authentication, internal audit mechanisms, and strict

access rights to sensitive keys and operations, are all built-in the product.

The scope of PrivateServer’s certification covers the entire HSM enclosure.

1.1 Secure by Design

The PrivateServer is a multi-chip standalone module. PrivateServer hardware version 4.7 with firmware

version 4.8.2 has been designed to meet the requirements of PCI HSM v2.0. This version is an enhanced

version of PrivateServer that was certified for FIPS 140-2 Level 3. This means that the module provides

strong security both inside and out.

Encased within a tamper-responsive and tamper-evident steel box, the module both protects against and

reacts to attacks.

All vents on the module are baffled meet opacity requirements for physical security.

Access to the module is only permitted through specific, well-defined interfaces.


The security features of the module ensure that access to sensitive information is granted only to an

authorized operator. Tamper Evident cans provide evidence of any attempt to tamper with module cover.

The units are encased in a solid metal case rigged with micro-switches and only the specified physical

interfaces permit access to the module. Intrusion attempts cause power to be instantly cut off,

preventing access to any useful information by zeroizing all plaintext critical security parameters including

the PrivateServer Critical keys.

Two smart cards (Init Smartcard and Startup Smartcard) are used for the purpose of initializing the

module. The initialization must be done in a secure environment.

The above PrivateServer Critical Keys are split between these two smart cards. Thus it is mandatory to

insert both smartcards for a successful initialization of the module.

During initialization of the module, a part of the PrivateServer Critical Keys is kept inside the internal

tamper device. Therefore, for a normal startup of the module, it is only required to insert the Startup

smart card.

After a detected tamper, the PrivateServer must be re-initialized with both Init and Startup smart cards.

It is possible to configure PrivateServer such that there is no need to enter the Startup smart card as part

of starting the module. In this configuration all PrivateServer Critical keys content is kept inside the

internal tamper device and erased upon a tamper event. This setting can be done using the PrivateServer

console and is called Unattended Mode.

All services of the module must be carried out through a secure session.


2. Modes of Operation

2.1 PCI Mode

PrivateServer does not support a non-PCI mode. When PrivateServer version 4.8.2 is in PCI mode, there is

no way to change it to non-PCI mode.

The user can view the PCI state be running the PrivateServer management application, connecting to the

server and entering Server -> Properties dialog.


3. Security Functions and Key Management

3.1 Algorithms

PrivateServer supports the following algorithms:

Data Encryption/Decryption

Triple-DES (ANSI X9.52) in ECB and CBC modes – 128 bits, 192 bits

AES (FIPS PUB 197) in ECB and CBC modes – 128 bits, 192 bits and 256 bits

OAEP (PKCS#1 v2.1) (RSA 2048 – 4096 bit)

Data Integrity

Triple-DES-MAC - 128 bits, 196 bits

HMAC (SHA1, SHA-256, SHA-384, SHA-512), key size up to 511 bytes (FIPS PUB 198-1)

AES-CMAC (NIST Special Publication 800-38B, May 2005)

Triple-DES-CMAC (NIST Special Publication 800-38B, May 2005)

CCM (NIST Special Publication 800-38C, May 2004)

Message Digest

SHA-1 (FIPS PUB 180-1)

SHA-256, SHA-384, SHA-512 (FIPS PUB 180-4)

Random Number Generator

FIPS 186-2

RSA Key Generation

ANSI X9.31 (RSA 2048 – 4096 bit)

Digital Signature Generation and Verification

PKCS#1 v1.5 (RSA 2048 – 4096 bit)

PSS (PKCS#1 v2.1) (RSA 2048 – 4096 bit)

ANSI X9.31 (RSA 2048 – 4096 bit)

ECDSA (curves 256, 384 and 521)

3.2 Key Management Schemes

PrivateServer supports the following key management schemes:


DUKPT (ANSI X9.24-1:2009)

Key import/export as defined in ANSI TR-31:2010

Key import/export encrypted by KEK

Key import/export by parts

Note: It is forbidden to import or export keys using weaker keys as follows:

AES keys should not be encrypted by Triple DES keys

3.3 Secure Key Storage

PrivateServer stores all non-volatile keys in the database. The database is stored encrypted (with AES-

128) on the PrivateServer’s internal hard drive. Within the database, keys have properties associated with

them. These properties determine which operations may be performed on a particular key and establish

which users are authorized to carry out these operations.

There are two levels of access to the keys stored on the module, Owner and User. Each key maintains a

list of owner IDs and User IDs. This should not be confused with the User Role as both levels of access are

applicable to the User or Supervisor Role. The Owner of a key can perform all operations on the key and

can grant or revoke key access rights to other entities. The User of a key may access it for cryptographic

operations only and is not able to read the key or perform administrative functions on it.

When a user is authenticated to the PrivateServer, his/her user identity is defined. When accessing a key

for the purpose of management or usage, this user identity is checked against the owner IDs list or user

IDs list depending on the required operation.

User Keys are keys that are generated upon request or inputted by the user for various key operations.

User keys consist of two types of keys: User Normal Keys, and User Temporary keys. Users choose what

type of key they want to create or input. Users can generate or input any of the following key types: TDES

128 and 192 bit keys, AES 128, 192 and 256 bit keys, RSA 2048 to 4096 bit keys, ECDSA P-256, P-384 and

P-521 curves and Secret keys. The only difference is that a User Normal key can be reused whereas a User

Temporary key cannot. User Normal keys are stored in memory and then written to the database before

the close of a user session. User Normal keys can be reloaded by the user for a new user session. User

Temporary keys are only stored in memory and are erased upon close of a user session.


4. Ports and Interfaces

4.1 Well Defined Ports

The module is a hard, rack mountable box. The physical ports include the power connector, network

connections (Ethernet Interfaces using TCP/IP and UDP/IP), power switches, indicators, a monitor port, a

keyboard port, and one smart card reader. The module is encased in a steel cover, with only the specified

ports providing access to the module. All ports use standard PC pin outs.

The ports are shown in Figure 1. On the front of the module behind the access door you have a smart

card reader in the top middle. Below that, from left to right, you have an on/off button, keyboard port,

and three indicator lights. On the back of the module, left to right, you have the power connector and

power switch below the fan and the monitor port and two network connections on the top right. These

ports are all listed in table 2.

Figure 1 – Front and Rear interfaces


Through the network ports either an encrypted and RSA based authenticated sessions are permitted or a

user ID/password authenticated sessions are permitted over either ports when operating in PCI-HSM

mode.

The following table shows the mapping of the logical and physical interfaces of the module.

Logical Interface Physical Interface

Control input Ethernet ports and keyboard ports - input commands and input data

Power switch, power-on switch, reset button - input commands

Data input

Ethernet port - Plaintext data, ciphertext data, encrypted cryptographic

keys, device management data, device configuration data, authentication

data, status information, & other key management data

Smartcard reader - Device configuration data, cryptographic keys,

authentication data

Keyboard port - Authentication data, device management data

Data output Ethernet ports - Plaintext data, ciphertext data, encrypted cryptographic

keys, key management data, & device management data

Status output

Ethernet ports and monitor port - Output data, syslog based reports,

SNMP based reports

Indicators - Output Indicators

All requests for cryptographic services are done through the PrivateServer API. This API, written primarily

in C and based on RPC (Remote Procedure Calls), provides a high-level interface to the cryptographic

services provided by the module, thus masking many of the complexities of cryptography from the

developer.

Status information can also be sent via syslog protocol to a syslog server or via SNMP traps to an SNMP

server. This status information is sent using the network ports of the module.

A special license can enable PrivateServer printing codes to a network printer. A client application will

interface PrivateServer through the normal data input interface. The application will either send the code

encrypted or direct the PrivateServer service to calculate a new code for the given user. The code will be

sent non-encrypted to the network printer that will use a special paper for concealing the code.


5. Services

5.1 Services Summary

The following table provides a high-level summary of the services provided by the module.

Service Information Summary

Key management and control

Secure storage and management of cryptographic keys (Triple-

DES/AES keys, RSA public and private keys, ECDSA public and private

keys, HMAC secret data and Special-purpose keys).

In the case of user ID/password authentication, keys cannot be

imported or exported in clear format to/from the HSM.

User management

Define users, their roles, permissions and access level.

Change password and set password operations can be done only

when using an authenticated and encrypted session.

Public-key database Centralized storage and management of public keys (RSA public keys

and ECDSA public keys).

Data encryption and decryption Symmetric [Triple-DES, AES] and Asymmetric Cryptography.

Digital signatures

Generate and verify digital signatures (RSA and ECDSA). The RSA

digital signature generation supports the following schemes: PKCS#1

v1.5, PSS and ANSI X9.31. Also, digital signature verification service is

supported based on the above algorithms.

Data hashing and data integrity Generate message digests [SHA-1, SHA-256, SHA-384 and SHA-512

(FIPS 180-2)], HMAC/Triple-DES-CMAC/AES-CMAC/AES-CCM.

User authentication

Two-way user authentication using the RSA challenge-response key

distribution mechanism. A smartcard token can be used. Also, for

local access by the Supervisor a smartcard can be used.

A user ID /password authentication mechanism can also be used.

Logging, auditing, secure auditing, administration, and management

Administrative and management operations as well as logging and

auditing. Audit log can be signed.

Code Mailing An interface to a Network printer for the purpose of producing a

Code mailer.

Internal real-time clock Used for accurate time stamps.


Service Information Summary

Get PrivateServer Details This anonymous API function csv_get_csv_cert replies with the

PrivateServer Identity and the public key of PrivateServer.

5.2 Services and Roles

The following table shows each specific service and which role has access to it.

Category Service Role Input Output

Server Console Operations

Initializing the HSM and its database

SO Init and Startup smart cards

Starting the module SO Startup smart card

Configuring the module’s IP information

SO Startup smart card

Resetting tamper condition SO Init and Startup smart cards

Server Management

Perform backup SO None Encrypted Backup File

Restore backup SO Encrypted Backup File

Success Code

Retrieve log file SO None Log File

Reset the log file SO, dual control

None Success Code

Perform firmware update SO Updated Firmware Success Code

Define code mailing parameters

SO Mailing Info Success Code

Perform shutdown SO None None

User Management

Create user SO New User Information

Success Code

Retrieve user information SO User ID User Information

Update user record SO User ID Success Code

Revoke user SO User ID Success Code

Session Management

Retrieve information about all open sessions

SO None Information about active sessions

Terminate a session SO Session ID Success Code

Key Management

Generate key SO Key ID Key Information

Import key or key part SO Key ID Key Information

Export key or key part SO Key ID Key Information

Retrieve al information about any key, except its value

SO Key ID Key Information

Update key record SO Key ID Success Code

Delete any key SO Key-ID Success Code

Cryptography Symmetric cryptography SO/User Key ID, Input Buffer Output Buffer


Category Service Role Input Output

Asymmetric cryptography SO/User Key ID, Input Buffer Output Buffer

Hashing SO/User Key ID, Input Buffer Output Buffer

Magnetic stripe services SO/User Key ID, Input Buffer Output Buffer

EMV services SO/User Key ID, Input Buffer Output Buffer

Code mailing services SO/User Key ID, Input Buffer Output Buffer

All SO services should be performed over RSA based authenticated and encrypted session, preferably

using a smart card.

For more information, please refer to PrivateServer API Guide v4.8.

5.3 System Backup and Restoring

The security Officer can backup the complete PrivateServer’s database, including all keys, users, owners,

and other configuration information. The backup operation creates an encrypted backup file. The critical

server backup encryption key is loaded into the PrivateServer from the Init and Startup smart cards during

the server initialization process.

The backup procedure should be performed by the Security Officer and includes the following steps:

From a client machine, run the PrivateServer management utility

Open an authenticated session with PrivateServer as Security Officer

In the Servers View window select the PrivateServer

From the menu, select Server -> Backup option

Specify the path for the backup file or click the Browse button to browse to its location.

Click Backup

Keep the encrypted backup file in a secure place

Similarly, it is possible to restore a backup file into PrivateServer. This operation can be done by the

Security Officer. The backup file can only be restored into a PrivateServer that was initialized by the same

set of Init and Startup smart cards that were used to initialize the Server from which the backup file was

produced.

The restore procedure should be performed by the Security Officer and includes the following steps:




From the menu, select Server -> Restore option

Enter the path of the backup file to use for the restore operation, or click the Browse button to

browse to its location

Click Restore


5.4 Auditing

PrivateServer maintains a log file that resides on the non-volatile media. The log file contains detailed

information messages such as:

Administrative operations: backup, restore, creation and deletion of users, configuration settings,

startup and shutdown operations

Key management operations: key generation, import, deletion, split and build from key parts etc.

Key usage: signing operations, asymmetric decryption

User activity: successful and unsuccessful connection, key access

Other: every action that failed for example failed key access

The Security Officer should perform a scheduled retrieval of the signed PrivateServer log file. It is

recommended to perform at least a weekly inspection of the audit log.

PrivateServer also supports syslog and SNMP (Simple Network Management Protocol) standards. Syslog

can be used for logging program messages in a separate server. SNMP can be used for managing devices

on IP networks. The PrivateServer can be queried for performance information over the standard MIB-2

(Management Information Base) objects. Additional applicative information is sent from PrivateServer as

SNMP traps. However, both Syslog and SNMP do not meet the PCI requirements that log data should be

protected from unauthorized modification, substitution, and deletion. Therefore a signed audit log should

be retrieved periodically.

To retrieve the signed audit log the Security Officer should perform the following steps:




From the menu, select Server -> Retrieve Log File option

Click Save Log File to save the audit file, and specify the name and location where the file should be

saved

Check the Sign the PrivateServer log file check box

Click OK to save the signed log file

5.5 PIN Block Translation

PrivateServer supports all available PIN block formats: ISO_0, ISO_1, ISO_2, ISO_3 and ANSI. If needed, it

is possible to specifically enable/disable certain translations.

To set the allowed PIN block formats the Security Officer should perform the following steps:





From the menu, select Server -> Settings option

Select the PINSTD tab

In the Permitted PIN Block Formats, disable ISO_2 as Reformat Input and disable ISO_1 and ISO_2 as

Reformat Output block format.

Select which PIN block formats are allowed for reformatting input, reformatting output, and for other

PINSTD functions

Click Apply

Restart the PrivateServer for the changes to take effect


6. Access Control Policy

6.1 Operator Roles

The PrivateServer supports multiple, simultaneous operators. A database record entry is created by the

PrivateServer for each operator and contains the operator name, authorization bits, quotas for operator

temporary keys created by the operator, the certifier of the operator, and the minimum access level. The

authorization mask controls the operator’s permissions.

There are two operator roles: Supervisor (Crypto-Officer) role and user/application role.

6.1.1 Supervisor (Crypto-Officer) Role

The Supervisor is responsible for operator and key management, module initialization and startup, and

the module’s configuration. All authorization bits are turned on (i.e., FFFFFFFF) for the Supervisor,

providing the following management functionality:

Perform backup of all data in the module

Restore previously backed up data

Retrieve information from the log file

Reset the log file

Perform firmware update

Define code mailing parameters

Perform shutdown

Create user

Retrieve user information

Update user records

Revoke user

Retrieve information about all open sessions

Terminate a specific session

Generate keys

Import key or key part

Export key or key part

Retrieve all information about any key, except its value

Update key record

Delete any key (besides Special-Purpose keys)

In addition, the Supervisor can access all cryptographic and miscellaneous services, including:

Symmetric cryptographic services – enable client applications use keys kept in PrivateServer for

symmetric operations.


Asymmetric cryptographic services – enable client applications use keys kept in PrivateServer for

asymmetric operations.

Hashing services – enable client applications use keys kept in PrivateServer for hashing operations.

Magnetic stripe services – PIN verification, PIN translation etc.

EMV services – card issuance, authorization and data preparation

Code mailing services

By connecting directly through the PrivateServer, the Supervisor has the ability to access certain

management operations of the module, including:

Initializing the module and its databases

Starting the module

Configuring the module’s IP information

Resetting a tamper condition

6.1.2 User/Application Role

The User/Application is for accessing the cryptographic services provided by the module. The User logs

into the module remotely through the PrivateServer Client that communicates with the PrivateServer

application program interface using RSA challenge-response or password based authentication protocols.

None of the authorization bits are turned on for the User, the User can only access the following services:

Symmetric cryptographic services - enable client applications use keys kept in PrivateServer for

symmetric operations

Asymmetric cryptographic services – enable client applications use keys kept in PrivateServer for

asymmetric operations

Hashing services – enable client applications use keys kept in PrivateServer for hashing operations.

PIN block services – verification, translation etc.

EMV services – card issuance, authorization and data preparation

Code mailing services

6.2 Identification and Authentication

A User must first authenticate to the module. PrivateServer supports two identification and

authentication schemes: RSA based authentication scheme (the user must connect to the HSM with a

smart card or software token) or a user ID / password authentication scheme.

6.2.1 RSA PKCS#1 Based Authentication

The RSA challenge-response mechanism requires the exchange and verification of the operator’s private

key. All keys used for authentication are private keys generated externally and certified by a CA signature.

In this scheme, after a successful authentication, an encrypted session is created. The RSA challenge-

response protocol used by the module is a key distribution scheme, used to authenticate the operator


and to establish a temporary session key (that is destroyed at the close of the session). Through this

session, the operator may perform the cryptographic services for which they have permissions.

The session keys (MAC and encryption/decryption) are negotiated during authentication of a user when

creating a session. The PrivateServer creates these keys during the opening of an encrypted session, and

they are destroyed when the session is terminated. These keys are temporary and are only stored in

volatile memory.

6.2.2 Password Based Authentication

In password based authentication, the password is presented as a cryptogram (SHA-256), calculated from

a random and salt numbers produced by the HSM. The minimum password length is 6 characters long.

In this scheme, after a successful authentication, a non-encrypted session is created. Through this

session, the operator may perform the cryptographic services for which they have permissions.

Any operation that either imports a key or exports a key from the module is restricted when this scheme

is used. Also, any change or set password or operation is restricted and must be done using the above

RSA based secured session.

6.2.3 Strengths of the Authentication Mechanisms

The RSA based authentication provides 1 in 2^161/(1000*60) probability of a successful random

attempt during a one-minute period.

The UID/Password authentication uses passwords that are at least 6 characters long. This yields a

minimum of 72^6 (over 1,000,000,0000) possible combinations.


7. Protected Items The protected items are contained within the cryptographic boundary and must be protected against

unauthorized access. The cryptographic boundary of PrivateServer includes the whole appliance. The

protected items such as CSPs (Critical Security Parameters) are stored inside the tamper proof tamper

evident enclosing.

7.1 Initial Configuration

The PrivateServer has three AES-128 Critical keys which are generated using an external smart card

reader. One half of each of the Critical keys is stored on the Startup smartcard and the other three halves

are stored on the Initialization smart card. The Critical keys are then created by XORing the split keys from

the Startup smart card and Initialization smart card and loading the result into the PrivateServer’s volatile

memory during startup. These keys are only stored in volatile memory. All three keys are erased from

memory when the module is terminated.

The three critical keys are used for the following internal operations:

Encrypting key values in the keys database

Checking the integrity of database records using a MAC key

Encrypting the database during a backup operation

The Special-Purpose keys are only used for internal operations on the PrivateServer. These keys include

the customer’s organization-wide root public key, PrivateServer’s RSA private/public key pair, the

PrivateServer critical Keys, and the PrivateServer key for continuous operations context encryption.

Public keys and certificates stored in the public key database are inaccessible through anonymous

services. Certificates loaded onto the module must be signed by the organization’s private key and this

signature is verified before addition to the public key database.

In the PCI-HSM mode of operation, all operator sessions are authenticated and encrypted so that no

secret or private keys are passed in or out of the module unprotected.

In the case of a User ID/Password authenticated session, no key can be imported or exported from the

module in clear format. Also any change password or set password operation can be done over an

authenticated and encrypted session.

The module also provides the ability to back up the key database in encrypted form.

7.2 Critical Security Parameters

The following table lists all the keys, their key types, and access control.


Cryptographic Keys and CSPs Key Type Key Generation/Establishment

Access (R/W1/X2)

Firmware Encryption Key AES 128 Hard Coded in the firmware

X

Firmware Signature Key Public RSA 2048 Hard Coded in the firmware

X

Critical Key for key value encryption of database keys

AES 128

Imported to PrivateServer during Module Initialization from Init Smartcard and Startup Smartcard

X

Critical Key for Backup encryption

AES 128

to PrivateServer during Module Initialization from Init Smartcard and Startup Smartcard

X

Critical Key for database Record MAC calculation

AES 128

Imported to PrivateServer during Module Initialization from Init Smartcard and Startup Smartcard

X

Key for continuous operations context encryption

AES 128 Generated during session initialization

X

PrivateServer RSA Public/private key pair

RSA 1024 bit key Generated during Module initialization

X

Organization Root Public Key RSA 1024 bit key Generated during Module initialization

X

ARX RSA public key for firmware signature verification

RSA 2048 bit key Hard Coded in the firmware

X

Session encryption/decryption keys

AES 128 Temporary key is generated during session initiation

X

Session MAC keys AES 128 Temporary key is generated during session initiation

X

1 W or R is relevant to User keys that can be imported or exported via encrypted session, depending on

the key definitions

2 X means that the key is used for executing cryptographic operation


Cryptographic Keys and CSPs Key Type Key Generation/Establishment

Access (R/W1/X2)

User keys (Two types: user Normal keys and user Temporary keys)

Different key types:

TDES 128 and 192 bit

keys,

AES 128, 192 and 256 bit

keys,

RSA Private Key 2048 to

4096 bit keys,

RSA Public Key 2048 to

4096 bit keys,

HMAC/Triple-DES-

CMAC/AES-CMAC/AES-

CCM secret data,

ECDSA P-256, P-384 and

P-521 keys

Generated by PrivateServer or imported from the PrivateServer client API (uploaded securely via PrivateServer secure connection).

R, W, X

Public key certificates RSA 1024 bit public keys stored in certificates

Uploaded in first connection attempt or the user

W, X

RSA based User Authentication

Authentication of operators uses RSA challenge-response mechanism

Used by user’s key medium during session initiation

X

UID/Password Authentication At least 6 character long Used during session initiation

X

Password Authentication for

console based authentication At least 6 alphanumeric characters long

Used when operator access startup smartcard when physically accessing the module

X


8. Physical Security This section details the physical security mechanisms that protect the PrivateServer HSM and the actions

operators must take to ensure the physical security is maintained.

8.1 Deployment

The PrivateServer HSM must be initialized and deployed in a secure controlled environment.

8.2 Environmental Conditions

The operational and environmental conditions for which the PrivateServer HSM was designed are:

Ambient Temperature - Operating: - 5ºC to 35ºC , Non-operating: - 20ºC to 65ºC

Relative Humidity - Operating: 20% - 80%(NC) , Non-operating: 10% - 90%(NC)-

Input Voltage - 115V AC to 230V

8.3 Environmental Failure Conditions

The PrivateServer hardware is based on standard PC components that will immediately stop functioning

when the temperature range or power range exceeds.

The internal Intel CPU will stop when high temperature exceeds.

The power-supply has an over voltage protection

(see http://www.fspgroupusa.com/fsp30060pln/p/638.html).

8.4 Tamper Detection

Encased within a tamper-responsive and tamper-evident steel box, the module both protects against and

reacts to attacks.

The units are encased in a solid metal case rigged with micro-switches and only the specified physical

interfaces permit access to the module. Intrusion attempts cause power to be instantly cut off,

preventing access to any useful information by zeroizing all plaintext critical security parameters including

the PrivateServer Critical keys.

All vents on the module are baffled meet opacity requirements for physical security.

8.5 Module Inspection

The cryptographic officer must perform a scheduled daily inspection of the module to detect tamper

evidence. The cryptographic officer shall inspect three areas for tamper evidence:

The cryptographic officer shall inspect the tamper led in the front panel of the PrivateServer HSM and

verify there is no tamper indication in the console.

The cryptographic officer shall inspect both of the Tamper Evident cans, which are located on the

back of the module.


The cryptographic officer shall check the module’s physical encasing to verify there was no physical

tampering.


9. Security Rules

9.1 Self Tests

9.1.1 Power-Up Self Tests

Low-Level Hardware Tests: When power is first applied to the module, the hardware performs a series

of checks to ensure it is functioning properly.

Firmware Integrity Test: After the hardware tests the module performs RSA digital signature

verification to ensure firmware has not been modified. The firmware signature is based on PKCS#1

v1.5 signature algorithm with RSA-2048 bit key and SHA-256.

Cryptographic Algorithm Tests: Known Answer Tests (KATs) are run at power-up for the Triple DES and

AES encryption/decryption, Message Authentication Codes, RSA and Hash Algorithms. The ECDSA is

tested using a sign/verify operation.

9.1.2 Periodic Self Tests

Firmware Integrity Test: After the hardware tests the module performs RSA digital signature

verification to ensure firmware has not been modified. The firmware signature is based on PKCS#1

v1.5 signature algorithm with RSA-2048 bit key and SHA-256.

Cryptographic Algorithm Tests: Known Answer Tests (KATs) are run at power-up for the Triple DES and

AES encryption/decryption, Message Authentication Codes, RSA and Hash Algorithms. The ECDSA is

tested using a sign/verify operation.

Random Seed Test: A periodic random test is performed every 30 seconds when a new random seed

is generated.

9.1.3 Conditional Self Tests

RSA pair-wise Consistency Test: the test is performed when RSA key pair is generated to ensure the

correct operation of the RSA key. The test performs sign/verify, encrypt/decrypt operations.

EC pair-wise Consistency Test: the test is performed when EC key pair is generated to ensure the

correct operation of the EC key. The test performs sign/verify operations.

Continuous Random Test: A random number test is performed for every block of 8 random bytes

produced by the PRNG.

Continuous Random Seed Test: A random number test is performed for every block of 8 random bytes

produced by the internal hardware.

Firmware Update Test: the test is performed when a new signed and encrypted firmware is loaded

into the PrivateServer. The signature of the uploaded firmware is based on PKCS#1 v1.5 signature

algorithm with RSA-2048 bit key and SHA-256.


9.2 PrivateServer Decommission

In the event of PrivateServer decommission, special measures should be taken to verify that no sensitive

keys and other cryptographic material are left.

To permanently dismantle PrivateServer perform the following procedure:

Create a new set of dummy Root, Init and Startup smart cards

Initialize the PrivateServer with the dummy set of smart cards to erase the database from the hard

disk and prevent future restore operation on this machine

Destroy the Root, Init and startup smart cards

Destroy the PrivateServer hard disk:

Break the tamper seals at the back of the appliance

Unscrew the screws and open the box

Remove the PrivateServer hard disk and destroy it

Delete all copies of database backup files

9.3 Key Replacement of Critical Server Keys

Whenever there is a known or suspected compromise of the server keys (Critical Key for Backup

encryption, Critical Key for database Record MAC calculation and Key for continuous operations context

encryption), or the time deemed feasible to determine the key by exhaustive attack elapses, a key

replacement procedure must be applied.

The procedure should be performed by the Security Officer and includes the following steps:

Generate a new set of Init and Startup smart cards

From a client machine, authenticate to the PrivateServer as Security Officer and load a special Key

Replacement module

From the PrivateServer console, run the Key Replacement module

Insert the old set of smart cards and then insert the new set of smart cards

Wait until the module re-encrypts and MACs the PrivateServer database with the new set of keys

Restart the server to unload the key replacement module from memory

Backup the PrivateServer database. The new backup will be done using the new set of keys

9.4 Additional Security Procedures

A key that is stored in PrivateServer’s database should be replaced whenever a compromise of the

key value is suspected or known and whenever the time deemed feasible to determine the key by

exhaustive attack elapses.

The Security Officer should periodically retrieve the signed PrivateServer audit log and inspect it for

any security events that might have occurred. The audit log should be kept.


The Security Officer should periodically perform backup of the PrivateServer’s database and keep

them in a secure location.

privateserver™ hsm - electronic signature industry...

Documents