Know where your re S e curity Modules

in g H a rd wa
Und erstand
keys are
Open the book
and find: Hardwa re S ec urit y
• How HSMs are designed
• What application interfaces
are available today Mod ule s (H SM )
What you need to know • What certification methods
exist
about Hardware Security
• How to start with the
Modules! Utimaco HSM Simulator

Cryptographic applications are essential for securing data

transactions. Via a unique cryptographic signature, a ‘birth
certificate’, each and every connected device can uphold
a core root of trust that ensures that every action a smart
device initiates, is authenticated and reliable, without
third-party obstruction. At Utimaco we work to take this
highly complex encryption process and transform it to
an easy-to-use product so that you don’t have to be a Know where
crypto expert to drive the full value of a hardware secu-
rity module. That way our customers can build products
Get smart!
Learn to: your keys are
and services that help their end users enjoy the full value
www.fuer-dummies.de • Distinguish between the different
of the Internet of Things, without the risk of third party
attacks or data theft. With this book you get clear, prac- HSM technologies
tical guidance on how to benefit from deploying HSM in
your Infrastructure. • Choose the right HSM for
your application
• Start today with the HSM
Simulator

Andreas Philipp is Vice President of Business Develop-

Brought to you by
ment with Utimaco, the innovation leader in Hardware
Security Modules. With an overall extensive experience
in the Security Module Business of 20 years, Andreas has
become a well-known industry expert and a frequent
conference speaker. Andreas Philipp
 HSM
for Dummies
 Andreas Philipp

HSM
for Dummies

WILEY-VCH Verlag GmbH & Co. KGaA

 1. Auflage 2015

© 2015 WILEY-VCH Verlag GmbH & Co. KGaA, Weinheim

Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks
and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc.
and/or its affiliates, in the United States and other countries. Used by permission.

Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene
Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc.,
USA, Deutschland und in anderen Ländern.

Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag
für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler
keine Haftung.

Gedruckt auf säurefreiem Papier

®
MIX
Papier aus verantwor-
tungsvollen Quellen

www.fsc.org FSC® C083411

Korrektur: Charlie Wilson, Nottingham, UK

Satz: inmedialo Digital- und Printmedien UG, Plankstadt
Druck und Bindung: CPI – Ebner & Spiegel, Ulm
Table of Contents
Introduction 7
About This Guide 7
Icons We Used in This Guide 8
Assumptions We’ve Made about You 8
About Us: Utimaco 9

Chapter 1
How It All Started: A Crypto Recap 11
Payment Systems: The Starting Point for HSMs 12
Signed and Sealed with Standardization 13

Chapter 2
HSM Technology Today 15
HSM Formats 16
Security Requirements 17
HSM Design Principles 17
Physical Protection 18
Standards and Norms 20
Conclusion 20

Chapter 3
The Interface: The Key to the Application 21
Overview of the Current Interfaces for HSMs 22
PKCS#11 Cryptographic Token Interface Standard 23
JCE: Java Cryptography Extension 23
Microsoft Cryptography API: Next Generation 24
Other Standard Interfaces 24
Purposes of Interfaces 25
Selecting the Correct Interface 25
Designing and Realizing Your Own API 26

5
 HSM for Dummies

Chapter 4
Certification: A Quality Accolade 27
The FIPS 140 Standard 27
Common Criteria and HSMs 29
What Does Certification Mean for My Project? 30

Appendix
The HSM Simulator 31
Installing the CryptoServer Simulator 31
Launching the CryptoServer Simulator 33
Connecting to the CryptoServer Simulator via CAT 34
Logging On to CryptoServer Simulator as the Admin 35

6
Introduction
Hardware security modules are integrated into the most diverse of applications
nowadays, and are a key part of our modern infrastructures. You’re well versed
in the field of IT security – be it the protection of corporate infrastructures, or
security infrastructures for electronic identities or smart metering. Working in
these fields, you’ve come across hardware security modules, or have worked
more closely with the odd device or two.
In this guide, we give you an overview of hardware security modules (HSMs for
short) – from their historic development and current hardware and software
solutions, to the trends and developments of the future. Alongside, we cover in
detail certification to standards such as FIPS and Common Criteria. Finally, we
introduce the standard interfaces that are currently on the market, and look at
all their benefits and downsides.
With HSM for Dummies at hand, you have an easy reference guide on the sub-
jects of hardware security modules, technologies, interfaces and certifications.

About This Guide

We’ve divided this guide into four chapters and an appendix:
Chapter 1: How It All Started: A Crypto Recap
This is a summary of the history of HSMs.
Chapter 2: HSM Technology Today
In this section, we explain how hardware and software product development
implements HSMs today. You will find out about the different forms that
hardware and corresponding software currently take.
Chapter 3: The Interface: The Key to the Application
Technical mumbo-jumbo or expert knowledge – in this section, we give you
the lowdown on the HSM interfaces that are popular today.
Chapter 4: Certification: A Quality Accolade
Here we explain the different certification methods and their context within
the application.

