Migrating to Standards-Based Key Blocks for PCI PIN Compliance and an

AES Master Key for PCI PIN and PCI P2PE Compliance

The information provided in this document is considered proprietary and confidential.

 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

KEY BLOCKS AND PCI PIN COMPLIANCE

To maintain compliance with Payment Card Industry (PCI) PIN guidelines, organizations will need to use structures
called key blocks to manage encrypted symmetric keys. This means organizations that rely solely on cryptograms will
need to plot a pathway to implementing key blocks in order to maintain compliance. The most common
implementations of these key block structures is the TR-31 structure defined in the X9 TR-31 technical report:
Interoperable Secure Key Exchange Block Specification for Symmetric Algorithms (2018). Any organization looking to
make this migration should purchase the X9 TR-31 report as a companion to this document. This whitepaper discusses
migration to TR-31 key blocks in compliance with PCI PIN.

PCI PIN SECURITY REQUIREMENT 18-3

Let’s start with a few definitions from PCI. PCI PIN Security Requirement 18-3 states that, “Encrypted symmetric keys
must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using
accepted methods.” In layman’s terms – these changes are monumental.

Worldwide, there are over 43.5 million terminals shipped each year, over 3 million ATMs currently deployed, and over
18 billion cards in circulation. The new PCI security requirement effects every single one of these devices, as well as
the organizations involved in storage, transport, processing, and key management. While it can be challenging, this
migration is essential to industry security. To support a smooth transition, the enforcement of these requirements will
be done in phases, per PCI.

PAGE 1 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

Each phase has corresponding dates for completion:

Phase 1 June 2019 “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).”
Phase 2 June 2021 “Implement Key Blocks for external connections to associations and networks.”
Phase 3 June 2023 “Implement Key Blocks to extend to all merchant hosts, point-of-sale (POS) devices and
ATMs.”
*PCI Point-to-Point Encryption, Security Requirements and Testing Procedures, Version 3.0 – December 2019

Depending on your organizations’ role in the financial process, you may be impacted by phase 1, 2, 3 – or all three!
We will use the fictional company “PayYou” to demonstrate how the PCI changes affect payment operations and
partner relationships through the implementation of PCI 18-3 requirement. PayYou operates as a payment gateway,
securely transmitting data between payment processors and merchant accounts. They have already completed phase
1 of updating the internal infrastructure and applications. With this phase completed, any keys that are referenced
between the HSM and PayYou’s internal application use secure key blocks to share data, rather than the outdated
cryptograms. Internal changes are the natural place to start when looking at migrating an entire system to meet new
technology requirements. When looking at deploying new algorithms in an infrastructure, everything starts at the
local key management level. The keys that are stored in your local key servers (or in your local HSMs) are the keys that
secure everything else in your infrastructure. Data structures, use cases, and everything else, all rely on these keys.

As a payment gateway, PayYou communicates and shares keys with external payment networks to approve or decline
transactions. Phase 2 of PCI requirement 18-3 stipulates that this exchange must be completed using TR-31 key
blocks. This phase deploys the financial key derivation algorithms and establishes interoperability, interchange, and
translation with these external networks. Finally, PayYou must change how it loads keys into its payment terminals,

PAGE 2 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

either through direct or remote key injection. Any keys loaded to merchant hosts, point-of-sale devices, and ATMs but
be loaded as TR-31 compliant key blocks. And finally. Phase 3 deploys PIN and other financial algorithms at the
payment terminals, ATMs, and all external appliances.

WHAT IS A KEY BLOCK?

Key blocks were developed as a means to combat the exact problem PCI PIN requires organizations to prevent:
unauthorized substitution, replacement, or misuse of cryptographic keys. Key blocks safeguard against this sort of
fraud by embedding information about a key within the key and data itself. A typical key block structure is made up of
a header, the data, and the key binding method.

Embedding this data within the symmetric key has many benefits including the key being uniquely identifiable in
cryptographic systems, preventing unintended usage. Another particularly useful benefit of a key block is that it can
mask the length of a key with padded bytes, preventing processes such as the unbundling of 3DES cryptograms. With
Futurex HSMs, shorter length key blocks are automatically padded to be at least the length of a 3DES key. Another
benefit of key blocks is fraud prevention. If a fraudster attempted to present an otherwise identical cryptogram
without the header attributes, the key would fail validation.

