A brief comparison of AS2805 and (TR-31) Key Blocks

Recently PCI-SSC released PCI industry standards and clarifying.FAQ’s mandating that encryption keys should be managed in structures called Key Blocks. Key Blocks are defined in the ANSI TR-31 Technical Report and ISO 20038 Standard. Similarly, there are concerns about the use of key variants in some regions. Late in 2019 PCI-SSC also published a process of obtaining “equivalency” with Key Blocks. Requirements 18-3 in the PCI-PIN Standard captures this neatly:


18-3 Encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods.

The phased implementation dates are as follows:

  • Phase 1 – Implement Key Blocks for internal connections and key storage within Service Provider Environments – this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019.
  • Phase 2 – Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 June 2021.
  • Phase 3 – Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices and ATMs. Effective date: 1 June 2023. Acceptable methods of implementing the integrity requirements include, but are not limited to:
  • A MAC computed over the concatenation of the clear-text attributes and the enciphered portion of the key block, which includes the key itself,
  • A digital signature computed over that same data,
  • An integrity check that is an implicit part of the key-encryption process such as that which is used in the AES key-wrap process specified in ANSI X9.102.

Changing key management schemes is obviously a big program of work for both terminal manufacturers and acquirers, especially for countries whose entire local debit system is based on variants and do not use Key Blocks. This would certainly have catastrophic consequences. We could possibly see local debit systems, like EFTPOS in Australia,  being excluded from transaction processing. That is unless they comply with this requirement. We have to keep in mind that PCI creates industry standards,  applied in various regions. Some regions use fixed keys, don’t implement dynamic key exchange models and rely on the expertise of PCI and their industry standards. However, some regions like Australia created dynamic key exchange standards, like in AS2805, and enforced these standards, though the Payments System Self Regulator, Australian Payments Network (APCA). PCI has recognized the potential issue for excluding players in the payments ecosystem and has created a process for defining “equivalency” against Key Blocks. I will attempt to answer three questions in this blog:

  1. What is equivalent to Key Blocks?
  2. Why are variants so insecure.
  3. Australian Standards (AS2805) use variants?

Before we start, I have to clarify a few points:

  1. The Payment Card Industry Security Standards Council (PCI-SSC) is not a standards body. PCI-SSC is a commercial company wholly owned by the card schemes (Mastercard, Visa, Amex and others). Participation in PCI-SSC is not open to industry players, all industry standards published at PCI are approved by the management members of the card schemes who may change standards as they see fit. Only card scheme participants have voting rights, and the standard consensus is conducted under a non-collusion policy.  The PCI-SSC publish industry standards but do not enforce them. Card Schemes enforce PCI Standards and may wave requirements as they see fit.
  2. AS2805 -Australian Standards is a standards-setting body, and its participants sit on international standard bodies, ISO/IEC. Participation in Australian Standards is open to industry participants. Standards are published by participant consensus. AS2805 standards are enforced by the Australian Payments Network and implemented by all Acquirers and Issuers in Australia. Other regions use AS2805, such as New Zealand, Fiji, and others. AusPayNet does not wave any security requirements and run a compliance program to monitor Acquirers and Issuers.

What is equivalent to Key Blocks?

In January 2020 PCI-SSC released an FAQ to clarify the process of determining equivalency against Key blocks. This is captured by Q26:


Equivalent methods must be subject to an independent expert review and said review is publicly available:

▪ The review by the independent expert must include proof that in the equivalent method the encrypted key and its attributes in the Key Block have integrity protection such that it is computationally infeasible for the key to be used if the key or its attributes have been modified. The modification includes, but is not limited to:

o Changing or replacing any bit(s) in the attributes or encrypted key

o Interchanging any bits of the protected Key Block with bits from another part of the block

  • The independent expert must be qualified via a combination of education, training and experience in cryptology to provide objective technical evaluations that are independent of any ties to vendors and special interests. Independent expert is further defined below.
  • The PTS laboratory will validate that any device vendors implementing this methodology have done so following all guidelines of said evaluation and peer review, including any recommendations for associated key management.

An Independent Expert possesses the following qualifications:

  • Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA, CES, or GCHQ) and
  • ▪  Has ten or more years of experience in the relevant subject and
  • ▪  Has published at least two articles in peer-reviewed publications on the relevant subject or
  • ▪  Is recognized by his/her peers in the field (e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body, e.g., ACM, BCS, IEEE, IET, IACR) and

Subscribes to an ethical code of conduct and would be subject to an ethics compliance process if warranted. Independence requires that the entity is not subject to control, restriction, modification, or limitation from a given outside source. Specifically, independence requires that a person, firm or corporation who holds itself out for employment as a cryptologist or similar expert to more than one client company is not a regular employee of that company, does not work exclusively for one company and were paid, is paid in each case assigned for time consumed and expenses incurred.


Let me first note the first paragraph in the TR-31 Standard:

From the introduction, “The retail financial transactions industry has in the past lacked an interoperable method for secure key exchange. While this has always been an issue, the move from Single DES to Triple DEA (TDEA) encryption made this issue more acute, as methods for the secure exchange of TDEA keys are non-obvious. This Technical Report is intended to give the reader an implementation that meets the requirements for secure key management as set forth in ANS X9.24 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques.”


And Later in the standard, we see:


“This document is not a security standard and is not intended to establish security requirements. It is intended instead to provide an interoperable method of implementing security requirements and policies.”


It would appear that equivalency is confused with interoperability. If the intention of Key Blocks is to provide a global interoperable method then it would certainly foster innovation and remove regional boundaries. The PCI FAQ sadly does not reflect this, instead, it cites security concerns with no proof.  Yet, we should prove cryptographic schemes are “equivalent” to an interoperability standard. Does this sound fair? Additionally, the TR-31 scheme is a technical report, far from a security standard, however, I believe that ANSI is working on a formal TR-31 Standard probably due to increased pressure from PCI. The TR-31 Standards also say that the patent holder will provide a license to use the scheme for a reasonable fee. Who is this license holder? Where should we buy this license if we are to comply? Let us see if AS2805 is equivalent to Key Blocks. To prove equivalency we need three things:

  1. Message Integrity, a MAC computed on the key and its attributes or a digital signature.
  2. The purpose of the key bounded to the key itself, such that the MAC will fail if the attributes are modified.
  3. A mode of operation that prevents bit interchangement, such as CBC or GCM.

So let’s review TR-31 Key Blocks. Focusing on key generation, a system would generate a Key Block Protection Key (KBPK), and then derive a Key Block Encryption Key (KBEK) and a Key Block Authentication Key (KBAK). If one wants to protect a key in the payments system, you first need to define the purpose of the key and additional header information. The key is then encrypted, and a MAC is computed over the key and its clear text attributes. These operations occur in an HSM or payment terminal. If a system (like an HSM or a Terminal) wants to use the key they would verify the MAC, then ensure the purpose of the key matches the operation being performed. This sounds simple. Any system that implements Key Blocks would be able to use the key effectively systems would be interoperable. Based on the equivalency requirements we can see that the MAC provides integrity protection and the clear text attributes specify the key attributes and will fail if the attributes are modified. The mode of operation is implicit in the key protection mechanism.

