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:

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

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

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.
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:

Message Integrity, a MAC computed on the key and its attributes or a digital signature.
The purpose of the key bounded to the key itself, such that the MAC will fail if the attributes are modified.
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:

MAC – Keys have integrity protection in transaction messages.
Key Purpose is enforced by a key purpose bit applied to the key.
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.

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:

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.

The Refund vulnerability of AS2805 and EFTPOS

Transactions are normally validated, matched then processed. This is very common to ensure that requests sent to a payments switch are associated with its responses before delivering responses to a terminal. Now for all transaction types this process in true, except for refunds. Well, at least it’s not matched for most financial institutions in Australia.

Below is a few descriptions of transactions that might be processed through a typical switch in Australia:

Authorization / Cash Out

The Authorization transaction is typically used by a merchant to obtain the authorization of a transaction amount as a pre-approval for the purchase of goods or services later during the fulfillment process. Authorization transactions are typically submitted for authorization and then funds are held by the issuer until that transaction is captured or the authorization is reversed or expires. An example can be found with online retailers who initiate an Authorization transaction to guaranteed funding by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods. An “Authorization” is also referred to as an Auth-Only transaction.

Sale / Purchase

A “Sale” transaction is used by merchants for the immediate purchase of goods or services. This transaction completes both the authorization and capture in a single transaction request. The Sale transaction is an Authorization and Capture transaction that if approved is automatically included for settlement.

Forced Sale

A “Forced Sale” is a transaction initiated by a merchant with the intent of forcing the posting of the transaction against the customer account without receiving prior authorization by the card issuer, or receiving a voice authorization code from the merchant acquiring call center. An example would be when a merchant’s terminal is offline, requiring the purchase of goods being completed without receiving online authorization by the card issuer. Or they received a Voice Approval. In these cases the merchant would enter the transaction details and forward this Forced Sale transaction to the card issuer with the expectation of receiving funding for the goods or services rendered. A forced sale does not require a matching authorization. Forced Sales are also known as Off-Line Sales.

Refund

A Refund allows a merchant to refund a previously settled transaction and submit the refund for processing. Refunds are only allowed for financial transactions (Sale and Captured) and are typically limited to the original authorization amount, or a lesser amount, in some cases, multiple partial refunds up to the original transaction amount. Some systems incorporate a feature called Matched Refunds. Matched Refunds must match back to an original transaction to help control fraud. “ Refunds” are also sometimes referred to as a “Credit” transaction.

Void

Void transactions can reverse transactions that have been previously authorized or approved by the card issuer and are pending settlement. Merchants will only be allowed to void transactions that are in an open batch (pending settlement). Sale or Refund transactions are the most commonly voided transaction types.

Capture

The Capture transaction will allow merchants to capture a previously authorized transaction that is pending settlement, and submit it for clearing and settlement. An example is when online retailers who initiate an Authorization transaction to reserve funds by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods, and then once fulfillment has been completed the transaction will be captured and submitted for settlement. A “Capture” is also referred to as a Pre-Authorization Completion transaction.

Now According to the AS2805 Specifications, The refund is not matched to the transaction during the refund authorization, and will approve by default, you need to match the Refund to an Authorization or Sale when doing settlement.

This appears not implemented in Australia for some reason, and some financial institutions will actually admit it.

I have tried this on a EFTPOS machine, you should try this as well. Simply do a refund on a EFTPOS terminal without doing a transaction. All you would need is a 4 digit password to access the refund function (in some cases refunds are not password protected) , these default passwords are published by the terminal manufacturers.

In every case that I’ve tried this, the refund is processed and the funds appeared in my account. This is surely a massive risk for fraud!!!!

Strange enough, the banks are not worried about this as the funds are tied to the merchant account, and it’s not a risk for the bank but for the Merchant. These are some clause in the contracts that absolve them from the risk.

So if you have a EFTPOS terminal, ask for the refund function to be disabled or you could be out of pocket!

DUKPT Explained with examples

Derived Unique Key Per Transaction (DUKPT) process that’s described in Annex A of ANS X9.24-2004.

It’s generally considered to be complex, but I’ve simplified it slightly with the help of online resources.

Key Management

Here’s a basic outline of the technique:

You’re given a Base Derivation Key (BDK), which you assign to a swiper (note that the same BDK can be assigned to multiple swipers).
You’ll use the BDK along with the device’s own unique Key Serial Number (KSN) to generate an Initial PIN Encryption Key (IPEK) for the device.
You’ll assign this IPEK to a swiper, which uses it to irreversibly generate a list of future keys, which it’ll use to encrypt its messages.
The swiper’s KSN is used along with one of its future keys to encrypt a message, and after each swipe it’ll increment the value of its KSN.
Whenever a swiper takes a card it formats the card’s information into a series of tracks, each track having a particular set of information (e.g. card number, holder’s name, expiration date).
The swiper usually encrypts these tracks using one of its generated future keys (called the “Session Key”) along with its current KSN. It’ll then increment the value of its KSN and discard the future key it used.
At this point you’ll probably have an encrypted track along with the KSN the swiper used to encrypt it.
It’s your responsibility to determine what BDK was used to initialize this device, and from there you’ll use the BDK and KSN to rederive the IPEK, which is used to rederive the Session Key, which is finally used to decrypt the message.

There’s a lot of technical information to be said about key management, but this isn’t the place for that. In some cases your provider/manufacturer (e.g. MagTek) will supply you with swipers that need to be initialized with an IPEK, and your supplier will usually have a manual that walks you through that process. If you’re doing encryption/decryption through a third party who also supplies swipers, they may have already loaded the devices with that information; what’s more is they may not even given you the BDK that belongs to your device in order to reduce the risk of security threats.

Note: Key management is beyond the scope of this explanation. Whatever you do with your keys, just make sure it’s secure.

One methodology I’ve seen that’ll allow you to associate a particular KSN to a BDK is to take the current KSN you’ve been given, mask it to retrieve the Initial Key Serial Number (IKSN), and look up the BDK in a table that maps IKSNs to BDKs:

Example:

ksn = FFFF9876543210E00008
iksn = ksn & FFFFFFFFFFFFFFE00000 // FFFF9876543210E00000

You’d then have a table that looks like:

IKSN	BDK
0xFFFF9876543210E00000	0123456789ABCDEFFEDCBA9876543210
…	…

From which you could easily grab the BDK 0123456789ABCDEFFEDCBA9876543210.

Algorithm

Note: Assume that all numeric values are hexadecimal numbers, or the representation of a sequence of bytes as a hexadecimal number.

The following are the BDK, KSN, and encrypted track message (cryptogram) we’ve been given:

bdk = 0123456789ABCDEFFEDCBA9876543210
ksn = FFFF9876543210E00008
cryptogram = C25C1D1197D31CAA87285D59A892047426D9182EC11353C051ADD6D0F072A6CB3436560B3071FC1FD11D9F7E74886742D9BEE0CFD1EA1064C213BB55278B2F12

Here’s an example of the unencrypted track 1 data (cryptogram above), and below that is its value in hex; this is what we’ll get after successfully decrypting the cryptogram:

%B5452300551227189^HOGAN/PAUL      ^08043210000000725000000?
2542353435323330303535313232373138395E484F47414E2F5041554C2020202020205E30383034333231303030303030303732353030303030303F00000000

