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:

The Host creates some data that it would like to digitally sign;
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.
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:

Data block.
Digital signature.
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 (PK_SI) from the Signature Issuer.
The Host has provided the Signature Issuer with its Public Key (PK_HOST), and receives the corresponding signature Sign(SK_SI)[ PK_HOST]. The Signature Issuer uses its own Private Key (SK_SI) 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 (PK_ROOT), and receives the corresponding signature Sign(SKSI)[PK_ROOT]. The Host has generated another key pair PK_HOST and SK_HOST and signs the PK_HOST with the SK_ROOT.
(Optional) The Host obtains a list of the valid PIN device’s Unique Identifiers. The Signature Issuer installs a Signature Sign(SK_SI)[ UI_ATM] for the Unique Id (UI_ATM) on the ATM PIN. The Signature Issuer uses SK_SI to do this.
The Signature Issuer installs its Public Key (PKSI) on the ATM PIN. It also derives and installs the Signature Sign(SK_SI )[PK_ATM] of the ATM PIN’s Public Key (PK_ATM) on the ATM PIN. The Signature Issuer uses SK_SI to do this.
The ATM PIN device additionally contains its own Public (PK_ATM) and Private Key (SK_ATM).

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 (PK_ROOT) and associated Signature. The ATM PIN verifies the signature using PK_SI and stores the key.

Step 4: The Host sends its public key to the ATM PIN: The Host sends its Public Key (PK_HOST) and associated Signature. The ATM PIN verifies the signature using PKSI (or PK_ROOT 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 (K_M) with PK_ATM. A signature for this is then created. The ATM PIN will then validate the signature using PK_HOST and then obtain the master key by decrypting using SK_ATM.

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 (K_M) with PK_ATM. A signature for the random number and encrypted key is then created using SK_HOST. The ATM PIN will then validate the signature using PK_HOST, verify the random number and then obtain the master key by decrypting using SK_ATM.

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:

Return R_ATM from the CTU to be used in authenticating the message.
Next, the ATM sends down the KTK to the CTU. The following items below show how this is accomplished.
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, I_HOST, and the key, K_KTK, and enciphers the block, using the CTU’s Public Encryption Key.
b) After completing the above, the HOST generates random data and builds the outer message containing the random number of the Host, R_HOST, and the random number of the ATM, R_ATM. The identifier of the CTU, I_ENC, 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
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.
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.

EFTPOS Initialisation using RSA Cryptography

Before you start with RSA, you should generate a public and private key pair using your HSM. These can be group keys or specific to the terminal you need to connect. Your terminal manufacturer will also provide its public key and modulus. Using these keys you will be able to calculate the TMK1 and TMK2 and also your session keys. The process is in fact very simple.

Here is an example of how to create these keys using a Thales HSM

Generating an 1536 bit RSA Key

Input

001-EI2153601

Output

001-EJ00

Public Key
3081C80281C0A0FAFB1789B87F6F075B04FE60B5F20AC9D658E6C9B9B4E82AD41FD748A5A00CAF0A5691D2D01726AB073AFB7B91810430F240244E0D4737A397C747FC67C622B12E3654DCDF4F58EE29241616AE7EBA08A1E16DB79E09529FB6CA92213F2DFAB3F677793BF977D640107FBF9833842A0BFBF5F871709E78EE5A152E0BBBBBDDED80D193BAC3033FE412B3C420532A8B309942E76F7A9FB4475B8EDEFDDADC4C101FF02F74BEE0261C681E314124654C39411E2CE56FE719A45CA7592B8431D30203010001

Private key length
0488

