The creation of a new standard of cybersecurity certification is always an exciting event as it involves exploring new technologies and establishing the basis on how an adequate design of the key aspects of cybersecurity should be for the typology of products under study. However, this is not usually exempt from problems or unknowns that are usually suffered by manufacturers who venture to spearhead and be at the forefront, not only from the technological point of view, but also from compliance.
The PCI council and the PCI DSS security standard
Known by its acronym PCI or PCI SSC, the Payment Card Industry Security Standards Council, is a forum that was created in 2006 by the main promoters of the financial card industry (American Express, MasterCard, VISA…). The council was created with the intention of promoting the card payment industry through, among other actions, the creation of security standards that raise the level of confidence of citizens securing the present and the future of this kind of financial transactions, and in a concrete way, ensuring the protection of the PIN and the cardholder data.
Maybe the most popular standard created by PCI is the one known as PCI DSS (Data Security Standard). PCI DSS provides a reference of technical and operational requirements developed to protect account data and it is applied to all entities involved in the processing of payment cards, including merchants, processors, acquirers, issuers and suppliers of services. The PCI DSS standard applies to all entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).
That is, if your application processes credit card data, for example, to implement transactions over the Internet, then you are likely to be affected by PCI-DSS, although, you probably prefer to delegate that responsibility to the well-known payment gateways, and avoid doing this processing for yourself.
PCI-DSS maintains 12 requirements to be met for systems that process credit card data and requires the implementation of an ISMS (Information Security Management System), in a similar way to other well-known standards, such as ISO 270001; although PCI-DSS acts as the only central accreditation entity while maintaining close control over who can or cannot audit these systems. The standard lays special emphasis on, for example, the proper segmentation of the network or the performance of vulnerability analysis to systems on a regular basis.
However, as we all know, man does not live by Internet payments alone, and that is why, in addition to PCI-DSS, the council has created a security regulation for the means by which probably most of us use credit cards, payment terminals.
A standard for the payment terminals, PCI PTS
The PCI PTS (Pin Transaction Security) standard addresses the logical and/or physical protection of the cardholder and other sensitive data in point of interaction (POI) devices and hardware security modules (HSM). An interaction point, for example, would be the payment terminal that we all use almost every day to pay in a store, while an HSM is a hardware device capable of carrying out and safeguarding cryptographic keys and that are usually evaluated against other rules of the industry as FIPS 140-2.
PCI-PTS follows a modular approach, according to which, your product must be evaluated against a common module of requirements that are considered nuclear and that refer to the safe construction and design of the device, and another set of optional requirements depending on whether the product implements or not certain features, such as communication with wireless standards (WiFi, Bluetooth, ...) or the ability to encrypt account data (SRED).
Cybersecurity is a never-ending race against potential attackers, and as a result, it is necessary to review, update and improve security regulations and the techniques used to verify compliance from the technical point of view. Therefore, the council updates the regulations and all their requirements normally every three years.
New payment ways
However, social and technological evolution creates use scenarios that were not foreseen and that escape the contents of the standard, demanding the development of new standards.
Given the proliferation of smartphones connected to the Internet, in certain countries it has become common to see how taxi drivers who do not have a PCI-PTS certified payment terminal, manually copy the data of the cards in their smartphone, using an application in the cloud, in order to accept card payments. Of course, this trend lacks even the minimal security measures, and meet the needs that technology itself has created.
Furthermore, the capabilities of the new generation smartphones encourage the use of mobile payment through technologies such as Apple Pay or Samsung Pay that allow payment using a credit card stored virtually in the cell phone.
Given this situation, would not it be desirable to have a PTS terminal in your pocket so that you cannot only make card payments from your mobile but also to accept them? Are we not technologically ready for something like that?
The proliferation of technology such as Secure Elements has allowed payment with the smartphone and will also allow receiving payments, but before, the payment industry, through the PCI-SSC, must establish the rules that guarantee the security of this sort of transactions.
PCI SPoC
That is why, in April 2018, a year ago, the council published the PCI-SPoC Software-based PIN Entry on COTS (Commercial off-the-shelf) standard. The objective of this new norm is to lay the foundations of what cybersecurity requirements must be demandable for a smartphone, tablet or wearable application, the device on which it is executed, to the card reader and the cloud infrastructure that supports the transaction financial. This kind of application is also known as "PIN-on-glass", since it allows the secure entry of a PIN number and is able to communicate with a card through the use of a smart card reader for PIN (SCRP).
PCI-SPoC evaluates a complete solution formed by the phone app, the processing, monitoring and attestation system, which must meet a series of requirements similar to those established by PCI-DSS, and the card reader, which must have been previously evaluated against the PCI-PTS standard.
This time, however, the rule seems not to have arrived on time and the industry has developed outside the regulations, particularly in those countries where the use to which we are used to of bank cards is not so widespread, where it is normal to find citizens who do not have a current account and where transactions almost never use PINs regardless of the amount, and there are applications that perform very similar to the standard that is intended to cover and, nevertheless, are far from what is requested, sometimes counting already with a considerably large user grounding, which makes manufacturers who have already created their own ecosystem to be in the frame of having to drop it and start from scratch to achieve the requirements.
For example, the TF1.1 test establishes that the only way to insert data from the card into the application must be through an approved PCI-PTS device, so that if an application used an unapproved device, it is not a priori possible to provide both capabilities in the same application, but it should be a fork, with the consequent confusion and potential loss of end users.
In addition, the standard seems to have been written with Googles operating system in mind, setting requirements for WhiteBox Cryptography or Trusted Execution Environment that are far from obvious to implement in operating systems where the capacity of application developers is much more limited as is the case of iOS, which incidentally takes a lot more road walking in terms of cybersecurity than Android.