Ultimately, key blocks add an extra layer of security to DES and 3DES keys that are otherwise inadequate. DES, as a
cryptographic algorithm, is strong but far too short, and can be brute forced in a matter of hours with inexpensive
hardware. This means DES has confidentiality but not integrity. The mandated move to 3DES has taken steps to
mitigate this risk, but additional problems are still present: with DES and 3DES cryptograms, it’s possible to guess the
algorithm used from the number of bytes in the cryptogram.

The below command is an example of a 3DES KEK generation using the General Purpose Generate Symmetric Key
command of the Excrypt API.

[AOGPGS;CT3;FS1;]
[AOGPGS;AE5AAE;BGA2EDA996DEBB9D4C0CEAF48EFE6F3D8A0B845256A152A006;RT1;]

It is encrypted (confidential), but it does not use a Message Authentication Code (MAC) or other binding method
(integrity). One can guess it is a 3DES cryptogram because it is 24 binary bytes in length, shown in bold above.
Key usage, key type, and additional application-specific parameters, however, are not attached to the key. These are
stored separately in a key database. The problem with storing keys in separate databases is that these databases are
another point of attack or vulnerability. If an attacker gains access to a key database, that gives them all the
information they need to compromise the system. Key blocks prevent this in that, even if a key is seized, an attacker
would have no knowledge of its usage, type, or even length. Any attempt to use the key would be rejected because of
the MAC embedded into the key.

PAGE 3 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

When a developer translates cryptograms to a TR-31 key block, however, the key integrity is fortified. This process is
detailed in the “Develop and Document” section.

KEY BLOCK VERSION ID

There are four types of key block version IDs: A, B, C, and D. Each version defines the method by which a key block is
cryptographically protected.

Version A “Key block protected using the Key Variant Binding Method”

Version B “Key block protected using the TDEA Key Derivation Binding Method”

Version C “Key block protected using the TDEA Key Variant Binding Method”

Version D “Key block protected using the AES Key Derivation Binding Method”

* ASC X9 TR 31-2018 “Interoperable Secure Key Exchange Key Block Specification”

Version A has been deprecated and should not be used in new applications. However, it is recommended that you
have products and processes that allow you to migrate from one version/algorithm to another version/algorithm
without effecting legacy use-cases. Once that is done, organizations can look at deploying new use cases.

Versions B and C encrypt the key block under a 3DES MFK. These versions are perfectly acceptable – so what drives
people to use Version D? There are two main driving factors to use key block version D. Version D is encrypted under
an AES wrapped key which enables organizations to meet PCI P2PE requirement 12-5. Additionally, the industry is
trending towards AES keys, utilizing this available feature helps to future-proof environments for any future mandates
surrounding AES wrapped keys.

PCI SECURITY REQUIREMENT 12-5 – HOW DOES THIS FIT IN?

Version D provides organizations the option to use an AES-wrapped key. While it is an option for some, for others it is
a requirement. Organizations audited for PCI P2PE compliance standards are required to use this version based on PCI
Security Requirement 12-5. Requirement 12-5 states, “Hardware security module (HSM) Master File Keys, including
those generated internal to the HSM and never exported, must use AES with a key size of at least 128 bits.”
Organizations can meet requirements 18-3 and 12-5 by using key block version D.

TRIPLE DES (3DES) AND THE REASON FOR AN AES MIGRATION

At the time of its introduction, 3DES was a natural progression from the aging (and compromised) single DES
algorithm. In 2003 3DES was originally enforced by the major card brands for all new devices and in 2007, the final
mandate to discontinue use of single DES keys. The industry adapted, and for the next twenty years, 3DES was the
norm. While 3DES was a good upgrade from single DES, time has depreciated its secure status. The transition to AES is

PAGE 4 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

the next natural progression for security in cryptography. While PCI and FIPS mandates have accelerated the
transition in financial spaces, this transition is in line with other industries that use key and cryptographic algorithms
to secure data.

FUTUREX CRYPTO AGILITY