7
 HSM for Dummies

Appendix: The HSM Simulator

We introduce a working HSM simulator with which you can make an imme-
diate start in the world of HSMs.
You can leaf back and forth to your heart’s content, select a specific section to
focus on or read the guide in one go.

Icons We Used in This Guide

This guide provides an overview of HSMs. We’ve used the following icons to de-
note useful and additional stuff to know:

This is where you can find interesting tips and more sources of infor-
mation.

Caution! The information here is about misconceptions or false inter-

pretations.

We’re issuing a warning! Incorrect assumptions can result in vulnera-

bilities – especially within security environments.

This is where the engineer steps in, providing background and infor-
mation on all aspects of HSM technology.

Assumptions We’ve Made about You

We assumed the following when writing this guide:
You’re at home in the field of cryptography.
You’re looking to find out a little more about HSMs.
You’ll have a good overview of HSMs after reading the guide.

8
 Introduction

About Us: Utimaco

Interacting ‘things’ in the Internet of Things (IoT) need to trust each other.
Utimaco is a leading manufacturer of hardware security modules (HSMs) that
provide the Root of Trust to the IoT. We keep your cryptographic keys and digital
identities safe to protect critical digital infrastructures and high value data
assets. Our products enable innovations and support the creation of new busi-
ness by helping to secure critical business data and transactions.
Utimaco delivers a general purpose HSM as a customizable platform to easily in-
tegrate into existing software solutions or enable the development of new ones.
With professional services, we also support our partners in the implementation
of their solutions.
Founded in 1983, Utimaco HSMs today are deployed across more than 80 coun-
tries in more than 1,000 installations. Utimaco employs a total of 160 people,
with sales offices in Germany, the US, the UK and Singapore.
Since then, thousands of enterprise and infrastructure companies rely on
Utimaco to guard IP, critical business data and applications against internal
and external threats. Our HSMs help protect millions of consumers globally.
Put your trust in Utimaco – today and in the future. Visit Utimaco at https://
hsm.utimaco.com.

9
 1
How It All Started: A Crypto Recap
In This Chapter
Why HSMs were developed
What initial devices looked like and which techniques they used
What initial forms of standardization and certification existed

I t probably comes as no surprise to you that HSMs were initially invented and
developed for military deployment. Security modules were developed at a
time when running cryptographic operations required special hardware. This is
because the performance of computer systems back then wasn’t exactly up to
mathematical functions. So the obvious approach was to build a coprocessor to
run the cryptography mathematics.
With the Data Encryption Standard (DES), in the late ’70s and early ’80s IBM
then introduced an algorithm to the market that developers could implement ef-
ficiently in hardware. This led to efficient implementations in software and hard-
ware, but evidently a solution for the protection of cryptographic keys used was
still lacking. So the industry developed the first HSMs. Some of the initial de-
vices were fitted with self-destructive technology.

Here’s a link to a few examples of historical equipment: ’NSA devices

with explosive tamper resistance’; www.nsa.gov/about/crypto
logic_heritage/museum/.

The combination of effective encryption methods (as they were at the time) and
the goal of protecting the computer system on which the algorithm is used drove
forward the development of HSMs. However, HSM technology wasn’t opened up
to the commercial, industrial world until the blanket introduction of Automated
Teller Machines (ATMs).

11
 HSM for Dummies

Payment Systems: The Starting Point for HSMs

ATMs these days are standalone, multi-service units. But it’s taken development
cycles over multiple decades to get to this point. Following the launch of this
equipment, the international cash machine network grew and financial institutes
placed increasing focus on the security of network mainframes processing the
data. During the first few years, the encryption routines were an inherent part of
a mainframe’s data-processing program. The upshot of this was that sensitive,
cryptographic, key data was stored directly in the memory area of a mainframe.
Because people had access to these areas, however, the security risk soon became
obvious, and financial institutes had to find a solution. Furthermore, the solu-
tion had to be in the form of a device operated externally to the mainframe that
could run the security code and that also provided a secure storage location for
the cryptographic keys.

The functionality of the ’finance HSM’ was essentially on the simple

side, but relatively critical in its effect. Financial institutes used, and
still use, the devices to store cryptographic keys with which finance ap-
plications can derive card PINs of account numbers. The wording of
the policy is: ’All PINs must be kept in encrypted form, and plain-
format PINs may never be made accessible to unauthorized third par-
ties.’ So, it became clear relatively quickly that financial institutes had
to deploy HSMs.

