Transferring a bank card from an iPhone into a key fob

New trends show growing interest in projects related to the Internet of Things (IoT).

In this article, I am going to tell about the IoT platform we have created, I’ll cover ways to upload payment cards into wearable devices, while exploring the capabilities of the Core NFC iOS framework, and touching a potential fraudulent scheme that can be enforced using an NFC enabled smartphone.

The article can be of interest to product managers, technologists, iOS developers, QA engineers who are engaged in mobile payments, and ultimately anyone interested in broadening their horizons in fintech.

Hello Medium!

My name is Maxim. I have been doing industrial development since 2005. I have joined Cardsmobile (The Koshelek App developer) in 2013, and ever since 2015 I have been helping the company in developing new fintech services as a division head.

At Cardsmobile, we have launched a whole range of innovative products over these years. Among them are one of the world’s first smartphone-based digital-first bank cards capable of contactless payments (one year ahead of Apple Pay launch in Russia and long before the launch of Apple Card), the first transport card, first fan card, and the first campus card in a smartphone.

Last year, together with Mastercard, we launched the Koshelek Pay services — the world’s only bank card tokenization and contactless payment service that, unlike its counterparts, is OS or smartphone manufacturer agnostic. What it means, Koshelek Pay works on Huawei smartphones that lack Google services

Thanks

Nikolai Ashanin, who encouraged me to write this article and helped me during its preparation for publication.

Sasha Pryimak, who, under my supervision, carried out the research described in the article.

Also, many thanks for your participation and support:
Katya Turkina, Marina Ivanova, Anton Davydov, Lesha Ershov, Dasha Alekseenko, Andrey Rassokhin.

IoT platform

At the moment, my team and I are working on launching an Internet of Things platform that will complement and expand the existing experience of using the Koshelek Pay service and implement payment (as well as identification services) in things that we usually carry with us — the so-called wearable devices — or simply, wearables.

The Internet of Things is a concept of familiar physical objects equipped with technologies to interact with the external environment or with each other.

In this concept, familiar scenarios of using things are rebuilt through automation.

Examples of what one can call ‘wearable devices’ are smart watches, fitness bracelets, rings, key fobs.

Unlike earlier, when a person wore a ring to look nice or for symbolic reasons, now, in line with the concept of the Internet of Things, the ring can serve as a payment tool, or access control system (AC) passcard, or remote control for other smart devices, etc. This is how a familiar object can acquire new application scenarios, making our life more comfortable.

Smart things are now a global trend. This is evidenced by statistical data collected by various world agencies (see references at the end of the article).

In this article, I would like to give an example of our research in the development of an IoT platform in order to tell you about the tasks Cardsmobile elaborates on in the fintech direction, the problems we face and how we use the proven technologies of the card industry to create new products.

To begin with, let me briefly describe the technologies which our platform is based on in simple words. If you are interested in reading more about these technologies, there will be links at the end of the article.

1. The Secure Element is a full-fledged computer made in a solid silicon crystal about 5–20 square millimeters in size. It has its own operating system, input-output system, CPU, several crypto-processors for cryptographic operations, RAM and read-only memory. Secure Elements are used in the production of bank cards, SIM cards, and are also embedded in smartphones and other devices. Secure Element is almost impossible to hack and get data from there (hence the name).
   As with any computer, you can install applications in the Secure Element — the so-called ‘applets’. In this article, we will deal with a payment applet, thanks to the installation and personalization of which a wearable device with a secure element has a contactless payment service.
2. GlobalPlatform Card Specification — a standard that specifies Secure Element OS operation as a whole, it also specifies Secure Element content management scripts and protocols.
3. TSM (Trusted Service Manager) — a service for managing content in a Secure Element. It manages the lifecycle of applets on a given Secure Element, and personalizes those applets accordingly, for specific users.
4. Tokenization of payment cards. To turn a wearable device into a means of payment, payment brands leverage tokenization technology specified in the appropriate standard by EMVCo. Tokenization is the process of obtaining a token (a surrogate number) from the payment brand, associated with the account number of a real bank card. The token is unique per card per payment device form factor, which provides additional security when paying with a token.

Here are the main scenarios for the interaction of smartphone with the device itself, which we put into our platform (in all scenarios, the user controls the wearable device through the interface of the mobile application on the smartphone):

The first scenario is an interaction with active wearable devices. Active devices are wearables that have their own battery. In general, active wearables have their own OS, and a BLE module for communication with external entities like smartphones. The device vendor provides SDK and access keys for interacting with the device’s embedded Secure Element.

That is how all the smartwatches and fitness bracelets with the contactless payment function work like. This scenario is pretty simple and clear for us — we just take it and make it.