Private Key
4E79F95F16AFF16278A893722DA94C8EBFEB013126EC0E98C9CBCBD99DB6D4E82336BD33631CB859D0506D4C2B69DAB818AEE965E73417006774DD746033A6F6EEC1AE3C823E3E20561C84B26885D9D9AE66A552864C75E2B8759B6909DA13CFE70FCB31358A56711549FB2ECC20E4EC3227309D074AE85307C98CF234AF115183716461A701E9FF877F118A5187C27D96B33BE88851ED75D71760DF671CBBA15F1EA7F54CC6205B6997669B6ED9C7448C3D0F451E229E44CC5474462D161A5A89E3D6A473080A8C734E4D5440D2E2A6530D5A848B8B2A0EE637ECF8F604D89449EA9922E115885C8024F6B765C16285C2FC5631CC8C437885170E96CD1D2CB748E4B7FE7FC40517705BC96C22C278BD15CEB51E4D49A722C09237E164D5091EBE847629488180972A1EF6626619B7A16F720D725EFB5C1164E44F915024414BEBF6CE6D258275398D35F38FDC2354F16CEECB7DA77D0E5EC3317D05B351D6938C888A88A9B588C8E88518EFD7581075CD6AA206690E865CA528D5BED5151B9BCAB892CCA49F43349F9F28C5502FC8CA5D2B6D84E57169AAD665961F28797995891B6520822134DBC92ADE13F4D154F520B5BD6EBEBF3620C3CEF941CF7A2302431FEB68C0093A0EE7CF14433F2E9E1A403E545FA96B4BF580D4C17FC26C6E93DADC23738B37E917

Generate a MAC on 1536 RSA key

Input

002-EO01<3081C80281C0A0FAFB1789B87F6F075B04FE60B5F20AC9D658E6C9B9B4E82AD41FD748A5A00CAF0A5691D2D01726AB073AFB7B91810430F240244E0D4737A397C747FC67C622B12E3654DCDF4F58EE29241616AE7EBA08A1E16DB79E09529FB6CA92213F2DFAB3F677793BF977D640107FBF9833842A0BFBF5F871709E78EE5A152E0BBBBBDDED80D193BAC3033FE412B3C420532A8B309942E76F7A9FB4475B8EDEFDDADC4C101FF02F74BEE0261C681E314124654C39411E2CE56FE719A45CA7592B8431D30203010001>

Output

002-EP00<C905141E><3081C80281C0A0FAFB1789B87F6F075B04FE60B5F20AC9D658E6C9B9B4E82AD41FD748A5A00CAF0A5691D2D01726AB073AFB7B91810430F240244E0D4737A397C747FC67C622B12E3654DCDF4F58EE29241616AE7EBA08A1E16DB79E09529FB6CA92213F2DFAB3F677793BF977D640107FBF9833842A0BFBF5F871709E78EE5A152E0BBBBBDDED80D193BAC3033FE412B3C420532A8B309942E76F7A9FB4475B8EDEFDDADC4C101FF02F74BEE0261C681E314124654C39411E2CE56FE719A45CA7592B8431D30203010101>

This is a generic version of RSA encryption using POS pinheads, there are variations in the field. Please keep that in mind when reading this.

Now when a POS terminal logs on for the first time it shall always logon using a 9820 message with a network management information code of 191, containing the TCU public key signed by the manufacturer’s secret key, and the un-enciphered PPID.

The Financial Switch shall respond with a 9830 message with the same network management information code, communicating the public key of the sponsor host (PKsp), and a random number.

The PIN Pad shall then generate the KI and send a 9820 message with a network management information code of 192 to the Financial Switch, containing the KI, PPID, date & time stamp, the random number and user data enciphered under the Financial Switch’s public key (PKsp) and signed by the TCU’s secret key (SKtcu). You will need to extract this information using your HSM H8 command, example below:

Input Data:

001-H801<FDC694A6>
<30550250AB378F98E373BBC6FA5E698F4F095A6D693A851E53C35CC9633947399C09D70932776DBEA5F2F0F0C4DAB4693CACB4D07B19242FF0435C55E3D4E28EFD563457F7EBA31BE1123DEA78CEC1573716130B020103>
;990192
<99658789F42672E7C51CB6ECAF3F061BBABCD954D4113E1CD9BD7BD4DF1BD94E6CBC10F497E9AE68265E87F77BFF293AA2D9FDE9C1A8F12A04D9B4D8DB9F5EAEE4690883838DEF670174E70C79E674F97E2457DD85EEEB346A17DD1F39CB3E8B2D69949436051994F8687F0FEE6558F28180D5A63946CD60604B1C82F6AE14454F5824CBFDCEE07478D2F0239299B64CD900DFF7559423E98F0C7AB8229933E4DD5A5E0BD736F8172668676949493577E323FC8EC592437F6DF20EDB5FBB6E92>
;0080
<7C9DDD3AEFF1D50BAFD11DBAF240BE827BAA156F9E8BB555CC019E183B3708F26EBE6C94702A9AD7CC1D2159CF587437532969D113C70BD622EB81AFC06E9408F1B69F3ED838A9EADFB41FB0E6E4202E>
;1234567890123456;000

