OpenHSM: An Open key life cycle protocol for
Public Key Infrastructure’s Hardware Security
Modules ?
Jean Everson Martina??1 and Tulio Cicero Salvaro de Souza2
Ricardo Felipe Custodio2
1 University of Cambridge
Computer Laboratory
William Gates Building
15 JJ Thomson Avenue
Cambridge – CB3 0FD – United Kingdom
2 Laborato´rio de Seguranc¸a em Computac¸a˜o (LabSEC)
Universidade Federal de Santa Catarina (UFSC)
Caixa Postal 476 – 88040-900 – Floriano´polis – SC – Brasil
Jean.Martina@cl.cam.ac.uk, salvaro@inf.ufsc.br, custodio@inf.ufsc.br
Abstract. The private keys used in a PKI are its most important as-
set. Protect these keys from unauthorised use or disclosure is essential to
secure a PKI. Relying parties need assurances that the private key used
to sign their certificates is controlled and managed following pre-defined
statement policy. Hardware Security Modules (HSM) offer physical and
logical protection and should be considered for any PKI deployment. The
software that manages keys inside an HSM should control all life cycle of
a private key. Normally this kind of equipment implements a embedded
key management protocol and this protocols are not available to public
scrutiny due to industrial interests. Other important issue is that HSMs
are targeted in their development to the Bank industry and not to PKI,
making some important PKI issues, like, strict key usage control and a
secure auditing trail, play a secondary role. This paper presents an open
protocol to securely manage private keys inside HSMs. The protocol is
described, analysed and discussed.
Keywords : Key management protocol, Hardware Security Modules
1 Introduction
Key management includes key establishment, rules and protocols for generating
keys, and the subsequent handling of those keys. Securely manage cryptographic
keys is one of the most important and resource consuming efforts to guarantee
? Work supported and founded by Rede Nacional de Pesquisa/Brazil
?? Supported by CAPES Foundation/Brazil on grant #4226-05-4

the security on public key cryptosystems. It means we must have a rigid control
on the life cycle of those keys and this is not a trivial task. Moreover, we can
assume that a public cryptosystem can be considered as secure as the keys are
secured. Taken this as a premise we should guarantee that a key is strictly secure
during all events on its life cycle. A way to achieve this is by designing systems
to securely create, manage, copy, and destroy private keys maintaining an audit
record of all uses during the key life.
Hardware security modules are specific hardware designed to protect key
against any kind of logical and physical tampering or extraction of cryptographic
material from its environment. The HSMs are normally hardware that passed by
certification procedure. The most widely known are FIPS 140-2 [1], a certifica-
tion developed by USA’s Department of Commerce, and Common Criteria [2],
developed by a consortium having in mind the creation of protection profiles for
such equipment. Normally these equipments implement their own key manage-
ment protocols, which due to industrial concerns are not made publicly available
for scrutiny, making us reasoning about their true correctness. Another impor-
tant issue to the actual HSMs is their targeted development to the Bank industry
and not to PKI, making some important PKI issues, like, strict key usage control
and auditing, play a secondary role in the security context, normally making the
HSM just a digital safe where we trow our keys.
Key management life cycle has been studied by many researchers [3–5].
Menezes et al. [6] discuss the public key management in a general context, in-
cluding from user registration and initialization to key revocation.
However, protecting a private key in a CA context was always one of the
main concerns in any PKI deployment, and is discussed by Jeff Schiller [7]. He
states that protection schemes can be broken into two basic classes: schemes
where no human ever has access to the raw private key material and schemes
where a human may have access to the raw private key material. In the first,
the private key is stored in a hardware device which itself requires a hardware
token to operate. He advises that when a key is generated by this kind of devices,
special attention should take in account to deploy facilities to recover the key
from a failed unit.
Having an open protocol is an important matter when concerning to crypto-
graphic algorithms and to cryptographic protocols. This was stated by Auguste
Kerckhoffs[8] in the 19th century and by Claude Shanon[9] in 1948, and our
main concern when designing this protocol is the lack of access to the industry
owned protocols due to their intent to protect their copyrighted material. This
makes us always suspicious when using a so sensitive equipment like a HSM to
control keys for a Certification Authority in a PKI environment.
This work presents a cryptographic protocol to manage private keys. Our
focus is an open key life cycle protocol for public key infrastructure’s Hardware
Security Modules which will fit on Schiller’s first category. The proposed pro-
tocol was embedded in a hardware designed to be a HSM holding all physical
tampering countermeasures.

The paper is structured with this introduction section, followed by section 2,
where we present all the protocol basic ideas and concepts, as well as the premises
we assumed during the protocol development in subsection 2.1. Later on section 3
we present our sub-protocol for initialisation and creation of the administrator
group. In section 4 we present our sub-protocol for creation of the operators
groups, addressing the problem of no trust between the groups inside the pro-
posed HSM. Then in section 5 we present the sub-protocol for key generation
and assignment to an operator group, which is followed by section 6, where we
present the sub-protocol responsible to apply the concept of key policies and that
will allow the operators group to unwrap a key for usage. Finally in section 7
we address some implementation issues that arose in our work and detail our
prototyping environment. In section 8 we present our conclusions and propose
future work in the theme.
2 Protocols
To address the problems on key life cycle management, we need to answer some
questions on the key during all its life cycle. First, it is important to know who
is authorised to create a key. This means that only authorised users can create
keys and then delegate the use of the key to other user. In addition, we should
guarantee that the key is unique and was generated on a secure and controlled
environment, i.e., no one knows or has generated the same key pair before.
The system administrator can answer the former questions by using a certified
system. The singleness of the key can be achieved by using a true random number
generator and the key has always to be stored in the memory of such certified
system while not ciphered.
The precise time when the key is generated, used, or destroyed must be
logged. The way the key is released to use and when and how many times it was
used must be also subject of control and tracing.
To each key can be attributed a policy. The key, for instance, can be released
for n uses or for a period of time for an application. Other aspect to consider
is the control of how many operational copies there are for a key. As many
operational keys exists, much more difficult to manage the life cycle of each
copy of the key. Due to the additional difficulties introduced by a high number
of operational keys, is advisable to keep as low is possible these number. In some
practical situations, like a signature system, is common to keep only one key.
We will be presenting in this paper our proposal to address the problem of
private key management in public key infrastructures, specifically in the domain
of Hardware Security Modules. Our key ideas in the protocol development were
to work under a shared responsibility scheme, were all operations must be done
by groups instead of a single person, and they will have one symmetric key Ks
which will be used to encrypt the asymmetrical private key Kr material assigned
to them. This symmetric key will be shared between the group using a share
secret algorithm, like the one proposed by Shamir [10], allowing to reconstruct
the secret with a minimum number of parts specified at group creation. This

is an important operation in the OpenHSM protocol, on all its uses, because
by splitting the ownership of a key through a group, we increase the number
of people necessary to corrupt and to exploit to gain access to the key being
shared, increasing in this way the whole security of the system.
Another key feature we present in our protocol is the existence of an in-
ternal public key infrastructure, which will have a self-signed certificate issued
internally by the HSM that will constitute our trust point. From this certificate,
we construct a single certification authority to issue certificates to all people
involved in the operations of the proposed protocol. By controlling the access
to the private key of this internal CA we can limit administrative operations
in our protocol, chaining the administrative task to a successful secret share
reconstruction and a subsequent decryption of the private key tied with this
certificate.
This paper just take in count the four initial processes of the key manage-
ment scheme, that are the initialisation and creation of administrator group, the
creation of operators group, the application’s asymmetric key generation and
application’s asymmetric key usage. This is done this way due to limits on space
in the paper. We also give clues on other important facts to a complete key
management scheme, like the necessity of modifying the current groups, change
the ownership of an application key, do secure backups to the whole system and
enable an audit trail. Also because of space limitations we summarise all the
descriptions for principals, message parts/objects and operations in Appendix
A.
2.1 Premises
To design the proposed protocol we have established some premises as follow:
– each administrator ADMI and operator OPERI hold securely its private
keys, respectively KrADMI and KrOPERI ;
– random number generator works perfectly and true randomly as an internal
part of the principals generating cryptographic keys;
– NXD is a data storage that should be considered as any other, but its data
is flushed on a pre-established basis;
– data storages, like ADS, ODS, CRL, CTL, NXD and KDS, store data as
it was sent to them, no additional cryptography is used;
– the secret sharing scheme works perfectly;
– all data is securely deleted by a part that holds it when it knows that it will
not be used anymore in the current run of the protocol, and no data can be
kept to other runs of the protocol, except the data sent to those principals
acting as storage facilities;
– all certificates used in the protocols are checked against their CRLs and their
certificate path must be constructed with a certificate contained in CTL as
point of trust.
The premises above have the only purpose of delimitating and normally ad-
dress some implementation related problem that we must assume as solved when
considering the protocol.

3 Initialisation and Creation of Administrator Group
We start this process creating a system-wide administrator group by informing
two values to feed the shared secret scheme, N and M , where 1 ≤ N ≤ M
and they will denote the minimum number of principals in the group to acti-
vate it, and the size of the system-wide administrator group. Each individual
administrator must know the key pair and the personal information that will
compose its certificate that will be issued by the internal PKI in the HSM .
Finally, to initiate the protocol run, the HSM can generate in advance its key
pair KrHSM ,KuHSM and a symmetric key KsADM , all this initial knowledge
is described in Table 1.
Table 1. Principals Initial Knowledge
Principal Initial Knowledge
ADMI N,M,KrADMI ,KuADMI , ADMIDI
4
HSM KrHSM ,KuHSM ,KsHSM 4
3.1 Messages Exchange
The sub-protocol we propose to handle the initialisations, create the basic envi-
ronment to the key life cycle management, and create the administrator group
is as follows:
1. ADM −→ HSM : N,M
2. HSM −→ CTL : {|KuHSM |}KrHSM
3. ADMI −→ HSM : KuADMI , ADMIDI
4. HSM −→ ADMI : {|KuADMI |}KrHSM , {|KuHSM |}KrHSM
5. HSM −→ HSM : KsADM1 ||...||KsADMM
6. HSM −→ ADS : {KsADM1}KuADM1 ...{KsADMM }KuADMM ,
{|KuADM1 |}KrHSM ...{|KuADMM |}KrHSM ,
{KrHSM}KsADM
In the step 1, an administrator from the proposed set informs the HSM
his willing to initialise the process by sending N and M , that are respectively,
the minimum amount of administrators to reconstruct the shared secret used to
protect their session key and the size of the administrator group. In the transition
between step 1 and step 2, the HSM generates a key pair, named KrHSM and
KuHSM , and will generate a self-signed digital certificate in X509v3 format[11],
that will mark our point of trust. To establish the trust in this certificate, in the
step 2, the HSM will store this certificate in the CTL, that will be checked to
4 Not necessarily an initial knowledge. This knowledge can be generated during the
protocol run.

guarantee the validity of every principals certificate present in the subsequent
protocols runs.
After this initial trust establishment, every ADMI from the administrators
groups will interact with the HSM , by generating its own key pair KrADMI ,
KuADMI and sending KuADMI and ADMIDI to the HSM as is shown in step 3,
where ADMIDI is the identification needed to issue the ADMI user certificate.
By receiving KuADMI and ADMIDI the HSM , in step 4 will issue a certificate
{|KuADMI |}KrHSM with the information provided, and will send this certificate,
together with its own self-signed certificate {|KuHSM |}KrHSM to the adminis-
trator ADMI that will store them properly.
After interacting with all M administrators informed in step 1, the HSM will
run step 5, where it will generate randomly a session keyKsADM , and will split it
using the secret sharing scheme explained in the previous section 2. After having
KsADM shared, the HSM will encrypt every {KsADMI} with the public key
KuADMI extracted from the ADMI ’s certificate just generated, and will store all
M encrypted parts together with {KrHSM}KsADM in the Administrators Data
Storage (ADS), as show in step 6.
3.2 Key objectives of the Sub-Protocol
As this sub-protocol is meant to initialise the HSM, establish trust points, and to
create the administrators, we shall accomplish the following security objectives:
– never disclose KrHSM ;
– never disclose KsADM ;
– never disclose KsADMI ;
– never disclose KrADMI ;
The requirement of non disclosure of KrHSM exist because this private key
is used to establish all trust inside the HSM by signing all the certificates be-
longing to administrators, and self-signing the HSM certificate. KsADM should
never be disclosed because it is used to protect KrHSM on its storage form.
Any KsADMI should never be disclosed because by having N or more parts,
independently of order, can lead to the reconstruction of KsADM , what will
make KrHSM accessible. According to what was stated on previous sections,
KrADMI should never be disclosed during the protocol run, because this can
compromise KsADMI and subsequently all the rest of the security objectives of
the sub-protocol.
4 Creation of Operators Group
This operation will create the operators groups, which will be responsible to use
and retain the guard of the HSM managed keys. This process is started by
informing the K and L values, where 1 < K < L, by the administrator group,
respectively the minimum amount of operators needed to reconstruct the shared

secret, and the size of the operators group. The purpose of these secret sharing
operations is the same as explained in the earlier section 2.
Normally each operators group present inside our HSM implementation will
represent a Certification Authority private key being protected inside our cryp-
tographical perimeter. This feature was introduced to let a single HSM being
used independently inside the same PKI environment to represent CA in the
same or different levels in the hierarchy depending just on the policy established
by the PKI management team.
The creation of an operators group slightly differs from administrators group
creation, because it will not have a private key directly assigned to it (in this
first moment) and because of the existence of KsOPER∗, that is responsible for
trace when the group is valid for administrative operations.
This is necessary because we do not want to establish trust between the
administrator group and any of the operators group. When KsOPER∗ is deleted
for some operator group, no administrative task can be done to this group until
the recovery of KsOPER∗. This scheme is possible by the use of XOR properties,
and will be also important in the future to define traceability of operational
copies in the case of backups of the HSM contents.
To initialise a run of this sub-protocol, we should have some initial knowledge
by each player, and this is described in Table 2. Each ADMI should know its
key pair KrADMI ,KuADMI , as well as the HSM certificate KrADMI ,KuADMI .
The administrator group should know in advance the values of OPERID,K
and L, that will be the group identification, the threshold of the secret sharing
reconstruction and the size of the operators group being created respectively.
The HSM should be able to generate during the run the values of KsOPER,
KsOPER∗ and at least N nonce NI to securely authenticate the administrator
group.
Table 2. Principals Initial Knowledge
Principal Initial Knowledge
ADMI OPERID,K, L,KrADMI ,KuADMI , {|KuHSM |}KrHSM
HSM KsOPER,KsOPER∗, NI4
OPERI KrOPERI ,KuOPERI , OPERIDI
4
CTL {|KuHSM |}KrHSM
ADS {KsADM1}KuADM1 ...{KsADMM }KuADMM , {KrHSM}KsADM ,
{|KuADM1 |}KrHSM ...{|KuADMM |}KrHSM
Each operator OPERI should know in advance its own key pair KrOPERI ,
KuOPERI and its personal data OPERIDI that will be used to issue its certifi-
cates. The principals CTL and ADS should be able to provide the data necessary
to correctly authenticate the administrators group

4.1 Messages Exchange
The sub-protocol we propose to handle the creation of operators groups is the
following:
1. ADM −→ HSM : K,L,OPERID
2. ADS −→ HSM : {KsADM1}KuADM1 ...{KsADMM }KuADMM ,
{KrHSM}KsADM , {|KuADM1 |}KrHSM ...{|KuADMM |}KrHSM
3. HSM −→ ADMI : {{KsADMI}KuADMI , NI}KuADMI
4. ADMI −→ HSM : {KsADMI}NI
5. HSM −→ HSM : KsADM1 ||...||KsADMN
6. HSM −→ NXD : KsOPER∗
7. CTL −→ HSM : {|KuHSM |}KrHSM
8. HSM −→ ODS : {KsOPER ⊕KsOPER∗}KuHSM
9. HSM −→ HSM : KsOPER1 ||...||KsOPERL
10. OPERI −→ HSM : KuOPERI , OPERIDI
11. HSM −→ OPERI : {|KuOPERI |}KrHSM , {|KuHSM |}KrHSM
12. HSM −→ ODS : {KsOPER1}KuOPER1 ...{KsOPERL}KuOPERL ,
{|KuOPER1 |}KrHSM ...{|KuOPERL |}KrHSM
This process is started with the administrator group informing the HSM an
operator group identification OPERID and the values of K and L in the step 1.
K and L values are respectively, the minimum amount of operators to reconstruct
the shared secret used to protect their keys and the size of the operators group,
and OPERID is a unique identification for the operators group being created.
As we consider this is an administrative operation, we must have administrative
authorisation. To start this process, in step 2 the ADS sends to the HSM the
values {KsADM1}KuADM1 ...{KsADMM }KuADMM and {KrHSM}KsADM , that is
all KsADMI ciphered with the KuADMI , plus KrHSM ciphered with KsADM .
Following the step 3, the HSM will send to each ADMI in the administrator
group, its ciphered part {KsADMI}KuADMI to deciphering, plus {NI}KuADMI ,
that is a freshly generated nonce ciphered with the ADMI public key extracted
from the certificates already sent from ADS. This is done due to two reasons.
First we want to avoid replay attacks in the messages sent by the ADM
back to the HSM . Second, we need a shared value to cipher KsADMI sent in
step 4 back from ADM to HSM , because this communication normally flows
outside the cryptographic barrier of the HSM , and the collection of N part of
KsADMI can lead to the reconstruction of KsADM . Note that we double cipher
the value of {KsADMI}KuADMI to avoid the capabilities of a Dolev-Yao attacker
[12] in reconstructing messages to replay. After doing this process with at least N
administrators, the HSM is able to reconstruct KsADM as shown in step 5 and
consequently decipher KrHSM , accomplishing the administrators authentication
and enabling the protocol to continue.
Following the protocol, the HSM will generate two symmetric encryption
keys, one KsOPER that will be used to cipher every key belonging to the group
being created, and KsOPER∗, that is a key to enable administrative operations
on the operators group and will be the base for the separation of trust between

the groups. The key KsOPER∗, is stored in the NXD as shown in step 6 to
enable administrative operations on the group for a while. In step 7, the CTL
sends to the HSM the value {|KuHSM |}KrHSM that is the self-signed certificate
of the HSM . This is done because we will need to cipher the result of the
XOR operation between KsOPER and KsOPER∗ with the public key that is
on this certificate. This will tie any subsequent operation on the groups with
deciphering KrHSM , that means an administrative authentication. The value of
{KsOPER⊕KsOPER∗}KuHSM is stored in the Operators Data Storage ODS in
step 8.
After this binding to administrative task when dealing with the operator
group, we need to share KsOPER to the L operators belonging to this operator
group. This task is very similar with what we have done when sharing KsADM to
the ADM group in section 3. In step 9 the HSM splits KsOPER in L parts, then
in step 10, each operator will inform to the HSM is own public key KuOPERI
and OPERIDI that is all the identification needed to issue the operators X509v3
certificate {|KuOPERI |}KrHSM . In step 11, the HSM sends the operators cer-
tificate, plus the HSM certificate to each operator OPERI with the message
{|KuOPERI |}KrHSM , {|KuHSM |}KrHSM .
Finally, the HSM will use the public keys present in each certificate issued to
the L administrator and will cipher all the L values KsOPERI parts with it and
send them to ODS together will all operators certificates {|KuOPER1 |}KrHSM ...
{|KuOPERL |}KrHSM , accordingly with step 12.
4.2 Key objectives of the Sub-Protocol
As this sub-protocol is meant to create the operators group, that are the groups
responsible to use the keys managed by the HSM, and taking in consideration
that there is no complete trust between any groups inside the HSM, we should
accomplish the following security objectives:
– never disclose KsOPER;
– never disclose KsADM ;
– never disclose KrHSM ;
– never disclose KsADMI ;
– never disclose KrADMI ;
– never disclose KrOPERI ;
– never disclose KsOPERI ;
– never disclose {KsOPER ⊕KsOPER∗};
As we have access to KrHSM , we have the same chain of objectives as stated
in section 3, so we must protect KsADM , KsADMI and KrADMI from disclosure.
The additional security objectives we must consider now are the non disclosure
KsOPER that is the symmetric key that will cipher all the keys belonging to the
group being created The non disclosure on KsOPERI , because with a K amount
of them we can reconstruct KsOPER, and we shall not disclose any operator
private key KrOPERI . Finally we also must protect {KsOPER ⊕ KsOPER∗},

because by knowing that this is a XOR compound value, an attacker can access
KsOPER∗ from NXD and use it with {KsOPER⊕KsOPER∗} to obtain KsOPER,
that is an already specified security objective.
5 Application’s Asymmetric Key Generation
This sub-protocol explain how to create the HSM managed keys. We consider
this an administrative process, however, there should exist the operators group
to which this key will be delegate and this administrative operation must be
authorised by the operator group with the explicit existence of KsOPER∗ in the
NXD.
The administrators are able to recover the operators group secret using
KsOPER∗ key from NXD and {KsOPER⊕KsOPER∗}KuHSM from ODS. When
the administrators are authenticated, they recover KsADM key. Using it, they
are able to load {KrHSM}KsADM from ADS and after they can decrypt the
XOR operation result. Now, using the reversible propriety of XOR operation,
the administrator group can recover the operators key applying {KsOPER ⊕
KsOPER∗} ⊕KsOPER∗. Becoming the operators key KsOPER known.
Other particularly in this sub-protocol is the KEY PARAM . It will specify
the key properties, like algorithm and size. For example, it could be a 1024 bits
RSA key pair.
The table 3 show a summary about the necessary things to execute this
sub-protocol.
Table 3. Principals Initial Knowledge
Principal Initial Knowledge
ADMI OPERID,KEY ID,KEY PARAM,KrADMI ,KuADMI ,
{|KuHSM |}KrHSM
HSM KrAPP ,KUAPP , NI4
NXD KsOPER∗
ADS {KsADM1}KuADM1 ...{KsADMM }KuADMM , {KrHSM}KsADM
ODS {KsOPER ⊕KsOPER∗}KuHSM
The administrator group must know in advance OPERID, KEY ID and
KEY PARAM , that are the operator group identification to which the keys will
be delegated, and identification for the keys being generated, and the parameters
for the key generation process respectively. Each ADMI Must know its own key
pair, and the HSM must be able to generate the key pair KrAPP ,KUAPP and
at least N nonce NI to securely authenticate the administrators.
TheNXD must have storedKsOPER∗ for the group to which the keys will be
delegated, showing with this that the operator group was aware of this adminis-
trative operation. ADS must have all authentication data for the administrator
group stored in it, and ODS must have all authentication data for the operator
group informed in OPERID.

5.1 Messages Exchange
The sub-protocol which creates a new HSM managed key is described below:
1. ADM −→ HSM : KEY NAME,KEY PARAM,OPERID
2. ADS −→ HSM : {KsADM1}KuADM1 ...{KsADMM }KuADMM ,
{KrHSM}KsADM
3. HSM −→ ADMI : {{KsADMI}KuADMI , NI}KuADMI
4. ADMI −→ HSM : {KsADMI}NI
5. HSM −→ HSM : KsADM1 ||...||KsADMN
6. ODS −→ HSM : {KsOPER ⊕KsOPER∗}KuHSM
7. NXD −→ HSM : KsOPER∗
8. HSM −→ HSM : KsOPER5
9. HSM −→ OUT : KuAPP
10. HSM −→ KDS : {KrAPP }KsOPER ,KuAPP ,KEY NAME,OPERID
This process is started with the administrator group informing the HSM
the identifier of the new key KEY NAME, the key generation parameters
KEY PARAM and the operator group identifier OPERID (this group must
be created before), as shown in the step 1. We set this as an administrative
operation, so the administrator group must be validated. The validation is made
in the steps 2, 3 and 4, where the ADS load to the HSM the data necessary to
the authentication process. Thus, the HSM sends to each ADMI its ciphered
part {KsADMI}KuADMI , plus a ciphered nonce {NI}KuADMI , and each ADMI
send back to the HSM your part ciphered with the nonce the HSM send in the
previous step. Finally the administrator secret can be recovered in the 5 when it
has more than N deciphered parts of KsADM . This validation has been shown
in the previous section 4.
Following the protocol, in step 6, the ODS will send to the HSM the result
of the XOR operation done when creating the operators group, ciphered with
KuHSM . In the next step, 7, the NXD will send the HSM the authorisation
value KsOPER∗, that will be used by the HSM to XOR with {KsOPER ⊕
KsOPER∗} and obtain KsOPER, as shown in step 8.
Between the steps 8 and 9, the application key pair subject to the HSM
protection is generated, then the public key is exported in the step 9. In step 10,
all necessary information regarding the key is stored into the Key Data Storage
KDS including the operators group identifierOPERID, key nameKEY NAME,
public key and encrypted private key {KrAPP }KsOPER ,KuAPP . The operators
group will use this information to allow the recovery of the key.
5.2 Key objectives of the Protocol
The main objectives in this protocol are to securely generate a key pair and
delegate its usage and management to an operator group, so the main security
objectives are:
5 This is recovered by applying the XOR properties in the {KsOPER ⊕KsOPER∗}

– never disclose KsOPER;
– never disclose KsADM ;
– never disclose KrHSM ;
– never disclose KrAPP ;
– never disclose KrADMI ;
– never disclose KsADMI ;
– never disclose {KsOPER ⊕KsOPER∗};
As we consider this an administrative operation, we must have administrative
authorisation to do so. By doing this way we have the same security requirements
as other previous sub-protocols, that are the non disclosure of KrHSM our trust
root, KsADM its ciphering key, and KrADMI and KsADMI that are the secrets
that protect KsADM in its shared form.
Additionally, as we deal with the operator group, by doing and administrative
operation in its name, we must have access to {KsOPER ⊕ KsOPER∗}, that
when XORed with KsOPER∗ gives us KsOPER. They are security objectives,
because they will protect KrAPP , our main security goal, and mean of existence.
KsOPER is important because it will cipher KrAPP , and {KsOPER⊕KsOPER∗}
is important because with it we can derive easily KsOPER.
6 Application’s Asymmetric Key Usage
This sub-protocol will cover the managed keys usage. This usage does not rep-
resent specifically to sign or encrypt something with the key. It will load the
key and apply the specified policy on its. The operations of signing or ciphering
something with the private key subject to protection is no in the scope of this
protocol, and should be treated as HSM API.
The policy, represented by KEY POL, will specify restrictions on loaded
keys. The operators group can set a maximum number of operations using the
key for signatures or encryptions and/or set a range of time for the key remain
loaded. For example, the key can be loaded for three uses and five minutes. The
first policy reach will unload the key automatically and this sub-protocol must
be executed again to load the key for a next usage.
In the table 4, we can see the items which must be initial knowledge. Basically,
the system must be initialised, the administrators, at least one operators group
must have been created and one key must also have been created.
Table 4. Principals Initial Knowledge
Principal Initial Knowledge
OPERI KEY ID,KEY POL,KrOPERI ,KuOPERI , {|KuHSM |}KrHSM
ODS {KsOPER1}KuOPER1 ...{KsOPERL}KuOPERL ,
{|KuOPER1 |}KrHSM ...{|KuOPERL |}KrHSM
KDS {KrAPP }KsOPER ,KuAPP , OPERID
HSM NI

6.1 Messages Exchange
1. OPER −→ HSM : KEY ID,KEY POL
2. KDS −→ HSM : {KrAPP }KsOPER ,KuAPP , OPERID
3. ODS −→ HSM : {KsOPER1}KuOPER1 ...{KsOPERL}KuOPERL ,
{|KuOPER1 |}KrHSM ...{|KuOPERL |}KrHSM
4. HSM −→ OPERI : {{KsOPERI}KuOPERI , NI}KuOPERI
5. OPERI −→ HSM : {KsOPERI}NI
6. HSM −→ HSM : KsOPER1 ||...||KsOPERK
7. HSM −→ HSM : KrAPP ,KEY POL
The process starts, in the step 1, when the operators group send the command
to load the key including the identification KEY ID and a policy KEY POL
for it. This is not an administrative operation, but it is necessary to validate
the operators group, as they are the effective owners of the key subject to the
HSM protection. The operator group to which the key belong is known be-
cause it is loaded from KDS in step 2,together with they ciphered private key
{KrAPP }KsOPER and its public part KuAPP . The validation of the operators
group will follow the same mechanism followed by the administrator group au-
thentication in other sub-protocols.
First, in step 3 ODS will send all data necessary to authenticate the opera-
tor group, that is all ciphered parts {KsOPER1}KuOPER1 ...{KsOPERL}KuOPERL ,
and the operators certificates {|KuOPER1 |}KrHSM ...{|KuOPERL |}KrHSM . In step
4, theHSM will send each operatorOPERI it ciphered part {KsOPERI}KuOPERI ,
plus a freshly generated nonce ciphered with its public key {NI}KuOPERI . Fol-
lowing, each operator OPERI will send to the HSM its part of the shared secret
ciphered with the nonce {KsOPERI}NI , as described in step 5.
After collecting K parts deciphered by the administrator, the HSM will be
allowed to recover KsOPER as shown in step 6, by the reconstruction of the
shared secret. Finally, the policy KEY POL is applied in the step 7 and the
key is loaded, being ready for its usage.
6.2 Key objectives of the Protocol
The main objectives in this protocol were to securely load a key pair by an
operator group following a policy, so the main security objectives are:
– never disclose KsOPER;
– never disclose KsOPERI ;
– never disclose KrAPP ;
– never disclose KrOPERI ;
As this operation must just have authorisation from operators group, the
authorisation must never have disclosure of KsOPER, the operators group secret
and the key that is used to encrypt the managed keys. KrOPERI and KsOPERI
that are the secrets that protect KsOPER in its shared form.
Additionally, as the main objective of HSM, we must never have disclosure
of KrAPP . It must be used just under authorisation and respecting the policy.

7 Implementation Issues
Although we create and manage keys, we do not plan any protocol for key
destruction or deletion, because this could be simply accomplished by removing
the ciphered parts from KDS, but this is not always that simple and sometimes
extremely difficult to achieve. Normally this is covered by the PKI policies, what
tend to the destruction of all private key material by physical means, like the
incineration of the HSM itself and everything that could have had contact with
these key material.
Other thing that is not covered in the protocol, is the operators group de-
struction, but this is easily achievable just by destroying X operators privates
keys, where X > N . This will also render all keys that belonged to the operators
groups set being destroyed unusable, as long the NXD part of the group is not
available for administrative matters.
7.1 Prototype
The embedded application was developed in C language and involved many
technologies, including smart card support, cryptography, data storage, secret
sharing and X509v3 certificates. To solve these technology gaps we used known
open/free libraries, such: OpenSSL - for cryptographic operations and X509
certificate support, SQLite - a lite database with focus in embedded systems,
OpenSC - smart card support, SharedSecret - for sharing secrets and PCSC-
LITE - supporting smart card readers and tokens, everything integrated with a
FreeBSD system running with embedded customisations we developed.
The hardware was projected to be tamper proof system using a Security
Unit(S.U.) to manage all sensors and protection systems, including a Random
Number Generation, a separate Clock and a true eraser circuit. The key manager
software was integrated using a library to manage the configuration of the S.U.
and used a pipe system to receive a problem detection message from the S.U.
8 Conclusions
This work presented a cryptographic protocol to manage private keys in a Cer-
tification Authority context, i.e., an application that can be embedded in a
Hardware Security Module. It is known the security of a PKI is related to how
the keys are generated, used and destroyed. Thus, our protocol was conceived
to have a strong control of the keys, a requirement in PKI solutions. The proto-
col was itself built on an internal PKI, i.e., we have designed a PKI to manage
private keys of external Certification Authorities.
To manage the HSM, it was created groups. The administrator group is re-
sponsible to create new application keys and the operator groups. The latter
group is bound to the private keys of the applications, like a certification au-
thority.