The second scenario is more interesting — as it involves communication with passive wearable devices. Wearable devices are called passive if they do not have their own battery. These devices are powered by an external magnetic field in which they must be placed. This can be the electromagnetic field of a contactless terminal reader or the NFC antenna of a smartphone. Thus, a contactless bank card can be safely called a passive wearable device.

The problem is that you need to upload your bank card into a passive wearable device from an application on your smartphone.

This scenario can be broken down in three variations, with respect to smartphone type and configuration:

1. Any smartphone without NFC
2. Android smartphone with NFC
3. iPhone with NFC

For the first type, we will use an external reader located in special personalization terminals. In short, the personalization terminal and the mobile application in the smartphone are connected to the same backend, which synchronizes both clients. The token is uploaded through the personalization terminal, and the user sees the result in the mobile application interface.

The implementation of the personalization terminal can vary: it can be the same user’s smartphone connected to an external smart card reader via BLE or USB, or it can be an autonomous external device (e.g. a laptop with a reader connected to it, with Internet access and control software installed).

For the second type (Android with NFC), the implementation is clear. In this case, the smartphone can be used as a terminal, which powers up the passive device via the NFC antenna and uploads a bank card token into it.

Now let me describe how we were elaborating on the third configuration (iPhone with NFC) in detail. For wearable devices, we used key fobs from ISBC, the vendor with whom we are launching the pilot project.

The research objective

The question is: can we enable The Koshelek App for iOS users to transfer their bank card into a wearable device by tapping it to the iPhone?

Outlined scenario:

1. The user submits payment card credentials in The Koshelek App for iOS.
2. The user touches the back of an iPhone with a wearable device.
3. The bank card data is uploaded off an iPhone and into the device.

In other words, our goal is to determine whether it is possible to upload a bank card into an external Secure Element chip by utilizing a regular iPhone and its NFC antenna, via the ISO / IEC 7816 protocol (T = CL).

Additional goals (nice to have):

1. Get ATR (Answer To Reset) of the chip without removing it away from the reader
2. Get the chip UID (Unique Identifier)

This data can be useful as it is often used to identify the chip in service provider systems and to diversify keys from the sensitive data of the chip’s applications.

What we have:

• iPhone 8 with iOS 13.5
• Test wearable device: ISBC keyfob with built-in JCOP 3 EMV P60 chip and preloaded applets from NXP: PPSE and an applet that implements the M/Chip Advance — Card Specification Payment and Data Storage v1.1;
• Keys from the Secure Element’s Issuer Security Domain.

Solution

First, let’s break down the main task to define the steps required to turn an ordinary keychain (well, almost) into a full-fledged means of payment:

1. Establishing a connection between the Secure Element chip of the device and the NFC module of the iPhone.
2. Installing Mastercard M/Chip Advance and PPSE applets on the chip.
3. Personalizing the applets.

Establishing a connection

Here we will focus on Core NFC framework features introduced in iOS 13. By the way, iOS 14 shows no significant changes that can affect this research so everything described hereafter is relevant for iOS 14 as well.

So, with iOS 13 it became possible not only to read data from NFC tags, as it was in iOS 12 (but not earlier than iOS 11 when interaction via NFC was only possible within Apple Pay), but also to write data and to communicate APDU commands to any Secure Element chip that complies with either of the standards:

• ISO/IEC 7816
• ISO/IEC 14443
• ISO/IEC 15693
• MIFARE
• FeliCa

To do this, two new classes have been added to Core NFC: NFCNDEFReaderSession and NFCTagReaderSession.

The first is used to interact with NDEF tags, and the second is for everything else.

In our case, there is a Secure Element chip that supports the GlobalPlatform Card Specification 2.2.1 and the ISO/IEC 7816 standard, which means we will go with the second class.

The documentation says what you need to do (besides writing the code, of course) to start communicating with the ISO 7816 chip:

• Provide a non-empty string for the NFCReaderUsageDescription key in your app’s info.plist file.
• Add the list of the application identifiers supported in your app to the
  com.apple.developer.nfc.readersession.iso7816.select-identifiers information property list key.

But below there is an interesting restriction:

Important Core NFC doesn’t support payment-related Application IDs.

This is exactly what we’d like to check upon, to learn what exactly it means.

So we add a string value such as «Allow NFC connection» for the key NFCReaderUsageDescription in the info.plist file. It also works fine with any other string of your choice.

[Here in the left column, it is not the key itself, but its description, as the XCode hides the formal names]

Now, to enable interaction with the chip as an ISO/IEC 7816 device, then in the value of the com.apple.developer.nfc.readersession .iso7816.select-identifiers key we specify the list of IDs of all applets (Application Identifier or AID), with which the application will interact.

