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:

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

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

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

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

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

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s