IBM and Racal deployed the first commercial devices at about the same time. Uti-
maco also launched its first device for the German banking system at this time.

Figure 1.1: The first Hardware Security Module ’KryptoServer’ from Utimaco

12
 1 How It All Started: A Crypto Recap

With its 3845 (table-top devices) and 3846 (rack-mounted devices) series, IBM
focused entirely on deployment inside the mainframe. Racal’s application focus
was more on alternative deployment for multipurpose usage. Utimaco’s ’Krypto-
Server’ was an ISA(E) embedded card system that supported all the necessary re-
quirements of German banking technology. It was also one of the first commer-
cially available devices that came with active tamper-responding technology.

A good overview of the devices and their designs is available at

http://www.cryptomuseum.com/crypto/index.htm. You can
search by manufacturer or device model.

What was noticeable back then for such devices was the separate input unit, en-
abling security administrators to enter key material. These devices were always
designed so as to satisfy the following requirements:
Physical protection of the data storage areas in which cryptographic keys are
kept. (Protection here means detection of unauthorised access.)
Moving of program code relevant to security inside the HSM.
Access control supported by means of a permissions-and-roles model.

Signed and Sealed with Standardization

Standards and generally applicable test procedures weren’t broadly available
when security modules first emerged, but the industry quickly recognized at a
national level that requirements for HSM technology security were necessary. It
was for this reason that, in the credit card services sector initially, security ex-
perts defined appropriate requirement lists, and then later used them for device
approval.
Increased internationalization of monetary transactions gave rise to a need for
internationally recognized and harmonized standards and test methods. It was
the ’big’ credit card companies, Europay, Mastercard and Visa, that defined their
own test and approval methods. But since 1995 an internationally recognized
certification scheme has existed in the Federal Information Processing Standard
(FIPS). Then, in 2012, the ISO launched the first ISO standard (ISO/IEC
19790:2012 Information technology – Security techniques – Security require-
ments for cryptographic modules), followed by test standard ISO/IEC
24759:2014 Information technology – Security techniques – Test requirements
for cryptographic modules. Available internationally now in addition to FIPS are
the Common Criteria standard, with its protection profile crypto modules, and
the Payment Card Industry (PCI) certification.

13
 2
HSM Technology Today
In This Chapter
Delineation of HSMs from smartcards and crypto devices
Hardware security module formats of today
Security requirements for hardware security modules
HSM design principles
Physical security mechanisms
Standards and norms for HSMs

S earch for ‘hardware security modules’ in your browser. You find links to
The Wikipedia definition of hardware security modules
Manufacturer websites
Other definitions

A tip: don’t enter ‘HSM’ or you’ll end up with the High School Musical
movie!

Searching for the term ‘hardware security modules’ on the internet brings up
different manufacturer sites and numerous definitions. Unfortunately, many ar-
ticles out there still put HSMs on a par with chip cards, and compare them.
Here’s an example: ‘Hardware security modules (HSMs), like smartcards, are
hardware devices that are used to store cryptographic key material in a secure
way and to perform cryptographic operations’ (NetKnights, 2014). The compari-
son isn’t wrong, but it doesn’t highlight the full capabilities of HSMs in terms of
computing speed and data-processing volume that we’re familiar with today in
modern data centers.

15
 HSM for Dummies

HSM Formats
The classic format of an HSM is certainly the plug-in card. This is essentially an
adapter card via which the secured computer unit enables the connection to the
host computer, and that simultaneously activates the secured area of the hard-
ware module. Figure 2.1 shows different variants of HSMs that we explain in
more detail further on.

Figure 2.1: Hardware security module formats

Another widespread HSM format is the network appliance, or server variant.

This is essentially an HSM activated directly using TCP/IP, so the host computer
can link it directly into a network.

Can you see the benefits of the plug-in card over the server variant?
The card is the product of choice when the requirement is a one-to-
one relationship between the application and the trust anchor (HSM).
The network appliance is the preferred form factor for use in data cen-
ters where it operates as the root of trust for distributed applications.

16
 2 HSM Technology Today

Security Requirements
Over the years, the security requirements of HSMs have remained essentially the
same, satisfying the following needs:
Protection against attacks on the HSM device hardware – tamper resistant
Protection from side channel attacks, such as timing attacks and differential
power analysis (so attacks that draw conclusions on the keys based on time-
based behavior or power consumption of the devices)
Protection of the cryptographic application environment
Protection of the software environment from tampering and loading of
third-party programs
Generation of keys by an authentic true random number generator
Support of all cryptographic operations currently established (signing, en-
crypting and so on)
These are the fundamental, across-the-board requirements that define HSMs.
(We intentionally omit the whole subject of interfaces at this point, and discuss
this in detail in Chapter 3.)

