CryptoServer Manual Systemadministrators

CryptoServer
Administration Manual
Imprint
Copyright 2018 Utimaco IS GmbH

Germanusstr. 4
D-52080 Aachen
Germany
Phone +49 (0)241 / 1696-200
Fax +49 (0)241 / 1696-199
Internet http://hsm.utimaco.com
E-mail hsm@utimaco.com
Document version 2.10.2
Date 2018-08-21
Status Final
Document No. M010-0001-en
All Rights reserved No part of this documentation may be reproduced in any form (printing, photocopy or
according to any other process) without the written approval of Utimaco IS GmbH or
be processed, reproduced or distributed using electronic systems.
Utimaco IS GmbH reserves the right to modify or amend the documentation at any
time without prior notice. Utimaco IS GmbH assumes no liability for typographical
errors and damages incurred due to them.
All trademarks and registered trademarks are the property of their respective owners.
Table of Contents
Table of Contents
1 Introduction ................................................................................................................................... 11
1.1 About this Manual ..........................................................................................................................11
1.1.1 Target Audience for this Manual ..............................................................................................11
1.1.2 Contents of this Manual ...........................................................................................................11
1.1.3 Document Conventions ............................................................................................................11
1.1.4 Abbreviations............................................................................................................................12
1.2 Other Manuals ................................................................................................................................13
2 CryptoServer Overview ................................................................................................................... 16
2.1 Administration of the CryptoServer................................................................................................17
2.1.1 CryptoServer Administration Tool (CAT) ..................................................................................17
2.1.2 CryptoServer Command-line Administration Tool (csadm)......................................................18
2.1.3 Menu Options on the CryptoServer LAN ...................................................................................18
2.2 Smartcards, PIN Pads and Keyfiles ................................................................................................18
2.2.1 Smartcards ...............................................................................................................................18
2.2.2 PIN Pads ...................................................................................................................................19
2.2.3 Keyfiles .....................................................................................................................................21
2.3 Implementation Environment with a CryptoServer PCIe ................................................................21
2.4 Implementation Environment with One or More CryptoServer LANs .............................................23
2.5 Hardware ........................................................................................................................................24
2.5.1 CryptoServer Series ..................................................................................................................24
2.5.2 CryptoServer Models ................................................................................................................25
2.5.3 CryptoServer Variants ..............................................................................................................26
2.5.4 IRAM and Key-RAM ..................................................................................................................26
2.5.4.1 IRAM ................................................................................................................................ 26
2.5.4.2 Key-RAM.......................................................................................................................... 26
2.5.5 Cryptographic Accelerator Chip ...............................................................................................27
2.5.6 Random Number Generator (RNG) ...........................................................................................27
2.5.7 Physical External Housing ........................................................................................................27
2.5.8 Sensors .....................................................................................................................................28
2.5.9 Tamper-protecting Foil .............................................................................................................28
2.5.10 Power Supply Monitoring .........................................................................................................28
2.5.11 Temperature Monitoring ...........................................................................................................32
2.6 An Alarm and Its Consequences.....................................................................................................34
2.7 The Software of the CryptoServer ..................................................................................................35
2.7.1 Bootloader ................................................................................................................................35
2.7.2 Firmware Modules ....................................................................................................................35
Page 3 of 203
Table of Contents
2.7.3 Firmware Package ....................................................................................................................37

2.8 System Keys ...................................................................................................................................37
2.8.1 Default Authentication Key ......................................................................................................37
2.8.2 Individual Device Key................................................................................................................38
2.8.3 Master Backup Key (MBK) ........................................................................................................38
2.8.4 Tenant Backup Keys .................................................................................................................39
2.9 Operating States.............................................................................................................................41
2.9.1 INITIALIZED Operating State ....................................................................................................41
2.9.2 DEFECT Operating State ...........................................................................................................41
2.10 Operating Modes ............................................................................................................................42
2.10.1 Operational Mode .....................................................................................................................42
2.10.1.1 Administration-Only Mode .......................................................................................... 42
2.10.2 Maintenance Mode ...................................................................................................................43
2.11 External Erase.................................................................................................................................43
2.12 Clear ...............................................................................................................................................44
2.13 Clear to Factory Settings ................................................................................................................45
2.14 Users, User Groups and Authentication .........................................................................................45
2.14.1 Users .........................................................................................................................................45
2.14.2 User Groups ..............................................................................................................................46
2.14.3 Permissions and Authentication Status ...................................................................................46
2.14.4 Permissions for New Users ..................................................................................................... 50
2.14.5 Authentication Mechanisms.................................................................................................... 50
2.14.6 Authentication Mode ................................................................................................................52
2.14.7 ADMIN, the Default Administrator ............................................................................................53
2.14.8 Cryptographic User ...................................................................................................................54
2.15 Configurable Role-based Access Control (C-RBAC) .......................................................................55
2.16 Secure Messaging ..........................................................................................................................55
2.17 Logs ................................................................................................................................................56
2.17.1 Boot Log ...................................................................................................................................56
2.17.2 Audit Log ..................................................................................................................................57
2.18 Backing up, Restoring and Cloning Databases...............................................................................58
2.19 Cryptographic Interfaces ................................................................................................................59
2.19.1 Cryptographic eXtended Interface (CXI)...................................................................................59
2.19.2 PKCS#11...................................................................................................................................59
2.19.3 Microsoft CryptoAPI and Cryptography API: Next Generation (CNG) ..................................... 60
2.19.4 Java Cryptography Extension (JCE) .........................................................................................61
2.19.5 OpenSSL ...................................................................................................................................61
Page 4 of 203
Table of Contents
2.19.6 Extensible Key Management (EKM) .........................................................................................61

2.20 Interface Hardening by Disabling Selected Functions ...................................................................62
2.21 Clustering for Load Balancing and Failover ...................................................................................62
2.21.1 Concept Overview .....................................................................................................................62
2.21.2 Preconditions ...........................................................................................................................65
2.21.3 Use of External and Internal Key Storage.................................................................................66
2.21.4 Configuration Settings .............................................................................................................67
2.22 CryptoServer Simulator ..................................................................................................................68
2.22.1 Features Overview ....................................................................................................................68
2.22.2 Deployment Purpose ............................................................................................................... 70
2.22.3 Physical Protection ..................................................................................................................71
2.22.4 Sensor Detection ......................................................................................................................71
2.22.5 Cryptographic Accelerator Chip ...............................................................................................72
2.22.6 CryptoServer Series ..................................................................................................................72
2.22.7 Starting the Simulator ..............................................................................................................72
2.22.8 Multiple Connections ................................................................................................................73
2.22.9 Device Address .........................................................................................................................73
2.22.10 Firmware Module Files .............................................................................................................74
2.22.11 csadm Commands ....................................................................................................................74
3 Installing the CryptoServer Host Software ...................................................................................... 76
3.1 System Requirements ....................................................................................................................76
3.2 Prepare for Installation...................................................................................................................77
3.3 Performing the Installation for Windows .......................................................................................77
3.3.1 Installing the Host Software and CryptoServer Simulator .......................................................78
3.3.2 Using the CryptoServer Simulator ............................................................................................79
3.3.3 Starting Multiple CryptoServer Simulator Instances ............................................................... 80
3.3.4 Setting up Java Cryptography Extension (JCE) for Windows ..................................................82
3.3.5 Installing the PIN Pad Driver ....................................................................................................83
3.4 Performing the Installation for Linux .............................................................................................85
3.4.1 Installing csadm .......................................................................................................................85
3.4.2 Installing CAT ...........................................................................................................................85
3.4.3 Installing and Using the CryptoServer Simulator .....................................................................86
3.4.4 Starting Multiple CryptoServer Simulator Instances ................................................................88
3.4.5 Setting up Java Cryptography Extension (JCE) for Linux ........................................................89
3.4.6 Configuring the PIN Pad .......................................................................................................... 90
4 Administering the CryptoServer with CAT ....................................................................................... 91
4.1 CAT - Overview of the Graphical User Interface (GUI) ....................................................................91
4.2 Setting Up a New Device ................................................................................................................93
Page 5 of 203
Table of Contents
4.3 Switching between Devices ............................................................................................................95

4.4 Setting up a PIN Pad under Windows.............................................................................................95
4.5 Setting up a PIN Pad under Linux...................................................................................................96
4.6 User Login.......................................................................................................................................97
4.7 Setting the Time in the CryptoServer .............................................................................................97
4.8 Generating an MBK.........................................................................................................................99
4.9 Changing the Authentication Key ................................................................................................ 102
4.10 Changing the PIN for Smartcards ............................................................................................... 103
4.10.1 Changing the PIN for the Authentication Key ....................................................................... 103
4.10.2 Changing the PIN for the MBK Smartcards ........................................................................... 103
4.11 Setting up Microsoft CryptoAPI and Cryptography API: Next Generation (CNG) ........................ 104
4.12 Setting up JCE ............................................................................................................................. 104
4.12.1 Setting up a User for JCE ...................................................................................................... 105
4.12.2 Modifying the Device Address and User Name in the File CryptoServer.cfg......................... 106
4.13 Setting up CXI .............................................................................................................................. 108
4.14 Setting up Extensible Key Management (EKM) ........................................................................... 110
4.14.1 Setting up an EKM User ......................................................................................................... 110
4.14.2 Modifying the Device Address in the File cssqlekm.cfg ........................................................ 111
4.14.3 Creating a Credential on the SQL Server ............................................................................... 113
5 Maintaining the CryptoServer ....................................................................................................... 114
5.1 Resetting an Alarm ...................................................................................................................... 114
5.2 Updating the Firmware of the CryptoServer ................................................................................ 115
5.3 Performing a Clear....................................................................................................................... 117
5.4 Performing a Clear to Factory Settings ....................................................................................... 117
5.4.1 Performing an External Erase ................................................................................................ 118
5.4.2 How to Perform a Clear to Factory Settings? ........................................................................ 122
5.5 Setting up the CryptoServer after a Clear/Clear to Factory Settings .......................................... 122
5.5.1 Importing the SecurityServer Package into the CryptoServer .............................................. 123
5.5.2 Generating and Importing an MBK ........................................................................................ 124
5.6 Managing Smartcards and Keys.................................................................................................. 125
5.6.1 Generating a Key on a Smartcard .......................................................................................... 125
5.6.2 Restoring a Key from a Backup on Smartcards .................................................................... 126
5.6.3 Copying a Key Backup from One Smartcard to another Smartcard ...................................... 127
5.6.4 Changing the PIN for a Smartcard......................................................................................... 128
5.6.5 Displaying the Contents of a Smartcard................................................................................ 128
5.6.6 Generating a Key as a Keyfile ................................................................................................ 128
5.6.7 Changing the Password for a Keyfile .................................................................................... 129
Page 6 of 203
Table of Contents
5.6.8 Copying a Keyfile to a Smartcard (Backup) ........................................................................... 130

5.7 User Management ....................................................................................................................... 130
5.7.1 User Profiles .......................................................................................................................... 130
5.7.2 Creating a User ...................................................................................................................... 133
5.7.3 Deleting a User ...................................................................................................................... 135
5.7.4 Creating a User Data Backup ................................................................................................. 136
5.7.5 Restoring User Data............................................................................................................... 136
5.7.6 Changing a User Authentication Token ................................................................................. 137
5.8 Master Backup Key Management................................................................................................ 138
5.8.1 Generating an MBK ................................................................................................................ 138
5.8.2 Importing an MBK .................................................................................................................. 140
5.8.3 Creating an MBK Backup ....................................................................................................... 142
5.8.4 Changing the PIN for an MBK Smartcard .............................................................................. 144
5.8.5 Retrieving MBK Information .................................................................................................. 144
5.9 Preparing Diagnostic Information ............................................................................................... 145
5.9.1 Showing the CryptoServer Status ......................................................................................... 146
5.9.2 Listing All Files ...................................................................................................................... 151
5.9.3 Listing the Firmware .............................................................................................................. 151
5.9.4 Viewing the Boot Log............................................................................................................. 153
5.9.5 Deleting Displayed Log Entries .............................................................................................. 154
5.9.6 Saving Displayed Log Entries ................................................................................................ 154
5.9.7 Viewing CryptoServer's Battery State.................................................................................... 154
5.9.8 Viewing Driver Information .................................................................................................... 155
5.9.9 Retrieving and Saving the Audit Log ..................................................................................... 155
5.9.10 Configuring the Audit Log Files ............................................................................................. 156
5.9.11 Deleting an Audit Log in the CryptoServer ............................................................................ 158
5.10 Backing up Databases ................................................................................................................. 158
5.11 Restoring Databases ................................................................................................................... 159
5.12 Cloning Databases ....................................................................................................................... 160
6 Contact Address for Support Queries ........................................................................................... 163
Appendix A Audit Log Entries .......................................................................................................... 164
A.1 Overview ...................................................................................................................................... 164
A.2 OS_AUDIT_CLASS_FIRMWARE .................................................................................................... 171
A.3 OS_AUDIT_CLASS_USER ............................................................................................................. 172
A.4 OS_AUDIT_CLASS_TIME .............................................................................................................. 173
A.5 OS_AUDIT_CLASS_STARTUP....................................................................................................... 173
A.6 OS_AUDIT_CLASS_AUDIT ............................................................................................................ 175
A.7 OS_AUDIT_CLASS_MBK ............................................................................................................... 175
Page 7 of 203
Table of Contents
A.8 OS_AUDIT_CLASS_KEY ................................................................................................................ 176

A.9 OS_AUDIT_CLASS_AUTH_SUCCESS ............................................................................................ 179
A.10 OS_AUDIT_CLASS_AUTH_FAILED................................................................................................ 179
A.11 OS_AUDIT_CLASS_BACKUP_RESTORE ....................................................................................... 180
A.12 OS_AUDIT_CLASS_SYSTEM......................................................................................................... 181
A.13 Class reserved for future use ...................................................................................................... 183
A.14 OS_AUDIT_CLASS_CUSTOM_MASK............................................................................................. 183
A.15 OS_AUDIT_CLASS_ALWAYS ........................................................................................................ 183
A.16 Special Audit Message Class....................................................................................................... 185
Appendix B Supported Algorithms ................................................................................................... 186
B.1 CXI API......................................................................................................................................... 186
B.2 CSP/CNG API ............................................................................................................................... 188
B.1 PKCS#11 API ............................................................................................................................... 189
B.1 JCE API ........................................................................................................................................ 196
References ........................................................................................................................................... 203
Page 8 of 203
Table of Contents
Page 9 of 203
Introduction
1 Introduction
Thank you for purchasing our CryptoServer security system. We hope you are satisfied with
our product. Please do not hesitate to contact us if you have any questions or comments.
1.1 About this Manual

This manual provides information about the CryptoServer functions and contains solution-
oriented information about how to use the CryptoServer Administration Tool (CAT) to set up,
manage and maintain the CryptoServer/CryptoServer LAN all series.
1.1.1 Target Audience for this Manual

This manual is primarily intended for administrators who use the CryptoServer administration
tool (CAT) to administer the CryptoServer or CryptoServer LAN all series.
1.1.2 Contents of this Manual

After the introduction, this manual is divided up into two main areas:
Functional description
This part of the manual, which runs in chapters 2, “CryptoServer Overview” and 3, “Installing
the CryptoServer Host Software”, gives you all important information about the CryptoServer
functions you require in order to operate it correctly and effectively.
Operating instructions
This part of the manual, which covers chapters 4, “Administering the CryptoServer with CAT”,
and 5, “Maintaining the CryptoServer”, provides solution-oriented information about how to
use the CAT to set up, manage and maintain the CryptoServer.
1.1.3 Document Conventions

We use the following conventions in this manual:
Convention Usage Example
Items of the Graphical User Interface

Bold Press the OK button.
(GUI), e.g., menu options
Page 11 of 203
Introduction
Convention Usage Example
Filenames, directory and directory

You will find the file example.conf
Monospaced names, commands, file outputs,
in the /exmp/demo/ directory.
programming code samples
See Chapter 3, "Sample Chapter" in

Italic References and important terms
the CryptoServer - csadm - Manual.
Table 1: Document conventions
We have used icons to highlight the most important notes and information.
Here you find important safety information that should be followed.
Here you find additional notes or supplementary information.
1.1.4 Abbreviations
We use the following abbreviations in this manual:
Abbreviation Meaning
AES Advanced Encryption Standard
BSI Bundesamt für Sicherheit in der Informationstechnik (Federal Office for

Information Security)
CAT CryptoServer administration tool
CNG Cryptography API: Next Generation
CSP Cryptographic Service Provider
CXI Cryptographic eXtended Interface
csadm CryptoServer command-line administration tool
Page 12 of 203
Introduction
Abbreviation Meaning
DES Data Encryption Standard
DRBG deterministic random bit generator
DRNG deterministic random number generator
DSA Digital Signature Algorithm
ECDSA Elliptic Curve DSA
EKM Extensible Key Management
FIPS Federal Information Processing Standard
HSM hardware security module
JCE Java Cryptography Extension
JRE Java Runtime Environment
MAC message authentication code
MBK Master Backup Key
NTP Network Time Protocol
P11CAT PKCS#11 CryptoServer Administration Tool
PCIe PCI Express Interface
PRNG pseudorandom number generator
RSA Rivest, Shamir, Adleman (cryptosystem)
TRNG true random number generator
Table 2: List of abbreviations
1.2 Other Manuals

The CryptoServer is supplied as a PCI Express (PCIe) plug-in card in the following series:
■ CryptoServer CSe-Series
■ CryptoServer Se-Series
■ CryptoServer Se-Series Gen2
The CryptoServer LAN (appliance) is supplied in the following series:
Page 13 of 203
Introduction
■ CryptoServer LAN CSe-Series

■ CryptoServer LAN Se-Series
■ CryptoServer LAN Se-Series Gen2
We provide the following manuals on the product CD for the CryptoServer PCIe plug-in cards
CSe, Se and Se Gen2 and for the CryptoServer LAN (appliance) CSe, Se and Se Gen2.
Quick Start Guides

You will find these Manuals in the main directory of the SecurityServer product CD. They are
available only in English, do not cover all possible scenarios, and are intended as a
supplement to the product documentation provided on the SecurityServer product CD.
■ CryptoServer LAN - Quick Start Guide
If you are looking for step-by-step instructions on how to bring the CryptoServer LAN into
service, how to prepare a computer (Windows 7) for the CryptoServer administration and
how to start administrating your CryptoServer with the Java-based GUI CryptoServer
Administration Tool (CAT), read this document.
■ CryptoServer PCIe - Quick Start Guide
If you are looking for step-by-step instructions on how to bring the CryptoServer PCIe card
into service, how to install the CryptoServer driver on a computer with minimal RHEL 7.0
installation and how to start administrating your CryptoServer with the CryptoServer
Command-line Administration Tool (csadm), read this document.
Manuals for System Administrators

You will find these manuals on the product CD in the following directory:
…Documentation\Administration Guides\
■ CryptoServer – Administration Manual

If you need to administer a CryptoServer PCIe card or a CryptoServer LAN using the
CryptoServer Administration Tool (CAT), read this manual. Furthermore, this manual
provides a detailed description of the CryptoServer functions, required for the correct and
effective operation of the product.
■ CryptoServer LAN – Administration Manual
If you need to administer a CryptoServer LAN (appliance), read this manual. Since a
CryptoServer PCIe card is mounted into the CryptoServer LAN, read the CryptoServer –
Administration Manual, as well.
■ CryptoServer - Troubleshooting
If problems occur while you are using a CryptoServer PCIe card or a CryptoServer LAN
(appliance), read this manual.
Page 14 of 203
Introduction
■ CryptoServer - PKCS#11 P11CAT – Manual

If you need to administer the PKCS#11 R2 interface with the PKCS#11 CryptoServer
Administration Tool (P11CAT), read this manual.
■ CryptoServer - csadm Manual
If you need to administer a CryptoServer PCIe card or a CryptoServer LAN using the
CryptoServer Command-line Administration Tool (csadm), read this manual.
Operating Manuals
You will find these manuals on the product CD in the following directory:
…Documentation\Operating Manuals\. They contain all necessary information for using the
hardware of the CryptoServer PCIe card respectively the CryptoServer LAN (appliance).
Page 15 of 203
CryptoServer Overview
2 CryptoServer Overview
The CryptoServer, created by Utimaco IS GmbH, is a hardware security module (HSM) that
was developed specifically to ensure the efficient and secure performance of the following
cryptographic operations:
■ Generate key
■ Save the key securely
■ Generate random numbers (hardware (true) and software (pseudo) random number
generator)
■ Generate and verify signatures
■ Encrypt and decrypt data
■ Calculate hash values
CryptoServer protects all cryptographic operations or keys you use against any form of attack.
To do so, it uses technical software solutions, and also shields against physical attacks. The
CryptoServer therefore guarantees the trustworthiness and integrity of data within your IT
systems.
There are three series of Utimaco's CryptoServer. They provide the same basic functionality
but have different types of physical security:
■ The CryptoServer CSe is designed to meet the most stringent requirements of physical
security, as required, for example, by the banking and government authority sectors. Its
highly-developed sensors can identify a multitude of mechanical, chemical and physical
attacks and actively delete sensitive keys and data from the CryptoServer's internal
memory before they can fall into the wrong hands. These mechanisms comply with the
FIPS 140-2 Level 4 physical security level.
■ The CryptoServer Se is designed to fulfill typical security requirements in a commercial
environment. The physical external enclosure of the hardware security module guarantees
that any unauthorized attempts to access the sensitive keys and data held in the
CryptoServer's memory will be repelled. These mechanisms comply with the FIPS 140-2
Level 3 physical security level. The CryptoServer Se-Series may be delivered with a
cryptographic accelerator chip which provides highest performance for RSA operations.
■ The CryptoServer Se Gen2 is the successor for the CryptoServer Se-Series. It fulfills the
same security requirements as the CryptoServer Se-Series, and is designed to comply with
the FIPS 140-2 Level 3 physical security level. The CryptoServer Se-Series Gen2 may be
delivered with a cryptographic accelerator chip which provides highest performance for
RSA and ECDSA operations.
All CryptoServer series are available in two variants:
Page 16 of 203
■ CryptoServer as a plug-in card with a PCIe bus.

This is referred to below as the CryptoServer or CryptoServer PCIe.
■ CryptoServer LAN as a network component (appliance) which can be easily integrated into
a network and wherein a CryptoServer PCIe is mounted.
This is referred to below as the CryptoServer LAN.
Throughout this manual, the term CryptoServer is used to refer to all series and all variants
of the CryptoServer.
However, the products are named explicitly when the functionalities of the CryptoServer
series differ.
Appendix B, "Supported Algorithms", describes the supported algorithms.
2.1 Administration of the CryptoServer

You can administer the CryptoServer in a number of ways, each of which is introduced briefly
in the sections that follow.
2.1.1 CryptoServer Administration Tool (CAT)

The CryptoServer administration tool is a Java application used to administer CryptoServer
PCIe cards as well as CryptoServer LANs. Use the CAT to handle all typical administration
tasks involved in bringing the CryptoServer into operation, monitoring its status and managing
the users, firmware and keys.
CAT versions 2.1.0.0 and later do not support administration of the CryptoServer CS-Series
(CS2000 and CS Classic). Use the CAT version earlier than 2.1.0.0 to administer those
CryptoServer series.
The CAT also has a range of other useful functions that can be implemented for keyfiles and
smartcards without involving the CryptoServer.
All operating systems that are currently supported for the host computer, whereon CAT shall
be installed, are listed in the document CS_PD_SecurityServer_SupportedPlatforms.pdf
provided on the SecurityServer/CryptoServer SDK product CD in the directory
…\Documentation\Product Details.
Page 17 of 203
The CAT runs in the following Java runtime environments (JRE):

■ Oracle JRE 1.7 and 1.8
■ IBM JRE
2.1.2 CryptoServer Command-line Administration Tool (csadm)

The CryptoServer command-line tool csadm is a program that can be called from either a
command line or a batch file. You can use csadm to administer both CryptoServer PCIe cards
and CryptoServer LANs. With csadm you can handle all typical administration tasks as
mentioned above for CAT, as well as perform additional advanced administration functions
primarily of interest for customers who want to extend the standard functionality of the
CryptoServer with self-developed firmware modules providing specific cryptographic
functions and commands. See [CSADMIN] for details.
All operating systems that are currently supported for the host computer, whereon csadm
shall be installed, are listed in the document
CS_PD_SecurityServer_SupportedPlatforms.pdf provided on the
SecurityServer/CryptoServer SDK product CD in the directory …\Documentation\Product
Details.
2.1.3 Menu Options on the CryptoServer LAN

On the front side of the CryptoServer LAN you will see a display and a number of control keys.
You can use this display and the control keys to access the menu options needed to perform
the most important administration functions. They include commissioning and status
monitoring, as well as a limited range of functions for managing firmware and keys. However,
you cannot use these menu options to manage user data.
With the menu options on the front side of the CryptoServer LAN you can administer both the
CryptoServer LAN and the CryptoServer PCIe card mounted within the CryptoServer LAN.
2.2 Smartcards, PIN Pads and Keyfiles

Smartcards, PIN pads and keyfiles are used to administer the CryptoServer.
2.2.1 Smartcards
The smartcards that can be used with the CryptoServer are supplied exclusively by Utimaco IS
GmbH. You cannot use any other smartcards for the administration of the CryptoServer. The
smartcards are preconfigured by Utimaco IS GmbH before they are shipped.
Page 18 of 203
The CryptoServer LAN is supplied along with ten smartcards.

However, if you purchase a CryptoServer PCIe, smartcards are not included in the
deliverables.
Each one of these smartcards is already preloaded with an authentication key for the default
administrator ADMIN.
The smartcards are PIN protected. If you enter the incorrect PIN three consecutive times, the
smartcard is blocked and can no longer be used. If this happens you must order a new
smartcard from Utimaco IS GmbH.
2.2.2 PIN Pads

The PIN pads are smartcard readers to be used with the CryptoServer which have an
integrated display and a keypad, and are also supplied exclusively by Utimaco IS GmbH. You
cannot use any other PIN pads for the CryptoServer.
The CryptoServer LAN is supplied along with a PIN pad.

However, if you purchase a CryptoServer PCIe, a PIN pad is not included in the deliverables.
Prior to SecurityServer 4.10 the REINERSCT cyberJack PIN pad has been supplied as shown
in the following figure:
Page 19 of 203
Figure 1: REINERSCT cyberJack
Additionally, as from SecurityServer 4.10 a new PIN pad of type Utimaco cyberJack One has
been introduced.
Figure 2: Utimaco cyberJack One
Both PIN pads provide the same functionality and can be used with the smartcards delivered
by Utimaco IS GmbH.
Page 20 of 203
Note that as of SecurityServer 4.10, the CryptoServer LAN is supplied either with the
REINERSCT cyberJack or with the Utimaco cyberJack One. To use these PIN pads on a
Windows host computer, the appropriate PIN pad driver shall be installed as described in
Chapter 3.3.5. For using the PIN pads on a Linux host computer, the udev rule provided in
Chapter 3.4.6 must be defined.
2.2.3 Keyfiles
After the installation of the CryptoServer host software from the product CD, the
authentication keyfile ADMIN.key for the default administrator ADMIN is also stored on the
host computer you are going to use for the CryptoServer administration.
Keyfiles can be used either with or without password protection. However, we strongly
recommend you always use a password to protect your keyfiles.
2.3 Implementation Environment with a CryptoServer PCIe

A description of a simplified system, with a CryptoServer PCIe that is ready for use, is given
below:
Page 21 of 203
Figure 3: Example for a system with integrated CryptoServer CSe PCIe card
The CryptoServer PCIe has been mounted in a host computer that is running either a
Windows or Linux operating system. To enable the operating system of the host computer to
communicate with the CryptoServer, the CryptoServer driver for the corresponding operating
system, provided on the SecurityServer/CryptoServer SDK product CD, has also been installed
on the host computer. If necessary, you can run more than one CryptoServer PCIe in the same
host computer. The CryptoServer itself is administered with the administration tools installed
on the host computer and also provided on the SecurityServer/CryptoServer SDK product CD.
You find the list of all currently supported operating systems for the host computer in the
document CS_PD_SecurityServer_SupportedPlatforms.pdf on the
Details.
Most of the commands used to administer the CryptoServer must be authenticated by users
with appropriate permissions. The user can use a keyfile, a passwords or a smartcard as an
Page 22 of 203
authentication token. However, the smartcards and the PIN pad serving as a card reader are
not included in the CryptoServer PCIe deliverables and must be acquired separately from the
manufacturer Utimaco IS GmbH. If you want to use smartcards, the PIN pad is usually
connected directly to the host computer via a serial or an USB port. For some security-
relevant operations you can also connect the PIN pad directly to the CryptoServer PCIe.
2.4 Implementation Environment with One or More CryptoServer LANs

A description of a simplified system with one or more CryptoServer LANs that is ready for use,
is given below.
Figure 4: Example for a system with three CryptoServer LANs
The CryptoServer LAN can be administered over a network from a host computer.
The CryptoServer PCIe, which is mounted in the CryptoServer LAN, can be administered either
from the host computer or directly on the CryptoServer LAN itself. To enable this, a PIN pad
and ten smartcards are included in the CryptoServer LAN deliverables.
Page 23 of 203
The network connection allows you to install the administration tools and the applications on
one and the same host computer. However, you can also install them on different host
computers. In addition, several CryptoServer LANs can be implemented in the same network
and managed from the central host computer.
You find the list of all currently supported operating systems for the host computer in the
document CS_PD_SecurityServer_SupportedPlatforms.pdf on the
Details.
If you want to administer the CryptoServer over the network, connect the PIN pad directly to
one of the serial or USB ports on the host computer. If you want to perform administration
tasks locally on the CryptoServer LAN, connect the PIN pad directly to the device.
2.5 Hardware
The CryptoServer hardware is comparable to that of a modern minicomputer or smartphone.
It includes a central processor, RAM, flash memory modules as mass storage media, a real
time clock, and external interfaces. Additional hardware components are arranged specifically
to provide the functionality of a hardware security module and are therefore described in
greater detail.
2.5.1 CryptoServer Series

Utimaco provides different series of CryptoServer. In general, they offer the same
functionality, but differ in their level of physical security:
CryptoServer CSe-Series is designed for the highest requirements regarding physical
security, as e.g. required in banking and governmental environments. Its extensive sensor
mechanism, which includes the usage of a sensor-protection foil, reacts on all kind of
mechanical, chemical and physical attacks and erases sensitive keys and data actively
and within shortest time from CryptoServer’s internal memory. This mechanism meets the
requirements of FIPS 140-2 highest level 4 in area “Physical Security”, and is certified
according to this security standard.
CryptoServer Se-Series is designed for most typical security requirements in commercial
environments. All security-relevant hardware components are encapsulated and
completely covered by potting material (epoxy resin). This hard, opaque enclosure
protects the sensitive CryptoServer hardware components from physical attacks on
sensitive keys and data. This mechanism meets the requirements of FIPS 140-2 level 3 in
area “Physical Security”.
Page 24 of 203
CryptoServer Se may be delivered with a cryptographic accelerator chip which provides

highest performance for RSA operations.
CryptoServer Se-Series Gen2 is the successor for the CryptoServer Se-Series. It fulfills the
same security requirements as the CryptoServer Se-Series, and has been designed to
meet the requirements of FIPS 140-2 level 3 in the area "Physical Security".
CryptoServer Se-Series Gen2 may be delivered with a cryptographic accelerator chip
which provides highest performance for RSA and ECC operations.
All CryptoServer series come with the same software architecture. In this document they will
henceforward only be named CryptoServer.
2.5.2 CryptoServer Models

The CryptoServer CSe-Series, CryptoServer Se-Series and the CryptoServer Se-Series Gen2 are
available in the following models. The numbers in the model names reflect their approximate
relative processing power.
▣ Without a cryptographic accelerator chip
□ CSe10
□ CSe100
□ Se10
□ Se50
▣ With a Broadcom cryptographic accelerator chip for RSA operations
□ Se400
□ Se1000
□ Se12
□ Se52
▣ With an Exar cryptographic accelerator chip for RSA and ECC operations
□ Se500
□ Se1500
Page 25 of 203
2.5.3 CryptoServer Variants

All models in the CryptoServer CSe-Series, Se-Series and Se-Series Gen2 are available in two
variants:
■ CryptoServer as a plug-in card with a PCI Express bus. This is referred to below as the
CryptoServer.
■ CryptoServer LAN as a network component (appliance), which can be easily integrated
into a network. This is referred to below as CryptoServer LAN.
2.5.4 IRAM and Key-RAM

On the CryptoServer PCIe card, there are two memory areas, which are highly relevant for
CryptoServer’s security architecture, because they can be used to store sensitive data in clear
text:
■ IRAM
■ Key-RAM
2.5.4.1 IRAM
The CPU of the CryptoServer is equipped with internal RAM (IRAM) for code, data and cache.
The IRAM can be used to hold sensitive data in plain on runtime. It is guaranteed that the
IRAM is erased actively within a very short time in case of an alarm triggered by the sensor
(each memory cell of the IRAM will be overwritten). If the CryptoServer goes down on power-
off, the IRAM will be erased, too.
2.5.4.2 Key-RAM
The Key-RAM is a non-volatile RAM, which is protected by the sensors. is used to store the
CryptoServer's individual device key because the sensor-protection holds on runtime and in
retention that is, if power supply is switched off. The individual device key is only used within
the CryptoServer to encrypt other keys and sensitive data that are stored in the CryptoServer.
Independently from the mode of operation the mechanism, an internal power supply provides
in any case enough power to detect an attack by the sensors, initiate an alarm and erase the
Key-RAM including the individual device key actively within less than two milliseconds. Within
this timeframe, the Key-RAM will be overwritten five times, alternately with 0x00 and 0xFF
patterns. As a consequence, none of the other keys and sensitive data in the CryptoServer can
be decrypted.
Page 26 of 203
2.5.5 Cryptographic Accelerator Chip

Certain CryptoServers may be delivered with a cryptographic accelerator chip providing
highest performance for RSA operations and/or ECC operations. The following list shows the
CryptoServer models having a cryptographic accelerator chips.
▣ With a Broadcom cryptographic accelerator chip for RSA operations
□ Se400
□ Se1000
▣ With an Exar cryptographic accelerator chip for RSA and ECC operations
□ Se500
□ Se1500
2.5.6 Random Number Generator (RNG)

The CryptoServer implements a hardware true random number generator (TRNG) and a
software pseudorandom number generator (PRNG), which is also called deterministic random
bit generator (DRBG).
The hardware random number generator is needed to produce real respectively true random
numbers. It is implemented by using a physical noise generator, the output of which is
mathematically post-processed and online tested to guarantee the quality of the generated
random numbers.
CryptoServer's TRNG complies with class PTG.2 of a TRNG as specified in the BSI
specification AIS 20/AIS 31. The generated random numbers can be used for the generation
of signature key pairs, random padding bits, etc.
To achieve high-performant random number generation, the TRNG is enhanced by a software
random generator (DRBG) which complies with class DRG.4 of DRNG as specified in the BSI
specification AIS 20/AIS 31. The algorithm used by this software is specified in NIST 800-90A
"Recommendation for Random Number Generation Using Deterministic Random Bit
Generators". The generated pseudorandom numbers can be used for the generation of keys,
padding bits, etc.
2.5.7 Physical External Housing