In AS2805, we apply a MAC on every transaction message binding all transaction attributes to the key usage. The key purpose of the key is enforced by applying a purpose bit to the encryption key by a xor operation. This operation binds the key with its purpose. The AS2805 Standards refer to this as a “variant bit”. AS2805 enforces the use of CBC mode of operation for all symmetric encryption.

So let’s review the equivalence requirements:

  1. MAC – Keys have integrity protection in transaction messages.
  2. Key Purpose is enforced by a key purpose bit applied to the key.
  3. AS2805 enforces the use of CBC mode of operation.

The only place where there is a mismatch between AS2805 and TR-31 is in host stored keys. AS2805 does not enforce integrity on stored keys, this is largely left to vendors and their HSM implementations. Thales HSM’s only use host stored keys, while Gemalto HSM’s store keys inside the HSM, which is accessible via indexes. Gemalto Payments HSM’s enforce integrity protection for HSM stored keys, while this may be implemented by a Thales host function.

What does this mean? does the absence of a MAC  in host stored keys make the system vulnerable? Can you change the purpose of a key? Well Yes, if you have access to it.

For a host stored key K encrypted under the LMK P, with a purpose-bit B \oplus (K_P) where B is the PIN Encryption purpose-bit.  We can change the purpose if we have Data Decryption purpose-bit D . To do this we apply ( B \oplus(K_P)) \oplus B = K_P  to cancel out the applied purpose-bit, then apply (D \oplus K_P) to change the purpose. If the key is used as input to a data decryption function we could decrypt PIN data. Effectively we compute (B \oplus (K_P) \oplus B) \oplus D = D(K_P) The problem with this attack is the fact that an attacker would need access to the HSM where the LMK P is loaded and have access to run arbitrary functions. Dual control requirements are certainly a set of controls that could mitigate this, but what else can be done. We see in Thales that host stored keys are encrypted using the Local Master Key (LMK), we could have an additional LMK which we could use to generate MAC’s and store the MAC with host stored keys and validate the MAC on each key before executing an HSM function. This method would, in fact, invalidate the attack and make key storage equivalent to the Key Block mechanisms. In the meantime, this attack to repurpose keys is possible and well known.

The question remains: Is AS2805 equivalent to Key Blocks? I would say NO, the same protections are applied to keys in transit, but not in storage. An attacker can change the purpose of the keys but would have great difficulty using them.  But the important question is: Is it interoperable? Well, that’s a big NO. Once Key Blocks are enabled on an HSM, variants are not able to run. (in Thales) In Gemalto HSMs variant and key blocks are handled by two different MFKs and translating between them is not allowed. If the LMK is in key blocks then ALL. keys are in Key Blocks. This in effect means that an organisation who need to run both Key Blocks and non-key blocks need duplicate systems. The AS2805 key scheme is, however, interoperable in Australia where all participants use the same key management standard. Anyone running Key Blocks cannot transact in Australia. The Australian key scheme pre-dates PCI-SSC and we have not seen a breach of the cryptographical standards since the inception. Even though this attack is well known. Card Systems in Australia has some of the lowest fraud rates in the world. I do however have to note that the use of 3DES is drawing to a close, as the usage should not continue after 2030 (as per ISO). Australian Standards and industry partners are working on defining the use of AES cryptography in payments and have recently adopted AS 20038 Key Blocks as part of their program of work. We would certainly see industry movements to adopt a new key management scheme where changing a key purpose is infeasible.

Why are variants so insecure.

A key variant is a public mechanism to compute encryption keys from a master key. This process is reversible. i.e. if an attacker knows a key, he can compute other variants of the key. Additionally, if he knows the variants then he can change the applied variant. We see that DUKPT use variants to compute future keys derived from an IPEK and additional information. The additional information is normally private and not subject to the same attacks. Many organizations advocate the depreciation of variants because of the reversibility, and rightly so. Any key scheme that breaks both forward and backward security is not a good key scheme. This brings me to my final question.

Do Australian Standards (AS2805) use variants?

Everywhere in the AS2805 series, variants are mentioned, but is this really variants? The AS2805.5.4 Standard use “variants” to calculate master keys, but if you inspect this closely you would see that the method of calculation is, in fact, one-way for KEK keys only. The one-way function is a non-reversible method of merging a key and data to produce an output of the same length, where all of the output data depends on the input data. Even if the output and parts of the input variables, key or data, are known it remains infeasible to. reconstruct the remainder of the inputs except by exhaustion.

So to answer the heading: Australia does not use variants? YES, confused? Australia uses variant bits applied to keys to derive keys for different purposes, KEK keys are generated by a non-reversible method, called a one-way function (OWF). Session keys that protect data and PIN blocks are in fact variants.

The key purpose-bit used to restrict encryption keys are normally referred to as key variants. This is because a key may have multiple variants. i.e. if a key is used for data encryption we apply one variant and MAC calculation another variant. The reference to the variants and OWF is certainly confusing, especially for individuals and organizations who are not familiar with the Australian Key Scheme. I hope there would be a push to remove “variants” from the Australian Standards and replace it with “non-reversible key calculation” or random keys.

In Closing

Changing a key purpose have been a problem since the inception of cryptographic standards in Australia, but due to the strong compliance programs run by Payments self Regulators, there has not been a single attack. The eHub and local debit systems all use the same AS2805 cryptographical standard. Moving all systems to key blocks would be a billion-dollar industry project, as it may require new infrastructure and running duplicate systems while maintaining interoperability with existing networks. This is certainly a long term project, with broad stakeholder participation. In the meantime, strict key management controls, dynamic key exchange models and strong self-regulation have mitigated any attacks on the Australian Card Payment Systems. So the question is: Should Australia move to key blocks and AES? If I can put it simply, Yes.

I have written an acedemic paper on this topic showing that there is no ‘equivelency’ between TR-31 and AS 2805.

Security in banking – preprint

Hopefully, it will be published in a journal soon..

This article is my opinion and does not reflect the position of any industry regulator or standards body.

Easy as pie.

From Bi-Linear Maps to Searchable Encryption

Pairings-Based Cryptography

Introduction

Theoretical research into pairings-based cryptography has been a well-researched area over the last few years, this cryptography scheme is based on the mapping of two cryptographical groups which allows for a new cryptographical scheme based on a trapdoor permutation between the groups with some interesting complexity properties.

