Let's now talk about where people make the most
common mistakes in requirement 3, which is encrypting cardholder data.
Yes.
My view is that,
and I know you've got some thoughts about encryption;
my view is you shouldn't do it, right?
Unless you're really good and you know what you're doing.
It's radioactive.
Because it's so hard to do right and easy to do wrong.
I mean, not just easy to do wrong,
but easy to do wrong in ways that are spectacularly bad and not apparently so.
So talk to me about that.
Well, so I mean the biggest pitfall is, I mean are implementation problems,
right?
We are going to develop some software that handles the PAN and we're
going to encrypt it and then we're going to insert those encrypted
values into the database or whatever, right?
So we have to write our cryptographic routines, right?
And I mean we could do a whole course on sort of what not to
wear in terms of like cryptographic usage,
right?
And I recommend we do it a sort of drunk-history style.
But it's very, very easy to make very severe implementation errors,
right, to sort of develop your own functions rather than use like a reputable,
crypto API for the programming, to misuse cryptographic primitives.
You know, even if you pick good ciphers,
well, we're going to use AAS 256, that's a good cipher,
right?
It's still very easy to muck that up,
it's still very easy to not generate good
cryptographic keys or to mishandle those keys.
Key management is actually very difficult to do.
I'm going to get on to key management, so look,
the first thing is that even if you pick a library,
so I'm going to use AES rather than,
well I have seen people try to write their own functions,
but yeah, yeah.
Oh, me too, it's bad.
You know,
the difference between ECB and CVC in terms of your
implementation mode is really chalk and pyramids,
I mean chalk and cheese.
It's like one is a good way of encrypting data,
and the other one, you've just wasted your time on that,
yeah.
Yeah, that's an enormously bad idea, right?
So again, it's radioactive because you can spectacularly fail, right?
So the requirements in DSS, you know, from 3.5, 3.5 onwards isn't it?
Yeah, 3.5 and 3.6 are about key management.
About how you do key management then, how you do cryptography.
It doesn't talk about algorithms, though.
So tell me, you know, it doesn’t say, don't use DES, don't use Triple DES?
No, it doesn't say that, right?
It's a little bit sneaky, right?
It uses the phrase, strong cryptography,
which it defines in the glossary, right,
and points to strong cryptography as using sort of
industry-accepted kind of practices?
Yeah.
And if you talk to Council folks or you read some guidance documents,
they point to the NIST, the U.S.
National Institute of Standards and Technology,
usually the Special Publications, kind of 800 series?
Yeah, I'm thinking 853 off the top of my head.
Yeah, 53, 57,
22 even for some of the kind of guidance about how to cryptography right.
And I'll tell you why that is.
The Council doesn't want to be a crypto standards body.
No, they don't, because it's radioactive.
Yes.
It's actually, you know, having sat on the working group that wrote DSS,
we did not want to, the Council never wants to get there,
the Browns never want to get there.
NIST?
NIST are really good at this.
They're good at it.
Yeah, they do this full time, and if you're in Europe,
ENISA also do the same thing, right?
So strong cryptography means if NIST says it's okay for doing it,
it's okay for doing it.
Right.
And because crypto changes really quickly.
The DSS has got a three-year lifecycle.
You couldn't say well,
we have an example of where DSS did say strong cryptography,
brackets, e.g.
SSL.
Right.
And that's taken four and a half years to unravel.
So as a standards body, it does not want to set crypto standards.
Right, it doesn't, it doesn't,
and then occasionally sort of does something like that,
which is problematic,
because there was this about six-month stretch between those sort of first
kind of POODLE attacks that showed SSL v3 was broken,
and when DSS published the update saying,
here's your transition period, and in that six months,
there were a few sort of weirdoes like me that were going
to organizations running SSL v3 saying, this is not strong cryptography,
you have to stop that.
I know, and that was almost a matter of luck,
because if you remember, the POODLE attack came out just at the refresh to 3.1,
and 3.1 was supposed to be a change to fix the typos.
Right.
Because there's always typos in the standard,
but usually in requirement 12, because if you're proofreading it,
by the time you get to like the 200th page,
people are getting a bit.
Right, you're exhausted or you've had far too much coffee,
and in either case you're useless for proofreading.
And actually,
the really interesting thing was that came out just was the Council
was about to do a new release with typos in it,
and so it was a really good opportunity to change that,
but that's why.
So firstly,
strong cryptography is not defined in the standard; go to NIST to find out.
Yeah, NIST or ENISA, yes,
or I mean there are there a handful of standards bodies that are workable.
So now if I want to do my own crypto, I've now got some algorithms I can use,
but you're saying that even that's dangerous,
even knowing what the algorithms are is dangerous.
So there is a sort of parallel in subsidiary standard to PCI DSS called PA-DSS.
It's the payment application data security standard.
It's for assessing payment applications,
point-of-sale software, shopping carts, things like that,
and there's a separate credential, right,
a PA QSA to assess those, and for a very,
very long time,
the thing that we ran into for a number of organizations developing these
payment applications and wanting PA-DSS validation for them,
it's something that I think has maybe a couple of names.
I call it the Frankenstein key.
It's the idea where the organization says,
oh, well,
I don't want a data encrypting key and a key encrypting key
and store them separately and protect them.
They say I just want to dynamically sort of generate this key on the fly,
and so I'm going to take you know, some constant that's you know,
hard-coded into the binary,
and then I'm going to stitch it together with the serial
number for the license of the software,
and then you put some other bits together and then animate it with some dark
ritual and then it shambles around moaning for BRAINS,
but it's a terrible way of doing cryptography,
right, because your key is very deterministic.
It's predictable,
it could be reassembled because of course it could be reassembled,
which means the bad guy can do that as well.
That's not AES 256, that's like AES 8, right?
Or I have seen the best one was that we made the key from the transaction
date and the value of the transaction and the till number,
right?
The point-of-sale number.
Right.
Which all also go with the message.
So you've actually got the keying information in the message,
which is an astonishing terrible idea, right?
And go read any of those cryptographic standards and they
will tell you that the only keys worth, you know,
the time of day are ones that are randomly generated using an appropriate
sort of cryptographically sound random number generator,
right?
Which is not Fred just randomly hitting the keyboard.
Not usually, no.
Right.
So number one, implementation of crypto is hard.
Right.
Secondly, let's talk about key management.
Key management is hard.
The DSS is really weak on key management.
It says do it well, but it doesn't tell you what well looks like,
whereas like the point-to-point encryption standard
tells you what key should look like.
What it looks like to a significantly greater degree, yes.
And more to the point,
I think a lot of organizations and a lot of assessors sort of
misunderstand some of the particulars of it,
right?
And I know there's some bits about making sure that if you're using a
key-encrypting key to protect the data-encrypting key,
then those need to be, you know, the keys of equivalent strength,
and every time I say those words,
I think of the Princess Bride's rodents of unusual size,
and every time you will think that, too,
but that's easy if you know, they're both AES keys,
right?
Is the AES 256 key-encrypting key enough for the AES 256 data-encrypting key?
Yes, yes it is, but if you're say,
protecting your data-encrypting key with an RSA asymmetric key pair,
right?
And I run into this quite a bit.
Right?
Like oh, we have an RSA 2048 module that’s protecting our AES 256 key, and.
And it's like it's not big enough.
It's not big enough, right?
But there's a table; where is that table?
Is it in the PCI standard?
It's in the P2E2 standard, right, and it's in the NIST 857 document,
which is where P2P cribbed it from.
Yeah.
And really it should go in the DSS somewhere.
Okay, so now we're in danger that people are looking at this,
there are two blokes talking about crypto keys; this is not interesting.
It's not interesting.
So let's stop talking about crypto keys,
because the interesting point is it's really hard to do.
It's very complicated and there are a lot of facets.
So how do you do it well?
Do you get your QSA to come in beforehand,
or most, I'm going to be asking really terrible questions.
Are most QSAs capable of telling you how to do crypto well?
No.
Right, so number one, don't ask your QSA how to do crypto well?
Well,
I would say maybe throw your QSA a little bit of a
test and if they can understand it, but if you don't know?
You don't know how to do it.
Right, if you don't know, yeah, that's tough,
but a lot of QSAs don't have a lot of cryptographic experience,
right?
And so this is a bit of a challenge, right?
So maybe one of the things you're looking for when selecting a QSA is at least,
you know, their ability to speak, you know,
to be conversantly intelligent about cryptography.
But that's really hard as a merchant if you don't speak
intelligently about cryptography.
That's true.
And my experience is that developers think they can do crypto really well,
because they've read a book on it.
Right.
Or they've gone to that Stack Exchange thing and gone, how do I do this thing?
Right.
So like my one thing, and I buy a lot of software,
so I buy, I do a lot of RFPs for people,
and I always say, you know, you need encrypt all data it's stored and everything,
and I speak to people about how are you doing the crypto,
and they tell me, and it's like well, that's not how crypto works.
Right.
Right?
You would not use a 2048-bit RSA key for doing that,
because we'd still be waiting here for the transaction to happen,
for example, right?
So I guess the answer is to find an expert, which would be a P2P QSA?
A P2P QSA would have more cryptographic knowledge and
would be able to speak to that, even if you're not interested in P2P services,
somebody that's capable of that can help you sort the wheat from the chaff.