Response:

001-H900
H604A678C8C78E1B9CFD415220D418E76
U9912C5D8B113B5E9D6787D57EE9E43BA
1122334455
9876543210987654

The Financial Switch shall check the PPID and random number. If the check fails, it will respond with a 9830 with a response code of “63”.

Where the Financial Switch is satisfied with the contents of the second 9820 message, it shall respond with the KCA and the KMACH enciphered under KI and its AIIC in the clear. When the PIN Pad has deciphered KCA and KMACH, it shall erase KI.

At this time the PIN Pad shall calculate the KIA. When the KIA has been calculated, the PIN Pad shall erase KCA.

The POS terminal shall then generate a 9820 message with a network management information code of 193 to the Financial Switch containing the PPID and the Financial Switch shall respond with a 9830 response containing the two initial KEKs and the PPASN.

You can generate this using the C0/C1 HSM command.

The POS terminal shall validate the MAC on the two KEKs and the PPASN and, if the MAC is valid, shall install KEK1, KEK2 and the PPASN and shall calculate the single length DES key KMACI. These keys are the terminal initial keys, that will updated in the season key exchange.

Once this has been carried out, the PIN Pad shall erase the KIA.

When these tasks have been completed, the POS terminal shall carry out its normal logon and session key installation with the Financial Switch. As the processing (initial logon then normal logon and session key installation) completes, the POS terminal will move into the “Ready” state.

easy as pie!

Thales 9000 with AS2805 Interchange & RSA EFTPOS Commands.

Interchange Cryptographic Keys

Interchange keys are used to protect financial transactions initiated at Acquirer eftpos / ATM Terminals while in transit to the Issuer institution. Interchange keys may be either:

(a) PIN encrypting keys – used to protect the customer PIN from the point of origin to the point of authorisation. PIN encrypting keys are a specific instance of session keys;

(b) Session keys – used to secure, validate and protect the financial message. Session keys can be further qualified into those used in the terminal to Acquirer environment (terminal session keys) or on node to node links (interchange session keys);

(d) Transport Keys – used to protect keys (e.g. KEKs) during transport to the partner institution.

Cryptographic Algorithms

DEA3 and DEA2 are the only approved algorithms for the protection of interchange information (full details of these algorithms may be found in the Australian standard AS 2805 part 5).

DEA3 keys are 128 bits in length (effectively 112 bits) and are generally referred to as triple DES or 3DES keys (the corresponding encryption algorithm is specified in AS 2805 part 5.4). Triple DES may also be acceptably implemented using a key length of 192 bits (effectively 168 bits).

DEA3 with a key length of 128 bits and DEA2 with key lengths equal to, or greater than 2048 bits are the minimum acceptable requirements for the effective protection of interchange information at the time of the issuance of this document.

In accordance with AS 2805 part 3, DEA3 must be used for PIN encipherment.

Interchange Links

For all Interchange Links, Issuers and Acquirers must ensure that:

(a) Security for Transactions processed over that Interchange Link complies with AS2805 Part 6;

(b) Message formats comply with AS2805 Part 2;

(d) PIN security and encryption complies with AS2805 Parts 3 and 5.4;

(e) Key management practices comply with AS2805 Part 6.1;

In each case and as more particularly set out in Part 8:

(a) Message Authentication must apply to all Interchange Links;

(b) The Message Authentication Code (MAC) must be calculated using, as a minimum, a DEA 3 (128-bit) key, Triple DES and an algorithm conforming to AS2805 Part 4; and

The Actual process using an Thales 9000 HSM (CECS Approved)

Now what we are clear on the actual requirements of CECS and APCA, lets attempt to do this using a Thales 9000.

Generate a Sponsor RSA key pair

This command is the first step as would be required to do this for all terminal commands.

This is done my using the HSM EI host Command, from the HSM base manual.
- The input is the length of the RSA key set required, and the length go the public key modulus.
The Public Key Verification Code should now be generated. This is done using the HSM H2 Command from the Australian Standards Support Manual.