These two groups are called a Gap Groups in many instances, where the Decisional Diffie-Helman problem is easy, but the Computational Diffie-Helman still is hard to solve. Weil and Tate pairings are used in implementations but requires complex mathematics, this is why in this section we will use a slightly more abstract means to explain bilinear maps..

Bilinear Maps

Mostly all constructions of pairings-based cryptosystems use bilinear maps, for this we consider two groups G_1 and G_2 or a prime order q. We can denote G_1 using additive notation and G_2 using multiplicative notation, even as the group operations of G_1 and G_2 are very different, G_1 can also be written as a multiplicative group operation in some literature.

If we consider two generators of group G_1 as \ P and Q, we can write:

aP\ =\ P+P+\ ..P\ \}\ a times

Using this we can also consider a map e as follows: {e:\ G}_1\ \times G_1\ \to \ \ G_2

This type of bilinear map has a main group G_1 and a shadow group G_2 where we map two group elements in the first group to the second group would need have properties between them in order for it to be useful,  Bilinearity, non-degenerate and computable.

Bilinearity:

For Group G_1 using generators P and \ Q we can define a map to G_2, where the additive operation in group G_1 equals the multiplicative operation in G_2:

\forall P,\ Q\in G_1, \forall a,\ b\ \in {\mathbb{Z}}^*_q,
Map:e\left(aP,\ bQ\right)=e(P,\ Q)^{ab}

If G1 and G2 where both multiplicative groups then the Bilinearity property would be the following:

  • \forall P,\ Q\in G_1,\ \forall a,\ b\ \in {\mathbb{Z}}^*_q,
  • Map:e\left(P^a,\ Q^b\right)=e(P,\ Q)^{ab}

This has an interesting property whereby it beaks the decisional Diffie-Helman problem, but this will be discussed in more details later.

Non-Degeneracy:

If all the elements map to the identity of the group then if would not have any additional computational aspects to explore. It is therefore important not to create a map with the identity of either of the groups.
\forall P\ \in G_1,\ P\ \neq 0\ \ \left\langle e\left(P,\ P\right)\right\rangle =G_2\ (e\left(P,\ P\right)\ generates\ G_2)
Such that: P\ \neq 0\ \Rightarrow e\left(P,\ P\right)\neq 1

Computability: e should be efficiently computable, there are some constructions of maps that are hard to compute.

The construction of these bilinear pairs has been proven by Wei and Tate pairings, where G_1 is a typical elliptic curve group, and G_2 is a finite field. These have proven to provide complex problems across these groups to construct cryptographical schemes.

Complex Problems

For the usage of bilinear maps in cryptographical schemes, we define a one-way function using two problems, the Decisional Diffie-Helman problem and the discrete log problem.

Theorem 1: The Discrete Log Problem in G_1 is no harder than the Discrete Log Problem in G_2.

Proof 1: If we use our additive notation and consider that Q\ =\ aP, we then need to solve a, which is random, for a given P and a random Q
e\left(P,\ Q\right)=e\left(P,\ aP\right)=e(P,\ P)^a

With this we can effectively reduce the Discrete Log Problem in G_1 to the Discrete Log Problem in G_2, if we are given P\in G_1 and a random Q\in G_1 then the mapping of e is easily computable by calculating {{log}_P (Q)} as:

P^`=e(P,\ P)
Q^`=e(P,\ Q)
a=\ {{log}_{P^`} \left(Q^`\right)\ in\ \ G_2\ }
a={{log}_P (Q)\ }\ in\ G_1

With this we can see that the difficulty of solving the discrete log problem in both groups are the same, since the computation of {{log}_P (Q)\ } have the same complexity in both groups.

Theorem 2: The Decisional Diffie-Helman is easy in G_1.

Proof 2: Solving the Decisional Diffie-Helman problem in G_1 requires distinguishing between:

\langle P,\ aP,\ bP,\ cP \rangle \ with\ a,\ b,\ c\ \in {\mathbb{Z}}^*_q and
\langle P,\ aP,\ bP,\ abP \rangle \in {\mathbb{Z}}^*_q
If we can define P,A,B and C as the distinguishers four values, then the distinguisher function is as follows:

v_1=Map:e(A,\ B)\ and\ v_2=Map:e(P,\ C)

If we have that v_1=v_2, then the tuple is of type \langle P,\ aP,\ bP,\ abP\rangle

From this we can take C=\ abP from (Theorem 1)

e(A,\ B)=e(aP,\ bP)
=e(P,\ P)^{ab}
=e(P,\ abP)
=e(P,\ C)

Since the map e is non-degenerate we can set e\left(A,\ B\right)=e(P,\ C) equivalent to c\ =ab. The distinguisher has thus a significant advantage given the mapping e to decide the Decisional Diffie-Helman problem.

Theorem 3 The Bilinear Diffie-Helman Problem is easy in G_1 but difficult in G_2

Fact: If we are given two groups G_1 and G_2 with a map between them as e, there are no polynomial time algorithm that can compute \left(P,\ aP,\ bP,\ cP\right)for\ \ some\ a,\ b,\ c\ \in \ {\mathbb{Z}}^*_q in G_1 given e(P,\ P)^{abc} in G_2. With this we can construct the following properties between the groups as the following hard problems:

e(aP,\ bP)^c\ in\ G_1=e(P,\ P)^{abc}\ in\ G_2
e(aP,\ cP)^b\ in\ G_1=e(P,\ P)^{abc}\ in\ G_2
e(bP,\ cP)^a\ in\ G_1=e(P,\ P)^{abc}\ in\ G_2

Using these theories, we can now construct cryptosystems based on these hard problems found in these groups.

Cryptography Schemes

Using these complexity problems, there has been an abundance of cryptosystems developed over the years, where the two most notable are the 3-party key agreement scheme, identity based encryption and searchable encryption.

The 3-party Diffie-Helman key agreement scheme

Joux  introduced in 2000 a three-party key agreement scheme using bilinear maps utilizing the Bilinear Diffie-Helman problem for the construction.

If we have two groups G_1 and G_2 with P as a generator of G_1, and three parties A,\ B,\ C that have respective secrets a,\ b,\ c\ \in \ {\mathbb{Z}}^*_q we can construct a key agreement scheme where each party shares a secret key as follows:
A\ \longrightarrow B,\ C:aP
B\ \longrightarrow A,\ C:bP
C\ \longrightarrow A,\ B:cP

Using the Bilinear Diffie-Helman Problem we can define the following:

A computes e(bP,\ cP)^a=e(P,\ P)^{abc}
B computes e(aP,\ cP)^b=e(P,\ P)^{abc}
C computes e(aP,\ bP)^c=e(P,\ P)^{abc}

All parties now have the same shared key K=e(P,\ P)^{abc}\ \in G_2 that can be used as an input to a symmetric encryption scheme.

Identity Based Encryption