For more information on hardware tamper mechanisms, please visit

https://hsm.utimaco.com, which covers in detail tamper resis-
tance, tamper evidence, tamper detection and tamper response.

HSM Design Principles

The fundamental design principle for HSMs is independence of the cryptograph-
ic coprocessor from the host system with its application and interfaces. All com-
munication uses a defined channel between the application and HSM. Further-
more, a clear-cut security boundary between the HSM computing system and
the outside world must be established.
The defined delineation also means clear-cut separation of storage areas for the
secretive data in the HSM. Only the firmware inside the HSM may address the
areas within the security zone. All other hardware and software outside the secu-
rity zone (such as cable baseboards and client software, APIs and authentication
tokens) are necessary for using the HSMs, but they aren’t able to access directly
the elements in the secure area.

17
 HSM for Dummies

Figure 2.2: HSM design

Bear in mind that the separation of duty may not be the case in all ap-
plications. In addition, the communication channel to the HSM must
be protected.

So when applications are using an HSM, the security zone provides maximum
protection from key information being subjected to spyware. The security zone
and secure communication channel guarantee that no information can enter the
outside world, in particular when an attacker steals a device from its operating
environment.

Physical Protection
As we’ve seen, the security zone in the HSM is particularly important. In con-
trast to the security mechanisms for smartcards and security chips, HSMs use a
combination of mechanical, sensory and logical components as protection
mechanisms.
Essentially, two types of physical protection exist for commercially available
HSMs:
Tamper resistance: This is the most widespread method for protecting
HSMs. The objective is to make it as difficult as possible for an attacker to
physically get to the circuitry. Coating the entire circuitry with an epoxy-like
resin is a proven method.

18
 2 HSM Technology Today

Tamper response: This is the maximum level of physical protection in the

commercial sector nowadays. The aim is to detect attacks during operation
and during the service life of an HSM. A proven method for detecting me-
chanical attacks on the CPU unit of an HSM is to fit a protective shield made
up of a network of tracks inside the epoxy-resin socketing. Monitoring the
current flow within the conductive network made up of tracks makes it pos-
sible to detect an attack on the protective shield. Potential countermeasures
are then active erasing of the HSM hardware memory and resetting of the
CPU data.

Figure 2.3: Cross-section of an HSM with tamper-responsive technology

HSMs also deploy advanced physical monitoring in today’s commercial HSMs.

