Tag Archives: MAC

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);

(c) Key Encrypting Keys (KEK) – used to protect other keys (e.g. session keys) during exchange; or

(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;

(c) Security of transactions from terminal to Acquirer and from Acquirer to Issuer complies with AS2805 Part 6;

(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

(c) all interchange PIN and MAC cryptographic functions must be performed within a Tamper-responsive SCM

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:

|OUR-Key|OUR-PVC|THEIR-Key|THEIR-PVC|THEIR-MAC|GEN-PVC|

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!