The idea of using private information, like an email address, as a public key has been long debated and researched, whereby the corresponding private key can be delivered to the rightful owner. The role of the key generator must be to verify the private information before distributing the private key to the owner, although a public key infrastructure would solve this problem, there were substantial research into this area to move away from a trusted third party, and having the identity as part of the encryption.

In Dan Boneh’s and Franklin’s paper an Identity based encryption scheme was created to remove the public key infrastructure with the use of bilinear maps and the bilinear Diffie-Helman problem, incorporating a random oracle model. This protocol consists out of five phases:

Setup

  • Defining two groups G_1 and G_2 with a bilinear map e:G_{1\ }\times G_1\ \to \ G_2 and P as a generator
  • A System wide secret key s\in \ {\mathbb{Z}}^*_q
  • A corresponding system wide public key P_{pub}=sP, which are not distributed
  • Public hash function H_1:\{0,\ 1{\}}^*\ \to G^*_1, a random oracle
  • Public hash function H_2:G_2\ \to \{0,\ 1{\}}^n for some fixed n, the second random oracle.
  • The message space \mathcal{M}=\{0,\ 1{\}}^n
  • The cypher space C=G^*_1\ \times \{0,\ 1{\}}^n

To create a private key for a corresponding participant for ID\in \{0,1{\}}^* the system computes:

Q_{ID}=H_1(ID) and
d_{ID}=\ {sQ}_{ID} which is the private key that can be distributes to the user.

Encryption:
If we are now given a message m\ \in \mathcal{M} we can compute the cyphertext as follows:

  • Q_{ID}=H_1\left(ID\right)\in G^*_1
  • We then choose a random r\in \ {\mathbb{Z}}^*_q
  • We can now compute g_{ID}=e\left(Q_{ID},\ P_{pub}\right)\in G_2
  • And create the cyphertext: c=(rP,\ m\oplus H_2(g^r_{ID}))

Decryption:

When the user receives the cyphertext, he has c=(u,\ v)\in C and can decrypt it using his corresponding private key d_{ID} and H_2

m=v\oplus H_2(e(d_{ID},\ u))

The main reason that both encryption and decryption works are because of the properties of pairings and the mask generated by H_2 that is xor’ed with the plaintext. We can prove the correctness by using simple substitution from the parameters above:

m=v\oplus H_2(e(d_{ID},\ u))
m=v\oplus H_2(e(sH_1(ID)\ ,\ rP))
m=v\oplus H_2(e(H_1(ID)\ ,\ P))^{rs}
m=v\oplus H_2(e(Q_{ID}\ ,\ sP))^r
m=v\oplus H_2(e(Q_{ID}\ ,\ P_{pub}))^r
m=v\oplus H_2(g^r_{ID})
m=(m\oplus H_2 (g^r_{ID}))\oplus H_2(g^r_{ID}))

=m

This scheme provides us a way to use the identity as a parameter within the encryption and decryption without the use of a third party. The usage of identity is important, as this can bind the encryption and decryption to a owner of the keys.

Searchable Encryption

Searchable encryption schemes are a well-studied topic, and there have been several constructions using order revealing and order preserving schemes. For the a simplified construction a protocol I have chosen to use an order revealing encryption schemes based on bilinear maps, this construction  is proven to be secure against adaptively chosen keyword attacks assuming the bilinear Diffie-Helman problem is intractable using the random oracle model.

To use this construction , we will look at the following scenario:

For this scenario, we need to define four entities that will be involved in the scheme:

  • Users (1..n): responsible for the creation of messages that are sent to a trusted party for routing. These messages are sent and received via a secure channel to the messaging server.
  • Third Party / Message Server: The messaging platform, that routes messages to users, and that can test weather a certain list of keywords are present in the message.
  • Legal Authority (1..n): The party interested in searching the message data.
  • Trusted Third Party: a Party responsible for securing the private key

Suppose a Legal authority needs to be alerted when certain keywords are transmitted to a messaging server. For example, a user sends a message to another user that he is planning a bombing, the “bombing” needs to create an alert on the messaging server, and the legal authority needs to be sent a encryption of the message thread.

If the messages between the users are encrypted using semantic means, then the messaging server cannot make any alerting decisions as it cannot decrypt the messages. Our goal here is to ensure that the messaging server provide a way to test whether a keyword has been transmitted between the users, without revealing the content of the messages. This can only be achievable by the legal authority providing a list of keywords to the message server that can be used, as well messaging server needs to have access to both the encryption and decryption key of the user’s messages.

To do so, a user encrypts messages between users and messaging server using a standard public key cryptosystem and saves it in his database. The messages are appended with a Public-Key Encryption with keyword Search (PKS) of each keyword. For example, User Steve sends Peter a message M with words W_1, W_2..W_m, then the trusted messaging server create:
E_{A_{pub}}(Message)\ \parallel PKS(A_{pub},\ W_1)\parallel \dots \parallel PKS(A_{pub},\ W_m)
Where \parallel denotes concatenation and E_{A_{pub}} is the public key of the legal authority (Alice). The reason for this form of encryption is so that the legal authority can provide a trapdoor T_w to the messaging server to test whether a certain keyword has been used. Given a searchable encryption for a keyword PKS(A_{pub},\ \ W^`) and a trapdoor T_w the messaging server can determine is W=W^` , if it’s the case that W\neq W^` then the messaging server does not learn any information about the word. It’s also quite interesting to note that this is not a very communitive scheme, as the searchable encryption (PKS) is constructed only using the public key of the legal authority.

Definitions

Throughout this section we will refer to a negligible function as f\mathrm{:}\mathrm{\ }\mathbb{R}\to \mathrm{[}0,\ 1] where f\left(s\right)<1/g(s) for any polynomial g and sufficiently large s. I will start by defining a searchable public key encryption scheme (PKS) where the public key refers to the cyphertext created by the messaging server  using the public key of the legal authority , and the searchable encryption scheme (PKS) does not reveal any information about the message.

Our goal is to enable the legal authority to send a short secret key (T_w) for a specific word to the messaging server, so that the messaging server can locate all messages that have this keyword without revealing the word W. The secret key (T_w) produced by the legal authority is based on the private key, and the messaging server send the message containing the words back to the legal authority, encrypted using the corresponding public key.

Definition 1.1: The following polynomial time randomized algorithms are part of a non-interactive searchable encryption scheme (PKS).

  • KeyGen(s): For a security parameter s a corresponding public/private key pair is generated (A_{priv},\ A_{pub}) by the legal authority and the public key is sent to the messaging server.
  • PKS(A_{pub},\ W): For a word W in the message, a searchable encryption (PKS) is generated using the public key A_{pub} of the legal authority. We will denote the PKS function as S
  • Trapdoor(A_{priv},\ W): Given the private key of the legal authority, a certain word W produces a trapdoor T_w.
  • Test(A_{pub},\ S,\ T_W): Given the public key of the legal authority A_{pub},\ \ and a searchable encryption S on the messaging server, a trapdoor T_w outputs `yes’ if W=W'

The legal authority will run the KeyGen algorithm and generate its public/ private key pairs, and then use the Trapdoor function to generate a series of trapdoors for words W_1..\ W_i that it wants to search for. The messaging server will then use the Test function to determine whether a given message has a keyword W_i.

Construction

For the definition above I will provide an efficient construction using bilinear maps based on a variant of the Decision Diffie-Hellman assumption with identity based encryption

We will use two groups G_1,\ G_2 of prime order p and a bilinear map e:G_1\times G_1\to G_2 between the two groups. This map satisfies the following three properties where the size of G_1 and G_2 is determined by a security parameter:

  • Computable: If you are given two elements in G_1 as g,\ h then there exists a polynomial time algorithm to compute the map e(g,\ h) in G_2
  • Bilinear: for all integers in the prime order, we have a map e(g^x,\ g^y) = e(g,\ g)^{xy}
  • Non-degenerate: if g is a generator of G_1 then the map e(g,\ g) is a generator of G_2

From this we can build a non-interactive searchable encryption scheme based on bilinear maps. For this we will need two hash function, or random oracles in each group as:

H_1:\{0,\ 1{\}}^*\to G_1 and H_2:G_2\to \{0,\ 1{\}}^{{log p\ }}

Based on definition 1.1 we will construct the scheme using the same model based on the Dan Boneh Searchable Encryption Scheme:

  • KeyGen(s): The security parameter s determines the size of the prime order p of the groups G_1and G_2. The legal authority then also selects a random \alpha \in {\mathbb{Z}}^*_p and a generator g of G_1. The Output is a public key A_{pub}=[g,\ h=g^{\alpha }] and a private key \alpha . The public key is then distributed to the messaging server.
  • PKS(A_{pub},\ W): Using the public key and a word W, the messaging server computes a bilinear map t\ =e(H_1(W),\ h^r)\in G_2 using the random oracle and a random r\in {\mathbb{Z}}^*_p. Then outputs a searchable encryption PKS(A_{pub},\ W)=[g^r,\ H_2(t)].
  • Trapdoor(A_{priv},\ W): The legal authority uses the random oracle and its private key to generate a trapdoor T_w=H_1(W)^{\alpha }\in G_1
  • Test(A_{pub},\ S,\ T_W): When the messaging server receives a Test function from the legal authority as S=[A,\ B] it can test if H_2(e(T_w,\ A))=B

The construction of the scheme can be viewed as a derivative of Identity Based Encryption with a limited number of identities. Using this scheme, the messaging server needs to have the ability to create an index of the words that’s exchanged between the users of the system that can be tested. Unfortunately, this construction has several issues relating to the sharing of the creation of the trapdoor function. None the less, the use of bi-linear maps and hash functions allows us to identify encrypted words without revealing what they actually are.

 

Mutual Authentication using Certificates

Mutual SSL authentication or certificate based mutual authentication refers to two parties authenticating each other through verifying the provided digital certificate so that both parties are assured of the others’ identity. In technology terms, it refers to a client (ATM) authenticating themselves to a server (Switch) and that server also authenticating itself to the client through verifying the public key certificate/digital certificate issued by the trusted Certificate Authorities (CAs).

Because authentication relies on digital certificates, certification authorities and Certificate Server are an important part of the mutual authentication process. From a high-level point of view, the process of authenticating and establishing an encrypted channel using certificate-based mutual authentication involves the following steps in TLS:

  1. A client requests access to a protected resource.
  2. The server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client sends its certificate to the server.
  5. The server verifies the client’s credentials.
  6. If successful, the server grants access to the protected resource requested by the client.

 

TLS Mutual Authentication Handshake

 

The TLS handshake firstly agrees the protocol to be used by both parties, then exchanges certificates and validates the signatures on each certificates. Below are more detailed steps explaining the handshake.

  1. The TLS client sends a “client hello” message that lists cryptographic information such as the SSL or TLS version and, in the client’s order of preference, the CipherSuites supported by the client. The message also contains a random byte string that is used in subsequent computations. The protocol allows for the “client hello” to include the data compression methods supported by the client.
  2. The TLS server responds with a “server hello” message that contains the CipherSuite chosen by the server from the list provided by the client, the session ID, and another random byte string. The server also sends its digital certificate. The server sends a “client certificate request” that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).
  3. The TLS client verifies the server’s digital certificate.
  4. The TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server’s public key.
  5. If the TLS server sent a “client certificate request”, the client sends a random byte string encrypted with the client’s private key, together with the client’s digital certificate, or a “no digital certificate alert”. This alert is only a warning, but we will not be allowing transactions without a client certificate.
  6. The TLS server verifies the client’s certificate.
  7. The TLS client sends the server a “finished” message, which is encrypted with the secret key, indicating that the client part of the handshake is complete.
  8. The TLS server sends the client a “finished” message, which is encrypted with the secret key, indicating that the server part of the handshake is complete.
  9. For the duration of the TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.

In order to have a clear understanding of public key cryptography and digital signatures, the following section provides a high level overview of the encryption scheme using mutual authentication and certificate authorities.

 

Public-key certificate scheme Basics

In this section we use Alice and Bob as two parties that exchange messages, Oscar is a malicious user trying to decrypt and steal data.

The underlying problem with normal RSA is that the server has no real proof of who its communicating to. If a server is issuing public keys to all parties, how can it identify each individual user and ensue the public keys belong to valid users? Public certificates are also susceptible to Man in the Middle Attacks (MIM) where Oscar can pretend to be Alice and the server have not way of knowing.

Message authentication ensures that the sender of a message is authentic. However, in the scenario at hand Bob receives a public key which is supposedly Alice’s, but he has no way of knowing whether that is in fact the case. To make this point clear, let’s examine how a key of a user Alice would look in practice:

kA = (kpub,A,IDA)

,where IDA is identifying information, e.g., Alice’s IP address or her name together with date of birth. The actual public key kpub,A, however, is a mere binary string,  e.g., 2048 bit. If Oscar performs a MIM attack, he would change the key to:

kA = (kpub,O,IDA)

Since everything is unchanged except the anonymous actual bit string, the receiver will not be able to detect that it is in fact Oscar’s. This observation has far-reaching consequences which can be summarized as: Even though public-key schemes do not require a secure channel; they require authenticated channels for the distribution of the public keys.

The idea behind certificates and authenticated channels is quite easy: Since the authenticity of the message (kpub,A,IDA)is violated by an active Man in the middle attack, we apply a cryptographic mechanism that provides authentication. More specifically, we use digital signatures. Thus, a certificate for a user Alice in its most basic form is the following structure where IDA is identifying information like a terminal id or serial number:

