Meet The Family: Payment Security Standards

0

UL LogoUL has published their latest white paper which provides a comprehensive overview of all the payment security standards involved in electronic transactions. This supports the understanding of what standards, industry organizations and payment schemes require for electronic payments to be considered secure.

Payment Processing 
Electronic payments are increasingly becoming part of our everyday lives.  For most people, it can be hard to imagine a single day where we do not make a purchase using our payment cards in a physical store, or perform some form of online payment or money transfer.  We almost take for granted the fact that these systems work, without consideration for how they work.  But consideration of the ‘how’ is important to understand what protects our electronic payments now, and to properly assess the changes that will be made to the way we perform electronic payments in the near future.

Payment processing is most commonly performed using a ‘four corner’ model, where four separate parties are involved in each transaction; the customer, the merchant, the merchants Acquiring Financial Institution, and the customers Issuing Financial Institution.  Different standards apply to each of the ‘corners’ of the transaction, as illustrated below for a generic ‘card present’ transaction.

Note that for ‘card not present’ transactions, such as eCommerce, the EMV, PCI PTS and PCI P2PE requirements do not currently apply.  This is because EMV L1 and L2 (Level 1 and Level 2) standards relate to the way in which a card present transaction is performed, and the PCI PTS and P2PE requirements to how a card present transaction can be secured.

Therefore, we can look at the standardization of payments processing as two broad groups; functional standards which detail how a transaction is processed, and security standards which detail how a transaction is secured.  This whitepaper is concerned primarily with the security standards of card present transaction processing.

Payment Security Standards

The payments industry is fundamentally based on trust.  When you use your payment card to purchase goods or services, you trust the merchant to accept that payment method and manage your details in some secure way.  The merchant trusts that this method of payment will eventually end up with funds being transferred into their bank accounts if the payment is authorized.  The financial institution that issues your payment card trusts that the details they receive from the merchants’ bank are not fraudulent, and the merchants’ bank trusts that the Issuer is going to follow through on their commitments if they approve the transaction.
The standards for security in payments are written and enforced with the intent of ensuring the required levels of trust to all parties involved.  Although there are many localized standards, this paper focuses solely on the International standards, their scope and application.

Standards Bodies