Firstly, this is stipulated as part of certifications. (Section 4 addresses this topic
in more detail). Secondly, these measures are required to fend off other attack
scenarios. These are the most common actions to take:
Temperature monitoring: The HSM monitors the ambient temperature to
prevent attacks from a drop in ambient temperature. (Also referred to as cold
boot attack: see http://en.wikipedia.org/wiki/Cold_boot_attack.)
Voltage monitoring: The HSM monitors adherence of the operating voltage
to the voltage ranges. If the voltage exceeds or falls below the operating volt-
age defined, the electronic circuitry may transition to a non-defined state
and then an attacker can access the restricted data.

19
 HSM for Dummies

Standards and Norms

All these issues and requirements, in the physical protection area in particular,
are detailed in ISO 19790 from 2012. This standard contains the definition of the
‘cryptographic module’ device. You can find a very good definition of different
security levels and their objectives, and a detailed description of the require-
ments for hardware protection and software measures. It also provides a compre-
hensive requirement analysis of the permissions-and-roles model of an HSM.
The second HSM standard we’d like to introduce to you is ISO 24759. This is the
test requirement for cryptographic modules corresponding to standard ISO
19790.

Conclusion
You’ve seen in this section which design principles, which security requirements
and which physical protection measures are deployed for HSMs. We’ve also brief-
ly introduced to you the current standards for HSMs. These fundamental defini-
tions appear also in the different certification schemes, such as FIPS and Com-
mon Criteria. Please head to Section 4 for more information.

20
 3
The Interface:
The Key to the Application
In This Chapter
Which interfaces exist today for HSMs
The purpose of each interface

W e’re all familiar with the logical software interfaces in IT. Taking a look at
an HSM means being faced with different interfaces for which the diverse
array of applications and operating systems is designed. Looking at application
interfaces (hereafter called APIs) from the viewpoint of the HSM means identify-
ing three APIs that are essentially logically independent:

Figure 3.1: Logical software interfaces of an HSM

Key Management API:

This API is the channel to the HSM for running all administrative functions
pertaining to keys. These functions include, for example, the secured key
backup and restore of key data in the HSM, and transport key generation.
Command API:
This is the API to the HSM for accessing the cryptographic functions of the
HSM. Also included are advanced functions such as key generation and the
import/export of key records.

21
 HSM for Dummies

User Management API:

This API is used to access all the functions necessary to create and manage
users and their corresponding roles in the HSM.

For today’s function interfaces for HSMs, such as PKCS#11, the de-
signing committees realize some of the key management and user
management functions over the command interface. Unfortunately,
developers have mixed different APIs here, which can result in security
vulnerabilities in the device if application programmers don’t imple-
ment it properly.

Now we take a look at the APIs of HSMs from the viewpoint of the calling appli-
cation. We start with a definition of the security API:
The security API enables non-trusted code run within an application to access
the sensitive resources of an HSM in a secure manner. It’s the interface between
running processes on the host system and the HSM.

Examples of security APIs are the interface between the (tamper-

secure) chip on a smartcard (trusted) and the card reader (not trust-
ed); the interface between a cryptographic hardware security module
(trusted) and the host server (not trusted); and the Google Maps API
(an interface between a server and Google, trusted) and the rest of the
internet.

An HSM interface has the following primary features:

Implementation of the security policy for external access to the secured area.
Protection of the security area from commands, irrespective of parameters
and command sequences. This means that when the code on the host system
is compromised or erroneous, it has no effect on the HSM or the critical
data.

Overview of the Current Interfaces for HSMs

We now come to the current HSM interfaces. We first introduce the interfaces
with international standardization.

22
 3 The Interface: The Key to the Application

PKCS#11 Cryptographic Token Interface Standard

This standard (also called Cryptoki) is an API for HSMs (in a broad sense) that
store cryptographic information and run cryptographic operations.
PKCS are essentially Public Key Cryptography Standards developed from 1991
onwards by the RSA Laboratories. PKCS#11 was developed up to Version 2.30 by
RSA Labs. The Organization for Advancement of Structured Information Stan-
dards (OASIS) took over the development in 2013. This interface is currently the
most widely used generic interface for accessing security modules.

Benefits
One of the key benefits of the PKCS#11 interface is interoperability between ap-
plication and security module. PKCS#11 also offers a universal approach for
symmetric as well as asymmetric cryptographic methods.

Downsides
However great the aforementioned interoperability may be, many manufacturers
have installed enhancements, or vendor defined mechanisms, in their PKCS#11
implementation, and so have reduced the benefit of manufacturer neutrality to
absurdity. The standard has also developed such a high level of complexity that
attacks on the interface in particular have very high success rates with sequences
of commands. Take a look at this article, http://www.dsi.unive.it/
~focardi/Articoli/bmfs-ASA09.pdf, which describes the problem very
well.

JCE: Java Cryptography Extension

The Java Cryptography Extension (JCE) is an interface of the Java programming
language, and at the same time a framework for cryptographic tasks such as en-
cryption, signature generation and key management. It’s been part of the Java
platform since JDK 1.4.

The JCE is part of the Java Cryptography Architecture (JCA). The split
into JCE and JCA meant that in the past the API could comply with US
restrictions for cryptography. Because the JCA contains only hash
functions, key generators and so on, they could be freely exported.

The JCE is based on a provider model that enables programmers to link in differ-
ent cryptographic models. The JCE is independent of the implementation of the

23
 HSM for Dummies

specific algorithms (as is the JCA). The JCE can use a Service Provider Interface
(SPI) to link different implementations from different suppliers into the Java run-
time environment simultaneously. From Version 1.4, Java has a JCE and JCA im-
plementation. The provider can subsequently load other implementations both
statically and dynamically. The JCE Provider from the Institute for Applied Infor-
mation Processing and Communication Technology (IAIK) at the Technical Uni-
versity of Graz (Austria) is one of the most widely known JCE implementations.

Microsoft Cryptography API: Next Generation

Lastly, we take a look around in the Microsoft world. The current interface here
is: Cryptography Next Generation (CNG). It was introduced in Windows VistaTM
and supersedes CryptoAPI. CNG supports currently popular symmetric and
asymmetric algorithms, as well as random number generation and all popular
hash functions. Microsoft is aligning itself with Suite B.

In 2005, the National Institute of Standards and Technology (NIST) in

America published a list (Suite B) of cryptographic algorithms. This
collection is a recommendation from the NSA for the deployment of
cryptographic methods and their key strengths. In parallel, the NSA
also put together the Suite A list, to represent the algorithms for de-
ployment in highly sensitive areas. The Suite A list wasn’t released.

But what would IT be without its exceptions? Microsoft has another interface for
HSMs in the field of database servers. This is a SQL server data encryption func-
tion Extensible Key Management (EKM). This function interface makes it possi-
ble to use an HSM to realize database encryption stipulated in many application
areas. The EKM interface is essentially another standard Microsoft interface.

Other Standard Interfaces

The interfaces introduced in this guide are the most widely used APIs for HSMs
at the time of print. Other interfaces to add to the list are either supplier specific
but represent an ‘industry’ standard, or are other defined interfaces such as the
integration of HSMs into the OpenSSL library. OpenSSL is a library for Secure
Socket Layer (SSL) and Transport Layer Security (TLS). Many other products,
such as OpenCA, use OpenSSL in the backend. The engine concept of OpenSSL
enables developers to link in smartcards and hardware security modules for all
cryptographic processes, meaning OpenSSL also represents a good alternative to
the interfaces we mentioned earlier in this section.

24
 3 The Interface: The Key to the Application

Purposes of Interfaces
The interface for communication with cryptographic devices is, unfortunately,
an Achilles’ heel in the deployment of HSMs. An HSM is a system offering the ca-
pability to represent a very high level of complexity. But from this attribute
comes the potential to make major implementation errors and therefore enable
a successful attack by means of a combination of different command structures.

Oldenburg University has published a very good overview of what form

attacks on interfaces take:
http://www.uni-oldenburg.de/fileadmin/user_upload/
informatik/download/da.pdf.

Also, it’s possible to run multi-protocol functions in an HSM. The consequence

here is that command interactions between individual function protocols can re-
sult in potential errors. You find these multi-protocol function HSMs, providing
different interfaces for diverse applications, in the banking sector in particular.

Selecting the Correct Interface

One of the most important criteria in selecting an HSM interface is always as-
sessment of the requirements as per the usage environment. This means that 90
percent of the interfaces you require when in a usage environment dominated
totally by Microsoft are Microsoft-defined interfaces, such as CNG (Cryptography
API: Next Generation). It also always depends on what the application you’re
planning to use already has as an interface to an HSM. The last few years have
seen advancements in this field in particular, and more and more suppliers of
standard business applications have integrated interfaces for HSM or Security
Token. Here’s a list of the most well-known applications:
Microsoft Windows Server 2012; Active Directory Certificate Services
(AD CS)
Microsoft Active Directory Rights Management Services (AD RMS)
Microsoft Internet Information Server (IIS)
Microsoft SQLEKM Provider
Bind 9 (Domain Name System)
OpenDNSSEC

25
 HSM for Dummies

Apache Tomcat
TrueCrypt
Oracle Database
Also, different security applications (such as a Public Key Infrastructure (PKI)
application or card-management system) naturally provide the capability of link-
ing in an HSM using a defined interface.

We introduce the HSM Simulator in the appendix to this guide, there

we’ve included more information on integrating HSMs into different
applications in the form of integration guides.

Designing and Realizing Your Own API

This too is possible – ask your HSM supplier about the options. In some applica-
tion areas a clearly defined application-related interface is of major benefit com-
pared to a standard interface such as PKCS#11 or JCE. If the requirements you
have in your project include the following, and they’re important in your list of
critical success factors, you should be thinking seriously about designing your
own interface:
High speed in transaction processing
Auditing capability for HSM integration
Approval from experts
The connectivity of the HSM as part of an intrinsically self-contained system,
with no interfaces coming in from outside

But you need to exercise caution. Only seasoned experts should design
and implement a security API. Involving outside experts is also very
helpful.

26
 4
Certification: A Quality Accolade
In This Chapter
Which certification schemes currently exist for HSMs
The benefits and downsides of HSM certifications
What you, as a user, must know about certifications

I n order to assess the quality and security level of a device for the purposes of
information security, product companies can perform expert assessment and
subsequent certification in accordance with defined test regulations and require-
ment lists. Addressing the issue of certification for HSMs is actually relatively
easy. Only two globally recognized certification schemes exist:
FIPS: The Federal Information Processing Standards Publications (FIPS
PUBS) is from the National Institute of Standards and Technology.
Common Criteria: The Common Criteria for Information Technology Secu-
rity Evaluation is an international standard for the testing and evaluation of
the security properties of IT products.
But certification isn’t as easy as it appears, because a broad array of diverse audit-
ing and certification schemes exists in different national industries. In the Ger-
man credit business, for example, separate requirements for HSMs exist for
deployment in monetary transaction networks. The payment card industry also
has its own definitions for HSMs.

The FIPS 140 Standard

You’ll find the body of requirements, rules and regulations for HSMs in the FIPS
140-2 standard. FIPS 140-2 is governed by the Cryptographic Module Validation
Programme (CMVP), a joint initiative by the U.S. and Canadian governments.
CMVP is a partnership initiated by the American National Institute of Standard
and Technology (NIST) and Canadian Communications Security Establishment
Canada (CSEC).
Within FIPS 140-2 there are four hierarchical security levels (1 – 4), as well as
specific certifications (FIPS 197 and so on). On every level a higher concentra-

27
 HSM for Dummies

tion of defined security criteria is attained, depending on the degree of security

necessary and the quality tests required.
The ISO/IEC 19790 standard is essentially a reworking of the national U.S. stan-
dard ‘Federal Information Processing Standard Publication (FIPS PUB) 140-2:
Security requirements for cryptographic modules’. This ISO will represent a
broader foundation in upcoming FIPS 140 definitions.

Figure 4.1: CMVP website

The CMVP website has all information you could want on FIPS 140;
see http://csrc.nist.gov/groups/STM/cmvp/index.html.
The ‘Module Validation Lists’ section has an overview of certified de-
vices sorted by manufacturer. The ‘Modules in Process’ section con-
tains all manufacturers whose modules are currently under evalua-
tion.

28
 4 Certification: A Quality Accolade

The security requirements that are detailed and specified in the standard address
a total of 11 areas of design and implementation of products in applied cryptog-
raphy. The standard differentiates between four security levels (from lowest, 1, to
highest, 4) depending on the scope of these requirements.
FIPS 140 is a key basis for the certification of products with cryptographic func-
tions. Successful certification to FIPS 140-2 entails certification of an overall se-
curity level (1 to 4) and also individual test results in different areas. For specific
applications, the latter are of far more informational value than the overall re-
sult.

In the medium term, ISO is planning to integrate the requirements of

ISO/IEC 19790 into the systematics of ISO/IEC 15408, with more than
one standard continuing to exist for the evaluation of all security prod-
ucts.

Common Criteria and HSMs

The second widely used certification scheme is the Common Criteria (CC).
The CC originated from three different standards, the European Information
Technology Security Evaluation Criteria (ITSEC), the American Federal Criteria
(FC) and the Canadian Trusted Computer Product Evaluation Criteria
(CTCPEC). They’re standardized internationally by ISO/IEC JTC 1/SC 27. In ad-
dition to a list of predefined functionality, the CC specify requirements for IT se-
curity products to be in line with a trustworthiness level. The CC enable the
security requirements to be grouped into pre-evaluated protection profiles.
Irrespective of HSMs, the Common Criteria differentiate between the functional-
ity of the system under analysis and its trustworthiness. The Common Criteria
essentially define the paradigm that the trust in a system is earned through test-
ing its functionality. Trustworthiness is considered in terms of the methods used
and the correctness of implementation.
Ideally, an independent expert committee carries out a security analysis indepen-
dent of the finished products, which leads to the creation of a general protection
profile. The product company can then develop specific security requirements
from this security list for certain products, against which the evaluation is then
performed in line with the CC. The required trustworthiness (test scope) is
generally specified as per the Evaluation Assurance Level (EAL; see later in this
section). Specification of the test scope without underlying functional security
requirements would make no sense.

29
 HSM for Dummies

The Common Criteria are made up of three parts:

Introduction and general model
Functional requirements
Assurance requirements

If you’re searching for protection profiles for an HSM, you’ll find protection pro-
files for so-called security modules. Caution is called for here, because these are
only security modules in smartcard format. The only protection profile that’s
currently evaluated and published is provided by the German Federal Office for
Information Security (BSI) with the number BSI-CC-PP-0045: Cryptographic
Modules, Security Level ‘Enhanced’.

What Does Certification Mean for My Project?

Misconceptions with regard to certification in particular still abound.
The requirements of certifications with regard to functionality frequently
mean the functions of HSMs are restricted. The consequence of this is that
many manufacturers have introduced the ‘FIPS Mode’. Auditors often expect
conformance to certifications, and so the operators run devices in ‘FIPS
Mode’.
Sometimes the functional scope of an HSM is restricted so much by the cer-
tified version that deployment within the relevant application isn’t possible.
Customers looking for HSMs need to clarify prior to product selection what
exactly they require.

30
 A
Appendix
The HSM Simulator

Y ou can start your own »software« HSM today by downloading the fully func-
tional Utimaco HSM Simulator. The Simulator package comes with the 100-
percent-functional HSM Runtime, including all administration and configura-
tion toolsets. You’ll also find a comprehensive library of integration and how-to
guides, so that you can integrate the HSM directly into your standard applica-
tion.
This chapter provides step-by-step instructions on how to download the Crypto-
Server Simulator, install it on a computer and start administrating the Crypto-
Server. It doesn’t cover all scenarios, and is intended to supplement the product
documentation provided on the SecurityServer product CD.
For detailed information on the full range of setup and configuration options,
please read the CryptoServer Manual for System Administrators 2.

Note: The CryptoServer Simulator is available for both Windows and

Linux operating systems.

Installing the CryptoServer Simulator

To download the HSM Simulator, please visit the download page at
https://hsm.utimaco.com and follow the registration process (see figure
A.1).
After you’ve registered and downloaded the Simulator, you start the installation
process by launching CryptoServerSetup-x.xx.x.exe (see figure A.2).
During the installation you need to select which components you want to install.
Please select as shown in figure A.3.

