Did you know? With over 69 years on the throne, Queen Elizabeth II is the longest reigning monarch in British history. After her, Charles, the Prince of Wales will ascend to the throne, his son William will follow, and so on.
The British royal family operates in order of a hierarchy, and always has throughout history—its clear progression is easy to understand.
Did you know that payment card assessments too also feature a hierarchy? It’s called a key hierarchy, and it can similarly serve to provide clear links between your related payment card elements.
If you’re involved with this kind of data, you already know that it’s in your best interest to get yourself assessed to ensure you’re doing the right things in protecting such sensitive information. But at the same time, you’re dreading that because historically, audits have never made for much of a good time.
As providers of these kinds of PIN and P2PE assessments, we have a unique perspective from the seat across from you on these evaluations. Now that we’ve done the reviews and encountered the possible hurdles, we want to relay what information we can to help you avoid them.
There may be no aristocracy involved in encryption, but establishing your own key hierarchies is critical to streamlining your payment card assessment process, no matter who you work with in the future.
To help you, we’re going to lay out three separate hierarchies likely found within your own transaction processes. We’ll provide a clear order of keys for each, and while there may be some variation, this will work for you as a baseline to create your individual progressions. We’ll also provide actual sample diagrams so as to really simplify things.
Afterwards, you’ll be able to use these guidelines to work from in establishing your specific hierarchies within your organization, positioning you for a much better experience during your assessment.
What is a Key Hierarchy and Why Do You Need One?
But first, let’s get the basics out of the way.
You’ve probably already heard of a key inventory because that is requisite for both the PIN and P2PE standards. But a key hierarchy is different—different in that it’s less a list and more of a tiered structure that defines the relationship between keys you use to protect or derive other keys involved in your processes.
It’s also different in that it’s not technically required by the standard. However, we would argue that it’s just as necessary.
That’s because, like the inventory, the PIN and P2PE standard also requires that you maintain some kind of information on how each key interacts with each other. When your assessor comes in to do their work, they will ask you for an understanding of the relationships between your keys.
Of course, you could just sit with them every time and have that conversation detailing how your keys interact, relying on the power of recall to relay those functions so that they can be reviewed as part of your assessment. But what if you’d figured all that out ahead of time, and even wrote it down to boot?
Think about it–documentation is a huge part of these assessments, and a key hierarchy can serve as part of that documentation. If you make the effort to create, track, and maintain these charts and/or diagrams demonstrating your key hierarchies, when the time comes for an evaluation, you will be able to:
- Provide a clear picture for your assessors regarding the keys in your process and how they work together—a necessary facet to your assessment;
- Preserve your own understanding throughout organizational change; and
- Save yourself—and your assessors—some time during every assessment, since they won’t have to discern and document things from scratch every time.
Where to start, you may be wondering. It’s time to get more specific–let’s break down three specific key hierarchies you might have within your processes.
1. Hardware Security Module (HSM) Hierarchy
We begin with key storage in HSMs. An HSM is essentially a vault or lockbox that creates and stores keys. It logically operates like nesting dolls do—the keys within the HSM are encrypted by other keys.
Within HSMs, the top-most key in the hierarchy is used to encrypt keys under it that are used for other purposes. This Queen Elizabeth key is referred to as the Master File Key (MFK) (or Local Master Key (LMK) by different manufacturers). The layout for your HSM key hierarchy is as follows:
- Master File Key (MFK): The aforementioned top key, it sits at the top of the chart and is present in each HSM. This key is used to encrypt the next tier in this hierarchy. This key is not shared outside of the HSM.
- Zone Master Key (ZMK): A type of key-encrypting key (KEK) used to exchange keys between organizations.
- Base Derivation Key (BDK): A cryptographic key used to create or derive additional keys.
- Terminal Master Key (TMK): A key-encrypting key used to protect keys at points of interaction (POI) or to distribute data-encrypting keys (DEKs).
- PIN Verification Key (PVK): A data-encrypting key used for PIN verification.
**Note: This diagram, as well as the ones that follow, explain common models used in PIN and P2PE services. The specific colors for each will correlate to our full examples of hierarchies linked below.
2. Distribution Hierarchy
Next, we’ll lay out the progression for those encryption keys involved in the creation and exchange of key components between two organizations. Though this is laborious and a time-consuming activity that also requires key custodians to perform key ceremonies, an evaluation of this is an unavoidable staple in the PIN and P2PE standards.
Because keys can also be exchanged between organizations to facilitate the subsequent creation and exchange of keys—as you’ll probably agree, establishing an organized order for this process can help tremendously.
To demonstrate how a hierarchy can simplify this exchange process, let’s say this:
- As part of your offered PIN solution, you receive key components from your issuer bank for a symmetric exchange key. Those key components are loaded into an HSM to recreate the exchange key used by both you and the bank—this recreation is technically called the Zone Control Master Key (ZCMK).
- That key is then used to encrypt the additional keys exchanged between the HSMs used by both you and your issuer (removing the need for manual, key loading actions by key custodians for the additional keys). Examples of these keys that will be exchanged include:
- Acquirer Working Key (AWK): This is a data-encrypting key used to encrypt PIN data between the service provider and acquiring bank.
- Base Derivation Key (BDK): A cryptographic key used to create or derive additional keys that will be loaded onto POI.
Visually, that translates to something like this:
3. Derivation Hierarchy
Speaking of derivation, that process has its own hierarchy, and the BDK plays a part here as well. During a transaction, the keys injected into POIs for the encryption of card or PIN data are almost always derived from other keys.
Here’s a simplified explanation of how it works, using technical terms. To create encryption keys with a process that is both secret and repeatable, we need to have details that are not shared.
- This starts with a core key (BDK) which will be used for a series of terminals or for a specific merchant.
- Next, the process requires something individual to the POI device, like a serial number (or Key Serial Number (KSN). There are now two elements—the BDK which is secret, and the KSN which isn’t.
- By using those two items (the core key and serial number), a device can programmatically create another key called the Initial PIN Encryption Key (IPEK). This one is assigned only to that device (the terminal that the serial number came from).
- That IPEK is just temporary though, because it’s then used as the seed for a large array of keys by combining an incrementing number like a transaction counter to make the Data Encrypting Keys (DEKs). Each key in the array will be used for a single transaction.
- Having that series of DEKs allows every transaction to use a new, unique key, all from this array. This is known as Derived Unique Key Per Transaction (DUKPT).
Voila, derivation explained. Now to illustrate its hierarchy:
**Note that neither the KSN nor transaction counter are present here. While both are integral to the creation of the keys, they are not actual keys and therefore do not need to be included in this hierarchy.
Documenting Your Own Key Hierarchy
You’re already required to identify and document every key—taking the extra step to also write down how they all interact will be tedious, yes, but you’ll reap the dividends at the time of your assessment–we promise!
We provided tiered example diagrams, but you are free to nail down these details in other formats. The important thing is to just write it down somehow—that’s the real shortcut.
How will all of that translate to your own assessment? Linked here are examples taken directly from the both the P2PE and PIN report templates provided by the PCI SSC. We’ve filled them out with sample information and color-coordinated them with our tiered diagrams above.
This is what your assessor will be filling out as they review your components—having read all this, you’ll note how much easier that will be for them if you’ve got all that information basically ready for them within your hierarchies.
Here at Schellman, our goal is to help you untangle complex compliance initiatives—that means making these endeavors as easy as possible. For those approaching either a P2PE or a PIN assessment, not only will documenting your key hierarchies help you “untangle” the relevant elements for yourself, such preparation will also make things easier on your eventual assessor too.
For more information on how to further bolster your groundwork for a PIN assessment in particular, read our articles to get started. They’ll help you set expectations and ensure you’re ready for an even smoother experience: