Atalla variants

Oct 20, 2011 at 5:03 PM

First, thanks for this simulator. Works great.

One thing I noticed though is that there is no support for the Atalla variants when importing keys from an HSM that applied the variant on export. I am trying to implement this feature but I do not have all Atalla variants(specially the ATM one).

This is what I have:

0: No change

1: Pin Key - 0x08 (i.e. 0800000000000000 is XOR for each key part)

2:DPK - 0x10

3: MPK: 0x18

4:PIN verification Key: ?

5: ATM: ?

There are more but personally only need the one for ATM.

The first 3 work fine when I test using our Futurex HSM device, plus also tested variant 1 with a key that came from an outside network that uses Atalla. What I need now at least is that variant to apply to ATM Keys (TMK) so that I can import those properly.

Do you know what I need to use?

Oct 20, 2011 at 5:09 PM

Forgot to mention that I tried to apply variants from 0x00 to 0xFF with no luck (hopefully did not make a mistake here). I am guessing that the ATM variant algorithm is different from the others.

Oct 20, 2011 at 7:33 PM

That's correct, Atalla variants are not supported. The main reason for this is that I've no clue how to implement that feature! Any ideas?

Oct 20, 2011 at 7:46 PM

Ideas yes.

For example in the case we are importing a ZPK from a network that used Atalla. We need to XOR the clear ZMK value with "0800000000000000" before trying to decrypt the ZPK. This is the most common usage.

In my case I also need to import TMKs and don't know what value to XOR with the clear ZMK.

The values above are good for:

Pin Encryption Keys (0x08)

Data Encryption (0x10)

MAC Keys (0x18)

Hope this helps.

Oct 20, 2011 at 7:59 PM

Is there some kind of documentation describing these? If XORing is all that's needed perhaps a moderate change in the HexKey class would be enough, provided of course that all XML message descriptions are amended.

Oct 20, 2011 at 8:21 PM

I don have any documentation. Only stuff that I found posted on forums, specifically this This is were I extracted those variants. Then I went and tested it specially the ZPK decryption.

For example:

Note: All these are test values.

If you have a clear ZMK (0123456789ABCDEFFEDCBA9876543210)

And then you receive an encrypted ANSI TPK from an Atalla device (39BF9032CE641ABA1824708B06B4C301) and you are told that the clear TPK has a checksum of 0A2F

You have to XOR 0123456789ABCDEFFEDCBA9876543210 and 08000000000000000800000000000000 and the resulting value should be used to decrypt the TPK.

I wish someone would know what is the variant for TMK though.

Oct 20, 2011 at 8:37 PM

I'll have a look at that url and I'll post back.

Oct 20, 2011 at 8:52 PM

I wish someone would know what is the variant for TMK though.

Variant Description

0 Key Exchange Key (KEK,KEK-IN)
0 Configuration Table Key (CTK)
1 PIN Encryption Key (KPE)
2 Data or Communication Key (KC)
3 Message Authentication Code key (KMAC)
3 VISA Card Verification Value, Mastercard Card Validation Code (KCVV, KCVC)
4 PIN Verification Key (KPV,PVK)
5 ATM A key (AATM)
5 ATM B key (BATM)
5 ATM master key (KMATM, TMK)
5 Object Key (KOP)
6 Initialization Vector (IV)
6 Decimalization/Conversion Table (DECTAB)
7 Challenge Response Authentication Key (KMACR)
8 Derivation Key (DK, BDK)
9 Visa VSVC Master Key / EMV Master Key (VSVCMK)
10 PIN Encryption Key - Encrypt Only (KPE-EO)
11 Custom (MK-DL)
12 Custom (PMK)
13 Master Message Authentication Key (KMACMK)
14 Custom
15 N/A
16 Data Encrypt Only (ENC)
17 Data Decrypt Only (DEC)
18 Generate Message Authentication Code only (GMAC)
19 Verify Message Authentication Code only (VMAC)
20 PIN Encryption Key - Decrypt Only KPE - DO
21 Custom
22 Custom
23 Custom
24 Custom
25 Custom
26 Custom
27 Custom
28 Custom
29 Custom
30 Challenge Data
31 Key Exchange Key - Outgoing KEK-OUT

Oct 20, 2011 at 8:58 PM

Pretty nice list.

I am interested in "5 ATM A key (AATM)" I need to know what hex value or values or algorithm I need to use to apply this variant.

Oct 20, 2011 at 9:19 PM

Multiply the variant number by 0x08 (0x08 * variant 5 = 0x28), then XOR that to the first byte (and 17th byte if 3DES) of the clear key before encrypting or decrypting.

To get an HSM that knows nothing of variants to accomplish the same thing, apply the variant to the clear key before importing into the HSM.