The Public Key and the PVC are sent to your Interchange Partner via different paths, as per their direction. (lets call this OUR-Key and OUR-PVC)

Your Interchange partner will now do the same process and provide you with a Public Key and a PVC. (lets call this THEIR-Key and THEIR-PVC)

When we receive this Public Key from our Interchange Partner, the following should happen:

The PVC for the Key should be generated using the HSM H2 Command from the Australian Standards Support Manual.
The MAC for the Key should be generated using the HSM EO command from the HSM Base Manual.

We now have public keys exchanged and have them ready for use!!

Our Database should be looking like this:

Now we have the Public keys exchanged and ready for use, we can generate our KEKs & send to Interchange Partner, and receive our KEKr from Interchange Partner;

To send our KEKs we will use the H4 command from the Australian Standards support manual.
To receive our KEKr we will use the H6 command from the Australian Standards support manual.

Once these are decrypted and stored in our key database we can generate and exchange our session MAC and PIN keys.

To generate and store our send keys we use the OI command from the Australian Standards support manual.
To receive and store our receive keys we use the OK command from the Australian Standards support manual.

Now we have all the keys in place we can start to process transactions.

To generate the MAC on a message there are a number of commands available, however as we are using the AS2805 standards we always recommend our customers use the C2 command from the Australian Standards support manual. This provides all the options required for the Australian environment.

Similarly to verify the MAC on a message there are a number of commands available, however as we are using the AS2805 standards we always recommend our customers use the C4 command from the Australian Standards support manual. This provides all the options required for the Australian environment.

Terminal Commands

Terminal Manufacturer will be injecting into the PINpads their Manufacturer Public Key. The MPK will be transmitted to SPONSOR securely. The MPK validity should be checked by verifying the PVC, this is achieved by generating a Public Key Verification Code This is done using the H2 command from the Australian Standards support manual. And the two values compared.

We also need to generate a PPASN, this is achieved using the AS2805 PK command.
The host will now send the SPK to the PINpad, the PINpad will now generate the KI (also known as KTI), and send to the host. This is recovered using the AS2805 host H8 command, which also returns the KCA, the KCA is encrypted under the LMK and the KTI.
Now we have the MPK and have verified it is genuine, we now need to generate a MAC for the Public Key, this is achieved using the Host EO command, this is used in subsequent processing. Note: this command is only available when the HSM is in Authorised State. We can now recover the PINpad Public from the MSK. This is achieved using the AS2805 H0 host command.
KCA is now used to create the TMK1 and TMK2 (also known as KEK1 & KEK2). These are generated using the C0 command.
Now we have the TMK’s in place we can use the TMK update commands.

Updating the Keys

When updating only TMK1 the AS2805 OU command is used.
When updating both TMK1 and TMK2 then the OW command is used.

Now we have the TMK’s in place and able to be updated, we can generate the Session Keys to be used for the PIN, MAC & optional encryption keys if required.

This is achieved using the AS2805 PI command. The PI command will generate the PIN, MAC, and optional Encryption keys.

Now we can have the session keys in place we can Decrypt the data, verify the MAC & verify the pin. The decrypt data & verify MAC steps depend on how it has been handled by the terminal. Has the terminal done the MAC first then encrypted the required data or has the terminal encrypted the data & then done the MAC. We have assumed that the Encrypt was done first.

Verify the MAC’s on the transactions from the terminal using the AS2805 C4.

Once the MAC has been verified we can then decrypt the required data with the AS2805 host command PW.

Now we have the required decrypted data you will need to either verify the PIN or Translate the PIN, to translate the PIN assuming the transaction is a debit card transaction. This is achieved using the AS2805 PO host command. To verify the PIN will use one of the following F0 or F2.

If you have translated the PIN we can form the message and generate a MAC for the message to be sent to Interchange Partner, this is achieved using the C2 command as detailed above in the Interchange messages.

The biggest problem we see with this are around the KEKs & KEKr is people get them around the wrong way. Your KEKs becomes the remote KEKr & vice versa. The AS2805 commands are designed to swap them over automatically.

The other gotcha is we split the terminal side & the interchange side of the HSM, TMK (terminal master key) is like a KEK (ZMK (Zone master key)) but used on the terminal side of the network where a ZMK (KEKs & KEKr) is used for interchange side of the network.

easy as Pie!