Requirement 3.5 was all about how keys are protected from unauthorized access.
Requirement 3.6 now looks at how the keys are managed to make
sure they're cryptographically correct,
and before we get into the guts of requirement 3.6,
some more personal advice.
If you want to keep encrypted cardholder data,
then get a specialist to help you with the policies and
procedures of these requirements.
It's really easy to make a mistake that cannot only
affect your PCI DSS compliance,
but it also makes it easy for criminals to steal and decrypt your data.
As I said before,
there've been countless breaches of encrypted cardholder data where the
criminals were able to steal or subvert the encryption keys,
because remember that really good criminals are
actually experts at cryptography as well,
and so the over-arching demand of requirement 3.6 is that all key management
processes and procedures are documented and implemented.
This requirement is badly worded, because again,
it talks about the keys used for the encryption of cardholder data,
but it really means secret keys,
so that's the one key for using symmetric algorithm,
and the private key if you're using an asymmetric algorithm.
As I'm sure you'll have guessed,
the testing procedure is for the QSA to look at the documentation.
Requirement 3.6 has eight sub requirements,
all of which will need to be included in the
documentation and implemented properly.
The first sub requirement is the only strong keys generated,
and a quick reminder of the definition of strong is found in the PCI
Glossary of Terms; we looked at it in requirement 3.4,
and it's that a minimum length of 112 bits is used,
and practically for anything other than legacy systems,
this means the lowest strength's life you should consider is 127-bit AES,
and it's not just about the length of the key.
So, as well as the length of the key,
the key needs to be non-deterministic so ideally generated randomly.
The QSA is going to check the documentation and according to the
standard is going to want to observe the procedures for generating
keys to verify that strong keys are generated.
Now this might cause a problem because unless you plan ahead,
the key generation is something that's typically done rarely and will
often have been done well before the QSA comes on site.
So there's two things you can do; I'm serious here.
One of which is what I always try to do,
which is to video the key generation process.
You might also hear this called a key ceremony and
then you show the QSA the video, keep it in a safe place.
The other is that you plan in advance and you invite the QSA,
or a QSA to the key ceremony.
The next requirement,
3.6 .2 needs you to distribute the keys you've just generated securely,
which means two things.
Firstly, that they're only shared with the nominated key custodians.
Do you remember the key custodians?
We identified those in requirement 3.5 .2.
And secondly, that the keys are never distributed in clear text.
And again, the standard asset,
the QSA looks at the documentation and observes the key distribution method,
and again, this might have taken place before the QSA came on site.
So frequently in the assessment you have to show the QSA
evidence of how the keys were distributed to allow them to
verify this with the key custodians.
Alternatively,
you can ask them to come on site when you first distribute the keys.
Requirement 3.6 .3 is a really strange one, actually.
It's identical to requirement 3.5 .3,
which says something like protect stored keys.
It's a bug in PCI DSS.
And the requirement is to store keys securely,
either in key parts protected by a key encrypting key or
ideally in a hardware security module.
And the QSA is going to look at the documentation and at how and where keys are
stored to make sure they're stored securely and honestly.
This is why using an HSM is the right thing to do,
because the HSM often has ways of doing the key distribution.
It will often save key parts to smart cars that you
then just give to the key custodians.
Requirement 3.6 .4 is complex and this is one where you really
need a cryptographic specialist to help,
because every key that's used to encrypt data has what's
known as a crypto-period associated with it.
The crypto-period is the length of time that the key
can be relied on to protect the data.
It varies depending on the encryption algorithm used,
the size of the key, the state-of-the-art encryption analysis,
and how much and what type of data has been encrypted with the key.
The requirement is for keys that have reached the end of their
crypto-period to be withdrawn from use and new keys to be used.
As I said,
this is quite a complex area and one that's not
massively understood by most QSAs.
So a QSA is going to look at your documentation and speak with people,
and see that you've documented the fact that you've considered what the
crypto-period could be and what your crypto-period is.
You know,
it's really rare you'll find a QSA who questions
the crypto-period you've chosen, but if you want to get this right,
if you're encrypting lots of data,
it's actually quite an important thing so again,
get a specialist to help.
Requirement 3.6 .5 sounds simple.
It is that keys that have been weakened need to be retired,
replaced, and you might need to archive them.
So there's two things to consider here.
The first is your criteria for working out when the
integrity of a key has been weakened,
and that could be because you suspect it's known or it's been
compromised or a key part has been compromised.
And secondly, you're processing or retiring or replacing the key,
and that's especially true if you've got stored cardholder
data that's encrypted with a weakened key,
and you might think, well, what do I do?
Do I decrypt it and re-encrypt it with a strong key?
You could do that.
That's quite risky.
What most people do is encrypt the encrypted data and then archive the
weakened key so it's still protected with a strong key.
If you ever need to go back to it, you decrypt it once with a strong key,
and then you decrypt it a second time with a weakened
key and you get the plain text data.
Hard stuff to do well.
The QSA will look at your procedures and they're going to
speak with people who make the call that a key's been
weakened so who's going to say, actually we should replace that key,
and then also people who would describe the process that you'd use to retire,
replace, and archive keys.
Again, as with most of the items in requirement 3.6,
this isn't simple and so expert help is really strongly advised.
Requirement 3.6 .6 is also a complex requirement and says that if ever
you have operations that involve plain text keys,
you have to observe the principle of split knowledge and dual control.
Now split knowledge and dual control can be hard to implement,
and my advice is to design your key management processes
so that you don't have clear text keys, but if you do,
let's look at what the standard requires.
And here to guide us in the standard is where you need to look,
because that's where split knowledge and dual control are defined.
Split knowledge means that one person must never have
access to an entire cryptographic key.
So there are proven techniques used that allow us to split a
plain text key between multiple people.
Let's look at a simple example.
Imagine if we had a simple eight-character key 12345678.
Splitting it in half and giving Alice one half and Bob
the other half isn't split knowledge, because if Alice or Bob was compromised,
the attacker would not know half the key.
So that really reduces the effective key strength to four characters.
Instead,
what split knowledge requires is that Alice and Bob each
have a full eight-character key part, which when they combine together,
and here in the example I've used an xor,
that produces the real key,
and there are other cryptographic techniques that can be used alongside xor.
So that was split knowledge.
Dual control means that whenever an entire key is processed,
there have to be two people responsible so that one person acting
alone can't affect the security of the key.
It is to prevent, yes, it's to prevent someone stealing the key.
So you need procedures to do this and doing this
properly is actually quite hard.
To validate that you're using split knowledge and dual control,
the QSA is going to look at your processed documentation,
observe the key management functions that are in place,
and also talk to key administrators and key custodian.
The next requirement is 3.6 guards against your encryption keys being
substituted by an attacker for the attacker's chosen keys.
Look, this is a really clever attack.
It's been used in the past,
and it's great because the criminal swapped the
organization's encryption keys for their own.
Everyone was happy, the data was still being encrypted,
but because the attacker had substituted the encryption key,
the attacker was able to decrypt all the data,
and the organization didn't know this.
They weren't able to detect it, and of course,
they were able to use the data as well.
Preventing this type of attack requires technical and procedural
controls such as making sure that key change is detected,
any key change is only possible in the dual control,
and again this is somewhere that HSM's hardware
security modules can really help.
As with all of these requirements in 3.6,
the QSA is going to look at the procedures and talk to the responsible people.
The last sub requirement of 3.6 is perhaps the simplest and wants to
make sure that all custodians know what they're doing.
The requirement is that key custodians formally acknowledge
their key custodian responsibilities,
which are typically to keep any key material they have safe and
secure and maybe not randomly give it to criminals.
The requirement is usually satisfied by having a written document that
outlines the key custodian's responsibilities and then having each key
custodian sign a copy of the document.
The QSA is going to check the procedures and look for the
evidence such as copies of that signed document,
to see where the custodians have acknowledged,
you know, their custodian responsibilities.
Some QSAs will go one step further; they'll actually go
and interview the key custodians, and say,
tell me what your key custodian responsibilities are.
That's actually not formally part of the testing requirements,
but QSAs typically do it.