Secure Card Reader: PIN - PCI PTS V5.1

Just last week (9th March 2018) PCI released the latest version of their PIN Transaction Security (PTS) standard.  This standard covers the security of ‘traditional’ PIN entry terminals, card readers, Unattended Payment Terminals, Encrypting PINPads (EPPs), as well as ‘non-PIN’ terminals – all of these devices are covered under the collective noun ‘point of interaction’ or POI.  These various approval classes are shown below, grouped according to their PIN use, if they’re commonly used in attended or unattended environments, or if they are covered by a different standard.

It is common for PCI to release x.1 versions of their PTS standard at around 18 months – or half of the publish lifetime – of that standard in order to address errata, update guidance, etc.  Usually, these changes are not so big.  However, the new v5.1 standard is a bit special, as it introduces an entirely new approval class - the Secure Card Reader: PIN, or SCRP.

SCRP - What's the difference?

An SCRP is a mandatory item for a solution that is to be approved to the new PCI Software PIN on COTS standard, and differs from a ‘normal’ SCR in a number of ways; most obviously in that it is required to translate PINs sent to it from the COTS device. But there are other differences, the main ones are summarised below:

• Protection of the ICC I/O pin to 26 points (rather than 20 for ‘normal’ SCRs)
• Key security to 35 points (as it’s protecting PIN relevant keys)
• All software in the SCRP must be considered firmware  
• Cannot allow for deactivation of encryption of card data
• The SCRP cannot have the physical features for an MSR reader
• Integrate the EMV L2 kernel, or us a ‘cloud’ kernel
• Must support the creation and delivery of PAN tokens to the COTS device
• Support the creation and delivery of entropy/random data to the COTS
• Implement a secure channel for communications to the COTS device
• Implement ‘enablement’ tokens provided from the monitor host
• So that the SCRP is automatically disabled after no more than 10 minutes of no communications from the monitor backend
• Receive PINs from the COTS device in ISO format 4, and translate these for online use (or send them to the customer ICC in the case of an offline PIN transaction)

There are a few implications from the above details.  Firstly, it is very likely that any existing SCR will need at least some changes before it can be compliant to the SCRP requirements.  These are definitely going to include logical changes - token generation, entropy delivery to the COTS device, automatic disablement ‘watchdog’ (more on this below), etc. It is reasonable to expect that there will also need to be some physical changes as well – to increase the security level, or to remove MSR features.

So, if you’re planning to be in the SPoC game, you’re going to need to read through v5.1 carefully and figure out what needs to be done ASAP.

Secondly, because there are these fundamental differences between an SCRP and an SCR, it is likely that there will be a completely separate listing for such a product.  New model name, new firmware version, new hardware version.  This means you will not be able to ‘switch’ a device between being an SCR to an SCRP and back again by loading new firmware in the field (for example).  An SCRP is always an SCRP.

Make it so!

Finally, it’s worth teasing out the ‘enablement token’ part a bit.  Because a SPoC system relies on the SCRP as a root of trust, it is important that the SCRP is able to control the SPoC system in some way.  This is achieved through these ‘enablement tokens’ which must be supplied by the backend monitor system of the SPoC solution at least every 10 minutes to enable the operation of the SCRP.  If no token is supplied within a 10-minute window from the last token, the SCRP must stop accepting cards – whether they’re to be used for PIN transactions or not.

This is like a hardware watchdog timer – if you’re a hardware person – which is commonly used in embedded systems to prevent run-away crashes of that system.  Here the ‘watchdog’ token is used instead to prevent a malicious entity from trying to fool the SPoC system that everything is OK even when the backend monitor is disconnected.  The token must be implemented to prevent man-in-the-middle, replay, pre-play, and other types of attacks to further achieve this goal.

These are just some of the examples where PTS v5.1 contains subtle differences that can greatly affect your design.  If you want advice on other aspects, you know how to reach us.