Clever Geek Handbook

How we loaded a bank card from an iPhone into a keychain



Every year more and more companies are showing interest in projects related to the Internet of Things ( IoT ). 



In this article, I will talk about the IoT platform we have created, how to load bank cards into wearable devices, explore the capabilities of the Core NFC iOS framework, and the possible fraud scheme using smartphones with NFC.



The article can be useful for product managers, technologists, iOS developers, QA engineers who are engaged in mobile payments, as well as anyone interested in fintech technology to expand their horizons.



Hello, Habr!



My name is Maxim. I have been doing industrial development since 2005. I have been working in Wallet since 2013, and since 2015 I have been helping the company's business develop new fintech services as a head of a division.



At Wallet, our team has launched many innovative products. This is one of the world's first fully virtual bank cards in a smartphone with the possibility of contactless payment (a year before the launch of Apple Pay in Russia and long before the launch of Apple Card), and the first transport card , and the first fan card , and the first campus card in a smartphone. ...



Last year, together with Mastercard, we launched the Wallet Pay serviceIs the only service in the world that, unlike its counterparts, works regardless of the smartphone manufacturer or operating system. For example, Pay Wallet works on Huawei smartphones that lack Google services.



Acknowledgments



Kolya Ashanin , who motivated me to write the 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, Anton Davydov, Lesha Ershov, Dasha Alekseenko.



IoT platform



At the moment, my team and I are working on launching an Internet of Things platform that can complement and expand the existing experience of using the Pay service and introduce payment (and other identification services) into those things that we usually carry with us - the so-called wearable devices. 



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 use cases for things are rebuilt through automation.



An example of wearable devices is smart watches, fitness bracelets, rings, key fobs.



If earlier a person wore a ring because of beauty or symbolism, now, in the concept of the Internet of Things, the ring serves as a payment instrument, an access control pass, remote control for other smart devices, etc. Thus, new convenient use cases appear for the familiar thing.



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



In this article, I would like to use the example of our research in the development of an IoT platform to tell you what tasks the fintech direction of the Wallet application works with, what problems we face, and how we use proven technologies of the card industry to create new products.



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



  1. , Secure Element — , 5-20 . , -, , - , . , SIM-, . ( ).



    , — . , .
  2. GlobalPlatform Card Specification — , .
  3. TSM  (Trusted Service Manager) — . .
  4. EMV — ( ), . , - , , .


Here are the main scenarios for the interaction of a 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 interaction with active wearable devices. Active devices are wearable devices that have their own battery (for example, a battery). As a rule, the thing has its own operating system and there is a BLE module for communication with a smartphone. The device manufacturer provides SDK and access keys for interacting with the security element. 



This is how all smartwatches and fitness bracelets with contactless payment function work. Everything is simple and clear - we take it and do it. 



The second scenario is more interestingIs interaction with passive wearable devices. Wearable devices are called passive devices that 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. So, contactless bank cards can be safely called passive wearable devices. 



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



We (conditionally) break this scenario according to the type of smartphones:



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


For the first type, we will use an external reader, which is 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 loaded through the personalization terminal, and the user sees the result in the mobile application interface.



The implementation of the personalization terminal can be different: 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 (a full-fledged computer with a reader connected to it, Internet access and control software) ...



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



In our study, I will describe in detail how we worked on the third type of smartphones (iPhones with NFC). As wearable devices, we used key fobs from ISBC , the partner with whom we are launching the pilot.



Purpose of the study



Can we enable the iOS Wallet user to load their bank card into a wearable device by attaching it to the iPhone?



I.e:



  1. The user in the application "Wallet" enters the data of his bank card
  2. User leans a wearable device against the back of an iPhone
  3. The bank card is loaded into the wearable device


Accordingly, the technical task is to determine whether it is possible to load a bank card into an external security element (Secure Element) using a regular iPhone and its NFC antenna, via the ISO / IEC 7816 protocol (T = CL). 



Additional tasks:



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


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



What we have:



  • iPhone 8 with iOS 13.5
  • Test wearable device - ISBC keyfob with an embedded JCOP 3 EMV P60 chip and loaded applets from NXP :

    PPSE and an applet that implements the M / Chip Advance - Card Specification Payment and Data Storage v1.1;
  • keys from the Issuer Security Domain chip.


Decision



At the beginning, we will decompose the main task, namely, we will determine the steps necessary to turn a completely ordinary keychain (well, almost) into a full-fledged means of payment:



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


Establishing a connection



It is here that we will talk about the features of the Core NFC framework added in iOS 13.

By the way, in iOS 14 no significant changes have happened regarding the subject of the article, so everything described is relevant for her.



So, in the thirteenth version of the apple OS, it became possible not only to read data from NFC tags, as it was in iOS 12 (but not earlier than iOS 11, before it, interaction via NFC was only possible within Apple Pay), but also to write them, and also communicate in the APDU command language with any chip that complies with one of the following standards:





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 used for everything else , respectively.



In our case, this is a chip that supports the GlobalPlatform Card Specification 2.2.1 and the ISO / IEC 7816 standard , which means we will use the second class.



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





But below there is such an interesting limitation: We just want to "touch" it, having learned what exactly it means. Add a line, for example "Allow NFC connection" for the NFCReaderUsageDescription key in the info.plist file. It also works with any other value of this key. 



Important

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













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



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





It is worth clarifying here that these identifiers are not just a random set of characters.

