Requirements 3.5 and 3.6 are all about how keys used to
encrypt and decrypt cardholder data are managed,
and before we get into these,
I'm going to say what I advise to anyone who asks me about
encrypting cardholder data in key management,
which is this: If you do not store cardholder data,
you will not need to do this,
because doing cryptography properly is hard and
protecting the keys is harder still.
There have been so many data breaches where the criminals stole the
keys at the same times they stole encrypted card data.
So this is my second piece of advice for people who
ignore the first piece of advice, and it's this.
If you are going to manage encryption keys,
then my advice to organizations is to buy a hardware security module or HSM.
This is a secure hardware device that contains encryption and decryption keys.
Very simply,
you send the data that needs to be encrypted or decrypted to the HSM,
and it does what you ask.
The cryptographic keys never leave the HSM.
So if a criminal steals your encrypted data, they can never steal your keys.
Now remember, this is my personal experience and my advice to you.
The standard doesn't go this far.
What the standard does ask for is initially that you've
documented all your key management procedures,
and unsurprisingly, the QSA is going to review these.
There's an additional requirement in 3.5 that is just
for service providers; however,
I actually encourage everyone to also meet this requirement,
which is to document the entire cryptographic architecture that's in use.
What this means is that there's a single point of reference that
describes everything cryptographic in the organization.
This is a great document to produce,
because it really makes sure that the organization has a proper
understanding of the way it both encrypts data and manages keys.
It also massively helps any QSA assessment of the environment.
Remember,
this requirement just applies to service providers and not to merchants.
So if you're a service provider,
your QSA is going to review the documentation and speak to key personnel to
both verify that it's correct and that it's followed.
The rest of the sub requirements in 3.5 apply to all entities; that's merchants,
service providers, and banks.
Requirement 3.5 .2 aims to make sure that just the minimum number of
people necessary have access to cryptographic keys.
Now people with access to keys are known as key custodians,
and the exact requirement is to restrict the number
of people who fulfill this role.
This isn't just because of the risk of a key custodian turning into
a criminal and using the keys to decrypt data,
but it mainly minimizes the number of accounts that could be targeted by a
criminal to gain access to cryptographic key material.
The QSA is just going to look at the list of key custodians and
verify that the organization has minimized these.
Requirement 3.5 .3 is where encryption starts to get hard,
because the requirement is to protect the keys used to encrypt and decrypt data.
It's actually a strangely worded requirement,
because it talks about access to the keys that can be
used to encrypt and decrypt data,
but actually the real risk is just access to keys
that can be used to decrypt data.
And so in symmetric encryption such as AES,
the data encrypting key and the decrypting key are the same,
which is why the standard talks about the data encrypting key.
You might often hear that referred to as a D-E-K or a DEK.
In asymmetric encryption like RSA where you've got a public/private key pair,
the key that is to be protected is the private key,
which is the one that usually decrypts data.
So that's why it says things like store secret and private keys in the standard,
but it's not always consistent when it says this.
So whenever we're talking about keys, think about,
is this the key that's used to decrypt data.
Anyway,
there are three ways that PCI DSS allows these secret
and private keys to be protected.
Firstly, you can encrypt this data decrypting key with another key,
which is called the key-encrypting key or a KEK.
This key needs to be strong cryptographically as the
data-encrypting key it encrypts,
and that's actually quite a hard thing to do if you're mixing
symmetric and asymmetric encryption and again,
asking a QSA for help on that.
Secondly,
you can take my preferred option which is to get yourself
a hardware security module or an HSM,
and actually the normal practical implementation of an HSM means
that you use it to protect key-encrypting keys,
not data-encrypting keys.
Thirdly, you can use key shares, which must be the same length as the key,
which when combined together using some mathematical function like Excel,
produces the actual key, and we'll look at how to do this in a few minutes.
The QSA is going to look at the documentation that says how you're protecting
secret keys and determine whether that meets the requirement.
We'll then see if what you implemented matches the documentation.
If all this cryptography is like a foreign language to you,
there's some great courses at Pluralsight that you can use to get up to speed.
Just search for cryptography.
The two I'd recommend for beginners are Matt Glass' Big Picture
course and Dale Meredith's Cryptography course,
which is part of this Ethical Hacking series.
And if you really want to get to grips with the crypto,
Michael Perry's Cryptography Fundamentals is really brilliant.
The last requirement in 3.5 is pretty simple.
It wants to make sure you're careful about where you store the secret keys,
and the wording of the requirement is also pretty simple; just those
secret keys are stored in the fewest possible locations.
Now remember, we've already said we're going to protect the secret keys,
so we've agreed we're protecting them and now we're
protecting them in as few places as possible,
because look, everywhere a key is stored,
it's somewhere an attacker can get hold of the key.
So just as with any valuable asset, minimizing the number of storage locations,
and knowing where they are, is just basic simple security.
As with the previous requirement,
the QSA is going to check your key management documentation and also then
look at the systems to see where the keys are stored.