An important note here is that these identifiers are not just a random set of characters.
These are hexadecimal (hex) strings that contain information about the application to which they are assigned.

AIDs can be 5 to 16 bytes long (two characters per line = one byte). They consist of two parts, the first identifies the application provider (for Mastercard it is “A000000004”), the second says what kind of a product it is from a given provider (for a product named Mastercard it is “1010”, and for Maestro it is “3060”).

In addition, sometimes it is required to put additional information in the AID, for example, if there are two identical applications from the same provider on the chip, but for different banks. There is what support for Long AID (or Extended AID) is there for. As long as the length of the AID does not exceed 16 bytes, you can write anything to it. For example, we took Mastercard AID and at the end added “TEST” to it and the result is as follows: “A0000000041010BB5445535401”.

The only AID that stands out from the list is “325041592E5359532E444446303101”. In fact, this is a plain-text string “2PAY.SYS.DDF01”, only in hex format. This is the AID PPSE, which is not a payment applet per se. It only contains the environment data required by payment applications.

Applet installation

To install applets on a chip, you need a secure connection (Secure Channel Protocol or SCP); we did it behind the scenes using a regular PC / SC reader and the Cardsmobile TSM platform.

Even if you don’t have any of these, you can still try installing your own applet on a chip — only on a virtual one.

You will need an IDE of your choice that supports JCOP Shell and JavaCard emulator, for example this one.

Create an empty project, specify the desired AID (for example, 0000000000) and run it.

Then execute commands, step-by-step:

1. /card
Get ATR, send SELECT without identifier so that Card Manager is selected

2. auth
Create a secure connection to the emulator (otherwise nothing can be installed).

3. ls (optional)
With this command you can see what applications are installed on your device emulator.

4. install [ packageAID ] [ appletAID ] [ instanceAID ]
Install the applet:

packageAID — package identifier Module), e.g. “0000000000”
appletAID — applet identifier (Load File), e.g. “000000000000”
instanceAID — identifier that will be assigned to your applet after installation, e.g. “A0000000041010”;

5. ls
Check if your applet appears in the list of installed applications:

Applet personalization

Personalizing an applet is easy; all you need is to upload the required payment data into it. To do this, select the applet with the SELECT command by its AID, establish a secure connection and send it the STORE DATA command with the data inside.

Now going back to the list of AIDs in the info.plist file — why do you need it, and how Core NFC chooses the right applet for interaction?

This is how it goes, roughly:

1. The program goes through the list from top to bottom;
2. For each AID, it generates and sends a SELECT command;
3. The AID of the first applet that replied “9000” (the status of a successful response, here is a list of all possible responses) is written in the initialSelectedAID field of an object of the NFCISO7816Tag type, which is put into the array of detected chips.

Next, you can select any such object from the whole range of objects, and use the sendCommand method to send APDU commands to the selected applet.

Now let’s get back to this restriction:

Core NFC doesn’t support payment-related Application IDs.

That is, Core NFC does not support payment AIDs, namely production AIDs which the payment terminals work with.

Of course, you can add a payment AID to the info.plist list, but Core NFC will ignore it and will not send SELECT (by the way, here is a list of all used AIDs). This is how Apple protects its Apple Pay technology, preventing third-party developers from accessing any of the iPhone’s payment functions (and everything related to it).

Workarounds

The first idea that comes to mind: is it possible to add to info.plist — not the payment applet AID, but the AID Card Manager (Card Manager is a group of services within the chip operating system that implement card management,administration and security), and then manually send it the SELECT command with the AID of the desired applet?

At this point we stumble upon the first pitfall: Core NFC does not allow sending SELECT command containing AID that is not registered in info.plist.

Okay, we added A0000000041010, but another setback has been awaiting us: Core NFC does not allow sending a SELECT command containing a payment AID, regardless of whether it is in info.plist or not.

Let’s see how the ID restriction works.

Suppose we have specified the following AIDs in info.plist:

1. A000000001510000 — GlobalPlatform Card Manager AID

2. 325041592E5359532E444446303101 — Proximity Payment System Environment (PPSE)

3. A0000000041010 — Mastercard Credit / Debit (Global)

4. A00000000401 — Mastercard PayPass

5. A00000000410101213 — Mastercard Credit

6. A00000000410101215 — Mastercard Credit

7.A00000000410101214 — Invented payment AID

8. A00000000410101216 — Invented payment AID

9.A0000000041010121F — Invented payment AID

10. A0000000041010BB5445535401 — Invented payment Long AID

11. A0000000041010BB5445535405 — Invented payment Long AID