All hardware components are enclosed in a sturdy metal case and are securely sealed in
place. The CryptoServer and the keys and data it contains are therefore fully protected against
any attack. Any attempt to break into this physical external enclosure, or to degrade any of its
Page 27 of 203
surfaces, will leave unmistakable traces of the attack that cannot be disguised. Any attempt
to remove the physical external enclosure will destroy the CryptoServer's internal
components.
2.5.8 Sensors
In addition to its physical external enclosure, the CryptoServer is equipped with a range of
sensors that constantly monitor some of its critical operating parameters. In particular, these
sensors check whether the device is running within the upper and lower threshold values for
its operating voltage and operating temperature. If the temperature or the voltage fall below or
rise above these threshold values, the sensors react as if the device is being attacked and
delete the CryptoServer's internal key memory. This prevents any keys and sensitive data from
being read-out as a result of unauthorized operating parameters.
An internal power supply (battery) ensures that, even when the CryptoServer is switched off, it
has sufficient power to operate the sensors and to delete sensitive data or memory if
necessary.
2.5.9 Tamper-protecting Foil

In the CryptoServer CSe-Series device a tamper-protecting foil is connected to the sensors. If
the physical external enclosure was under a mechanical or chemical attack, which damages
the tamper-protecting foil, the sensors trigger an alarm which immediately deletes all keys
and sensitive data in the CryptoServer.
When the alarm is triggered, an entry is recorded in the CryptoServer's audit log file.
The alarm triggered by the tamper-protecting foil being damaged or destroyed, is a

permanent alarm. The CryptoServer cannot be brought back into operation until the tamper-
protecting foil has been repaired or replaced by the manufacturer Utimaco IS GmbH.
After a restart, the CryptoServer goes into Maintenance Mode. This allows you to extract the
status information and logfiles to analyze the error in greater detail before sending the
CryptoServer device back to Utimaco IS GmbH for repair.
2.5.10 Power Supply Monitoring

The power supply of the CryptoServer is provided by the following sources:
■ PCIe interface
Page 28 of 203
This is the usual power supply if the CryptoServer PCIe card has been mounted in a
computer and this computer has been switched on or the CryptoServer PCIe card has
been mounted in a CSLAN and this CSLAN has been switched on.
■ Carrier battery
The carrier battery on the CryptoServer PCIe card is the backup power supply for the case
that the power supply via the PCIe interface is not available.
Figure 5: The CryptoServer Se PCIe card
Item 2 in the figure indicates the carrier battery.

■ External battery
The external battery is an optional power supply that can be provided in the CryptoServer
LAN.
The external battery is the backup power supply for the case that the power supply via the
PCIe interface is not available.
Page 29 of 203
Figure 6: The external battery of the CryptoServer LAN V4
■ Capacitor
If neither the power supply via the PCIe port nor the carrier battery nor the external battery
can provide a sufficient power supply, it is provided by a capacitor on the CryptoServer
PCIe card for a minimum of 5 minutes and a maximum of 30 minutes.
If even the capacitor cannot provide the required voltage anymore, an alarm is triggered to
prevent keys or other sensitive data from being read-out by unauthorized means. The
alarm state information is lost during power failure. A power failure occurs as well when
the CryptoServer is started for the very first time. See Chapter 2.6, “An Alarm and Its
Consequences”, for more details about alarms.
The following table gives more information about triggering alarms.
Page 30 of 203
Voltage Behavior of the CryptoServer
If the power supply via the PCIe port is not available anymore, the
carrier battery voltage and the external battery voltage are below
2.55 V, and the capacitor does not provide any voltage anymore,
an alarm is triggered, all keys and sensitive data in the
Below 2.55 V CryptoServer are deleted, an entry is recorded in the
CryptoServer's audit log file, and the CryptoServer is restarted.
(carrier battery and
external battery) After the restart, the processor of the CryptoServer is suspended,
and commands are not executed any longer.
There is no lower threshold for the voltage provided via the PCIe
port because it is assumed that there is a carrier battery or
external battery available.
Carrier battery voltage Normal operation.

and external battery
Power is supplied to the sensors and the internal memory.
voltage above 2.55 V
and
internal supply voltage
below 7.9 V
or
power supply via the
PCIe interface is
present
If the internal supply voltage is above 7.9 V, an alarm is triggered,

all keys and sensitive data in the CryptoServer are deleted, an
entry is recorded in the CryptoServer's audit log file, and the
Above 7.9 V CryptoServer is restarted.
(internal supply After the restart the processor of the CryptoServer is suspended,
voltage) and commands are not executed any longer.
There is no upper threshold for the carrier battery voltage or the
external battery voltage to trigger an alarm.
Table 3: Voltage ranges and alarms
Page 31 of 203
If the carrier battery or the external battery has been replaced, the methods to retrieve the
battery state ( e.g., the csadm Dev=PCI:0 GetBattState command or by clicking the
Show > Battery State menu in the CAT main window) do not show the current battery
state. Wait at least one minute before retrieving the battery state.
The alarm triggered by the power supply monitoring sensors is a temporary alarm. Once the
mains power returns to within the limits of the predefined threshold values, the reason for
triggering this alarm is no longer present. CryptoServer can then be brought back into
operation.
The following table describes the replies to battery state requests that are initiated by e.g., the
csadm Dev=PCI:0 GetBattState command or by clicking the Show > Battery State menu in
the CAT main window. No automatic actions are initiated by the CryptoServer if the voltage
falls below the described thresholds.
Voltage Behavior of the CryptoServer
Below 2.6 V Requesting the battery state delivers a reply indicating among
other things that the external battery is not available.
(external battery)
other things that the carrier battery voltage is too low.
(carrier battery)
other things that the external battery voltage is too low.
(external battery)
Table 4: Voltage ranges and state requests
2.5.11 Temperature Monitoring

The sensors monitor the CryptoServer's internal temperature whilst it is in operation. The
following table shows the permitted temperature ranges and also how the CryptoServer
reacts if the temperature falls below or rises above the threshold values.
Temperature Behavior of the CryptoServer
Alarm is triggered, all keys and sensitive data in the CryptoServer

is deleted, and the CryptoServer is restarted. After the restart the
Below -12 °C (10.4 °F)
processor of the CryptoServer is suspended and commands are
not executed any longer.
Page 32 of 203
Temperature Behavior of the CryptoServer
–12 C to -5 C The processor of the CryptoServer is suspended; a new entry is

(10.4°F to 23 °F) written into the audit log file (Temperature exceeds valid
range (<value>°C): Shutdown!); commands are not
executed any longer. No alarm is triggered, i.e., no keys and
sensitive data stored in the CryptoServer are deleted. After being
back to the normal operational temperature (-5 C to 62 C) the
CryptoServer has to be restarted to be operational again.
-5 °C to 62 °C Normal operation
(23 °F to 143.6 °F)
The processor of the CryptoServer is suspended; a new entry is

written into the audit log file (Temperature exceeds valid
range (<value>°C): Shutdown!); commands are not
62 °C to 66 °C
executed any longer. No alarm is triggered, i.e., no keys and
(143.6 °F to 150.8 °F)
sensitive data stored in the CryptoServer are deleted. After being
back to the normal operational temperature (-5 C to 62°C) the
CryptoServer has to be restarted to be operational again.
An alarm is triggered, all sensitive data in the CryptoServer is

deleted and the security module is restarted. After the restart the
Above 66°C (150.8 °F )
processor of the CryptoServer is suspended and commands are
not executed any longer.
Table 5: Temperature ranges and CryptoServer behavior
The temperature ranges given in this table are only approximate and may vary slightly due to
the tolerances of individual components.
An entry is recorded in the CryptoServer audit log file both when the device goes into sleep
mode and when an alarm is triggered.
If the CryptoServer is in sleep mode, it can be reset to Operational Mode once its internal
temperature returns to the permitted temperature range. To do this, you must perform a
hardware reset on the CryptoServer. As no keys or other data are deleted when the
CryptoServer goes into sleep mode, it returns to Operational Mode once the restart procedure
is completed.
Page 33 of 203
The alarm triggered by the temperature monitoring sensors is a temporary alarm. Once the
temperature returns to within the limits of the predefined temperature range, the reason for
triggering this alarm is no longer present. CryptoServer can then be brought back into
operation.
2.6 An Alarm and Its Consequences

When an alarm is triggered, the following sensitive data is actively deleted from the
CryptoServer:
■ The individual device key.
This automatically makes all other keys (including the MBK) and sensitive data stored in
the CryptoServer unusable, because they can no longer be decrypted without the
individual device key.
■ All users from the user database who use a password-based mechanism to authenticate
themselves:
However, all users who log in to the CryptoServer with a signature-based mechanism (RSA
Signature, RSA Smartcard or ECDSA signature) are not deleted.
After the alarm, the CryptoServer is no longer in Operational Mode and will go into
Maintenance Mode after a restart.
The alarm must be reset by an administrator who has the appropriate authentication status
before the CryptoServer returns to Operational Mode.
After triggering the alarm, the CryptoServer is no longer in Operational Mode and will go into
Maintenance Mode after a restart. Before you, as the administrator, reset an alarm, you should
find out why it was triggered. At this point you must note the following:
■ If the alarm is a temporary alarm, and the event that triggered it is no longer present, (i.e.
the power supply and the internal temperature of the CryptoServer are once again within
the permitted threshold values), the CryptoServer returns to Operational Mode after a
reset of the alarm and the restart.
■ If the alarm is a temporary alarm and the event that triggered it is still present (i.e. the
power supply or the CryptoServer's internal temperature are still not within the permitted
threshold values), CryptoServer goes into Maintenance Mode after the restart. The
CryptoServer will not return to Operational Mode after a restart until you resolve the event
that triggered the alarm and reset the alarm.
■ If the alarm is a permanent alarm, i.e. the tamper-protecting foil in a CryptoServer CSe-
Series has been damaged or destroyed, the CryptoServer returns to Maintenance Mode
Page 34 of 203
after the restart. Any attempt to reset the alarm will not succeed. You cannot bring the
CryptoServer into operation again until it has been repaired by Utimaco IS GmbH.
2.7 The Software of the CryptoServer

Different software components work together in the CryptoServer at different times. This
section gives a brief introduction to these software components and describes their
functionality.
2.7.1 Bootloader
The bootloader is a base software stored in the CryptoServer's FLASH memory. It runs every
time the CryptoServer (re)starts, before the actual operating system and the other firmware
modules are booted.
If you are working as a CryptoServer administrator, you will never come into contact with the
bootloader in "normal" operations. For this reason, the bootloader is only described in brief
here. More detailed information is provided in the sections about the special situations in
which the bootloader plays a critical role.
2.7.2 Firmware Modules

The CryptoServer's firmware has a modular structure. In addition to the actual SMOS (Security
Module Operating System) operating system there are a number of other firmware modules
each performing specific functions, for example, generating random numbers, signature
generation and data encryption (RSA, elliptic curves cryptography, DES, AES, etc.), performing
hash functions, access to the internal real time clock, database for storing keys and other
data, communications with the PIN pad and smartcard, etc.
All these firmware modules are loaded, updated and deleted more or less independently of
each other. When you upgrade a firmware module it is ensured that any keys and data already
present, are transferred automatically and therefore do not need to be imported from scratch.
The firmware modules included, by default, in version 4.00.0 and later of SecurityServer
firmware packages are listed below:
■ SMOS (Security Module Operating System)
■ POST (Power-on self-tests): Firmware module implementing self-tests for all
cryptographic algorithms that are executed every time the CryptoServer has been started.
■ CMDS (Command Scheduler) command processing and user management
■ ADM Administration of firmware modules
■ UTIL (utilities) access to the real time clock and random number generator
Page 35 of 203
■ CXI (Cryptographic eXtended Interface); Utimaco’s proprietary cryptographic HSM

interface which is used by the host libraries for the CXI API, PKCS#11 (CXI module version
2.0.0.0 or later), CSP/CNG, JCE, OpenSSL and EKM.
■ VDES (DES algorithm); used for key generation, encryption/decryption, MAC
■ AES (AES algorithm); used for key generation, encryption/decryption, MAC
■ VRSA (RSA algorithm); incl. key pair generation
■ LNA (Long Number Arithmetic)
■ ECA (Elliptic Curve Algorithm)
■ ECDSA (Elliptic Curve Cryptography, ECDSA signature generation/verification, key pair
generation)
■ DSA (Digital Signature Algorithm)
■ HASH various hash algorithms
■ DB database used to store keys and other data
■ MBK (Master Backup Key (MBK) Management) incl. generation, export and import of MBK
■ ASN1 (Abstract Syntax Notation One)
■ NTP Time management using an NTP (Network Time Protocol) client
■ BCM: Driver for the Broadcom cryptographic accelerator chip of the CryptoServer models
Se400 and Se1000 of the CryptoServer Se-Series. This firmware module only starts if the
Broadcom cryptographic accelerator chip is built into the CryptoServer. If this is not the
case, as for the models Se10 and Se50, the initialization state of the BCM firmware
module is set to INIT_INACTIVE, and no services of the BCM firmware module are
available.
■ EXAR: Driver for the Exar cryptograhic accelerator chip as built in the CryptoServer models
Se500 and Se1500 of the CryptoServer Se-Series Gen2. This firmware module only starts
if the Exar cryptographic accelerator chip is built into the CryptoServer. If this is not the
case, as for the CryptoServer models Se12 and Se52, the initialization state of the EXAR
firmware module is set to INIT_INACTIVE, and no services of the EXAR firmware module
are available.
■ HCE (Hardware Crypto Engine): Generic interface for accessing the cryptograhic
accelerator chip. The HCE firmware module can only provide its full functionality, if the
BCM firmware module is available and fully functional or respectively the EXAR firmware
module is available and fully functional. If this is not the case, as for the CryptoServer
models Se10 and Se50 of the CryptoServer Se-Series and as for the CryptoServer models
Se12 and Se52 of the CryptoServer Se-Series Gen2, the initialization state of the firmware
module HCE is set to INIT_INACTIVE, and no services of the HCE firmware module are
available.
Page 36 of 203
■ PP (PIN Pad driver)

■ SC (Smartcard driver): Driver for the communication with a smartcard (using ISO 7816
commands)
2.7.3 Firmware Package

The SecurityServer product CD supplied along with every CryptoServer device contains all
firmware modules, provided as firmware packages. You can easily identify these packages by
their .mpkg file extension in the directory \Firmware\SecurityServer-<CryptoServer-
Series>.
For the different series of CryptoServer, Se-Series, Se-Series Gen2, CS- and CSe-Series, as well
as for the CryptoServer Simulator and the FIPS 140-2 Level 3 certified CryptoServer Se, the
corresponding SecurityServer firmware packages are provided.
2.8 System Keys

These keys play an important role in the CryptoServer's security concept:
■ The default authentication key ADMIN.key for the default administrator ADMIN.
■ The individual device key used to encrypt all keys and data in the CryptoServer.
■ The Master Backup Key (MBK) used to encrypt the backup copies of the key and/or user
data stored in the CryptoServer. This ensures that this data can also be stored securely
outside the CryptoServer.
2.8.1 Default Authentication Key

The authentication key ADMIN.key is an RSA key with a key length of at least 1024 bit. It is
generated by the manufacturer Utimaco IS GmbH before the CryptoServer is delivered to you.
The private part of the key is made available to you (to every customer) on the smartcards,
and as a keyfile on the SecurityServer product CD in one of the following directories:
\Software\Windows\x86-32\Administration\key.
\Software\Windows\x86-64\Administration\key
\Software\Linux\x86-32\Administration\key
The public part of the key is loaded into the CryptoServer device by the manufacturer Utimaco
IS GmbH before it has been delivered to you.
The default administrator ADMIN who already has been set up on the CryptoServer must then
use this authentication key to authenticate initial administration tasks. It can also be used to
authenticate other specific CryptoServer users.
Page 37 of 203
Since the ADMIN.key is a default key that does not provide any individual protection, we
strongly recommend to replace it by your own authentication key as soon as possible. For
detailed instructions on how to generate a new authentication key on a smartcard, read
Chapter 5.6.1, “Generating a Key on a Smartcard”. Chapter 5.6.6, “Generating a Key as a
Keyfile”, contains detailed instructions on how to generate a new authentication key as a
keyfile.
2.8.2 Individual Device Key

The individual device key (CryptoServer's Master Key) is generated randomly every time the
CryptoServer is brought into operation. It cannot be readout, exported, or imported, saved, or
restored, and is therefore inaccessible to everyone, even to the CryptoServer owner. It is
implemented exclusively within the CryptoServer itself.
The individual device key is used to encrypt all other keys and sensitive data stored in the
CryptoServer.
2.8.3 Master Backup Key (MBK)

The CryptoServer provides secure storage for secret data and private keys. This includes, for
example, the keys used by the PKCS#11, CSP/CNG, JCE and other interfaces. As any
perceived attack will cause the CryptoServer to permanently delete all sensitive data and
private keys stored on it, we strongly recommend you to back up this data and keys so they
can be reimported (restored) once the alarm has been resolved. To ensure that each backup
copy of sensitive data or private keys is stored securely even outside the CryptoServer, it is
protected with the Master Backup Key (MBK).
The purpose of an MBK is therefore to protect the backups and externally stored secret data
and private keys from unauthorized access.
As an alarm will also cause the MBK to be permanently deleted, a backup copy of this key has
to be stored in a different location (not on the CryptoServer).
If the MBK is stored on a smartcard or in a keyfile, it is always split into several, at least two
parts (shares), approval according to the two-person rule. Splitting the MBK into several key
shares is one of CryptoServer's most important security functions because it enforces the
MBK to be used by several people (at least two), who then share responsibility for its use.
The MBK is always split into minimum two shares. Each of these shares can be stored
outside the CryptoServer in two different ways:
■ On a smartcard protected by a PIN
■ As a keyfile protected by a password
Page 38 of 203
The MBK firmware module provides the following functions for MBK management:
■ Generation and storage of an MBK
This function generates a 256-bit (32-byte) AES key as an MBK within the secure
environment of the CryptoServer. To ensure the highest possible levels of quality and
"randomness" the hardware random number generator of the CryptoServer is used for the
MBK generation. The generated MBK is then split into shares and stored on smartcards or
in keyfiles, but it is not stored yet on the CryptoServer. The MBK must be imported into the
CryptoServer in a separate step.
■ Import of an MBK
This function imports an MBK from the smartcards or keyfiles to the CryptoServer. For
backward compatibility purposes, the import of 128-bit (16-byte) DES keys is supported
additionally.
For detailed step-by-step instructions on managing an MBK with CAT, see Chapter 5.8,
“Master Backup Key Management”, in this manual. For details on managing an MBK with the
command-line tool csadm, see [CSADMIN].
There are two methods for managing an MBK:
■ Local MBK Management
In this case, the PIN pad is connected directly to the CryptoServer. As the CryptoServer
writes the MBK shares directly to the smartcards, they are neither stored in the host
computer's RAM nor transferred via a network. However, if you use this method, you
cannot store the MBK in a keyfile.
Local MBK management can be performed by both the csadm command-line tool and the
CryptoServer LAN menu.
■ Remote MBK Management
In this situation, the MBK can be managed over a network on a CryptoServer LAN. After
the MBK has been generated in the CryptoServer, its shares are transferred to the host
computer, where the administration tools have been installed. Afterwards, they are stored
on smartcards or in keyfiles. If the MBK shares are stored on smartcards, the PIN pad is
connected to the host computer.
2.8.4 Tenant Backup Keys

As from SecurityServer/CryptoServer SDK 4.10 the Master Backup Key can be additionally
used to derive individual backup keys, called Tenant Backup Keys (TBK). The TBKs ensure
that key backups and keys stored outside a CryptoServer, and used for example by the
PKCS#11, CSP/CNG or CXI API, are protected in an individual way. For example, in a cloud
environment the CryptoServer serves as the root of trust for more than one PKCS#11
applications simultaneously. Each application uses a single PKCS#11 slot on the
CryptoServer for its individual key management. The CryptoServer considers each of these
Page 39 of 203
applications as a tenant. Thus, the key backup of a slot is protected with the slot-individual
TBK and can only be accessed by the authorized users of that PKCS#11 slot.
The database backup functionality in CAT and csadm always uses the CryptoServer's MBK.
The individual protection of external keys and key backups by using TBKs is only provided by
P11CAT, p11tool2 and the CXI tool, and requires individual configuration.
TBKs are not used by default. The CryptoServer can be configured on demand to use them.
This is done by setting dedicated configuration attributes. Further individualization of the
TBKs can be achieved by defining individual passphrases for their derivation.
The usage of TBKs can be enabled globally for the CryptoServer or only for specific
CryptoServer PKCS#11 slots/CXI key groups:
■ The global use of TBKs means that TBKs are used for every key and each PKCS#11
slot/CXI key group. To enforce this, the CryptoServer requires one or more authenticated
CryptoServer users with user management permissions (min. authentication status
20000000) or the ADMIN to set the following global configuration attribute:
▣ For PKCS#11 applications: Set CKA_CFG_SECURE_SLOT_BACKUP to CK_TRUE by using

the p11tool2 (command SetGlobalConfig) or P11CAT.
1. For applications using Utimaco's CXI interface: Set SecureGroupBackup to true by using
the CXI tool, for example:
cxitool LogonSign=ADMIN,C:\Utimaco\keys\ADMIN.key SetConfig=SecureGroupBackup,true
If you want to use a TBK, the following applies:

If you use SecurityServer/CryptoServer SDK 4.10, create an external key or key backup by
using an MBK, then enable the usage of TBKs by setting the
CKA_CFG_SECURE_SLOT_BACKUP configuration attribute to the CK_TRUE value, trying
to restore the external key or key backup fails and the external key and key backups become
inaccessible. The error message “invalid mac of key blob” (error code: 0xB0680026) is
created.
This applies as well if you have upgraded to SecurityServer/CryptoServer SDK 4.20 or later
before trying to restore the external key or key backups.
However, if you upgrade to SecurityServer/CryptoServer SDK 4.20 before creating the
external key or key backup using an MBK, restoring them with a TBK succeeds.
■ The slot/key group-specific use of TBKs means that TBKs can be used only for selected
PKCS#11 slots/CXI key groups on the CryptoServer. To enforce this, the CryptoServer
requires the corresponding PKCS#11 slot/CXI key group administrator(s), so-called
Page 40 of 203
Security Officer(s) (SO), with permissons in the user group 2 (min. authentication status
00000200) to set the configuration attributes mentioned above for the specific PKCS#11
slot(s)/CXI key group.
For further details on how to configure the CryptoServer to use TBKs, read [CS_PKCS11T2]
respectively [CS_PKCS11CAT].
For configuring the passphrase (CKA_CFG_SLOT_BACKUP_PASS_HASH attribute), the
SecureSlotPass command has been introduced in the command-line tools p11tool2 and the
CXI tool. For details on how to use the command to configure your PKCS#11 application, see
the corresponding chapter in [CS_PKCS11T2]. For details on setting the passphrase with the
CXI tool, refer to the cxitool in-tool help.
If a passphrase shall be used for the derivation of TBKs, it has to be defined prior to enabling
the usage of TBKs. The usage of TBKs in turn must be configured before the corresponding
PKCS#11 slot/CXI group on the CryptoServer gets operational. Otherwise, existing external
keys and key backups become inaccessible.
Changing the CKA_CFG_SLOT_BACKUP_PASS_HASH attribute for a slot that is currently

in use causes previously generated external keys and their backups to become inaccessible.
If you use SecurityServer/CryptoServer SDK 4.10 when creating the external key and their
backups and you try to restore them with a changed individual passphrase, the error
message “invalid mac of key blob” (error code: 0xB0680026) is created.
before trying to restore the external key or key backups.
However, if you upgrade to SecurityServer/CryptoServer SDK 4.20 before creating the
external key or key backup and you try to restore them with a changed individual
passphrase, the error message “wrong TBK passphrase for this key blob” (error code:
0xB0680081) is created.
2.9 Operating States

The CryptoServer has two operating states, which are described briefly in this section.
2.9.1 INITIALIZED Operating State

When the CryptoServer is started correctly, it goes into the INITIALIZED operating state.
2.9.2 DEFECT Operating State

The bootloader performs a self-test every time the CryptoServer starts to check whether
particular hardware and software components are functioning correctly. If this self-test
Page 41 of 203
detects an error, booting is interrupted and the CryptoServer switches to the DEFECT
operating state.
If it is still possible to call the CryptoServer's status whilst it is in the DEFECT operating state,
you will see its operating state displayed as DEFECT.
In this operating state the CryptoServer accepts either only very few or no administration
commands.
If a significant hardware defect is present, it may not even be possible to start the
bootloader itself. If the bootloader cannot be started, the operating state DEFECT will not be
displayed. In this situation, the CryptoServer's register displays an undefined value.
2.10 Operating Modes

When the CryptoServer's operating state is INITIALIZED it can be in either one of two basic
operating modes.
■ Operational Mode
■ Maintenance Mode
These modes are described in greater detail in the following sections.
2.10.1 Operational Mode

The Operational Mode means that the CryptoServer is functioning correctly. The complete set
of loaded firmware modules (.msc) has been started successfully.
2.10.1.1 Administration-Only Mode
You can configure the startup mode of the CryptoServer, by using the csadm administration
tool, in a way that the automatic activation of cryptographic interfaces after a restart is
blocked. This is indicated as the Operational Mode – Administration-Only which is first provided
with the release 4.00.0 of the SecurityServer product CD.
It is an operating mode that provides access to all CryptoServer administration functions, and
blocks all cryptographic (key management and key usage) functions.
■ The Operational Mode – Administration-Only can be activated as default startup mode.
Therefore, a dedicated csadm command specified in chapter "SetStartupMode" of
[CSADMIN] shall be executed. It has to be authenticated by one or more users with system
administration permissions, and defines that on the next restart of the CryptoServer all
cryptographic interfaces will be disabled.
Page 42 of 203
For example, if an attacker would be able to steal both, the CryptoServer device and the
authentication credentials of a key manager or key user, booting into Operational Mode –
Administration-Only will prevent the attacker from misusing the stolen CryptoServer.
■ The Operational Mode – Administration-Only can also be activated temporarily.
This means that all cryptographic functions can be blocked on-demand by users with
system administration permissions. For example, during CryptoServer maintenance, for
avoiding delays or interruptions by long-lasting key generations in the middle of a
maintenance window. Another dedicated csadm command, as described in chapter
"SetAdminMode" of [CSADMIN] shall be used for that. No restart of the CryptoServer is
required.
2.10.2 Maintenance Mode

The Maintenance Mode means that the CryptoServer is no longer ready for normal operation,
and only the backup-set of firmware modules (.sys) is running. This mode provides an
interface for performing administration tasks, but no cryptographic services are available. The
following events will cause the CryptoServer to go into Maintenance Mode:
■ The CryptoServer's sensors have triggered an alarm, and all keys and sensitive data have
been deleted from the device.
■ The CryptoServer's operating system, SMOS, cannot be started or loaded without an error
occurring.
The following actions will cause the CryptoServer to go into Maintenance Mode.
■ An External Erase has been performed and this has triggered an alarm.
■ The Clear command has been used to delete the entire contents of the CryptoServer.
The CryptoServer's functionality is very restricted in Maintenance Mode. The administrator
can perform all functions required to make the CryptoServer operational again. Applications
like, e.g., PKCS#11, JCE, CSP/CNG, etc., cannot access the CryptoServer when it is running in
this mode. For information about how to switch from Maintenance Mode to Operational
Mode, read chapter "Checking the Operativeness and the State of the CryptoServer" in
[CSADMIN].
2.11 External Erase

An External Erase is accompanied by an alarm and actively deletes the following sensitive
data from the CryptoServer:
■ The individual device key
the CryptoServer unusable, because they can no longer be decrypted without the
Page 43 of 203
■ All users from the user database who use a password-based mechanism to authenticate
themselves
However, all users who log in to the CryptoServer with RSA Signature, RSA Smartcard or
ECDSA are not deleted.
After the External Erase the CryptoServer is no longer in Operational Mode and returns to
Maintenance Mode after a restart.
The alarm triggered by an External Erase must be reset by an administrator who has the
appropriate authentication status before the CryptoServer returns to Operational Mode.
The alarm triggered by an External Erase is the prerequisite for performing a Clear to Factory
Settings on the CryptoServer.
However, you must ensure that the alarm triggered by the External Erase is not reset so that
the Clear to Factory Settings function can also be performed.
2.12 Clear
Use the Clear command to manually delete all sensitive data and firmware modules from the
CryptoServer. The following actions are triggered after you enter this command:
■ The firmware modules are deleted.
Only the system firmware modules .sys required for base administration remain on the
CryptoServer.
■ All users using a password to log in to the CryptoServer are deleted.
■ A new individual device key is generated for the CryptoServer.
the CryptoServer unusable, because they can no longer be decrypted without the "old"
However, all users who log in to the CryptoServer with RSA Signature, RSA Smartcard or
ECDSA signature are not deleted.
After the Clear the CryptoServer is no longer in Operational Mode and returns to Maintenance
Mode after a restart.
The CryptoServer does not return to Operational Mode until the firmware modules of the
corresponding SecurityServer firmware package are reloaded.
You should only use the Clear command if you want to set up or reinstall the CryptoServer
again.
Page 44 of 203
2.13 Clear to Factory Settings

If ever you cannot find the authentication key for the default administrator, ADMIN, and can
therefore no longer administer the CryptoServer, you can also perform an External Erase
directly on the CryptoServer and on the CryptoServer LAN.
However, if you do perform this External Erase directly on the CryptoServer or the CryptoServer
LAN, this will trigger an alarm which enables you to perform a Clear to Factory Settings.
The Clear to Factory Settings command can only be implemented if the alarm triggered by the
External Erase is still present.
When you run the Clear to Factory Settings command, it resets the CryptoServer to the state it
was in when it was first supplied. The Clear to Factory Settings command triggers the following
actions:
Only the system firmware modules required for base administration remain on the
CryptoServer.
■ All users in the CryptoServer user database are deleted.
■ The default administrator ADMIN is set up again and can use the original authentication
key ADMIN.key to log in to the CryptoServer.
■ A new individual device key is generated for the CryptoServer. This automatically makes
all other keys (including the MBK) and sensitive data stored in the CryptoServer unusable,
because they can no longer be decrypted without the "old" individual device key.
After the Clear to Factory Settings the CryptoServer is no longer in Operational Mode and returns
to Maintenance Mode after a restart.
corresponding SecurityServer package are reloaded.
2.14 Users, User Groups and Authentication

The commands given to the CryptoServer can only be authenticated by authorized users. The
CryptoServer provides user management functions for this purpose.
2.14.1 Users
Every user is identified by a unique name. In addition, every user is also assigned a number of
other properties that are described in the following table.
Page 45 of 203
Property Meaning
Name Used as a unique identification for a user
Permission User's permissions for the different user groups
Authentication mechanism Defines how the user is to authenticate themselves
Keyfile or password depending on the authentication

Authentication token
mechanism
Additional data used to specify particular properties or

Attributes restrictions, such as that a user may only access
specific keys
Table 6: CryptoServer user properties
All this data is stored in a user database in the CryptoServer. These properties and their
meanings are described in greater detail in the sections that follow.
2.14.2 User Groups

The CryptoServer's user management functionality has eight user groups, numbered from
group 0 to group 7. Some user groups are reserved by Utimaco IS GmbH for applications and
their corresponding role-based user profiles.
Group Application Role-based user profile
0 All cryptographic Interfaces Cryptographic User und PKCS#11 User
2 PKCS#11 PKCS#11 Security Officer (SO)
5 NTP Administration NTP Manager
6 System Administration System Manager
7 User Management User Manager
Table 7: User groups and role-based user profiles reserved for specific applications
2.14.3 Permissions and Authentication Status

A user has a particular permission in each of the eight user groups. This permission is
represented by the numbers 0 to 0xF (15). The next table shows the meaning of this
permission.
Page 46 of 203
Permission Meaning
0 The user has no permissions in that particular user group.
Two-Person rule: although the user can authenticate commands to

1
the CryptoServer, a second user is also required to do this.
2 The user is entitled to authenticate commands on his own.
Not required by the CryptoServer firmware functions by default. Might

be required by functions with custom permissions defined in a signed
3 to 0xF
configuration file cmds.scf (see Chapter 2.15, “Configurable Role-
based Access Control (C-RBAC)”, for detailed information).
Table 8: User permissions
Authentication status from the view point of the CryptoServer

From the CryptoServer's point of view, the authentication status defines which permission
must be present before it can perform a particular command.
Authentication status for user management

User group 7 is reserved for user management. Permission 2 in user group 7 is required to
authenticate the corresponding commands. Therefore, the user management can only be
performed by users who have reached on their own or in pairs (two-person rule) the
authentication status 20000000 at the CryptoServer.
User group 7 6 5 4 3 2 1 0
Authentication status 2 0 0 0 0 0 0 0
Authentication status for administering firmware modules

User group 6 is reserved for the administration of firmware modules (loading, replacing or
deleting firmware modules). Permission 2 in user group 6 is required to authenticate the
corresponding commands. Therefore, the firmware module administration can only be done
by such users who have reached on their own or for example in pairs (two-person rule) the
authentication status 02000000 at the CryptoServer.
User group 7 6 5 4 3 2 1 0
Authentication status 0 2 0 0 0 0 0 0
Page 47 of 203
Authentication status from the user's point of view

From the user's point of view, the authentication status defines which permission(s) can be
reached effectively by one or more authentications. After an authentication has been
performed successfully, the authentication status is increased by the user's (or users', if they
are more than one) permission, starting from authentication status 00000000. The examples
below illustrate this relationship.
The CryptoServer has four users who have the following permissions.
User group 7 6 5 4 3 2 1 0
ADMIN 2 2 0 0 0 0 0 0
Admin1 0 1 0 0 0 0 0 0
Admin2 0 1 0 0 0 0 0 0
User3 0 0 0 0 0 0 1 0
No user has been authenticated.
Authentication status: 0 0 0 0 0 0 0 0
ADMIN has been authenticated.
The commands used to administer firmware modules and those involved in user
management can now be performed because authentication status 2 has been reached in
groups 6 and 7.
Only Admin1 has been authenticated.
The commands used to administer firmware modules cannot be performed because

authentication status 2 has not been reached in group 6.
Admin1 and Admin2 have been authenticated.
Page 48 of 203
The commands used to administer firmware modules can now be performed because
authentication status 2 has been reached in group 6. However, the commands involved in
user management cannot be performed because neither of the two administrators has the
appropriate permission in group 7.
Admin1 and User3 have authenticated themselves.
Despite the fact that two authenticated users are now present, the commands used to
administer firmware modules still cannot be performed because authentication status 2 has
not been reached in group 6.
Authentication status and permissions

The following table provides an overview of the functions which can be performed once the
authentication status 20000000 and 02000000 has been reached.
Authentication status Permissions
Create a user
Delete users
20000000 Create a backup of user data
Restore user data
Reset alarm
Load, replace and delete firmware modules
Set time
Reset alarm
02000000
Clear CryptoServer
Import Master Backup Key
Delete audit log
Table 9: Permissions for authentication status 20000000 and 02000000
Page 49 of 203
2.14.4 Permissions for New Users

The permissions within applications have already been defined at the programming stage.
Once an application has been loaded into CryptoServer you can no longer change its
assignment to a user group or the permission. When you assign new permissions within the
individual user groups, you must also take into account the fact that several user groups have
already been predefined by Utimaco IS GmbH. The following table shows which user groups
have been predefined by the Utimaco IS GmbH for applications and the corresponding role-
based user profiles and which are unused:
User Group Application Role-based user profile
0 All cryptographic interfaces Cryptographic User und PKCS#11 User
2 PKCS#11 PKCS#11 Security Officer (SO)
5 NTP Administration NTP Manager
6 System Administration System Manager
7 User Management User Manager
Table 10: CryptoServer user groups and their permissions
In principle, it is possible to assign new permissions to a user group that has already been
predefined. As a result, the new permissions in a predefined user group are automatically
given the predefined permission. Therefore, a new permission in group 5 (NTP Administration)
can also administrate NTP.
As the predefined user groups 6 and 7 have already been assigned wide-ranging
administration permissions for the CryptoServer, we recommend you do not assign any
other permissions to these groups.
2.14.5 Authentication Mechanisms