For example, if you're encrypting a TMK under a ZMK, XOR 28000000000000002800000000000000 to the clear ZMK, then import it.

It is also worthwhile noting that a TMK is functionally no different than a ZMK or KEK, which use variant 0 (equivalent to no variant at all since 0x08 * 0 = 0) and the vast majority of ATMs that I'm familiar with do not use variants. The most common use of variants is for storing keys in a database encrypted under the appropriate variant of the MFK. If this is your purpose, abandon using Atalla variants and use the Thales LMK key scheme 'U' which serves the same purpose.

Oct 20, 2011 at 9:57 PM

That is awesome! This is the confirmation I needed.

My data was wrong before because I could not get it to match when I tried that approach. I re-generated the TMK to compare again and the resulting exported cryptograms now match (simulator vs HSM)!

Thank you very much babtras!

Oct 21, 2011 at 9:34 AM

I think that babtras has provided enough information to have a go at it. I'll see how to make this into a feature, at least for import commands.

Oct 22, 2011 at 10:46 PM

Using the information provided by babtras I coded an implementation that allows the use of an Atalla variant with the A6 command. This can be downloaded from here. Eliseoc, it would be nice if you can check it out and let me know if it works as you expect.

Oct 24, 2011 at 1:55 PM

I'll take a look at it.

Oct 24, 2011 at 2:21 PM

Seems like is not liking the format I am using.

My ZMK for this test: 0123456789ABCDEFFEDCBA9876543210

Encypted under ZMK variant: U42BBE7D9A0A55D0EBDE055DE2791ACCD

ZPK I need to import: X39BF9032CE641ABA1824708B06B4C301 The expected Checksum is "0A2F"

Send command: 0000A601U42BBE7D9A0A55D0EBDE055DE2791ACCDX39BF9032CE641ABA1824708B06B4C301U1

Request: 0000A601U42BBE7D9A0A55D0EBDE055DE2791ACCDX39BF9032CE641ABA1824708B06B4C301U1Parsing header and code of message 0000A601U42BBE7D9A0A55D0EBDE055DE2791ACCDX39BF9032CE641ABA1824708B06B4C301U1...Searching for implementor of A6...Found implementor ThalesSim.Core.HostCommands.BuildIn.ImportKey_A6, instantiating...Calling AcceptMessage()...Exception while processing messageSystem.Exception: Invalid value [01U] for field [Key Type].   at ThalesSim.Core.Message.XML.MessageParser.Parse(Message msg, MessageFields fields, MessageKeyValuePairs& KVPairs, String& result)   at ThalesSim.Core.HostCommands.BuildIn.ImportKey_A6.AcceptMessage(Message msg)   at ThalesSim.Core.ThalesMain.WCMessageArrived(WorkerClient sender, Byte[]& b, Int32 len)Disconnecting client.Calling Terminate()...Implementor to NothingClient disconnected.


Not sure why is taking the 01U as the key scheme here. Even if I do not include the "U1" part, it still errors out with the same message.

Oct 24, 2011 at 2:58 PM

Indeed it doesn't. Key type is supposed to be 3 hex characters. The key type for ZPK is 001. Can you please try it again?

Oct 24, 2011 at 3:30 PM

Oops, missed that. Worked beautifully.

Here are the results:

Command sent: 0000A6001U42BBE7D9A0A55D0EBDE055DE2791ACCDX39BF9032CE641ABA1824708B06B4C301U01

=== [A6], starts 10:25:59.109 =======

[Key,Value]=[Atalla Variant,01]
[Key,Value]=[Key Scheme,X]
[Key,Value]=[Key Scheme LMK,U]
[Key,Value]=[Key Type,001]
[Key,Value]=[ZMK Scheme,U]

ZMK (clear): U0123456789ABCDEFFEDCBA9876543210
Key (clear): XFEB66E2A25AEE64C5B682A62D5F7041F
Key (LMK): U7E28745A78C51F84049C04A1DA7129A3
Check value: 0A2FA8
=== [A6],   ends 10:25:59.213 =======

Oct 24, 2011 at 7:33 PM

Glad to hear it. Turns out it wasn't that difficult to code but only thanks to the info provided by babtras. In the next days I will expand the Atalla support to more existing commands. If you have preferences, now's the time to state them.

Oct 24, 2011 at 8:33 PM

I will mostly use it with the FA command to translate a ZPK from the network so it can be stored locally.

Nov 25, 2011 at 8:18 PM

Sorry it took such a long time. You should now be able to use the Atalla variant with the AW, BY, FA, FC, FK and MI commands as well. Just download version 0.9.5. If you get any problems, please let me know.

Jul 16, 2013 at 1:53 PM
Is the Atalla Variant supported for command IA?