History has proven two things: algorithms can be broken and standards change. Knowing this, organizations need to
be able to react quickly in the event an algorithm vulnerability is discovered, and to plan for these inevitabilities.
Crypto agility allows just this. Systemwide upgrades are less complex when crypto agility is implemented, enabling
early adoption of new standards and bast practices.

At Futurex, one of our most important responsibilities is to give organizations a foundation by which they can grow
over time. This is accomplished through crypto agility. Crypto agility enables organizations to switch between
algorithms without rewriting applications or deploying new hardware. Simply put, crypto agility prepares you for the
future.

Over time, usage of 3DES major keys will decrease due to compliance mandates, but it will not disappear altogether.
At the same time, usage of AES will increase dramatically. An Infrastructure that has crypto agility, will enable
organizations to support multiple platforms. For example, what if an organization has two commands they need to
run for their new application? One is relying on a 3DES wrapped key, while the other is relying on an AES wrapped
key. In a non-agile environment, they would need two separate systems or applications – each running its separate
command. In an agile Futurex environment, the HSMs can automatically distinguish which wrapping key was used in
the command. This prevents applications from having to be re-written and saves organizations from the development
pain points associated with that.

Crypto agility and key rotation for the 3DES/AES migration should:

• Allow for concurrent 3DES and AES processing

• Allow for planning
• Everything should be scriptable
• Everything should be supportable

All steps are essential for an agile environment. Additionally, your solution should not lock you in to their proprietary
schema. Your system should rely on standards-based algorithms and data structures to allow you to perform crypto-
agility functions. Crypto agility is essential as we see increased crossover between financial, general-purpose, and
cloud-based cryptographic processing.

HOW TO MIGRATE TO TR-31 KEY BLOCKS

OVERVIEW OF PROCESS

Develop & Implement

Identify Plan Test
Document & Review

PAGE 5 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

The amount of time it takes an organization to migrate to standards-based key blocks for PCI PIN compliance varies
considerably based on the organization’s profile. Larger organizations, with far more applications and complex &
layered key generation and loading procedures, will likely take longer to complete the migration process. Smaller
organizations, by contrast, are more likely to have fewer applications and might act more nimbly in adjusting their
procedures. Of course, this is a generalization as there are numerous factors both large and small that organizations
must consider when developing implementation goals and timelines.

The first stage of the process, identifying those procedures and applications that will be affected in your organization,
sets the tone for the rest of the migration. The second, where the plan is developed, will give organizations a better
sense on the migration time frame. The development and documentation stage is the most time-consuming stage
wherein applications, procedures, and documents are adjusted to accommodate the use of key blocks. After that, the
applications should be tested in a non-production environment. Once the organization is comfortable with the
development, the project can be rolled out however the organization sees fit—during which time it can be reviewed
and revised as needed.

NOTE: This process flow is merely a suggestion based on industry best practices. Every organization will need to
develop its own process and procedures in line with its own requirements and goals.

IDENTIFY ALL APPLICATIONS AND PROCEDURES AFFECTED

Cryptographic systems rely on Application Programming Interfaces (APIs) that govern encryption processes and are
processed by hardware security modules. Not all APIs support key blocks. However, the Futurex Excrypt API does.
Organizations could have many applications that are affected by implementing key block usage in favor of
cryptograms. Therefore, organizations migrating from cryptograms to key blocks will need to examine the APIs they’re
using and determine the level of support these have for key blocks.

Some organizations may need to update their applications for support of key blocks, but Futurex strongly urges
organizations using Futurex devices to standardize on its Excrypt API. There are several reasons for this:

• Support of multiple key block formats, along with functionality for key, PIN/offset, and MAC
management, data encryption, hashing, card verification, and more.
• Simple and easy-to-understand command syntax which uses field identifiers for parsing and data
manipulation.
• Hexadecimal command encoding, eliminating the need for binary.
• Key length determined per request, so manual configuration is not required.

With the Excrypt API, users form commands and send a call to the HSM, after which a response is sent validating or
rejecting the command. A sample of an Excrypt TR-31 key block generation command follows:

Request

[AOGKBL;AS1;BG0A98439F510BD7B1DC74D3CC713F71F6;AKA0088P0TE00E0000;]