CertA = [(kpub,A,IDA), sigkpr (kpub,A,IDA)]

The idea is that the receiver of a certificate verifies the signature prior to using the certificate, and both the client and the server validates the signature before using the public key. The signature protects the signed message which is the structure (kpub,A,IDA) in this case—against manipulation. If Oscar attempts to replace kpub,A by kpub,O it will be detected. Thus, it is said that certificates bind the identity of a user to their public key.

 

Certificates require that the receiver has the correct verification key, which is a public key. If we were to use Alice’s public key for this, we would have the same problem that we are actually trying to solve and Oscar can impersonate Alice. Instead, the signatures for certificates are provided by a mutually trusted third party. This party is called the Certification Authority commonly abbreviated as CA. It is the task of the CA to generate and issue certificates for all users in the system.

For certificate generation, we can distinguish between two main cases. In the first case, the user computes her own asymmetric key pair and merely requests the CA to sign the public key, as shown in the following simple protocol for a user named Alice:

 

 

Table 1 Certificate Generation with User-Provided Keys

Description Alice Request / Response CA
Alice generates a public private key pair generate kpr,A, kpub,A    
Sends this to the CA   RQST(kpub,A,IDA)  
CA verifies Alice’s identity     verify IDA
CA signs Alice public key with its private key     sA = sigkpr ,CA(kpub,A,IDA)
CA creates a certificate (public private key pair) with its signature     CertA = [(kpub,A,IDA), sA]
Certificate is distributed to Alice for usage   CertA  
       

From a security point of view, the first transaction is crucial. It must be assured that Alice’s message (kpub,A, IDA) is sent via an authenticated channel. Otherwise, Oscar could request a certificate in Alice’s name.

In practice it is often advantageous that the CA not only signs the public keys but also generates the public–private key pairs for each user. In this case, a basic protocol looks like this:

Table 2 Certificate Generation with CA-Generated Keys

Description Alice Request / Response CA
Alice request certificate request certificate    
Sends this to the CA   RQST(,IDA)  
CA verifies Alice’s identity     verify IDA
CA generates new certificate     generate kpr,A, kpub,A
CA signs Alice public key with its private key     sA = sigkpr ,CA(kpub,A,IDA)
CA creates a certificate (public private key pair) with its signature     CertA = [(kpub,A,IDA), sA]
Certificate is distributed to Alice for usage   CertA  
       

For the first transmission, an authenticated channel is needed. In other words: The CA must be assured that it is really Alice who is requesting a certificate, and not Oscar who is requesting a certificate in Alice’s name. Even more sensitive is the second transmission consisting of (CertA, kpr,A). Because the private key is being sent here, not only an authenticated but a secure channel is required. In practice, this could be a certificate delivered by mail or USB stick.

Table 3 Diffie–Hellman Key Exchange with Certificates

Description Alice Request / Response Bob
Both Alice and Bob have private keys issued by a trusted CA a = kpr,A   b = kpr,B
  A = kpub,A a mod p   B= kpub,B aB mod p
Both Alice and Bob generates a public key and signs it with their private key and identity CertA = [(A,IDA), sA]   CertB = [(B,IDB), sB]
Certificates are exchanged    CertA  
  CertB  
  verify certificate:   verify certificate:
Both Alice and Bob use the public key of the CA to verify the signature of the certificate verkpub,CA (CertB)   verkpub,CA (CertA)
  compute session key:   compute session key:
Session key can now be computed. kAB Ba modp   kAB Ab mod p

 

One very crucial point here is the verification of the certificates. Obviously, without verification, the signatures within the certificates would be of no use. As can be seen in the protocol, verification requires the public key of the CA. This key must be transmitted via an authenticated channel; What’s happening here from a more abstract point of view is extremely interesting, namely a transfer of trust. With the introduction of certificates, they only have to trust the CA’s public key kpub,CA. If the CA signs other public keys, Alice and Bob know that they can also trust those. This is called a chain of trust.

 

Certificate Structure

Discussing the fields defined in a X.509 certificate gives us some insight into many aspects of PKIs. We discuss the most relevant ones in the following:

  • Certificate Algorithm: Here it is specified which signature algorithm is being used, e.g., RSA with SHA-1 or ECDSA with SHA-2, and with which parameters, e.g., the bit lengths.
  • Issuer: There are many companies and organizations that issue certificates. This field specifies who generated the one at hand.
  • Period of Validity: In most cases, a public key is not certified indefinitely but rather for a limited time, e.g., for one or two years. One reason for doing this is that private keys which belong to the certificate may become compromised. By limiting the validity period, there is only a certain time span during which an attacker can maliciously use the private key. Another reason for a restricted lifetime is that, especially for certificates for companies, it can happen that the user ceases to exist. If the certificates, and thus the public keys, are only valid for limited time, the damage can be controlled.
  • Subject: This field contains what was called IDA or IDB in our earlier examples. It contains identifying information such as names of people or organizations. Note that not only actual people but also entities like companies can obtain certificates.
  • Subject’s Public Key: The public key that is to be protected by the certificate is here. In addition to the binary string which is the public key, the algorithm (e.g., Diffie–Hellman) and the algorithm parameters, e.g., the modulus p and the primitive element a, are stored.
  • Signature: The signature over all other fields of the certificate.

 

We note that for every signature two public key algorithms are involved: the one whose public key is protected by the certificate and the algorithm with which the certificate is signed. These can be entirely different algorithms and parameter sets. For instance, the certificate might be signed with an RSA 2048-bit algorithm, while the public key within the certificate could belong to a 160-bit elliptic curve scheme.

Certificate Revocation

One major issue in practice is that it must be possible to revoke certificates. A common reason is that a certificate is stored on a smart card which is lost. Another reason could be that a person left an organization and one wants to make sure that she is not using the public key that was given to her. The solution in these situations seems easy: Just publish a list with all certificates that are currently invalid. Such a list is called a certificate revocation list, or CRL. Typically, the serial numbers of certificates are used to identify the revoked certificates. Of course, a CRL must be signed by the CA since otherwise attacks are possible.

 

The problem with CLRs is how to transmit them to the users. The most straightforward way is that every user contacts the issuing CA every time a certificate of another user is received. The major drawback is that now the CA is involved in every session set-up. This was one major drawback of KDC-based, i.e., symmetric key, approaches. The promise of certificate-based communication was that no online contact to a central authority was needed.

An alternative is that CRLs are sent out periodically. The problem with this approach is that there is always a period during which a certificate is invalid but users have not yet been informed. For instance, if the CRL is sent out at 3:00 am every morning (a time with relatively little network traffic otherwise), a dishonest person could have almost a whole day where a revoked certificate is still valid. To counter this, the CRL update period can be shortened, say to one hour.

