[Autogenerated] there are a lot of new requirements regarding the encryption of
cardholder data and also a sensitive authentication data.
It's becoming increasingly clear that with the power of modern computers
hashing a pan really doesn't protect it anymore so that if you're using
hashing to meet the requirement to make pan unreadable,
then the hash now needs to be a cryptographically keyed hash such as an H Mac.
And the cryptographic key used in conjunction with the
hashing algorithm should be protected in the same way that
any cryptographic key is protected.
This could be an important change.
Also if you're using a hashed pan outside of the cardholder data
environment because that hash would also need to be a
cryptographically keyed hash to maintain the concept that the
hashes out of scope of the pc IDs requirements.
The second major cryptographic change is that stored
sensitive authentication data which remember PCs CSS allows
to be stored before authorization.
Well stored sensitive authentication data also now needs to
be encrypted using strong cryptography.
Typically most organizations don't store track data now or pins or pin blocks.
So I guess this requirement will mostly apply to the cvV two values
using e commerce transactions and this is going to lead to its own
challenge because encrypting three or four digits.
It's actually quite hard to do properly.
So I'm optimistic the PCs sc will produce some
guidelines about how to do this properly.
The next major change under the heading of cryptography is that
whole disk or whole partition encryption is no longer considered
sufficient to encrypt stored cardholder data.
This was always an area that needed cleaning up because an
organization claiming about using BitLocker on a server
provided sufficient protection for panic.
Rest really was quite laughable.
So any stored pam mouth needs to be properly encrypted.
Although organizations still can rely on stuff like the transparent data
encryption functions provided by commercial databases but generally file
level or field level encryption is what's needed.
Whole disk or media encryption is actually still allowed in
one particular case and that's to protect panel when it's
stored on removable media only.
So something like a USB drive.
And the standard notes that for the avoidance of doubt hot swappable disks in
a disk array on a server are not clusters removable media.
Next what might appear to be an insignificant change but actually
can involve a lot of work for an organization and this is to
create a cryptographic inventory of everywhere that cryptography
is used in the organization.
This infantry must include where cryptography is used for data
at rest and also any certificates used for session level
encryption for a large organization.
This may take a number of people quite a lot of time to do.
The reason it's a requirement is to be able to support the new requirement
12.3.3 which is that the organization every year needs to do a cryptographic
risk assessment to make sure that all of its cryptography is still strong And
that it will remain strong for the next 12 months.
One key reason for this is that during the course of the lifetime of PCISS
version four there is the potential that quantum computing will significantly
reduce the strength of algorithms and key lengths.
So the standard requires entities to make this formal evaluation of
their cryptographic strength on an annual basis.
I don't expect this formal evaluation to take much effort but the initial
creation of an inventory of everywhere that cryptography is used,
including algorithms and key sizes might take a fair bit of work.
The final cryptographic change is that all certificates now need to be managed,
checked and confirmed to be valid.
This means that applications will need to check a
certificate hasn't been revoked.
The applicability notes do still allow for the use of self science
certificates but only in cases where they've been properly generated
by an internal certificate authority and the certificate is
confirmed to be valid and trusted before it is used Although not
part of DSS version four,
I just quickly want to mention that three key triple deckers.
So T D says Will most probably not be considered strong
cryptography after 31 December 2023 because from this day the
National Institute of Standards and Technology Nist has
disallowed its use for the encryption of data.
I mentioned this here because if you're planning to do
cryptographic changes as a result of DSS version four,
you should also be planning to stop using tDS if you're using it,
certainly for the storage of cardholder data and probably
for the protection of pan in transit.
At the time of recording this course,
the PCA has not published any guidance on the demise of triple days,
but it might have done by the time you're taking this course.
So please check the pc sc website