Response

PAGE 6 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

[AOGKBL;BBA0088P0TE00E000014C974634767EF1A93A8D1C884766B4B2A3928C81471A5F6EE
3A0017E3345EED3363A54F;AE255B;]

For more detailed information about this, and other key generation commands, see the Futurex Excrypt Technical
Reference.

PLAN THE MIGRATION

Careful planning will go a long way in making the migration as painless as possible. Before you determine how to
proceed with the development, you will also want to select the types of key blocks you will generate. Just like
cryptograms, not all key blocks are created equally.

Organizations should be using at least 3DES when generating a key block, even though DES key blocks can be padded
to 3DES lengths. Because some of the organization’s applications might not support specific key types or lengths, the
organization will need to plan for the best possible security given their current infrastructure and whether they want
to optimize their applications to use more secure methods—AES encryption keys that are considered stronger than
DES or 3DES, for example. In fact, planning around current application support for algorithms, key length, binding, and
all other elements of key blocks is critical to a successful migration.

Another component of the planning process is identifying the keys that will need to be translated into key blocks
during the development stage. In the meantime, it would be beneficial to review key management procedures. For
example, these procedures could be centralized using the Futurex KMES Series 3 Key Management Enterprise Server
to support key block usage through key referencing. Key blocks, key referencing, and key/certificate management can
all be complete within a single system.

Finally, organizations should consider how quickly they want to phase out cryptograms. Futurex devices allow users to
disable cryptogram such that these no longer interfere with compliant key protocols. An important part of the
planning process to bear in mind is that any procedural changes to key management must be documented in
accordance with PCI compliance; this can be done with development concurrently or during the implementation and
review stage.

KMES SERIES 3 – ENTERPRISE KEY AND CERTIFICATE MANAGEMENT

Rather than storing keys in separate databases, the KMES Series 3 allows users to manage large volumes of keys,
certificates, and other cryptographic objects. The central management of all key blocks in one secure location makes
key referencing and other key operations far simpler. It removes the need to leave data integrity up to a database
solution that is less secure, especially as an external solution to storage needs.

Advantages of the KMES Series include, but are not limited to:

PAGE 7 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

• Full symmetric and asymmetric key and certificate lifecycle management

• Permission-based user management system with dual control and segregation of roles
• Robust, versatile API for programmatic automation of repetitive tasks
• Customizable, secure key mailer printer templates for distributing key components
• Management of keys from one central location, reducing cost and time associated with traveling to multiple
data centers

Among these advantages, the KMES Series 3 meets and exceeds relevant compliance standards as a FIPS 140-2 Level
3-validated Secure Cryptographic Device. Those standards include PCI DSS, EMVCo, and ANSI X9.24 Parts 1 & 2 for
Symmetric and Asymmetric Key Management – TR-39, RoHS, and FCC Class B-Part 15.

The KMES Series 3, therefore, has potential to be one more tool at an organization’s disposal to exceed compliance
standards and facilitate easy key operations without foregoing security.

DEVELOP AND DOCUMENT

With a specific plan in mind, application developers can begin adjusting code to support the specific key blocks
identified in the planning stages.

Developers will also need to translate existing keys into key block structures. This means they’ll need to write an
application that can perform this translation using the Excrypt command GKBL, which translates cryptograms to key
blocks. The command looks as follows:

REQUEST

[AOGKBL;AS1;BG0A98439F510BD7B1DC74D3CC713F71F6;AKA0088P0TE00E0000;APA008
8K0TB00E000057FBBE38E6FE2F81EA586352184116741B290348AE5716F7440F064C8484
73E4B459A8D2;]

RESPONSE

[AOGKBL;BBA0088P0TE00E0000517A749179A91E24DCC3A992A42EC4B60245CC574E3688
59362668E831A28A62DD248DE6;AE4465;]

Inputting header values from the ANSI TR-31 technical report attaches attributes to the key. The following table
shows how those input values affect the command.

Key block header inputs from above example

Encrypted using TR-31 key block version A. (Other options available are key block versions B,
A
C, and D)

PAGE 8 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

0088 Size of key block

PO PIN encryption