However, this would be a tremendous burden on the bandwidth of the network. This is an instructive example for the trade-off between costs in the form of network traffic on one hand, and security on the other hand. In practice, a reasonable compromise must be found. In order to keep the size of CRLs moderate, often only the changes from the last CRL broadcast are sent out. These update-only CRLs are referred to as delta CRLs.

Importing ZPK and ZMK into Thales Payshield 9000 HSM

ZMK

Zone Master Key (ZMK) also known as an Interchange key (IK), is a key-encrypting key which is distributed manually between two communicating sites, within a shared network, in order that further keys can be exchanged automatically. The ZMK is used to encrypt keys of a lower level (e.g. ZPK) for transmission.

The ZMK is exchanged using secured methods and Split knowledge policy. The IK is split into two components that are sent by two separate physical couriers to two nominated Security Officers of the other party. This is one of the most secure way to do it since no single person gains knowledge of the clear ZMK.

Here is the detailed Process. please note values indicated here are for testing only, in live environment the values will be exchanged securely.


Build ZMK Key manually:

This key is generated by two components, lets call them K1 and K2. To obtain the ZMK Key,

ZMK = K1 XOR K2

Test values provided,

K1 (clear) = 6D6B E51F 04F7 6167 4915 54FE 25F7 ABEF
K2 (clear) = 6749 9B2C F137 DFCB 9EA2 8FF7 57CD 10A7

   
ZMK (clear) key = K1 XOR K2 = 0A227E33F5C0BEACD7B7DB09723ABB48; 
KCV = 05EE1D

Import ZMK into HSM

FK
Key length [1,2,3]: 2
Key Type: 000
Key Scheme: U
Component type [X,H,E,S]: X
Enter number of components (2-9): 2
Enter component #1: 6D6BE51F04F76167491554FE25F7ABEF
Enter component #2: 67499B2CF137DFCB9EA28FF757CD10A7

Encrypted key: U E685 8676 0A16 3026 C297 1007 3AB2 D7BE 
Key check value: 05EE1D

ZPK

Zone PIN Key (ZPK) also known as a A PIN Protection Key (PPK), is a data encrypting key which is distributed automatically and is used to encrypt PINs. For security and protocol reasons the HSM where this key generated, never exposes the ZPK in clear. But it can be exported using another key called ZMK (Interchange Key). In this context exports actually means use the ZMK Key to encrypt the ZPK and give back to the user.


Import ZPK

The following ZPK shared by communicating party, is encrypted under ZMK

ZPK encrypted under ZMK: AC4D3C5F603C1B502E5F45668A155C25
KCV: AFDA4F

From the host application, send the A6 commands with required arguments as following,

HSM Command:

0000A6001UE68586760A163026C29710073AB2D7BEXAC4D3C5F603C1B502E5F45668A155C25U00

Where,

Atalla Variant = 00
Encrypted PPK Key = AC4D…….5C25
Key Scheme= X
Key Scheme LMK= U
Key Type = 001
ZMK = E68586760……..D7BE
ZMK Scheme = U

Response:
0000A700U5F2DC42E10C92B16BA54802314CE95F5AFDA4F

ZPK under LMK: U5F2DC42E10C92B16BA54802314CE95F5
KCV: AFDA4F

Here we can compare KCV (AFDA4F) to check if key is imported successfully.


Signature and Certificate based key injection for ATM

Overview

Remote key loading infrastructures generally implement Diebold’s and Triton’s Certificate Based Protocols (CBP), and NCR, Wincor and Hyosung Signature based Protocols.

The Diebold and Triton approaches use X.509 certificates and PKCS message formats to transport key data. NCR, Wincor and Hyosung methods rely on digital signatures to ensure data integrity. Both processes require the loading of the ATM EPP with a public key or certificate at the factory. Both these methods are supported in and XFS compliant manner and this document describes the process of doing so as well as the pitfalls and benefits of using both methods.

The General Process

Initialization

A prerequisite for using Remote Keys is for a customer to generate a set of keys or certificates that will be “signed” by a Certificate Authority or Trust Authority. Once signed, the public key or certificate signatures are returned and imported into the Host system. The EPPs obtain their signed public keys or certificates during the manufacturing process before being installed in ATMs.

Mutual Authentication

With public and private key pairs now present in the Host and in the ATM’s EPP, mutual authentication can be initiated with message exchanges from the Host to the EPP.  The ATM sends the EPP serial number to Host encrypted by its public key or certificate. The Host verifies the message and sends a message back to the EPP encrypted by its public key or certificate.

Key Delivery

With mutual authentication successfully completed, the Host receives a request to deliver a new terminal master key to the EPP. The Host receives the key request and generates a random terminal master key and encrypts it with the public key of the EPP and “signs” the new TMK message. This message is sent to the EPP. The EPP verifies the signature, decrypts the new terminal master key, and stores the key.

If the dialogue has been successfully completed, the EPP sends a notification back to the Host that it has loaded the new terminal master key including a Key Check Value (KCV) of the new key. If the terminal key load is unsuccessful, an appropriate error message will be returned to the Host. Upon receiving a “successful” terminal master key load message from the EPP with the correct KCV, the Host will establish the new TMK in the key database.

 

 

Remote Key Loading Using Signatures

RSA Data Authentication and Digital Signatures

Digital signatures rely on a public key infrastructure (PKI). The PKI model involves an entity, such as a Host, having a pair of encryption keys – one private, one public. These keys work in consort to encrypt, decrypt and authenticate data.

One-way authentication occurs is through the application of a digital signature. For example:

  1. The Host creates some data that it would like to digitally sign;
  2. Host runs the data through a hashing algorithm to produce a hash or digest of the data. The digest is unique to every block of data – a digital fingerprint of the data, much smaller and therefore more economical to encrypt than the data itself.
  3. Digest is encrypted with the Host’s private key. This is the digital signature – a data block digest encrypted with the private key.

The Host then sends the following to the ATM:

  1. Data block.
  2. Digital signature.
  3. Host’s public key.

To validate the signature, the ATM performs the following:

ATM runs data through the standard hashing algorithm – the same one used by the Host – to produce a digest of the data received. Consider this digest2;

ATM uses the Host’s public key to decrypt the digital signature. The digital signature was produced using the Host’s private key to encrypt the data digest; therefore, when decrypted with the Host’s public key it produces the same digest. Consider this digest1. Incidentally, no other public key in the world would work to decrypt digest1 – only the public key corresponding to the signing private key.

ATM compares digest1 with digest2. If digest1 matches digest2 exactly, the ATM has confirmed that the data was not tampered with in transit. Changing a single bit in the data sent from the Host to the ATM would cause digest2 to be different than digest1. Every data block has a unique digest; therefore, an altered data block is detected by the ATM.

