Therefore, when our customers are looking to obtain EMV Level 2 certification for a solution, I’m often asked what support the EMVCo level 2 certification process provides for allowing the solution to be certified when some features are only supported in certain markets.

In recent years EMVCo have refined the EMV Level 2 approval process, required for all EMV Kernels, to take into account the need for different configurations to support those requirements. When submitting a Kernel for approval, a baseline is defined which covers the typical set of features that the device will support, and the entire set of EMV Level 2 test cases will be applied to this configuration. However, the solution provider can also choose to submit additional configurations for approval, and each of these additional configurations will only be subjected to a subset of the EMV Level 2 test cases, which can significantly reduce the time and cost of having to approve multiple different configurations.

In addition, EMVCo have also defined the concepts of minor changes and hidden features. These processes allow support for certain EMV features to be changed or disabled without having to re-approve the EMV Kernel or even submit it for an additional configuration, and so if it is possible to utilise these processes then this can provide even greater benefits.

This process is only possible if the EMV Level 2 Kernel being used can be configured to support each of these changes without the need to make a major change to the Kernel (such as recompiling the Kernel code). Therefore, to reduce the cost of EMV Level 2 approvals and meet the needs of multiple markets and operating environments, it is very advantageous to use a highly configurable kernel, such as the CreditCall EMV Kernels. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

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.

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.

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?

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.

In addition to the test case updates to validate the implementations of all the EMV specification update bulletins that have been published during the past year, test cases are now also provided for American Express. This is the first EMVCo Level 2 test plan released since they joined MasterCard, Visa and JCB as EMVCo’s fourth member last year.

With over 100,000 users of the Kernel in Europe alone, and with customers in most regions of the world where Chip and PIN is mandated, CreditCall expects to be certifying new integration of its EmvX, EmvJ and EMV.LIB as soon as March 2010.

Link to EmvCo Bulletins

Metric "Aura" EMV equipped Pay-and-Display machine

Although much of the publicity surrounding EMV “Chip and PIN” migration has related to its use in retail outlets, another market sector that has benefitted from EMV migration is Unattended Payment Terminals (UPT).

Unattended payments, where a customer uses an unsupervised terminal to pay for goods or services such as parking and vending machines or self-service kiosks, have traditionally been processed using cash. Where card payment has been supported this has been achieved by using the data from the magnetic stripe on a customer’s card, with no cardholder verification. This means that such machines are an obvious target for fraudsters trying to use stolen and cloned cards and, as there are no attendants to monitor these environments, it has been extremely difficult to crackdown on this illegal activity. This has therefore limited the growth of unattended card payments.

However, the advent of EMV cards means that secure PIN entry can now be used to verify the cardholder, and advances in communications technology means that it is also possible to quickly and safely authorise transactions with the card issuer even when there is no fixed communications infrastructure on site.

Together, these developments have fuelled a large growth in a number of unattended environments, including car parking, transport ticketing, automated supermarket lanes and other self-service kiosks vending higher value goods, as vendors can now have confidence that every transaction is genuine and they will always receive their payment.

This is just one example of the benefits that EMV migration can bring. The CreditCall EMV Kernels provide a simple but powerful way to add EMV Level 2 capability to payment devices. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

When there are multiple payment applications present on an EMV card, or the card configuration requires cardholder confirmation, payment terminals will display the list of applications to the cardholder to allow them to select an EMV application to use for the transaction.

EMV cards will often include an ‘application preferred name’, which is the name of the card application in the cardholder’s local language. Although this is the preferred name to display to the cardholder, it will not always be possible to do so as the name may use an ‘issuer code table’ that is not supported by the terminal. For example,  a terminal in Europe may not contain a display font that allows Arabic characters to be displayed.

Therefore, normally all EMV card applications will contain an ‘application label’ which contains only characters in the common character set that all EMV-capable terminals are required to support, which should ensure that there will always be a name that can be displayed to the cardholder.

Unfortunately, although the presence of the application label on the EMV card is mandatory when using the PSE directory method during application selection, it was only defined as optional when selecting the application using the list of Applications method. Therefore  it has never been possible to guarantee the presence of the application label on a chip card – until now! EMVCo have finally resolved this by issuing Specification Update Bulletin No. 71 that now makes the application label mandatory on all new EMV-compliant cards. This will finally mean that EMV Level 2 Kernels used by payment terminal vendors will always have a name to display during application selection, and should no longer need to implement default name processing.

The CreditCall EMV kernels are compliant with all the latest industry requirements, and provide a simple but powerful way to add EMV Level 2 compliance to payment devices. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

Whenever an EMV transaction is performed, the terminal’s EMV Level 2 Kernel processes the CVM list in order, until it finds a CVM that it supports and can process. In the event that no supported CVM is found or an error occurs during CVM processing (e.g. the PIN-Pad was malfunctioning), the EMV kernel will flag this in the Terminal Verification Results, which may cause the transaction to be declined or sent online for authorisation by the card issuer.

The CVM that EMV currently supports are Online PIN (required in certain countries for all transactions, and also for all ATM cash withdrawals), Offline PIN verified by the chip card (required in certain countries for all payment transactions), signature (for attended payment terminals in some countries), or a combination of both PIN and signature if additional verification is required.

Also, in some environments it is permissible to use no CVM for low-value transactions or for terminals that do not support any of the CVM on the cards.

CreditCall’s EMV Kernels support every EMV-defined CVM, and provide a simple yet powerful way to add EMV level 2 to payment devices. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

It is of course possible to update an existing EMV solution to meet the latest specifications, but the sheer volume of specification changes means that this is a significant task. A better approach therefore, is to migrate to an EMV Kernel that is compliant with the latest EMV standards, such as the CreditCall EMV Kernels. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

Found this Interesting, but struggling with the terminology? Why not consult the helpful Glossary of Terms at http://www.emvx.co.uk/glossary.aspx EMV de-mystified!