A website dedicated to contactless payment systems

By maintaining the specifications of the banking card applications, EMVCo has a huge effect on banking card business. Visa and MasterCard developed  their own implementations (VSDC and M/Chip respectively) based on EMV specifications. They are almost identical, they have a few configuration changes. Contactless applications payWave and PayPass are also based on EMV specifications, however they were developed before EMVCo released a contactless specification.

It seems EMVCo is ahead of Visa and MasterCard this time, they released requirements for contactless payments by handsets. There are already implementations of Visa and MasterCard’s applications on handsets, but all of them have been dropped before launch -after pilot phase.

Basically, a mobile application is a user interface for accessing the EMV compliant payment application running on the secure element of the handset. Secure element can reside on the NFC controller of the handset or on the SIM card.

What EMVCo requires for these applications are;

• Application should have a soft/hard key for easy access. If it’s a soft key, it must be accessible from the main/home screen.
• Application should inform the handset/card holder when a contactless transaction is in place.
• Application should be secured by a password and it should be configurable to enable/disable the application.
• There should be an indication of contactless capability, just like the bluetooth icon.
• Handset shall provide a mechanism to notify the application when it is powered off.

It is a good effort to draw the boundaries of the environment and will lead the players in the industry to have a single user experience. It seems we will see more mobile payment applications on the market -hopefully in the commercial level rather than pilots.

Original document can be found here.

Not so long, about 10 years ago, if someone had told you that you could process a payment transaction with your watch, you’d probably laugh. But things have changed in an enormous speed and since last few years, this definitely possible and there are people actually doing this now.

This has been possible by a company -Laks, whose vision is beyond most of the people in both card payments and watch industry. Laks is a Vienna based company developing very cool watches that have a dual interface chip slot and the watch has an antenna inside the watch. The antenna plugs into a specific type of SIM sized dual interface chip produced specifically to fit in this environment. There is the possibility of running many applications on the chip. Actually there is the possibility of requesting any kind of chip in this form, which means that sky is the limit for implementing a chip application inside a watch. Laks also has native mifare chip embedded into the watch. Although I’ve never asked, I am sure that they can fit any kind of chip inside a watch.

Watches come with the antenna, while the dual interface chips do not necessarily. If so, personalization process must be processed while the chip is in the watch, which is something hard to do when personalizing huge volumes.

In Turkey, Garanti Bank launched a product based on Laks watches a few years ago. It was a little bit early, however it was still a very innovative product. In Turkey, there were efforts to develop a payment product based on Laks’ watches, which some of them had already passed the proof of concept phase, unfortunately they were never launched.

Maybe, the commercialization did not happen due to the fact that watch is a personal thing (like a mobile phone in the NFC case) and a payment product bundled in a personal stuff might not sound good to people. But I am sure there will be some contactless projects based on watches and Laks will definitely have a big role in this picture. There are more interesting watches other than having a contactless capability in Laks’ web site, worth to visit.

Contactless cards are penetrating into more and more market segments day by day. The three most common use cases of contactless cards are clearly ticketing, payment and access control. Now let’s skip the access control and compare the ticketing and payment use cases.

Work Flows

Functional requirements of a contactless ticketing application are generally store a balance, contract, expire date and a log space. Typical work flow of a contactless ticketing transaction is as follows:

• Identify the card in the field
• Authenticate the card and the ticketing terminal
• Read the contract from the card
• Read the previous transaction logs -if necessary
• Compute the fare
• Debit the card with the fare
• Write the transaction log

When it comes to payment, the work flow of a contactless EMV payment is as follows:

• Identify the card in the field
• Authenticate the card and the terminal
• Debit the card
• Store the transaction log

As you can see, the main difference of the payment and the ticketing work flow is the fare calculation based on some variables like contract type of the card and the previous transactions performed and stored in the application. This is something EMV is still uncapable of. Both Visa and MasterCard are already working on ticketing extensions of payWave and PayPass, however they will still have many barriers ahead even if the specification are completed and first samples are out for testing.

Authentication and cryptography

EMV relies on RSA and Triple DES, while ticketing applications use mainly DES variants and AES. Contactless EMV transactions are quite secure with DDA (Dynamic Data Authentication) and it is a perfect solution for an interoperable environment of different banks.