When discussing International payment security standards, there are four main actors that need to be discussed, these being PCI SSC, ISO, ANSI, and EMV.  Both PCI SSC (the Payment Card Industry Security Standards Council), and EMV (named after its founding payment brands of EuroPay, MasterCard, and Visa) are Industry bodies that have been established by the payment brands specifically to manage standards for their industry.  In contrast ISO (the International Standards Organization), and ANSI (American National Standards Institute manage standards covering many different areas, some of which include security and specific items for the payment industry.   The FIPS (Federal Information Processing Standards) standards interact with payments only tangentially, being used as references or benchmarks for other, payment specific, standards.

In addition to these standards bodies, there is also the Common Criteria approval methodology which is sometimes applied in the evaluation of payments systems.  Common Criteria is different from the previously mentioned standards bodies in that it is not a single approval or standards body, and devices or systems must be tested against a specific ‘Protection Profile’, or ‘Security Target’ which is often be created bespoke for each device to be evaluated.  Common Criteria evaluations are favoured in the European region, and this methodology has been chosen for use with the Common Approval Scheme (CAS) which is to form part of the approval of devices to be used within the Single European Payments Arena (SEPA).

Payment Card Security 

Card present payments start with the customer card, so it is fitting perhaps to start with these as we examine the standards for payment security.  Historically, payment cards have not been very secure.  They have contained static information that is easily read and copied, and once copied it is very difficult to differentiate the original from the clone.  For this reason, the EMV standards were created to outline a whole new methodology for performing payments, using a secure card that could provide cryptographic authentication of itself and the transaction.   The EMV standards themselves are separated into three broad groups; ones that outline the security of the processing element, or ‘chip’ on the customer card; ones that detail the physical and electrical interface of the customer card and payment terminal; and finally standards that outline how the transaction is to be performed.

The security of customer cards, or more specifically the security of the ‘chips’ used in EMV cards, is covered by EMV Security Guidelines, currently published as v4.  This standard addresses both the physical security of the chip itself, as well as the security of the applications and cryptographic operations performed by the chips.

Much of the other EMV requirements are much more focused on the ‘how’ of the transaction, rather than the security of the transaction.  However, as part of this ‘how’ the standards do allow for the customer card to provide authentication data to the payment terminal; preventing the ‘cloning’ of payment cards.  Additionally, an EMV card can also provide authentication data relating to the transaction itself, allowing for a card Issuer to validate that the transaction that the customer authorized is the same as that communicated from the payment terminal.
EMV cards provide this authentication using cryptographic keys that are stored on their processing elements  and using profiles, or ‘scripts’, that outline how these keys are to be used.  The loading of these profiles and cryptographic keys is referred to as the ‘personalization’ (or ‘perso’) process, and understandably is highly security sensitive.  The security of this ‘perso’ process is covered under the PCI Card Production standard, which is an audit standard that is designed to ensure that Issuing Financial Institutions – and their agents – ensure that there is sufficient security in their handling of customer cards and the process of loading cryptographic keys and profile data.

Payment Device Security 

Standards addressing the security of devices accepting or authenticating our payment transactions have been written to address both the physical and logical security aspects of payment devices, but it is perhaps true to say that these standards have started to show their hardware bias.  The rapid changes in software – and the importance of software within hardware security modules – is something that is difficult to address within hardware security standards.  Hardware does not change once shipped, but often it is important to have update methodologies for addressing new vulnerabilities in software even after shipping.  Given this, it is reasonable to expect that software security will become an increasing focus for all aspects of security and security standards into the future.

The seminal standard for hardware security is ISO13491, which covers the security of Secure Cryptographic Modules (SCM) which includes PIN Entry Devices, Hardware Security Modules, Automatic Teller Machines, amongst others.  Although ISO13491 is still used by many local payment schemes as a basis for device testing and approval, both PCI PTS and Common Criteria standards and methodologies have overtaken this standard as the most common evaluation method.

The PCI PTS (PIN Transaction Security) standards address the security of devices used by customers to perform card present transactions, as well as the Hardware Security Modules (HSMs) that are used to generate/verify customer PINs, and manage the cryptographic keys used to secure customer PINs and card data whilst they are transmitted from the Point of Interaction through to the Issuing Financial Institution.

PCI PTS was formed by the collaboration of MasterCard and Visa in 2004, even prior to the creation of the PCI SSC, and along with the PCI PIN standard (discussed later) were the first documents to carry the PCI name.  The PCI PTS standards are updated every three years, with the current version being v4 of this standard.  Initially these standards took their inspiration from hardware security standards such as ISO13491 and FIPS140-2, however their comparatively rapid update cycle and industry acceptance has meant that they have increasingly become a source of inspiration themselves:  The SEPA CAS POI Protection Profile is currently based upon the PCI PTS v3 requirements, and the latest version of ISO13491 borrows concepts previously only found in the PCI PTS criteria.  At the time of writing testing against the CAS POI PP has just completed its trial stages, and the Protection Profile is expected to be update to reflect learnings from the initial evaluations and to reflect the changes made in v4 of the PCI PTS standard.

Devices used for the acceptance of customer card information and/or customer PINs in a card present environment are referred to as ‘Point of Interaction’ (POI) devices within the PCI PTS standard and wider industry.  These devices are assessed under the PCI PTS POI
standard, covering both attended and unattended payment devices of all types – with one exception.  At the time of writing, Automatic Teller Machines (ATMs) are not covered by the PCI PTS POI standard, and cannot be approved by PCI.  Currently, the PCI Payment Brands only mandate the approval of devices which are used to accept customer PINs.

Key Management 

The standards that address hardware security, discussed above, have a single common element in that in every case the hardware system being assessed is intended to prevent the disclosure of some secret data.  Most often this secret is a cryptographic key, and that key is used by the hardware system to secure other data – customer card information, customer PINs, authentication information – as it is sent between systems that are disparate from both a physical and security point of view.

The management of cryptographic keys is a particularly complex problem, due to the fact that it by necessity involves human interaction – and therefore is prone to mistakes.  Such mistakes are especially concerning as they can involve the secret cryptographic keys that protect all customer PINs and cardholder data.  Therefore, the standardization of secure management of cryptographic keys is very important and this topic is covered by all of the payment standards bodies.

The main, generic, references for management of cryptographic keys used in payments are ISO11568 and ANSI X9.24.  These two documents are largely similar, covering basic principles such as dual control and split knowledge, acceptable forms for keys and key components, and methodologies for the generation of keys.  However, ANSI X9.24 goes a step further and defines an entire key management protocol known as Derived Unique Keys Per Transaction (or DUKPT).   This has become the most common and widely used key management method in the payment industry.

As key management is a human driven process, the standards covering this must also include method for auditing or validating the correct implementation of any secure methods.  Such audit standards are provided in the PCI PIN, and ANSI TR 39 standards.  Additionally, standards such as the PCI Card Production requirements, PCI Point to Point Encryption (P2PE), and PCI DSS standards have sections that cover the management of cryptographic keys.

Application Security 

Software security is a vital aspect of the overall security of a payment system.  It is of no benefit to have a physically secure device if the software that runs on that device is vulnerable.  However, the rapid evolution of software vulnerability analysis has caused an increased focus on software security within payments, and standards to address this are not as prevalent as those addressing hardware security.  Currently, PCI is the only standards body that has a specific payment software security standard (PA DSS), although software is addressed to a lesser extent in traditional hardware standards such as ISO13491, PCI PTS, and the CAS POI PP.
At the time of writing, new payment application security standards are in development and it can be expected that this will be an area of great focus over the coming years.

System Security 

The PCI Data Security Standard (PCI DSS) is an audit standard that focuses on the security of environments that are used to store, process and/or transmit cardholder data.  Although this standard does cover technical aspects of security, such as network security and encryption, it also has a large focus on procedures and validating the correct, on-going implementation of security measures to protect card data.

PCI DSS is deliberately wide in scope.  Many of the other standards discussed so far focus on one specific aspect of payments security, but PCI DSS by its nature must address the entire payment process – all aspects that are involved in the storage, processing, and/or transmission of cardholder data.  The standard applies equally to Acquiring banks as it does corner shops, although the methods of validating compliance to the standard, of proving that a certain system or company is compliant, changes to reflect the reality of the size and risk posed by the organization under consideration.

However, even with differences in validation requirements, there is a recognition that many store operators are not necessarily in the business of payment security – they are in the business of conducting business, and accept payments to facilitate this business.  Payments is a means to an end for them, not an end of itself, and therefore the burden posed by securing payment systems can be seen as overly harsh in some contexts.  To address this there is an increasing focus on methods to secure card data from the point of acceptance to effectively shift the scope and burden of payment security from the merchant to the payment service provider.

End to End Security 

Usually this security for the card data is provided with encryption within the card acceptance device, and therefore these standards often represent an amalgam of all of the previous standards discussed in this paper.  Both ANSI and ISO standards bodies are working on standards to this effect, but at the time of writing the PCI Point to Point Encryption (P2PE) standard is the only standard released in this area.

The PCI P2PE essentially ‘wraps up’ the PCI standards into a single audit standard that allows for the validation of solutions that protect customer card data through encryption within the Point of Interaction.  Merchants using a P2PE approved solution for the acceptance of card present transactions essentially automatically meet all of the PCI DSS requirements for their environment, alleviating them of the burden and cost of on-going compliance and validation of that compliance.

End to end security is likely a vital part of securing payments into the future, and can greatly assist with the overall security posture of an organization when well implemented.

Future of Payment Standards 

In this year of 2014, the payment industry stands at a cross-roads.  Change in payments is being driven from many different directions – EMV adoption in the US is picking up, the security of software is increasingly under attack, mobile payments are presenting a challenge to the existing status quo, and methodologies for enhancing card data protection are under active development. Payment systems security is founded through the payment industry and standards setting bodies – both of which are not traditionally recognized for their rapid evolution and ability to adapt to change.

This is causing a disconnect as new actors in the payments market drive change at a pace that is hitherto unknown in this industry.  It is fair to expect more change within the payment industry within the next 5 years than we have seen over the last 30, and the question of how payment security will be addressed by these new systems is an open question.

With the growth of mobile Issuing (where a customer card may be managed within a customer’s mobile phone), and Host Card Emulation (where the details of a customer’s card may be stored within a ‘cloud’ based service) the concept of transactions where the card is not present is potentially becoming redundant.  If my mobile phone can connect to the Internet, and at the same time act as my customer card, why should eCommerce transactions be processed as ‘card not present’? If my card can always be considered ‘present’ for a transaction, and can provide cryptographic authentication verifying this fact, do I still care about the security of my card details?  To be fair, any such change will take a considerable time – even if run at ‘Internet speed’!  Therefore, standards such as PCI DSS remain important even in the face of a complete worldwide EMV deployment.

The computer industry has a long history of swinging from thick-to-thin-back-to- thick client methodologies, and it appears likely that we are witnessing such a change in payments at this point with an increase in ‘cloud’ based payment kernels and thin-client mobile systems.   Payment security standards must rapidly adapt to this changing environment, where the security of the software performing the payments is more important than the security of the hardware that is used to accept the card data, as vulnerabilities can be exploited remotely and instantly.  Fortunately, the industry seems to be recognizing this fact, and creating new standards to address this issue.

For those of us working and servicing the payment industry, we live in interesting times.

Share.

Comments are closed.