Payment card fraud
For every $100 in volume spent through payment cards, 5.65¢ was fraudulent in 2014 – and the numbers continue to climb. The attacks on payment systems that lead to card fraud amount to billions of dollars in losses annually. All of us are paying for it – both directly through personal loss and indirectly through added cost for payment transactions.
How can technology help protect us from these attacks and fraudulent use of our cards?
Let’s look at what the SLN-POS-RDR is designed to do and the meaning behind its nomenclature:
SLN = Solution
POS= Point of Sale
RDR = Reader
This is a class of products from NXP that brings together hardware, software and certifications, enabling you to implement devices that accept payment cards.
Picture the devices you use to pay in the check-out at the grocery store, coffee shop, clothing store or small food truck. Now that you have some idea of the type of device this solution supports, let’s focus on what a solution is.
There are a couple of common definitions for the word solution. A solution can be the means of solving a problem or dealing with a difficult situation. The word solution is also defined as a mixture in which the solute is distributed within the major component (the solvent). Both of these definitions can be applicable to the SLN-POS-RDR, the secure card reader solution that address the problems of developing a payment terminal with a high level of security integration.
Solving a problem
Solutions are built with an end goal in mind and to address specific problems. In the case of the secure card reader, the solution addresses the needs around the payment card interfaces. Beyond the software drivers and stacks that run on the microcontroller, there are hardware components for IC card readers (contact interface), and the NFC front ends (contactless interface). Bringing these pieces together and performing compliance testing leads to components that more completely address the specific challenges that a payment terminal manufacturer will face.
To show how the application problems are solved, the solutions being created by NXP are measured by certification and compliance testing where applicable. In this way, instead of simply showing the answer to the problem, the collateral built around the compliance testing provides the user of the card reader solution with the methodology that can be used to solve the problem.
A secure card reader is a complex device, having functions related to user interaction with display and a pin pad, the card reader interfaces and USB communications to a host. Bringing all of these functions together into one application means that interactions and dependencies for MCU resources have to be considered. The influence on the hardware and software components of the solution leads to a robustness and usability that benefits the user as they develop their end products.
A solution of security
Central to building a solution for payment systems is meeting the security requirements set in place to combat the staggering card fraud problem. For a secure card reader, there are two standards that are considered throughout the development and deployment of these devices. These standards are the Payment Card Industry Security Standards Council requirements for Pin Transaction Security (PCI PTS) and the EMVCo EMV Specifications.
In order to meet these standards, security has to be considered in all aspects of the card reader design. As an example, to achieve PCI PTS certification, the software development has to be shown to be secure and robust. More about how processor features align to the security standards for payment systems will be covered in an upcoming ARM TechCon Session. For a payment application solution, security is distributed throughout the design creating a solution of security into the payment application.
There are many resources highlighting the MCU technology needed to meet security requirements. These are the trust, cryptography and anti-tamper capabilities for NXP MCUs. For the card reader solution, we get to see the technology in use. Some examples include the use of cryptography to secure the data transfers from payment cards to the card reader. In addition to adhere to security requirements for card holder PIN information, the software functions that handle this data are protected by memory clear functions to ensure that sensitive data does not persist longer than necessary. The solution software also makes use of the system memory protection unit of the MCU, separating software functions with logical protection in order to protect highly secure data.
With regards to anti-tamper capabilities, there is an example built into the solution to demonstrate the capabilities of actively monitoring a tamper mesh. This example makes use of NXP’s Kinetis Software Development Kit in order to initialize the DryICE peripheral to detect a physical attack. In addition, grouped into the card reader solution will be documents related to the PCI evaluations done for the MCU and associated hardware. These documents will provide guidelines on which MCU features are necessary to meet the PCI PTS requirements.
The benefits of creating a solution can go beyond the targeted use case. Just as complex mathematical problems can be broken down, so can the challenges of embedded design. With a solution, like the SLN-POS-RDR, not only are we addressing industry problems such as card fraud, but also the challenges of embedded design. Bringing security along with other common embedded functions around human interfacing and communications will enable the developer to confidently bring their devices to production.