Almost all ticketing systems are proprietary and each transport operator or provider has its own application. Every system has its own infrastructure and interoperability between ticketing systems are quite rare. So each system has its own authentication alghoritm and of course key types and lengths.

Main differences

EMV is designed for securing the transaction between card and terminal, terminal and host systems, host system and the card. It’s the underlying standard of Visa, MasterCard and JCB. Each organization has its own application of EMV but  essentially they are mostly identical. Contactless ticketing application depend heavily on the chip platform and operating system they are using. Every transport authority, system integrator or solution provider has its own ticketing application. There are efforts in Europe to standardize the ticketing applications but they are not mature enough yet. So basically ticketing is proprietary for now.

Some time in the near future, payment and ticketing is supposed to meet on the NFC platform, but it seems it’s still a long way there.

Visa has been working for some time on mobile payment space with DeviceFidelity for porting the Visa contactless applications into the MicroSD environment. We’ve already heard many news that Apple is also quite interested on the same subject and now finally that seems to be a reality, according to a post on Engadget.

Apple has been submitting patent application for the next generation iPhone on NFC objects. However, I strongly believe that the secure element will be under the control of Apple, not the carrier or the user -if an iPhone with NFC support is to be released. So Visa is heading on to its own path. What I understand from the news is that a PayWave application running on a MicroSD card will be attached to iPhone through a special casing. It seems we will see the application available on iTunes in the long run. And it’s name is In2Pay.

Although there’s not much detail on the project in general, I think that it will be specific to US, which will essentially switch the transaction interface from magnetic stripe to contactless for payment, not more. Of course a transaction history kind of details must be available in the application. The aplication will be secured by password

It’s a good move from Visa to provide a solution to mobile payment space over the iPhone platform, but I believe it will take quite a time to make the application commercially available. If it comes quickly, it will definitely be the killer application for me to buy an iPhone!

DeviceFidelity’s white paper also indicates that other mobile platforms are supported. More importantly, In2Pay v2 will have OTA support for personalization and multiple bank accounts will be available. v2 will have the full NFC environment from couponing to payment.

I strongly recommend to download the white paper from DeviceFidelity (requires a very short registration)

After the infamous Mifare hack, there’s been a lot of talk on Mifare Classic chips. Some governments even issued laws for banning Mifare Classic in the future for using some specific purposes.

So what did NXP do? Actually NXP was already aware of the upcoming issues and was working on next generation of Mifare. There has been two outputs of this study, as fas as I know. One of them is Mifare Plus and the other is Mifare EV1, which is to be announced soon.

What is Mifare Plus and how does it overcome the security issue? More importantly, how does it help to migrate the current installation of devices working with Mifare Classic only? I think NXP did a great job to respond to the security and migration questions with Mifare Plus.

Mifare Plus is actually the update of Crypto1 to AES while the memory organization of the chip remaining the same. Mifare Plus comes with 4 security levels, each of them having a different authentication levels.

• Level 0 is the personalization level.
• Level 1 is Mifare Classic level, where the chip acts exactly as Mifare Classic. This level helps start issuing more secure cards while the reader infrastructure is still the same.
• Level 2 is only valid for Mifare Plus X cards, I will come to that later.
• And Level 3 is where good old Crypto1 ends its journey and AES is being used for authentication.

There are 2 types of Mifare Plus chips; S and X. With Mifare Plus S, you can only utilize the AES alghoritm and MAC’ing while X comes with much more features like encryption of exchanged data and proximity check. X is an export controlled product. With Mifare Plus X, there is the option of using both Crypto1 and AES at the Security Level 2.

Another big update of Mifare Plus is the 7 bytes unique id. Since the 4 byte unique ids are almost at the end of its limit, Mifare Plus chips has 7 bytes unique ids. Mifare Plus also has a very important implementation; now you can read and write multiple blocks instead of one at a time. This will dramatically improve the trransaction speed, if implemented correctly. The last of the updates is that Mifare Plus supports random uid, which responds to again some security issues.

I think that Mifare Plus is a very solid product for migrating from Mifare Classic to a more secure platform with minimal infrastructure updates. If you need more features that this you can go for Mifare DesFire which provides much more flexibility in terms of file integrity and flexibility.