CryptoServer can authenticate a user in a number of different ways. These mechanisms are
described in greater detail in the sections that follow.
Page 50 of 203
Authentication with electronic signature

Authentication with an electronic signature provides every user with a pair of keys, one public
and one private.
This authentication mechanism is then described as an RSA Signature or ECDSA Signature
depending on which algorithm you select.
In this method, the private part of the RSA or ECDSA key is stored on a smartcard or in a
keyfile which the user must keep in a safe place. The corresponding public part is stored as
authentication data in the CryptoServer's user database.
Every command which is sent to the CryptoServer will be signed by user’s private key.
A random number provided by CryptoServer is included in the signature calculation process.
This prevents a signed command from being intercepted and entered again later.
The CryptoServer then uses the corresponding public key to check this signature. The
signature authenticates the command and checks whether the command is genuine, i.e. no
transfer errors have occurred and there is no sign of data manipulation.
As this procedure does not transfer any confidential authentication data it is particularly
suitable for remote authentication to the CryptoServer LAN when the network connection is
not completely under your control.
Authentication with an electronic signature can be used with all CryptoServer administration
tools and for local administration tasks on the CryptoServer LAN, as long as the user's private
key is stored on a smartcard.
If the private part of the key is stored in a keyfile, this procedure cannot be used for local
administration tasks on the CryptoServer LAN.
Authentication with an RSA smartcard

A special variant of the electronic signature authentication process described above is
authentication with an RSA smartcard. In this procedure the user's private RSA key is only
stored on a smartcard and not in a keyfile. The corresponding public part is stored as
authentication data in the CryptoServer's user database.
Page 51 of 203
If you use this authentication mechanism, the PIN pad must be connected directly to a port on
the CryptoServer.
You cannot use the ECDSA algorithm with this procedure.
In contrast to the first procedure described above, the electronic signature is not calculated
before the command is sent to the CryptoServer. The command is sent first to the
CryptoServer and then the CryptoServer requests a signature via the RSA smartcard.
You should use authentication with an RSA smartcard if you want to make sure that an
authorized user authenticates a command locally on the CryptoServer.
Remote authentication is not an option here because the PIN pad must be connected
directly to the CryptoServer in this case.
The electronic signature authentication can be implemented with all CryptoServer

administration tools.
Authentication with user name and password

The authentication mechanism involving the user name and password is by far the most well-
known. Unfortunately, this mechanism is not as secure as the authentication using an RSA
smartcard.
The CryptoServer supports HMAC password mechanism for user authentication. The
password is transferred to the CryptoServer in a protected form: A random number is added
to each authentication. This prevents the authentication from being intercepted and
performed again at a later point in time. Thus, the HMAC password authentication procedure
is also suitable for remote authentication to the CryptoServer LAN.
The HMAC password is stored as authentication data in the CryptoServer's user database
user.db.
All CryptoServer administration tools support authentication with a user name and an HMAC
password.However, since you cannot enter a password using the CryptoServer LAN menu
options, this authentication mechanism cannot be used if you are administering the
CryptoServer LAN locally, by using its front panel.
2.14.6 Authentication Mode

Every security-relevant command must be authenticated by an authorized user before it is
send to the CryptoServer.
Page 52 of 203
If you administrate the CryptoServer with the command-line tool csadm, you shall
authenticate every command individually, with the csadm LogonSign or LogonPass
command, depending on the user's authentication mechanism.
If you administrate the CryptoServer with the Java-based administration tool CAT, a Secure
Messaging connection to the CryptoServer is established every time a user logs in to the
CryptoServer. This connection is set to a maximum duration of 14 minutes and 59 seconds
and resets to 14 minutes and 59 seconds every time the user sends a command to the
CryptoServer, or when another user logs in to the CryptoServer. No matter how many
administrators log in simultaneously to the CryptoServer, only one Secure Messaging
connection is ever set up to the CryptoServer. As a consequence, all users currently logged on
to the CryptoServer are logged off simultaneously. This is because the Secure Messaging
connection, which is being used by these multiple users, is terminated.
2.14.7 ADMIN, the Default Administrator

We have already set up the default administrator, ADMIN, on the CryptoServer to ensure you
can administer the CryptoServer after it has been delivered.
The administrator ADMIN not only has the authentication key (smartcard or keyfile), but also
has full permissions in user groups 6 and 7 that are reserved for administration tasks and can
authenticate any command on their own. However, the default administrator ADMIN has no
permissions in user groups 0 to 5.
Anyone who has the authentication key on the smartcard or as a keyfile can log in to the
CryptoServer as the default administrator ADMIN and manage the device on their own.
The user permissions in the default administrator ADMIN's user groups 6 and 7 cannot be
changed on the CryptoServer. You can only change the authentication key used by the default
administrator ADMIN to log in to the CryptoServer.
If the following criteria have been met, it is also possible to delete the default administrator we
set up on the device:
■ You create one or more new users as administrators who have the same permissions in
total in user groups 6 and 7 as the default administrator ADMIN already set up on the
CryptoServer.
■ However, only signature-based authentication mechanisms are permitted for the new
administrator(s), i.e.:
▣ RSA signature
Page 53 of 203
▣ ECDSA signature
▣ RSA smartcard
Only such users are not automatically deleted by an alarm (see Chapter 2.6, “An Alarm and
Its Consequences”) or an External Erase (see Chapter 2.11, “External Erase”).
This therefore enables you to implement a two-person rule for the CryptoServer's
administration tasks. You create two new administrators who in total have the same
permissions in user groups 6 and 7 as the default administrator ADMIN previously had on
their own. The corresponding role-based user profiles have been set up in the CAT for this
purpose.
After this you can delete the default administrator we supplied with the CryptoServer. From
that point onwards, two people will be required (two-person rule) to perform the CryptoServer
administration tasks.
Permissions
The default administrator with authentication status 22000000 is permitted to perform these
functions on the CryptoServer:
■ Create a user
■ Delete users
■ Create a backup of user data
■ Restore user data
■ Load, replace and delete firmware modules
■ Set time
■ Reset alarm
■ Clear CryptoServer
■ Import Master Backup Key
■ Delete audit log
2.14.8 Cryptographic User

A Cryptographic User with permission 2 in the user group 0 (authentication status 00000002)
has been set up in CAT by default. The Cryptographic User has all permissions in user group 0
and can authenticate all commands on its own. The Cryptographic User has been created to
enable you to administer all cryptographic interfaces.
■ CXI (Cryptographic eXtended Interface)
■ JCE (Java Cryptography Extension)
Page 54 of 203
■ CSP/CNG (Microsoft CryptoAPI and Cryptography Next Generation)

■ Open SSL (Cryptographic Token Interface), only if the CryptoServer is connected directly
via an ENGINE interface
■ EKM (Extensible Key Management)
The permissions assigned to the Cryptographic User in user group 0 have been defined in
the CXI firmware module and cannot be changed.
2.15 Configurable Role-based Access Control (C-RBAC)

With release 4.0 of the SecurityServer product CD the CryptoServer provides the possibility to
increase the required permissions for the authentication of specific CryptoServer functions.
The increased permission requirements can be individually configured by the customer for all
external functions specified in the signed configuration file cmds.scf. During command
execution, the currently reached permission for the function is compared to the required
permission in the configuration file. If they are equal or no permission restrictions list exists,
the command is executed normally performing the default (unchanged) permissions check for
the command.
For detailed information about signed configuration files and their use, read chapter "Signed
Configuration Files" in [CSADMIN]. There you will also find a list of all firmware functions for
which you might define enhanced permission requirements.
2.16 Secure Messaging

The CryptoServer supports Secure Messaging for communications between the host and
itself. Commands from the host to the CryptoServer and the CryptoServer's replies to the host
can be encrypted and the integrity of the data can be protected by a MAC (Message
Authentication Code).
In Secure Messaging between the CryptoServer and the host, a new random session key is
generated for each connection. This prevents recorded data packets belonging to an earlier
connection from being imported into a new connection. No valid data packets can be present
once the imported data packet has been decrypted with the current session key.
In addition, the CryptoServer generates a start value for a sequence counter and a session ID
for every new session key. The sequence counter increases every time a command is sent
and is also included in the MAC calculation or integrity check. This ensures that no
commands are recorded within the same connection and sent to the CryptoServer again. The
Page 55 of 203
unique session ID guarantees that every session key is uniquely identifiable. All commands
that use the same session key and session ID are part of the same session (connection).
A session key automatically becomes invalid if it is not used for 15 minutes.

The SecurityServer/CryptoServer SDK 4.10 and later support a maximum of 40961 session
keys (connections) active at the same time. If another session key is requested for a
connection, exceeding the maximum of 4096, the oldest connection is closed and the
session key, associated with it, becomes invalid.
The benefits of sending messages with Secure Messaging are obvious. Once a session key
has been requested, and a secure connection has been established between the host and the
CryptoServer, all commands exchanged within this session are authenticated, encrypted and
secured against being tampered by a MAC.
Additionally, starting with SecurityServer/CryptoServer SDK 4.10 the CryptoServer can be
configured to authenticate itself towards host applications at the beginning of a Secure
Messaging session. For that purpose a new key, the HSM Authentication Key (a 3072-bit RSA
key), has been introduced that can be used to verify the authenticity of a Secure Messaging
session originating from the HSM.
The new security feature is disabled in the default configuration of the CryptoServer. It can be
enabled on demand by using the csadm administration tool as explained in Chapter "Enabling
Mutual Authentication" in [CSADMIN]. There you will also find a detailed description of the
concept in the Chapter "Mutual Authentication" and of the newly introduced csadm command
GetHSMAuthKey in the corresponding chapter.
2.17 Logs
In the CryptoServer, every action that involves a security issue (for example, creating a new
user) or event (especially the triggering of an alarm) is saved in logs. There are two types of
log: the boot log and the audit log.
2.17.1 Boot Log

Every time the CryptoServer starts up, i.e. after being switched on, and after a reset, every
individual step and its results are recorded in the boot log. These include:
1
The SecurityServer/CryptoServer SDK 4.01 and earlier support a maximum of 256 session keys which are active
at the same time and used by different host applications (each key identified by its session ID). If a host application
requests a new session key while the maximum of 256 sessions are already active, the oldest session is closed
and the session key session key, associated with it, becomes invalid.
Page 56 of 203
■ The version number of the loaded operating system (SMOS)

■ The version number of the internal sensor switch
■ Information about whether a license file is present and which system settings have been
made on the basis of this license file
■ For every firmware module that was loaded and started by the operating system: a short
description and unique ID to identify it, whether it could be initialized successfully or which
errors occurred during the initialization process.
If any problems occur during the boot process, you can use the boot log to analyze the errors.
The boot log is stored as a text file in the CryptoServer and is therefore available in a readable
format after you import it.
2.17.2 Audit Log

The audit log is where all events and actions involving security issues that occur or are
performed whilst the CryptoServer is running are recorded. It records for example if the
following occurs:
■ The sensor triggers an alarm
■ The permitted upper limit for the CryptoServer's internal temperature has been exceeded
and the CryptoServer has therefore changed into sleep mode (power down mode)
■ An alarm is reset
■ The CryptoServer is completely deleted
■ The date/time in the CryptoServer's real time clock (RTC) is reset
■ Firmware modules or packets have been loaded, deleted or replaced
■ Users have been created, changed or deleted or their "properties" have been changed
■ The audit log is deleted
■ A few other infrequently used commands
See Chapter 5.9.10, “Configuring the Audit Log Files”, for details about how to configure the
initiation of an audit log entry.
Every entry in the audit log has the following structure:

DD.MM.YY hh:mm:ss [user] event data [returncode] <CR-LF>
The individual fields in this type of entry have the following meaning:
Field Meaning
Page 57 of 203
DD.MM.YY Date on which the event occurred in day.month.year format. The date
is taken from the CryptoServer's internal real time clock.
hh:mm:ss Time at which the event occurred in hour:minute:second format. The

time is taken from the CryptoServer's internal real time clock.
[user] Name(s) of the user(s) who performed the action. Multiple users are
separated by commas. However, if an "external" event occurs, i.e.
alarm or restart, the user ID is missing.
event Description of the event in a readable format
data Additional information about the event in a readable format
[returncode] Return value of the function that has been performed. A return value of
0 means that the function has been performed successfully. A return
code other than 0 shows the returned error number.
<CR-LF> Carriage return - line feed
Table 11: Meaning of the audit log entry fields
The square brackets […] displayed for user and returncode in the previous table do not mean
that these fields are optional. In each case the relevant user name or return code is effectively
enclosed in square brackets.
See Appendix A ,”Audit Log Entries”, contains a list of all audit log entries and describes by
which audit message classes they are activated.
2.18 Backing up, Restoring and Cloning Databases

If you are using version 2.30.2 or later of the SecurityServer package for the CryptoServer, the
following functions are available in CAT:
■ Store a copy of the CryptoServer databases on a computer (backup).
For step-by-step instructions on how to prepare a backup of the CryptoServer databases,
read Chapter 5.10, “Backing up Databases”.
■ Import a copy of the databases from a backup directory to the CryptoServer (restore).
For step-by-step instructions on how to restore the CryptoServer databases, read Chapter
5.11, “Restoring Databases”.
■ Copy the databases from one CryptoServer and then import them to a different
CryptoServer (clone).
For step-by-step instructions on how to clone the CryptoServer databases, read Chapter
5.12, “Cloning Databases”.
Page 58 of 203
Before you can use these new functions, the following must be applied:
■ Version 2.30.2 or later of a SecurityServer package must have been installed in the
CryptoServer.
■ The MBK must have been imported to the CryptoServer. The MBK is used to encrypt all
data that is stored outside of the CryptoServer.
If you want to transfer the databases from one CryptoServer to another (cloning), both these
CryptoServer must have the same MBK.
2.19 Cryptographic Interfaces

This section gives a brief introduction to the CryptoServer's most important cryptographic
interfaces. The corresponding libraries for these interfaces are provided on the SecurityServer
product CD.
2.19.1 Cryptographic eXtended Interface (CXI)

The Cryptographic eXtended Interface (CXI) is a proprietary interface developed by Utimaco IS
GmbH. CXI provides all CryptoServer cryptographic functions via a user-friendly interface,
which has a low protocol overhead and is easy to integrate into customer-specific
applications.
You can use the Cryptographic User user to administer all other cryptographic interfaces
described later on in this chapter via this CXI interface. You can control all other cryptographic
interfaces and their functions within the CryptoServer via the CXI interface. In this respect the
CXI interface plays a more prominent role than the other cryptographic interfaces.
In the CryptoServer itself, CXI functions are provided by the CXI firmware module which is a
component of the SecurityServer firmware package. You can use the CAT administration
program to create a Cryptographic User which functions both as a CXI user and as a user for
all other cryptographic interfaces. The CAT provides the appropriate permission profile for the
Cryptographic User.
2.19.2 PKCS#11
PKCS#11 is the standard used to define a programming interface for security tokens such as
smartcards or hardware security modules. From the PKCS#11 viewpoint, a security token is a
device that stores objects and can perform cryptographic functions. These objects may be
Page 59 of 203
keys or certificates. In addition, the objects can each have different attributes which not only
define how you handle them but may also limit the areas in which they can be used.
With version 3.20 and later of the SecurityServer/CryptoServer SDK product CD only the
PKCS#11 R2 implementation is supplied for which a dedicated administration tool P11CAT
and a separated manual are available.
The PKCS#11 functions in the CryptoServer are provided by the CXI firmware module which is
also a part of the SecurityServer firmware package.
2.19.3 Microsoft CryptoAPI and

Cryptography API: Next Generation (CNG)
Software developers can use the Microsoft cryptographic application programming interface
(CryptoAPI) to call powerful cryptographic functions from their Windows-based applications.
These functions are provided by what is known as the Cryptographic Service Provider (CSP).
The CryptoAPI contains all functions necessary for encrypting and decrypting data (with both
symmetrical and asymmetrical keys) and for using and managing digital certificates for
authentication purposes.
Cryptography API: Next Generation (CNG) is Microsoft's latest cryptographic platform. In CNG
the provider concept has been extended further than in CryptoAPI. CNG also supports newer
cryptographic algorithms, for example elliptic curves. At present, both CryptoAPI and CNG are
being supported, to enable existing applications to be upgraded step-by-step.
The CSP/CNG cryptographic interface is accessed via the CXI firmware module. Depending on
the CryptoServer CSP version different configuration settings are necessary:
■ For CryptoServer CSP 1.x provided on SecurityServer and CryptoServer SDK product CD
up to 4.01, you do not need to set up a Cryptographic User for CSP/CNG on the
CryptoServer. If you have installed the device or the machine via the Control panel applet,
a user is created on the CryptoServer automatically. This machine, or the CSP/CNG user,
has the same authentication status as the Cryptographic User in the CXI firmware
module.
■ For CryptoServer CSP 2.x provided on SecurityServer and CryptoServer SDK product CD
version 4.10 and later, the CSP and CNG interfaces are configured via a dedicated
configuration file, and a CSP/CNG user, with the same permissions as the Cryptographic
User (min. 00000002) must be created manually.
The CryptoAPI and CNG functions are made available to the applications that call them by a
CryptoServer Cryptographic Service Provider (CSP) which serves both these interfaces.
Depending on the version of the SecurityServer and the CryptoServer SDK product CD, not
only the CryptoServer CSP itself is provided, but also a control panel applet CSP Configuration
or a dedicated configuration file, cs_cng.cfg, that can be used to configure the CSP/CNG
cryptographic interface. Additionally, two key management tools are available: The GUI-based
Page 60 of 203
CSP tool for creating, editing and deleting key container and keys with CSP, and the
command-line utility CNG tool for managing CNG cryptographic keys.
2.19.4 Java Cryptography Extension (JCE)

The Java Cryptography Extension (JCE) is a collection of Java packages that implement
cryptographic procedures for Java applications. These include, among other things,
encrypting and decrypting data and generating keys. These functions are made available by
the JCE provider.
In the CryptoServer, these JCE functions are made available by the CXI firmware module
which is a component of the SecurityServer firmware package. You can use the CAT
administration tool to create a Cryptographic User that is also a user for JCE. The CAT
provides the appropriate authorization profile for the Cryptographic User.
2.19.5 OpenSSL
OpenSSL is a free implementation of the SSL/TLS protocol for Open Source environments
which also offers a range of more specialized functions for certificate management and for
different cryptographic functions. These various different functions are grouped together in
the OpenSSL command-line tool.
The integration of OpenSSL into the CryptoServer is done indirectly via an OpenSSL PKCS#11
wrapper. If you want to integrate OpenSSL indirectly via a PKCS#11 wrapper, use the
PKCS#11 administration tool P11CAT to initialize a PCKS#11 token or slot.
2.19.6 Extensible Key Management (EKM)

An SQL Server provides functions for data encryption and EKM (Extensible Key Management).
Here, the Microsoft Cryptography API service provider is used for encryption and key
generation. Encryption keys for encrypting data and keys are created in temporary key
containers, and must be exported by the service provider before they can be saved in the
database.
This approach enables SQL Server to be used for key management with an encryption key
hierarchy and key security.
In CryptoServer, the EKM functions are provided by the CXI firmware module which is an
element of the SecurityServer firmware package.
Use the CAT administration program to create a Cryptographic User which is also a user for
EKM. The CAT provides the appropriate authorization profile for the Cryptographic User.
Page 61 of 203
2.20 Interface Hardening by Disabling Selected Functions

With release 4.0 of the SecurityServer/CryptoServer SDK product CD the CryptoServer offers
the possibility to disable selected functions. The firmware functions to be disabled are defined
in a custom signed configuration file cmds.scf. The configuration file is read and evaluated
on every startup of the CryptoServer. If a function is listed in this configuration file, it is
blocked. For detailed information about signed configuration files and their use read chapter
"Signed Configuration Files" in [CSADMIN]. There you will also find a list of all firmware
functions that can be disabled.
2.21 Clustering for Load Balancing and Failover

Several CryptoServer LANs can be organized in a cluster either for load balancing or for
failover purposes.
Configured to support failover, the CryptoServer cluster ensures high system availability and
reliability.
In a load balancing cluster, CryptoServer LAN devices are configured to optimize the use of
resources to reach higher system performance, and to avoid overloading a single device. A
load balancing cluster also implicitly offers high availability in case some CryptoServer in the
cluster fails, yet at the cost of reduced system performance compared to the performance of
a fully functional cluster.
2.21.1 Concept Overview
Load Balancing
Load balancing defines the ability to distribute connections over several CryptoServer LANs
which are all active (rather than one active and the others passive).
All CryptoServer LANs in the cluster must be configured identically. Connections are
established by the client-side software based on the "Least Connections" principle, i.e. a new
connection is opened on the CryptoServer LAN with the least number of existing connections.
For example, let us assume that each of the N CryptoServer LANs as shown in the figure
below has currently exactly one open connection (Connection 1 to N). When later on
connection 2 is closed and subsequently the connection N+1 should be established, this
connection will be opened on the CryptoServer LAN 2 that has the least number of
connections at that time, namely no connections at all.
Page 62 of 203
Figure 7: Example of a load balancing cluster with N CryptoServer LANs
Load balancing has been tested with clusters of four CryptoServer LANs. This is not due to
limitations of CryptoServer or load balancing functionality. You may build clusters with more
than four CryptoServer without any concerns.
Currently, load balancing is only supported by the CXI and PKCS#11 interfaces of the
CryptoServer Se- and CSe- Series.
Failover
Failover defines the ability to automatically switch processing to a redundant or standby unit
in a cluster, i.e. only the primary CryptoServer is active while other cluster members are
passive. Usually, a cluster of two CryptoServer LANs is deployed as a failover solution (see the
figure below). When the primary CryptoServer LAN fails, the active connection(s) is (are)
automatically routed to the passive CryptoServer LAN which continues to operate in the same
manner as the failed device. The failover mechanism tries to reconnect to the primary
CryptoServer in regular time intervals (fallback interval). In this context the primary
CryptoServer can be the same device as before and which has become operable again; or it
Page 63 of 203
can be a passive CryptoServer which is used as a replacement for the defect primary
CryptoServer. On success the connections are switched back to the primary CryptoServer
resp. transferred to the passive CryptoServer.
Figure 8: Example for a failover cluster with two CryptoServer LANs
A cluster of more than two CryptoServer LANs can be also deployed as a failover solution.
When choosing the fallback interval suitable for your system environment consider the
following aspects to minimize the downtime of your failover cluster:
■ If the passive CryptoServer LAN is available and preconfigured (identically to the primary
CryptoServer LAN) in the same rack or in the local network, and just has to be switched on
to be ready for use, a fallback interval of few minutes might be reasonable.
■ If the passive CryptoServer LAN is locally available, but not in the same rack, and has to be
configured identically to the primary CryptoServer LAN before connections can be
rerouted to it, a fallback interval of few hours might be reasonable.
■ If the passive CryptoServer is not locally available, can be delivered per express delivery
and has to be configured identically to the primary CryptoServer before connections can
be rerouted to it, a fallback interval of few days might be reasonable.
■ If the primary CryptoServer has to be send back to the manufacturer Utimaco IS GmbH
per RMA request, and no passive CryptoServer is available, a fallback interval of several
days might be reasonable.
The use of CryptoServer PCIe cards is only of limited use since normally for the replacement
of a defect CryptoServer PCIe card the host computer must be shut down, and therefore the
application and the CryptoServer cluster are completely out of operation.
Page 64 of 203
Error Handling
Error-handling mechanisms for load balancing and failover are designed to minimize the
possibility of disrupting the service availability of the CryptoServer cluster. The load balancing
and failover mechanisms react to errors in a similar way:
■ If an error indicates that the execution of the failed command might succeed on another
device, e.g. in case of a timeout error, then a connection to the next CryptoServer is
established, and the command is sent to that CryptoServer.
■ If an error indicates that the execution of the failed command most likely will not succeed
on another CryptoServer either, an error message is returned to the requesting application.
This would be the case, e.g., if a key could not be found. The existing connection remains.
If a connection to a CryptoServer cannot be established, or a connection breaks and cannot
be re-established, or any other error or problem dealing with load balancing and failover
mechanism occurs, it is reported in the audit log.
2.21.2 Preconditions
Before you start configuring and using the load balancing and failover features make sure that
the following requirements are fulfilled for the CryptoServer devices which should belong to
the same cluster.
Mandatory Preconditions
■ Make sure that all CryptoServer are accessible for the client computer to the same
network.
■ You have loaded exactly the same firmware modules (versions and functionality in case of
self-developed firmware modules) into all devices.
■ You have loaded the same MBK into all CryptoServer in the cluster.
Read Chapter 5.8, „Master Backup Key Management“, of this manual for detailed
information. In case you prefer using the command-line administration tool csadm, read
[CSADMIN].
■ You have synchronized the user databases of all CryptoServer in the cluster, i. e. the same
user account(s) and user credentials (password, keyfile, attributes) required for
authentication/Secure Messaging are available on every CryptoServer LAN in the cluster.
You find detailed information on how to create users, backup and restore a user database
with CAT in Chapter 5.7, „User Management“, of this document. In case you prefer using
the command-line administration tool csadm, read [CSADMIN].
Page 65 of 203
The usage of keys stored on smartcards for user authentication on CryptoServer devices
organized in a cluster is not supported.
Consider to synchronize user accounts between all CryptoServer in a cluster after creation of
new users, deletion of existing user accounts as well as any changes on existing user
accounts on a CryptoServer in the cluster.
■ If an internal key storage is used, you have synchronized all keys between all CryptoServer
in the cluster, e.g., by using the CryptoServer's backup and restore functions as described
in Chapter 5.10, “Backing up Databases”, 5.11, “Restoring Databases”, and 5.12, „Cloning
Databases“. In case you prefer using the command-line administration tool csadm, read
[CSADMIN].
When using internal key storage, and keys are created, deleted or modified by the application
accessing the cluster, these changes must be synchronized between all CryptoServer in the
cluster using some mechanisms external to the load balancing/failover implementation.
Optional Preconditions
■ The time in all CryptoServer belonging to the CryptoServer cluster is synchronized by
using NTP.
■ The audit log configuration file is synchronized between all devices in the cluster.
2.21.3 Use of External and Internal Key Storage

The load balancing and failover mechanisms support both internal and external key storage.
■ Internal key storage
All keys are stored in the key database, CXIKEY.db, inside the CryptoServer.
The load balancing and failover implementation does not provide an integrated key
replication algorithm for internal key storage.
Page 66 of 203
Do not create any new objects (keys or users) while using load balancing or failover with
internal key storage. To create additional objects, disable load balancing/failover in the
corresponding configuration file, create the new objects, replicate the information on all
devices in the cluster, and enable load balancing/failover in the configuration file again.
■ External key storage

All keys are stored in a database outside the CryptoServer
The following table gives an overview of the advantages and disadvantages to be considered
when you decide to use either internal or external key storage in combination with load
balancing or failover.
Key Storage Advantages Disadvantages
Internal ■ High security level since all ■ Manual key synchronization

keys are stored inside the between all cluster members is
CryptoServer, i.e., additional required
protection by the HSM sensor,
■ Limited number of keys (several
authenticated access
thousands, depending on the key
■ High performance length)
External ■ No manual key ■ Slightly lower performance than

synchronization between internal key storage
cluster members is required
■ High security level due to MBK
(AES-256) protection of the
external key storage
Table 12: Internal/External key storage – advantages and disadvantages
2.21.4 Configuration Settings

Currently, the load balancing mechanism is available only for the PKCS#11 API and for the
C++ interface of the CXI API. The failover mechanism is provided for the PKCS#11 API and for
both C++ and Java interfaces of the CXI API.
Configuration Settings for the Use with CXI

■ For detailed information on how to configure failover and load balancing for the C++
interface of the CXI API, read the HTML documentation provided on the SecurityServer
product CD under …\Documentation\Crypto_APIs\CXI.
Page 67 of 203
■ For detailed information on how to configure failover for the Java interface of the CXI API,
read the HTML documentation provided on the SecurityServer product CD under
…\Documentation\Crypto_APIs\CXI_Java.
Configuration Settings for the Use with PKCS#11

Before you can use load balancing and failover in your PKCS#11 environment some settings
in the configuration file cs_pkcs11_R2.cfg are required. For details, read [CS_PKCS11DEV]
provided on the SecurityServer product CD in the directory
…\Documentation\Crypto_APIs\PKCS11_R2\.
2.22 CryptoServer Simulator

The CryptoServer Simulator is a software program provided by Utimaco IS GmbH. It simulates
the cryptographic and administrative functions of all series CryptoServer. It is available for
Windows and Linux operating systems, and is delivered on the SecurityServer product CD, as
can be downloaded over the Utimaco web page https://hsm.utimaco.com/download-simulator
after successful registration.
The CryptoServer Simulator does not provide physical data protection as the real
CryptoServer device, and should only be used for test and evaluation purposes but not for
data protection in real production environments.
2.22.1 Features Overview

The next table describes the differences between the CryptoServer Simulator and a hardware
CryptoServer, i.e., a PCIe card mounted in a computer or in a CryptoServer LAN. The
mentioned items are described in detail below the table.
Item CryptoServer Simulator Hardware CryptoServer
PCIe card in a CryptoServer

computer LAN
Deployment Evaluation and test of data Data protection

purpose protection; firmware
development
Physical No Yes
protection
Sensor detection Possible, manually set, no Yes (automatically set)

default
Page 68 of 203
Item CryptoServer Simulator Hardware CryptoServer
PCIe card in a CryptoServer

computer LAN
Cryptographic No Possible
accelerator chip
CryptoServer CryptoServer Se-Series ■ CryptoServer Se-Series

series Gen2
Multiple Possible, static, no default No Yes

connections
Device address 3001@127.0.0.1 Example: IP address of

Windows: PCI:02 CryptoServer
LAN
Linux: /dev/cs2.02
Firmware Module Windows: .dll files .out files

Files
Linux: .so files
csadm commands
ListFirmware Windows: SDK C64 or C64+

Linux: SIM
ListFiles Windows: SDK C64 or C64+

Linux: SIM
ModuleInfo Windows: SDK-DLL CS2-COFF

Module type Linux: SDK-SO
ModuleInfo Windows: SDK C64+ or C64x

Target CPU type Linux: SIM
Table 13: Differences between the CryptoServer Simulator and a hardware CryptoServer
Deliverables
2
CryptoServer PCIe card mounted in the host computer where CAT is installed.
Page 69 of 203
The individual device key

An individual device key has already been generated and then stored in the CryptoServer.
As none of the options for administering this key are present, even Utimaco IS GmbH cannot
know the key value. You can decide whether you want to keep this individual device key as it
is, or completely reset the CryptoServer to generate a new individual device key.
ADMIN, the default administrator

The default administrator ADMIN has already been set up on the CryptoServer. He has the
permission 2 in the user groups 7 and 6 (22000000).
The authentication with electronic signature procedure has already been defined as the
authentication procedure for the default administrator ADMIN. The RSA algorithm is used as
the cryptographic algorithm here. The public part of the RSA key has already been loaded into
the CryptoServer's user database as authentication data.
You will find the private part of the RSA key, which is needed for authentication, on the
product CD. It is the ADMIN.key keyfile in one of the following directories:
\Software\Windows\x86-32\Administration\key.
\Software\Windows\x86-64\Administration\key
You do not need a password to open the file.

You will also find the private part of the RSA key on any smartcard that you have received as
part of the standard deliverables or as a result of an additional order.
To use the private RSA key from the smartcard, you must enter the PIN 123456.
Serial numbers and descriptors

Every CryptoServer has a number of serial numbers that identify component parts. Some of
these serial numbers will be displayed on the CryptoServer. This status information and
additional descriptors are displayed when the CryptoServer's status is queried or called.
All serial numbers and descriptors have already been loaded and stored on the device when
the CryptoServer is supplied.
2.22.2 Deployment Purpose

The CryptoServer Simulator is an ideal means for new customers to evaluate and test the
CrytptoServer without purchasing any hardware. The simulator should only be used for these
purposes. If the CryptoServer Simulator has been purchased as part of the software
Page 70 of 203
development kit, you can use it as well to develop and debug your own firmware modules
providing specific cryptographic functions and commands.
The CryptoServer Simulator does not provide physical data protection like a hardware
CryptoServer, and should not be used for data protection in real production environments.
2.22.3 Physical Protection

The CryptoServer Simulator usually runs on a non-protected computer, i.e. no physical
protection is provided as it is done on a hardware CryptoServer by using a tamper-protecting
foil etc., see Chapter 2.5.7, “Physical External Housing”, and Chapter 2.5.9, "Tamper-protecting
Foil”.
2.22.4 Sensor Detection

Per default, the CryptoServer Simulator does not provide any support for the simulation of
sensors. See Chapter 2.5.8, “Sensors”, for details about sensors. But you can create a sensor
alarm manually by editing the ALARM.curr file before starting the CryptoServer Simulator.
The default state of the ALARM.curr file is as follows:
# SDK Alarm state:
# Bit 7 -- External Erase
# Bit 6 -- Power Low
# Bit 5 -- Power High
# Bit 4 -- Outer Foil
# Bit 3 -- Inner Foil
# Bit 2 -- Temp High
# Bit 1 -- Power Fail
# Bit 0 -- Temp Low
ALARM=00000000
E.g., if you want to set a temperature too high alarm, change the value of the ALARM parameter
to 00000100. The alarm is indicated by a red alarm field in the status bar of the CAT main
window. If you click the Show Status button in the CAT toolbar (see Chapter 5.9.1, “Showing
the CryptoServer Status”), the alarm is indicated in the information field as well:
=== Thursday, February 23, 2017 10:38:53 AM CET ===
=== CryptoServer GetState ===
mode = Maintenance Mode
state = INITIALIZED (0x000afd84)
temp = 25.8 [C]
alarm = ON
sens = 02fd
- Alarm has occurred
- Temperature too high
bl_ver = 5.01.1.0 (Model: Se-Series Gen2)
Page 71 of 203
hw_ver = 0.00.8.15
uid = 4b61761d 25242a53 | Kav %$*S
adm1 = 5554494d 41434f20 43533030 30303030 | UTIMACO CS000000
adm2 = 53696d75 6c61746f 72205769 6e000000 | Simulator Win
adm3 = 496e6974 2d446576 2d312d4b 65790000 | Init-Dev-1-Key
You can combine two alarms at the same time, e.g., a temperature too high alarm with a
power too low alarm (ALARM=01000100).
You find the ALARM.curr file in the following directory:
<product CD installation directory>\Simulator\sim5_windows\devices
The same alarms are used in the hardware CryptoServer as well but they are noticed and
indicated automatically.
2.22.5 Cryptographic Accelerator Chip

The CryptoServer Se-Series and the CryptoServer Se-Series Gen2 may be delivered with a
cryptographic accelerator chip providing highest performance for RSA and/or ECC operations.
See e.g., Chapter , 2.5.5, "Cryptographic Accelerator Chip", and Chapter 2.7.2, “Firmware
Modules”, for details. The CryptoServer Simulator does not simulate any accelerator chip.
2.22.6 CryptoServer Series

