Requirement 3.4 in itself is pretty straightforward.
PCI DSS prohibits you from storing plain text or
unencrypted primary account numbers or PANs.
Now personally, I would take this one step further,
because my advice to all organizations is just not to store cardholder data,
because if you don't store it, criminals cannot steal it; well,
they can't steal it from datastores anyway.
They could still steal it in memory, but you know,
a big target for criminals is stored cardholder data.
No stored cardholder data, people can't steal it from there,
but remember, this is just my advice, it's not what the standard says.
What the standard says is this; it's says that if you
do store primary account numbers, you cannot store them in a plain text format.
The exact wording of the requirement is that an organization has to
render or make PANs unreadable wherever they are stored,
and the standard offers four ways to make PANs unreadable.
These are firstly,
creating a one-way hash of the PAN using an
industry-approved strong hashing algorithm.
Secondly, truncating the PAN,
which obscures all but the first six and last four digits.
Thirdly,
replacing PANs with tokens using a system that exchanges a token for a PAN.
And then finally employing strong cryptography.
If you're going to create a hash of the PAN,
PCI DSS requires that the hash is of the entire PAN
and not just the proportion of it,
and that a recognized hashing algorithm is used.
PCI DSS doesn't actually require a salt in the hashing process; however,
look, this is strongly recommended,
because there are so few PANs based on a 16-digit number that actually
matches the sixteen-digit checksum that cards use that it's actually
easy to create a rainbow table over them.
So although the standard doesn't say it,
you should have a salt when you hash PANs.
PAN truncation is a complicated way of saying that a PAN is
stored with some of the middle digits missing,
the idea being that if somebody got hold of a truncated PAN,
it could not be used for fraudulent transactions.
And people often confuse truncation and masking.
Remember, masking,
which we looked at like a couple of clips ago is about
not showing the full PAN on screen.
Truncation is about not storing the full PAN.
And a truncated PAN can contain as many as or it's the same as masking actually.
It's the same as the first six and the last four digits of the real PAN,
and the remaining five or six digits in the middle
are stored replaced by asterisks.
There's a really useful FAQ on the PCI SSE website that describes
acceptable truncation formats for all of the different lengths of PANs
you might encounter from each card brand.
Tokenization replaces a PAN with a value that isn't a PAN.
Tokens often keep the same structure and the same format as
PANs so they can be used in systems that expect to see and
store a sixteen-character field.
And just like a truncated PAN,
a token contains the real first six and last four digits of the original PAN.
Typically,
an organization will have a tokenization server or a tokenization
appliance that exchanges PANs for tokens and also,
you know, given the right security, can turn a token back into a PAN.
The alternative,
they'll use an external tokenization service provided by their processor,
their acquirer or their merchant bank.
Now here's something awesome.
Truncation, hashing, and tokenization are magic as far as PCI DSS is concerned,
because they turn a PAN into something that's not a PAN,
and something that's not a PAN does not need to be protected by PCI DSS.
Let me say that again.
If you take a PAN and you hash it or truncate it or tokenize it,
it is no longer a PAN,
and the PCI DSS requirements apply to systems that
store process or transmit PANs.
PCI DSS does not apply to systems that do not store process or transmit PANs.
On the other hand,
the fourth option that requirement 3.4 offers to
prevent storing plain text PANs, encryption is not magic,
and this is really important, because people often get this wrong.
As far as PCI DSS is concerned, an encrypted PAN is still a PAN,
and it needs to be protected by the PCI DSS requirements.
So systems that store encrypted PANs are fully in scope of PCI DSS.
There are some rare exceptions to this,
and the FAQs on the PCI SSC website are really useful here,
but if you ever want to make an argument that
encrypted PAN doesn't need protection, and you can in some circumstances do this,
you really need to talk with an experienced QSA.
If you are going to store encrypted PANs,
you must use strong cryptography, which is defined in the PCI glossary,
and essentially it means you should use a recognized,
and to all intents and purposes this means a NIST-approved algorithm,
a recognized algorithm of at least 112 bits of key strength.
That 112 bits minimum requirement is actually there to allow people to
continue to use an encryption algorithm called Triple DES,
which is used extensively in some legacy bits of the payment ecosystem,
but if you're designing something now,
really 128 bits of key strength should be your minimum,
so 128-bit AES effectively.
To test an organization's compliance with the requirement 3.4,
the QSA is going to look at all the places primary account numbers may be
stored and validate there are no occurrences of plain text PANs.
If encryptional tokenization is used, the QSA,
yeah,
they're also going to probably look at the vendor's documentation to
understand how the tokenization system or the encryption works.
Ah gosh,
look; I could give a whole course on ways to encrypt tokenized and hashed PANs,
so if you're thinking of storing a PAN,
my advice is really to talk to an experienced QSA first.
There's a further wrinkle to requirement 3.4, which I'm not a great fan of.
Requirement 3.4 .1 says that if you're using whole disk
encryption to protect PANs in accordance with 3.4,
it should not be integrated with the same
authentication system as the operating system.
Let's unpick this requirement, and first off,
I'm not going to have the debate about whether whole disk encryption really
meets the intent of not storing plain text cardholder data here,
but Jacob and I have a long discussion about it at the end of the module.
What I am going to look at is what the standard says and why.
So basically, if you use disk or partition encryption to meet requirement 3.4,
but you encrypt PANs that are stored,
this sub requirement says that the credentials to manage the
encryption must be separate from the operating system,
and you can see that this makes sense, because if I've authenticated to the OS,
and that's also good enough for the disk encryption,
merely logging into the operating system makes all
stored cardholder data available to me.
It's essentially plain text storage when
authenticated user of the operating system.
Now that's not really true when it comes to removal media or portable media,
so like a USB disk or a portable drive where whole
disk encryption is really good.
To test this requirement,
the QSA will look at how whole-disk or partition encryption is being set up,
and make sure it's not tied to the operating system credentials.
The QSA will also look at how the encryption works so
the size of the algorithm used, and also the associated key management with it.