Note: As you’re probably already aware, this algorithm is best described using big numbers, which can’t be represented as literals in some programming languages (like Java or C#). However, many languages have classes that allow you to represent big numbers in other ways (e.g., java.math.BigInteger, System.Numerics.BigInteger). It’s your job to adapt this algorithm so that it can be represented in your language of choice. Two small problems I encountered were ensuring the correct endianness and signedness were being used (this algorithm requires the byte order to be big endian and that unsigned integers are used). I made a utility class called BigInt to do this for me.

First, let’s define a few standard functions:

DES and Triple DES refer to their respective cryptographic algorithms. Most programming languages have access to some implementation of these ciphers either through OpenSSL or Bouncy Castle. These ciphers are initialized with a zeroed out IV of 8 bytes, they’re zero-padded, and use Cipher-Block Chaining (CBC). Let’s define the signatures for these standard functions that’ll be used throughout this algorithm:
- DesEncrypt(key, message) -> returns cryptogram
- DesDecrypt(key, cryptogram) -> returns message
- TripleDesEncrypt(key, message) -> returns cryptogram
- TripleDesDecrypt(key, cryptogram) -> returns message

First we must create the IPEK given then KSN and BDK:

CreateIpek(ksn, bdk) {
    return TripleDesEncrypt(bdk, (ksn & KsnMask) >> 16) << 64 
         | TripleDesEncrypt(bdk ^ KeyMask, (ksn & KsnMask) >> 16)
}

Now we can get the IPEK:

ipek = CreateIpek(ksn, bdk)
     = CreateIpek(FFFF9876543210E00008, 0123456789ABCDEFFEDCBA9876543210)
     = 6AC292FAA1315B4D858AB3A3D7D5933A

After that we need a way to get the Session Key (this one is more complicated):

CreateSessionKey(ipek, ksn) {
    return DeriveKey(ipek, ksn) ^ FF00000000000000FF
}

The DeriveKey method finds the IKSN and generates session keys until it gets to the one that corresponds to the current KSN. We define this method as:

DeriveKey(ipek, ksn) {
    ksnReg = ksn & FFFFFFFFFFE00000
    curKey = ipek
    for (shiftReg = 0x100000; shiftReg > 0; shiftReg >>= 1)
        if ((shiftReg & ksn & 1FFFFF) > 0)
            curKey = GenerateKey(curKey, ksnReg |= shiftReg)
    return curKey
}

Where the GenerateKey method looks like:

GenerateKey(key, ksn) {
    return EncryptRegister(key ^ KeyMask, ksn) << 64 
         | EncryptRegister(key, ksn)
}

And EncryptRegister looks like:

EncryptRegister(key, reg) {
    return (key & FFFFFFFFFFFFFFFF) ^ DesEncrypt((key & FFFFFFFFFFFFFFFF0000000000000000) >> 64, 
                                                  key & FFFFFFFFFFFFFFFF ^ reg)
}

Then you can generate the Session Key given the IPEK and KSN:

key = CreateSessionKey(ipek, ksn)
    = CreateSessionKey(6AC292FAA1315B4D858AB3A3D7D5933A, FFFF9876543210E00008)
    = 27F66D5244FF621EAA6F6120EDEB427F

Which can be used to decrypt the cryptogram:

message = TripleDesDecrypt(key, cryptogram)
        = TripleDesDecrypt(27F66D5244FF621EAA6F6120EDEB427F, C25C1D1197D31CAA87285D59A892047426D9182EC11353C051ADD6D0F072A6CB3436560B3071FC1FD11D9F7E74886742D9BEE0CFD1EA1064C213BB55278B2F12)
        = 2542353435323330303535313232373138395E484F47414E2F5041554C2020202020205E30383034333231303030303030303732353030303030303F00000000
        = %B5452300551227189^HOGAN/PAUL      ^08043210000000725000000?

That’s it, you’re done!

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!

ATM Pin encryption using 3DES

Introduction

Most modern ATM’s use a Triple Des algorithm to encrypt the pin and send it to a host server for processing. Once the host system receives the pin, it does a translation of the pin from one encryption key to another, and sends it to a bank. In this post I will attempt to explain the process and how it is done in the real world.

Overview of the Triple Data Encryption Standard

What we all call Triple DES is EDE (encrypt, decrypt, encrypt). The way that it works is that you take three 56-bit keys, and encrypt with K1, decrypt with K2 and encrypt with K3. There are two-key and three-key versions. Think of the two-key version as merely one where K1=K3. Note that if K1=K2=K3, then Triple DES is really Single DES.

Triple DES was created back when DES was getting a bit weaker than people were comfortable with. As a result, they wanted an easy way to get more strength. In a system dependent on DES, making a composite function out of multiple DESes is likely to be easier than bolting in a new cipher and sidesteps the political issue of arguing that the new cipher is better than DES.

As it turns out, when you compose a cipher into a new one, you can’t use a double enciphering. There is a class of attacks called meet-in-the-middle attacks, in which you encrypt from one end, decrypt from the other, and start looking for collisions (things that give you the same answer). With sufficient memory, Double DES (or any other cipher) would only be twice as strong as the base cipher — or one bit more in strength.

There’s more to it. If the cipher forms a group, then encrypting twice with two keys is equivalent to encrypting once with some key. Now, it’s not trivial to know what that other key is, but it means that a brute-force attack would find that third key as it tried all possible single-keys. So if the cipher’s a group, then multiple-ciphering is merely a waste of time.

Applying this encryption in Python is trivial as there are plenty of tested libraries that can provide the functionality like pyDes and Crypto :

import os
from Crypto.Cipher import DES3

def encrypt_file(in_filename, out_filename, chunk_size, key, iv):
    des3 = DES3.new(key, DES3.MODE_CFB, iv)

    with open(in_filename, 'r') as in_file:
        with open(out_filename, 'w') as out_file:
            while True:
                chunk = in_file.read(chunk_size)
                if len(chunk) == 0:
                    break
                elif len(chunk) % 16 != 0:
                    chunk += ' ' * (16 - len(chunk) % 16)
                out_file.write(des3.encrypt(chunk))

def decrypt_file(in_filename, out_filename, chunk_size, key, iv):
    des3 = DES3.new(key, DES3.MODE_CFB, iv)

    with open(in_filename, 'r') as in_file:
        with open(out_filename, 'w') as out_file:
            while True:
                chunk = in_file.read(chunk_size)
                if len(chunk) == 0:
                    break
                out_file.write(des3.decrypt(chunk))

ATM Internals and how they calculate the keys

When you have an ATM, you typically need to provide it with a set of encryption keys from your host, or HSM. These keys are clear text keys and it’s not encrypted in any way. Your host will link them to your terminal number, and when the ATM encrypts the pin; the host will know what keys are used so it can decrypt / translate them to the bank. The clear keys are never stored by the host, only the LMK encrypted keys.

Lets assume your host provides the following keys to you as the ‘ATM Encryption Key’ :

Clear component A: 67C4 A719 1ADA FD08 6432 CE0D D638 4AB

Key check value: 20D40B

Clear component B: 8A89 6D4C 4625 5E2A 1A75 2002 07A7 D35E

Key check value: 4EC801

Combined Check Value: 2B547D

Now typically you would enter the clear components into the ATM, as Encryption keys, and the ATM will combine them (Basically XOR Them) and derive the check value. If the check value match, then all is good.

What happens at your host end is the following:

Your host will also combine the keys and encrypt them under the LMK (Local Master Key). It will then use this key to encrypt all other keys that are sent to the ATM.

Now the ATM have a Terminal Master Key that it can use to decrypt all keys that are sent to it from the host.

ATM Configuration Request (Key Exchange)

Now when an ATM starts up, the first thing it does it send a configuration request to the host. This request is to get the Third key used in Triple DES. The Host will generate a random Terminal Pin Key and encrypt it under the Terminal Master Key (TMK). Since the ATM has the Terminal Master Key, it can decrypt the encrypted TPK, and use all 3 Keys now for the Triple DES operations. (it actually uses 2)

The Host would generally execute the A0 Thales command to get this key. He would store the key in the key database to do the decryption / translation later.

Pin Encryption / Decryption

When a ATM gets ready to transmit a transaction it does the 3DES operation on the Pin only. the cypher text is now transmitted to the host. The host never knows the pin code, and only does a translation of the pin from the terminal keys to the bank keys.

The Host will have the following:

(ZPK) Zone Pin Key – from the Bank during Host to Bank Key exchange

(TPK) Terminal Pin Key – from Terminal using Terminal Configuration Request

(PAN) Account Number – from Transaction transmitted.

With these values, the Host can translate the pin using a HSM, below is an example of the D4 Command.

 Res = KeyGenerator.TranslatePIN_TDES(TerminalPINKey=self.Crypto["TPK_LMK"], PINEncryptionKey=self.HostKeys["ZPK_LMK"], PINBlock=self.iso.getBit(52), AccountNumber=track2["PAN"][-13:-1])

def get_commandTPKPinBlock(self, TerminalPINKey, PINEncryptionKey, PINBlock, AccountNumber):

 command_code = 'D4'
 KTP = TerminalPINKey
 KPE = PINEncryptionKey
 PinBlock = PINBlock
 PAN = AccountNumber


 message = command_code
 message += KTP
 message += KPE
 message += PinBlock
 message += PAN
 return message
#transmit to HSM

The transaction can now be transmitted to the acquiring bank with the translated pin for processing.

Sometimes the ATM requires a Message Authentication Code, this will be covered in another post.

easy as pie

Implementing AS2805 Part 6 Host to Host Encryption using a Thales 9000 and Python

Introduction

The AS2805.6 Standard specifies communication security between two nodes during a financial transaction. These nodes needs to have a specific set of encryption algorithms, and needs to follow a specific process.

The specification is not very clear on what exactly needs to happen, so I intend to clarify the exact steps, with the HSM functions. Now in order to do this I will assume you have a Thales 9000 HSM, as well as you need to know how to properly operate it. All commands defined are in the 1270A547-015 Australian Standards LIC003 v2.3a.pdf Manual provided by Thales when purchasing the device.

Source Code

a Copy of this Manual can be found here [Thales 9000 Australian Standards LIC003 v2.3a]

a Copy of my AS2805 parser is located here

a Copy of my Thales commands class is located here

a Full version of a AS2805 Interchange Node is located here

KEK Process (Level 1)

For this process:

you need to go to your HSM and generate 2 Clear components, you then need to form a KEKs key from these components. This can be done using the UI of the HSM manger, or with the FK console command.
Store the KEKs formed from the clear components in your switch database.
Your connecting node / host will then provide you with a set of clear components, you need to generate a key again, but in this case a KEKr
You need to provide you host with your key components you generated in Step 1,so they can generate their corresponding KEKs.

Now you have a KEKr and a KEKs in your database as well as your host read, for Level2

Session and MAC key Initialisation (Level 2)

This Level has 2 separate steps, the first step (Logon) validating the KEKr and KEKs so that both nodes know that the correct keys are being used. The second step (Key Exchange) is to create temporary keys that are changed every 60 minutes or 256 transactions.

Logon Process

During the logon process your HSM will need to generate 2 things:

a Random Number (RN)
an Inverted Random Number (~RN)

These numbers will be returned encrypted under the KEKr and KEKs, and you will need to validate them, this is also called end of proof point validation.

The Logon process is a 2 step process outlined in the image below.

Step 1

When you connect to your host you will receive a logon request, bit number 48 will be populated with a KRs from the host that you will need to validate with your KEKr.

Generating a KEKr Validation Response you would need your KRs received in this request, and you KEKr that you generated from your host components.

E2 Command Definition: To receive a random key (KRs) encrypted under a variant of a double length Key Encrypting Key (KEKr), compute from KRs another value, denoted KRr and encrypt it under another variant of the KEKr

Your HSM command will look as follows: >HEADE2{KEKr}{KRs} and you output will generate a KEKr. Your response to the host will need to include this value in bit number 48.

Step 2

You now need to send the host a logon request with bit 48 set with your KRs

E0 Command Definition:To generate a random key (KRs) and encrypt it with a variant of a double length Key Encrypting Key (KEKs). In addition, KRs is inverted (to form KRr) and the result encrypted with another variant of the KEKs.

Your HSM command will look as follows: >HEADE0{KEKs} and the output will generate a KRs. Your host will validate this request, and return with a response.

Once both steps are complete, both you and the host has been validated that you are using the same keys.

An Example of this process is outlined below in Python:

 def __signon__Part1__(self):
 self.log.info("====Sign-On Process Started ====")
 self.__setState('signing_on')
 cur = self.con_switch.cursor(MySQLdb.cursors.DictCursor)

 try:
 self.log.info("Waiting for 0800 Request")
 self.s.settimeout(20.0)
 length_indicator = self.s.recv(2)
 if length_indicator == '':
 self.log.critical('Received a blank length indicator from switch... might be a disconnect')
 self.__setState("blank_response")
 else:
 size = struct.unpack('!H', length_indicator)[0]
 payload = self.s.recv(size)
 payload = ByteUtils.ByteToHex(payload)
 d = datetime.now()
 self.log.info(" Getting Sign-On Request 0800 = [%s]" % payload)
 if payload == '':
 self.log.critical('Received a blank response from switch... might be a disconnect')
 self.__setState("blank_response")
 else:
 iso_ans = AS2805(debug=False)
 iso_ans.setIsoContent(payload)


 self.__storeISOMessage(iso_ans, {"date_time_received": d.strftime("%Y-%m-%d %H:%M:%S")})
 if iso_ans.getMTI() == '0800':
 if iso_ans.getBit(70) == '001':
 #log.info("Logon Started with KEKr = %s, KEKs = %s" % ( self.KEKr, self.KEKs))
 KRs = iso_ans.getBit(48)
 #log.info("KRs %s Received from Host" % (KRs))
 #print "Generating a E0 Command with KEKr=%s, and KRs=%s" % (self.KEKr, KRs)
 self.ValidationResponse = KeyGenerator.Generate_KEKr_Validation_Response(KEKr=self.KEKr, KRs=KRs)
 #print self.ValidationResponse

 if self.ValidationResponse["ErrorCode"] == '00':
 #log.info("KRs Validation Response %s generated" % (self.ValidationResponse["KRr"]))
 d = datetime.now()
 iso_resp = AS2805(debug=False)
 iso_resp.setMTI('0810')
 iso_resp.setBit(7, d.strftime("%m%d%H%M%S"))
 iso_resp.setBit(11, iso_ans.getBit(11))
 iso_resp.setBit(33, self.Switch_IIN)
 iso_resp.setBit(39, '303')
 iso_resp.setBit(48, self.ValidationResponse["KRr"])
 iso_resp.setBit(70, '0001')
 iso_resp.setBit(100, self.Switch_IIN)

 iso_send = iso_resp.getNetworkISO()
 iso_send_hex = ByteUtils.HexToByte(iso_send[2:])
 self.log.info("Sending Sign-On Response 0810 [%s]" % ReadableAscii(iso_send))
 self.__send_message(iso_send_hex)
 self.__storeISOMessage(iso_resp, {"date_time_sent": d.strftime("%Y-%m-%d %H:%M:%S")})
 self.__setState('signed_on')
 else:
 self.log.error("0810 KRr Response Code = %s, Login Failed" % (self.ValidationResponse["ErrorCode"],))
 #TODO: Send Decline to the Partner

 else:
 self.log.error("Could not login with 0810")



 except InvalidAS2805, ii:
 self.log.error(ii)
 except socket.error as e:
 pass
 self.log.debug("nothing from host [%s]" % (e))
 except:
 #self.__signoff()
 self.log.exception("signon_failed")
 self.__setState("singon_failed")
 finally:
 cur.close()

 def __signon_Part2__(self):

 try:
 self.s.settimeout(20.0)
 self.ValidationRequest = KeyGenerator.Generate_KEKs_Validation_Request(KEKs=self.KEKs)
 d = datetime.now()
 iso_resp = AS2805(debug=False)
 iso_resp.setMTI('0800')
 iso_resp.setBit(7, d.strftime("%m%d%H%M%S"))
 iso_resp.setBit(11, self.__getNextStanNo())
 iso_resp.setBit(33, self.HostIIN)
 iso_resp.setBit(48, self.ValidationRequest["KRs"])
 iso_resp.setBit(70, '001')
 iso_resp.setBit(100, self.HostIIN)
 iso_send = iso_resp.getNetworkISO()
 iso_send_hex = ByteUtils.HexToByte(iso_send[2:])

 self.log.info("Sending Sign-On Request 0800 [%s]" % ReadableAscii(iso_send))
 self.__send_message(iso_send_hex)
 self.__storeISOMessage(iso_resp, {"date_time_sent": d.strftime("%Y-%m-%d %H:%M:%S")})

 self.log.info("Waiting for 0810 Response")
 a = self.s.recv(8192)
 payload = ByteUtils.ByteToHex(a[2:])
 d = datetime.now()
 self.log.info(" Getting Sign-On Response 0810 = [%s]" % payload)
 iso_ans = AS2805(debug=False)
 iso_ans.setIsoContent(payload)
 self.log.debug(iso_ans.dumpFields())
 self.__storeISOMessage(iso_ans, {"date_time_received": d.strftime("%Y-%m-%d %H:%M:%S")})
 if iso_ans.getBit(39) == '3030':
 self.log.info("====Sign-On Sequence Completed Successfully====")
 self.__setState("signed_on_dual")
 else:
 #self.__signoff()
 self.log.error("Could not login with 0800")
 self.__setState("singon_failed")
 except InvalidAS2805, ii:
 self.log.info(ii)
 except socket.error as e:
 self.log.info("nothing from host [%s]" % (e))
 except:
 #self.__signoff()
 self.log.exception("signon_failed")
 self.__setState("singon_failed")

Key Exchange (Level 2)

In the Key Exchange process, you will generate session keys for your node as well as MAC keys. Now when generating these keys, you need to remember that they need to be the same type as you partner node. (simply ask your processor for a trace if you want to confirm)

So right after a successful logon, you would need to wait for a key exchange request, (0820 with field 30 as 303) this key exchange request will have a ZAK and a ZPK in field 48, these are encrypted under the KEKr generated on your host from their components. You would need to translate these keys using your KEKr under your LMK and generate check values for verification.

The command will look like follows: >HEADOK{KEKr}21H{ZPK}1H{ZAK}0H11111111111111111111111111111111

These keys are known as your: RECEIVE KEYS

Where the KEKr is the KEKr generated from your components, ZPK and ZAK is the ZPK and ZAK received. This will output the following:

def Translate_a_Set_of_Zone_Keys(KEKr, ZPK, ZAK, ZEK):
 response = KeyClass.execute_Translate_a_Set_of_Zone_Keys(KEKr, ZPK, ZAK, ZEK)
 #print response
 TranslatedZoneKeys = {}
 TranslatedZoneKeys["Header"] = response[2:6]
 TranslatedZoneKeys["ResponseCode"] = response[6:8]
 TranslatedZoneKeys["ErrorCode"] = response[8:10]
 if TranslatedZoneKeys["ErrorCode"] == '00':
 TranslatedZoneKeys["KCV Processing Flag"] = response[10:11]
 TranslatedZoneKeys["ZPK(LMK)"] = response[11:44]
 TranslatedZoneKeys["ZPK Check Value"] = response[44:50]
 TranslatedZoneKeys["ZAK(LMK)"] = response[50:83]
 TranslatedZoneKeys["ZAK Check Value"] = response[83:89]
 TranslatedZoneKeys["ZEK(LMK)"] = response[89:122]
 TranslatedZoneKeys["ZEK Check Value"] = response[122:128]
 return TranslatedZoneKeys

In other words, you need to generate the same keys, but under your LMK and store them in your key database

Now whenever you get a request from your host with a mac you can validate the mac using the ZAK(LMK), and when you get encrypted values from your host you can translate the values using the ZPK(LMK)

So, when you respond to the key exchange process you put the check values in field 40. Your host will validate the check values, and then wait for you to send a request using your KEKs.

Here is an implementation using Python:

def __key_exchange_listen(self):
 self.log.info("===== Key Exchange process Started =======")
 self.s.settimeout(20.0)
 length_indicator = self.s.recv(2)
 if length_indicator == '':
 self.log.critical('Received a blank length indicator from switch... might be a disconnect')
 self.__setState("blank_response")
 else:
 size = struct.unpack('!H', length_indicator)[0]
 payload = self.s.recv(size)
 payload = ByteUtils.ByteToHex(payload)
 d = datetime.now()
 self.log.info(" Receiving Key Exchange Request = [%s]" % payload)
 if payload == '':
 self.log.critical('Received a blank response from switch... might be a disconnect')
 self.__setState("blank_response")
 else:
 iso_ans = AS2805(debug=False)
 iso_ans.setIsoContent("%s" % (payload))
 self.log.debug(iso_ans.dumpFields())

 self.__storeISOMessage(iso_ans, {"date_time_received": d.strftime("%Y-%m-%d %H:%M:%S")})
 if iso_ans.getMTI() == '0820' and iso_ans.getBit(70) == '0101':
 Value = iso_ans.getBit(48)
 self.ZAK = Value[:32]
 self.ZPK = Value[32:]

 self.node_number = iso_ans.getBit(53)
 log.info("Recieve Keys under ZMK : ZAK= %s, ZPK = %s" % (self.ZAK, self.ZPK ))

 self.ZoneKeySet2 = KeyGenerator.Translate_a_Set_of_Zone_Keys(self.KEKr,ZPK=self.ZPK, ZAK=self.ZAK, ZEK='11111111111111111111111111111111')
 cur = self.con_switch.cursor(MySQLdb.cursors.DictCursor)
 sql = """UPDATE sessions_as2805 set
 ZPK_LMK = '%s',
 ZPK_ZMK = '%s',
 ZPK_Check ='%s',
 ZAK_LMK = '%s' ,
 ZAK_ZMK = '%s',
 ZAK_Check = '%s',
 ZEK_LMK = '%s',
 ZEK_Check = '%s',
 keyset_number = '%s'
 WHERE host_id = '%s' and keyset_description = 'Recieve' """ %\
 (
 self.ZoneKeySet2["ZPK(LMK)"],
 self.ZPK,
 self.ZoneKeySet2["ZPK Check Value"],
 self.ZoneKeySet2["ZAK(LMK)"],
 self.ZAK,
 self.ZoneKeySet2["ZAK Check Value"],
 self.ZoneKeySet2["ZEK(LMK)"],
 self.ZoneKeySet2["ZEK Check Value"],
 self.node_number,
 self.host_id)
 log.info("Recieve Keys under LMK : ZAK= %s, ZAK Check Value: %s ZPK = %s, ZPK Check Value: %s" % (self.ZoneKeySet2["ZAK(LMK)"], self.ZoneKeySet2["ZAK Check Value"], self.ZoneKeySet2["ZPK(LMK)"], self.ZoneKeySet2["ZPK Check Value"]))
 cur.execute(sql)
 self.log.debug("Records=%s" % (cur.rowcount,))
 iso_req = AS2805(debug=False)
 iso_req.setMTI('0830')
 iso_req.setBit(7, iso_ans.getBit(7))
 iso_req.setBit(11, iso_ans.getBit(11))
 iso_req.setBit(33, iso_ans.getBit(33))
 iso_req.setBit(39, '303')
 iso_req.setBit(48, self.ZoneKeySet2["ZAK Check Value"] + self.ZoneKeySet2["ZPK Check Value"])
 iso_req.setBit(53, iso_ans.getBit(53))
 iso_req.setBit(70, iso_ans.getBit(70))
 iso_req.setBit(100, iso_ans.getBit(100))
 self.__storeISOMessage(iso_req, {"date_time_sent": d.strftime("%Y-%m-%d %H:%M:%S")})
 try:

 iso_send = iso_req.getNetworkISO()
 iso_send_hex = ByteUtils.HexToByte(iso_send[2:])

 self.log.debug(iso_req.dumpFields())
 self.log.info("Sending Key Exchange Response = [%s]" % ReadableAscii(iso_send))
 self.__send_message(iso_send_hex)
 self.node_number = iso_ans.getBit(53)
 except:
 self.log.exception("key_exchange_failed")
 self.__setState('key_exchange_failed')

 finally:
 cur.close()

These Keys are known as your SEND KEYS

So when you send a key exchange request you would need to generate a set of zone keys, this command on your HSM would look like this;

>HEADOI{KEKs};HU;1

Where the KEKs is the KEKs that you generated from your components, and your output will be the following:

def Generate_a_Set_of_Zone_Keys(KEKs):
 response = KeyClass.execute_get_a_Set_of_Zone_Keys(KEKs)
 #print response
 ZoneKeys = {}
 ZoneKeys["Header"] = response[2:6]
 ZoneKeys["ResponseCode"] = response[6:8]
 ZoneKeys["ErrorCode"] = response[8:10]
 if ZoneKeys["ErrorCode"] == '00':
 ZoneKeys["ZPK(LMK)"] = response[10:43]
 ZoneKeys["ZPK(ZMK)"] = response[43:76]
 ZoneKeys["ZPK Check Value"] = response[76:82]
 ZoneKeys["ZAK(LMK)"] = response[82:115]
 ZoneKeys["ZAK(ZMK)"] = response[115:148]
 ZoneKeys["ZAK Check Value"] = response[148:154]
 ZoneKeys["ZEK(LMK)"] = response[154:187]
 ZoneKeys["ZEK(ZMK)"] = response[187:220]
 ZoneKeys["ZEK Check Value"] = response[220:226]
 return ZoneKeys

Now when sending your 0820 request, you need to set field 40 as ZAK(ZMK) + ZPK(ZMK). Your host will do a Validation request (same as you did in step 1) and send you the check values. you need to compare this to the check values generated by your OI command, and if they match then you have successfully exchanged keys.

Below is an implementation using Python:

 def __keyExchange__(self):
 self.__setState("key_exchange")

 self.__key_exchange_listen()


 cur = self.con_switch.cursor(MySQLdb.cursors.DictCursor)
 d = datetime.now()
 self.ZoneKeySet1 = {}
 self.ZoneKeySet2 = {}
 self.ZoneKeySet1 = KeyGenerator.Generate_a_Set_of_Zone_Keys(self.KEKs)


 iso_req = AS2805(debug=False)
 iso_req.setMTI('0820')
 iso_req.setBit(7, d.strftime("%m%d%H%M%S"))
 iso_req.setBit(11, self.__getNextStan())
 iso_req.setBit(33, self.HostIIN)
 iso_req.setBit(48, self.ZoneKeySet1["ZAK(ZMK)"][1:] + self.ZoneKeySet1["ZPK(ZMK)"][1:])
 iso_req.setBit(53, self.node_number)
 iso_req.setBit(70, '101')
 iso_req.setBit(100, self.SwitchLink_IIN)
 self.__storeISOMessage(iso_req, {"date_time_sent": d.strftime("%Y-%m-%d %H:%M:%S")})
 log.info("Send Keys under LMK : ZAK= %s, ZAK Check Value: %s ZPK = %s, ZPK Check Value: %s" % (self.ZoneKeySet1["ZAK(LMK)"], self.ZoneKeySet1["ZAK Check Value"], self.ZoneKeySet1["ZPK(LMK)"], self.ZoneKeySet1["ZPK Check Value"]))

 try:

 # send the Send Keys
 iso_send = iso_req.getNetworkISO()
 iso_send_hex = ByteUtils.HexToByte(iso_send[2:])

 self.log.debug(iso_req.dumpFields())
 self.log.info("Sending Key Exchange Request = [%s]" % ReadableAscii(iso_send))
 self.__send_message(iso_send_hex)

 self.s.settimeout(20.0)
 length_indicator = self.s.recv(2)
 if length_indicator == '':
 self.log.critical('Received a blank length indicator from switch... might be a disconnect')
 self.__setState("blank_response")
 else:
 size = struct.unpack('!H', length_indicator)[0]
 payload = self.s.recv(size)
 payload = ByteUtils.ByteToHex(payload)
 d = datetime.now()
 self.log.info(" Receiving Key Exchange Response = [%s]" % payload)
 if payload == '':
 self.log.critical('Received a blank response from switch... might be a disconnect')
 self.__setState("blank_response")
 else:
 iso_ans = AS2805(debug=False)
 iso_ans.setIsoContent(payload)
 self.log.debug(iso_ans.dumpFields())
 self.__storeISOMessage(iso_ans, {"date_time_received": d.strftime("%Y-%m-%d %H:%M:%S")})

 if iso_ans.getMTI() == '0830':
 if iso_ans.getBit(39) == '3030':

 Value = iso_ans.getBit(48)
 self.KMACs_KVC = Value[:6]
 self.KPEs_KVC = Value[6:]
 #self.log.info("KMACs_KVC = %s, KPEs_KVC = %s" % (self.KMACs_KVC, self.KPEs_KVC))
 if self.KMACs_KVC == self.ZoneKeySet1["ZAK Check Value"] and self.KPEs_KVC == self.ZoneKeySet1["ZPK Check Value"]:
 self.log.info("0820 Key Exchange successful: Check Values Match, ZAK Check Value= %s , ZPK Check Value = %s" % (self.ZoneKeySet1["ZAK Check Value"], self.ZoneKeySet1["ZPK Check Value"]))
 sql = """UPDATE sessions_as2805
 SET
 ZPK_LMK = '%s',
 ZPK_ZMK = '%s',
 ZPK_Check= '%s' ,
 ZAK_LMK= '%s',
 ZAK_ZMK = '%s',
 ZAK_Check ='%s',
 ZEK_LMK = '%s' ,
 ZEK_ZMK = '%s',
 ZEK_Check = '%s',
 keyset_number = '%s'
 WHERE host_id = '%s' and keyset_description = 'Send' """%\
 ( self.ZoneKeySet1["ZPK(LMK)"],
 self.ZoneKeySet1["ZPK(ZMK)"],
 self.ZoneKeySet1["ZPK Check Value"],
 self.ZoneKeySet1["ZAK(LMK)"],
 self.ZoneKeySet1["ZAK(ZMK)"],
 self.ZoneKeySet1["ZAK Check Value"],
 self.ZoneKeySet1["ZEK(LMK)"],
 self.ZoneKeySet1["ZEK(ZMK)"],
 self.ZoneKeySet1["ZEK Check Value"],
 self.node_number,
 self.host_id)

 cur.execute(sql)
 self.log.debug("Records=%s" % (cur.rowcount,))
 self.__setState("key_exchanged")

 self.__setState('session_key_ok')
 self.log.info("==== Key Exchange Sequence Completed Successfully====")
 self.last_key_exchange = datetime.now()

 else:
 self.log.error("Generate_a_Set_of_Zone_Keys: KVC Check Failed!!")
 else:
 self.log.error("0820 Response Code = %s, Key Exchange Failed" % (iso_ans.getBit(39)))
 except InvalidAS2805, ii:
 self.log.error(ii)
 self.s.close()
 self.s = None
 self.__setState("session_key_fail")
 except:
 self.log.exception("key_exchange_failed")
 self.__setState('key_exchange_failed')

Now that keys have successfully been exchanged, you can start submitting transactions.

When sending transactions encrypt data (pin / field) Send Keys, and when receiving data translate / decrypt using your receive keys, Generate MAC using Send MAC and Verify using Receive MAC.

TAK – Your key to generate and verify MACs
TEK – Your key to encrypt data and decrypt / translate

This concludes the implementation of Node to Node interfaces using AS2805 Standards.

Easy as Pie!

Typical Cryptography in AS2805 Explained

Key Management conforms to AS 2805 part 6.1.

KEK Establishment

Each interchange node contains an Interchange Send Key Encrypting Key (KEKs) and an Interchange Receive Key Encrypting Key (KEKr). The Interchange Send KEK is the same key as the Interchange Receive KEK in the partnering node, similarly the Interchange Receive KEK is the same as the Interchange Send KEK in the partnering node.

The Interchange Key Encrypting Keys are used to encipher and decipher the session keys when they are transmitted between the nodes and in the proof of end points process.

Interchange Key Encrypting Keys is statistically unique and shall be changed, at a minimum, once every two years.

Node A		Node B
KEKs	=		KEKr
KEkr	=		KEKs

Session Keys

Each node keeps four sets of session keys, two send sets and two receive sets.

Each set of session keys consists of two keys, MAC Key, PIN Protect Key. Each session key is 128-bits long and stored in a secure manner.

The send session key sets are generated by the sending node and numbered “1” or “2”. The send session key sets are then forwarded to the receiving node to be used as the receive session key sets.

The receive session key sets are received in a 0820 Network Management Advice message with bit ‘070’ equal to 101 from the sending node. The set number of either “1” or “2” contained in bit 53 indicates the receive session key set used by the receiving node to verify the MAC, decipher the data and translate or verify the PIN.

One set of send session keys is used at a time and all Transactions sent from the sending node will generate the MAC and encipher the PIN, if present, using the MAC Generator Key and PIN Protect Key, respectively, from the same send session key set. The send session key set used is indicated by bit 53 (contains “1” or “2”) in each message. Session Keys must be statistically unique and replaced, at a minimum, once every hour or on every 256 Transactions, whichever occurs first.

Node A		Node B
Send Session Keys Set 1		Receive Session Keys Set 1
MAC Key (KMACs1)	=		MAC Verification Key (KMACr1)
PIN Protect Key (KPEs1)	=		PIN Protect Key (KPEr1)
Send Session Keys Set 2		Receive Session Keys Set 2
MAC Key (KMACs2)	=		MAC Verification Key (KMACr2)
PIN Protect Key (KPEs2)	=		PIN Protect Key (KPEr2)
Receive Session Keys Set 1		Send Session Keys Set 1
MAC Verification Key (KMACr1)	=		MAC Key (KMACs1)
PIN Protect Key (KPEr1)	=		PIN Protect Key (KPEs1)
Receive Session Keys Set 2		Send Session Keys Set 2
MAC Verification Key (KMACr2)	=		MAC Key (KMACs2)
PIN Protect Key (KPEr2)	=		PIN Protect Key (KPEs2)

When enciphered for transmission, each session key type will use a unique variant of the Key Enciphering Key in accordance with AS 2805 part 6.1 request response (logon) from the other before starting any other message exchange. When ready to logon, a party should attempt to logon and continue to attempt to logon until a successful response has been received. Upon receipt of an unsolicited logon (i.e. receiving a logon message when in an assumed logged on state) or a message with a response code indicating an irrecoverable error, a party should send an immediate logoff message and attempts to logon should be made as soon as possible. All logon response messages should be inspected to ensure that the response code indicates a successful logon

Changing Session keys

While one set of send session keys is being used, the other send session key set is randomly generated by the sending node and their KVCs generated, the keys are then enciphered under the Interchange Send KEK and transmitted to the receiving node in a 0820 Network Management Advice message.

When a 0820 message is received by the receiving node, the session keys are deciphered using the Interchange Receive KEK. These deciphered keys are set up as the set of receive keys specified by the set number contained in bit 53 of the 0820 message. The Key Verification Codes (KVCs) are calculated by the receiving node and transmitted to the sending node in bit 48 of the 0830 message.

When the 0830 Network Management Advice response message is received at the node initiating the key change, the KVCs contained in the 0830 message are validated. If the KVCs are correct, the new send session key set can be used immediately. If the KVCs are invalid, new send session key set must be generated and the whole process is repeated.

Sign off

Either node may terminate the transmission of financial messages by sending a Sign Off Advice. A Sign Off is accomplished by the transmission of a 0820 Network Management Advice Message with a NMIC (Bit 70) equal to ‘002’.

Key change during normal processing

A session key change can occur at any time; each node independently initiates the change of their send keys. The sender will advise their sending session keys to the receiver using a 0820 Network Management Advice message with a NMIC equal to ‘101’ indicating key change. Once a valid response (0830 message) is received and the KVCs confirmed, the new keys can be used.

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!