12. A000000004101FBB5445535401 — Invented non-payment AID

13. A000000004101F1213 — Invented non-payment AID

14. A00000000F1010 — Invented non-payment AID

15. A0000000040F — Invented non-payment AID

We installed 14 payment applets with different AIDs (items 2–11 are payment AIDs), and tried to send Card Manager SELECT commands with each of these AIDs.

Numbers 12–15 responded

It turns out that the restriction is imposed on a certain AID prefix, the presence of which determines whether it is a payment identifier or not.

Too bad, but it seems like this method is not going to work.

The second personalization method provided by GlobalPlatform is the INSTALL [for personalization] command.

INSTALL command is sent to the Card Manager, containing the AID of the applet that needs to be personalized.

Now STORE DATA commands can be sent to the Card Manager, which in turn will forward them to the target application.

Nevertheless, there is another limitation here. In order for the applet to support this personalization method, it must implement the interface org.globalplatform.Application.

In response to the INSTALL [for personalization] command with Mastercard Credit / Debit ( Global ) AID, which was assigned to the M / Chip Advance applet from NXP, Card Manager returned error “6985” (Conditions of use not satisfied),

which means that we wanted to check if it implements the Application interface.

To do this, we wrote a dummy application that implements this interface. As expected, it returned “9000” in response to INSTALL [for personalization].

But just as soon as Application was removed from the interfaces implemented by the application, it began to return “6985” to this command, as in the case with the M/Chip Advance applet.

Therefore, the problem is precisely that the NXP application does not have the right interface implemented for this type of personalization. This method also is not an option.

Additional tasks

1. Obtaining the UID of the Chip

This can be done easily.
At the start of an NFC session, the module looks for Secure Element chips as well as the AIDs of applets of which are registered in info.plist, and puts them into an array. Now you can get any of them from there, and if its type is NFCISO7816Tag, then it should have an identifier field, which contains the UID of the chip.

2. Obtaining the ATR of the chip

As for the ATR, it seems like Core NFC is unable to get one, due to no special tool for this is implemented in the framework, thus you cannot get ATR using APDU commands.

Conclusion

So what’s the bottom line?

1. We’ve learned how to work with Secure Element chips of the ISO / IEC 7816 standard (including getting their UIDs), by leveraging the new capabilities offered by the Core NFC framework.
2. We’ve learned of the restrictions that Apple has placed on its technology.
3. We found out that using the iPhone, currently there is no way to personalize payment applets that do not implement the Application interface.
4. We took a note that with any other AID everything works perfectly — this knowledge will be useful to us in the future, when working with non-financial services.

Answering the question posed at the beginning, whether we can give The Koshelek App user the opportunity to transfer their bank cards into the key ring by tapping it to iPhone — no, this is not possible yet.

As part of the task, we settled on using an external BLE reader to transfer a bank card token from an iPhone into a passive wearable device.

Hopefully, in the future Apple will expand the capabilities of NFC Core to solve this and a range of other tokenization and payment tasks in third-party applications. However, recent news signals that this is unlikely to happen in the near future.

Side effects

In the course of the work, a potential fraud scheme was born, which cannot be reproduced using Apple smartphones, but is quite possible to implement through an Android smartphone with NFC support and Host Card Emulation technology.

In short — suppose the following:

• Smartphone A is used as a terminal — that is, it will connect to bank cards and interact with their payment applets.
• Smartphone B is used as a means of payment (at the checkout it will look like a regular payment with a smartphone).

Using this scheme, an attack chain can be created: bank card — smartphone A — smartphone B — payment terminal, namely:

1. Smartphone A is applied to a bank card.
2. Smartphone B is applied to the payment terminal.
3. Smartphone B emulates a bank card by sending APDU commands sent by the terminal to Smartphone A.
4. Smartphone A transmits these commands to the bank card applied, transmitting its responses to smartphone B.
5. Smartphone B transmits the received responses to the terminal.
6. The payment has been made.

That is, a potential fraudster can put a smartphone in your pocket and trigger a payment transaction. Be careful!

To avoid becoming a victim of such a fraudulent scheme, you can transfer bank cards to your smartphone and not carry plastic cards with you.

As a conclusion

I tried to write this article in a simple language, not going too deeply into the terminology of the subject area.I described one of the innovative projects we are working on, the subject area and a little research on the new features of the iOS Core NFC framework. Any feedback is welcome: questions, reviews, comments, additions, and constructive criticism.

References

If you are interested in the topic described in the article, below are several links for a more detailed exploration:

1. The concept of EMV Payment Tokenization
2. IoT market analysis articles:

• article 1
• article 2