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!