The CryptoServer Simulator only simulates CryptoServer Se-Series Gen2, i.e., it simulates the
following memory sizes.
Memory Size
IRAM 1 Mbyte
SDRAM 32 Mbyte
Flash 64 Mbyte
NVRAM 1 Mbyte
Table 14: Memory sizes
2.22.7 Starting the Simulator

If you start the CryptoServer Simulator by executing the bl_sim5.exe file explicitely, you can
use the following options.
■ Without any option
The simulator is started in BOOTLOADER mode with one connection.
Page 72 of 203
■ –h
The simulator is started with multiple connections. See Chapter 2.22.8, "Multiple
Connections", for details. If you want to debug the simulator, omit this option.
■ –o
The SMOS operating system is started. The simulator is in the OPERATIONAL mode.
If this option is omitted, the simulator is in the BOOTLOADER mode. In this case, no
firmware modules are loaded and no operating system is started. You can load firmware
modules (mtc files) manually using the csadm LoadFile command. You can start the
operating system using the csadm StartOS command.
As a best practice, use a combination of the –h option and the –o option. On Windows, this
can be done by using the cs_sim.bat file.
2.22.8 Multiple Connections

If a CryptoServer PCIe card has been mounted in a computer, it offers only one connection to
the network. Only one command sent to the CryptoServer can be processed at a time.
However, in a CryptoServer LAN, there is a small server between the CryptoServer PCIe card
and the network. Multiple commands sent to the CryptoServer can be processed at a time.
The CryptoServer Simulator offers both, a single connection and multiple connections
depending on the way the simulator has been started. If you start the CryptoServer Simulator
by executing the bl_sim5.exe file explicitely, use the –h option to activate multiple
connections (see Chapter 3.3.2, “Using the CryptoServer Simulator”). This parameter starts a
small server providing multiple connections. If you do not use the –h option, you start a
simulator for a single connection. If you use the cs_sim.bat file instead, the CryptoServer
Simulator is started automatically with the –h option. This applies for Window. On Linux, the
cs_sim.sh file includes starting the CryptoServer Simulator with the –h option (see chapter
3.4.3, “Installing and Using the CryptoServer Simulator”).
2.22.9 Device Address

If you use a single instance of a CryptoServer Simulator, its device address is
3001@127.0.0.1. See Chapter 3.3.3, “Starting Multiple CryptoServer Simulator Instances” for
handling multiple simulator instances.
The device addresses for hardware CryptoServers are different. It is e. g., PCI:0 for a
CryptoServer PCIe card mounted in the Windows host computer where CAT is installed. If this
computer runs on Linux, /dev/cs2.0 is an example. If you use a CrytoServer LAN, its IP
address is its device address.
Page 73 of 203
If you have developed your own firmware modules providing specific cryptographic
functions and commands by using the CryptoServer Simulator, and you want to execute
these firmware modules on a hardware CryptoServer, the device address is the only item
that has to be changed.
2.22.10 Firmware Module Files

A firmware module file is a file compiled for the CryptoServer and ready for the interpretation
of the CryptoServer operating system SMOS.
In case of a hardware CryptoServer, it is an .out file. It is a COFF file (common object file
format).
In case of the CryptoServer SDK or the CryptoServer Simulator on Windows, it is a .dll file in
the MS-DOS MZ executable file format, i.e. using MZ as the magical number at the beginning of
the file.
In case of the CryptoServer Simulator on Linux, it is an .so file in the ELF format (executable
and linking format).
.out files created for a hardware CryptoServer cannot be used on a CryptoServer Simulator,
and .dll files and .so files created for the CryptoServer Simulator cannot be used on a
hardware CryptoServer.
2.22.11 csadm Commands

The following csadm commands differ slightly depending on whether they are executed on
the CryptoServer Simulator or on a hardware Cryptoserver:
The ListFirmware command lists among others information about the CPU target type the
firmware module has been compiled for. It is C64 or C64+ for a hardware CryptoServer, SDK for
the CryptoServer Simulator on Windows and SIM for the CryptoServer on Linux.
The ListFiles command lists among others information about the CPU target type the
firmware module has been compiled for. It is C64 or C64+ for a hardware CryptoServer, SDK for
the CryptoServer Simulator on Windows and SIM for the CryptoServer on Linux.
The ModuleInfo command lists among others information about the module type the
firmware module has been compiled for. It is CS2-COFF for a hardware CryptoServer, SDK-DLL
for the CryptoServer Simulator on Windows and SDK-SO for the CryptoServer on Linux.
The ModuleInfo command lists among others information about the CPU target type the
firmware module has been compiled for. It is C64+ or C64x for a hardware CryptoServer, SDK
for the CryptoServer Simulator on Windows and SIM for the CryptoServer on Linux.
Page 74 of 203
See [CSADMIN] for more details about csadm commands.
Page 75 of 203
Installing the CryptoServer Host Software
3 Installing the CryptoServer Host Software

In this chapter we describe how you install the software you need to run the CryptoServer on a
host computer with Windows and Unix/Linux operating systems. This includes:
■ The CryptoServer administration tools already mentioned above, csadm and CAT. These
tools can be used to administer both the CryptoServer PCIe and the CryptoServer LAN.
■ The CryptoServer Crypto APIs (JCE, CXI, CSP/CNG, PKCS#11)
■ The CryptoServer Simulator
■ The complete documentation of the CryptoServer and the CryptoServer LAN
Before you install the software for administering the CryptoServer, you first have to carry out a
few preparations.
3.1 System Requirements

■ CPU: Intel x86/x64, AMD x86/x86-64
■ Hard disk capacity: at least 120 Mbyte
■ RAM: more than 12 Mbyte
■ A free PCIe expansion slot, if you are using a CryptoServer PCIe Se-Series, CSe-Series or
Se-Series Gen2
▣ The computer in which you want to mount the CryptoServer PCIe card must be sited in
a cool, well ventilated place.
▣ Do not place it near sources of heat or in direct sunlight.
▣ You must ensure that the expansion slot in which CryptoServer is mounted lies in the
computer's ventilation airstream.
▣ The CryptoServer PCIe card should only be inserted below other plug-in cards that
produce heat.
▣ Ensure that you keep one expansion slot free between all other heat producing plug-in
cards, or other CryptoServer PCIe cards.
■ Network card: Ethernet 10/100/1000 Mbit/s for the connection to the CryptoServer LAN
■ Operating systems:
You find the current and complete list of supported operating systems in the document
CS_PD_SecurityServer_SupportedPlatforms.pdf on the SecurityServer/CryptoServer
SDK product CD in the directory …\Documentation\Product Details.
■ CD-ROM disc drive
■ Current Java versions for Windows/Linux
Page 76 of 203
3.2 Prepare for Installation

If you are using a CryptoServer LAN, you must first have integrated this into your network. In
addition, you must have assigned an IP address for this device. You can find detailed
instructions on how to bring your CryptoServer LAN into service in the CryptoServer LAN V4
Operating Manual provided on the SecurityServer product CD.
If you are using a CryptoServer PCIe card, you must already have mounted this along with the
corresponding driver.
The following manuals describe how to install the driver for the PCIe card:
■ CryptoServer PCIe - Operating Manual – CSe-Series
■ CryptoServer PCIe - Operating Manual – Se-Series
■ CryptoServer PCIe - Operating Manual – Se-Series Gen2
3.3 Performing the Installation for Windows

This chapter describes how to install the CryptoServer host software on a computer that is
running a Windows operating system.
The CryptoServer host software and the CryptoServer Simulator support the operating
systems listed in the document CS_PD_SecurityServer_SupportedPlatforms.pdf
provided on the SecurityServer/CryptoServer SDK product CD in the directory
…\Documentation\Product Details.
On a 64-bit computer, only a 64-bit Java SE Runtime Environment is supported by the

CryptoServer, and on a 32-bit computer, only a 32-bit Java SE Runtime Environment is
supported.
If you use a 64-bit computer, perform the following command in a command-line to verify
whether a 64-bit version of the Java SE Runtime environment has been installed on your
computer:
java -d64 –version
Output example:
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
If you use a 32-bit computer, verify whether a 32-bit Java version has been installed:
Page 77 of 203
Before you start the installation, check that you have installed the current version of the Java
SE Runtime Environment on your computer. We recommend you uninstall the old version of
the Java SE Runtime Environment from your computer first. Restart your computer before
you install the current version of the Java SE Runtime Environment.
3.3.1 Installing the Host Software and CryptoServer Simulator

To install the CryptoServer software, perform the following steps.
2. Insert the product CD in the computer's CD-ROM drive.
3. If the installation does not start automatically, double-click the file
CryptoServerSetup-<version number>.exe.
The installation wizard starts. The Welcome to the CryptoServer Setup Wizard dialog box
opens.
If necessary, you will be prompted to install the Microsoft runtime environment (VCRedist).
Click OK to confirm the corresponding dialog box.
4. Click the Next > button.

The Select Destination Location dialog box opens.
5. Use the Browse… button to select a different directory for installing the software or
confirm the default installation directory.
6. Click Next >.
The Select Components dialog box opens.
7. Select the components you want to install. By default, the CryptoServer Administration
Tools and CryptoServer Documentation are selected.
To install the CryptoServer Simulator for Windows, select the corresponding check box here.
8. Click Next > to continue the installation process.

The Select Start Menu Folder dialog box opens. Here you can select the directory in which
the shortcut used to start the program is to be stored.
Page 78 of 203
9. Confirm the default directory or click the Browse button to change the directory for the
shortcut.
If you click Don't create a Start Menu folder, no shortcut is created in the Windows Start
menu.
10. To continue with the installation, click the Next > button.
The Select Additional Tasks dialog box opens. Here you can decide whether to create a
desktop icon or not. By default, Create a desktop icon is selected.
11. Click Next >.
The Ready to Install dialog box opens. Here you can see what you have selected or
specified in the previous dialog boxes.
12. Click the Install button to start the installation of the software.
During installation a special setup window opens in which you are prompted to download
the Java(TM) Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files
from the Oracle web site. These files are required to work with the Utimaco CryptoServer
JCE Provider.
13. To use the JCE interface, click the Yes button in the Setup window.
The system continues the installation.
After completing the installation, the Completing the CryptoServer Setup Wizard dialog box
opens. Here you can specify whether the CAT should be launched automatically after
successful software installation. By default, the option Launch CryptoServer
Administration is selected.
14. Click the Finish button to complete the software installation.
You have now finished installing the CryptoServer software. CAT starts now by default and the
Settings dialog box is displayed.
3.3.2 Using the CryptoServer Simulator

To use the CryptoServer Simulator on a host computer running a Windows operating system,
proceed as follows:
1. Start the CryptoServer Simulator:
▣ By using the Windows Start menu and clicking
Start > All Programs > Utimaco > CryptoServer > CryptoServer Simulator
Page 79 of 203
▣ By double-clicking the desktop icon for the CryptoServer

Simulator shown to the right. The desktop icon is available if
you kept the default setting for desktop links during the
installation of the host software.
▣ By using a command-line window:
a) Open a command-line in the product CD installation directory for the CryptoServer

Simulator
<product CD installation directory>\Simulator\sim5_windows\bin.
2. Type cs_sim.bat and press ENTER.

Alternatively, type bl_sim5.exe –h –o and press ENTER.
The –h option starts a small server enabling multiple connections (see Chapter 2.22.8,
“Multiple Connections”). The –o option starts the SMOS operating system.
If a Windows Security Alert windows opens, click Allow access.

This starts the Utimaco CryptoServer SDK5 – Simulator command-line application. Do not
close this application until you have finished using the simulator.
3. Double-click the CryptoServer Administration desktop icon to start the CAT. The CAT main
window opens.
4. In the toolbar, click Devices.
This opens the CryptoServer Devices dialog box.
5. Enter the address 3001@127.0.0.1 in the New Device text box.
6. Click the Add to List button.
7. Click the Test button to check whether a connection can be established. The test result is
displayed in a separate window.
8. Click OK to close this window.
9. Close the dialog box CryptoServer Devices by using the Close button.
The successfully established connection is now confirmed in the info field of the CAT main
window. Furthermore, information about the date and time as well as the current status of the
CryptoServer Simulator is displayed.
You can use the CryptoServer Simulator as described in the sections that follow this one.
3.3.3 Starting Multiple CryptoServer Simulator Instances

As from SecurityServer 4.01, the simultaneous start and use of multiple CryptoServer
Simulator instances is possible. This might be very useful, for example, if you want to
Page 80 of 203
configure and simulate your own CryptoServer load balancing cluster for evaluation and test
purposes.
Prerequisites:
You have installed the CryptoServer host software provided on the
SecurityServer/CryptoServer SDK product CD 4.01 and later as described in Chapter 3.3.1.
Proceed as follows:
1. Start the CryptoServer Simulator as described in step 1 of Chapter 3.3.2, “Using the
CryptoServer Simulator”.
2. Configure it according to your individual requirements, for example, create specific users
as explained in Chapter 5.7.2, “Creating a User”.
3. Close the CryptoServer Simulator after you have finished the configuration.
4. Open a command-line window.
If you open the path mentioned in the next step in Windows Explorer, enter cmd in the
address field and press the ENTER key, a command-line in the specified path opens..
5. Change to the CryptoServer product CD installation directory:

cd <product CD installation>\Software\Windows\Simulator\sim5_windows\bin
6. Start, for example, three CryptoServer Simulator instances by typing cs_multi.bat 3 and
pressing ENTER.
Three identically configured CryptoServer Simulator instances are started. They have the
following device addresses:
▣ First instance – 3001@localhost
▣ Second instance – 3003@localhost
▣ Third instance – 3005@localhost
Page 81 of 203
Figure 9: Example for running three CryptoServer Simulator (Windows) instances simultaneously
To close all CryptoServer Simulator instances, change to the command-line window and press
any key. When the instances are closed, all your changes are lost. The next time you start
multiple CryptoServer Simulator instances they will have the same configuration as the one
you have previously configured in step 2.
To only terminate the Simulator that is running in the currently active command-line window,
for example, the instance with the device address 3003@localhost, press CTRL+C. The other
CryptoServer Simulator instances, that have been started, remain running and can be used.
3.3.4 Setting up Java Cryptography Extension (JCE) for Windows

If you want to use the JCE interface you need the Java(TM) Cryptography Extension (JCE)
Unlimited Strength Jurisdiction Policy Files.
Download the appropriate Java(TM) Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files for the Java version installed on your computer.
Page 82 of 203
Before you download the Java(TM) Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files, check which Java version is installed on your computer by typing
java –version in a terminal.
1. Load the appropriate ZIP file jce_policy-x.zip onto your computer.

2. Extract jce_policy-x.zip on your computer.
From the jce_policy-x.zip file you require the following files:
▣ local_policy.jar
▣ US_export_policy.jar
3. Copy them into the following directory:
C:\Program Files\Java\jrex\lib\security
This completes the installation of the Java(TM) Cryptography Extension (JCE) Unlimited
Strength Jurisdiction Policy Files.
3.3.5 Installing the PIN Pad Driver

To be able to use the delivered PIN pad for the CryptoServer administration, the appropriate
driver, provided by Utimaco IS GmbH, must be manually installed on the host computer where
the host software has already been installed.
Prerequisites:
■ You have uninstalled any previous PIN pad driver versions on the host computer.
In case the PIN pad REINER SCT cyberJack (as shown in Figure 1, Chapter 2.2.2, “PIN Pads”)
was delivered to you and there is a version of Utimaco's PIN pad driver already installed on
the host computer and listed in the Windows Device Manager as LibUSB Devices, then no
driver update or new driver installation is required.
■ You have inserted the delivered product CD in the computer's CD-ROM drive.
Page 83 of 203
Under no circumstances install the "Base components" USB driver for Windows from the
company REINER SCT.
If your Windows operating system already has REINER SCT's "Base Components" driver
installed, it is essential that you remove it before you install the Utimaco IS GmbH driver.
The official REINER SCT "Base Components" driver and the driver from Utimaco IS GmbH
cannot be used in parallel.
Under no circumstances run the “cyberJack Device Manager” from the REINER SCT Base
components, and perform a firmware update of the PIN pad driver.
Installing a firmware update on the PIN pad renders this PIN pad unusable with CryptoServer
administration tools and cryptographic libraries. After a firmware update, it is not possible to
revert to the PIN pad firmware as shipped by Utimaco IS GmbH.
1. Connect the USB plug of the PIN pad with the host computer.
You are prompted in a separate dialog box to download the PIN pad driver from the
Internet or to let Windows install it automatically.
2. Close this dialog box without selecting any of these options.
3. Double click the Other Devices entry in the displayed list.
4. Depending on the PIN pad you are using, proceed as follows:
▣ If the REINERSCT cyberJack PIN pad shown in Figure 1 has been supplied to you,
double-click cyberJack e-com(a).
▣ If the Utimaco cyberJack One PIN pad shown in Figure 2 has been supplied to you,
double-click cyberJack ONE.
The <PIN pad type> Properties dialog box opens.
5. Click the Update Driver button.
6. The Update Driver Software - <PIN pad type> dialog box opens.
7. Click Browse my computer for driver software.
8. In the dialog box that opened, click Browse and select the PIN pad driver provided on the
product CD.
You find the driver software on the product CD delivered by the Utimaco IS GmbH here:
▣ For a 32-bit system:

\Software\Windows\x86-32\Tools\cyberJack\Driver\
9. For a 64-bit system:

\Software\Windows\x86-64\Tools\cyberJack\Driver\
10. Click Next.
Page 84 of 203
11. Confirm the Windows Security warning with Install.

The PIN pad driver is now being installed. When completed, the successful driver
installation is confirmed in a separate dialog box.
12. Click Close to close the installation confirmation dialog box.
13. Click Close to close the <PIN pad type> Properties dialog box.
The PIN pad is now displayed with its name – cyberJack e-com(a) or cyberJack ONE - in the
Windows Device Manager as a subentry of the Universal Serial Bus devices entry.
3.4 Performing the Installation for Linux

This chapter describes how to install the CryptoServer host software on a computer that is
running a Linux operating system.
3.4.1 Installing csadm

To install csadm, follow these steps:
1. If there is no ~/bin directory present on your system, create it in your user directory:
mkdir ~/bin
2. Copy the csadm relevant for your operating system (32-bit or 64-bit) into the ~/bin
directory.
An example for Linux 64-bit:
cp <mount point of the product CD>/Software/Linux/x86-64/Administration/csadm ~/bin
3. Ensure that you have write and execute permissions for the CryptoServer administration
tool csadm.
chmod –R u+w+x ~/bin
4. Add the ~/bin directory to the path in the user configuration file in the shell that is being
used.
In our example we have used a bash as the shell, i.e., open the ~/.bashrc file, and then
add the following line to it:
export PATH=$PATH:~/bin
5. Save the changes and close the ~/.bashrc file.
3.4.2 Installing CAT
CAT can be used on Linux 32-bit and 64-bit systems.
Page 85 of 203
On a 64-bit computer, only a 64-bit Java SE Runtime Environment is supported by the

CryptoServer, and on a 32-bit computer, only a 32-bit Java SE Runtime Environment is
supported.
If you use a 64-bit computer, perform the following command in a command-line to verify
whether a 64-bit version of the Java SE Runtime environment has been installed on your
computer:
Output example:
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
If you use a 32-bit computer, verify whether a 32-bit Java version has been installed:
To be able to use the CAT, install first the appropriate Sun Java Runtime Environment for the
Java version available on your computer.
Perform the following command in a command-line to retrieve the installed Java version:
java –version
Use the package manager for your Unix/Linux system to install the Oracle Java Runtime
Environment.
To install the CAT, follow these steps:

1. Copy the cat.jar file into your user directory.
cp <path to the Product CD>/Software/Linux/x86-32/Administration/cat.jar ~/
or
cp <path to the Product CD>/Software/ Linux/x86-64/Administration/cat.jar ~/
2. Start CAT with the following command:

java -jar ~/cat.jar
3.4.3 Installing and Using the CryptoServer Simulator

The CryptoServer Simulator supports the following Linux (32-bit and 64-bit) operating
systems:
■ Red Hat Enterprise Linux 6.4/6.5/6.6/7.0/7.1/7.2
■ SUSE Linux Enterprise Server (SLES) 11
■ Debian 7 "Wheezy" and Debian 8 "Jessie"
Page 86 of 203
Prerequisites:
If you are using a 64-bit Linux operating system, you must have installed gcc-multilib on it.
To perform the installation of gcc-multilib, use the commands described in the next table
and consider that you must have root permissions to do so. The root permissions are only
needed for this installation but installing other components should be done as a non-
privileged user.
Operating system Installation command
Debian 8 apt-get install gcc-multilib
SLES zypper install glibc-32bit
RHEL yum install glibc.i686 glibc-devel.i686 libstdc++-

devel.i686
Table 15: Examples for installing the gcc-multilib
Installation and Execution

