Now let's take a quick look at the three standards that are concerned with
entire payment solutions for face‑to‑face transactions.
The aim of all these standards is to ensure that all payment data,
whether that's PANs or PINs,
is strongly encrypted and inaccessible in the merchant's environment,
which massively reduces the number of requirements the
merchant has to meet to comply with PCI DSS.
The Point‑to‑Point Encryption, or P2PE standard,
describes how to encrypt the primary account number in a
POI device in the merchant's environment,
and then to make sure it stays encrypted until it reaches a point of decryption,
which is usually in a payment service provider or in an acquirer.
It specifies the physical and logical controls for key management,
the security of the decryption environment,
and also how the POI devices should be managed.
The P2PE standard was developed so that merchants could buy solutions
from service providers and know that the solution had been assessed
to a high standard and that cardholder data wouldn't be accessible in
the merchant environment.
Remember that when we looked at the face‑to‑face example earlier,
there were lots of places you could potentially find
authorization data‑‑in devices, in electronic cash registers,
in point‑of‑sale systems, in store servers,
and on servers in head office.
Well,
the goal of the point‑to‑point encryption standard is to
make sure that all cardholder data in the merchant
environment is strongly encrypted, and so useless to criminals.
It does this very much in the way that PINs are encrypted,
by strongly encrypting the track data within the PTS POI device using
an encryption key that's been supplied by the acquirer or by the
payment processor or by the service provider.
So whoever provides the solution to the merchant puts their
encryption key in the PTS POI device.
So all the data flowing through the merchant system is now strongly encrypted,
and so the criminal won't be able to get card data
from the merchant environment.
And, of course, nothing in the merchant's environment now stores,
processes, or transmits unencrypted cardholder data.
So the PCI DSS requirements won't apply to the majority of
systems in the merchant environment,
which is really cost effective for the merchant.
There is a downside.
Using P2PE means the merchant won't be able to retain cardholder data,
for example, in a database like they used to.
The P2PE standard relies on the merchant using a validated PCI PTS POI that also
includes the capability to securely read and transmit PANs.
Such POIs are actually quite expensive to manufacture because of the security
and anti‑tamper mechanisms that they must have in them.
And so innovative vendors decided that it should be possible to
turn an off‑the‑shelf smartphone or a tablet into something that
could securely accept payments.
And so there are now two PCI standards that support this.
They both have extraordinarily long names that use the term COTS,
C‑O‑T‑S, which stands for Commercial Off‑The‑Shelf,
or, in other words,
things you can buy in normal shops such as smartphones and tablets.
The first standard is called Software‑Based PIN Entry on COTS,
or SPoC for short.
A SPoC solution allows a merchant to use an off‑the‑shelf smartphone or tablet
connected to a card reader to accept payment transactions.
So the standard includes requirements for a secure encrypting card
reader which connects to the commercial off‑the‑shelf smartphone or
tablet either by a Bluetooth or by a cable.
And it also includes requirements for some software running on the
smartphone which accepts the PIN and then communicates with both the
card reader and the solution provider.
And, finally,
requirements for a system at the solution provider that can
decrypt the payment card data and can also monitor the security
status of the smartphone or tablets,
so the device where the PIN is being accepted.
In a SPoC solution, the payment card data is read in the secure card reader,
but the PIN is entered into the smartphone.
Both the cardholder data and the PIN are actually
encrypted by the external card reader,
but then they are sent to the solution provider for processing.
So very much like the P2P standard, the SPoC standard covers the hardware,
the software, and the systems used by the solution provider.
The second PCI security standard that allows a merchant to use a
commercial off‑the‑shelf smartphone to accept payments also has a
long name and a short abbreviation.
This is the Contactless Payments on COTS Solutions standard, or CPoC short.
A CPoC solution allows a merchant to accept contactless transactions that
don't require a PIN on an off‑the‑shelf smartphone.
The smartphone has to have the necessary NFC antenna and electronics
in it to be able to pretend to be a card reader.
Just as with SPoC,
the standard covers the way that the software works on
the device and the back‑end systems,
which both decrypt the received data from the device and which can
monitor security posture of the smartphone or the tablet.
Ah, now it's time for a quick sidebar about device security.
From a security perspective, in a SPoC solution,
the PAN and the track data contained in the magnetic stripe or the
equivalent from the chip are encrypted in the card reader,
but the PIN is entered into an app on the device's screen.
The PIN is then sent to the card reader to also be strongly encrypted.
But at some stage, the device will see the unencrypted PIN,
but it will never see the unencrypted PAN.
In a CPoC solution, only the contactless information is read from the card,
which will include the PAN and the mag stripe equivalent.
And that will be received in clear text by the device,
and then it's encrypted in the device.
So the device sees the PAN, but it doesn't see the PIN because,
remember,
CPoC is only for transactions without the PIN where the
value of the transaction is below the limit set for
contactless transactions without PIN.
Now you may be thinking, Well,
what about contactless transactions with a PIN where the value of the
transaction is over the limit allowed for transactions without a PIN?
Of course, the issue then is that without an external reader,
the device itself would have all the information from the card along
with the PIN that's been entered on the device.
And although that in itself wouldn't allow for a fraudulent transaction,
it does remove one of the major protections.
And so the industry is going to be cautious about this because
some malware running on that device would be able to get access to
unencrypted PANs and unencrypted PINs.
However,
at some stage I think that this cautiousness will be overcome so there may be a
third acceptance‑on‑COTS‑device standard which allows for a device to act as a
contactless card reader and also accept the PIN.
Just like the P2PE standard,
the SPoC and CPoC standards make sure that all payment card data is strongly
encrypted and so inaccessible in the merchant environment.
And that's important because it means that the merchant's again not
going to have to take responsibility for security other than properly
looking after the card readers and the devices.