Public key used to decrypt the digital signature corresponds to the private key used to create it. No other public key could possibly work to decrypt the digital signature, so the ATM was not handed someone else’s public key.

This gives an overview of how Digital Signatures can be used in Data Authentication. In particular, Signatures can be used to validate and securely install Encryption Keys.

The following section describes Key Exchange and the use of Digital signatures.

 

RSA Secure Key Exchange using Digital Signatures

In summary, both end points, the ATM and the Host, inform each other of their Public Keys. This information is then used to securely send the PIN device Master Key to the ATM.

A trusted third party, the Signature Issuer, is used to generate the signatures for the Public keys of each end point, ensuring their validity.

The detail of this is as follows:

Purpose:

The Host wishes to install a new master key (KM) on the ATM securely.

Assumptions:

  • The Host has obtained the Public Key (PKSI) from the Signature Issuer.
  • The Host has provided the Signature Issuer with its Public Key (PKHOST), and receives the corresponding signature Sign(SKSI)[ PKHOST]. The Signature Issuer uses its own Private Key (SKSI) to create this signature.
  • In the case where Enhanced Remote Key Loading is used, the Host has provided the Signature Issuer with its Public Key (PKROOT), and receives the corresponding signature Sign(SKSI)[PKROOT]. The Host has generated another key pair PKHOST and SKHOST and signs the PKHOST with the SKROOT.
  • (Optional) The Host obtains a list of the valid PIN device’s Unique Identifiers. The Signature Issuer installs a Signature Sign(SKSI)[ UIATM] for the Unique Id (UIATM) on the ATM PIN. The Signature Issuer uses SKSI to do this.
  • The Signature Issuer installs its Public Key (PKSI) on the ATM PIN. It also derives and installs the Signature Sign(SKSI )[PKATM] of the ATM PIN’s Public Key (PKATM) on the ATM PIN. The Signature Issuer uses SKSI to do this.
  • The ATM PIN device additionally contains its own Public (PKATM) and Private Key (SKATM).

Steps for the Process

 

Step 1: The ATM PIN sends its Public Key to the Host in a secure structure: The ATM PIN sends its ATM Public Key with its associated Signature. When the Host receives this information it will use the Signature Issuer’s Public Key to validate the signature and obtain the ATM Public Key.

Step 2 (Optional):  The Host verifies that the key it has just received is from a valid sender. It does this by obtaining the PIN device unique identifier. The ATM PIN sends its Unique Identifier with its associated Signature. When the Host receives this information it will use the Signature Issuer’s Public Key to validate the signature and retrieve the PIN Unique Identifier. It can then check this against the list it received from the Signature Issuer.

Step 3 (Enhanced Remote Key Loading only) : The Host sends its root public key to the ATM PIN: The Host sends its Root Public Key (PKROOT) and associated Signature. The ATM PIN verifies the signature using PKSI and stores the key.

Step 4:  The Host sends its public key to the ATM PIN: The Host sends its Public Key (PKHOST) and associated Signature. The ATM PIN verifies the signature using PKSI (or PKROOT in the Enhanced Remote Key Loading Scheme) and stores the key

Step 5:  The ATM PIN receives its Master Key from the Host: The Host encrypts the Master Key (KM) with PKATM. A signature for this is then created. The ATM PIN will then validate the signature using PKHOST and then obtain the master key by decrypting using SKATM.

 Step 6 – Alternative including random number:  The Host requests the ATM PIN to begin the DES key transfer process and generate a random number. The Host encrypts the Master Key (KM) with PKATM. A signature for the random number and encrypted key is then created using SKHOST. The ATM PIN will then validate the signature using PKHOST, verify the random number and then obtain the master key by decrypting using SKATM.

 

Remote Key Loading Using Certificates

Certificate Exchange and Authentication

Both end points, the ATM and the Host, inform each other of their Public Keys. This information is then used to securely send the PIN device Master Key to the ATM. A trusted third party, Certificate Authority (or a HOST if it becomes the new CA), is used to generate the certificates for the Public Keys of each end point, ensuring their validity. In this message contains the Host certificate, which has been signed by the trusted CA. The Pinpad Cryptography Unit (CTU) uses the Public Key of the CA (loaded at the time of production) to verify the validity of the certificate. If the certificate is valid, the CTU stores the HOST’s Public Verification Key. The CTU then sends a message that contains a certificate, which is signed by the CA and is sent to the HOST. The HOST uses the Public Key from the CA to verify the certificate. If valid then the HOST stores the CTU’s verification or encryption key (primary or secondary this depends on the state of the CTU).

 

 

Remote Key Exchange

After the above has been completed, the HOST is ready to load the key into the CTU.

The following is done to complete this and the application must complete the Remote Key Exchange in this order:

  1. Return RATM from the CTU to be used in authenticating the message.
  2. Next, the ATM sends down the KTK to the CTU. The following items below show how this is accomplished.
  3. a) HOST has obtained a Key Transport Key and wants to transfer it to the CTU. HOST constructs a key block containing an identifier of the HOST, IHOST, and the key, KKTK, and enciphers the block, using the CTU’s Public Encryption Key.
  4. b) After completing the above, the HOST generates random data and builds the outer message containing the random number of the Host, RHOST, and the random number of the ATM, RATM. The identifier of the CTU, IENC, and the enciphered key block. The HOST signs the whole block using its private signature key and sends the message down to the CTU. The CTU then verifies the HOST’s signature on the message by using the HOST’s Public Verification Key. Then the CTU checks the identifier and the random number of the CTU passed in the message to make sure that the CTU is talking to the right HOST. The CTU then deciphers the enciphered block using its private verification key. After the message has been deciphered, the CTU checks the Identifier of the HOST. Finally, if everything checks out to this point the CTU will load the Key Transport Key
  5. c) After the Key Transport Key has been accepted, the CTU constructs a message that contains the random number of the Host, the random number of the CTU and the HOST identifier all signed by the private signature key of the CTU. This message is sent to the Host.
  6. d) The HOST verifies the message sent from the CTU by using the ATM’s public verification key. The HOST then checks the identifier of the Host and then compares the identifier in the message with the one stored in the HOST. Then checks the random number sent in the message and to the one stored in the HOST. The HOST finally checks the CTU’s random number with the one received.

 

Replace Certificate

After the key is been loaded into the CTU, the following could be completed: The new CA requests a Certificate from the previous Certificate Authority. The HOST must over-sign the message to take over the role of the CA to ensure that the CTU accepts the new Certificate Authority. The HOST sends the message to the CTU. The CTU uses the HOST’s Public Verification Key to verify the HOST’s signature. The CTU uses the previous CA’s Public Verification Key to verify the signature on the new Certificate sent down in the message. If valid, the EPP stores the new CA’s certificate and uses the new CA’s Public Verification Key as its new CA verification key.