31
 HSM for Dummies

Figure A.1: Utimaco Website, Utimatico Portal

Figure A.2: CryptoServer setup

32
 A Appendix: The HSM Simulator

Figure A.3: Selected components

Launching the CryptoServer Simulator

After you complete the installation process, you’ll see new icons on your desktop.

To launch the Simulator, double-click the ‘CryptoServer Simulator’ icon. After

the Simulator launches, you’ll see the status window as shown in the following
figure.

33
 HSM for Dummies

Figure A.4: CryptoServer Simulator status

Connecting to the CryptoServer Simulator

via CAT
With the CryptoServer Adminstration Tool (CAT) you can manage and administer
the HSM via a graphic toolset. The first step is to set up the connection via the
CAT and the Simulator.
1. Launch the CAT by clicking the icon on your desktop.

If you selected the ‘launch CAT’ option during the installation process,
the CAT is still running.

2. Click on ‘Devices’ in the main CAT window.

3. Enter [email protected] for the IP address of the CryptoServer Simulator into
the ‘New Device’ box.
4. Click on ‘Add to List’.
5. Click on ‘Test’ to ensure the CAT can connect to the CryptoServer Simulator.
6. Click on ‘OK’ to save the settings.

34
 A Appendix: The HSM Simulator

Logging On to CryptoServer Simulator