The protocol was coded and embedded in a prototype HSM. The implemen-
tation has shown that it is comfortable and secure to manage private keys to
Certification Authorities. It also showed that we can use this strict key controls
to debug CA software. As future work it is intended to extend the protocol pre-
sented by including a backup feature and auditing system. We also propose to
do formal analysis on the protocol.
References
1. FIPS: Security requirements for cryptographic modules, FIPS PUB 140-2 (2002)
2. Killmann, W., Leitold, H., Posch, R., Salle´, P.: Protection profile - secure signature-
creation device type 3. http://www.commoncriteriaportal.org
/public/files/ppfiles/pp0006b.pdf (July 2001)
3. Barker, E., Barker, W., Burr, W., Polk, W., Smid, M.: Recommendation for key
management part 1: General. Technical Report 800-57, NIST (May 2006) NIST
Special Publication.
4. Neumann, P.G.: Crypto key management. Commun. ACM 40(8) (1997) 136
5. Daemen, J.: Management of secret keys: Dynamic key handling. In Preneel, B.,
Rijmen, V., eds.: State of the Art in Applied Cryptography. Volume 1528 of Lecture
Notes in Computer Science., Springer (1997) 264–276
6. Menezes, A.J., Vanstone, S.A., Oorschot, P.C.V.: Handbook of Applied Cryptog-
raphy. CRC Press, Inc., Boca Raton, FL, USA (1996)
7. Schiller, J.: Protecting a private key in a ca context (2000) A useful discussion of
the issues and patterns.
8. Kerckhoffs, A.: La cryptographie militaire. Journal des sciences militaires IX
(1883) 5–38
9. Shannon, C.E.: A mathematical theory of communication. Bell System Technical
Journal 27 (1948) 379423
10. Shamir, A.: How to share a secret. Commun. ACM 22(11) (1979) 612–613
11. X.509, I.T.R.: Information technology - open systems interconnection - the direc-
tory: Authentication framework. Technical report, ITU-T (1997)
12. Dolev, D., Yao, A.C.: On the security of public key protocols. IEEE Transactions
on Information Theory 29(2) (1983) 198–208
Appendix A: Conventions
The protocols are subject to conventions in Table 5, Table 6 and Table 7.
Table 5. Description of all Operations Used in the Protocols
Operation Description
{} Data inside brackets is ciphered by subscript key outside brackets.
{||} Data inside piped brackets is signed by subscript key outside brackets.
|| Data is concatenated or dissociated using a secret sharing scheme.
{⊕} Data inside brackets is logically XOR-ed and the result becomes 1 single
object.

Table 6. Description of all Principals of the Protocols
Principal Description
ADMI An administrator of the HSM
HSM The HSM Crypto-Processor
CTL Certificate Trust List
ADS Administrator Data Storage
OPERI An operator of the HSM
NXD Non Exportable and Temporary Data Storage
ODS Operator Data Storage
OUT External output of HSM.
KDS Key Data Storage
CRL Certificate Revocation List.
Table 7. Description of all Objects and Message Parts of the Protocols
Message Description
M Size of the administrators group.
N Minimum amount of administrators to reconstruct a shared secret.
I Any principal part of a group.
KrHSM Private key of the HSM.
KuHSM Public key of the HSM.
KrADMI Private key of one Administrator.
KuADMI Public key of one Administrator.
ADMI Identification for one Administrator.
KsADM Symmetric key used for ciphering KrHSM .
KsADMI Shared part of KsADM belonging to one Administrator.
NI A random value just used once (Nonce).
K Size of the operators group.
L Minimum amount of operators to reconstruct a shared secret.
OPERID Identifier of a operators group.
KrOPERI Private key of one operator.
KuOPERI Public key of one operator.
OPERIDI Identification for one operator.
KsOPER Symmetric key for ciphering private keys owned by operators group.
KsOPERI Shared part of KsOPER belonging to one Operator.
KsOPER∗ Non exportable and temporary operand that enables administrative
operations to an operator group.
KEY ID Identifier for the key being generated or being used.
KEY PARAM Parameters for the key being generated.
KrAPP Application protected private key.
KuAPP Public key related with KrAPP .
KEY POL Policies for a key being used.