T Triple DES

E Encrypt or wrap only

00 Not a component

E Exportable

00 No extra key blocks

00 Reserved for future use by TR-31 specification

Command GKBL essentially attaches information about the key in the header, giving the key both confidentiality and
integrity. Using the GKBL command allows users to translate all existing cryptograms to key blocks. This process can
be automated. The ANSI X9 TR-31 technical report entitled “Interoperable Key Exchange Key Block Specification for
Symmetric Algorithms” (2018), provides the technical details for TR-31 key blocks, including the input values for
headers. This document will be vital to organizations wanting to implement TR-31 key blocks. Once this process is
complete, only key blocks should be stored in the database. Note that this may require a different command to be
used during production.

Developers will need to compare the key check digits and the translated key block check digits to verify accuracy.

FUTUREX HSM-SPECIFIC SETTINGS

To use key blocks with Futurex HSMs, administrators will need to ensure that certain settings are configured. First,
users will need to enable TR-31 key blocks from the Extended Options tab of the Excrypt Manager application. Under
the Key Block Policy tab, check ANSI Key Blocks (TR31). While here, users can also disable cryptograms by ensuring
that the appropriate box is unchecked.

PAGE 9 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

Users will also have to ensure that key block commands are enabled in Excrypt Manager. To do so, navigate to the
Function Blocking tab of Excrypt Manager. To translate cryptograms to key blocks, the GKBL command must be
enabled. This command will also generate new key blocks.
Another key block-related setting is choosing whether to use a character limit on MAC verification. This can be
adjusted from the Extended Options tab of Excrypt Manager under the Miscellaneous section.

TESTING AND VALIDATION

Once everything has been developed, it’s important to test not only for application bugs, but for procedural problems
as well. It may be helpful to ask the following questions:

• Are the key blocks generated in a manner that complies with PCI PIN, PCI P2PE, and other relevant
compliance standards?
• Can an adversary conceivably use key blocks for any purpose other than intended, or are there any potential
leaks in key blocks used?
• Are the keys encrypted using an appropriate key size and secure algorithm?
• Does the control information allow the hardware security modules to reject incorrect key usage and validate
correct key usage?
• Can the mechanism detect any modification or manipulation of control information and encrypted keys?

As with other application development efforts, quality assurance will hopefully identify those changes that need to be
made once the applications have been adjusted for key block support. Should any problems arise, these should be
addressed before moving on to the implementation stage. It would be most helpful for an organization to set up a
test environment where key management procedures are conducted facsimile.

IMPLEMENT AND REVIEW

When all code and procedures have been tested and revised, the rollout and implementation can begin. It is often
best for companies to roll out a large project such as this in phases—during which time they can review and evaluate
the overall success of the project. As part of any well-planned project, a post-implementation review is critical and can
allow lessons learned to be shared and kept in mind for future initiatives.

API COMMANDS FOR PRODUCTION

After all the cryptograms in the database have been translated into key blocks, the TPIN command should be used to
translate PIN blocks from one key to another. This process is virtually no different with key blocks than it would be
with cryptograms. Only the input values will have change, but the output will remain the same. The process with
cryptograms and with key blocks is shown in this section to illustrate that point. If desired, follow along in a test
environment to reproduce the results shown.

PAGE 10 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

Input Values

MFK (unmodified) D2DE5CD9110F4CAB 111111111111111 0123456789ABCDEF

MFK (modifier 1) DADE5CD9110F4CAB 191111111111111 0923456789ABCDEF

KCV 8071

PEK 1 0123456789ABCDEF FEDCBA9876543210

PEK 1 (cryptogram) 0C3D7CCA80E2840B 527FA6C59A3F3719

PEK 2 0011223344556677 8899AABBCCDDEEFF

PEK 2 (cryptogram) 4156E9088F651084 32314FDAC8345931

PIN 1234

PAN 561237487695

Clear PIN block 041262EDC8B7896A

Encrypted PIN block 62604E63F0A60182

C0088P0TN00E000054CF02CF89CCC36897E3D4AC22D7BBECA1CBD08296A315A472282
TR-31 PEK 1
74A2FAE03EA699AF35F