as the Admin
To log on to the CryptoServer Simulator as the admin you can use the default
keyfile that’s pre-installed in the Simulator (for details of keyfiles please look at
‘CryptoServer_Manual_Systemadminstrator.pdf; Chapter 2.2.3’).

For security reasons you should replace the default admin keyfile set-
tings with your own generated keyfile. To learn more about the key
material please consult the document ‘CryptoServer_Manual_System-
adminstrator.pdf’. You find this file in your install directory, in the
subfolder ‘Documentation/Administration Guides/’.

Follow these steps (see also figure A.5):

1. In the CAT click on ‘Log In/Log Off’.
2. Select the user ‘admin’.
3. Click on ‘Log In’.
4. Select ‘Keyfile’.
5. Select path (the standard path to the Administration is set as default).
6. Select the file ‘ADMIN.key’.
7. Click on ‘Open’. (You don’t need a password.)
8. Click ‘OK’.
After you’ve finished these steps, your CryptoServer Simulator will be running
successfully. You can find detailed information on the full range of setup and
configuration options, as well as information about possible integration scenari-
os, in the documentation directory of the SecurityServer directory on your com-
puter. Here are some recommendations for further reading:
• CryptoServer LAN Manual for System Administrators
• CryptoServer Manual for System Administrators
• CryptoServer csadm Manual for System Administrators
• CryptoServer LAN V4 Operating Manual