To install the CryptoServer Simulator, proceed as follows:
1. Create a new directory in your home directory, for example:
mkdir -p ~/Utimaco/CryptoServer/Simulator
2. Copy the CryptoServer Simulator files provided on the SecurityServer product CD to the
new directory.
cp –r /<mount point of SecurityServer product CD>/Software/Linux/Simulator/*
~/Utimaco/CryptoServer/Simulator
3. Define the environment variable CRYPTOSERVER which is needed for the use of the
CryptoServer Simulator:
export CRYPTOSERVER=3001@localhost
Add this command to your ~/.bashrc, ~/.profile or ~/.zshrc according to your shell to call it
automatically.
4. Ensure that you have write and execute permissions for the CryptoServer Simulator files.
chmod –R u+w+x ~/Utimaco/CryptoServer/Simulator/sim5_linux
5. Start the CryptoServer Simulator:

~/Utimaco/CryptoServer/Simulator/sim5_linux/bin/cs_sim.sh
Page 87 of 203
The –h option in this sh file starts a small server enabling multiple connections (see
Chapter 2.22.8, “Multiple Connections”). The –o option starts the SMOS operating system.
This starts the Utimaco CryptoServer SDK5 – Simulator command-line application. Do not
close this application until you have finished using the simulator.
3.4.4 Starting Multiple CryptoServer Simulator Instances

As from SecurityServer 4.01 the simultaneous start and use of multiple CryptoServer
Simulator instances is possible. This might be very useful, for example, if you want to
configure and simulate your own CryptoServer load balancing cluster for evaluation and test
purposes.
Prerequisites:
You have installed the CryptoServer Simulator for Linux provided on the
SecurityServer/CryptoServer SDK product CD 4.01 and later as described in chapter 3.4.3.
Proceed as follows:
1. Start the CryptoServer Simulator as described in step 5 of Chapter 3.4.3, “Installing and
Using the CryptoServer Simulator”.
2. Configure it according to your individual requirements, for example, create specific users
as explained in Chapter 5.7.2, “Creating a User”.
3. Close the CryptoServer Simulator after you have finished the configuration.
4. Open a command-line window.
If you open the path mentioned in the next step in Windows Explorer, enter cmd in the
address field and press the ENTER key, a command-line in the specified path opens..
5. Change to the CryptoServer product CD installation directory:

<product CD>\Software\Linux\Simulator\sim5_linux\bin
6. Start, for example, three CryptoServer Simulator instances by typing cs_multi.sh 3 and
pressing ENTER.
Three identically configured CryptoServer Simulator instances are started. They have the
following device addresses:
▣ First instance – 3001@localhost
▣ Second instance – 3003@localhost
Page 88 of 203
▣ Third instance – 3005@localhost
Figure 10: Example for running three CryptoServer Simulator instances simultaneously (Linux)
To close all instances, press any key in the terminal. When the instances are closed, all your
changes will be lost. Next time you start multiple CryptoServer Simulator instances they will
have the same configuration as the one you have previously configured in step 2.
To only terminate the Simulator that is running in the currently active command shell, for
example, the instance with the device address 3003@localhost, press CTRL+C. The other
CryptoServer Simulator instances, that have been started, remain running and can be used.
3.4.5 Setting up Java Cryptography Extension (JCE) for Linux

If you want to use the JCE interface, you need the Java(TM) Cryptography Extension (JCE)
Unlimited Strength Jurisdiction Policy Files that can be downloaded from the Oracle website.
These files are required for working with the Utimaco's CryptoServer JCE Provider.
Page 89 of 203
Check the Java version installed on your computer by performing the “java –version”
command before you start downloading the Java(TM) Cryptography Extension (JCE)
Unlimited Strength Jurisdiction Policy Files.
1. Load the appropriate ZIP file jce_policy-x.zip onto your computer.

2. Extract jce_policy-x.zip on your computer.
From the jce_policy-x.zip file you require the following files:
▣ local_policy.jar
▣ US_export_policy.jar
The following example shows the path for Java 6 on a computer with a Linux operating
system and 64-bit architecture.
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/security/US_export_policy.jar
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/security/local_policy.jar
3. Copy the policy files shown above to the appropriate directory on your Linux system.
3.4.6 Configuring the PIN Pad

There is no PIN pad driver installation required for host computers with a Linux operating
system. However, for using an PIN pad delivered by Utimaco on a Linux host computer, the
definition of a special udev rule is necessary.
■ For using the REINERSCT cyberJack PIN pad (see Figure 1 in chapter 2.2.2):
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0c4b", ATTR{idProduct}=="0400",
MODE="666"' > /lib/udev/rules.d/z80_cyberjack.rules
■ For using the Utimaco cyberJack One PIN pad (see Figure 2 in chapter 2.2.2):
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0c4b", ATTR{idProduct}=="0600",
MODE="666"' > /lib/udev/rules.d/z80_cyberjack.rules
■ For using both PIN pads:

echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0c4b", MODE="666"' >
/lib/udev/rules.d/z80_cyberjack.rules
Page 90 of 203
Administering the CryptoServer with CAT
4 Administering the CryptoServer with CAT

CAT starts by default automatically once the CryptoServer host software has been installed
correctly.
4.1 CAT - Overview of the Graphical User Interface (GUI)

In the following you get an overview of the GUI elements in CAT and their meaning.
The CAT main window is the main operating control of CAT. It contains the following
elements:
■ Menu bar
The menu bar is located directly under the title bar in the upper border of the CAT main
window. It enables you to access all functions for CryptoServer administration.
■ Toolbar
The toolbar is located under the menu bar. It makes it possible for you to quickly access
the most often used administration functions of CAT, like for example, setting up a new
Page 91 of 203
device, getting the current CryptoServer status, the user management, logging on/logging
off from CryptoServer, the management of Master Backup Keys and firmware.
■ Information field
The information field comprises the middle area of the CAT main window under the
toolbar. Here various status and firmware information is shown which you can retrieve by
clicking the Show menu, as well as by clicking the Show Status, Show Files, Show
Firmware buttons in the toolbar.
■ Status bar
The status bar is located on the bottom border of the CAT main window.
Here you can select the device you want to administer by using the combo box Device at
the left window border.
Furthermore, the most important status information about the administered CryptoServer
is shown:
▣ Operating Mode (Mode:)

If the CryptoServer is running correctly, and is ready for use, you will see Operational
here.
▣ Current authentication status (Login State:)
This displays the current login status. If the default administrator, ADMIN, with
authentication status 22000000, is logged into the CryptoServer, this authentication
status is displayed here. If another administrator with authentication status 20000000
has logged on at the same time, the total authentication status is displayed here. In
this case, you would see authentication status 42000000.
▣ Current remaining time until the existing Secure Messaging session is terminated
(Session:)
A Secure Messaging connection to the CryptoServer is established every time an
administrator logs in to the CryptoServer. This connection is set to a maximum
duration of 14 minutes and 59 seconds. The remaining length of time for the Secure
Messaging connection is displayed here.
The duration of the Secure Messaging connection resets to 14 minutes and 59
seconds every time an administrator sends a command to the CryptoServer, or when
another administrator logs in to the CryptoServer. No matter how many administrators
log in simultaneously to the CryptoServer, only one Secure Messaging connection is
ever set up to the CryptoServer. As a consequence, when a Logoff All is performed, all
administrators who are currently logged on are logged off simultaneously. This is
because the Secure Messaging connection, which is being used by these multiple
administrators, is terminated.
▣ Current temperature of the CryptoServer in °C and in °F (Temp.:)
Page 92 of 203
▣ Alarm state (Alarm:)

This shows whether an alarm is present. You see either OFF if no alarm has been
triggered or ON if an alarm has occurred.
▣ Status of the CryptoServer Carrier Battery (Battery:)
The status and the power of the carrier battery (in V) is displayed here. The status can
be either OK or LOW. If you see the status LOW, this means the carrier battery is in a
critical state. If you are running the CryptoServer in a computer, it is supplied with
power via the PCI or PCIe interface. If the CryptoServer is running as a standalone
device, it is powered by the carrier battery. If the status drops to LOW it may happen
that the supply of power can no longer be guaranteed. This may trigger an alarm which
then deletes all data from the CryptoServer.
4.2 Setting Up a New Device

Using CAT you can administer several CryptoServers simultaneously which you have set up
previously in CAT.
To set up a new device in CAT, proceed as follows:

1. Start CAT.
2. Click the Devices button in the toolbar.
The dialog box CryptoServer Devices opens.
CAT starts automatically after finishing the installation of the CryptoServer host software
provided on the SecurityServer product CD, and the dialog box CryptoServer Devices
opens. You have to enter the address of the device you want to administer in this dialog box.
3. Enter the address of the device you want to use in the New Device text box.
Possible address entries:
Page 93 of 203
Device address Description
/dev/cs2.n CryptoServer PCIe card No. n+1 mounted in the Linux host
where n = {0, 1, 2, …, 7} computer where CAT is installed.
The maximum number of eight CryptoServer PCIe cards can be

changed in the source of the Linux driver.
PCI:n CryptoServer PCIe card No. n+1 mounted in the Windows host
where n = {0, 1, 2, …, 31} computer where CAT is installed.
TCP:288@194.168.4.107 IP address and port number of a CryptoServer LAN
In CAT, always use IP addresses without leading zeros although

they are shown in the CryptoServer LAN display, e.g.,
194.168.004.107.
TCP:194.168.4.107 IP address of a CryptoServer LAN (default: port=288)

194.168.004.107.
194.168.4.107 IP address of a CryptoServer LAN (default: protocol=TCP,

port=288)

194.168.004.107.
TCP:288@cslan01 Host name and port number of a CryptoServer LAN (using DNS
request to resolve host name)
TCP:cslan01 Host name of a CryptoServer LAN (using DNS request to resolve

host name, default: port=288)
cslan01 Host name of a CryptoServer LAN (using DNS request to resolve

host name, default: protocol=TCP, port=288)
TCP:3001@127.0.0.1 or Local CryptoServer simulator for Windows/Linux (SDK)

TCP:3001@localhost
3001@127.0.0.1 or Local CryptoServer simulator for Windows/Linux (SDK) with the

3001@localhost default protocol TCP
Table 16: Example values for the device address
Page 94 of 203
If you are going to use a CryptoServer LAN, first configure the CryptoServer LAN's IP address
and the IP address of the default gateway with the menu control options on the front panel
of the CryptoServer LAN. For step-by-step instructions, consult the CryptoServer LAN - Quick
Start Guide or the CryptoServer LAN – Administration Manual.
From CSLANOS version 4.2.0 and later the Internet Protocols IPv4 and IPv6 are supported.
In CAT, always use IP addresses without leading zeros although they are shown in the
display on the front panel of the CryptoServer LAN, e.g., 194.168.004.107.
4. Click the Add to List button to confirm the entry.

5. Click the Test button to check whether a connection to the device can be established.
If the connection has been created successfully, a message appears both in a separate
window and in the CAT main window.
6. Click OK to close the CryptoServer Devices dialog box.
If the connection has been established successfully, this is confirmed in the information field
of the CAT main window. Additionally, information about the date and the time of connection
is displayed.
4.3 Switching between Devices

In the left part of the status bar in CAT's main window, you see which devices have been set
up. Here you can select which devices you want to administer with the CAT.
4.4 Setting up a PIN Pad under Windows

Once you have configured the device address of your CryptoServer in CAT (see Chapter 4.2,
“Setting Up a New Device”), connected the supplied PIN pad to the host computer and
installed the PIN pad driver as described in Chapter 3.3.5, you have to set up the PIN pad in
CAT. Proceed as follows:
1. Click the File menu and select Settings.
This opens the Settings dialog box.
2. Select the Autodetection option in the Type box.
The PIN pad is automatically recognized by the CryptoServer.
Page 95 of 203
In case the PIN pad could not be recognized automatically by the CryptoServer, you can
select here alternatively the option corresponding to the name of your PIN pad: REINERSCT
cyberJack (shown in Figure 1) or Utimaco cyberJack One (shown in Figure 2).
3. Select the Port to which you have connected the PIN pad. By default, USB Port is selected.
4. Click OK to confirm your selection and then click the Timeout tab.
5. Here is where you set the Connection Timeout between the CAT and the CryptoServer in
milliseconds.
The default setting is 5000 milliseconds. This default setting means that the CAT
attempts to set up a connection to the CryptoServer for 5 seconds. If this does not
succeed, the attempt is interrupted due to a timeout.
6. Once you have finished editing the data in the Settings dialog box, click OK.
The settings you have made are saved.
4.5 Setting up a PIN Pad under Linux

Once you have configured the device address of your CryptoServer in CAT, connected the
supplied PIN pad to the host computer and configured the required udev rule as described in
Chapter 3.4.6, you have to set up the PIN pad in CAT. Proceed as follows:
1. Click the File menu and select Settings.
This opens the Settings dialog box. By default, the PIN pad tab is displayed.
2. Select Autodetection in the Type box.
The PIN pad is automatically detected by the CryptoServer.
In case the PIN pad could not be recognized automatically by the CryptoServer, you can
select here alternatively the option corresponding to the name of your PIN pad: REINERSCT
cyberJack (shown in Figure 1) or Utimaco cyberJack One (shown in Figure 2).
3. Select the Port to which you have connected the PIN pad. By default, USB Port is selected.
4. Click OK to confirm your selection and then click the Timeout tab.
5. Here is where you set the Connection Timeout between the CAT and the CryptoServer in
milliseconds.
The default setting is 5000 milliseconds. This default setting means that the CAT
attempts to set up a connection to the CryptoServer for 5 seconds. If this does not
succeed, the attempt is interrupted due to a timeout.
Page 96 of 203
6. Once you have finished editing the data in the Settings dialog box, click OK.
The settings you have made are saved.
4.6 User Login

Specific security relevant actions can only be performed by users who are logged on to the
CryptoServer respectively users who have authenticated themselves successfully against the
CryptoServer.
To log in to the CryptoServer, proceed as follows:
1. Start CAT.
2. Click the Login/Logoff button in the toolbar.
The Login/Logoff User dialog box opens. It contains a list of all users created by you and
the default user ADMIN.
3. Select the user you require (e.g. ADMIN) and click the Login button.
The dialog box Choose User Token for Login opens.
4. Select the appropriate authentication mechanism.
■ Smartcard Token
If the user is using an RSA or an ECDSA authentication key stored on a
smartcard, click Smartcard Token and then click OK in the Choose User Token
for Login dialog box. Follow the instructions on the PIN pad.
■ Keyfile Token
If the user is using an RSA or ECDSA authentication key stored in a keyfile, click
Keyfile Token, and proceed as follows:
b) Click the search button (…) next to the Key Path text box.
The Set Name and Path for User Keyfile Token dialog box opens.
c) Select the keyfile you require, e.g., ADMIN.key.
d) Click Open.
e) In case the keyfile is protected with a password, enter the password in the
Password text box of the Choose User Token for Login dialog box.
5. Click OK in the Choose User Token for Login dialog box.

The dialog box closes. If the user login succeeded, a green check mark appears on the left
hand side of the user item.
4.7 Setting the Time in the CryptoServer

The real time clock (RTC) of the CryptoServer shows the date and time with millisecond
precision. This precise time information is required for the logfile because every entry is
Page 97 of 203
stored here along with the exact time at which it was made. This time information can also be
used for applications, such as the timestamp service.
The time of the CryptoServer can be set up by one or more (n-person rule) authenticated
users with min. permission 2 (i.e., authentication status 02000000) in the user group 6 or by
You can set the time shown by the RTC in the CryptoServer.
1. Start CAT.
2. Click Login/Logoff in the toolbar.
The Login/Logoff User dialog box opens. It contains a list of all users created by you and
default users (e.g., ADMIN).
3. Select the user you require (e.g., ADMIN) and click the Login button.
The Choose User Token for Login dialog box opens.
4. Select the appropriate authentication mechanism.
■ Smartcard Token
If you have selected Smartcard Token, click OK in the Choose User Token for
Login dialog box and follow the instructions on the PIN pad.
■ Keyfile Token
If you have selected Keyfile Token, proceed as follows:
a) Click the search button (…) next to Key Path the text box.
The Set Name and Path for User Keyfile Token dialog box opens.
b) Select the keyfile you require, e.g., ADMIN.key.
c) Click the Open button.
d) In case the keyfile is protected with a password, enter the password in the
Password text box of the Choose User Token for Login dialog box.
5. Click the OK button in the Choose User Token for Login dialog box.
The dialog box closes. If the user login succeeded, a green check mark appears on the left
hand side of the user item.
6. Click Close to close the Login/Logoff User dialog box.
7. On the Manage menu, click Date/Time.
The CryptoServer Date/Time dialog box opens. Here you can choose between two options
to set up the date and time of the CryptoServer.
■ Apply host time

Select this option to transfer the date and time from the host system and use it
for the CryptoServer.
Page 98 of 203
■ Apply time manually

Select this option to set the date and the time of the CryptoServer manually. Use
the predefined date and time format.
8. Click the Apply button.

The settings you have performed are saved.
9. Click OK.
The CryptoServer Date/Time dialog box closes.
If you only want to view the time in the CryptoServer, and not to set it, you do not need to be
logged in to the CryptoServer.
You must reset the time of the CryptoServer after every alarm triggered by a power failure or
if the battery level falls too low.
4.8 Generating an MBK

Before you can use the full range of the CryptoServer's functionality, you must generate a
Master Backup Key (MBK) and import it into the CryptoServer. This chapter describes how to
generate a Master Backup Key.
Before you start generating an MBK:
■ Answer the following questions:
▣ Do you want to store the MBK in keyfiles (outside the CryptoServer) or on smartcards?
▣ How many people shall the MBK be distributed to?

This specifies the number of key shares the MBK is to be split in. This number is
defined as the parameter n.
▣ What is the minimum number of key shares (people) required to use the MBK?
This specifies the number of key shares needed to make the MBK reconstruction
possible. This number is defined as the parameter m.
n defines the number of people to whom the MBK shall be distributed, and m defines
the minimum number of people required to use the MBK.
The examples below clearly illustrate the relationship between m and n key shares and
show which combinations are useful:
Page 99 of 203
Key Shares Number Meaning
n (shares) 4 Four people have a part of the MBK.
Two of these four people must therefore be present

m (shares) 2
before the MBK can be used.
Table 17: Example for an MBK split into 4 key shares
Key Shares Number Meaning
n (shares) 2 Two people have a part of the MBK.
m (shares) 2 Two people must be present before the MBK can be

used.
Table 18: Example for an MBK split into 2 key shares
■ Make sure that you have the required number n of smartcards delivered by Utimaco IS
GmbH at hand before you start generating the MBK.
To generate the MBK, you must log in to the CryptoServer with at least permission 2 in the
user group 6 (authentication status 02000000) or as the default user ADMIN.
To generate an MBK execute the following steps:

1. Start CAT.
The Login/Logoff User dialog box opens.
3. Log in to the CryptoServer as the default administrator ADMIN.
You find further details on how to log in to the CryptoServer in Chapter 4.6, „User Login“, in
this manual.
5. Click the Manage MBK button in the toolbar.
The Remote Master Backup Key (MBK) Management dialog box opens. The Generate tab
is shown by default.
6. In the MBK Name text box, enter a name (max. eight characters) for the MBK.
Page 100 of 203

The type of the MBK is predefined (MBK Type 256 Bit AES Key) and is unchangeable.
7. Select how many parts you want to split the key into.
▣ If you enable XOR, the key is split into two parts and therefore two people will be
needed to use the MBK (two-person rule).
▣ If you click m out of n, you can select any value as the number of parts the MBK is to
be split into n (Shares) and the number of people needed to use the MBK m (Shares).
In our example we have selected the m out of n option, where n (Shares) = 3 and
m (shares) = 2.
8. Click Automatic MBK Import.
9. Click Generate.
This opens the Master Backup Key (MBK) Share Storage 1/n dialog box.
10. In this dialog box, specify whether you want to store the MBK on a smartcard MBK
Smartcard Token or as a keyfile MBK File Token.
■ MBK Smartcard Token

In our example we need three smartcards.
a) Insert the first smartcard into the PIN pad.
b) Press the OK button on the PIN pad.
c) Enter the PIN for the smartcard.
d) Press the OK button on the PIN pad.
e) Repeat the steps a) to d) for the remaining smartcards n-1 shares.
■ MBK File Token
a) Enter the location for the MBK into the Key Path text box manually or use the
search button (…).
b) Specify (optionally) a password in the Password text box to protect the MBK
keyfile from unauthorized access.
c) Click OK.
The generation of the MBK is initiated and confirmed in a separated window.
d) Repeat the steps a) to c) for the remaining two key parts n shares.
11. Once you have saved the MBK either as a keyfile or on a smartcard, close the Remote
Master Backup Key (MBK) Management dialog box by clicking Close.
Page 101 of 203

4.9 Changing the Authentication Key

The default administrator ADMIN has an authentication key (stored as a keyfile and on a
smartcard) which is known to the manufacturer Utimaco IS GmbH (see Chapter 2.8.1, "Default
Authentication Key"). For this reason, it is imperative you change this authentication key. You
can generate the new authentication key as a keyfile or on a smartcard. Here we show you
how to generate the key on a smartcard.
First generate a new authentication key and then assign this key to the default administrator
ADMIN. To do so you need at least three smartcards.
1. In the Authentication Token menu, click Smartcard.
The Smartcard Token Management dialog box opens. The Generate tab is shown by
default.
2. As you are the default administrator ADMIN you are obliged to use the RSA signature
method and therefore you must select the RSA option.
3. In the Key-Info text box, enter a key name.
4. Select the key length in the RSA Key Length (bits) box.
For security reasons we recommend you not change the default value 2048 for the RSA
Key Length (bits).
5. In the Number of Backups box, specify how many backups are to be generated from this
key. For one backup you require two backup smartcards.
6. Click Generate.
7. Follow the instructions on the PIN pad.
A confirmation window opens confirming the successful generation of the new
authentication token.
8. Close the Smartcard Token Management dialog box with Close.
After you have generated the new key you must assign it to the default administrator ADMIN.
9. Click the Manage User button in the toolbar.
This opens the User Management dialog box.
10. Select the ADMIN user.
11. Click the Change Token/Password button.
This opens the Choose User Token for Login dialog box.
12. Use the "old" authentication key to log in to the CryptoServer as the default administrator
ADMIN and click OK.
Page 102 of 203

A confirmation window opens confirming the successful authentication of the ADMIN

user.
13. Click OK to close it and to be able to continue.
The dialog box Choose new User Token opens.
14. Select Smartcard Token and click OK.
15. Insert the smartcard with the new authentication key into the PIN pad.
16. Click the OK button on the PIN pad.
Once the authentication key for the default administrator ADMIN has been successfully
changed, the system will confirm this to you in a separate window.
4.10 Changing the PIN for Smartcards

If you purchased a smartcard from us for administering the CryptoServer, we recommend that
you change the predefined default PIN for these cards.
You can change the following PINs on the smartcards:
■ The smartcard PIN for the authentication key
■ The smartcard PIN for the MBK
4.10.1 Changing the PIN for the Authentication Key

1. Click the Authentication Token menu and select Smartcard .
The Smartcard Token Management dialog box opens. The Generate tab is shown by
default.
2. Click the Change PIN tab.
3. Make sure that the PIN pad is connected to the host computer.
4. Click the Change PIN button in the Smartcard Token Management dialog box.
5. Follow the instructions on the PIN pad. First enter the old PIN, and then enter the new PIN.
Only PINs consisting of 6 up to 12 digits are supported. Confirm the new PIN. A message
window appears to tell you that the PIN was changed successfully.
4.10.2 Changing the PIN for the MBK Smartcards
You do not have to log in to the CryptoServer if you only want to change the PIN of the
smartcard on which the MBK is stored.
Page 103 of 203


This opens the Remote Master Backup Key (MBK) Management dialog box. The Backup
tab is shown by default.
2. Click the MBK Change PIN tab.
3. Make sure that the PIN pad is connected to the host computer.
4. Click the Change PIN button. First enter the old PIN and then enter the new PIN. Only PINs
consisting of 6 up to 12 digits are supported. Confirm the new PIN. A message window
appears to tell you that the PIN was changed successfully.
5. Change the PIN on every smartcard on which parts of the MBK are stored. You must do
this separately for each individual card.
4.11 Setting up Microsoft CryptoAPI and Cryptography API: Next

Generation (CNG)
The CSP/CNG cryptographic interface is accessed via the CXI firmware module and cannot be
configured by using CAT.
You must generate and import an MBK into the CryptoServer before you can use Microsoft
CSP/CNG.
For a detailed functional description and instructions about how to configure the CryptoServer
CSP/CNG Provider, read the manual CryptoServer CSP and CryptoServer CNG Key Storage
Provider 1.x. and 2.x. The document is provided on the SecurityServer/CryptoServer SDK
product CD in the \Documentation\Crypto_APIs\CSP-CNG directory.
4.12 Setting up JCE

In the CryptoServer, JCE functions are provided by the CXI firmware module. A Cryptographic
User has been created in this firmware module. See Chapter 4.12.1, “Setting up a User for
JCE”, for more details about this user or see Chapter 4.12.2, “Modifying the Device Address
and User Name in the File CryptoServer.cfg”, for more details about the corresponding
CryptoServer.cfg file.
This Cryptographic User is also the JCE user. You must set up the Cryptographic User in the
CryptoServer before you can use JCE. The CAT provides the appropriate authorization profile
for the Cryptographic User.
The CryptoServer.cfg configuration file has been provided for JCE. You must modify the
device address and the user name for the DefaultUser in this file.
Page 104 of 203

You must load the MBK into the CryptoServer before you can use JCE.
4.12.1 Setting up a User for JCE

1. Start CAT.
2. Click the Login/Logoff button in the toolbar and log in to the CryptoServer with at least
authentication status 20000000.
The User Management dialog box opens.
5. In this dialog box, click the Add User… button.
This opens the Add User dialog box.
6. In the Name of New User field, enter the name Cryptographic User.
Do not use the characters <, >, :, ", !, ?, *, /, \, | in user names.
7. In the User Profile drop-down combo box, select Cryptographic User.

8. In the Authentication Mechanism group, select the authentication mechanism you want to
use.
9. You can also enter attributes in the Custom String field of the Attributes group, if you want
to.
Each cryptographic key on the CryptoServer is assigned to a specific key group called
CXI_GROUP, and may only be accessed by users who are members of the same
CXI_GROUP. Therefore, the CXI_GROUP membership has to be set on user creation as an
attribute in the Custom String field.
Note the following:
▣ In the Custom String field, set an attribute in the following format:

10. CXI_GROUP=<Name of the group>
Page 105 of 203

If the cryptographic user should be granted access to keys in multiple key groups, set
CXI_GROUP=* as the user attribute.
Do not use the characters <, >, :, ", !, ?, *, /, \, | in the name of the CXI key group.
▣ If you do not set an attribute, the cryptographic user will not be able to access any key
on the CryptoServer.
11. Click the OK button to confirm your selection and, depending on which authentication
mechanism you selected, follow the instructions on the CAT or on the PIN pad.
The authentication status (00000002) for the user Cryptographic User has already been
defined when the CXI interface was programmed and cannot be changed retrospectively at a
later date.
4.12.2 Modifying the Device Address and User Name in the File CryptoServer.cfg
The CryptoServer.cfg configuration file has been provided for JCE.
You must modify this file to suit the particular CryptoServer hardware you are using
(CryptoServer PCIe card or CryptoServer LAN).
From CSLAN version 4.2.0 onwards, the Internet Protocols IPv4 and IPv6 are supported.
If you want to use the CryptoServer Simulator, enter 3001@127.0.0.1 as the device.
A DefaultUser with the name JCE has already been created in this configuration file. You must
also modify this name.
You will find this CryptoServer.cfg file in this directory by default:
C:\Program Files\Utimaco\CryptoServer\Software\JCE\
1. Open the CryptoServer.cfg file with an appropriate text editing program.

After installation, the CryptoServer.cfg file looks like this:
# Configuration File for JCE CryptoServer Provider
Page 106 of 203

#LogFile = C:/<user directory>/CryptoServerJCE.log

#LogLevel = 2
#LogSize = 10000
# exemplary device specifier

#Device = 192.168.4.183
Device = PCI:0
#Device = 3001@127.0.0.1
#Device = /dev/cs2
# exemplary cluster configuration:

#Device = PCI:0 \
# 192.168.4.183 \
# 192.168.4.185 \
# 192.168.4.186
ConnectionTimeout = 3000
Timeout = 30000
EndSessionOnShutdown = 1
KeepSessionAlive = 0
DefaultUser = JCE
#KeyGroup = MyGroup
#KeySpecifier = 42
#StoreKeysExternal = false
#KeyStorePath = C:/<user directory>/JCE.sdb
All lines starting with a number sign (#) are comments, i. e., these lines do not apply. In the
example above several devices have been set up (Device = ) but only the line without a
number sign at the beginning of the line (Device = PCI:0) applies after the installation. If
required, modify it to suit your situation.
Examples:
▣ If you are using a CryptoServer PCIe card in a Windows computer and the card is
located in the second slot, change PCI:0 to PCI:1.
▣ If you are using a CryptoServer PCIe card in a Linux computer and the card is located
in the first slot, remove the number sign in front of the #Device = /dev/cs2 entry,
and change this entry to /dev/cs2.0. If the card is in the second slot, change it to
/dev/cs2.1.
▣ If you are using a CryptoServer LAN, remove the number sign in front of the #Device =
192.168.4.183 entry, and enter the IP address of your CryptoServer LAN.
▣ If you want to use the CryptoServer Simulator, enter 3001@127.0.0.1.

All device entries you are not currently using must have the # in front.
Page 107 of 203

2. Modify the name of the DefaultUser from JCE to Cryptographic User that has been
created in step 6 in Chapter 4.12.1, “Setting up a User for JCE”.
You do not have to assign a password to the DefaultUser.
3. Save your changes and close the CryptoServer.cfg file.
4.13 Setting up CXI

You can administer all cryptographic interfaces via this (CXI) interface, which was specially
developed by Utimaco IS GmbH. You can control all other cryptographic interfaces and their
functions within the CryptoServer via the CXI interface. In this respect the CXI interface plays
a more prominent role than the other cryptographic interfaces.
You must load the Master Backup Key (MBK) into the CryptoServer before you can use CXI.
To be able to use CXI you have to create a CXI user, e. g.by using CAT.
1. Start CAT.
3. Close the Login/Logoff User dialog box by clicking Close.
4. On the toolbar, click the Manage User button.
5. In the User Management dialog box, click the Add User button.
The Add User dialog box opens.
In the Name of New User field, enter a unique name for the CXI user, e.g. CXIuser.
Page 108 of 203

6. Select the predefined Cryptographic User profile under User Profile.

7. Under Authentication Mechanism, select the authentication mechanism you require. If you
have decided to use Password (HMAC), you must assign a password.
The authentication status (00000002) for the user Cryptographic User was defined when the
CXI interface was programmed and cannot be changed retrospectively.
8. You can also enter attributes in the Custom String field of the Attributes group, if you want
to.
Note the following:
▣ In the Custom String field, set an attribute in the following format:

9. CXI_GROUP=<Name of the group>
▣ If you do not set an attribute, the CXI cryptographic user will not be able to access any
key on the CryptoServer.
10. Exit the Add User dialog box by clicking OK.
Page 109 of 203

4.14 Setting up Extensible Key Management (EKM)

The CryptoServer supports Extensible Key Management (EKM) for the following versions of
SQL Server:
■ Microsoft SQL Server, SP1, on a Windows Server 2008
■ Microsoft SQL Server 2008 R2 on a Windows Server 2008 R2
In the CryptoServer, EKM functions are provided by the CXI firmware module.
You must load the Master Backup Key (MBK) into the CryptoServer before you can use EKM.
4.14.1 Setting up an EKM User

A Cryptographic User has been created in this firmware module. This Cryptographic User is
also the EKM user. You must set up the Cryptographic User in the CryptoServer before you
can use EKM. The CAT provides the appropriate authorization profile for the Cryptographic
User.
1. Click the Login/Logoff button in the toolbar and log in to the CryptoServer at least with the
4. In the User Management dialog box, click the Add User button.
5. In the Name of New User field, enter a unique name for the Cryptographic User. In our
example, this is Paul.
6. Select the predefined Cryptographic User profile in the User Profile group.
7. In the Authentication Mechanism group, select Password (HMAC).
Page 110 of 203

8. In the Custom String field of the Attributes group, enter optionally the attribute you require.
Note the following:
▣ If you want EKM to have the ability to process clients, you must set the following in the
Attributes group: CXI_GROUP=<Name of the group>
We use PaulGroup for our example.
CXI_GROUP=PaulGroup
Do not use the characters <, >, :, ", !, ?, *, /, \, | in the name of the group (CXI_GROUP=).
▣ If you do not want EKM to have the ability to process clients, you do not need to enter
a value under Attributes.
9. Exit the Add User dialog box by clicking OK.
This opens the Set Password of new User dialog box.
10. Enter a unique password for the Cryptographic User (e.g. Paul), confirm it, and click OK to
close the Set Password of new User dialog box.
4.14.2 Modifying the Device Address in the File cssqlekm.cfg

The cssqlekm.cfg configuration file has been created for EKM.
You must modify this file to suit the particular CryptoServer hardware you are using
(CryptoServer PCI, CryptoServer PCIe or CryptoServer LAN).
You will find the cssqlekm.cfg configuration file on your SQL Server, in this directory:
C:\Program Files\Utimaco\CryptoServer\Software\EKM
Page 111 of 203

As of CSLAN version 4.2.0, the Internet Protocols IPv4 and IPv6 are supported.
If you want to use the CryptoServer Simulator, enter 3001@127.0.0.1 as the device specifier.
1. Use an appropriate text editor to open the configuration file cssqlekm.cfg.
The cssqlekm.cfg configuration file looks like this on your SQL Server:
# This is a sample configuration file
# path to logfile
LogFile = C:/Program Files/Utimaco/CryptoServer/Lib/cssqlekm.log
# loglevel
LogLevel = 3
# maximum logsize in bytes

LogSize = 1000000
# path to the EKM Keystore

KeyStore = C:/Program Files/Utimaco/CryptoServer/Lib/cssqlekm.sdb
# local CryptoServer device

Device = PCI:0
# remote CryptoServer
#Device = 192.168.1.2
# cluster of Cryptoserver
#Device = PCI:0 192.168.4.183 \
# 192.168.4.184 \
# 192.168.4.185 \
# 192.168.4.186 \
# 192.168.4.187
# timeout on connection attempt

ConnectionTimeout = 5000
# command timeout
Timeout = 60000
2. All lines starting with a number sign (#) are comments, i. e., these lines do not apply. In the
example above several devices have been set up (Device = ) but only the line without a
number sign at the beginning of the line (Device = PCI:0) applies after the installation.
Adjust the following part of the configuration file according to your situation:
# local CryptoServer device
Device = PCI:0
# remote CryptoServer
#Device = 192.168.1.2
Page 112 of 203

Examples:
▣ If you are using a CryptoServer PCIe card in a Windows computer and the card is
located in the second slot, change PCI:0 to PCI:1.
▣ If you are using a CryptoServer PCIe card in a Linux computer and the card is located
in the first slot, remove the number sign in front of the #Device = /dev/cs2 entry,
and change this entry to /dev/cs2.0. If the card is in the second slot, change it to
/dev/cs2.1.
▣ If you are using a CryptoServer LAN, remove the number sign in front of the #Device =
192.168.4.183 entry, and enter the IP address of your CryptoServer LAN.
▣ If you want to use the CryptoServer Simulator, enter 3001@127.0.0.1.

All device entries you are not currently using must have the # in front.
3. Save the cssqlekm.cfg file and close your text editor.
4.14.3 Creating a Credential on the SQL Server

To enable the SQL database to work with the CryptoServer, a credential must be created on
the SQL Server. To do so, you can for example use the Microsoft SQL Server Management
Studio.
An SQL Statement must have the following appearance:
CREATE CREDENTIAL <credential-name> WITH

IDENTITY=‘<CryptoServer=User>@<CXI_GROUP>‘,
SECRET=‘<CryptoServer=User-Password>‘
FOR CRYPTOGRAPHIC PROVIDER utimaco
This is the SQL Statement that you need to adjust.

Note that you need to enter the user name and the password of the user Cryptographic User
Also note that the value of the Attribute that you have entered when you were setting up a
user Cryptographic User must match the value entered in the Credential (Identity).
Consequently, in our example, the modified SQL Statement would look like this:
CREATE CREDENTIAL PaulCred WITH IDENTITY=‘Paul@PaulGroup‘,

SECRET=‘password‘
FOR CRYPTOGRAPHIC PROVIDER utimaco
Page 113 of 203

Maintaining the CryptoServer
5 Maintaining the CryptoServer

This chapter describes the general maintenance tasks you will need to perform for your
CryptoServer.
5.1 Resetting an Alarm

As already mentioned earlier in this manual, every alarm triggered on the CryptoServer must
be reset by an administrator. This ensures the alarm will not go unnoticed and also that it will
be investigated.
Before you reset an alarm you should find out why it was triggered in the first place. If the
alarm is a temporary alarm triggered, for example, because the mains power supply is too low,
or because the internal temperature is either too high or too low, you must resolve the cause
of the alarm before resetting it.
If you do not resolve the cause, the CryptoServer will return to Maintenance Mode after you
restart it. The CryptoServer will only go into Operational Mode after a restart if you have
removed the cause for the alarm.
1. Start CAT.
3. Log in to the CryptoServer as a user with at least authentication status 20000000 or
02000000.
5. Click the Manage menu and select Reset Alarm.
A new message window informs you whether the alarm has been reset successfully. The
CryptoServer then performs a restart. This logs off any user who is currently logged in to
the device. Therefore, every user must log in again to continue working with the
CryptoServer.
If you cannot reset the alarm, contact the manufacturer Utimaco IS GmbH.
To recreate the full functional availability of the CryptoServer (Operational Mode), you must set
up the CryptoServer again and reload the firmware modules of the SecurityServer package.
Page 114 of 203

5.2 Updating the Firmware of the CryptoServer

This chapter describes how to update the CryptoServer firmware package.
2. Log in to the CryptoServer with at least authentication status 02000000.
3. Click the Manage menu and select Firmware.
This opens the Setup CryptoServer dialog box.
The series of your CryptoServer is shown in the upper part of the Setup CryptoServer
dialog box in the Model text box. You must select the appropriate license file and firmware
package for the CryptoServer device you are using.
If you have a CryptoServer with a SecurityServer firmware version 3.10 and later, and a
firmware module ADM version 3.0.8.0 or later you do not need to import any license file
during a setup (firmware package import).
If your version of the SecurityServer firmware is earlier than version 3.10 and the version of
the firmware module ADM is earlier than version 3.0.8.0, you must import the appropriate
license file during a setup (firmware package import).
4. Select the appropriate license file for your CryptoServer in the License File text box.
After the installation of the product CD, you find the license files on your computer in the
following directory:
C:\Programm Files\Utimaco\CryptoServer\Administration
The names of the license files must match the names of the CryptoServer series. Therefore,
if you have purchased, for example, a CryptoServer CSe-Series, you must select the
appropriate license file for the CSe-Series here. See the table below.
CryptoServer series CryptoServer model Appropriate license file
CSe-Series CSe10 No license file required
CSe-Series CSe100 cse100.slf
Se-Series Se10 No license file required
Se-Series Se50 se50.slf
Page 115 of 203

CryptoServer series CryptoServer model Appropriate license file
Se-Series Gen2 Se12 No license file required
Se-Series Gen2 Se52 Se52.slf
Se-Series Gen2 Se500 Se500.slf
Se-Series Gen2 Se1500 se1500.slf
Table 19 CryptoServer models and the corresponding license files
Utimaco IS GmbH provides for each CryptoServer series the appropriate SecurityServer
package as shown in the following table:
CryptoServer series SecurityServer packages
CryptoServer CSe-Series SecurityServer-CSe-Series-x.xx.x.mpkg
CryptoServer Se-Series SecurityServer-Se-Series-x.xx.x.mpkg
CryptoServer Se-Series Gen2 SecurityServer-Se2-Series-x.xx.x.mpkg
Table 20: CryptoServer firmware packages
After the installation of the product CD, you find the SecurityServer packages on your
computer in the following directory:
C:\Programm Files\Utimaco\CryptoServer\Firmware
5. Select the required SecurityServer package file in the Firmware Package text box.
6. Click Update (installs only new firmware).
7. Click Setup.
8. Click Yes.
A separate window informs you whether the SecurityServer package has been installed
successfully.
After the SecurityServer package has been updated, the CryptoServer performs a restart
which automatically logs off all users.
Page 116 of 203

5.3 Performing a Clear

The Clear command deletes all sensitive data and firmware modules stored on the
CryptoServer. The following actions are triggered after you execute this command:
■ All firmware modules are deleted.
CryptoServer.
■ All users using a password to log in to the CryptoServer are deleted.
This automatically makes all other keys (including the Master Backup Key) and sensitive
data stored in the CryptoServer unusable, because they can no longer be decrypted
without the "old" individual device key.
However, all users who log in to the CryptoServer with an RSA Signature, an RSA smartcard or
an ECDSA signature are not deleted.
1. Start CAT.
authentication status 02000000, e. g., as the default ADMIN user.
4. Click the Manage menu and select Clear.
5. Confirm the confirmation prompt with Yes.
A separate window appears to tell you if the Clear command has been performed
successfully.
The CryptoServer then performs a restart and goes into Maintenance Mode.
This logs off any user who is currently logged in to the device. Therefore, every user must log
in again to continue working with the CryptoServer.
To re-create all features of the CryptoServer (Operational Mode) you must set up the
CryptoServer again and reload the firmware modules of the SecurityServer package according
to Chapter 5.5, “Setting up the CryptoServer after a Clear/Clear to Factory Settings”.
SecurityServer package are reloaded.
5.4 Performing a Clear to Factory Settings

When you execute the Clear to Factory Settings command, it resets the CryptoServer back to
delivery conditions.
Page 117 of 203


CryptoServer.
■ All users in the CryptoServer user database are deleted.
■ The default administrator ADMIN is set up again and can use the original authentication
key ADMIN.key to log in to the CryptoServer.
This automatically makes all other keys (including the Master Backup Key) and sensitive
data stored in the CryptoServer unusable, because they can no longer be decrypted
without the "old" individual device key.
Before you can execute a Clear to Factory Settings, you must first perform an External Erase
directly on the CryptoServer PCIe card or on the CryptoServer LAN according to Chapter 5.4.1,
“Performing an External Erase”.
The External Erase triggers an alarm in the CryptoServer which allows the Clear CryptoServer to
Factory Settings command to be executed for as long as this alarm is active.
5.4.1 Performing an External Erase

You can only perform an External Erase on the CryptoServer PCIe card during normal
operation when the host computer is running. This is the only way to ensure the
CryptoServer is supplied with enough power to perform the External Erase. In this
situation, note that the different CryptoServer series – CryptoServer CS, CSe, Se
and Se Gen2 - have different designs.
You find detailed information on how to perform an External Erase on the CryptoServer LAN
in the CryptoServer LAN – Administration Manual.
CryptoServer Se-Series
1. Start CAT.
2. Make sure that the CryptoServer PCIe card has been plugged in a computer and this
computer has been switched on. The next step is only effective if these conditions are
fulfilled.
3. Short-out the two contacts labeled External Erase in the white square in the next figure.
Page 118 of 203

Figure 11: Performing External Erase on a CryptoServer Se-Series PCIe card
4. Click the ShowState button in the CAT administration tool to check whether the
CryptoServer is now in Maintenance Mode.
Regardless of whether you have performed an External Erase or not, the following applies:
If you remove the CryptoServer PCIe card from the computer and remove any battery from
this PCIe card, the sensitive data on this PCIe card is deleted automatically in any case after
a maximum of 30 minutes.
CryptoServer CS-Series
1. Start CAT.
fulfilled.
3. To perform an External Erase on a CryptoServer CS-Series, short-out the two contacts
labeled GND and IN in one of the white squares of the next figure. Do not short out the
contacts in both white squares.
Page 119 of 203

Figure 12: Performing External Erase on a CryptoServer CS-Series PCIe card
CryptoServer CSe-Series
1. Start CAT.
fulfilled.
3. If you want to perform an External Erase, push the push-button under the aperture labeled
A by using an appropriate screwdriver. You find this aperture on the slot plate of a
CryptoServer CSe-Series (see next figure).
Page 120 of 203

Figure 13: Slot plate of a CryptoServer CSe-Series PCIe card
CryptoServer Se-Series Gen2

1. Start CAT.
2. If you want to perform an External Erase, push the push-button under the aperture labeled
B by using an appropriate screwdriver. You find this aperture on the slot plate of a
CryptoServer Se-Series Gen2 (see next figure).
Figure 14: Slot plate of a CryptoServer Se-Series Gen2 PCIe card
The LED flash light C flashes up red to confirm the activation of the Erase push-button B.
You can perform this action as well if the Cryptoserver PCIe card is not plugged in a
computer or the computer is switched off. However, then the next step is not possible.
Page 121 of 203

5.4.2 How to Perform a Clear to Factory Settings?

1. Start CAT.
2. Click the Manage menu and select Clear to Factory Settings that has been activated by
the External Erase.
3. Click YES.
A separate window informs you whether the Clear to Factory Settings command was
executed successfully.
The CryptoServer restarts and goes into Maintenance Mode.
5. Log in to the CryptoServer again.
6. Reset the alarm that has been activated by the previously performed External Erase as
described in chapter 5.1, „Resetting an Alarm“, in this manual.
7. Set up the CryptoServer again as described in the following chapter 5.5, „Setting up the
CryptoServer after a Clear/Clear to Factory Settings“, in this manual.
5.5 Setting up the CryptoServer after a Clear/Clear to Factory Settings

This section describes how to set up a CryptoServer again after a Clear or Clear to Factory
Settings command has been executed.
1. Import the relevant license file and the appropriate firmware package (SecurityServer-
<Series>-<version>.mpkg) into your CryptoServer as described in Chapter 5.5.1,
“Importing the SecurityServer Package into the CryptoServer”.
Page 122 of 203

2. Generate an MBK, import the MBK into the CryptoServer, split this into several parts, and
define how many parts of the MBK are required to allow the MBK to be used. Save the
private part of the MBK to the smartcards as described in Chapter 5.5.2, “Generating and
Importing an MBK”.
5.5.1 Importing the SecurityServer Package into the CryptoServer

2. Log in to the CryptoServer with at least authentication status 02000000 or as the default
administrator ADMIN.
3. Click the Manage menu and select Firmware.
This opens the Setup CryptoServer dialog box.
The series of your CryptoServer is shown in the upper part of the Setup CryptoServer
dialog box in the Model text box.
4. Select the appropriate license file for your CryptoServer in the License File text box.
If you have a CryptoServer with a SecurityServer firmware version 3.10 and later, and a
firmware module ADM version 3.0.8.0 or later, you do not need to import any license file.
Otherwise, you must import the appropriate license file into your CryptoServer.
5. After the installation of the product CD, you find the license files on your computer in the
following directory:
C:\Programm Files\Utimaco\CryptoServer\Administration
The names of the license files must match the names of the CryptoServer series. Therefore,
if you have purchased a CryptoServer CS-Series, you must select the appropriate license file
here. See Table 19 in chapter 5.2, “Updating the Firmware of the CryptoServer”, for a list of
the CryptoServer series and the corresponding license files.
Utimaco IS GmbH provides for each CryptoServer series the appropriate SecurityServer
package as shown in Table 20 in Chapter 5.2, “Updating the Firmware of the CryptoServer”.
After the installation of the product CD, you find, by default, the SecurityServer packages
on your computer in the following directory:
C:\Programm Files\Utimaco\CryptoServer\Firmware
6. Select the required SecurityServer package file in the Firmware Package text box.
7. Click the option New Installation (deletes all files; installs new firmware package).
Page 123 of 203

8. Click the Setup button.

9. Respond Yes to the following security prompt.
A separate window appears to tell you if the SecurityServer package has been installed
successfully.
After the SecurityServer package has been installed, the CryptoServer performs a restart
which automatically logs off all users.
5.5.2 Generating and Importing an MBK

Perform the following steps.
1. Before generating an MBK, check how many smartcards are available. This is important
because the MBK is stored on smartcards and you can split the MBK into a number of
parts. You will need the corresponding number of smartcards for this.
If you use SecurityServer/CryptoServer SDK 4.10, and you import a new MBK, the external
key and key backups become inaccessible. The error message “invalid mac of key blob”
(error code: 0xB0680026) is created.
after you have imported the original MBK.
If you use SecurityServer/CryptoServer SDK 4.20 and you import a new MBK, the external
key and key backups become inaccessible. The error message “key blob encrypted with
different MBK” (error code: 0xB0680080) is created.
2. To generate and import an MBK, you must be logged in to the CryptoServer with at least
authentication status 02000000 or as the default administrator ADMIN.
3. Click the Manage MBK button in the CAT toolbar.
The Remote Master Backup Key (MBK) Management dialog box opens.
4. Enter a name for the MBK in the MBK Name text box.
5. You then need to decide how many parts you want to "split" the key into.
▣ If you click m out of n, you can select into how many parts you want to split the MBK n
(Shares), and how many key parts/persons are required m (Shares) to be able to use
the MBK.
6. Select Automatic MBK Import to automatically import the MBK into the CryptoServer.
7. Click the Generate… button.
8. In the next dialog box, select whether you want to save the MBK as MBK Smartcard Token
or as MBK File Token.
Page 124 of 203

9. After you have made your selection, click OK to initiate the generation of an MBK.
10. If you want to save the new MBK as an MBK Smartcard Token, follow the instructions on
the PIN pad and on the CAT.
11. To save the new MBK as an MBK File Token, follow the instructions on the CAT.
12. Once you have saved the MBK either as MBK Smartcard Token, or as MBK File Token,
close the Remote Master Backup Key (MBK) Management dialog box by clicking the Close
button.
5.6 Managing Smartcards and Keys

CAT provides a wide range of key and smartcard management functions, which are described
in the sections below.
5.6.1 Generating a Key on a Smartcard
Any key you can generate on a smartcard is only designed to help administer or use the
CryptoServer. You cannot use that key for any other purpose.
Connect the delivered PIN pad to the computer whereon CAT is installed.
You need at least two additional smartcards for a single backup of the generated key. These
smartcards have to be at hand at the time of the key generation.
1. Click the Authentication Token menu and select Smartcard. The Smartcard Token
Management dialog box opens.
2. Specify whether you want to generate an RSA or an Elliptic Curve (DP: brainpoolP320t1)
(ECDSA) key.
3. Enter a name for the new key in the Key-Info field.
4. Specify the length for your RSA key in the RSA Key Length (bits) field. The default length is
2048 bit.
Page 125 of 203

The definition of a specific key length is not necessary for an ECDSA key. Therefore, the
RSA Key Length (bits) field is made unavailable in case you have previously selected
Elliptic Curve (DP: brainpoolP320t1).
5. In the Number of Backups text box, specify how many backups are to be generated from
this key. By default one backup of the key will be created on two smartcards. The backup
of the key is stored on the smartcard as RSA backup or respectively ECDSA backup.
6. Click the Generate button, and follow the instructions on the PIN pad. The new RSA or
ECDSA key will overwrite the default RSA key and ECDSA key stored on each of the ten
delivered smartcards.
7. Close the Smartcard Token Management dialog box by clicking the Close button.
5.6.2 Restoring a Key from a Backup on Smartcards

To restore an RSA key or an ECDSA key from a backup stored on smartcards, proceed as
follows:
1. Keep two smartcards whereon the backup of the key is stored at hand.
2. Keep a third smartcard whereon the key will be restored at hand.
3. Connect the delivered PIN pad to the computer whereon CAT is installed.
5. Depending on the key type you want to restore proceed as follows:
▣ If you want to restore an RSA key:
a) Click the Restore RSA tab.

b) Click the Restore RSA… button.
c) Insert the first RSA backup smartcard into the PIN pad and press the OK
button on the PIN pad.
d) Enter the PIN of the first RSA backup smartcard and press the OK button on
the PIN pad.
e) Insert the second RSA backup smartcard into the PIN pad and press the OK
f) Enter the PIN of the second RSA backup smartcard and press the OK button
on the PIN pad.
g) Insert the smartcard on which you want to restore the key into the PIN pad
and press the OK button on the PIN pad.
h) Enter the PIN of the smartcard and press the OK button on the PIN pad.
▣ If you want to restore an ECDSA key
a) Click the Restore EC tab.

b) Click the Restore EC… button.
Page 126 of 203

c) Insert the first EC backup smartcard into the PIN pad and press the OK button
on the PIN pad.
d) Enter the PIN of the first EC backup smartcard and press the OK button on the
PIN pad.
e) Insert the second EC backup smartcard into the PIN pad and press the OK
f) Enter the PIN of the second EC backup smartcard and press the OK button on
the PIN pad.
g) Insert the smartcard on which you want to restore the key into the PIN pad
and press the OK button on the PIN pad.
h) Enter the PIN of the smartcard and press the OK button on the PIN pad.
6. Close the dialog confirming the successful key creation by clicking OK.
7. Exit this Smartcard Token Management dialog box by clicking the Close button.
5.6.3 Copying a Key Backup from One Smartcard to another Smartcard

You can copy an RSA key backup or an ECDSA key backup stored on a smartcard to another
smartcard.
1. Keep the smartcard whereon the backup of the key is stored (source smartcard), and the
smartcard to which the key backup should be copied (destination smartcard) at hand.
2. Connect the delivered PIN pad to the computer whereon CAT is installed.
4. Click the Copy tab.
5. Click the Copy button.
6. Insert the smartcard from which you want to copy the key into the PIN pad, and press the
OK button on the PIN pad.
7. Enter the PIN of the smartcard, and press the OK button on the PIN pad.
8. Insert the smartcard to which you want to copy the key backup into the PIN pad, and
press the OK button on the PIN pad.
An existing key backup of the same key type on the smartcard will be overwritten. A
smartcard can store the following key types at the same time: RSA key, RSA key backup,
ECDSA key, ECDSA key backup and Master Backup Key
9. Enter the PIN of the smartcard, and press the OK button on the PIN pad.
A separate dialog box appears to confirm that the key backup has been copied
successfully.
Page 127 of 203

5.6.4 Changing the PIN for a Smartcard

To change the PIN for a smartcard, perform the following steps:
1. Click the Authentication Token menu and then select Smartcard. The Smartcard Token
2. Click the Change PIN tab and then the Change PIN button.
3. Insert the smartcard on which you want to change the PIN into the PIN pad and press the
OK button on the PIN pad.
4. Enter the old PIN for that smartcard and press the OK button on the PIN pad.
5. Enter the new PIN (of at least six and maximum 12 digits) for that smartcard and press
the OK button on the PIN pad.
6. Confirm the new PIN and press the OK button on the PIN pad.
A separate window appears to tell you that the smartcard's PIN has been changed
successfully.
5.6.5 Displaying the Contents of a Smartcard

To get detailed information about the keys currently stored on a smartcard, proceed as
follows:
2. Select the Info tab.
3. Click the Show Info button.
4. Insert the smartcard whose contents you want to view into the PIN pad and press the OK
5. Press the OK button on the PIN pad again.
The smartcard content is shown in a separate window.
5.6.6 Generating a Key as a Keyfile
Any key you can generate as a keyfile is only designed to help administer or use the
CryptoServer. You cannot use that key for any other purpose.
1. Click the Authentication Token menu and select Keyfile. The Keyfile Token Management
dialog box opens.
Page 128 of 203

2. In the Generate tab, specify the type of the key you want to generate. You can choose
between an RSA key and an ECDSA key using the Elliptic Curve (DP: brainpoolP320t1).
3. In the Keyfile text box, manually enter a file location and a name for the keyfile or click the
search button (…) next to the Keyfile text box to select the location to which the key should
be saved.
4. If you have chosen to generate an RSA key, we highly recommend you to keep the default
setting 2048 bits for the RSA Key Length.
By default the keyfile will be generated as an encrypted, password-protected keyfile (RSA or

ECDSA).
For security reasons, we recommend you to only generate encrypted, password-protected

RSA and ECDSA keyfiles.
5. Enter the password for the keyfile into the Password text box.
6. Confirm your password entry in the Confirm Password text box.
7. Finally, click the Generate button.
A separate window appears to confirm the successful key generation.
5.6.7 Changing the Password for a Keyfile

If you want to change the password used to protect an encrypted keyfile, proceed as follows:
1. Click the Authentication Token menu and then select Keyfile. The Keyfile Token
2. Select the Password tab.
3. Click the search button (…) next to the Keyfile text box to select the keyfile whose
password you want to change.
4. In the Old Password text box, enter the old password.
5. In the New Password text box, enter the new password.
6. Repeat the new password entry in the Confirm New Password text box.
7. Click the Change button.
A separate window appears to tell you that the smartcard's PIN was changed
successfully. Close it by clicking OK.
8. Click the Close button to close the Keyfile Token Management dialog box.
Page 129 of 203

5.6.8 Copying a Keyfile to a Smartcard (Backup)

If you want to copy a keyfile you have previously created to a smartcard, for example for
backup purposes, execute the following steps:
1. Click the Authentication Token menu and then select Keyfile. The Keyfile Token
Management dialog box opens. The Generate tab is displayed by default.
2. Click the Copy to Smartcard tab.
3. Click the search button (…) to select the keyfile you want to copy to the smartcard. Your
selection appears in the Keyfile text box.
4. If the keyfile is protected with a password, enter this password in the Password text box.
5. Click the Backup button.
6. Follow the instructions on the display of the PIN pad.
A separate window appears to tell you that keyfile was copied successfully to the
smartcard.
7. Click the Close button to close the Keyfile Token Management dialog box.
5.7 User Management

5.7.1 User Profiles
If you want to use the user management functions to create one or more new user, you
must log in to the CryptoServer as a user with at least permission 2 in the user group 7 (min.
required authentication status 20000000).
User profiles with predefined roles have been set up in the CAT to make it easier for you to
create new users. These user profiles have been assigned the appropriate permissions in their
individual user groups, according to their roles. The choice of authentication mechanism is
possible only on user creation and cannot be modified at a later point of time. Later on you
can only change the user's authentication token (password or keyfile), which has been created
according to the selected authentication mechanism.
You can select the following role-based user profiles:
Page 130 of 203

User profiles Description
ADMIN Manager Permissions: 22000000

one-person rule
Default authentication mechanism:
Smartcard (RSA Signature); can only be changed on user creation.
This profile corresponds to the default administrator ADMIN who is granted

permission 2 in the user groups 6 (System Administration) and 7 (User
Management), and can therefore authenticate all CryptoServer user and
system management commands on its own.
ADMIN Manager Permissions: 11000000

two-person rule
This profile embodies the two-person rule. It is granted permission 1 (limited)

in the user groups 6 (System Administration) and 7 (User Management), and
requires a second person to authenticate user and system management
commands to the CryptoServer.
User Management Permissions: 20000000

one-person rule
This profile is granted permission2 in user group 7 (User Management), and

can authenticate all user management commands to the CryptoServer on its
own.
User Management Permissions: 10000000

two-person rule
This profile embodies the two-person rule. It is granted permission 1 in the

user group 7 (User Management) and requires a second person to
authenticate commands to the CryptoServer.
System Manager Permissions: 02000000

one-person rule
This profile is granted permission 2 in the user group 6 (System

Administration), and can authenticate all system management commands to
the CryptoServer on its own.
Page 131 of 203

User profiles Description
System Manager Permissions: 01000000

two-person rule

user group 6 (System Administration), and requires a second person to
authenticate system management commands to the CryptoServer.
NTP Manager one- Permissions: 00200000

person rule
This profile is granted permission 2 in the user group 5 (NTP Administration),

and can authenticate all NTP administration commands to the CryptoServer
on its own.
NTP Manager two- Permissions: 00100000

person rule

user group 5 (NTP Administration), and requires a second person to
authenticate NTP administration commands to the CryptoServer.
Cryptographic User Permissions: 00000002

This profile is granted permission 2 in the user group 0, and can authenticate
all key management commands to the CryptoServer and use cryptographic
keys on its own.
Use this profile to administer the following cryptographic interfaces: CXI, JCE,
CSP/CNG, OpenSSL and EKM.
Customized User Permissions: To be defined individually

Password (HMAC); can only be changed on user creation.
This is a user for customer-specific applications, e.g., PKCS#11.
Table 21: User profiles available in CAT
Page 132 of 203

5.7.2 Creating a User
Prerequisites:
■ The PIN pad provided by Utimaco IS GmbH is connected to the host computer where CAT
is installed on.
■ If you are using a Windows host computer, you have set the PIN pad settings in CAT as
described in Chapter 4.4, "Setting up a PIN Pad under Windows".
■ If you are using a Linux host computer, you have set the PIN pad settings in CAT as
described in Chapter 4.5, "Setting up a PIN Pad under Linux".
■ If digital signature authentication mechanism (RSA or ECDSA signature) should be used
with a key stored on a smartcard, the appropriate smartcard and smartcard holder must
be available. A smartcard holder is a person knowing the PIN for accessing the smartcard.
To create a new CryptoServer user, proceed as follows:
1. Start CAT.
3. Log in to the CryptoServer as a user manager with at least authentication status
20000000 or as the default administrator ADMIN.
6. Click the Add User button.
7. Enter a unique name for the new user in the Name of New User text box.
8. Click ADMIN Manager one-person rule and select the role-based User Profile you require.
All available user profiles are listed and explained in Table 21 above. To create a user with
specific permissions, which do not match the permissions of any predefined user profile,
e.g., PKCS#11 Key Manager, select the Customized User profile.
9. Specify the authentication mechanism for the new user under Authentication Mechanism.
Page 133 of 203

10. If you have selected the Customized User profile above, define the user permissions in the
different user groups under Group/Role and Permission Level.
11. If you are creating a Cryptographic User or a Customized User, enter an Attribute for the
user.
Attribute.
When you enter an Attribute, note the following:
▣ Set an attribute in the following format:

CXI_GROUP=<Name of the group>
For PKCS#11 User (Key Manager) or Security Officer the correct format for the attribute is
CXI_GROUP=<slot number>, for example for PKCS#11 slot 1 CXI_GROUP=SLOT_0001.
▣ If you do not set an attribute, the cryptographic user/key manager will not be able to
access any key on the CryptoServer.
12. Click the OK button.
▣ If you have selected the Password (HMAC) authentication mechanism, the Set
Password of new User dialog box opens.
a) Enter a unique, secure password in the Password text box.
b) Confirm your password entry in the Confirm Password text box.
c) Close the Set Password of new User dialog box by clicking OK.
The dialog box Add User closes automatically.
Page 134 of 203

▣ If you have selected the authentication mechanism Smartcard (RSA Signature),

Smartcard (ECDSA Signature) or Smartcard (PIN Pad on CryptoServer), the Choose
User Token to Add a New User dialog box opens with preselected option Smartcard
Token.
a) Click the OK button and follow the instructions on the display of the PIN pad.
b) Insert the smartcard, where the key is stored on, and press OK on the PIN pad.
▣ If you have selected the authentication mechanism Keyfile (RSA Signature) or Keyfile
(ECDSA Signature), the Choose User Token to Add a New User dialog box opens with
preselected option Keyfile Token.
a) Click the OK button.
b) Click the search button (…) next to the Key Path field.
c) Select the keyfile path and click Open.
d) Click OK in the Choose User Token to Add a New User dialog box.
The new user is created and appears in the list of users in the User Management dialog box.
5.7.3 Deleting a User

To delete a CryptoServer user, proceed as follows:
1. Start CAT.
user ADMIN.
6. Select the user to be deleted from the user list.
7. Click the Delete User… button.
8. Confirm the deletion with Yes.
Page 135 of 203

To guarantee that the CryptoServer can be administered even after deleting the default user
ADMIN, an internal check of the permissions of the remaining users is performed every time
a user should be deleted. The default user ADMIN or any other CryptoServer user will only be
deleted if the sum of the permissions of the remaining users, using a signature-based
authentication mechanism, is at least 2 in the user group 7 and at least 1 in the user group 6.
Otherwise, the deletion of the user will fail by returning the appropriate error message.
The selected user has been removed from the user list.
5.7.4 Creating a User Data Backup
Before you can create a backup of the CryptoServer user database, you must first have
imported the Master Backup Key (MBK) into the CryptoServer according to Chapter 5.8.2,
“Importing an MBK.
To create a backup of the CryptoServer user database, proceed as follows:

1. Start CAT.
user ADMIN.
6. Click the Backup Users… button.
The Set Name and Path for User Backup File dialog box opens.
7. In the File name text box assign a unique name for the backup file.
8. Click Save. The user backup file is stored by default in the following directory:
C:\Program Files\Utimaco\CryptoServer\Administration
The type of the created backup file is by default UserBackup (*.ubu).
5.7.5 Restoring User Data
Page 136 of 203

You can only perform a restore of the CryptoServer user database, if the same MBK used for
creating the user data backup has been previously imported into the CryptoServer.
1. Start CAT.
3. Log in to the CryptoServer as a user with at least authentication status 20000000 or as
6. Click the Restore Users… button.
The Open User Backup File dialog box opens.
7. Select the appropriate user backup file (*.ubu).
8. Click the Open button.
A note in the information field of the CAT main window states that the user list has been
restored successfully.
5.7.6 Changing a User Authentication Token

Only the user themselves can change their password or authentication key. No one else, not
even the default administrator ADMIN we created, can change the password or the
authentication key for another user.
The authentication mechanism cannot be changed either. Once it has been decided that a
particular user shall log in using an HMAC password that cannot be changed retrospectively.
Only the password itself can be changed or swapped.
1. Click the Manage User button.
2. Select your user name in the list of users.
3. Click the Change Token/Password button.
The User Password of <user name> dialog box opens.
4. Enter your current password in the Password text box.
The User Password of <user name> dialog box closes. The Change User Password dialog
box opens.
Page 137 of 203

6. Enter here in the New Password text box your new password.
7. Repeat your new password entry in the Confirm New Password text box.
8. Confirm the entry by clicking OK.
The Change User Password dialog box closes.
In a separate window you now see that you have successfully changed your password.
10. Click Close to close the User Management dialog box.
5.8 Master Backup Key Management

If you want to perform MBK management functions remotely, you can use CAT. They can only
be performed locally if the CryptoServer PCIe card is in a CryptoServer LAN and you use the
front panel of the CryptoServer LAN.
In this context, remote means you connect the PIN pad to the host computer from which you
want to administer the CryptoServer.
You do not need to be logged in to the CryptoServer to perform the following actions:
■ Backup an MBK
■ Change the PIN of the smartcard the MBK is stored on
■ Retrieve information about an MBK
If you want to generate and import the MBK into the CryptoServer, you must log in to the
CryptoServer with at least permission 2 in the user group 6 (min. authentication status
02000000).
5.8.1 Generating an MBK

Before you start generating an MBK, answer the following questions by considering the
security policy of your company:
■ Do you want to store the MBK outside the CryptoServer into keyfiles or on smartcards?
■ How many people shall the MBK be distributed to?
■ What is the minimum number of parts (people) required to use the MBK?
Utimaco IS GmbH highly recommends to generate and distribute the MBK in an m-out-of-n
scheme, where <n> (n ≥ 2) defines the number of the key parts (shares) to be generated and
<m> (m ≥ 2) specifies how many key parts are required for the key to be reconstructed and
used.
Page 138 of 203

In case you have decided to use smartcards for the MBK generation, make sure that the PIN
pad is correctly connected to the computer where CAT is installed on and keep the required
number of smartcards at hand.
Follow these steps to generate an MBK:
1. Start CAT.
3. Log in to the CryptoServer with at least permission 2 in the user group 6 (min.
authentication status 02000000) or as the default administrator ADMIN.
6. Enter a name for the MBK under MBK Name.
7. Select how many parts you want to split the key into.
▣ If you select m out of n, you can select into how many parts you want to split the MBK
m (Shares), and how many key parts/persons are required n (Shares) to be able to use
the MBK.
8. If you want to import the MBK automatically into the CryptoServer, select Automatic MBK
Import.
9. Click the Generate… button.
The dialog box Master Backup Key (MBK): Share Storage 1/<n> opens.
10. Select whether you want to save the MBK as a Smartcard Token or as a Keyfile Token.
For security reasons we recommend you store the MBK on a smartcard and keep this in a
safe place.
▣ If you have chosen to store the MBK as a Smartcard Token, proceed as follows:
e) Click OK to trigger the generation of an MBK.
f) Insert a smartcard into the PIN pad and press OK on the PIN pad.
g) Enter the PIN for the smartcard and press OK on the PIN pad.
a) In a separate CAT window you now see that you have successfully generated and
stored the MBK share on the smartcard. Click OK to continue for the next MBK share.
b) Keep the Smartcard Token option selected and click OK.
Page 139 of 203

c) Repeat steps b) to e) for the remaining MBK share(s).

After you have successfully created all m MBK shares, this is confirmed to you in a
separate CAT window. Click OK to close this window.
▣ If you have chosen to store the MBK as a Keyfile Token, proceed as follows.
a) In the dialog box Master Backup Key (MBK): Share Storage 1/<n> click the search
button next to the Key Path text box.
The Set Name and Path for MBK key share 1/<n> dialog box opens.
b) Select the location and enter the File name you require for the keyfile.
c) Click Save.
d) Optionally, enter a password in the corresponding text box to additionally protect the
keyfile and click OK.
In a separate window you now see that you have successfully generated and stored
the MBK share as a keyfile. Click OK to continue for the next MBK share (2/<n>).
The dialog box Master Backup Key (MBK): Share Storage 2/<n> opens.
e) Repeat steps a) to d) for the remaining MBK share(s).
After you have successfully created all m MBK shares, this is confirmed to you in a
separate CAT window. Click OK to close this window.
11. Click Close to close the Remote Master Backup Key (MBK) Management dialog box.
5.8.2 Importing an MBK

If you have not automatically imported the MBK into the CryptoServer after you have
generated it, follow the instructions in this chapter.
If you use SecurityServer/CryptoServer SDK 4.10, and you import a new MBK, the external
key and key backups become inaccessible. The error message “invalid mac of key blob”
(error code: 0xB0680026) is created.
after you have imported the original MBK.
If you use SecurityServer/CryptoServer SDK 4.20 and you import a new MBK, the external
key and key backups become inaccessible. The error message “key blob encrypted with
different MBK” (error code: 0xB0680080) is created.
In case you have stored the MBK on smartcards, make sure that the PIN pad is correctly
connected to the computer where CAT is installed on and keep at least m (m ≥ 2, see Chapter
5.8.1, "Generating an MBK") MBK smartcards at hand before you start.
1. Start CAT.
Page 140 of 203


3. Log in to the CryptoServer with at least permission 2 in the user group 6 (min.
authentication status 02000000) or as the default user ADMIN.
5. Click in the toolbar on Manage MBK. The Remote Master Backup Key (MBK) Management
dialog box opens.
6. Click the Import tab.
7. Select the key type of the MBK you want to import: AES (32 bytes) or DES (16 bytes).
8. Select the number of key shares, m (shares), needed to reconstruct and use the MBK you
want to import.
9. Click the Import button.
The Master Backup Key (MBK): Share Import 1/<m> dialog box opens.
If the firmware package loaded into your CryptoServer contains the CXI firmware module,
you cannot use a DES key as the MBK. The CXI firmware module can only use an AES key as
an MBK.
10. In the Master Backup Key (MBK): Share Import 1/<m> dialog box, specify whether the
MBK is to be imported from a smartcard or from a keyfile.
▣ To import the MBK from a smartcard, proceed as follows:
a) Select the option Smartcard Token and click OK.
b) Insert the smartcard and press OK on the PIN pad.
c) Enter the PIN for the smartcard and press OK on the PIN pad.
d) In a separate CAT window, you now see that you have successfully imported the first
MBK share. Click OK to continue.
e) Keep the Smartcard Token option selected and click OK.
f) Repeat steps b) to d) for all remaining MBK shares.
g) In a next CAT window, you now see that you have successfully imported all required
MBK shares. Click OK to close this window.
▣ To import the MBK from a keyfile, proceed as follows:

a) Select the Keyfile Token option.
b) Click the search button next to the text filed Key Path and double-click of the
previously generated MBK shares to select it. By default the MBK shares are keyfiles
with the file extension *.mks.
Page 141 of 203

c) In case the MBK share keyfile is password protected, enter the appropriate password
into the Password text box.
d) Click OK.
e) In a separate CAT window, you now see that you have successfully imported the first
MBK share. Click OK to continue.
f) Repeat steps a) to e) for all remaining MBK shares
g) In a next CAT window, you now see that you have successfully imported all required
MBK shares. Click OK to close this window.
11. After you have imported the MBK, close the Remote Master Backup Key (MBK)
Management dialog box by clicking the Close button.
5.8.3 Creating an MBK Backup

This section explains how to create a backup copy of your MBK with CAT.
You do not have to log in to the CryptoServer to create a backup of an MBK.
Prerequisites:
■ The smartcard holders of all n smartcards, containing all shares of the MBK must be
present, keeping their MBK smartcards at hand. A smartcard holder is a person knowing
the PIN for accessing the smartcard.
■ The smartcard holders of all n smartcards required for creating backup copies of all
shares of the MBK must be present, keeping their MBK smartcards at hand.
■ The PIN pad must be connected to the computer where CAT is installed on.
Follow these steps to create a backup copy of your MBK.
1. Start CAT.
3. Click the Backup tab.
4. Under Source Token, select whether the MBK backup is to be prepared from Smartcards
or from a Keyfile. If you select the Keyfile option, you must enter/select the file location
where the MBK share is stored and the filename. In case the MBK keyfile is protected with
a password, you must enter the appropriate password into the Password text box.
5. Under Destination Token select whether the backup is to be created on Smartcards or as
a Keyfile. If you select the Keyfile option, you must enter/select the file location and the
Page 142 of 203

filename for the copy of the MBK share. Optionally, you can enter a password in the
Password text box if the MBK backup keyfile shall be additionally protected with a
password.
6. Then click the Backup… button to confirm your selection for both source and destination
tokens.
Create a backup from an MBK smartcard to another smartcard:
a) Insert the source smartcard containing the first share of the MBK into the PIN pad and
press OK on the PIN pad.
b) Enter the PIN for the MBK smartcard and press OK on the PIN pad.
c) Insert the first destination smartcard into the PIN pad and press OK on the PIN pad.
d) Enter the PIN for the destination smartcard and press OK on the PIN pad.
A separate window appears to confirm the successful creation of the MBK share copy.
If the smartcard containing the copy of the MBK share is protected with the default PIN,
change the PIN as described in the next section "Changing the PIN for an MBK Smartcard".
e) Repeat steps a) to d) for all source MBK smartcards containing MBK shares.
Create a backup from an MBK smartcard to a protected keyfile:
a) Insert the source smartcard containing the first share of the MBK into the PIN pad and
press OK on the PIN pad.
b) Enter the PIN for the MBK smartcard and press OK on the PIN pad.
A dialog box appears to warn you that if there are two different types of MBK – AES
and DES stored on the smartcard – one keyfile copy will be created for each. Confirm
the warning by clicking YES to continue.
c) Repeat steps a) and b) for all source MBK smartcards containing MBK shares.
Create a backup from a protected keyfile to an MBK smartcard:
a) Insert the destination smartcard into the PIN pad and press OK on the PIN pad.
b) Enter the PIN for the smartcard and press OK on the PIN pad.
c) Repeat steps a) and b) for all MBK shares.
Page 143 of 203

If the smartcard containing the copy of the MBK share is protected with the default PIN,
change the PIN as described in the next section "Changing the PIN for an MBK Smartcard".
5.8.4 Changing the PIN for an MBK Smartcard
You do not have to be logged in to the CryptoServer to change the PIN of the smartcard
where the MBK is stored.
To change the PIN of the smartcard where the MBK is stored proceed as follows:
1. Start CAT.
2. Click the Manage MBK button in the toolbar. The Remote Master Backup Key (MBK)
3. Select the MBK Change PIN tab.
4. Click the Change PIN button.
5. Insert the smartcard the PIN of which you want to change into the PIN pad and press OK
on the PIN pad.
6. Enter the old PIN for the smartcard and press OK on the PIN pad.
7. Enter the new PIN of at least six and maximum 12 digits for that smartcard and press OK
on the PIN pad.
8. Confirm the new PIN by entering it once again and press OK on the PIN pad.
A separate window appears to tell you that the smartcard's PIN has been successfully
changed.
5.8.5 Retrieving MBK Information
You do not have to log in to the CryptoServer to retrieve information about an MBK.
1. Start CAT.
Page 144 of 203


3. Click the Info tab.
4. Under MBKs stored in CryptoServer you see more information about the MBK that is
stored in the CryptoServer.
The Slot column shows the MBK slot number. Supported values: 0…255
(SecurityServer/CryptoServer SDK 4.20 or earlier: 0…3). The MBK slot number has not to
be mixed up with the PKCS#11 slot number.
5. To view information about an MBK that is stored on a smartcard, click the Card Info
button and follow the instructions on the PIN pad.
All important information about an MBK that is stored on a smartcard is displayed under
MBKs stored on Smartcard.
6. Close the Remote Master Backup Key (MBK) Management dialog box by clicking the
Close button.
5.9 Preparing Diagnostic Information

If a problem occurs whilst the CryptoServer is running, you can call a range of status
information that may help you sort out the problem.
To view the most important status information, perform the following steps:
1. Start CAT.
2. Click the Show menu and select Diagnostics.
The following diagnostic information appears in the separate window Save Diagnostics:
▣ The current date and time on the host computer when the diagnostics query was sent
to the CryptoServer.
▣ The CAT version
▣ The address of the CryptoServer or the IP address of the CryptoServer LAN
▣ The CryptoServer status
▣ The boot log
▣ Driver information (GetInfo)
▣ The battery state of the carrier battery and the external battery
▣ All files currently present in the CryptoServer
▣ All active firmware modules in the CryptoServer
▣ All users set up in the CryptoServer
▣ Date and time on the CryptoServer
Page 145 of 203

▣ The alarm log (only displayed if bootloader version ≤ 2.5 is loaded in the CryptoServer)
▣ Information about the Master Backup Key that is saved in the CryptoServer
3. To send the diagnostic information to the manufacturer Utimaco IS GmbH for problem
analysis, click Save and save the .txt file on your computer.
In the following chapters, the meaning of the items listed above are described in more detail.
5.9.1 Showing the CryptoServer Status

For example, if you click the Show Status button in the CAT toolbar, the system displays the
CryptoServer's status in the CAT main window:
mode = Operational Mode
state = INITIALIZED (0x00100004)
temp = 39.9 [C]
alarm = OFF
bl_ver = 3.00.2.1 (Model: Se-Series)
uid = db000017 189d4401 | D
adm1 = 53653130 20202020 43533434 32353938 | Se10 CS442598
adm2 = 53656375 72697479 53657276 65720000 | SecurityServer
adm3 = 494e5354 414c4c45 44000000 00000000 | INSTALLED
The following table shows the different status information fields and their meanings, and how
they are displayed.
Description Meaning and coding
Operating mode of the CryptoServer:
■ Operational
The regular set of firmware modules (*.msc) is started. All administration
and cryptographic functions are available.
■ Operational Mode – Administration-Only

The regular set of firmware modules (*.msc) is started. All administration
mode
functions are available. All cryptographic functions are blocked.
■ Maintenance
Backup set of firmware modules (*.sys) is started (e.g., in alarm state)
■ Bootloader
The Bootloader is running. The operating system and the regular set of
firmware modules have not been started yet.
Current operating state of the CryptoServer (should be INITIALIZED):

state ■ MANUFACTURED
This state is only relevant during production process.
Page 146 of 203


■ INITIALIZED
Firmware modules and all system keys (Production Key, Module
Signature Key, default Administrator Key (ADMIN.key file)) are loaded.
■ DEFECT
CryptoServer is defect. Contact the manufacturer, Utimaco IS GmbH.
Current temperature of the CryptoServer (in °C)
temp You find detailed information about the CryptoServer's behavior depending on
its internal temperature in the Chapter “Temperature-dependent Behavior of
the CryptoServer” in [CSADMIN].
Current alarm status.
It can be either ON or OFF. If ON, the following reasons are possible and shown
in case of an alarm state:
■ Power is too low (empty battery)
■ Power is too high
■ Temperature too high (> 66°C)
■ Temperature too low (< -13 °C)

alarm ■ Outer foil is broken3
■ Inner foil is broken3
■ External Erase is executed (manually by a short-circuit of the

corresponding pins on the PCIe card)
■ Invalid/Corrupted Master Key
■ Communication to sensor controller failed
In addition it is shown if the alarm reason is still present or if it has been

removed in the meantime (for example, an empty battery has been replaced).
bl_ver Current bootloader version and the model type of the CryptoServer
Version of the hardware for the CryptoServer CSe-Series and CryptoServer Se-
hw_ver Series Gen2.
Not available for CryptoServer CS- and Se-Series
uid UID is an 8-byte binary data field.
3
This alarm is only relevant for CryptoServer CS- and CSe-Series.
Page 147 of 203


The UID is a "Universal Identification" that uniquely identifies every
CryptoServer PCIe card. It is stored on a hardware component and loaded
onto the PCIe card during production.
The UID is displayed when the status information is extracted. It is not stored
adm1 is a readable character string, with a length of 16 characters.
The first 8 characters of adm1 contain a short form of the CryptoServer's

model type, filled with blank spaces
CSe10, Se10, Se12, CSe100, Se50, Se52,Se400, Se500, Se1000 or Se1500.
The second 8 characters represent the unique serial number of the

adm1 CryptoServer's PCIe card. This serial number is assigned by Utimaco IS GmbH
during manufacture and then loaded into the CryptoServer. The serial number
starts with the letters CS, followed by a 6-digit number.
The adm1 character string is displayed when you select the status
information. The 8-character serial number CSxxxxxx is also stored on the
CryptoServer PCIe card.
adm2 is a readable 16-character string.
The contents of the adm2 character string is also assigned by Utimaco IS

GmbH and loaded onto the CryptoServer during production. Whilst the
CryptoServer is being manufactured, the name of the firmware module
adm2 package loaded for the customer is also recorded here, according to which
CryptoServer model series is being produced.
The adm2 character string is displayed when you select the status
information. It is not stored on the CryptoServer.
This field may be empty.
adm3 is a readable 16-character string.
During production, a default value is recorded here, according to which

adm3 CryptoServer model is being manufactured. For an CryptoServer Se-Series,
CSe-Series and Se-Series Gen2, the INSTALLED value is recorded here.
For a CryptoServer CS-Series, the value Init-dev-1-prv is recorded here.
Error code indicating that a power-on self-test has failed. If these tests
error state
succeed, nothing is shown.
Table 22: CryptoServer status information
Page 148 of 203

The bit representation of the state field has the following meaning:
Bit(s) Value Description
CryptoServer state
0 .. 6 1 DEFECT
2 MANUFACTURED
4 INITIALIZED
5 OPERATIONAL
Alarm
7 0 OFF
1 ON
Sensor
8 0 The temperature is too low.
1 No temperature low alarm has been registered.
9 0 The temperature is too high.
1 No temperature high alarm has been registered.
104 0 The inner foil has been broken.
1 No inner foil alarm has been registered.
114 0 The outer foil has been broken.
1 No outer foil alarm has been registered.
12 - This bit is not used any more.

This bit was only used by CryptoServer 2000 and CryptoServer CS-Series with
boot loader version < 2.5.0.0, which is not in the scope of this document.
4
This is only possible for CryptoServer CS-Series or CryptoServer CSe-Series.
Page 149 of 203

13 0 The power is too high (power overdrive).
1 No power high alarm has been registered.
14 0 The power is too low.
1 No power low alarm has been registered.
15 0 The external erase has been executed.
1 No external erase alarm has been registered.
16 0 No alarm is present.
1 An alarm is still present.
17 0 No alarm has occurred.
1 An alarm has occurred.
FIPS140 mode
18 0 FIPS mode OFF
1 Some FIPS mode (restricted (CryptoServer Se-Series only) or validated, see bit
26 below)
Boot mode
19 .. 20 0 The boot loader is started (not possible here).
1 *.sys modules are started.
2 *.msc modules are started.
CC endorsed mode
21 0 OFF
1 ON
FIPS140 (2)
265 0 FIPS mode = ON
1 FIPS Mode = OFF but FIPS restrictions are applied (CryptoServer Se only)
5
This bit is only relevant if bit 18 has been set.
Page 150 of 203

Administration-only mode
27 0 Administration-Only Mode = OFF
1 Administration-Only Mode = ON
Table 23: The bit representation of the state field
5.9.2 Listing All Files

Open the CAT main window and click the Show Files button in the toolbar to display all files
resident in the CryptoServer's flash memory (RAM). You can display all loaded firmware
modules (*.msc), databases (*.db), logfiles (*.log) and license files (*.slf).
If you are using the signed configuration file cmds.scf, for example to harden your
CryptoServer interfaces or to increase the required permissions for the authentication of
specific CryptoServer functions/commands, it also will be listed here. More detailed
information about using the cmds.scf is provided in Chapters 2.15, "Configurable Role-based
Access Control (C-RBAC)", and 2.20, "Interface Hardening by Disabling Selected Functions".
5.9.3 Listing the Firmware

1. Start CAT.
2. Click the Show Firmware button in the toolbar to display all firmware modules that have
been loaded into the CryptoServer.
The next table shows an example.
ID number Module name Version number Initialization Status

(hexadecimal)
0 SMOS 5.3.3.0 INIT_OK
68 CXI 2.1.9.2 INIT_OK
81 VDES 1.0.9.1 INIT_OK
82 PP 1.2.5.0 INIT_OK
83 CMDS 3.4.0.0 INIT_OK
84 VRSA 1.3.0.6 INIT_OK
85 SC 1.2.0.2 INIT_OK
Page 151 of 203

ID number Module name Version number Initialization Status

(hexadecimal)
86 UTIL 3.0.3.0 INIT_OK
87 ADM 3.0.16.0 INIT_OK
88 DB 1.3.1.1 INIT_OK
89 HASH 1.0.9.0 INIT_OK
8b AES 1.3.5.1 INIT_OK
8d DSA 1.2.2.1 INIT_OK
8e LNA 1.2.3.0 INIT_OK
8f ECA 1.1.7.3 INIT_OK
91 ASN1 1.0.3.4 INIT_OK
96 MBK 2.2.4.4 INIT_OK
9c ECDSA 1.1.8.5 INIT_OK
Table 24: Example for how firmware information is displayed in CAT
The firmware module's initialization states have the following meanings:

■ INIT_OK
The firmware module has been installed successfully and is ready for use.
■ INIT_FAILED
An error occurred when the firmware module started.
■ INIT_INACTIVE
This message is output for the HCE firmware module if the CryptoServer does not have a
cryptographic accelerator chip. This is the situation for all CryptoServer models excluding
Se400, Se500 Se1000 and Se1500, see Chapter 2.5.5, "Cryptographic Accelerator Chip",
and Chapter 2.7.2, "Firmware Modules".
For CryptoServer Se400, Se500, Se1000 and Se1500 that have a cryptographic
accelerator chip, the INIT_OK status is output for the HCE firmware module.
■ INIT_INTERNAL
This status is usually only displayed during the temporary boot phase and means that the
firmware module is initialized internally.
■ INIT_DEP_OK
Page 152 of 203

This status is usually only displayed during the temporary boot phase and means that all
dependencies to other modules have been successfully removed.
■ INIT_SUSPENDED
This status is displayed if the previous operation (for example, Clear) requires a
CryptoServer restart.
If you encounter a problem with one of the firmware modules, which means its
initialization status is not INIT_OK, make a note of all entries shown in the above table.
Then contact Utimaco's customer support, and pass on these details to enable us to
identify this module.
5.9.4 Viewing the Boot Log

Follow these steps to view the CryptoServer boot log:
1. Click the Show menu and select Boot Log.
You see everything that has been started and initialized by the bootloader when the
CryptoServer was booted (e.g. after a reset).
▣ If you have a CryptoServer Se10, Se12, Se50 or Se52 model, the message No
Hardware Crypto Engine detected is displayed. This means your CryptoServer
does not have a cryptographic accelerator chip.
▣ The cryptographic accelerator chip is present in the CryptoServer Se400, Se500,

Se1000 or Se1500 models. In this case, you see the message Hardware Crypto
Engine detected.
▣ If you have a CryptoServer CSe10, Se10 or Se12 model, the line CMDS: 1000 TPS
appears in the boot log. In every other model, the line CMDS: no TPS limit appears
here.
▣ If your CryptoServer is a CryptoServer CSe100, Se50, Se52, Se400, Se500, Se1000 or

Se1500 model, and the line CMDS: 1000 TPS still appears, this may mean that no
license file has been loaded. In this case the boot log contains the line No license
file found. Alternatively, it means that a license file that does not match your
CryptoServer model was found. In this situation, check the Signed License File
found: xxx.slf message to see that the name xxx matches the name of the
CryptoServer series you are using.
2. Perform a setup and then import the appropriate license file and the corresponding
firmware package for your CryptoServer series according to Chapter 5.2, “Updating the
Firmware of the CryptoServer”.
3. After a reboot, check once again the corresponding messages in the boot log.
Page 153 of 203

5.9.5 Deleting Displayed Log Entries

All data you can display in the CAT main window by clicking the Show menu or by clicking the
Show Status, Show Firmware, or Show Files buttons in the toolbar is only displayed
temporarily.
If you want to delete any of the entries in the CAT main window follow these steps:
1. Click the File menu and select Clear Console Output.
2. In a separate window, confirm by clicking OK that you want to delete the entries currently
displayed in the main window.
5.9.6 Saving Displayed Log Entries

To save all information currently displayed in the CAT main window, follow these steps:
1. Click the File menu and select Save Console Output.
The CryptoServer Console Output dialog box opens.
2. In the File name text box, assign a unique name for the logfile.
3. Click the Save button.
The logfile is stored by default in the following directory:
The type of the created logfile is by default Console Output File (*.log).
In case of an issue, provide this output file to the customer support of Utimaco IS GmbH for
being analyzed.
5.9.7 Viewing CryptoServer's Battery State

The status of the carrier battery on a CryptoServer PCIe card is always displayed in the lower
right-hand corner of the CAT main window. If you see the status LOW here, this means that
the carrier battery is in a critical state and shall be replaced by a new one as soon as possible.
Otherwise, it may happen that the supply of power can no longer be guaranteed. This may
trigger an alarm which then deletes all sensitive data from the CryptoServer. You will find
instructions on how the replace the carrier battery in the Operating Manual delivered in a
printed form to you or on the product CD in the Documentation\Operating Manuals
directory.
To check the status of the External Battery of your CryptoServer LAN by using CAT, click the
Show menu and select Battery State. When the external battery reaches a critically low power
level, it must be replaced as described in the corresponding CryptoServer LAN Operating
Manual.
Page 154 of 203

5.9.8 Viewing Driver Information

If your CryptoServer suddenly stops reacting to any commands, you can display the driver
information. Have this information at hand if you then need to contact our support team.
This information includes, among other things, details about the CryptoServer driver, the slot
number etc., which can only be interpreted by the manufacturer Utimaco IS GmbH.
1. To display this driver information, click the Show menu and select Driver Info .
5.9.9 Retrieving and Saving the Audit Log

To view the audit log:
1. Start CAT.
2. Click the Show menu and select Audit Log.
This opens the CryptoServer Audit Log dialog box.
In the Logged Events group, you see a list of all events that are written in the audit log, e.
g.:
▣ Firmware Management
▣ User Management
▣ Date/Time Management
▣ Startup Messages
▣ Audit Log Management
▣ MBK Management
▣ Failed Login Attempts
▣ Backup/Restore
In the Audit Log Filters group, you can filter the displayed audit log either by User or by
Command/Return Value.
To save the audit log, follow these steps:
3. Click the Save Log… button.
The CryptoServer Audit Log File dialog box opens.
4. Assign a unique name for the audit log file in the File name text box.
5. Click the Save button.
The audit log file is stored by default in the following directory:
The type of the created audit log file is, by default, .log.
6. Close the CryptoServer Audit Log dialog box by clicking the Close button.
Page 155 of 203

5.9.10 Configuring the Audit Log Files

You can adjust the audit log configuration to your individual requirements. By doing so you
determine the information to be written into the audit log. Follow these steps:
1. Start CAT.
3. Log in to the CryptoServer as a user with at least authentication status 22000000.
5. Click the Manage menu and select Audit Log Settings.
This opens the Audit Log Configuration dialog box.
In this dialog box, you can setup the following settings:
▣ Number of audit log files

Specify the maximum number of audit log files. The number 3 (default setting) means
that three audit log files are recorded in the CryptoServer. You can store a minimum of
2 and a maximum of 10 audit log files.
▣ File size (max. 240)

Specify the maximum size of each audit log file in kilobytes. The default setting is 200
kilobytes for each audit log file. You must specify at least 4 Kilobyte.
▣ When all log files are full

This defines how the audit log files are to be handled when they are full.
■ If you select Rotate file, it means that the next audit log file is used when the
previous audit log file is full. Once all audit log files are full, the first audit log
file will be overwritten.
■ If you select Stop logging, this means that no audit log files are overwritten if
all audit log files are full.
If all audit log files are full, and you have selected Stop logging all CryptoServer commands
generating a logfile entry will be blocked.
In this case, you must delete all audit log files, in order to be able to administer the
CryptoServer again.
For that purpose, you have to log in to the CryptoServer with authentication status
20000000 or 02000000.
Page 156 of 203

▣ Events
Specify the events to be recorded in the audit log files.
The table below describes the meanings of the check boxes.
Event name Meaning
Firmware management Load, delete and replace firmware modules.
User management Create and delete users, and backup and restore the user
database.
Date/Time management Set of time and date
Audit log management All aspects of audit log file configuration
MBK management All aspects of MBK management (remote and local)
Key management Key management functions for cryptographic interfaces

(for example CXI)
Failed login attempts All unsuccessful attempts to log in to the CryptoServer
Successful login attempts All successful attempts to log in to the CryptoServer
Startup messages All relevant CryptoServer messages during the start

phase
Backup/Restore Backup and restore CryptoServer databases.

If the CryptoServer databases contain a large number of
entries, the volume of data may cause the individual audit
log files to overflow.
Table 25: Logging events
In the default settings for audit log files, only the Key Management and Successful login
attempts are not enabled.
6. Click the Apply button.
This saves your changes and the Audit Log Configuration dialog box remains open.
7. Click the OK button to finish processing.
This applies your changes and closes the Audit Log Configuration dialog box.
The equilavent action can be performed by using audit message class numbers and the
csadm tool. See [CSADMIN], e.g., Chapter “Auditing”, “SetAuditConfig” or “GetAuditConfig”, for
details.
Page 157 of 203

See Appendix A ,”Audit Log Entries”, contains a list of all audit log entries and describes by
which audit message classes they are activated.
5.9.11 Deleting an Audit Log in the CryptoServer
You cannot restore the CryptoServer audit log once it has been deleted. For this reason you
must save the audit log before you delete it.
To delete an audit log file in the CryptoServer:

1. Start CAT.
3. Log in to the CryptoServer as a user with at least authentication status 20000000 or
02000000, or as the default user ADMIN.
5. Click the Manage menu and select Audit Log .
This opens the CryptoServer Audit Log dialog box.
6. Click the Clear Log… button.
In a separate window the system prompts you to confirm the deletion of the audit log in
the CryptoServer by clicking Yes.
We recommend you to view, save and delete the audit log files regularly.
5.10 Backing up Databases

This section describes how to copy the databases from a CryptoServer and save them to a
backup directory.
Before you can do this, you must first import your individual Master Backup Key into the
CryptoServer. This Master Backup Key is then used to encrypt all data, and therefore also all
databases, before they are copied from the CryptoServer to a backup directory.
Page 158 of 203

1. Click the Backup/Restore button in the CAT toolbar.

This opens the CryptoServer Database Backup/Restore Wizard dialog box.
2. Click Copy databases from Source CryptoServer to Backup directory.
3. Enter the device address of the source CryptoServer in the Source CryptoServer text box.
The device address is the IP address for a CryptoServer LAN, e.g., PCI:0 for a
CryptoServer in a Windows computer, e.g., /dev/cs2.0 for a CryptoServer in a Linux
computer, and e.g., 3001@127.0.0.1 for a CryptoServer Simulator.
4. Enter in the Backup directory text box the directory where the data is to be stored.
5. In the lower part of the dialog box, under Source CryptoServer, select the databases you
want to copy.
▣ You can select all databases by clicking the Add All >> button.
▣ You can add databases individually by first selecting them and then clicking the Add >>
button.
Once you have made your selection, the databases appear in the Backup Directory list.
6. Click the Execute button.
The Login User for Source CryptoServer dialog box opens.
7. Log in to the CryptoServer as ADMIN (or another user with the same permissions) with the
The result of exporting the databases to a backup directory then appears in an Database
Export window.
8. Close the Database Export window by clicking the Close button.
5.11 Restoring Databases

This chapter describes how to copy databases from a backup directory into a CryptoServer.
The CryptoServer to which you want to copy the databases must have the same MBK that
was used to create the database backup in the first place.
2. Click Copy databases from Backup directory to Target CryptoServer.
3. Enter in the Target CryptoServer text box the device address of the CryptoServer where
the databases are to be restored to.
The device address is the IP address for a CryptoServer LAN, e.g., PCI:0 for a
CryptoServer in a Windows computer, e.g., /dev/cs2.0 for a CryptoServer in a Linux
computer, and e.g., 3001@127.0.0.1 for a CryptoServer Simulator.
4. Enter in the Backup directory text box the directory where the databases have been
previously stored to.
Page 159 of 203

5. In the lower part of the dialog box, under Source CryptoServer, select the databases you
want to copy.
▣ You can select all available databases by clicking the Add All >> button.
button.
Once you have made your selection, the databases appear in the Target CryptoServer list.
This opens the Login User for Target CryptoServer dialog box.
7. Log in to the target CryptoServer as a user who has at least authentication status
22000000 and then close the dialog box by clicking Close.
The result of importing the databases from a backup directory into a CryptoServer is
displayed in the Database Import window.
You must restart the CryptoServer (Manage > Reboot CryptoServer), so that the restore of
the databases gets applied.
5.12 Cloning Databases

This section describes how to copy databases from one CryptoServer to another
CryptoServer.
Before this can happen, you shall ensure that both CryptoServers are running the same
version of the SecurityServer package. To show the firmware versions of CryptoServer, click
Show Firmware in the toolbar of the CAT main window.
Additionally, the MBK of the source CryptoServer shall be imported into the target
CryptoServer, see Chapter 5.8.2, “Importing an MBK” for details. This MBK is used to encrypt
all database entries before they are copied from the source CryptoServer to the target
CryptoServer. In case you have stored the required MBK on smartcards, make sure that the
PIN pad is correctly connected to the computer where CAT is installed on. Furthermore, keep
at least m (m ≥ 2, see Chapter 5.8.1, "Generating an MBK") of the n smartcards, where the
required MBK is stored on, at hand before you start.
2. Select the option Copy databases from Source CryptoServer to Target CryptoServer.
3. Enter the device address of the source CryptoServer in the Source CryptoServer text box.
Page 160 of 203

For a CryptoServer LAN, the device address is the IP address. For a CryptoServer in a
Windows computer, it is e.g., PCI:0, for a Linux computer, it is e.g., /dev/cs2.0, and for a
CryptoServer Simulator, it is e.g., 3001@127.0.0.1.
4. Enter the IP address of the target CryptoServer in the Target CryptoServer text box.
5. In the lower part of the window, under Source CryptoServer, select the databases you
want to copy.
▣ You can select all available databases by clicking the Add All >> button.
button.
Once you have made your selection, the databases appear in the Target CryptoServer list.
CAT first compares the firmware modules of both CryptoServers (source and target) that
are involved in this process. The results of this comparison are displayed in an information
window.
▣ If the results show that both CryptoServers have the same firmware modules (OK!),
click the OK button to close this information window.
▣ If the results show that the firmware modules or the firmware module status in the s
are not identical, you can either click No to cancel the operation, or continue by clicking
Yes.
Comparing the firmware modules and the firmware module status do not actually affect
how the databases are copied.
The Login User for Source CryptoServer dialog box opens.
7. Log in to the source CryptoServer as a user with at least authentication status 22000000.
8. Click the Close button to close the Login User for Source CryptoServer dialog box.
This opens the Login User for Target CryptoServer dialog box.
9. Log in to the target CryptoServer as a user with at least authentication status 22000000.
10. Click the Close button to close the Login User for Target CryptoServer dialog box.
This opens the CryptoServer Date/Time for Target CryptoServer dialog box. This dialog
box is where you specify the date and time for the target CryptoServer. However, setting
the date and time for the target CryptoServer is optional and has no effect on how the
databases are transferred.
11. Select Apply host time to transfer the date and time from the host system.
12. When you have finished entering your data, click the Apply button.
This saves your changes and the CryptoServer Date/Time for Target CryptoServer dialog
box remains open.
Page 161 of 203

13. Click the OK button to finish processing.

This applies your changes and closes the CryptoServer Date/Time for Target CryptoServer
dialog box.
The Master Backup Key for Target CryptoServer dialog box opens. The MBK will encrypt all
database entries before they leave the source CryptoServer. Both CryptoServers involved
in this process must have the same Master Backup Key so the databases can be
decrypted correctly in the target CryptoServer.
14. In the Master Backup Key for Target CryptoServer dialog box, click the Import tab.
15. Select under MBK Type, the type of key you want to import: an AES (32 byte) or a DES (16
byte) MBK. If the CXI firmware module is part of the loaded firmware, only MBKs of type
AES are accepted.
16. Under m (shares) specify the number of parts into which you have split the MBK.
17. Click the Import button.
18. In the Master Backup Key (MBK): Share Import dialog box, specify whether the MBK is to
be imported from a Smartcard Token or from a Keyfle Token.
20. Follow the instructions on the PIN pad and the CAT to import all parts of the Master
Backup Key into the target CryptoServer .
21. After all parts of the Master Backup Key have been imported successfully into the target
CryptoServer , click Close to exit the Master Backup Key (MBK): Share Import dialog box.
You have now copied the databases from one CryptoServer to another CryptoServer. The
results are now displayed in a separate information window.
Page 162 of 203

Contact Address for Support Queries
6 Contact Address for Support Queries

If an error occurs while operating the CryptoServer, read [CSTrSh] to solve it.
If the error still occurs, prepare diagnostic information in a .txt file on your computer as
described in [CSTrSh] or in Chapter 5.9, “Preparing Diagnostic Information”, in this manual.
If you have any further questions on CryptoServer, feel free to contact us.
You can reach us from Monday to Friday 09.00 a.m. to 05.00 p.m., apart from German public
holidays and other customs days.
Utimaco IS GmbH
Germanusstr. 4
52080 Aachen
Germany
■ RMA query
If you need to send the CryptoServer back to the Utimaco IS GmbH, i.e., open a new RMA
case, we request that you use the following web address. RMA cases cannot be opened by
e-mail, phone or fax.
https://support.hsm.utimaco.com/support/rma/new
■ For other support queries, use the following contact data:
▣ By mail (preferred contact method)

support-cs@utimaco.com
Attach the diagnostic information to your e-mail.
▣ By web portal
https://support.hsm.utimaco.com/support/cases/new
The diagnostic information will be requested in our response if necessary.
▣ By phone
+49 (0) 241 1696-155
▣ By fax
+49 (0) 241 1696-199
Page 163 of 203

Appendix A Audit Log Entries
A.1 Overview
The following table provides an overview of the used audit message classes. These classes
are shown as Events if you click Manage > Audit Log Settings. The following subchapters
describe the audit log entries for these classes.
Audit message class name Audit Audit Description / Default
message message Event name6
class mask class
number
0x00000001 1 Firmware Yes

OS_AUDIT_CLASS_FIRMWARE
management
0x00000002 2 User Yes

OS_AUDIT_CLASS_USER
management
0x00000004 3 Date/Time Yes

OS_AUDIT_CLASS_TIME
Management
0x00000008 4 Startup Yes

OS_AUDIT_CLASS_STARTUP
messages
0x00000010 5 Audit log Yes

OS_AUDIT_CLASS_AUDIT
management
0x00000020 6 MBK Yes

OS_AUDIT_CLASS_MBK
management
0x00000040 7 Key No
OS_AUDIT_CLASS_KEY
management
0x00000080 8 Successful login No

OS_AUDIT_CLASS_AUTH_SUCCESS
attempts
0x00000100 9 Failed login Yes

OS_AUDIT_CLASS_AUTH_FAILED
attempts
OS_AUDIT_CLASS_BACKUP_RESTORE 0x00000200 10 Backup/Restore Yes
0x00000400 11 Operating Yes

OS_AUDIT_CLASS_SYSTEM
system events7
6
As shown in the CryptoServer Administration Tool (CAT) at Manage > Audit log settings > Events.
7
This audit message class is neither shown nor can it be assigned at Manage > Audit log settings > Events in the
CryptoServer Administration Tool (CAT), see Figure 15.
Page 164 of 203

Audit message class name Audit Audit Description / Default

message message Event name6
class mask class
number
<Class reserved for future use> - 12-23, 31 -7 -
OS_AUDIT_CLASS_CUSTOM_MASK - 24-30 -7 -
OS_AUDIT_CLASS_ALWAYS8 0xFFFFFFFF - -7 -
<Special audit message class> - - -7 -
Table 26: Audit message classes
The first column shows the name of the audit message class.
The second and the third columns show the audit message class mask and number as used
in the csadm … GetAuditConfig command and in the csadm … SetAuditConfig command.
Examples:
csadm dev=192.168.4.1 getauditconfig
Audit log configuration parameters:
Number of logfiles: 3
Rotate logfiles: yes
Max filesize: 200000
Events: 0x00000010 (Bits 5)
csadm Dev=192.168.4.1 LogonPass=paul,swordfish

SetAuditConfig=MaxFileCount=5,Events=1:2:3:4:5:6:8:9
csadm Dev=192.168.4.1 LogonSign=paula,:cs2:cyb:USB0

SetAuditConfig=RotateLogfiles=yes,Events=0x000001BF
In the examples, 0x00000010 and 0x000001BF are the masks, and 5 and 1:2:3:4:5:6:8:9
are the corresponding numbers.
The fourth column shows the corresponding representation at Manage > Audit log settings >
Events in the CryptoServer administration tool (CAT).
8
If an audit message class name is set to OS_AUDIT_CLASS_ALWAYS, the audit log entry is written in any case,
independently from the audit log configuration. The audit log configuration is shown at Manage > Audit log settings
> Events in the CryptoServer Administration Tool (CAT), see Figure 15.
Page 165 of 203

Figure 15: Audit message classes (event names) in CAT
The fifth column shows whether the audit message class is enabled by default.
The following table shows the function codes for the firmware modules.
Function code Firmware module
0x000 SMOS
0x068 CXI
0x069 MBK, extended interface
0x083 CMDS
0x087 ADM
0x088 DB
0x096 MBK, normal interface
Page 166 of 203

Function code Firmware module
0x09A NTP
Table 27: Function codes and firmware modules
Each firmware module specification contains more detailed information about its audit log
entries.
The following table shows which function codes including the subfunction code and
subfunction name belong to a dedicated audit message class. If a function code cannot be
assigned to an audit message class, it is not shown in this table.
Audit message class name Function code, subfunction code and subfunction
information
FC:0x083 SFC:0x13 SetAdminMode14
FC:0x083 SFC:0x14 SetStartupMode
OS_AUDIT_CLASS_FIRMWARE FC:0x087 SFC:0x03 LoadFile
FC:0x087 SFC:0x04 DeleteFile
FC:0x087 SFC:0x13 LoadFirmwareDecryptionKey
FC:0x068 SFC:0x21 AddUser9
FC:0x068 SFC:0x22 DeleteUser10
FC:0x083 SFC:0x05 DeleteUser11
OS_AUDIT_CLASS_USER FC:0x083 SFC:0x06 ChangeUser
FC:0x083 SFC:0x0D RestoreUser12
FC:0x083 SFC:0x0E AddUserExtended13
FC:0x083 SFC:0x11 SetMaxAuthFailures14
OS_AUDIT_CLASS_TIME FC:0x087 SFC:0x07 SetTime
9
This is the CXI AddUser subfunction, not the CMDS AddUserExtended subfunction.
10
This is the CXI DeleteUser subfunction.
11
This is the CMDS DeleteUser subfunction.
12
This audit log entry is created if either OS_AUDIT_CLASS_BACKUP_RESTORE or OS_AUDIT__CLASS_USER is
enabled.
13
This is the CMDS AddUserExtended subfunction, not the CXI AddUser subfunction.
14
Neither the function code nor the subfunction code is shown in the audit log entry.
Page 167 of 203

information
FC:0x09A SFC:0x02 ChangeActivationState
FC:0x09A SFC:0x04 SetNTPSettings
FC:0x… SFC:0x… Checking configured authentication

OS_AUDIT_CLASS_STARTUP requirements in the audit log
FC: 0x000 SCF: … SMOS successfully started
OS_AUDIT_CLASS_AUDIT FC:0x087 SFC:0x0B ClearAuditLog
FC:0x069 SFC:0x00 Import DES key from PIN pad 15
FC:0x069 SFC:0x01 Import DES key from smartcard15
FC:0x069 SFC:0x02 Import AES key from smartcard15
FC:0x069 SFC:0x03 Generate DES key and write to

smartcard15
FC:0x069 SFC:0x04 Generate AES key and write to

smartcard15
OS_AUDIT_CLASS_MBK FC:0x069 SFC:0x08 Import MBK key from PIN pad and
store on smartcard15
FC:0x069 SFC:0x09 Generate DES key shares and store on

smartcard15
FC:0x069 SFC:0x0A Generate AES key shares on store on

smartcard15
FC:0x096 SFC:0x04 GenerateMBK
FC:0x096 SFC:0x05 ImportMBK
FC:0x068 SFC:0x05 InitKeyGroup
FC:0x068 SFC:0x08 BackupKey
OS_AUDIT_CLASS_KEY FC:0x068 SFC:0x09 RestoreKey
FC:0x068 SFC:0x0B GenerateKey
FC:0x068 SFC:0x0C OpenKey
15
Attention! This is the extended MBK interface with the function code 0x069, not the normal MBK interface with
the function code 0x096. Neither the function code, nor the subfunction code is shown in the audit log entry.
Page 168 of 203

information
FC:0x068 SFC:0x0D DeleteKey
FC:0x068 SFC:0x0F SetKeyProp
FC:0x068 SFC:0x10 ExportKey
FC:0x068 SFC:0x11 ImportKey
FC:0x068 SFC:0x19 CreateObject
FC:0x068 SFC:0x1A GenerateKeyPair
FC:0x068 SFC:0x1B CopyObject
FC:0x068 SFC:0x1C DeriveKey
FC:0x068 SFC:0x1D WrapKey
FC:0x068 SFC:0x1E UnwrapKey
OS_AUDIT_CLASS_AUTH_SUCCESS -
OS_AUDIT_CLASS_AUTH_FAILED -
FC:0x083 SFC:0x0C BackupUser
FC:0x083 SFC:0x0D RestoreUser16

OS_AUDIT_CLASS_BACKUP_RESTORE
FC:0x087 SFC:0x18 ExportDBEntry
FC:0x087 SFC:0x19 ImportDBEntry
FC: 0x000 SCF: … CryptoServer shutdown
FC: 0x000 SCF: … SHA-512 known answer test failed
FC: 0x000 SCF: …Unpacking firmware module failed
FC: 0x000 SCF: … Loading firmware module failed

OS_AUDIT_CLASS_SYSTEM
FC: 0x000 SCF: … Start function of firmware module failed
FC: 0x000 SCF: … Firmware module is defective
FC: 0x000 SCF: … DRBG: Known answer test failed
FC: 0x000 SCF: … DRBG: Initialization failed
16
This audit log entry is created if either OS_AUDIT_CLASS_BACKUP_RESTORE or OS_AUDIT__CLASS_USER is
enabled.
Page 169 of 203

information
FC: 0x000 SCF: … DRBG: Random number generation failed
FC: 0x000 SCF: … DRBG: Reseed failed
FC: 0x000 SCF: … TRNG: Hardware failed
FC: 0x000 SCF: … TRNG: Self-test failed
FC: 0x000 SCF: … TRNG: Online test failed
FC: 0x088 SFC: Corrupted database
<Class reserved for future use> -
OS_AUDIT_CLASS_CUSTOM_MASK -
FC: 0x000 SCF: … FIPS mode entered or left
FC: 0x000 SCF: …Clear to factory settings
FC: 0x000 SCF: …Erase executed
OS_AUDIT_CLASS_ALWAYS FC: 0x000 SCF: … New alarm detected
FC: 0x000 SCF: …Temperature exceeds valid range
FC:0x087 SFC:0x15 Clear
FC:0x087 SFC:0x1A ConfigParamSet
<Special audit message class> FC:0x087 SFC:0x14 ResetAlarm
Table 28: Function codes and subfunction codes of audit messages
The tables in the following chapters contain information by which tool resp. which action an
audit log entry has been generated:
■ csadm
■ CryptoServer Administration Tool (CAT)
■ PKCS#11 CryptoServer Administration Tool (p11CAT)
■ p11tool2
■ cxitool
■ cngtool
■ csptool
Page 170 of 203

The general format of an audit message is <DateTime> <User> <Function code> <Subfunction
code> <Log data>.
A.2 OS_AUDIT_CLASS_FIRMWARE
The OS_AUDIT_CLASS_FIRMWARE audit message class is mainly used when firmware
modules are loaded, deleted etc. The following tables describe the corresponding audit log
entries and the actions leading to them.
Audit log entry Description
Setting the administration mode
SetAdminMode from <old> to Neither the function code (0x83) nor the subfunction code
<new> [error code] (0x13) is shown in the audit log entry.
Initiation: csadm (SetAdminMode)
Setting the startup mode
SetStartupMode <new> Neither the function code (0x83) nor the subfunction code
[error code] (0x14) is shown in the audit log entry.
Initiation: csadm (SetStartupMode)
Loading the <filename> file.
The part of the file is optional.

FC:0x087 SFC:0x03 Load
File ‘<filename>’ Part 1 Initiation: csadm (LoadFile or LoadPKG) or CAT (Manage >
[error code] Firmware > Update (installs only new firmware) or Manage >
Firmware > New installation (deletes all files; installs new
firmware package))
FC:0x087 SFC:0x03 The <filename> file (.mtc file) is a firmware module and
Verification of MMC the verification of its MMC signature has failed with the error
signature failed <error code>.
(<filename>) err = <error
code> Initiation: csadm (LoadFile)
Deleting the <filename> file.

FC:0x087 SFC:0x04 Delete
File ‘<filename>’ [error Initiation: csadm (DeleteFile or LoadPKG with option
code] ForceClear) or CAT (Manage > Firmware > New
installation (deletes all files; installs new firmware package)
Loading the firmware description key.

FC:0x087 SFC:0x13 Load FW
DecKey #R0 [error code] Initiation: csadm (LoadFWDecKey) or CAT (Manage >
Firmware Decryption Key)
Page 171 of 203

Table 29: Audit log entries for OS_AUDIT_CLASS_FIRMWARE
A.3 OS_AUDIT_CLASS_USER
The OS_AUDIT_CLASS_FIRMWARE audit message class is used when users are created,
changed, restored and deleted. The following tables describe the corresponding audit log
FC:0x068 SFC:0x21
user_add: <key group>
<user name> (<Optional Adding a user (in CXI).
user name>, Initiation: P11CAT (e.g., Slot Management > Init Token > SO
<authentication mechanism
PIN, Confirm SO PIN > Init Token > Login)
ID> <user’s permission>)
[error code]
FC:0x068 SFC:0x22 Deleting a user (in CXI).

user_delete: <key group> Initiation: P11CAT (Login/Logout > Login Generic > Login >
<user name> [error code]
Slot Management > Delete SO > Delete SO > Yes)
FC:0x083 SFC:0x05 Delete Deleting a user (in CMDS).

User ‘<user name>’ [error Initiation: csadm (DeleteUser) or CAT (Manage > User >
code]
Delete User)
FC:0x083 SFC:0x06 Change Changing a user.

User ‘<user name>’ [error Initiation: csadm (ChangeUser) or CAT (Manage > User >
code]
Change Token/Password)
Restoring a user.
FC:0x083 SFC:0x0D Restore
User ‘<user name> Initiation: csadm (RestoreUser) or CAT (Manage >
(<Optional user name>, Manage User > Restore Users).
This audit log entry is created if either
[error code] OS_AUDIT_CLASS_BACKUP_RESTORE or
OS_AUDIT_CLASS_USER is enabled.
FC:0x083 SFC:0x0E Add User

‘<user name>’ (<Optional Adding a user (in CMDS).
user name>,
<authentication mechanism Initiation: csadm (AddUser) or CAT (Manage > User > Add
ID> <user’s permission>) User)
[error code]
Page 172 of 203

Setting the maximum number or authentication failures

Set MaxAuthFailures from
Neither the function code (FC: 0x083) nor the subfunction
<old> to <new> [error
code (SFC: 0x11) is shown in the audit log entry.
code]
Initiation: csadm (SetMaxAuthFails)
Table 30: Audit log entries for OS_AUDIT_CLASS_USER
A.4 OS_AUDIT_CLASS_TIME
The OS_AUDIT_CLASS_TIME audit message class is used when the time is set, the limitations
for time changes changed and the activation state for these changes is changed. The
following tables describe the corresponding audit log entries and the actions leading to them.
FC:0x087 SFC:0x07 Set Time Setting the time.

from <date/time stamp> [error Initiation: csadm (SetTime) or CAT (Manage >
code]
Date/Time)
FC:0x09A SFC:0x02 NTP: New

Settings Changing the activation state.
MaxAdjustPerOperation=<value1> Initiation: CAT (Manage > NTP Settings > Enabled /
MaxAdjustPerDay=<value2>
Disabled)
[error code]
FC:0x9A7 SFC:0x04 NTP: New Setting the NTP settings.

Settings
MaxAdjustPerOperation=<value1> Initiation: CAT (Manage > NTP Settings > Max. time to
MaxAdjustPerDay=<value2> set per day and Manage > NTP Settings > Max. time to
[error code] set per operation)
Table 31: Audit log entries for OS_AUDIT_CLASS_TIME
A.5 OS_AUDIT_CLASS_STARTUP
The OS_AUDIT_CLASS_STARTUP audit message class is used when the configured
authentication requirements in the audit log are checked the power-on self-test has failed, the
Page 173 of 203

cryptographic algorithm test has failed, SMOS is started etc. The following tables describe the
corresponding audit log entries and the actions leading to them.
Checking the configure authentication requirements in the

audit log
FC:<function code> SFC: Initiation: csadm (Edit the cmds.scf file, perform csadm …
<subfunction code> SignConfig, csadm … LoadFile=…\cmds.scf, csadm
Configured … ListFiles, csadm … Restart, csadm …
Permission=<value>
GetBootLog and csadm … GetAuditLog. See Chapter
“Creating and Using the Signed Configuration File cmds.scf”
in [CSADMIN] for details.)
Failed power-on self-test initialization.
Initiation: The POST (power-on self-test) firmware module is

CMDS: unable to initialize
module POST for Power-on not available and one of the following actions is performed:
Self-tests (err = <error Windows command-line (shutdown –r –t 0), csadm
code>) (Restart or Reset (It is strongly recommended not to use
the csadm … Reset command.) or CSLReboot) or CAT
(Manage > Reboot CryptoServer)
POST: Selftest of utility

functions failed with Failed power-on self-test
error code: <error code>
POST: <Algorithm name>

Cryptographic Test failed Failed cryptographic algorithm test, i.e., for AES, ECDA,
with error code: <error HASH, HMAC RSA, DSA or DES
code>
Skipped cryptographic algorithm test, i.e., for AES, ECDA,

HASH, HMAC RSA, DSA or DES
Initiation: The corresponding firmware module (AES, ECDSA

POST: <Algorithm name> etc.) is not available and one of the following actions is
Cryptographic Test skipped performed: Windows command-line (shutdown –r –t 0),
csadm (Restart or Reset (It is strongly recommended not
to use the csadm … Reset command.) or CSLReboot) or
CAT (Manage > Reboot CryptoServer)
SMOS has been started successfully.

SMOS Ver. <version> Initiation: csadm (Restart or Reset (It is strongly
successfully started recommended not to use the csadm … Reset command.)
or CSLReboot) or CAT (Manage > Reboot CryptoServer)
Table 32: Audit log entries for OS_AUDIT_CLASS_STARTUP
Page 174 of 203

A.6 OS_AUDIT_CLASS_AUDIT
The OS_AUDIT_CLASS_AUDIT audit message class is used when the audit log configuration is
cleared or changed. The following tables describe the corresponding audit log entries and the
actions leading to them.
Clearing an audit log file
FC:0x087 SFC:0x0B Clear <number> indicates the number of the (youngest) parts that
Audit Files ‘<filename>’ are not deleted (omitted in error case).
(<number>) [<error code>]
Initiation: csadm (ClearAuditLog) or CAT (Manage > Audit
Log > Clear Log > Yes)
Table 33: Audit log entries for OS_AUDIT_CLASS_AUDIT
A.7 OS_AUDIT_CLASS_MBK
The OS_AUDIT_CLASS_MBK audit message class is used when an MBK (master backup key)
is generated, imported and stored. The following tables describe the corresponding audit log
mbk_ei_import_pp: DES-16, Importing a DES key from the PIN pad.

slot <slot number> [error Neither the function code (FC:0x069) nor the subfunction
code]
code (SFC:0x00) is shown in this audit log entry.
mbk_ei_import_des_sc: DES- Importing a DES key from the smartcard.

16, ‘<key name>’, slot Neither the function code (FC:0x069) nor the subfunction
<slot number> [error code]
mbk_ei_import_aes_sc: AES- Importing an AES key from the smartcard.

32, ‘<key name>’, slot Neither the function code (FC:0x069) nor the subfunction
<slot number> [error code]
Page 175 of 203

mbk_ei_generate_des_sc: Generating a DES key and writing to the smartcard.

DES-16, ‘<key name>’,
record <record number> Neither the function code (FC:0x069) nor the subfunction
[error code] code (SFC:0x03) is shown in this audit log entry.
mbk_ei_generate_aes_sc: Generating an AES key and writing to the smartcard.

AES-32, ‘<key name>’,
[error code] code (SFC:0x04) is shown in this audit log entry.
Importing an MBK key from the PIN pad and storing them on
mbk_ei_imp_pp_write_sc:
<key info>, ‘<key name>’, the smartcard.
[error code]
Generating DES key shares and storing them on the

mbk_ei_gen_des_key_shares:
DES-16 ‘<key name>’, <k>- smartcard.
out-of-<n>, record <record Neither the function code (FC:0x069) nor the subfunction
number> [error code]
code (SFC:0x09) is shown in this audit log entry
Generating AES key shares and storing them on the

mbk_ei_gen_aes_key_shares:
AES-32 ‘<key name>’, <k>- smartcard.
out-of-<n>, record <record Neither the function code (FC:0x069) nor the subfunction
number> [error code]
code (SFC:0x0A) is shown in this audit log entry.
mbk_key_generate: <key Generating an MBK.

info> ‘<key name>’ <k>- Initiation: csadm (MBKGenerateKey) and CAT (Manage >
out-of-<n> [error code]
Master Backup Key > Generate)
mbk_key_import: <key info> Importing an MBK.

‘<key name>’, <x> parts,
slot <slot number> [error Initiation: csadm (MBKImportKey) and CAT (Manage >
code] Master Backup Key > Import)
Table 34: Audit log entries for OS_AUDIT_CLASS_MBK
A.8 OS_AUDIT_CLASS_KEY
The OS_AUDIT_CLASS_KEY audit message class is used when keys are generated, backed up,
restored, opened, deleted, exported, imported, derived, wrapped and unwrapped and additional
processes are performed. The following tables describe the corresponding audit log entries
and the actions leading to them.
Page 176 of 203

Initiating a key group.

FC:0x068 SFC:0x05
key_init: <key group> Initiation: By the P11CAT or p11tool2 program when
[error code] reinitializing a PKCS#11 slot, thereby deleting all key
material.
FC:0x068 SFC:0x08 Backing up a key.

key_backup: <key info>,
<key group>: <key name>: Initiation: Call by the appropriate method of the keyCAT,
<key specifier> [error P11CAT, p11tool2 or cxitool program although backing up a
code] key is not a PKCS#11 function.
FC:0x068 SFC:0x09 Restoring a key.

key_restore: <key info>,
<key specifier> [error P11CAT, p11tool2 or cxitool program although restoring a
code] key is not a PKCS#11 function.
FC:0x068 SFC:0x0B
key_generate: <key info>, Generating a key.
<key group>: <key name>: Initiation: Call by the appropriate method of the csadm, CAT,
<key specifier> [error
P11CAT, p11tool2, cxitool or cngtool program.
code]
FC:0x068 SFC:0x0C Opening a key.

key_open: <key group>:
<key name>: <key Initiation: Call by the appropriate method of the csadm, CAT
specifier> [error code] or P11CAT program.
FC:0x068 SFC:0x0D
key_delete: <key info>, Deleting a key.
<key group>: <key name>: Initiation: Call by the appropriate method of the P11CAT,
p11tool2, cxitool, cngtool or csptool program.
code]
Setting key properties.

FC:0x068 SFC:0x0F
key_prop_set: <key group>: Initiation: Call by the appropriate method of the keyCAT or
<key name>: <key P11CAT program by changing key properties e.g., the label of
specifier> [error code]
a key.
FC:0x068 SFC:0x10
key_export: <key info>, Exporting a key.
cngtool or csptool program.
code]
FC:0x068 SFC:0x11
key_import: <key info>, Importing a key.
<key group>: <key name>:
Page 177 of 203


<key specifier> [error Initiation: Call by the appropriate method of the keyCAT,
code]
cngtool or csptool program.
FC:0x068 SFC:0x19
obj_create: <key info>, Creating an object.
<key group>: <key name>: Initiation: Call by the appropriate method of the P11CAT or
p11tool2 program.
code]
FC:0x068 SFC:0x1A
key_pair_gen: <key info>,
<key group>: <public key Generating a key pair.
name>: <public key Initiation: Call by the appropriate method of the P11CAT or
specifier> / <private key
p11tool2.
name>: <private key
FC:0x068 SFC:0x1B
cxi_ext_obj_copy: <key
info>, <key group>:
<source key name>: <source Copying an object.
key specifier> > Initiation: Call by the appropriate method of the P11CAT or
<destination key group>:
p11tool2 program.
<destination key name>:
<destination key
FC:0x068 SFC:0x1C
key_derive: <key info>, Deriving a key.
<key group>: < key name>: Initiation: Call by the appropriate method of the P11CAT or
< key specifier> [error
p11tool2 program.
code]
FC:0x068 SFC:0x1D Wrapping a key.

key_wrap: <key info>, <key
group>: < key name>: < key Initiation: Call by the appropriate method of the P11CAT or
specifier> [error code] p11tool2 program.
FC:0x068 SFC:0x1E
key_unwrap: <key info>, Unwrapping a key.
<key group>: < key name>: Initiation: Call by the appropriate method of the P11CAT or
< key specifier> [error
p11tool2 program.
code]
Table 35: Audit log entries for OS_AUDIT_CLASS_KEY
Page 178 of 203

A.9 OS_AUDIT_CLASS_AUTH_SUCCESS
The OS_AUDIT_CLASS_AUTH_SUCCESS audit message class is used when the authentication
of a user succeeded. The following tables describe the corresponding audit log entries and the
Successful authentication.
authentication Initiation: csadm (LogonPass or LogonSign), CAT
(<authentication mechanism (Manage > Login/Logoff > Login), P11CAT (e.g.,Login/Logout
ID>) succeeded [error > Login Generic > User name > Login), p11tool2
code]
(LoginUser), cxitool (LogonPass or LogonSign), cngtool
(automatic login) and csptool (automatic login).
Table 36: Audit log entries for OS_AUDIT_CLASS_AUTH_SUCCESS
A.10 OS_AUDIT_CLASS_AUTH_FAILED
The OS_AUDIT_CLASS_AUTH_FAILED audit message class is used when an authentication
attempt fails. The following tables describe the corresponding audit log entries and the
‘<user>’ authentication Failed authentication without maximum value for failed

(<authentication mechanism authentication attempts set.
ID>) failed, failure
counter: <number> [error Initiation: Call by the appropriate method of the csadm, CAT,
code] P11CAT, p11tool2, cxitool, cngtool or csptool program.
Failed authentication with maximum value for failed

‘<user>’ authentication
(<authentication mechanism authentication attempts set.
ID>) failed,<number> Initiation: Call by the appropriate method of the csadm, CAT,
attempts left [error code]
P11CAT, p11tool2, cxitool, cngtool or csptool program.
Failed authentication due to a wrong user name.

‘unknown’ Authentication
failed [error code] Initiation: Call by the appropriate method of the csadm,
P11CAT, p11tool2, cxitool, cngtool or csptool program
Page 179 of 203

‘<user>’ account locked, Too many failed authentication attempts.

authentication refused Initiation: Call by the appropriate method of the csadm, CAT,
[error code]
P11CAT, p11tool2, cxitool, cngtool or csptool program.
Table 37: Audit log entries for OS_AUDIT_CLASS_AUTH_FAILED
A.11 OS_AUDIT_CLASS_BACKUP_RESTORE
The OS_AUDIT_CLASS_BACKUP_RESTORE audit message class is used when a user is
backed up or restored and a database entry is exported or imported. The following tables
describe the corresponding audit log entries and the actions leading to them.
FC:0x083 SFC:0x0C Backup Backing up a user.

User ‘<user name> [error Initiation: csadm (BackupUser) or CAT (Manage > Manage
code]
User > Backup Users)
Restoring a user.
FC:0x083 SFC:0x0D Restore
User ‘<user name> Initiation: csadm (RestoreUser) or CAT (Manage > Manage
(<Optional user name>, User > Restore Users).
This audit log entry is created if either
[error code] OS_AUDIT_CLASS_BACKUP_RESTORE or
OS_AUDIT_CLASS_USER is enabled.
Exporting a database entry.

FC:0x087 SFC:0x18 Backup
DB Entry (Database / Initiation: csadm (BackupDatabase) or CAT (Manage >
Searchkey): ‘<DB name>’ / Backup/Restore > Copy databases from Source
‘<user name>’ [error code] CryptoServer to Backup directory > Select database > Add >
Execute)
Importing a database entry.

FC:0x087 SFC:0x19 Restore
DB Entry (Database / Initiation: csadm (RestoreDatabase) or CAT (Manage >
Searchkey): ‘<DB name>’ / Backup/Restore > Copy databases from Backup directory to
‘<user name>’ [error code]
Source CryptoServer > Select database > Add > Execute)
Table 38: Audit log entries for OS_AUDIT_CLASS_BACKUP_RESTORE
Page 180 of 203

A.12 OS_AUDIT_CLASS_SYSTEM
The OS_AUDIT_CLASS_SYSTEM audit message class is used when the power-on self-test
succeeded, the CryptoServer is shut down and some operations failed. The following tables
describe the corresponding audit log entries and the actions leading to them.
FC: 0x088 SFC: Database

‘<database name>’
Corrupted database
corrupted (integrity
failure detected)
Successful power-on self-test

CMDS: Power-on Self-tests Initiation: Windows command (shutdown –r –t 0),
performed sucessfully csadm (Reset (not recommended), Restart or
CSLReboot) or CAT (Manage > Reboot CryptoServer)
CryptoServer shutdown.
This applies for V4.5.2.0 ≤ SMOS version V5.0.0.0 or SMOS

[] FC:0x000 SFC: version ≥ V5.5.4.0.
CryptoServer shut down
Initiation: csadm (Reset (not recommended), ResetToBL,
Restart, CSLShutdown or CSLReboot) or CAT (Manage >
Reboot CryptoServer)
The known answer test of the deterministic random bit

generator (DRBG) has failed. This test verifies whether a
[] FC:0x000 SFC: DRBG: device produces the expected output as a reaction to a given
known answer test failed input.
[<error code>]
version ≥ V5.5.4.0.
Failed DRBG initialization.

[] FC:0x000 SFC: DRBG:
initialization of The profile name is either ‘Real’ or ‘Pseudo’.
’<profile name>’ failed
[<error code>]
[] FC:0x000 SFC: DRBG: Failed deterministic random number generation.

generation failed [<error This applies for V4.5.2.0 ≤ SMOS version V5.0.0.0 or SMOS
code>]
[] FC:0x000 SFC: DRBG:

reseed failed [<error Failed reseed of the deterministic random bit generator.
code>]
Page 181 of 203


The firmware module has been detected as defective due to

[] FC:0x000 SFC: Module a failed integrity check.
<function code> (<module
The function code is identical to the module ID.
name>) is corrupt [<error
code>] This applies for V4.5.2.0 ≤ SMOS version V5.0.0.0 or SMOS
[] FC:0x000 SFC: TRNG: TRNG (true random number generator) hardware failure.
hardware failure [<error This applies for V4.5.2.0 ≤ SMOS version V5.0.0.0 or SMOS
code>]
[] FC:0x000 SFC: TRNG: Failed TRNG self-test.

selftest failed [<error This applies for V4.5.2.0 ≤ SMOS version V5.0.0.0 or SMOS
code>]
Poor statistical quality of a random number.

[] FC:0x000 SFC: TRNG:
online test failed This applies for V4.5.2.0 ≤ SMOS version V5.0.0.0 or SMOS
This applies for V3.3.7.0 ≤ SMOS version V4.0.0.0 or

FC:0x000 SFC: SHA-512
V4.5.4.0 ≤ SMOS version V5.0.0.0 or SMOS version ≥
Known Answer Test failed
V5.5.6.0.
Unpacking a firmware module file, e.g., adm.msc, has failed.

[] FC:0x000 SFC: Unpack of
module ‘<module name>’ This applies for V3.3.7.0 ≤ SMOS version V4.0.0.0 or
failed [error code] V4.5.4.0 ≤ SMOS version V5.0.0.0 or SMOS version ≥
V5.5.6.0.
Loading a firmware module file, e.g., adm.msc, has failed.

[] FC:0x000 SFC: Loading
of module ‘<module name>’ This applies for V3.3.7.0 ≤ SMOS version V4.0.0.0 or
failed [error code] V4.5.4.0 ≤ SMOS version V5.0.0.0 or SMOS version ≥
V5.5.6.0.
Start function of a firmware module file, e.g., adm.msc, has

[] FC:0x000 SFC: Start failed.
function of module
‘<module name>’ failed This applies for V3.3.7.0 ≤ SMOS version V4.0.0.0 or
[error code] V4.5.4.0 ≤ SMOS version V5.0.0.0 or SMOS version ≥
V5.5.6.0.
Table 39:Audit log entries for OS_AUDIT_CLASS_SYSTEM
Page 182 of 203

A.13 Class reserved for future use

This audit message class is used for future extensions.
A.14 OS_AUDIT_CLASS_CUSTOM_MASK
The OS_AUDIT_CLASS_CUSTOM_MASK audit message class is only used for extension
implemented by the customer.
A.15 OS_AUDIT_CLASS_ALWAYS
If an audit message class name is set to OS_AUDIT_CLASS_ALWAYS, the audit log entry is
written in any case, independently from the audit log configuration shown at Manage > Audit
log settings > Events in the CryptoServer Administration Tool (CAT), see Figure 15.
The OS_AUDIT_CLASS_ALWAYS audit message class is used when the CryptoServer is
cleared, a certification mode (CC, FIPS) has to handled, a new alarm is detected, the
temperature exceeds its valid range etc. The following tables describe the corresponding audit
log entries and the actions leading to them.
FC:0x087 SFC:0x15 Clear Clearing the CryptoServer.

[error code] Initiation: csadm (Clear) or CAT (Manage > Clear)
FC:0x087 SFC:0x1A change

audit config param id: Changing audit log parameter.
<ID> (<ID specifier>) Initiation: csadm (SetAuditConfig) or CAT (Manage >
from: <old> to: <new>
Audit Log > Change configuration > OK)
[error code]
CC endorsed mode
=<on/off>, CC error state CC endorsed mode
= <ON/OFF> [error code]
FIPS restrictions applied

mode = <ON/OFF>, FIPS
FIPS restrictions applied mode
error state = <ON/OFF>
[error code]
FIPS mode = <ON/OFF>, FIPS FIPS mode.

error state = <ON/OFF> Initiation: Call by the appropriate method of the csadm or
[error code]
CAT program.
Page 183 of 203

[] FC:0x000 SFC: The CryptoServer has entered the FIPS mode.

CryptoServer has entered Initiation: Call by the appropriate method of the csadm or
FIPS mode
CAT program.
[] FC:0x000 SFC: The CryptoServer has left the FIPS mode.

CryptoServer has left FIPS Initiation: Call by the appropriate method of the csadm or
mode
CAT program.
CryptoServer ERASE to factory settings.
Initiation: Call by the appropriate method of the csadm

(including Clear=DEFAULT) or CAT program (including
[] FC:0x000 SFC: Manage > Clear to Factory Settings).
CryptoServer ERASE to Consider that all sensitive data is removed during this
factory setting
process.
If you use the CryptoServer Simulator, use the ALARM.curr

file for performing the External Erase. See Chapter 2.22.4,
“Sensor Detection”, for details.
New alarm.
Initiation:
■ Read Chapter 2.6, “An Alarm and Its Consequences”,

first. Then read Chapter 2.22.4, “Sensor Detection”, for
[] FC:0x000 SFC: New ALARM retrieving a list of possible alarms. This chapter also
detected: <value> describes how to create an alarm if you use a
(<description>) CryptoServer Simulator. In this case, you must perform a
csadm … Restart command or CAT > Manage >
Reboot CryptoServer before the alarm is active.
■ Consider that all sensitive data is removed during this

process.
[] FC:0x000 SFC:
Temperature exceeds valid The temperature exceeds 62 °C or falls below -5°C. See
range (<value>°C): Chapter 2.5.11, “Temperature Monitoring”, for details.
Shutdown !
ERASE executed.
Initiation: Read Chapter 2.6, “An Alarm and Its

[] FC:0x000 SFC:
Consequences”, first. Perform the instructions in Chapter
CryptoServer ERASE
5.4.1, ,”Performing an External Erase”.
executed
Consider that all sensitive data is removed during this
process.
Page 184 of 203

Table 40: Audit log entries for OS_AUDIT_CLASS_ALWAYS
A.16 Special Audit Message Class

A special audit message class is used for an audit log entry due to an alarm that is reset. This
class ensures that an audit log entry is always created, independently from the configuration
of the audit log. Only if a reset alarm cannot be logged due to a full and non-rotating audit log,
as an exception resetting this alarm is executed without logging.
Resetting an alarm.
FC:0x087 SFC:0x14 Reset
Alarm [error code] Initiation: csadm (ResetAlarm) or CAT (Manage > Reset
alarm)
Table 41: Audit log entry for the special audit message class
Page 185 of 203

Appendix B Supported Algorithms

The following subchapters list the supported algorithms sorted by API.
B.1 CXI API

The CXI API supports the following algorithms.
Algorithm Key length [bit] Mode Chaining mode Padding
DES 56, 112, 168 Encrypt, Decrypt ECB, CBC None, PKCS#5,
ISO7816, Random
MAC CBC, CBC-Retail None, Zero, PKCS#5,

ISO7816, Random
Wrap, Unwrap ECB, CBC None, PKCS#5,

ISO7816, Random
AES 128, 192, 256 Encrypt, Decrypt ECB, CBC, GCM, None, PKCS#5,
OFB, CTR, CCM, ISO7816, Random
KWP
MAC CBC None, Zero, PKCS#5,

ISO7816, Random
CMAC None, Zero, PKCS#5,

ISO7816, Random
GMAC None
Wrap, Unwrap ECB, CBC, OFB, None, PKCS#5,

KWP ISO7816, Random
RSA 512 .. 16384 Encrypt, Decrypt - None, PKCS#1-v1_5,

PKCS#1-OAEP
(delta = 1 bit)
Sign, Verify - PKCS#1-v1_5, X9.31,
PKCS#1-PSS
Wrap, Unwrap - None, PKCS#1-v1_5,

PKCS#1-OAEP
ECDSA, Brainpool: 160 … 512 Encrypt, Decrypt - -

ECDH (ECIES)
NIST: 163 .. 571
Secp: 112 .. 571 Sign, Verify - -

(according to
FRP256v1
ANSI X9.62;
Page 186 of 203

Algorithm Key length [bit] Mode Chaining mode Padding

format: Raw or
ASN.1)
EdDSA curve25519 Sign, Verify - -
DSA, DH, P: >= 512 Sign, Verify - -

DH_PKCS17
Q: >= 160
RAW 80 ... 8192 Hash - -

(Generic Computation
(delta = 8 bit)
Secret) (HMAC)
Sign, Verify
(HMAC)
Derive Key
Table 42: Key algorithms supported by the CXI API
If random padding bytes are needed, always the deterministic random number generator
(DRNG) is used.
The following hash algorithms are supported.
Algorithm Hash length [bit]
MD5 128
RIPEMD-160 160
17
DH_PKCS mandatorily only contains the prime P and the generator G as domain parameters. Q is optional. DH
mandatorily contains all three DSA domain parameters P, Q and G.
Page 187 of 203

Algorithm Hash length [bit]
SHA-1 160
SHA-224 224
SHA-256 256
SHA-384 384
SHA-512 512
SHA3-224 224
SHA3-256 256
SHA3-384 384
SHA3-512 512
Table 43: Hash algorithms supported by the CXI API
See the CXI firmware module specification for restrictions in the FIPS mode.
B.2 CSP/CNG API

The CSP/CNG API supports the following algorithms.
Algorithm Key length/Curves [bit] Interface
CSP CNG
DES 56, 112 and 168  
AES 128, 192 and 256  
RSA 512 – 16.384 (delta = 8 bit)  
ECDSA NIST-P256, NIST-P384, NIST-P521  
ECDH NIST-P256, NIST-P384, NIST-P521  
Table 44: Key algorithms supported by the CSP/CNG API
Page 188 of 203

Algorithm Hash length [bit] Interface
CSP CNG
MD5 128  
RIPEMD-160 160  
SHA-1 160  
SHA-224 224  
SHA-256 256  
SHA-384 384  
SHA-512 512  
Table 45: Hash algorithms supported by the CSP/CNG API
B.1 PKCS#11 API

This chapter contains an overview about the mechanisms currently supported by the
CryptoServer PKCS#11 library.
PKCS#11 Defined Mechanisms

The following table shows the PKCS#11 standard mechanisms provided by the CryptoServer
and the PKCS#11 API functions supporting them.
Functions
Mechanism Encrypt Sign SR Gen. Wrap
& & & Digest Key/Key & Derive
Decrypt Verify VR1 Pair Unwrap
CKM_RSA_PKCS_OAEP 2 
CKM_RSA_PKCS_KEY_PAIR_GEN 
CKM_RSA_X9_31_KEY_PAIR_GEN 
CKM_RSA_PKCS 2 2  
CKM_RSA_PKCS_PSS 2
Page 189 of 203

Functions
CKM_RSA_X_509 2 2 
CKM_RSA_X9_31 2
CKM_MD5_RSA_PKCS 
CKM_SHA1_RSA_PKCS 
CKM_SHA3_224_RSA_PKCS 
CKM_RIPEMD160_RSA_PKCS 
CKM_SHA1_RSA_PKCS_PSS 
CKM_SHA3_224_RSA_PKCS_PSS 

CKM_SHA3_256_RSA_PKCS_PSS 
CKM_SHA1_RSA_X9_31 
CKM_DSA 2
CKM_DSA_SHA1 
CKM_DSA_SHA224 
CKM_DSA_SHA256 
CKM_DSA_SHA384 
Page 190 of 203

Functions
CKM_DSA_SHA512 
CKM_DSA_SHA3_224 
CKM_DSA_KEY_PAIR_GEN 
CKM_DSA_PARAMETER_GEN 
CKM_DH_PKCS_KEY_PAIR_GEN 
CKM_DH_PKCS_DERIVE 
CKM_X9_42_DH_KEY_PAIR_GEN 
CKM_X9_42_DH_PKCS_PARAMETER_GEN 
CKM_X9_42_DH_DERIVE 
CKM_EC_KEY_PAIR_GEN

(CKM_ECDSA_KEY_PAIR_GEN)
CKM_ECDSA 2
CKM_ECDSA_SHA1 
CKM_ECDSA_SHA224 
CKM_ECDH1_DERIVE 
CKM_ECDH1_COFACTOR_DERIVE 
CKM_GENERIC_SECRET_KEY_GEN 
CKM_AES_KEY_GEN 
CKM_AES_ECB  
CKM_AES_CBC  
CKM_AES_CBC_PAD  
CKM_AES_CTR 
CKM_AES_CCM 
Page 191 of 203

Functions
CKM_AES_GCM 
CKM_AES_MAC_GENERAL 
CKM_AES_MAC 
CKM_AES_CMAC 
CKM_AES_GMAC 
CKM_AES_OFB  
CKM_AES_KEY_WRAP 2 
CKM_AES_KEY_WRAP_PAD 2 
CKM_AES_KEY_WRAP_KWP 2 
CKM_DES_KEY_GEN 
CKM_DES_ECB  
CKM_DES_CBC  
CKM_DES_CBC_PAD  
CKM_DES_MAC_GENERAL 
CKM_DES_MAC 
CKM_DES2_KEY_GEN 
CKM_DES3_KEY_GEN 
CKM_DES3_ECB  
CKM_DES3_CBC  
CKM_DES3_CBC_PAD  
CKM_DES3_MAC_GENERAL 
CKM_DES3_MAC 
CKM_DES_ECB_ENCRYPT_DATA 
CKM_DES_CBC_ENCRYPT_DATA 
CKM_DES3_ECB_ENCRYPT_DATA 
CKM_DES3_CBC_ENCRYPT_DATA 
CKM_AES_ECB_ENCRYPT_DATA 
CKM_AES_CBC_ENCRYPT_DATA 
Page 192 of 203

Functions
CKM_MD5 
CKM_MD5_HMAC_GENERAL 
CKM_MD5_HMAC 
CKM_MD5_KEY_DERIVATION 
CKM_SHA_1 
CKM_SHA_1_HMAC_GENERAL 
CKM_SHA_1_HMAC 
CKM_SHA1_KEY_DERIVATION 
CKM_SHA224 
CKM_SHA224_HMAC_GENERAL 
CKM_SHA224_HMAC 
CKM_SHA256 
CKM_SHA256_HMAC 
CKM_SHA384 
CKM_SHA384_HMAC 
CKM_SHA512 
CKM_SHA512_HMAC 
CKM_SHA3_224 
CKM_SHA3_224_HMAC_GENERAL 
CKM_SHA3_224_HMAC 
CKM_SHA3_224_KEY_DERIVATION 
Page 193 of 203

Functions
CKM_SHA3_256 
CKM_SHA3_384 
CKM_SHA3_512 
CKM_RIPEMD160 
CKM_RIPEMD160_HMAC_GENERAL 
CKM_RIPEMD160_HMAC 
CKM_XOR_BASE_AND_DATA 
CKM_CONCATENATE_BASE_AND_KEY 
CKM_CONCATENATE_BASE_AND_DATA 
CKM_CONCATENATE_DATA_AND_BASE 
CKM_EXTRACT_KEY_FROM_KEY 
CKM_UTI_AES_KEY_WRAP 2 
CKM_UTI_AES_KEY_WRAP_PAD 2 
CKM_UTI_AES_KEY_WRAP_KWP 
2 
Table 46: List of supported mechanisms defined in the PKCS#11 standard
1 SR = SignRecover, VR = VerifyRecover
2 Single-part operations only
3 Single-part sign operations only
Page 194 of 203

4 Wrap only
* As specified in PKCS #11 Cryptographic Token Interface Current Mechanisms Specification

3.00 Draft Version
Vendor Defined Mechanisms

The following table shows the PKCS#11 mechanisms provided by the CryptoServer, which are
not included in the PKCS#11 standard, and the PKCS#11 API functions supporting them.
Functions
Decrypt Verify VR 1 Pair Unwrap
CKM_ECDSA_SHA3_224 
CKM_ECDSA_RIPEMD160 
CKM_DSA_RIPEMD160 
CKM_DES3_RETAIL_MAC 
CKM_RSA_PKCS_MULTI 4, 5
CKM_RSA_X_509_MULTI 4, 5
CKM_ECDSA_MULTI 4, 5
CKM_DES_CBC_WRAP 
CKM_AES_CBC_WRAP 
CKM_ECKA 4
CKM_ECDSA_ECIES 2
Table 47: List of vendor defined mechanisms
1 SR = SignRecover, VR = VerifyRecover
2 Single-part operations only
3 Mechanism can only be used for wrapping, not for unwrapping
4 Single-part sign operations only
5 Mechanism can only be used for signing, not for verification
Page 195 of 203

Public Object Support

Currently only CKK_RSA and CKK_EC public objects (CKA_PRIVATE == CK_FALSE) are
supported for the following operations:
C_GetAttributeValue
C_EncryptInit
C_Encrypt
C_EncryptUpdate
C_DecryptInit
C_Decrypt
C_DecryptUpdate
C_SignInit
C_Sign
C_SignUpdate
C_VerifyInit
C_Verify
C_VerifyUpdate
C_WrapKey
C_UnwrapKey
B.1 JCE API

The JCE API supports the following algorithms.
Signatures
Algorithm Padding Modes
SHA1withRSA PKCS1, PSS
Page 196 of 203

Algorithm Padding Modes
SHA3-224withRSA PKCS1, PSS
MD5withRSA PKCS1, PSS
SHA1withECDSA -
SHA224withECDSA -
SHA256withECDSA -
SHA384withECDSA -
SHA512withECDSA -
SHA3-224withECDSA -
SHA3-256withECDSA -
SHA3-384withECDSA -
SHA3-512withECDSA -
MD5withECDSA -
SHA1withDSA -
Table 48: Signatures algorithms supported by the JCE API
KeyPairGenerator
Algorithm
RSA
Page 197 of 203

Algorithm
EC
DSA
Table 49: KeyPairGenerator algorithms supported by the JCE API
KeyFactory
Algorithm
RSA
EC
DSA
Table 50: KeyFactory algorithms supported by the JCE API
SecretKeyFactory
Algorithm
DES
DESede
AES
Table 51: SecretKeyFactory algorithms supported by the JCE API
KeyStore
Algorithm
CryptoServer
Page 198 of 203

Table 52: KeyStore algorithms supported by the JCE API
SecureRandom
Algorithm
SHA1PRNG
CryptoServer
Table 53: SecureRandom algorithms supported by the JCE API
KeyGenerator
Algorithm
DES
DESede
AES
Table 54: KeyGenerator algorithms supported by the JCE API
Cipher
Algorithm Block mode Padding mode
DES ECB, CBC NONE, PKCS5, ISOO10126
DESede ECB, CBC NONE, PKCS5, ISOO10126
AES ECB, CBC, OFB NONE, PKCS5, ISOO10126
AES GCM, CCM NONE
RSA - NONE, PKCS1, OAEP
Table 55: Cipher algorithms supported by the JCE API
Page 199 of 203

MAC
Algorithm Block mode Padding mode
DES CBC NONE,
DESwithPKCS5Padding CBC PKCS5
DESwithISO10126Padding CBC ISOO10126
AES CBC NONE
AESwithPKCS5Padding CBC PKCS5
AESwithISO10126Padding CBC ISO010126
Table 56: MAC algorithms supported by the JCE API
Algorithm Mode
DES HmacMD5
DES HmacSHA1
DES HmacSHA224
DES HmacSHA256
DES HmacSHA384
DES HmacSHA512
DES HmacSHA3-224
DES HmacSHA3-256
DES HmacSHA3-384
DES HmacSHA3-512
Page 200 of 203

Algorithm Mode
DES HmacRMD160
AES HmacMD5
AES HmacSHA1
AES HmacSHA224
AES HmacSHA256
AES HmacSHA384
AES HmacSHA512
AES HmacSHA3-224
AES HmacSHA3-256
AES HmacSHA3-384
AES HmacSHA3-512
AES HmacRMD160
Table 57: MAC and hash algorithms supported by the JCE API
MessageDigest
Mode
MD5
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
Page 201 of 203

Mode
SHA3-224
SHA3-256
SHA3-384
SHA3-512
RMD-160
Table 58: Message digest modes supported by the JCE API
Page 202 of 203

References
Reference Title/Company Doc.-No.
[CSADMIN] CryptoServer – csadm Manual/Utimaco IS GmbH. 2009-0003
[CSFIPS- CryptoServer – Administrator’s Guide for CryptoServer 2011-0002

AdmGuide] Se-Series Gen2/CSe in FIPS Mode/Utimaco IS GmbH
[CSLAN] CryptoServer LAN – Administration M010-0002-en

Manual/Utimaco IS GmbH.
[CS_PKCS11CAT] CryptoServer – PKCS#11 P11CAT M013-0001-en

[CS_PKCS11DEV] PKCS#11 R2 Developer Guide/Utimaco IS GmbH. 2012-0007
[CS_PKCS11T2] CryptoServer –PKCS#11 p11tool2 Reference 2012-0014

[CSTrSh] CryptoServer Troubleshooting/Utimaco IS GmbH. M011-0008-en
Page 203 of 203

CryptoServer Manual Systemadministrators

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CryptoServer Manual Systemadministrators

Загружено:

Авторское право:

Доступные форматы

CryptoServer

Copyright 2018 Utimaco IS GmbH

2.7.3 Firmware Package ....................................................................................................................37

2.19.6 Extensible Key Management (EKM) .........................................................................................61

4.3 Switching between Devices ............................................................................................................95

5.6.8 Copying a Keyfile to a Smartcard (Backup) ........................................................................... 130

A.8 OS_AUDIT_CLASS_KEY ................................................................................................................ 176

1.1 About this Manual

1.1.1 Target Audience for this Manual

1.1.2 Contents of this Manual

1.1.3 Document Conventions

Convention Usage Example

Items of the Graphical User Interface

Convention Usage Example

Filenames, directory and directory

See Chapter 3, "Sample Chapter" in

Table 1: Document conventions

Here you find important safety information that should be followed.

Here you find additional notes or supplementary information.

AES Advanced Encryption Standard

BSI Bundesamt für Sicherheit in der Informationstechnik (Federal Office for

CAT CryptoServer administration tool

CNG Cryptography API: Next Generation

CSP Cryptographic Service Provider

CXI Cryptographic eXtended Interface

csadm CryptoServer command-line administration tool

DES Data Encryption Standard

DRBG deterministic random bit generator

DRNG deterministic random number generator

DSA Digital Signature Algorithm

ECDSA Elliptic Curve DSA

EKM Extensible Key Management

FIPS Federal Information Processing Standard

HSM hardware security module

JCE Java Cryptography Extension

JRE Java Runtime Environment

MAC message authentication code

MBK Master Backup Key

NTP Network Time Protocol

P11CAT PKCS#11 CryptoServer Administration Tool

PCIe PCI Express Interface

PRNG pseudorandom number generator

RSA Rivest, Shamir, Adleman (cryptosystem)

TRNG true random number generator

Table 2: List of abbreviations

1.2 Other Manuals

■ CryptoServer LAN CSe-Series

Quick Start Guides

Manuals for System Administrators

■ CryptoServer – Administration Manual

■ CryptoServer - PKCS#11 P11CAT – Manual

■ CryptoServer as a plug-in card with a PCIe bus.

Appendix B, "Supported Algorithms", describes the supported algorithms.

2.1 Administration of the CryptoServer

2.1.1 CryptoServer Administration Tool (CAT)

The CAT runs in the following Java runtime environments (JRE):

2.1.2 CryptoServer Command-line Administration Tool (csadm)

2.1.3 Menu Options on the CryptoServer LAN

2.2 Smartcards, PIN Pads and Keyfiles

The CryptoServer LAN is supplied along with ten smartcards.

2.2.2 PIN Pads

The CryptoServer LAN is supplied along with a PIN pad.

Figure 1: REINERSCT cyberJack

Figure 2: Utimaco cyberJack One