C0088P0TN00E00002BB54D92E73B747E1755F7558DF15BC2696C7EA59DCF8FFD465ECD
TR-31 PEK 2
5258C015FD58CF51EC

PAGE 11 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

EXAMPLE PIN TRANSLATION USING A CRYPTOGRAM

The following is a simple TPIN command using a cryptogram. The input values have been colored to show their
designated position in the call to the HSM. Note that this call will not necessarily be used in production because all
cryptograms should already have been converted to TR-31 key blocks.

Request

[AOTPIN;AW1;AX0C3D7CCA80E2840B527FA6C59A3F3719;BT4156E9088F65108432314FDAC8345931;AL62
604E63F0A60182;AK561237487695;]

Response

[AOTPIN;AL56231FABF821F159;BBY;]

Note that the response output, shown in bold, is identical to the response output using the TR-31 key block as an
input instead of the cryptogram. To show how the same cryptogram can be converted into a TR-31 key block and
subsequently used in a TPIN command to produce the same output, the GKBL command is shown below.

CONVERTING THE CRYPTOGRAM TO A TR-31 KEY BLOCK USING PEK 1:

The same cryptogram can be converted into a TR-31 key block and subsequently used in a TPIN command to produce
the same output. The following uses the GKBL command discussed earlier to convert the cryptogram to a TR-31 key
block.

Request

[AOGKBL;AS1;BG0C3D7CCA80E2840B527FA6C59A3F3719;AKC0088P0TN00E0000;]

Response

[AOGKBL;BBC0088P0TN00E000054CF02CF89CCC36897E3D4AC22D7BBECA1CBD08296A315A47228274A2F
AE03EA699AF35F;AE08D7;]

CONVERTING THE CRYPTOGRAM TO A TR-31 KEY BLOCK USING PEK 2:

Request

[AOGKBL;AS1;BG4156E9088F65108432314FDAC8345931;AKC0088P0TN00E0000;]

Response

[AOGKBL;BBC0088P0TN00E00002BB54D92E73B747E1755F7558DF15BC2696C7EA59DCF8FFD465ECD5258C
015FD58CF51EC;AEFB09;]

PAGE 12 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

EXAMPLE PIN TRANSLATION USING A TR-31 KEY BLOCK:

Once the key blocks for PEKs 1 and 2 have been generated, the values can be input into the TPIN command in place of
the cryptogram PEKs. The output should be the same.

Request

[AOTPIN;AW1;AXC0088P0TN00E000054CF02CF89CCC36897E3D4AC22D7BBECA1CBD08296A315A4722827
4A2FAE03EA699AF35F;BTC0088P0TN00E00002BB54D92E73B747E1755F7558DF15BC2696C7EA59DCF8FFD
465ECD5258C015FD58CF51EC; AL62604E63F0A60182;AK561237487695;]

Response

[AOTPIN;AL56231FABF821F159;BBY;]

Throughout the entirety of the implementation and migration process, the Futurex Xceptional Support team is
available to help with any questions. It also offers a range of on and off-site professional services for organizations
requiring additional assistance.

PAGE 13 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

SOURCES
• “Information Supplement: PIN Security Requirement 18-3 - Key Blocks”. Version 1.0. Payment Card Industry
(PCI). June 2019.
• “Point-to-Point Encryption: Security Requirements and Testing Procedures”. Version 3.0. Payment Card
Industry (PCI). December 2019.
• “Interoperable Secure Key Exchange Key Block Specification.” ANSI X9 TR-31. April 15, 2018.
• The Nilson Report – https://nilsonreport.com/publication_newsletter_archive_issue.php?issue=1095
• The Nilson Report – https://nilsonreport.com/upload/issues/1140_0321.pdf
• ATMIA – https://www.atmia.com/images/50th%20anniversary/50th_atm_anniversary_fact_sheet_-
_06272016.pdf

PAGE 14 OF 15
 WHITEPAPER | TR-31 KEY BLOCK IMPLEMENTATION

OFFICE: +1 830 - 980 - 9782 TOLL FREE: 800 - 251 - 5112

864 OLD BOERNE ROAD, BULVERDE, TEXAS, USA 78163

PAGE 15 OF 15