For integration into various applications, please look up the integration guides.

35
 HSM for Dummies

Figure A.5: Admin login process

36
Notes

37
 Notes

38
Notes

39
 Notes

40
Notes

41
 Notes

42
Notes

43
 Notes

44
Notes

45
 Notes

46
Notes

47
 Notes

48
 Know where your re S e curity Modules
in g H a rd wa
Und erstand
keys are
Open the book
and find: Hardwa re S ec urit y
• How HSMs are designed
• What application interfaces
are available today Mod ule s (H SM )
What you need to know • What certification methods
exist
about Hardware Security
• How to start with the
Modules! Utimaco HSM Simulator

Cryptographic applications are essential for securing data

transactions. Via a unique cryptographic signature, a ‘birth
certificate’, each and every connected device can uphold
a core root of trust that ensures that every action a smart
device initiates, is authenticated and reliable, without
third-party obstruction. At Utimaco we work to take this
highly complex encryption process and transform it to
an easy-to-use product so that you don’t have to be a Know where
crypto expert to drive the full value of a hardware secu-
rity module. That way our customers can build products
Get smart!
Learn to: your keys are
and services that help their end users enjoy the full value
www.fuer-dummies.de • Distinguish between the different
of the Internet of Things, without the risk of third party
attacks or data theft. With this book you get clear, prac- HSM technologies
tical guidance on how to benefit from deploying HSM in
your Infrastructure. • Choose the right HSM for
your application
• Start today with the HSM
Simulator

Andreas Philipp is Vice President of Business Develop-

Brought to you by
ment with Utimaco, the innovation leader in Hardware
Security Modules. With an overall extensive experience
in the Security Module Business of 20 years, Andreas has
become a well-known industry expert and a frequent
conference speaker. Andreas Philipp