CryptoServer Csadm Manual For System Administrators Crypto Server Systemadministrators
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 222
| Download | |
| Open PDF In Browser | View PDF |
CryptoServer LAN CryptoServer CryptoServer Command-line Administration Tool - csadm Manual for System Administrators Imprint Copyright 2017 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.1.1 Date 2017-02-14 Status Final Document No. 2009-0003 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 ................................................................................................................................ 9 1.1 1.1.1 Target Audience for this Manual ...........................................................................................9 1.1.2 Contents of this Manual ........................................................................................................9 1.1.3 Document Conventions ...................................................................................................... 10 1.2 2 About This Manual...................................................................................................................... 9 Other Manuals .......................................................................................................................... 10 Fundamentals ........................................................................................................................... 13 2.1 Hardware .................................................................................................................................. 13 2.1.1 IRAM................................................................................................................................... 14 2.1.2 Key-RAM ............................................................................................................................ 14 2.2 Software ................................................................................................................................... 14 2.2.1 Bootloader.......................................................................................................................... 15 2.2.2 Firmware Modules.............................................................................................................. 15 2.2.2.1 Operating System – SMOS......................................................................................... 19 2.2.2.2 Further Standard Firmware Modules ......................................................................... 19 2.2.3 Signed Licence File ............................................................................................................ 23 2.2.4 CryptoServer’s Boot Process ............................................................................................. 23 2.2.4.1 Boot Phase Controlled by Bootloader ........................................................................ 23 2.2.4.2 Start OS ...................................................................................................................... 24 2.2.4.3 Boot Phase Controlled by Operating System SMOS .................................................. 24 2.2.4.4 Watching the Boot Process and Analyzing Errors ..................................................... 25 2.2.4.5 Start Backup Copies of Firmware (SYS Firmware Modules) ...................................... 26 2.2.4.6 Commands to Reset the CryptoServer ....................................................................... 26 2.2.5 3 Operating Modes of the CryptoServer ................................................................................ 27 Security Management................................................................................................................ 29 3.1 Life Cycle and Global States of the CryptoServer .................................................................... 29 3.1.1 State INITIALIZED .............................................................................................................. 29 3.1.2 State DEFECT ..................................................................................................................... 30 3.2 Access Control, User Concept and Secure Messaging ............................................................. 30 3.2.1 Users .................................................................................................................................. 30 3.2.2 Authentication.................................................................................................................... 31 3.2.2.1 Authentication Status and User Permissions ............................................................ 32 3.2.2.2 User Groups and Access to Commands ..................................................................... 32 3.2.2.3 Authentication Mechanisms ...................................................................................... 33 3.2.3 Maximum for Failed Authentication Attempts................................................................... 35 3.2.4 User Groups for Administration ......................................................................................... 35 Page 3 of 222 Table of Contents 3.2.4.1 Default User ADMIN ................................................................................................... 36 3.2.5 Secure Messaging .............................................................................................................. 38 3.2.6 Mutual Authentication ....................................................................................................... 40 3.3 Auditing .................................................................................................................................... 41 3.4 Alarm ........................................................................................................................................ 44 3.4.1 External Erase .................................................................................................................... 47 3.5 The Clear Functionality ............................................................................................................ 47 3.6 Temperature-dependent Behavior of the CryptoServer ........................................................... 49 3.7 System Keys ............................................................................................................................. 50 3.7.1 Default Administrator Key.................................................................................................. 50 3.7.2 Module Signature Key ........................................................................................................ 51 3.7.3 Alternative Module Signature Key ..................................................................................... 52 3.7.4 Firmware Encryption Key ................................................................................................... 53 3.7.5 The Master Key of the CryptoServer .................................................................................. 54 3.8 Backup of Keys and Users ........................................................................................................ 55 3.9 Firmware Module Management ................................................................................................ 56 3.9.1 Firmware Containers: MTC/MMC, MSC, SYS...................................................................... 56 3.9.2 Encrypted Firmware Modules ............................................................................................ 57 3.9.3 Package Files ..................................................................................................................... 58 3.10 Signed Configuration Files ....................................................................................................... 58 3.10.1 Sample Configuration File cmds_sample.cfg .................................................................... 60 3.10.2 Interface Hardening by Disabling Selected Functions ....................................................... 60 3.10.3 Configurable Role-based Access ....................................................................................... 61 3.10.4 List of External Firmware Functions .................................................................................. 62 4 The Batteries of CryptoServer/CryptoServer LAN ...................................................................... 68 5 Administration of CryptoServer with csadm .............................................................................. 69 5.1 General ..................................................................................................................................... 69 5.1.1 System Requirements ........................................................................................................ 69 5.1.2 Installation of csadm ......................................................................................................... 69 5.1.3 Syntax of csadm ................................................................................................................ 71 5.1.4 Key Specifiers .................................................................................................................... 72 5.1.5 Password Entry .................................................................................................................. 75 5.1.6 Command Execution with the csadm Tool......................................................................... 76 5.2 Basic Commands ...................................................................................................................... 78 5.2.1 Help .................................................................................................................................... 79 5.2.2 More ................................................................................................................................... 79 5.2.3 PrintError............................................................................................................................ 79 5.2.4 StrError............................................................................................................................... 80 Page 4 of 222 Table of Contents 5.2.5 Version ............................................................................................................................... 80 5.2.6 SetTimeout......................................................................................................................... 81 5.2.7 Cmd .................................................................................................................................... 82 5.2.8 CmdFile .............................................................................................................................. 83 5.2.9 CSterm ............................................................................................................................... 84 5.2.10 Sleep .................................................................................................................................. 85 5.2.11 ConnTimeout ...................................................................................................................... 85 5.3 Commands for Authentication ................................................................................................. 86 5.3.1 LogonSign .......................................................................................................................... 87 5.3.2 LogonPass ......................................................................................................................... 88 5.3.3 ShowAuthState .................................................................................................................. 89 5.3.4 GetHSMAuthKey ................................................................................................................ 90 5.4 Commands for Administration ................................................................................................. 91 5.4.1 GetState ............................................................................................................................. 92 5.4.2 SetAdminMode ................................................................................................................... 95 5.4.3 SetStartupMode ................................................................................................................. 96 5.4.4 GetStartupMode ................................................................................................................. 97 5.4.5 GetBattState ...................................................................................................................... 98 5.4.6 StartOS ............................................................................................................................... 99 5.4.7 RecoverOS........................................................................................................................ 100 5.4.8 GetTime ............................................................................................................................ 101 5.4.9 SetTime ............................................................................................................................ 102 5.4.10 GetBootLog ...................................................................................................................... 103 5.4.11 GetAuditLog ..................................................................................................................... 104 5.4.12 ClearAuditLog................................................................................................................... 104 5.4.13 GetAuditConfig ................................................................................................................. 105 5.4.14 SetAuditConfig ................................................................................................................. 106 5.4.15 MemInfo ........................................................................................................................... 108 5.4.16 Test .................................................................................................................................. 109 5.4.17 ResetAlarm....................................................................................................................... 110 5.4.18 GetModel .......................................................................................................................... 111 5.4.19 Reset ................................................................................................................................ 112 5.4.20 ResetToBL ........................................................................................................................ 113 5.4.21 Restart.............................................................................................................................. 114 5.4.22 GetInfo ............................................................................................................................. 115 5.5 Commands for Managing the User Authentication Keys ....................................................... 117 5.5.1 GenKey ............................................................................................................................. 117 5.5.2 SaveKey............................................................................................................................ 118 Page 5 of 222 Table of Contents 5.5.3 BackupKey ....................................................................................................................... 120 5.5.4 CopyBackupCard .............................................................................................................. 121 5.5.5 GetCardInfo ...................................................................................................................... 122 5.5.6 ChangePassword ............................................................................................................. 123 5.5.7 ChangePIN ....................................................................................................................... 124 5.5.8 BackupDatabase .............................................................................................................. 124 5.5.9 RestoreDatabase.............................................................................................................. 125 5.6 Commands for User Management .......................................................................................... 126 5.6.1 ListUser ............................................................................................................................ 130 5.6.2 AddUser ............................................................................................................................ 131 5.6.3 ChangeUser ...................................................................................................................... 134 5.6.4 DeleteUser ........................................................................................................................ 136 5.6.5 BackupUser ...................................................................................................................... 136 5.6.6 RestoreUser ..................................................................................................................... 137 5.6.7 SetMaxAuthFails .............................................................................................................. 138 5.6.8 GetMaxAuthFails.............................................................................................................. 139 5.7 Commands for Managing the Master Backup Keys ............................................................... 139 5.7.1 MBKListKeys .................................................................................................................... 141 5.7.2 MBKGenerateKey ............................................................................................................. 142 5.7.3 MBKImportKey ................................................................................................................. 144 5.7.4 MBKCopyKey .................................................................................................................... 145 5.7.5 MBKCardInfo .................................................................................................................... 146 5.7.6 MBKCardCopy .................................................................................................................. 148 5.7.7 MBKPINChange ................................................................................................................ 148 5.8 Commands for Firmware Management .................................................................................. 149 5.8.1 ListFirmware .................................................................................................................... 149 5.8.2 ListFiles ............................................................................................................................ 152 5.8.3 LoadFile............................................................................................................................ 155 5.8.4 LoadPkg ........................................................................................................................... 157 5.8.5 DeleteFile ......................................................................................................................... 160 5.8.6 Pack ................................................................................................................................. 161 5.8.7 Unpack ............................................................................................................................. 161 5.8.8 ListPkg ............................................................................................................................. 162 5.8.9 CheckPkg ......................................................................................................................... 163 5.8.10 ModuleInfo ....................................................................................................................... 164 5.8.11 Clear ................................................................................................................................. 166 5.9 Commands for Firmware Packaging ...................................................................................... 167 5.9.1 Page 6 of 222 MakeMTC ......................................................................................................................... 168 Table of Contents 5.9.2 RemoveMTC ..................................................................................................................... 171 5.9.3 VerifyMTC......................................................................................................................... 171 5.9.4 VerifyPkg .......................................................................................................................... 172 5.9.5 RenameToVersion ............................................................................................................ 174 5.9.6 LoadFWDecKey ................................................................................................................ 174 5.9.7 LoadAltMdlSigKey ............................................................................................................ 175 5.9.8 SignConfig ........................................................................................................................ 176 5.10 Commands for Administration of CryptoServer LAN ............................................................. 178 5.10.1 CSLGetConnections ......................................................................................................... 178 5.10.2 CSLScanDevices .............................................................................................................. 179 5.10.3 CSLGetVersion ................................................................................................................. 181 5.10.4 CSLGetStatus ................................................................................................................... 181 5.10.5 CSLGetLogFile.................................................................................................................. 182 5.10.6 CSLGetConfigFile ............................................................................................................. 183 5.10.7 CSLPutConfigFile ............................................................................................................. 184 5.10.8 CSLSetTracelevel ............................................................................................................. 185 5.10.9 CSLShutdown ................................................................................................................... 186 5.10.10 CSLReboot ....................................................................................................................... 187 5.10.11 CSLGetTime ..................................................................................................................... 187 5.10.12 CSLSetTime...................................................................................................................... 188 5.10.13 CSLGetSerial .................................................................................................................... 188 5.10.14 CSLGetLoad ..................................................................................................................... 189 5.10.15 CSLListPPApps ................................................................................................................ 189 6 7 8 Typical Administration Tasks ..................................................................................................192 6.1 Generating a User Authentication Token ............................................................................... 192 6.2 Setting-Up a New CryptoServer .............................................................................................. 194 6.3 Checking the Battery State..................................................................................................... 198 6.4 Performing a Complete Clear of the CryptoServer ................................................................. 198 Advanced Administration Tasks ............................................................................................. 203 7.1 Creating Self-Signed/Encrypted Firmware Modules ..............................................................203 7.2 Loading a Self-Signed Encrypted Firmware Module into the CryptoServer ...........................205 7.3 Creating and Using the Signed Configuration File cmds.scf ..................................................208 7.4 Enabling Mutual Authentication .............................................................................................210 Troubleshooting ......................................................................................................................213 8.1 Checking the Operativeness and the State of the CryptoServer ............................................ 213 8.2 Alarm Treatment .................................................................................................................... 215 Appendix A Built-in Elliptic Curves .............................................................................................218 References ......................................................................................................................................221 Page 7 of 222 Table of Contents Page 8 of 222 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 fundamentals of Utimaco's hardware security module CryptoServer and its security mechanisms. Furthermore, here you find information about the installation requirements and procedure of the CryptoServer's command-line administration tool (csadm), detailed descriptions of all csadm commands provided with csadm version 2.0.1 and higher, and their usage. The manual guides you through the basic and most important administration tasks, and explains the usage of some advanced administration functions, enabling you to extend the standard functionality of the CryptoServer with self-developed firmware modules. 1.1.1 Target Audience for this Manual This manual is primarily intended for system administrators who use csadm, command-line utility provided by Utimaco, to set up, administer and maintain the CryptoServer CSe-Series, Se-Series and Se-Series Gen2 (with Bootloader version 2.5.0.0 or later). 1.1.2 Contents of this Manual Chapter 2 describes the fundamentals of the hardware security module CryptoServer and its environment. Chapter 3 provides the necessary background information about the various security mechanisms of the CryptoServer, like, for example, user authentication, secure messaging, or alarm treatment. Chapter 4 provides some basic information about the batteries of the CryptoServer PCIe-plugin card and the CryptoServer LAN. Chapter 5 contains detailed descriptions of the csadm commands that should be used in practice for the CryptoServer administration. Chapter 6 provides instructions for certain typical administrative situations. Chapter 7 describes advanced administration functions primarily addressing customers who want to extend the standard functionality of the CryptoServer with self-developed firmware modules. Chapter 8 gives help and practical guidance in critical situations like an alarm or in case the CryptoServer is not reacting as expected or not reacting at all. Page 9 of 222 Introduction 1.1.3 Document Conventions We use the following conventions in this manual: Convention Usage Example Bold Items of the Graphical User Interface (GUI), e.g., menu options Press the OK button. Monospaced File names, folder and directory names, commands, file outputs, programming code samples You will find the file example.conf in the /exmp/demo/ directory. References and important terms See Chapter 3, "Sample Chapter" in the CryptoServer LAN/CryptoServer CryptoServer Command-line Administration Tool -csadm -Manual for System Administrators. Italic Table 1: Document conventions We have used icons to highlight the most important notes and information. Here you find additional notes or supplementary information. Here you find important safety information that should be followed. 1.2 Other Manuals The CryptoServer is supplied as 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 10 of 222 Introduction ■ CryptoServer LAN CSe-Series ■ CryptoServer LAN Se-Series ■ CryptoServer Se-Series Gen2 We provide the following manuals on the product CD for all series CryptoServer plug-in cards and for all series CryptoServer LAN (appliance): Quick Start Guides You will find these Manuals in the main folder 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 plugin 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 the manuals on the product CD in the following folder: …Documentation\Administration Guides\ ■ CryptoServer - Manual for System Administrators If you need to administer a CryptoServer PCIe plug-in card or a CryptoServer LAN using the 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 - Manual for System Administrators If you need to administer a CryptoServer LAN (appliance), read this manual. Since a CryptoServer plug-in card is integrated into the CryptoServer LAN, please read the manual for System Administrators CryptoServer, as well. ■ CryptoServer LAN/CryptoServer - Troubleshooting If problems occur while you are using a CryptoServer PCIe plug-in card or a CryptoServer LAN (appliance), read this manual. ■ CryptoServer LAN/CryptoServer PKCS#11 CryptoServer Administration Tool - Manual for Systemadministrators Page 11 of 222 Introduction If you need to administer the PKCS#11 R2 interface with the PKCS#11 CryptoServer Administration Tool (P11CAT), read this manual. Operating Manuals You will find the manuals on the product CD in the following folder: …Documentation\Operating Manuals\. In these manuals you will find all the necessary information for using appropriately the CryptoServer PCIe plug-in card hardware and the CryptoServer LAN (appliance) hardware. Page 12 of 222 Fundamentals 2 Fundamentals This chapter describes the fundamentals of the hardware security module CryptoServer and its environment. 2.1 Hardware Utimaco’s hardware security modules CryptoServer are physically protected specialized computer units designed to perform sensitive cryptographic tasks and to securely manage cryptographic keys. Utimaco provides different series of CryptoServer. In general, they offer the same functionality, but differ in their level of physical security: ■ CryptoServer CSe (CSe-Series) are designed for the highest requirements regarding physical security, as e.g. required in banking and governmental environments. Its extensive sensory mechanism, which includes the usage of a sensory-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 (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”. CryptoServer Se may be delivered with a hardware accelerator chip which provides highest performance for RSA operations. ■ CryptoServer Se Gen2 (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 crypto 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. 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. Page 13 of 222 Fundamentals ■ CryptoServer LAN as a network component (appliance), which can be easily integrated into a network. This is referred to below as CryptoServer LAN. On the CryptoServer plug-in 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.1.1 IRAM The CPU of the CryptoServeris 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 sensory (each memory cell of the IRAM will be overwritten), see chapter 3.4. If the CryptoServer goes down on power-off, the IRAM will be erased, too. 2.1.2 Key-RAM The Key-RAM is a non-volatile RAM, which is protected by the sensory: In case that an alarm is registered the Key-RAM will be actively erased within less than two milliseconds. Within this timeframe the Key-RAM will be overwritten five times, alternately with 00h and FFh patterns. Since the sensory-protection holds on runtime and in retention (i.e. if power supply is switched off) the Key-RAM is used to store the internal Master Key of the CryptoServer (which is needed to encrypt the data inside the CryptoServer, see chapter 3.7.5). Independently from the mode of operation the mechanism to detect an attack is active: An internal power supply will in any case provide enough power to erase the Key-RAM and so the CryptoServer's Master Key in case of an alarm. 2.2 Software During the boot process and the life cycle of a CryptoServer several parts of its software come into action. This chapter only lists these different software components and gives a rough description of their functionality. Inside the CryptoServer different kinds of software will run to different times: ■ Bootloader, ■ Operating system (SMOS) with firmware modules. The Bootloader is an independent firmware part that runs only partially on the CryptoServer whereas SMOS and the other modules run on the CryptoServer during its normal Operational Mode. Page 14 of 222 Fundamentals 2.2.1 Bootloader The Bootloader is an independent software module running before the real operating system and the firmware modules are started. The Bootloader is the first software started inside the CryptoServer after a reboot. If during the boot process the Bootloader finds itself initialized (i.e., the CryptoServer’s public Production Key has been found) and the operating system module SMOS is present in the CryptoServer, the latter will be started by the Bootloader. A more detailed description of the boot process follows in chapter 2.2.4. 2.2.2 Firmware Modules This chapter describes the firmware that is normally running – SMOS and the firmware modules. Software module or firmware module in the context of this documentation denotes an encapsulated software part running inside the CryptoServer. A module can have an external interface which can be used by an application from outside the CryptoServer device, and an internal C interface which can be called by other firmware modules. The following figures give a general overview of the various software parts of all CryptoServer series (including the software running on the host PC), how they are divided into modules and – in a rough way – where the communication paths pass. Page 15 of 222 Fundamentals Figure 1: Software architecture of the CryptoServer Se Series Page 16 of 222 Fundamentals Figure 2: Software architecture of the CryptoServer Se-Series Gen2 Page 17 of 222 Fundamentals Figure 3: Software architecture of the CryptoServer CSe-Series Page 18 of 222 Fundamentals The figures above provide an overview of the software modular parts of a CryptoServer system, including the software on the host PC like the CryptoServer administration tools: CryptoServer Command-line Administration Tool (CSADM) and CryptoServer Administration Tool (CAT), the PCI Express driver (Device Driver) and CryptoServer’s Extended Application Programming Interface (CSXAPI). The modular software parts inside the CryptoServer are called firmware modules. The firmware modules can be divided into several classes: ■ Operating system (SMOS) ■ Further standard firmware modules (CMDS, UTIL, ADM, VDES, ...) provided by Utimaco (which are realized in order to get a running CryptoServer with basic functionality, for example, for administration, cryptographic routines and data management) and ■ Other application firmware modules (cryptographic interfaces like CXI provided by Utimaco, or as developed by customer). Customer firmware modules may use all functionality that is CryptoServer-internally provided by Utimaco’s standard firmware modules. The role and functionality of these standard firmware modules is explained in the following subchapters. 2.2.2.1 Operating System – SMOS The CryptoServer’s operating system SMOS (Secure Module Operating System) provides mechanisms for task handling, inter process communication, memory management and file handling. Furthermore, SMOS realizes access to CryptoServer’s internal hardware components like memory areas, RTC, physical interfaces etc. and offers appropriate access command interfaces to the other firmware modules. In particular, based on the included device drivers SMOS provides through its hardware abstraction layer a high level access to the physical interfaces of the CryptoServer device (PCI express, USB and V.24), for read and write operations on the devices. 2.2.2.2 Further Standard Firmware Modules The following modules are implemented as CryptoServer’s standard firmware modules, providing the described functionality. Most of these firmware modules have no external interface and can only be accessed by other firmware modules via an internal public C interface. ■ SMOS (Secure Module Operating System): operating system ■ CMDS (Command Scheduler): command processing incl. protocol stack, user management Page 19 of 222 Fundamentals ■ ADM (Administration): general administration of CryptoServer, incl. firmware module management and management of audit log file ■ UTIL (Utilities): internal access to random number generator and real time clock ■ VDES: DES algorithm (key generation, encryption/decryption, MAC) ■ AES: AES algorithm (key generation, encryption/decryption, MAC) ■ VRSA and LNA (Long Number Arithmetic): RSA algorithm (incl. key pair generation) ■ ECDSA and ECA: elliptic curve algorithm (incl. ECDSA signature generation/verification, key pair generation) ■ DSA (Digital Signature Algorithm) ■ HASH: Various hash algorithms ■ DB: database management (for example, secure storage of keys and other sensitive data) ■ MBK: Management of Master Backup Key (MBK), incl. generation, export and import of MBK ■ ASN1 (Abstract Syntax Notation One) ■ NTP: Time management using an NTP (Network Time Protocol) client ■ HCE (Hardware Crypto Engine): interface for accessing the crypto accelerator chip, Broadcom, of the CryptoServer Se and, Exar, of the CryptoServer Se-Series Gen21 BCM: Driver for the Broadcom crypto accelerator chip of the CryptoServer Se; this firmware module can only provide its full functionality if the HCE firmware module is available and fully functional. EXAR: Driver for the Exar crypto accelerator chip of the CryptoServer Se-Series Gen2; this firmware module can only provide its full functionality if the HCE firmware module is available and fully functional. PP: PIN pad driver ■ SC: driver for the communication with a smartcard (using ISO 7816 commands) ■ CXI: 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. 1 The HCE module will only start up if the Broadcom hardware crypto accelerator chip is built into the CryptoServer Se or the Exar hardware crypto accelerator chip is built into the CryptoServer Se-Series Gen2. If this is not the case, the initialization state of HCE and BCM for a CryptoServer Se, and HCE and EXAR for a CryptoServer Se-Series Gen2 will be set to INIT_INACTIVE, and no services of HCE, BCM resp. EXAR firmware modules are available. Page 20 of 222 Fundamentals Only the firmware modules ADM, CMDS, CXI, PP, NTP and MBK provide external interfaces that can be used by applications outside the CryptoServer and customized firmware modules developed with the CryptoServer SDK (Software Development Kit). The CryptoServer is usually delivered with all above listed firmware modules loaded (firmware package of the SecurityServer), and stored as *.msc files. Additionally, during production at the manufacturer’s site, a subset of these firmware modules is loaded into the CryptoServer as so-called system firmware modules.2 The purpose of these system firmware modules is to provide a backup-copy of every system-relevant firmware module. In general, the CryptoServer stores a firmware module in form of a MSC (Module Storage Container). The MSC format is for CryptoServer-internal use only. It stores the module code together with certain module information and the check value for the module code’s integrity (SHA-512 hash value over the module code which will be verified at every startup). Firmware modules that are loaded during an early phase of production, at the manufacturer’s site, will be stored as SYS files (CryptoServer system files), which is exactly the same format as a MSC, just with another extension *.sys. These system firmware modules cannot be deleted and thereby offer anytime a fallback possibility for firmware. The firmware modules that are loaded as system firmware modules are those that are needed to do all necessary administration tasks to set up the CryptoServer (for example, load, replacement and deletion of further firmware modules, administration functions). The following firmware modules are loaded as system firmware modules: ■ ADM ■ AES ■ CMDS ■ DB 2 For this a specialized LoadFile Bootloader command will be used which stores the firmware modules as *.sys files (system firmware modules). The Bootloader command LoadFile is not available for any CryptoServer after delivery, i.e., it is not available at the customer’s site. Page 21 of 222 Fundamentals ■ ECA ■ ECDSA ■ HASH ■ LNA ■ SMOS ■ UTIL ■ VDES ■ VRSA Even if the operating system or other firmware modules is later on deleted or replaced by newer versions, or if the CryptoServer is cleared by the customer, all system firmware modules (*.sys) will be preserved. Therefore, in case of buggy or incompatible new firmware modules, a fallback to this first set of system firmware modules can always be made in order to reconfigure the whole system. Additionally, to these system firmware modules, which are always loaded inside the CryptoServer and can be used as backup system of firmware modules for emergency cases, a complete set of all wanted firmware modules should be loaded. This may include Utimaco’s standard firmware modules including specialized application-specific firmware modules (e.g., CXI) or further customer-specific firmware modules which may provide the actual CryptoServer functionality through an appropriate external interface, for example, for key management, cryptographic algorithms or time stamping. In addition to the above mentioned standard firmware modules, which are provided by Utimaco, it is possible to load further firmware modules into the CryptoServer. The functional design of each standard firmware module and its interface is specified in more detail in the respective module specific documentation. The functionality and interface of application firmware is not a subject of this document but will be described in separate documents. Page 22 of 222 Fundamentals 2.2.3 Signed Licence File The CryptoServer uses a Signed Licence File concept to regulate the availablity of certain features and performances (for instance the speed of certain cryptographic algorithms) in a customer-specific way. These regulations do not cause any security-relevant changes to the software. A Signed Licence File (SLF) is a customer-specific licence file *.slf which is generated by Utimaco and signed by Utimaco’s Module Signature Key (RSA signature, see chapter 3.7.2). The SLF can be loaded with the LoadFile command. During loading the signature is verified, and a check value for the SLF’s integrity (SHA-512 hash value over the SLF) is calculated. The SLF is stored together with this check value which replaces the signature. With every startup the operating system SMOS searches for the SLF and verifies its hash value during the-boot process. If a SLF is missing or its integrity cannot be verified, the CryptoServer’s firmware modules always use their default values concerning the execution of certain functions. These are in any case the most restrictive options, i.e., without SLF the CryptoServer will for instance perform certain algorithms only with lowest speed. 2.2.4 CryptoServer’s Boot Process CryptoServer’s boot procedure is divided into two phases, each of them being controlled by one firmware part: ■ first boot phase, which is controlled by the Bootloader ■ second boot phase, which is controlled by the operating system SMOS 2.2.4.1 Boot Phase Controlled by Bootloader After any reset (power-up or hardware reset) the CryptoServer starts with the program code that is stored in the BL code area, which is located in the flash device3. This is the Bootloader firmware code. The Bootloader does the first necessary start procedures, including self-tests, and offers some basic commands like status queries. 3 On a CryptoServer CSe, the CryptoServer starts with the First Stage BL which is stored in the FPGA and which itself starts the (second stage) Boot Code as stored in the BL code area. Page 23 of 222 Fundamentals At the end of the Bootloader-controlled boot phase, after the initialization of the PCIe interface, there is an open time window for command. If the Bootloader does not receive any command within the defined time window (3 seconds), and if the operating system module SMOS is loaded and its integrity can be verified (SHA-512 hash value), the Bootloader starts SMOS automatically. If this was successful, the CryptoServer is considered to be in Operational Mode (or Maintenance Mode) and the Bootloader terminates itself. 2.2.4.2 Start OS The operating system of the CryptroServer (firmware module SMOS) can be started in two ways – either in the regular way or by starting the failsafe backup copy of SMOS: At the end of the Bootloader-controlled phase of the boot procedure the Bootloader always tries at first to search for and start the OS as smos.msc. Only if this fails, it tries to start the smos.sys system module. Both modalities to start the OS can also be explicitly chosen by the user if the respective external CryptoServer command is performed: ■ The command StartOS (see chapter 5.4.6) corresponds to the usual way of starting SMOS (i.e., starting smos.msc) whereas ■ The command RecoverOS (see chapter 5.4.7) corresponds to the start of the backup copy of SMOS (i.e., start of the system module smos.sys). If the OS start fails in both modalities the CryptoServer remains in Bootloader Mode. The Bootloader is active and further Bootloader commands (like, for example, status queries) can be performed. If starting SMOS is successful the CryptoServer enters Operational or Maintenance Mode (see below), and the Bootloader terminates. 2.2.4.3 Boot Phase Controlled by Operating System SMOS After the Bootloader has passed the control to the operating system, SMOS roughly performs the following steps: 1. Initialize the memory. 2. Initialize the flash file system. 3. Initialize all hardware peripherals (including serial, PCIe and USB interfaces). 4. Search for firmware modules in the flash file system depending on its own starting mode: ▣ If SMOS itself has been started as smos.msc, and if there is no alarm present, it will start all *.msc firmware modules. Page 24 of 222 Fundamentals ▣ If SMOS is started as smos.sys module, or if an alarm is present, it will start all *.sys system firmware modules. 5. Verify the integrity of all firmware modules (see chapter 3.9.1). 6. Start all firmware modules. 2.2.4.4 Watching the Boot Process and Analyzing Errors During startup of SMOS and other firmware modules the CryptoServer writes log messages to its log interface: ■ On a CryptoServer Se log messages are written to one of the serial interfaces, usually the COM1 interface (if the network appliance CryptoServer LAN is used). If the FLASH file system contains a file named \FLASH\ then the messages are redirected to the COM2 interface (this should be the case if the CryptoServer plug-in card is used). To watch these messages a terminal (for example, a PC running a terminal program or the csadm tool, see chapter 5.2.9) has to be connected to the serial line of the CryptoServer, using the following interface settings: 115200 baud, 8 bits, no parity. ■ To output the log messages of the CryptoServer CSe and the CryptoServer Se-Series Gen2 a special USB-To-Serial Adapter (Prolific PL2303) has to be connected to one of the two USB ports available. The CryptoServer CSe and the CryptoServer Se-Series Gen2 do not have a serial port. To watch the log messages on a PC a terminal program (for example, csadm tool) has to be connected to the USB-To-Serial Adapter (115000 baud, 8 data bits, 1 stop bit, no parity). For every error or warning that occurs during the startup of SMOS, an appropriate message is output. Additionally, the log messages contain a list of all firmware modules that have been found by SMOS, and the information whether these modules could have been started successfully or not. If the boot process is stopped due to a fatal error, connecting a terminal to the log interface may be the only way to get information about the problem. If no fatal error occurs during the boot phase (i.e., if all basic firmware modules could be started successfully) the log messages can be retrieved later using the csadm administration command GetBootLog (see chapter 5.4.10). Page 25 of 222 Fundamentals 2.2.4.5 Start Backup Copies of Firmware (SYS Firmware Modules) If the CryptoServer hangs-up during the boot phase, it cannot be accessed anymore over the command interface. This may happen, for example, if the administrator has deleted one of the base firmware modules or loaded buggy or incompatible software. In such a situation of hang-up the backup copies of the base firmware modules (i.e., all system firmware modules *.sys) can be started to get the CryptoServer in Operational Mode again. This has to be done by issuing the command ResetToBL followed by the command RecoverOS (see chapters 0 and 5.4.7). After that only the system firmware modules are running, which is sufficient to administrate the CryptoServer. The bad/missing firmware can now be replaced/loaded using the normal administration command LoadFile (see chapter 5.8.3). After that the CryptoServer can be put again in normal Operational Mode (running all firmware modules *.msc) with a Restart command. 2.2.4.6 Commands to Reset the CryptoServer There are three different driver commands that reset the CryptoServer and start the boot process: ■ The Reset command (see chapter 5.4.19) causes a hardware reset. The boot process described in the previous chapters is performed including the 3 second time window for command of the Bootloader. It is strongly recommended not to use the Reset command. ■ The Restart command (see chapter 5.4.21) causes a hardware reset, waits for the beginning of the time window for Bootloader commands and immediately issues a StartOS command. Like this the boot process is sped up by skipping the 3 second time window of the Bootloader. Additionally, the Restart command waits for all firmware modules to be started by the operating system SMOS. After the Restart command has been successfully completed, the CryptoServer is in Operational Mode, and ready to accept commands. Page 26 of 222 Fundamentals ■ The ResetToBL command (see chapter 5.4.20) causes a hardware reset, waits for the beginning of the time window of the Bootloader and issues a GetState command. The boot process is stopped and the CryptoServer remains in Bootloader Mode (see chapter 2.2.5). After the ResetToBL command has been successfully completed, the CryptoServer is immediately ready to accept Bootloader commands. Use the ResetToBL command only if Bootloader commands should be performed, while the CryptoServer is in Bootloader Mode. 2.2.5 Operating Modes of the CryptoServer Basically the CryptoServer can be operated (if the respective software is loaded) in four different modes, depending on which firmware is currently active: ■ The CryptoServer is in Bootloader Mode if the Bootloader is active, i.e., the Bootloader is powered up and running but the operating system SMOS of the CryptoServer (if loaded at all) has not yet been started. ■ The CryptoServer is in Operational Mode if the operating system SMOS and further firmware modules (*.msc modules) could have been started successfully and are active. The CryptoServer can be explicitly configured to boot into restricted Operational Mode (Operational Mode – Administration-Only). In this special kind of Operational Mode all cryptogtaphic functions are blocked, and only administration functions can be executed. See chapter 5.4.3 for how to configure this special startup mode. ■ The CryptoServer is in Maintenance Mode if the backup system firmware modules (SYS modules: *.sys files) have been started successfully and are active. ■ The CryptoServer is in power down mode if no firmware is active (CryptoServer is shutdown). In power down mode the CryptoServer is not able to receive any commands. A hardware reset has to be performed to get the CryptoServer active again. If the CryptoServer is in Operational or Maintenance Mode, further load, replacement, deletion of firmware modules and other administrative work can be done by using the respective administrative commands (see chapter 5.4). ■ With the ■ ResetToBL command the CryptoServer can be set to Bootloader Mode. This may be useful for diagnostic purposes. Page 27 of 222 Fundamentals ■ With the Restart command or (if the CryptoServer is in Bootloader Mode) the StartOS command the CryptoServer can be set to Operational Mode (if the respective firmware modules are loaded and not defect). ■ With the Restart command a CryptoServer that is in the special Operational Mode – Administration-Only can be set back to the standard Operational Mode again, if the start-up mode has been previously defined with the SetStartupMode command. ■ With the SetAdminMode command a CryptoServer that is currently in the special Operational Mode – Administration-Only can be set back to the standard Operational Mode again. This means that the cryptographic functions are no longer blocked. ■ With the ■ ResetToBL command followed by the RecoverOS command the CryptoServer can be set to Maintenance Mode. With the GetState command the operating mode and state can be retrieved. It can be executed in all CryptoServer operating modes except for the power down mode. Page 28 of 222 Security Management 3 Security Management This chapter describes the various security mechanisms of the CryptoServer, like, for example, user authentication, secure messaging, or alarm treatment. 3.1 Life Cycle and Global States of the CryptoServer In error-free operation throughout its life cycle, the CryptoServer runs through the following states: BLANK -> MANUFACTURED -> INITIALIZED Additionally, the CryptoServer can be in DEFECT state. For a CryptoServer in BLANK state, there is no housing present yet and the CryptoServer board is neither covered with potting material nor tamper-protected, no software is loaded. If the CryptoServer is in MANUFACTIRED state the Bootloader code is loaded, the CryptoServer is wrapped and/or potted and the mechanical housing of the CryptoServer is closed. At the customer’s site, only CryptoServer devices in state INITIALIZED or DEFECT will normally appear. The states BLANK and MANUFACTURED are only relevant for the production process and for maintenance work done by the manufacturer. Utimaco IS GmbH does not deliver the CryptoServer in one of these states. If the CryptoServer is in DEFECT state or in any other state but INITIALIZED, contact the manufacturer Utimaco IS GmbH. Information about CryptoServer’s state can be retrieved via the csadm command GetState. 3.1.1 State INITIALIZED Any CryptoServer leaving the manufacturer’s secure environment and being delivered to the customer is in INITIALIZED state. As a minimum, in initialized state the Bootloader program code and all standard firmware modules are loaded as *.sys-files, as well as all (manufacturer-owned) system keys (public parts) like Module Signature Key, Default Administrator Key and the Production Key. Any CryptoServer supplied to the customer is in INITIALIZED state. Page 29 of 222 Security Management 3.1.2 State DEFECT If the Bootloader’s hardware self test fails during the starting phase, the CryptoServer will be in the DEFECT state. This test is always run at the beginning of the boot process. In DEFECT state the CryptoServer exclusively accepts the commands GetState and GetBootLog (if yet technically possible), which do not require any authentication. The alarm mechanism of the CryptoServer remains unchanged. If the CryptoServer is in DEFECT state, contact the manufacturer Utimaco IS GmbH. 3.2 Access Control, User Concept and Secure Messaging To control and restrict the access to security-relevant commands, the CryptoServer implements the concept of users. Security-relevant external commands sent to the CryptoServer may only be performed if the sender has authenticated the command. Only users, who are registered at the CryptoServer, and are equipped with the relevant permissions are permitted to authenticate and execute security-relevant commands. Additionally, the SecurityServer/CryptoServer SDK 4.10 introduces the CryptoServer's ability to authenticate itself towards host applications at the beginning of a secure messaging session, if requested by the corresponding application. CryptoServer's concept of HSM authentication implements a new HSM Authentication Key described in Chapter 3.2.6 and used for mutual authentication. 3.2.1 Users Commands can only be successfully authenticated by authorized users. For the management of these users, the CryptoServer stores and administrates a user database. In this database, the following data is stored for each user: ■ Name (which serves as a unique identifier for the user), 8 bytes long. ■ Long name (optional, which serves as a unique identifier for the user), up to 255 bytes long. ■ Permissions of the user. The structure of these user permissions corresponds to the structure of the authentication status (as explained in chapter 3.2.2.1, “Authentication Status and User Permissions” below), i.e., it consists of eight values in the range from 0 to 15 (0xF). Page 30 of 222 Security Management ■ Flags that determine if secure messaging is allowed for this user. ■ The authentication mechanism that has to be used by the user (see chapter 3.2.2.3 below). ■ Authentication data like cryptographic keys, passwords or other, see below. ■ User Attributes (optional). For a more detailed description of the possible user data see chapter 5.6. The CryptoServer provides also the appropriate commands to create or delete a user or to change his/her authentication token/data, see chapter 5.6.3. For every authentication to be performed, the user name and the authentication token have to be specified. Further necessary data depend from the authentication mechanism of the user. After a successful authentication the authentication status of the CryptoServer will be augmented by the permissions of the user. The authentication concept is explained in the following chapter. 3.2.2 Authentication The CryptoServer accepts certain external commands only after one (or more) appropriate user(s) have successfully authenticated themselves. Inside the CryptoServer, the firmware module CMDS is responsible for managing the authentication of commands. Certain external commands that are sent to the CryptoServer may only be executed if the sender has authenticated the command and a certain authentication status has been reached (see next chapter). For this purpose, one or more authentication header data blocks can be added to the command data block. These authentication headers are processed completely by CMDS (including verification of the authentication), and, depending on the result, CMDS increments the authentication status. The firmware module that was addressed by the command checks this authentication status later on. The CryptoServer requires all security-relevant commands to be always authenticated separately. That is, the authentication holds only for a single command and must be performed together with the corresponding command. After the execution of the command the authentication status is automatically set back to the previous value. The following subchapters explain the authentication mechanisms and their usage in detail. Page 31 of 222 Security Management 3.2.2.1 Authentication Status and User Permissions The CMDS firmware module internally stores an authentication status. The stored value is incremented after every successfull authentication. Depending on the currently reached authentication status, the command is performed or not. The authentication status consists of eight values, each in the range from 0 to 15 (0xF). These eight values represent eight different user groups (user group 0 to 7). Each value, called authentication level, gives the height (sum) of the rights/permissions gained through the authentications of various users from this specific user group. Each authentication level can vary from 0 (no permission/authentication) to 15 (highest level of permission/authentication). Example: Authentication status: 2 0 0 1 0 3 0 1 User group 7 6 5 4 3 2 1 0 In this example, the CryptoServer has reached authentication level 2 in user group 7, level 0 in user group 6, (...), and authentication level 1 in user group 0. After a user has been successfully authenticated to the CryptoServer, the authentication status is augmented by the permissions of the user (see Chapter 3.2.1, “Users”): Example: Initial authentication status (no user logged in): 00000000 Permissions of the AdminUser1: 21000000 Permissions of the AdminUser2: 33000000 Permissions of the AdminUser3: 51000000 Permissions of the AdminUser4: 51000000 Permissions of the CryptoUser: 00000002 Authentication status: AdminUser1, AdminUser2, AdminUser3 and CryptoUser logged in: F6000002 3.2.2.2 User Groups and Access to Commands Depending on the application, the eight different user groups/permissions can be used to control the access to sensitive commands. For each command in an application firmware module it can be individually defined (as part of the source code implementation) whether an authentication is necessary to perform this command, and if yes, which authentication status is mandatory. The command implementation decides, which user group is allowed to access the command and which authentication level within this user group must be reached at least. Page 32 of 222 Security Management Using these access control mechanisms, and if it is wanted for security reasons, it is for example possible to determine that a specific command is only available after an authentication following the two-person rule: If for instance the necessary authentication status for this command demands the authentication level 2 in some user group ‘x’, and if for this group ‘x’ only users with permission 1 are registered, then the specific command must be authenticated by two users of this group ‘x’. Thus, the command is only accessible if the twoperson rule is obeyed. The implementation of security rules for the authentication of commands within a specific CryptoServer application depends on the application firmware as well as on the user management. With the concrete implementation of application firmware modules, the framework for the security rules for command authentication will be determined. In particular, it will be fixed which commands have to be authenticated and which not. Within this framework, with setting rules for user administration, the customer-individual security rules for command authentication can be realized. This can be done by setting the specific permissions and authentication mechanisms for any user, when the user is created. 3.2.2.3 Authentication Mechanisms The following authentication mechanisms are implemented: ■ HMAC Password Authentication The password will not be submitted in clear text and thus cannot be scanned. Because of the random value the authentication data block cannot be scanned and replayed at a later time. A ‘Playback’-attack of the command becomes impossible. The command data are protected against unnoticed manipulation. For this mechanism a password of arbitrary length is used (minimum 4 bytes). First the host demands an 8-byte random value from the CryptoServer. Then the host calculates the HMAC value over this random value and the command data block using the password as the HMAC key. This HMAC hash value is transfered to the CryptoServer together with the command data. The CryptoServer recalculates and checks the hash with by using the password stored in the user database. The default hash algorithm for the HMAC calculation is SHA-256. Other hash algorithms can be used on demand. This authentication mechanism has the following advantages: ▣ The password is not submitted in clear text and thus cannot be scanned. Page 33 of 222 Security Management ▣ Because of the random value the authentication data block cannot be scanned and replayed at a later time. A ‘Playback’-attack of the command becomes impossible. ▣ The command data are protected against unnoticed manipulation. Therefore, this authentication mechanism is also qualified for the communication via Ethernet (CryptoServer LAN). ■ RSA Signature Authentication For this mechanism first the host demands an 8-byte random value from the CryptoServer. Then the host (or RSA smartcard) calculates an RSA signature over this random value and the command data block with the user’s private RSA key (PKCS#1 signature format). This command signature will then be transmitted to the CryptoServer together with the command data. The CryptoServer will verify the signature with the help of the RSA key’s public part, which is stored in the user database. The default hash algorithm for the signature calculation is SHA-1. Other hash algorithms can be used on demand. This mechanism is particularly qualified for communication via Ethernet (CryptoServer LAN) and therefore recommended for secure applications. ■ ECDSA Signature Authentication For this mechanism the host first demands an 8-byte random value from the CryptoServer. Then the host (or ECDSA smartcard) calculates an ECDSA signature over this random value and the command data block with the user’s private ECDSA key. This command signature will then be transmitted to the CryptoServer which will verify it with the help of the public part of the ECDSA key which is stored in the user database. The default hash algorithm for the signature calculation is SHA-256. Other hash algorithms can be used on demand. Just as the RSA signature authentication, this mechanism is particularly qualified for communication via Ethernet (CryptoServer LAN) and therefore recommended for secure applications. ■ RSA Smartcard Authentication For this mechanism the entire authentication is performed within the CryptoServer, by using an RSA signature smartcard. The user’s smartcard (containing the user’s RSA authentication key) has to be inserted into the PIN pad which is directly connected to the CryptoServer (serial port 2, at a CryptoServer LAN port CS COM). The CryptoServer can now check the authentication of commands by requesting over this PIN pad a signature created with the private part of the user’s RSA key. The CryptoServer verifies the signature using the public part of the user’s RSA key, which is stored in the user database. Page 34 of 222 Security Management This mechanism is only applicable for local applications because direct access to the CryptoServer is necessary. It is not applicable if the CryptoServer is used remotely. For the syntax to be used in the context of the csadm tool, see chapter 5.3. 3.2.3 Maximum for Failed Authentication Attempts In CryptoServer the number of consecutive failed authentication attempts for every user is automatically counted and stored as a user attribute (counter for failed authentication attempts, AuthenticationFailureCounter, denoted as Z[n]). If the authentication of a user fails, the AuthenticationFailureCounter for the user is incremented by one. On successful authentication the AuthenticationFailureCounter is reset to zero. A maximum value for the number of failed authentication attempts (MaxAuthFails) can be set by using the csadm command SetMaxAuthFails (see chapter 5.6.7), where 0 ≤ MaxAuthFails ≤ 255. To retrieve the defined value for MaxAuthFails the csadm command GetMaxAuthFails should be used. By default, MaxAuthFails = 0 which means that the number of failed authentication attempts for all CryptoServer users is not limited. Any other value for MaxAuthFails means that for each user there are only MaxAuthFails-1 consecutive failed authentication attempts allowed. The user is locked automatically after MaxAuthFails consecutive failed authentication attempts, i.e., if the AuthenticationFailureCounter of the user equals the value of MaxAuthFailures. If a user is locked no further authentication is possible for her/him, consequently this user cannot perform any command which has to be authenticated. Only a user with user management permission (permission 2 in user group 7, 20000000) can unlock a locked user by setting her/his AuthenticationFailureCounter back to zero by using the csadm command ChangeUser (see chapter 5.6.3). 3.2.4 User Groups for Administration There are two user groups predefined for the access to the external commands of the standard firmware modules. User groups 6 and 7 are reserved and should not be used by application firmware modules. User groups 0 to 5 are available for user-defined applications. User groups 6 and 7 are reserved for the following tasks: ■ User group 6: users with rights for CryptoServer administration (loading, replacing or deleting a module or file, setting the RTC, clear CryptoServer), clear audit logfile and to reset alarm. Page 35 of 222 Security Management ■ User group 7: users with user management rights (creating or deleting a user or changing the rights of a user in the user database, backup or restore a user), rights to manage the audit log file (clear audit log file, load audit.cfg file, see chapter 3.3) and to reset alarm. Here, the command for creating a user who has the rights for CryptoServer administration, i.e., a user with permission at least 1 or 2 in user group 6, is an exception. Such a user may only be created, if the authentication status is at least 21000000, i.e., the command has not only to be authenticated by a user with user management rights (20000000) but additionally by a user who himself has the permission to administrate the CryptoServer (01000000 or 02000000). To perform these commands, authentication level 2 within the respective user group is mandatory. Optionally, a higher authentication level in the respective user group can be configured by using a signed configuration file, cmds.scf, as explained in chapter 7.3. The implementation of the standard firmware requires, by default, authentication level 2 in user group 6 resp. 7 for the execution of the administrative and user management commands. This allows the realization of customer-individual security rules by setting rules for the creation of users, for example: If the customer’s security rules allow execution of these commands after authentication of one authorized user, then users with permission 2 in user groups 6 and 7 (i.e., user permission 22000000) may be created. If the customer’s security rules allow execution of these commands only after authentication of two independent authorized users (i.e., according to the two-person rule), then only users with permission 1 in user groups 6 and 7 should be created. Every other security rule that requires authentication according to the two-person rule only for specific commands or specific users, can be realized that way by setting respective organisational rules for the user management. 3.2.4.1 Default User ADMIN Before delivery Utimaco creates a default user ADMIN on every CryptoServer which enables the customer to do initial administration tasks. The ADMIN is allowed to perform all standard administration and user management commands. The authentication mechanism of the default user ADMIN is RSA Signature. He is granted permission 2 for the user groups 6 and 7. A Default Administrator Key ADMIN.key (described in chapter 3.7.1) for the user ADMIN is delivered on the SecurityServer product CD Page 36 of 222 Security Management (…\Software\All_Supported_Operating_Systems\Administration\key) and on each of the delivered smartcards, enabling the user ADMIN to authenticate himself towards the CryptoServer. Since the ADMIN.key is not customer-individual, it should either be changed by the customer, or the ADMIN user should be replaced by other users with administrator rights: After delivery the user ADMIN should as soon as possible perform one of the following actions: Replace his Default Administrator Key ADMIN.key by an individual authentication token, i.e., by an individual RSA key. In case the two-person rule is required for the administration tasks (company security policy) the user ADMIN must be replaced by two (or more) new users with the necessary user permissions. Details on this procedure can be found in chapter 6.2. If the default user ADMIN shall be replaced by two or more users, the sum of the permissions of the newly created users who use a RSA or ECDSA key as authentication token has to be at least 21000000. Only if this permission is reached, the CryptoServer allows the deletion of the default user ADMIN. The reason for this precaution is that in any situation the CryptoServer must remain administrable. Whenever an alarm occurs on the CryptoServer, or when the Clear command is performed (see chapters 3.4 and 3.5), all users with password authentication mechanism are deleted from the user database. The remaining users should be able to setup the CryptoServer again. In particular, there must be enough users left, who are able to authenticate the commands to reset the alarm and to create new users. Additional administrator users with password mechanism may be created, but they will be deleted in case of an alarm. Any user with password authentication mechanism is deleted if an alarm has occurred, and if the Clear command is executed on the CryptoServer. Also at any later date, the CryptoServer will only allow to delete a user with user management rights if the following two conditions are fulfilled: ■ In the specific user group 7 the sum of the permissions of all remaining users who use a public key as authentication token is still above the minimum permission level of 2. ■ In the specific user group 6 the sum of the permissions of all remaining users who use a public key as authentication token is still above the minimum permission level of 1. Page 37 of 222 Security Management These are the necessary conditions to retain an administrable CryptoServer. Otherwise, the command for user deletion will be rejected with an error code. In an emergency case, when the administration key is lost (e.g. smartcard(s) with private part of customer-inidividual administrator key is lost), the CryptoServer can be reset by executing the csadm Clear=DEFAULT command. In this case, the CryptoServer deletes the user database and creates a new one that contains the default ADMIN user described above. See chapter 3.5 for details. 3.2.5 Secure Messaging The CryptoServer uses a secure channel for the communication with the host/host applications. Secure messaging ensures that commands sent to the CryptoServer and all answer data received from the CryptoServer are AES encrypted and integrity-protected with an AES MAC. For this purpose, a secure messaging header data block is added to the command and the answer data block. The detailed structure of the header data blocks is described in [CSCMDS] provided on the CryptoServer SDK product CD. The secure messaging functionality implements the following steps that are transparent for the csadm user since performed within one csadm command, see LogonSign or LogonPass: 1. The host and the CryptoServer use the Diffie-Hellman key agreement scheme to agree upon an AES session key. First the external CryptoServer function GetSessionKey is called to generate an AES session key. The session key can be negotiated in one of the following ways: ▣ With the Diffie-Hellman key establishment protocol (see [PKCS#3]) ▣ With the anonymous Elliptic curve Diffie-Hellman key establishment protocol (see [ANSI-X9.63] chapter 6.2) ▣ By using the key or the password (also referred to below as the secret) of a user registered in the CryptoServer. If one of the Diffie-Hellman key agreements is used, no user account is necessary to generate the session key. In the other cases, the user’s secret will be used to encrypt or to establish the session key. Therefore, Secure Messaging shall be allowed for the selected user by setting the appropriate user flag, as described in chapter 5.6, on user creation. The CryptoServer also returns a session ID and a starting value of a sequence counter. Page 38 of 222 Security Management The exchange of the session key is done in one of the following ways: ▣ For users with password authentication, the CryptoServer calculates the SHA-256 hash value over the user’s password and the current sequence counter. Using this 32byte result value as key encryption key, the CryptoServer returns the session key to the host in an encrypted form. ▣ For users using RSA signature authentication, the CryptoServer will encrypt the session key with the public part of the user’s RSA key and send it to the host. ▣ For users using ECDSA authentication, the session key will be negotiated over the Elliptic curve Diffie-Hellman key establishment protocol with the user’s ECDSA key pair (according to [ANSI-X9.63], chapter 6.2). 2. The host and the CryptoServer exchange encrypted commands in a Secure Messaging session. The host can now send commands to the CryptoServer that are AES-encrypted and integrity-protected with an AES MAC. The respective answers to these commandsthat are sent back to the host by the CryptoServer, are always encrypted and protected with a MAC, too. The sequence counter is used as initialization vector for the AES encryption and MAC calculation and is incremented after every command to prevent unauthorized replays of the commands. The session key is identified by a session ID. All commands using the same session ID and the same session key belong to one and the same session. In this way a secure channel can be established between the CryptoServer and the host application using the Secure Messaging mechanism. The CryptoServer accepts commands that do not require authentication (i.e., in cleartext), sent to it over an unprotected connection, in parallel to commands sent to it within a protected Secure Messaging session. If the CryptoServer receives an encrypted command (i.e., a command using the Secure Messaging layer of CryptoServer’s protocol stack), it checks the MAC. The command is rejected, if the MAC is invalid. Page 39 of 222 Security Management A session key automatically becomes invalid if it is not used for 15 minutes. The SecurityServer/CryptoServer SDK 4.10 supports a maximum of 40964 session keys that can be active simultaneously and can be 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 4096 sessions are already active, the oldest session is closed and the session key associated with it becomes invalid. If the GetSessionKey function is authenticated by one or more users using single command authentication, the permissions of the corresponding user(s) will be granted to the established Secure Messaging session. All commands that are protected with this session key have the permissions of these users without any extra authentication being necessary. However, outside this session the former authentication status is preserved. The steps explained above for the usage of Secure Messaging remain transparent to the user of the csadm tool. The user just has to perform one of the authentication commands LogonSign or LogonPass, together in one command line with the command(s) for which Secure Messaging should be used. Then, csadm will automatically open an authenticated Secure Messaging session, perform the specific command(s) with Secure Messaging (i.e., encrypted and MAC-secured) and close the Secure Messaging session on the CryptoServer again. For details on the usage and syntax of LogonSign or LogonPass, see chapters 5.3.1 and 5.3.2. 3.2.6 Mutual Authentication Mutual authentication is a security feature introduced with the SecurityServer/CryptoServer SDK 4.10. It requires that both communicating parties, i.e., the host application and the CryptoServer device, prove their respective identities to each other before performing any application functions. Securiy-relevant commands are sent to the CryptoServer by host applications, within a Secure Messaging session, that must be always authenticated by one or more users with appropriate permissions. The CryptoServer does not authenticate itself to the host applications by default. It can be configured to do so as described in chapter 7.4. To control and restrict the access on the host side to security-relevant commands on the CryptoServer, the CryptoServer implements the concept of users, which is described in chapter 3.2.1. 4 The SecurityServer/CryptoServer SDK 4.01 and earlier support a maximum of 256 session keys active at the same time that can be 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 its session key is invalidated. Page 40 of 222 Security Management For the CryptoServer to be able to authenticate itself to requesting host applications, the concept of the HSM Authentication Key (HSMAuthKey) has been introduced. This is a deviceindividual 3072-bit RSA key pair, automatically generated on request and owned by the CryptoServer. Once created, the key cannot be modified or deleted by any CryptoServer user. It is used by the CryptoServer to authenticate itself in the initialization phase of a Secure Messaging session if requested by the respective host application. Both the private and the public part of the HSMAuthKey are securely stored inside the CryptoServer's FLASH memory in the authkey.db database. The private part of the HSMAuthKey is encrypted with the CryptoServer's Master Key and cannot be exported outside the HSM. The public part of the key can be retrieved with the dedicated csadm command, GetHSMAuthKey, and exported into a file, for example, HSMauth.keys, maintained by the CryptoServer administrator. Thus, it can be used to verify the authenticity of a Secure Messaging session originating from the HSM. The HSMAuthKey resp. the authkey.db is deleted when an alarm has occured or a Clear command has been executed. A new HSM Authentication Key is generated the next time the csadm GetHSMAuthKey command is executed. 3.3 Auditing The CryptoServer offers extensive audit functionality. Some events will always and automatically be audited. Other events can be optionally audited if the CryptoServer is configured accordingly. If an auditable event occurs, the operating system SMOS automatically adds an entry to the audit log file. The audit log entry always includes: ■ A timestamp with date and time of the event (if the RTC is running), ■ User name of all users who authenticated the audited command (if appropriate), ■ Function code (FC) and subfunction code (SFC) of the audited command (if appropriate), ■ Error code which indicates if the action has been successfully performed or if an error had occurred (if appropriate). Additionally, event-individual information may be stored, too. The following events are always logged: Event Audit log entry contains additional information about: alarm alarm reason Page 41 of 222 Security Management Event Audit log entry contains additional information about: extremely high temperature measured temperature Clear command performed ResetAlarm command performed Table 2: Events that are always logged into the audit log Additionally, many more events may be logged if the CryptoServer’s audit system is accordingly configured. In the last column it is indicated, if the listed event is audited by a CryptoServer in default configuration: Auditable event Message Class No. Audited by default? Firmware and file management (e.g., commands to load or delete a 1 file/firmware module, or load the Firmware Encryption Key) yes User management actions (e.g., commands to add or delete a user 2 or to change the user’s authentication token) yes Setting of the system clock of the CryptoServer 3 yes CryptoServer startup 4 yes Audit Log file management (e.g., deletion the audit log file, any changes in the audit configuration) 5 yes Master Backup Key management (e.g., create or import a Master Backup Key) 6 yes Key management (e.g., key management functions of the firmware 7 module CXI) no Successful authentications/logins 8 no Failed authentications/logins 9 yes Backup and restore operations (e.g., backup database or restore database) 10 yes Audit message classes reserved for future use 11 – 24 no Customer-defined audit message classes 25 - 30 no Table 3: List of auditable events Page 42 of 222 Security Management Auditing may also be configured in a way that only some (or none) of the above listed “default” events, or some of the “non-default” events are logged. For this purpose, a list with all audit event classes that shall be logged (identified by their message class number) may be submitted to the CryptoServer with the SetAuditConfig command described in chapter 5.4.14. Additionally, the following parameters of CryptoServer’s audit functionality may be configured: ■ Write logfiles rotatingly or not?5 (default: write rotatingly), ■ Number of audit log files (2 – 10) (default: 3) ■ Length of one logfile (4,000 ≤ length ≤ 240,000 bytes) (default: 200,000 bytes). Further auditing may be implemented application-dependent. Customer-individual firmware modules can use the audit functionality, for example, for auditing security-relevant actions like key management actions and others more. If this is wanted, the individual firmware module has to call the appropriate CMDS function cmds_audit_write(), which writes a message into the CryptoServer’s audit log file. Furthermore, the audit log system has to be configured as described above, i.e., by adding the respective message classes. A CryptoServer audit log file can be read at any time and in any mode with the csadm command GetAuditLog, see chapter 5.4.11. A CryptoServer audit audit log file can be deleted with the csadm command ClearAuditLog (if appropriately authenticated), see chapter 5.4.12. The current configuration of the CryptoServer audit functionality can be retrieved with the csadm command GetAuditConfig, see chapter 5.4.13 and it can be changed with the command SetAuditConfig, see chapter 5.4.14 The audit log files are stored in the FLASH memory of the CryptoServer. Regarding the configuration of auditing, it should always be kept in mind that a too extensive auditing may result in a great wear and tear of the FLASH memory and therefore in a decreased lifetime of the CryptoServer. 5 The audit log file is organized in several files. If configured to be written rotatinglyand in case the last audit log file is full, the CryptoServer starts overwriting the first (oldest) existing logfile, etc. If the audit log file is configured to not rotating, and in case the last audit log file is full, the CryptoServer refuses executing any auditable functions except for deleting the audit log file. If the audit log file is deleted, this is logged as first new audit log entry. Page 43 of 222 Security Management 3.4 Alarm Alarm state is caused by certain extraordinary physical circumstances. It has not to be mixed up with the above mentioned global states (initialized, defect) the CryptoServer can be in. Anytime a physical alarm occurs in the CryptoServer, it will be detected immediately by the sensory, which triggers the defined alarm mechanism (see below for details). Part of this mechanism is a restart of the CryptoServer. Alarm is given if the operating system SMOS detects an alarm condition in the alarm status register during the boot process. The CryptoServer responds with the current alarm condition and a ResetAlarm command is required to reset the alarm status register. The alarm reason can be output via the GetState command. Generally, two different kinds of alarm are possible: ■ temporary alarms (alarm can be reset) ■ permanent alarms (alarm cannot be reset) Permanent alarms occur in case of a damage of the inner or outer tamper-protecting foil, whereas usually all other possible alarms are temporary. Possible reasons for alarm are: 6 Abbreviation Description Temp_low Temperature too low (see also chapter 3.6) Temp_high Temperature too high (see also chapter 3.6) Pow_high Voltage / tension too high (CryptoServer-internal battery) Pow_low Voltage / tension too low (CryptoServer-internal battery) In_foil Internal foil damaged6 Out_foil External foil damaged6 ext_Erase External deleting / clearing done inval_MK Invalid (corrupted) device-internal Master Key (reason for this is usually an empty battery, see below) Power failed Sensory controller without power This alarm reason is only relevant for CryptoServer CSe-Series. Page 44 of 222 Security Management Abbreviation Description Sensory Controller failed No reaction from sensory controller Table 4: Possible alarm reasons Whenever a physical alarm occurs (noticed by the sensory), a dedicated Alarm-Bit in the alarm status sensory register will be set immediately, together with bits which indicate the alarm reason. The CryptoServer’s internal Master Key will be deleted immediately (i.e., the Key-RAM will be actively erased by the sensory controller) and the CryptoServer will be restarted. Independently from the occurrence of an alarm, the CPU’s internal RAM (IRAM) will be erased at the very beginning of the boot procedure. A Clearing of Key-RAM and IRAM will be finished within less than 4 msec after the occurrence of the alarm. If during the (following) boot process the operating system SMOS finds an alarm in the alarm status register which is not yet logged (i.e., the Alarm-Bit is still set), all security-relevant data inside the CryptoServer is deleted. In particular, all data that is stored, and encrypted with the CryptoServer’s Master Key, as well as the Master Key itself, is deleted. Only some specific data like firmware and the system keys remains. ■ All firmware modules, except those which had been loaded and stored in encrypted form (see chapter 3.9.2) ■ The user database, except for all users who use a password authentication mechanism (i.e., in particular all passwords have been deleted) ■ All system keys (Module Signature Key, Default Administrator Key, Production Key and, if loaded by customer, the Alternative Module Signature Key) ■ The audit log file audit.log and its configuration file audit.cfg ■ Bootloader configuration file bl.cfg, including the EID (Extended ID) ■ Any signed licence files *.slf ■ The signed configuration file cmds.scf (if available). After the deletion of all other data SMOS continues to start all system firmware modules (*.sys), which means that in alarm state the CryptoServer is running in Maintenance Mode: only the backup copies *.sys of the basic firmware modules are running. No secret or private key is left. Since the firmware module DB for database management is blocked without the Master Key, no further keys can be loaded in alarm state. Most CryptoServer functionality is blocked. Page 45 of 222 Security Management Commands that are available in alarm state comprise only all administrative commands which do not have to be authenticated (like all commands which return non-sensitive information), plus the commands ResetAlarm and SetTime. If possible, please try to eliminate the physical cause of the alarm. To regain full functionality, the ResetAlarm csadm command has to be performed and the CryptoServer has to be restarted. After that the CryptoServer will react again on further commands. Thus, each alarm must be explicitly reset by the user using the command ResetAlarm (chapter 5.4.17) before the CryptoServer can accept further sensitive commands. As part of the command ResetAlarm, the alarm is logged into the audit log file audit_.log), including date and time (up to seconds), alarm reason, and the user name of the user who authenticated the command. This log file can be read out anytime and in any mode with the GetAuditLog command. With ResetAlarm the Alarm-Bit is set back (to demonstrate that the alarm has already been logged) and a new CryptoServer's Master Key is generated. Since the ResetAlarm command has to be authenticated by a user with administrative rights, it is ensured that for any alarm at least one responsible person has been aware about the occurence of the alarm. In case of a physical alarm, which is still present (for example, temperature still too high) the Alarm-Bit will immediately be set again. The Key-RAM will be erased and the CryptoServer will be restarted. Thus, the procedure described above will be repeated, if the cause of the alarm is not eliminated. Therefore, in case of a permanent alarm, for which the reason can’t be eliminated (for example, Power Failed, or damaged foil) the CryptoServer has to be sent back to the manufacturer. Please contact Utimaco IS GmbH. If the CryptoServer is stored for a long period of time without voltage supply and the battery gets empty, the CryptoServer-internal Master Key will be deleted according to the alarm mechanism. However, information about this alarm state will be lost, too, as the content of the sensors register is also lost in the absence of voltage. Therefore, the Bootloader additionally checks at each boot process the integrity of the loaded Master Key. If the verification fails, the Bootloader will then activate a ‘virtual’ alarm. This alarm is displayed as Inval_MK, see above. Page 46 of 222 Security Management For the accurate procedure "What to do?" in case of an alarm see chapter 8.2. 3.4.1 External Erase To offer the possibility for deliberate and manual erasure of all sensitive data inside the CryptoServer, an alarm may artificially be triggered by performing an External Erase. The execution of an External Erase is the precondition for a ClearToFactoryDefaults (csadm command Clear=DEFAULT) to be performed, see chapter 3.5. ■ For a CryptoServer PCIe plug-in card, External Erase has to be performed on the PCIe plugin card as described in chapter "Performing an External Erase" of the [CSMSADM]. ■ For a CryptoServer LAN V3, an External Erase has to be performed by pressing the sealed delete switch inside the battery compartment of the device as described in chapter "Performing an External Erase on a CryptoServer LAN V3" in [CSLAN]). ■ For a CryptoServer LAN V4, an External Erase has to be performed by pressing the ERASE pushbutton behind the front door of the device as described in chapter "Performing an External Erase on a CryptoServer LAN V4" in [CSLAN]). 3.5 The Clear Functionality The CryptoServer provides with its Clear function the possibility to erase the CryptoServer to a previous state. For various purposes there are two variants of the Clear function implemented. ClearToInit function The ClearToInit function is triggered by the execution of the csadm command Clear=INIT described in chapter 5.8.11 and should be authenticated by a user with administrative rights. This function ■ Erases the CryptoServer's Master Key Page 47 of 222 Security Management ■ Erases all firmware modules (except for the Bootloader code and system firmware modules *.sys), ■ Erases the signed configuration file cmds.scf if available ■ Erases all data except for ▣ The public parts of the Production Key, Default Administrator Key, Module Signature Key and Alternatve Module Signature Key, ▣ The alarm state file (alarm.sens) ▣ The audit log file, ▣ Users with public keys as authentication token (as stored in user database) ▣ Any Signed Licence File *.slf (if present) ▣ The Bootloader configuration file bl.cfg. Afterwards the CryptoServer must be rebooted. ClearToFactoryDefaults If a customer has lost his customer-individual administrator keys and the CryptoServer cannot be administrated anymore, the ClearToFactoryDefaults function (syntax csadm Clear=DEFAULT, see chapter 5.8.11) command has to be used instead. The ClearToFactoryDefaults function offers the possibility to get an administrable CryptoServer again. However, all customer’s data is erased. The usage of this command should be restricted to this emergency case only. After a ClearToFactoryDefaults the user database will be empty, except for the default administrator user ADMIN who will be restored with the Default Administrator’s Key as authentication token. This ClearToFactoryDefaults command does not need to be authenticated, but it can be executed only immediately after an External Erase was performed, see chapter 3.4.1. This assures that only persons with physical access to the CryptoServer hardware have the possibility to clear the CryptoServer from all non-default users. Then a reboot must be performed, and the alarm (emerging from the External Erase) has to be reset (ResetAlarm command). The CryptoServer is now in the factory default settings in Page 48 of 222 Security Management which it is usually delivered (only all basic firmware modules are loaded as *.sys-files, and the single user available is the default administrator ADMIN with his ADMIN.key as the authentication key). 3.6 Temperature-dependent Behavior of the CryptoServer The CryptoServer is fully operational only if its internal temperature does not exceed or fall below a well-defined operational temperature range. The next table shows how the CryptoServer's behaviour changes depending on its internal temperature. Temperature Behavior of the CryptoServer below –13 °C Alarm is triggered, all sensitive data in the CryptoServer are deleted, and the CryptoServer is restarted. After the restart CryptoServer’s processor is suspended, commands are not executed any longer. –13 °C to 3 °C CryptoServer’s processor is suspended; a new entry is written into the audit log file; commands are not executed any longer. After being back to the normal operational temperature (4 °C to 62 °C) the CryptoServer has to be restarted in order to be operational again. 4 °C to 62 °C Normal operation 63 °C to 66 °C CryptoServer’s processor is suspended; a new entry is written into the audit log file; commands are not executed any longer. After being back to the normal operational temperature (4 °C to 62 °C) the CryptoServer has to be restarted in order to be operational again. above 66 °C An alarm is triggered, all sensitive data in the CryptoServer are deleted and the security module is restarted. After the restart CryptoServer’s processor is suspended, commands will not be executed any longer. Table 5: Operational temperature of the CryptoServer All temperature values in the table are approximate values. The exact temperature values may vary a little because of tolerances of the electronic components and the use of a hysteresis by the comparators. Note that only the internal temperature of the CryptoServer device is relevant, not the environmental temperature. The actual value of the inner temperature can be retrieved with the GetState administration command. Page 49 of 222 Security Management Once the CryptoServer’s processor is suspended (i.e., its internal temperature exceeded or fell below the operational temperature range), it does not respond to any request. Any attempt to connect to the CryptoServer will usually result in a kind of timeout error from the device driver. Before the CryptoServer’s processor is suspended the Bootloader writes an entry into the audit log file which can be read out with the administration command GetAuditLog. The only way for the CryptoServer to leave the suspend mode is to reset it by using the Restart or the ResetToBL command. Resetting the CryptoServer has no effect if its internal temperature still exceeds or is below the operational temperature range. In case of CryptoServer’s suspend mode caused by high temperature, it is recommended to switch off the power supply for some time in order to cool down the CryptoServer. 3.7 System Keys This chapter describes the system keys used in and around a CryptoServer, how they are generated, who is responsible for storing them, and the way they are handled and used. The user keys (user’s authentication token) and the Master Backup Key (MBK) are not described herein. 3.7.1 Default Administrator Key After shipping the Default Administrator Key ought to be used as soon as possible to perform first administrative tasks, including to set up a customer-individual CryptoServer. In case that the customer has lost his customer-individual administrator authentication token(s), the Default Administrator Key offers a fall-back possibility to get an administrable CryptoServer again. You will find the key (incl. private part) on the product CD stored in the keyfile \Software\All_Supported_Operating_Systems\Administration\key\ADMIN.key, and on the delivered smartcards. The following table contains detailed information about the Default Administrator Key. Page 50 of 222 Security Management Type The Default Administrator Key is an RSA key of at least 1024 bits size. Generation The Default Administrator Key is generated by the manufacturer Utimaco, outside the CryptoServer. The key is manufacturer-specific, but it is a default key and therefore neither customer-individual nor CryptoServer-individual. As part of CryptoServer shipment, the manufacturer hands over the key (public and private part) to the customer. Usage The key is needed to offer first administration possibilities: The key can be used by default administrator user ADMIN to authenticate the security relevant administration commands (commands, for example, for firmware and user management, reset alarm, set CryptoServer time) as long as the CryptoServer is still in factory default setting. The key ought to be used immediately after shipping to set up a customer-individual CryptoServer, either by replacing the default authentication token of user ADMIN (who by default uses the Default Administrator Key as authentication token) by a customer-individual key, or by replacing the default administrator user ADMIN by customer-individual users with sufficient administrator rights. Life cycle The key is imported into the CryptoServer by the manufacturer as part of the production process. One copy of the public part of the Default Administrator Key is stored in the user database as default authentication token of the administrator user ADMIN. This copy can be overwritten (csadm command ChangeUser, which has to be authenticated by the ADMIN himself) or deleted (csadm command DeleteUser, which can only be performed after sufficent further users with administrator rights have been created before, see 3.2.4.1). One of these options should be done by the customer as soon as possible after receiving the CryptoServer. A second copy of the public key is stored in the flash device (file init.key). This copy can neither be changed nor deleted, but it will be used to restore the default administrator user ADMIN with his Default Administrator Key as authentication token (using the Clear = DEFAULT (ClearFactoryDefaults) command, see chapter 3.5). Even in case of an alarm this copy of the key will not be deleted. Table 6: Details about the Default Administrator Key ADMIN.key 3.7.2 Module Signature Key The Module Signature Key is used only by the CryptoServer to verify the integrity and authenticity of the firmware modules, i.e., its origin is by the manufacturer. This system key is not used by the customer. Page 51 of 222 Security Management The following table contains detailed information about the Module Signature Key. Type The Module Signature Key is an RSA key of at least 4096-bit size. Generation It is generated by the manufacturer, outside the CryptoServer. Usage The private part of the Module Signature Key is used by the manufacturer for the signature of any MMC (Module Manufacturer Container, see chapter 3.9.1). A MMC contains the executable of a CryptoServer firmware module. The signature is used to protect the integrity and authenticity of the MMC during load process, i.e., its origin by the manufacturer. The public part of the Module Signature Key is stored inside the CryptoServer. During firmware load process, this key or the customer-specific Alternative Module Signature Key (if present, see chapter 3.7.3) will be used to verify the MMC signature. The private part of the Module Signature Key will as well be used by the manufacturer for the signature of any Signed Licence File (SLF, see chapter 2.2.3 for details). Whenever an *.slf file is loaded, the public part of the Module Signature Key will be used to verify the SLF signature, and thus to verify the integrity and authenticity of the SLF, i.e., its origin by the manufacturer. Life cycle The private part of the Module Signature Key is stored in a safe environment at the manufacturer’s site, where only authorized personnel has access. The public part of the key is imported into the CryptoServer by the manufacturer as part of the production process. It is stored in the file system area of the CryptoServer flash file (mdlsig.key). The Module Signature Key can neither be exported nor changed nor deleted by the customer. In case of an alarm, or a Clear command being executed, the key will not be deleted. Table 7: Details about the Module Signature Key 3.7.3 Alternative Module Signature Key The Alternative Module Signature Key is optional. It has to be used only if the customer would like to develop and load his own CryptoServer firmware modules (respectively if he wants to use firmware modules that do not come from the manufacturer/¬Utimaco IS GmbH). The following table contains detailed information about the Alternative Module Signature Key. Type Page 52 of 222 The Alternative Module Signature Key is an RSA key of variable length. Security Management Generation It is generated by the customer, e.g., by using the csadm command GenKey, outside the CryptoServer. The csadm command SaveKey can be used to store the new key on a smartcard. We recommend to create at least one backup copy of the smartcard/keyfile containing the Alternative Module Signature Key with the csadm command SaveKey. The customer is responsible for using and storing the key pair. Usage In case that this key shall be used: The private part of the Alternative Module Signature Key is used for the signature of the MMC (Module Manufacturer Container, see chapter 3.9.1) of any CryptoServer firmware module that the customer develops of his own. The signature is used to protect the integrity and authenticity of the MMC during load process, i.e., its origin by the customer. The public part of the Alternative Module Signature Key is stored inside the CryptoServer. During firmware load process, this key or the manufacturer’s Module Signature Key (see previous chapter) will be used to verify the MMC signature. Life cycle The public part of the Alternative Module Signature Key mdlsigalt.key may be imported in the CryptoServer with the csadm command LoadAltMdlSigKey. In this case this command has to be authenticated by a user with sufficient administrator and user management rights (authentication level 2 in user groups 6 and 7, see chapter 3.2.2). If this key has been imported into the CryptoServer, it remains stored inside CryptoServer’s flash device (file mdlsigalt.key) and will be used for MMC signature verification (in parallel to the manufacturer’s Module Signature Key, file mdlsig.key). The key can be changed/overwritten (by loading another mdlsigalt.key file, see above) and deleted (with command DeleteFile). The Alternative Module Signature Key cannot be exported from the CryptoServer, and it will not be deleted in case of an alarm. Table 8: Details about the Alternative Module Signature Key 3.7.4 Firmware Encryption Key The usage of the Firmware Encryption Key is optional. It shall be used only if the customer would like to store and load encrypted firmware modules. The following table contains detailed information about the Firmware Encryption Key. Type The Firmware Encryption Key is an RSA key of variable length. Page 53 of 222 Security Management Generation The generation shall be done by the customer, outside the CryptoServer. The customer is responsible for using and storing the key pair, and for loading the private part of the key into the CryptoServer. Usage The usage of the Firmware Encryption Key is optional. It shall be used only in case that the customer wants to load and store encrypted firmware modules. In case that this key shall be used: The public part of the Firmware Encryption Key, which remains outside the CryptoServer, is used by the developer to encrypt the executable firmware module. The encrypted executable, wrapped in a MMC/MTC structure, may be loaded into the CryptoServer. After being loaded it will be decrypted by using the private part of the Firmware Encryption Key which is stored inside the CryptoServer. Even if the private part of the Firmware Encryption Key is loaded the CryptoServer accepts also cleartext firmware modules for load. For more details see chapter 3.9.2. Life cycle The private part of the Module Encryption Key may be imported in the CryptoServer with the command LoadFWDecKey. This command has to be authenticated by a user with sufficient administrator rights (authentication level 2 in user group 6, see chapter 3.2.2). The private part of the key will be stored in an appropriate key database fw_dec_key.db, encrypted with CryptoServer’s Master Key. The export of the key is not possible. The key can be changed/overwritten (by loading another private key part with command LoadFWDecKey) and deleted (command DeleteFile). Both commands have to be authenticated by a user with sufficient administrator rights (authentication level 2 in user group 6). The (encrypted) key will also be deleted in case of an alarm and with all Clear commands, see chapters 3.4 and 3.5. Table 9: Details about the Firmware Encryption Key 3.7.5 The Master Key of the CryptoServer The customer will never use CryptoServer’s Master Key directly. The CryptoServer itself is responsible for the generation, usage and erasure (in case of alarm) of this key. The Master Key is CryptoServer-individual and will never leave the CryptoServer. The following table contains detailed information about the CryptoServer's Master Key. Type Page 54 of 222 The internal Master Key of the CryptoServer is a 32 bytes AES key (default) or a 24 bytes Triple DES key (in case that the firmware module AES is not loaded). Security Management Generation The key is generated automatically inside the CryptoServer, as part of the production process. The CryptoServer security module itself is responsible for usage and life cycle of this key. Usage The Master Key is needed to encrypt the data stored inside the CryptoServer.7 For this purpose, it will be used internally by other firmware modules. The database firmware module (module DB) facilitates the usage of the key. This DB module provides an internal public interface for secure data storage to other application firmware modules. DB will use the internal Master Key in full length. Life cycle The Master Key cannot be imported; it is generated inside the CryptoServer. After generation, the key is stored inside the CryptoServer in the sensory-protected Key-RAM (see chapter 2.1.2). The Master Key cannot be exported; hense it will never be available outside the CryptoServer. The life cycle of this key ends when an alarm occurs on the CryptoServer. If any alarm cause (temperature, foil, voltage, etc.) is detected by CryptoServer’s sensory, the memory area in which the key is stored is automatically erased. A new Master Key is generated during the next boot process after successful execution of the ResetAlarm command. Additionaly, the Master key is erased by executing the Clear command, see chapter 3.5. Any Clear command erases the CryptoServer's Master Key by generating and storing a new one (the previous one is overwritten). Table 10: Details about the CryptoServer's Master Key 3.8 Backup of Keys and Users In many applications, for security reasons or to set up a redundant CryptoServer with identical data, there is a need to create a backup of the cryptographic keys that are stored in a hardware security module, and/or to create a backup of the registered users and their user data including their authentication data (public key or password). To support backup functionality, CryptoServer provides the possibility to use Master Backup Keys. A Master Backup Key is used to encrypt secret data which is exported from the CryptoServer (for example, create a key backup), or to decrypt data, which is imported into the CryptoServer (for example, restore a key backup). This is done, for example, by Utimaco’s application firmware module CXI. It can also be used to backup and restore a user and his user data (see 7 This is necessary in order to be able to store sensitive data also in memory areas which are not sensoryprotected, i.e., which will not be erased within a very short time after an alarm has occurred. These are, for example, the flash device, NV-RAM and SD-RAM (CryptoServer CSe: DDR2 RAM). Page 55 of 222 Security Management commands BackupUser and RestoreUser in chapters 5.6.5 and 5.6.6) or database records (see commands BackupDtabase and RestoreDatabase in chapters 5.5.8 and 5.5.9). The CryptoServer is able to store up to four Master Backup Keys (slot 0...3) to be used by various applications. Each Master Backup Key (MBK) can either be a DES key (16-byte or 24byte length) or an AES key (32 bytes). The handling of such Master Backup Keys is implemented over the CryptoServer firmware module MBK. The csadm commands for MBK management are described in chapter 5.7 of this manual. 3.9 Firmware Module Management This chapter describes the management of the firmware modules of the CryptoServer from a security point of view. With the aim to link the firmware with administrative information (for example, module name and version number) and to add check values for the authenticity and integrity of the firmware, every firmware module is enveloped into a so called container. These containers allow also the load and storage of encrypted firmware. For easier handling, Utimaco IS GmbH offers also so-called package files in which a set of firmware modules (the containers described below) is bundled, ready for loading. Please see chapter 3.9.3 of this manual for the concept and usage of these firmware packages. 3.9.1 Firmware Containers: MTC/MMC, MSC, SYS A raw firmware module (RFM) is the executable module compiled for the CryptoServer platform, i.e., ready for interpretation of the CryptoServer operating system SMOS. This can be in COFF format (*.out), as used by the CryptoServer hardware, in DLL format (*.dll), as used by the CryptoServer Simulator/SDK (Software Development Kit) for Windows or in ELF format (*.so) as used by the CryptoServer Simulator/SDK for Linux. For various purposes (firmware transport, loading, and storage inside the CryptoServer) this RFM are enveloped in so-called firmware module containers: ■ For firmware loading the RFM is enveloped into a MTC (Module Transport Container). This MTC contains an MMC (Module Manufacturer Container) which has to be signed mandatorily. ■ For secure and authentic transport, the MTC may optionally be signed. ■ After the MTC has been loaded in the CryptoServer, the CryptoServer unwraps the RFM from the MMC/MTC and stores it in form of a MSC (Module Storage Container). The MMC adds a header with module information to the RFM and a signature that guarantees for the integrity and authenticity of the module. The signature has to be calculated with either Page 56 of 222 Security Management Utimaco’s Module Signature Key, or with the customer’s Alternative Module Signature Key, which is verified during firmware loading. The RFM may be encrypted. The MTC adds a second header to the MMC (which contains additional module transport information) and optionally a second signature which is calculated over the complete MMC. The MTC structure and signature can be used to secure the transport of the firmware module from the developer to the customer (to guarantee the authenticity of the module during delivery). The MSC format is for CryptoServer-internal use only. It stores the module code together with certain module information and the check value for the module code’s integrity (SHA-512 hash value over the module code). Backup-copies of all system-relevant firmware modules are always stored in every CryptoServer as SYS modules (system firmware modules). SYS files have the same format as MSC, but will be stored with file extension *.sys. It is impossible to delete a SYS file. 3.9.2 Encrypted Firmware Modules Optionally, firmware modules may be loaded and stored inside the CryptoServer in an encrypted way. This procedure requires that the private part of an appropriate RSA key, the Firmware Encryption Key, is imported into the CryptoServer. For importing the key the csadm command LoadFWDecKey is used which shall be authenticated with administrative user rights (permission 2 in the user group 6, see chapter 5.9.6). The Firmware Encryption Key is encrypted with the CryptoServer-internal Master Key, and is stored inside the CryptoServer. Outside the CryptoServer the public part of the Firmware Encryption Key is now used as a Key Encryption Key (KEK) for a 32 Byte AES key. The raw firmware module itself is encrypted with this AES key. The AES-encrypted firmware module, the KEK-encrypted AES key (encryption according to PKCS#1 block 02) and some key type information are embedded in the MMC structure. During the load procedure of a firmware module the CryptoServer searches the MMC structure for the field with the encrypted AES key. If the field is found and the Firmware Encryption Key is already stored, CryptoServer uses its private part to decrypt the AES key. After that the CryptoServer decrypts the firmware module with the AES key and checks its integrity. Before the firmware module is stored (now as an MSC) inside the CryptoServer it is encrypted again, this time with the CryptoServer-internal Master Key. A flag in the MMCheader indicates that the contained firmware module is encrypted. All other internal steps of the firmware load (for example, checking module integrity with SHA512 hash) are the same as decribed above. If an encrypted firmware module *.mtc is loaded in the CryptoServer but the Firmware Encryption Key is not yet stored inside the CryptoServer, the firmware module is stored in the Page 57 of 222 Security Management FLASH file system with the file extension *.emc for later decryption, as part of the LoadFWDecKey command. 3.9.3 Package Files In order to simplify the firmware management Utimaco IS GmbH offers firmware also in the so-called package files. A *.mpkg package file can contain several firmware modules (e.g., MTCs) as well as other files in a packed form. Package files are intended to give the user a facile possibility to load or update a set of several firmware modules and/or files into the CryptoServer in only one step. For this purpose, the CryptoServer Administration Tool csadm offers the LoadPkg command (see chapter 5.8.4) which can replace a series of succeeding csadm commands. The LoadPkg command loads the contents of the given *.mpkg package file into the CryptoServer, adding to or replacing existing firmware. Furthermore, the csadm tool offers commands to create a package file from a collection of MTCs or to list its contents, to retrieve the contained firmware modules from a *.mpkg file, and to compare the contents of a package file with the firmware that is already stored in the CryptoServer (commands Pack, see chapter 5.8.6, ListPkg, see chapter 5.8.8, Unpack, see chapter 5.8.7, CheckPkg, see chapter 5.8.9). Additionally, you can also check the MMC signature of each firmware module contained in a package (VerifyPkg, see chapter 5.9.4). 3.10 Signed Configuration Files The CryptoServer software supports the use of signed configuration files with the.scf file extension. In such a signed configuration file you can define specific firmware module configuration settings, for example, to disable selected CryptoServer functions which enables the hardening of this functions, and to define elevated permission/authentication requirements for specific CryptoServer functions. The signed configuration files are protected with a signature using an Alternative Module Signature Key, and can only be loaded into the CryptoServer by a user with system administrator permission (2 in the user group 6). Like this setting, changing or removing additional security rules defined in a signed configuration file requires the same permissions and protection as those for loading and changing the CryptoServer firmware. The signed configuration files are supported for the CryptoServer-Series listed in the table below, and starting with the given minimum versions of the firmware modules making this functionality available: Page 58 of 222 Security Management Minimum versions of required firmware modules CryptoServer-Series CSe Se Se Gen2 SMOS ≥ 4.4.0.0 ≥ 3.3.0.3 ≥ 5.1.0.0 CMDS ≥ 3.2.0.2 ≥ 3.2.0.2 ≥ 3.2.0.2 ADM ≥ 3.0.12.0 ≥ 3.0.12.0 ≥ 3.0.12.0 Table 11: Firmware requirements for the support of signed configuration files A signed configuration file is originally created as a configuration file with any file extension, for example, *.cfg, *.txt. This configuration file is then signed with the Module Signature Key or the Alternative Module Signature Key by using the csadm command SignConfig (see chapter 5.9.8). The Alternative Module Signature Key is created by the customer outside the CryptoServer and imported into it (by using the csadm commands GenKey and LoadAltMdlSigKey). The .scf file is loaded into the CryptoServer with the csadm command LoadFile. While loading it into the CryptoServer the signature of the .scf file is verified by the ADM firmware module. After successful signature verification and before the signed configuration file is stored on the CryptoServer's file system, the signature is replaced by a SHA-512 hash value. On every startup this hash value is recalculated and compared with the previously stored one, in order to check the integrity of the signed configuration file. Syntax The syntax of a signed configuration file is as follows: ■ Sections are defined as [Section name]. ■ Global configuration items should be specified above the first section definition. ■ Configuration items are defined as combination of a key and a value: = , ,…, Rules ■ Leading and trailing space characters are stripped on and . ■ A should not contain any space characters. ■ The character # should be used for commenting out a line. ■ Lines with an invalid syntax are ignored. ■ One [Section] should be used only once in the current configuration file. ■ A should be used only once in the current [Section]. Page 59 of 222 Security Management ■ The might be split over several lines which should end with a backslash "\". Deleting and Replacing Signed Configuration Files Signed configuration files are only deleted when: ■ Executing the csadm command Clear or as described in chapter 5.3 of the CryptoServer Manual for System Administrators, ■ Loading a new firmware package into the CryptoServer (by using the csadm command LoadPkg with parameter ForceClear or as described in chapter 5.5.1 of the CryptoServer Manual for System Administrators) ■ Executing a Clear-to-Factory-Defaults by performing an External Erase as described in chapter 5.4 of the CryptoServer Manual for System Administrators. Signed configuration files cannot be deleted by using the csadm command DeleteFile, and are not deleted when an alarm has occurred. You can load a new signed configuration file into the CryptoServer with the csadm command LoadFile. The existing one is then overwritten. 3.10.1 Sample Configuration File cmds_sample.cfg Utimaco provides a sample configuration file cmds_sample.cfg on the SecurityServer 4.0 product CD in the folder \Software\All_Supported_Operating_Systems\Administration. It contains a list of the CryptoServer firmware modules, providing external interfaces, and their unique module IDs (function code (FC)), as well as complete list of their external functions/interfaces (subfunction codes (SFC)). You can use this sample configuration file as a basis for your own configuration/signed configuration file. After editing the sample configuration file to fit to your requirements, you should rename it to cmds.cfg so that it can be interpreted by the CryptoServer. You will find step-by-step instructions on how to create/edit, sign, load and activate your configuration file in chapter 7.3. 3.10.2 Interface Hardening by Disabling Selected Functions With release 4.0 of the SecurityServer product CD the CryptoServer software offers the possibility to additionally secure the CryptoServer interfaces by disabling selected CryptoServer functions. These functions have to be defined in the signed configuration file cmds.scf. For that purpose, the configuration file cmds_sample.cfg has to contain the dedicated section [DiasableSFC] specifying which functions should be disabled. The syntax is as follows: Page 60 of 222 Security Management [DiasableSFC] = , ,…, or for better readability = ,\ ,\ …,\ FC is the function code (ID) of the firmware module, which is exactly three hex digits with leading 0x, e.g., "0x012". SFC is the specific decimal sub-function code (ID), specifying a function within a firmware module, which is disabled. The SFCs do not have to be ordered numerically. The disabled firmware module functions are listed during CryptoServer's startup in the Boot Log in specific entries with the syntax CMDS/DSOM: – disabled … . For example, CMDS/DSOM: 0x083 – disabled 0 1 17 means that in the firmware module CMDS (with function code FC = 0x83) the functions Echo (with SFC = 0), Reverse Echo (with SFC = 1) and Set Maximum Authentication Failures (with SFC = 17) are disabled, and cannot be used by external applications. If you try to access a disabled CryptoServer function the following error message is returned by the CryptoServer: Error B0830061 This function is not available in this HSM configuration See chapter 7.3 for step-by-step instructions on how to create/edit, sign, load and activate your signed configuration file cmds.scf. 3.10.3 Configurable Role-based Access With release 4.0 of the SecurityServer product CD the CryptoServer provides the possibility to increase the necessary authentication level for selected CryptoServer functions, and thus, to even further restrict the access to the system to users with customized roles/permissions. The CryptoServer maximal possible authentication status that can be reached for selected functions in the different user groups has been increased to 15 (0xF). The increased permission level enabling specific users to execute specific functions can be individually configured by the customer for the CryptoServer external functions with help of the signed configuration file cmds.scf. In order to do so the configuration file cmds_sample.cfg, has to contain a section [Permissions] specifying the increased permissions required for specific functions in the defined firmware modules. The syntax is as follows: [Permissions] = : , : ,…, : Page 61 of 222 Security Management or for better readability [Permissions] = : ,\ : ,\ …,\ : FC is the function code (ID) of the firmware module which is exactly three hex digits with leading 0x, e.g., 0x012. SFC is the decimal sub-function code and permissions is a hexadecimal number (maximum 8 bytes without leading 0x, e.g., FF00F000) denoting the permission in each of the eight user groups as described in chapter 3.2.1,"Users". The SFCs do not have to be ordered numerically. The permissions defined in the signed configuration file can only be used to extend the permission required, by default, for the execution of the corresponding firmware module function. For security reasons it is not possible to suspend the required default permissions for the specified functions for external interfaces. The signed configuration file cmds.scf is evaluated during startup, while all firmware modules register with their FC and SFCs at the CMDS module. In case there is an entry for a given firmware module, identified by its FC, found in the cmds.scf file, the reguired permissions for each specified SFC are set according to that definition. The list of customized permissions that are enforced after registration, is included in the audit log only if the log event "Startup messages" is activated, as by default (see chapter 5.9.10 of the the CryptoServer Manual for System Administrators). An entry in the Audit Log contains the following information: