The EMV specifications, which cover all aspects of processing EMV “Chip and PIN” payments are freely available to download from the EMVCo website. However, EMVCo frequently issue specification bulletins that modify or clarify these requirements, but the published versions of the EMV specifications are only updated every few years to include these updates. Some of these bulletins are active immediately, while others are published many months before they will be valid, or are issued in a draft form to allow feedback prior to introducing a potentially controversial change.

Therefore in order to get an accurate picture of the current EMV requirements, to develop an EMV Level 2 Kernel that will be fully EMV compliant and approvable with the latest version of the EMVCo test cases, it is necessary to study all these EMVCo bulletins in addition to the current version of the EMV specifications. Even then, it is only a snapshot – in a few weeks the target may have moved again – and so keeping up-to-date becomes an arduous task!

In addition to the specification bulletins, EMVCo also publish bulletins on a number of other topics. The Terminal Type Approval Update bulletins describe changes to the EMVCo test cases required for EMV level 1 approval (which applies to card readers) and EMV Level 2 approval (which is required for all EMV Kernels), as well as related changes to the approval processes and fees charged by EMVCo. Similarly, the Card Type Approval bulletins relate to the approval of EMV-compliant cards. EMVCo also issue general updates and notices that cover EMVCo processes, future roadmaps and migration plans and other major EMVCo announcements.

To avoid the problems of constantly changing requirements and approval processes, many solution providers wishing to support EMV instead opt to license the use of a third party EMV Kernel, such as the CreditCall EMV kernels. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

EMVCo has taken the highly unusual step of publishing a formal response to a recent Cambridge University report claiming that ‘Chip and PIN is broken’, but unsurprisingly have played down the impact of this potential flaw.

The specific case highlighted by the report was restricted to stolen cards. Once a card issuer is informed of a theft they can decline all further transactions and can also send an issuer script command that will block the chip application on the card and prevent any further use. Therefore thieves may have only a small time window in which to commit any fraud with the card and, as the issue uncovered by Cambridge University only related to the use of EMV offline PIN, it would not be possible for them to obtain cash with the stolen card because ATM transactions always use online PIN for cardholder verification. This means that, whilst in this case there may still be the potential for goods to be fraudulently obtained from merchants, it offers significantly higher risks and less potential return than many other types of card fraud, and so is unlikely to be a significant threat.

Whilst the EMV specifications do actually define sufficient data elements and functions to enable cards, terminals and online hosts to perform the necessary analysis to detect most fraudulent attacks, it is still down to individual card issuers to ensure that their cards and host networks implement all these features. Many have proactively taken a lead on this by introducing more complex (and expensive) processing chips on cards that can support data authentication and PIN encryption, and by improving their backend systems to perform additional checks on transaction data. Obviously, though, to retain the public’s trust in the security of EMV it needs all industry players to maintain the highest standards, and even a small-scale breach can undermine consumer confidence – particularly when “Chip and PIN” technology has been marketed to the public as being totally secure.

In fact, one of the biggest problems with EMV is its versatility. In order to meet the multitude of requirements for individual markets, card schemes and card issuers, the EMV specifications allow cards to be configured in many different ways including which features a card may support and the way in which they format and deliver data to a payment terminal. As well as adding significant complexity to the EMV Level 2 Kernels used in payment terminals, and the associated testing regimes, the flexibility of the EMV specifications also increases the probability of interoperability issues arising whereby a card or terminal has implemented a feature in an unusual or non-standard way that may only be exposed when a particular combination of card and terminal are used. However, as well as the potential for interoperability issues, this flexibility can also lead to implementations that are completely compliant with all the specifications but yet are configured in such a way as to provide the potential for criminals to fraudulently exploit certain loopholes, such as that described in the Cambridge University report.

The report also suggests that EMV needs to be redesigned but, whilst it is true many people in the industry would like to see certain parts of the EMV specifications thrown away or heavily modified, a sense of realism is needed – with millions of EMV-compliant cards and payment devices already deployed worldwide, that is certainly not practical in the short-term. However, it may still be useful for the industry to collectively take a considered look at which EMV features are actually needed or used, and gradually migrate to a more common subset of the specifications which still meets all the industry security requirements but also removes unused, over-complex or insecure parts of the processing logic currently required in EMV Level 2 Kernels and cards. That should both improve interoperability and reduce the potential for cards being configured in an unsecure way.

Over the years, EMVCo has developed a process for the management of multiple operating systems (O/S), which allows an EMV Level 2 Kernel to be approved for use with multiple different O/S provided the change of O/S does not require re-compilation of the Kernel.

This process requires that the EMV Kernel is submitted for certification testing with each O/S, and a considerable number of the EMVCo test cases are repeated for each of the O/S, increasing the time and cost of the approval process. In contrast, Kernels written in Java are exempt from that process, as EMVCo considers that Java provides a fully platform-independent abstraction that can therefore be guaranteed to run identically on each O/S.

This leads to the strange situation that an EMV Level 2 Kernel, developed to run in Windows XP and Windows 7, is required to follow the EMVCo multi-O/S process if it uses the standard Windows API but does not need to do so if it uses Java – even though both solutions are running on the same combinations of O/S and are using standard interfaces!

This seems even stranger when considering that the parts of an EMV transaction that are more platform-dependent – such as the host connections, user interfaces and payment application – are all outside the scope of EMV level 2. Existing acquirer and card scheme processes already require additional integration testing to be performed prior to the final deployment of any EMV solution, and those should be sufficient to validate that any change of O/S has not had an adverse effect on the operation of that system.

Based on this knowledge, it would be easy to conclude that the existing requirements of the EMVCo multi-O/S process are arbitrary, unnecessary and unfair – maybe in the future EMVCo will re-assess this and adapt a more consistent approach?

Traditionally, most card payment terminals have used purpose-built hardware and software, running an embedded operating system for reasons of cost and performance. Over the years however the market has gradually evolved and many payment terminals now use general purpose platforms that support Java.

When developing EmvJ – the platform-independent EMV Level 2 Kernel that runs on any Java Virtual Machine – CreditCall wanted to harness the full potential of Java. Thus EmvJ is not only a very powerful and versatile kernel but has also been highly optimised for both performance and size, making it ideal for use on any payment device – whether it’s an ATM, an unattended kiosk or an EFT PoS (Point-of-Sale) terminal.

A major focus during the development of EmvJ was to provide an EMV Kernel that could easily be integrated into a card payment application. This enables EMV novices to quickly achieve an EMV-compliant transaction using EmvJ with only a few lines of code, and also provides advanced features to customise the kernel to support specific EMV Level 2 or card scheme-specific functionality appropriate to a particular solution.

The EmvJ Kernel was also designed to allow any PIN-pad and card reader components to be added without recompilation of the Kernel, by providing the drivers for those in separate Java packages. This can provide significant savings when undertaking the EMVCo Level 2 approval processes if multiple configurations and PIN Pads need to be supported. Drivers are already available for popular PIN Pads and EMV Level 1 approved card readers, including those from Ingenico, Verifone, Gemalto, Magtek and Sankyo.

CreditCall’s family of EMV Kernels are maintained to the very latest EMV Level 2 and industry standards, so you can be certain that they provide the best EMV solutions both now and in the future. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.