Welcome to our podcast series, Coffee with the Council. I'm Alicia Malone, Director of Communications and Public Relations for the PCI Security Standards Council. Recently, the Council published its newest standard, the Key Management and Operations, or KMO Standard. But what exactly is KMO, and how does it fit into the Council's portfolio of standards? Here to answer all of my questions is the Council's VP Distinguished Standards Architect, Mr. Andrew Jamieson. Welcome, Andrew.
Listen to the full episode on Spotify or on your favorite podcast player.
Andrew Jamieson: Thank you, Alicia. I'm not sure I can answer all of your questions, but I will try and answer your questions about KMO. So, let's start with the name then. KMO stands for Key Management and Operations, and that pretty much sums up exactly what it is. The standard details the requirements for secure management and operations using cryptographic keys, covering everything from the design of the key management system, through to the generation and loading of keys, the distribution of those keys, the use of the keys, and then finally through to retirement, replacement, and destruction.
But it's more than just key management, if you can believe that, if there's anything more than just key management! KMO also introduces new requirements for secure operation of remote and cloud-based HSMs (Hardware Security Module), as well as physical and logical security of key management and operation environments. Importantly, KMO does this in a way that is both modular and open to different key data types. The initial focus of KMO is on keys used to secure PINs (Personal Identification Numbers) and P2PE (Point-to-Point Encryption) data. But the Standard has been developed to allow for potential uses beyond these key data types over time.
Alicia Malone: So, Andrew, for those who might still be unfamiliar with it, who does it apply to?
Andrew Jamieson: Well, people might be familiar with the fact that we already have a key management standard that is specific to PIN keys, the PCI PIN Standard. However, PIN's not the only kind of data type that you need to secure with cryptography. In fact, cryptography is a core feature of pretty much every security standard, and certainly the security standards that we have. So, it's certainly true that key management is a vertical, a horizontal, that cuts across all of those standards. So, where there is use of cryptography in our standards, we've had to replicate key management requirements in there, essentially. So, this is not ideal, of course, because then we need to maintain them. Other people need to kind of comply with different requirements that have this similar sort of intent. So, the intent with KMO was to really boil all of these key management requirements down into a single standard, a single source of truth, if you like, for key management. That is the primary goal of what we're doing with KMO. So, in terms of who needs to comply, we talked about the fact that it applies to PIN keys and P2PE keys initially, but it's really about that generic key management approach and the key management security with a focus on those initial key data types.
Alicia Malone: So, as the primary architect of this standard, working, of course, in close collaboration with the payment security industry, what really led to the creation of KMO? Why is it needed and what does it accomplish that the Council's other standards do not?
Andrew Jamieson: So, as I mentioned, it's about consolidating down those key management requirements and intended to go beyond that as well. So, when I refer to things like PCI PIN, they were very kind of monolithic. They approached key management from a "you must do all of these things” and “you assess all of these things”. With KMO, we're taking a much more modular and adaptive approach. So, you can assess certain KMO service types and then you can build additional services on top of those service types.
And it goes beyond that as well, in terms of new types of key management operations, like cloud-based HSMs, for example, that really weren't available or weren't technology that was being used when we had the first generation of PCI PIN Standards. So, the goal is to help the industry make use of existing secure implementations that might have already been assessed. That could be an existing KMO service and allow for what we refer to as an "assess-once-and-use-many” approach to facilitate the secure use of cryptography and key management.
Alicia Malone: So, what does that mean for PIN and P2PE in terms of these standards and their assessments moving forward?
Andrew Jamieson: So, I mentioned how cryptography is something that cuts across all security standards and certainly our own. So, a long-term goal of KMO is to be that single source of truth, as I mentioned, across multiple standards. But we didn't want to try and boil the whole ocean, if you like, with the first version of KMO. So, we really wanted to focus in and make it a very clear standard to start off with, and that clarity being the focus on PIN keys and P2PE keys. So, the intent is if somebody has, for example, a P2PE implementation, they can potentially refer to KMO services that have been assessed under KMO that are part of a KMO listing, and there will be mapping from that onto P2PE component types so they can reference those as part of that P2PE implementation.
Alicia Malone: So, what are some of the new requirements in the KMO Standard that our industry should be aware of?
Andrew Jamieson: All of them, of course! I joke, but I would say that one thing that might strike people when they first approach KMO, when they first look at it, is that KMO addresses key management in a way that is quite different to PCI PIN, and that's deliberate. The format and approach will be familiar to people who are familiar with PCI DSS (Data Security Standard), for example, but for each requirement we have a very clear, simple statement. There are then testing requirements and then there's guidance for each of those requirements as well.
But, to answer your question in terms of what's new, there are a number of net new requirements that don't exist in any of our other standards before. I would say worth noting specifically there's, as I mentioned, an approach for cloud-based HSMs, or we would call them HSM-as-a-Service. And I think this is something that the industry will appreciate and has been designed along with the revision that we released earlier on this year of PCI HSM v5.0 to allow for the secure validation of these cloud-based HSM implementations. There's also a new approach to software-based cryptography in KMO, where you might have, for example, a derivation key that exists in an HSM. Then you have transaction unique keys that come out of the HSM that can be used perhaps in the server, that is allowed in P2PE, but there's actually quite a large section of P2PE that talks to these implementations. We've boiled all of that down to basically five requirements, a handful of requirements, in KMO to help simplify the use and operation in that context.
And then finally, an area I'd like to highlight is the requirements that exist in KMO that focus on HSMs that have been validated to FIPS (Federal Information Processing Standard) 140-2 or 140-3. These HSMs can still be used, and they are used in the industry at the moment, but these HSMs have not been validated to payment security requirements. FIPS is kind of a generic HSM evaluation methodology, if you like. So, for KMO, it then says, these HSMs validated to FIPS 140-2 and 140-3, they can still be used: However, there are some additional validation requirements that exist that don't apply to HSMs that are validated for payments, like PCI HSMs.
Alicia Malone: How does the new KMO Standard prepare us for the future of post-quantum cryptography?
Andrew Jamieson: Well, post-quantum cryptography is certainly an important topic, but it's definitely a complex topic as well, especially in environments with a long history of cryptographic systems such as payments has. It's never as simple as just implement these new algorithms, because people need to take a measured and careful approach. They need to understand the impacts of these things. So, in KMO, we do require that every key has a defined crypto period, a period at which it can be used. And the key owners have a program in place to actively monitor the changes in the cryptographic threat landscape and make appropriate changes in the key management systems as that threat landscape changes.
Finally, you asked me before about new requirements in KMO, and I did leave one set of requirements out. I apologize. But I did want to talk about them here. That's a specific best practice set of requirements. These are requirements that are not mandatory. You don't have to assess them, and even if you are assessed to them and you don't meet them, there's no problem with that. They’re specifically best practice requirements, but they are indicative of requirements that, for example, might appear in future versions of KMO. And this is something where we do have requirements for specifically post-quantum cryptography as well. So, none of these best practice requirements have a date on them. We're not introducing future-dated requirements, but if people are considering how they might want to approach their implementation of post-quantum cryptography, they might want to have a look at those best practice requirements in KMO.
Alicia Malone: That's great. That's a lot of great information. Is there anything else that you'd like to share with the payment security industry today about the KMO Standard?
Andrew Jamieson: Well, as we talk now, specifically today, as we're recording this podcast, the KMO Standard and Program have been released. So, people can go to the Document Library and download that, which is great. We're anticipating the qualification requirements for KMO will be released very soon as well. The training, we expect the computer-based training to be out towards the end of this year, potentially the start of next year, depending on when we can get it finished. It's going to be out as soon as we finish it.
And to close off, I'd really like to thank everybody who helped make this Standard. Obviously, this Standard is being released by PCI SSC, but it's really a product of the industry. We've worked closely with our partners as our POs (Participating Organizations) who've provided input from RFCs (Request For Comments). We've worked with our assessor community. We've worked with GEAR (Global Executive Assessor Roundtable), our PPOs (Primary Participating Organizations), and our Board of Advisors to help receive input, not only through RFCs, but through specific meetings that we've held to get input on what we need to have in this Standard to make it the best Standard it possibly can be. In the working group, we actually have representation from ANSI X9 who've been providing input and expertise on this Key Management Standard. And I know how much time it takes for people to provide input on this Standard. It's a long document. Obviously, not everybody's excited about key management as I am. So, we really appreciate all the time people have taken in reading the documentation, providing us with input, and really getting us to the place where we have the best possible version of KMO to release as v1.0 as we've done now. So, thank you very much to the whole industry for helping with this.
Alicia Malone: It really is a collaborative effort. Well, thank you for joining us on Coffee with the Council, Andrew, and for lending your expertise on all things KMO. It's always a pleasure to speak with you.
Andrew Jamieson: And always a pleasure speaking with you as well, Alicia, especially in person. And especially about key management!
Alicia Malone: Well, the new KMO standard and its supporting materials are now available for download in the Document Library on the PCI SSC website.
Like what you’ve heard? Subscribe to PCI SSC’s “Coffee with the Council” podcast by visiting any of the following platforms: Apple Podcasts, Spotify, Amazon Music, Anchor, Castbox, Google Podcasts, iHeartRadio, Pocket Casts, RadioPublic, or Stitcher.