These are hexadecimal strings containing 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 product this provider is (for a product named “Mastercard” it is “1010”, and, for example, 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. For this there is support for Long AID (or Extended AID). 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, the result: "A0000000041010BB5445535401".



The only AID that is out of the list is "325041592E5359532E444446303101".

In fact, this is the usual (only in hex format), as they say, plain-text string "2PAY.SYS.DDF01". This is the AID PPSE, which is not a payment applet per se. It only contains the environment data required by payment applications.



Installing applets



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 .



However, even if you don't have any of these, you can still try installing your own applet on a chip - only a virtual one.



You will need any IDE with JCOP Shell support and JavaCard emulator, for example this one .



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



Then we understand the steps:



  1. / card

    Get ATR, send SELECT without ID so that Card Manager is selected;





  2. auth

    , ;



  3. ls ()

    , /;





  4. install [packageAID] [appletAID] [instanceAID]

    :



    packageAID — (Module), , «0000000000»

    appletAID — (Load File), , «000000000000»

    instanceAID — , , , «A0000000041010»;





  5. ls

    , :







In fact, personalizing an applet is very simple; all that is required is to load 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 the selected applet the STORE DATA commands with the data inside.



Now let's return to the list of AIDs in the info.plist file - why is it needed, and how exactly does Core NFC choose which applet to interact with?



It looks like this:



  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


@available(iOS 13.0, *)

public protocol NFCISO7816Tag : NFCNDEFTag, __NFCTag {

   /**

    * @property initialSelectedAID The Hex string of the application identifier (DF name) selected by the reader when the tag is discovered.

    *                              This will match one of the entries in the «com.apple.developer.nfc.readersession.iso7816.select-identifiers»

    *                              in the Info.plist.

    */

   @available(iOS 13.0, *)

   var initialSelectedAID: String { get }


Further, you can select any such object from the array, and use the sendCommand method to send APDU commands to the selected applet.



Now let's talk about this limitation:

  

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


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



Of course, you can add a payment AID to the info.plist list, but Core NFC will ignore it and will not send a SELECT for it (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 thing that comes to mind is whether it is possible to add to info.plist not the AID of the payment applet, but the AID Card Manager (Card Manager is a group of services inside the operating system of the chip that manage the card, which are responsible for administration and security), so that then manually send him the SELECT command with the AID of the desired applet?



Here we stumbled upon the first pitfall - Core NFC does not allow sending a SELECT command containing an AID that is not registered in info.plist .



Okay, we added A0000000041010, but this is also a failure - 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.



In info.plist we have specified the following AIDs: 



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                    	-   AID                 
8. A00000000410101216                    	-   AID 
9. A0000000041010121F                    	-   AID 
10. A0000000041010BB5445535401 	        -   Long AID
11. A0000000041010BB5445535405 	        -   Long AID
12. A000000004101FBB5445535401 	        -    AID                
13. A000000004101F1213                    	-    AID                 
14. A00000000F1010                             	-    AID
15. A0000000040F                                     -    AID


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



Numbers 12-15 answered .  



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.



It's a pity, but this method is no longer valid.



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





It is sent to the Card Manager and contains the AID of the applet that needs to be personalized.



Then you can send STORE DATA commands to Card Manager, which will forward them to the target application.



But there is one limitation. For an applet to support this kind of personalization, it must implement the org.globalplatform.Application interface .



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



which means you need to check if it implements whether it is the Application interface .



To do this, we wrote a simple dummy application that implements this interface. As expected, it answered "9000" on INSTALL [for personalization].



But when Application was removed from the interfaces implemented by the application, it began to respond to this command "6985", as is the case with the M / Chip Advance applet.



Therefore, the problem is precisely that the NXP application does not implement the interface necessary for this type of personalization. This method also disappears.



Additional tasks



  1. Obtaining the UID of the chip

    This can be done in a very simple way.

    At the start of an NFC session, the module looks for chips, the AIDs of applets of which are registered in info.plist, and adds them to an array.

    After that, you can get any of them from there, and if its type is NFCISO7816Tag , then it has an identifier field, which contains the UID of the chip. 



    /**
  * @discussion The hardware UID of the tag.
*/
var identifier: Data { get }


  2. Obtaining an ATR chip

    But it seems that Core NFC cannot receive ATR , because there are no separate tools for this in the framework, and you cannot get ATR using APDU commands .


conclusions



What's in the bottom line?



  1. ISO/IEC 7816 ( UID), Core NFC;
  2. , Apple ;
  3. , , iPhone, , Application — ;
  4. , AID — .


Answering the question posed at the beginning, can we give the Wallet user the opportunity to load their bank card into the key fob by attaching it to the iPhone - no, this is not yet possible.



As part of the task, we settled on using an external BLE reader to load 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 accomplish 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.



A side effect of the study



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



The bottom line is: 



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


Using this scheme, you can create a chain bank card - smartphone - smartphone - payment terminal, namely:



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


That is, potentially a fraudster can put a smartphone to your pocket and pay for the purchase. Be careful!



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



Instead of a conclusion



I tried to write the article in a simple language, not delving too deeply into the terminology of the subject area. In it, 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, constructive criticism.



useful links



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



  1. Book of I. M. Goldovsky " Bank Microprocessor Cards "

  2. Concept EMV Payment Tokenisation

  3. Articles with analysis of the IoT market: 



More articles:


All Articles