Hello from Berlin. My name is Maxim. I’m an iOS Engineer at N26. This is a mobile bank across Europe and the US. At N26 I’m working on user identity verification. And my presentation today is all about this topic.
First we discuss the problem of user identity verification and why this is so critical for the business. Then we consider existing solutions for this problem and explore NFC as a possible solution. Here we take a look at NFC from the iOS perspective and learn some NFC use cases regarding user identity verification. So what is user identification? When you’re a service like a mobile bank or car sharing service or some booking service… …you need to verify the identity of your customers. You may ask them to take a selfie, or to take pictures of their identity documents or enter some personal data manually.
All the provided user data is going through some verification process… …and finally your service knows if it’s a good person or some fraudster. And working on these problems daily you can see that user identification process is not perfect. The business lost a lot of potential customers even before they start to use the service.
And the problem basically comes from two sides. From one side, it’s the people itself. When people need to enter some data manually, it’s totally normal to make some typos or mistakes. Or even when you provide the best instructions how to take photos, from which documents or which data to enter… …there is always a misunderstanding from users.
From the other side there is a bunch of technical issues. For example the snapshots of the documents are often in bad quality. They could be too blurred or too dark or too bright. Or a bad connection may cause the uploading of big image files to fail. The combination of all these problems have a big impact on the user growth funnel.
And in the best scenario the user can retry to go through the verification process… …or contact the customer support which is always additional cost for the business. Or in the worst scenario the user just gives up to use the service and the business losses users and money. The problem basically comes from a different perspective. For example, we see OCR (Optical Character Recognition Technology)… …could replace manual data entry, or machine learning techniques could provide some hints on how to make correct photos. But these technologies are still error prone and not 100% accurate. And moreover, if you not want to use native frameworks but some 3rd party services… …it brings in additional size for the mobile app, which is usually very painful.
From the other side there’s a bunch of technical and a bunch of legal techniques which can improve the situation. For example, if some data is not necessary anymore for verification in some country… …you can remove the step from the process and simplify the process for the user. But as you can see, none of the solutions could remove the human factor and get rid of technical limitation at the same time except for the one solution that came to the iOS world recently, which is NFC.
NFC is an abbreviation for Near Field Communication. This is a wireless technology that allows NFC enabled devices to exchange data between each other in close proximity. And Apple devices support NFC starting from the iPhone 7. A bit of technical background on NFC… All the standards and protocols and technologies of NFC are classified into five so-called tech types from one to five. And the difference between them basically is in their technical background, like speed, security, memory and so on. And there is also NDEF as a common language between the different tag types.
From the huge variety of NFC examples, I think the two most popular for us as an iOS community… …is Apple Pay and the new fancy clips feature of iOS 14. But I want to show you another example which is relevant to the problem we discuss today. Most of the modern banking documents like passports, ID cards, driving licenses and so on… …have an embedded NFC chips that contain some user data which you can read using your iPhone.
So first you need to provide some input data. We will discuss this a bit later. Then you need to provide… then you need to bring your device close to the card and you can start scanning. And by the way, all the data in this demo besides the photo is fake. I slightly changed the UI just for privacy reasons. And then after some time when the reading is finished, you can see the data from the card on your device.
And you can see that the photo is also here in good quality. That’s why the reading took a bit more time because of the big image file. So from first look NFC looks like a promising solution for you to solve user identification problems. Let’s go further. All the NFC API’s I use are inside the Core NFC framework. This is the system framework that Apple introduced in iOS 11. At that time Core NFC could read some simple NFC tags and only in foreground mode.
It supported only simple tags, kind of a replacement for QR codes… …because they just contain a kind of text message and that’s all that you can read from these tags. And despite these tags could be based on different tag types, we still can read all of them because they have a common NDEF format. And then later in 2019, as you remember, Apple brought a lot of updates to the SDK and Core NFC with a huge enhancement as well. So now you can not only read that simple tag, but also write data to the tags from your iPhone. And also some iPhone models support background reading of these tags. But what is really cool is the support for reading of some more complex tag types.
For example, MIFARE chips used in a contactless smart cards and proximity cards. A proximity card means a card that could be read from close proximately. like up to 10 centimeters. And these tags are basically used in services like access cards or micro payment services and so on.
The FeliCa chips are produced by Sony and they are mainly used in Asia. These tags types have a wider range of functionality and that is why this kind of tag type is more expensive than some other than other tag types. These tag types used in an application like public transport tickets, electronic money, electronic ID cards, and so on.
The ISO 153693 standard is for vicinity cards and these vicinity cards can be read from a greater distance than proximity cards. For example 1 to 1.5 meters distance could be enough to read data from this card. And these tag types are popular in use cases such as when you have a big distance between reader device and tag… …for example large storages or public libraries, when you have a bigger distance from reader device to the card or the chips. But the one change in iOS 14 regarding Core NFC besides some syntax changes is about this standard.
So now you can do even more operations in iOS 14 with this tag type. But to our interest today is the ISO 7816 standard because this standard is related to electronic identity cards. It means starting from iOS 13 we can read tags from passports and identity cards. Using Core NFC is pretty straightforward and we will go through the key steps of reading ISO 7816 standard, but if you want to read some other tag types, it’s slightly different… …but basically the idea is the same to how to read ISO 7816 standard. So first you need to provide capabilities in your project for NFC. It’s in the same way as for some other Apple features.
Then you need to update your privacy description in info.plist. And then you need to add the application identifiers also to your info.plist file… …and the application identifiers is kind of… every NFC use case has their own identifier.
For example if you want to read biometric passports then we need to provide this identifier to our project. In the same way if you want add some more use cases to the project you can add more identifiers to the list. Using the API is also pretty straightforward. First we need to create a session and there’s two types of sessions in Core NFC… …one for simple NFC tags, another one for reading more complex tag types. As you wanna read ISO 7816 standard tags we need to select NFCTagReaderSession. Here we need to specify polling options and we need to select this polling option… …because this one is compatible with the ISO 7816 standard.
And this is a delegate method. It’s also pretty straightforward. When we are setting it up we can start our session and here we bring our device close to the card. Here we have a 60 seconds timeframe to detect NFC tags and perform all necessary operations with them. And when the tag is successfully detected, this delegate method is handled and here we need to connect our session to the detected tag.
And if we take a look on the layers of the implementation you can see that Core NFC, as a system framework… …provides us a channel to communicate with the NFC tag… …but our custom use cases like reading data or some other use cases should be done on our side. And for that we have this API in Core NFC. We need to create a so-called APDU command, Application Protocol Data Unit Command. It provides some instructions and parameters for this command. Send this command to the tag and wait for a response from the tag.
And when the tag responds with an APDU response we do the next steps like maybe send some other command to the tag. And the structure of APDU commands is described in a ISO 7816 standard. But all the sequences of commands or instructions and parameters of these commands are described in Doc 9303. This doc is the documentation provided by the International Civil Aviation Organization… …and this organization is responsible for the documents, basically everything about travel documents. And the main use case we want to use is that we want to perform reading data from the cards.
But before we start to read the data from the card, we need to get access for reading the data. And all the data on the card is obviously sensitive because it’s personal data, but some data could be considered as less sensitive. For example the document number, name, and date of birth and so on. And some other data could be considered as more sensitive for example fingerprints. And to get access to both data types, we need to provide different access control for both data types. So first basic access control.
And as we saw in the demo before we start to read the data, we need to provide some input data… …and this input data basically it’s data… it’s the document number, date of birth and date of expiration of document… …and these three pieces of data form the password. And with some symmetric cryptography the reading device can establish a secure message with the the card and start to read the data from the card. Today this mechanism is basically almost replaced with Password Authenticated Connection Establishment. This mechanism is based on asymmetric cryptography.
It doesn’t depend on the length of the password and it means that instead of this long three pieces of data… …we can use the card access number which is also displayed on the card. And today if you want to implement your solution for reading data from documents… …you need to support both of these mechanisms because some older documents could support only basic access control. Most of the documents today are compatible with both mechanisms… …but new documents for example issued last year or this year could support only Passport Authenticated Connection Establishment.
And talking about Extended Access Control. You can see that here we need to…. …both sides should authenticate each other. So chip should authenticate reader device or terminal and terminal should authenticate the chip. So chip authentication is based on Key-agreement protocol and we will discuss this mechanism a bit later. And terminal authentication is based on terminal certificate and to… This certificate should be requested from the government and the… If your service wants to implement Extend Access Control to get access to more sensitive data from the document… …you need to request this certificate from the government. The signing chain of the certificate looks like this.
So eventually the terminal certificate is signed by the Country Verifying Certificate Authority… …and the private key of the certificate is stored on the card. And the reading device should provide its terminal certificate to the card. The card can verify if it’s a valid certificate, with it’s private key and then the card sends a challenge to the terminal.
And if the terminal is able to sign this challenge with the correct terminal certificate… …the card can be sure that it is exactly this terminal, as it only knows exactly this correct certificate. And this is how both types of access control look like. They are both described in this Doc 9303. But if the document is not compliant with this documentation or compliant just partially… …then it’s not necessarily the case to read the data with both access controls.
For example Germany identity documents like the German ID cards or the new German residence permits issued since the last year… …they require extended access control even for less sensitive data. So it means that if you want to read even less sensitive data from this document types… …the basic access control is not enough to do this. Regarding the documents from The Netherlands, as I didn’t work with them personally… …but as far as I know, all passports, identity cards and drink licenses in the Netherlands… …are compatible with Doc 9303 so you can set up both… You can start both ways of access control to read less sensitive data from these document types. And when we set up access to the card, we can start to read the data. All the data on the card stored in files that are called data groups. There are 16 defined data groups in Doc 9303.
And the first two data groups are mandatory. For documents to be compatible with Doc 9303, this document must have these two data groups on the card. The first group contains the data which is stored in machine readable zone. So data displayed on the card like name, document number, country, nationality, date of birth and so on.
Second data group contains face image which is also displayed on the card… …and the other data groups are optional, they can be present or not on the card… …depending on the document version and issuing country and the document type. But most probably you want not just read the data from the card, but also be sure that the data on the card is official… …signed by the government. And also want to be sure that card is an original one and not not a copy.
And let’s take a look on both of these use cases. So first authentication… Besides the data groups we can also read a so-called security object document file from the card. This file contains hashes of all data groups and this file is signed by the official certificate. The signing chain of this file is similar to the signing chain of terminal certificate which we just discussed.
So eventually Security Object Document is signed by the Country Signing Certificate Authority… …and the public key of this certificate is available publicly. For example on the website of the International Civil Aviation Organization you can download this public certificate… …and using this certificate the reading device can perform passive authentication for Security Object Document… …and check the data integrity in this file and on the card. And for example if this file is not signed by the official certificate or if some data was changed, it means the card was tempered… …then the passive authentication will fail and the terminal can determine that something is wrong with the data integrity on this card.
The idea behind clone detection is that the private key of the card is stored in some special secret memory on the card… …and this memory is not available for reading or cloning. And it means that if someone decides to clone the card, the private key can’t be the same as the original one. So to detect cloning of the card you just need to detect if the private key on the card is the original one or not. For clone detection there are two common mechanisms. One of them is active authentication, another one is chip authentication… …which we already know from extended access control. But first I want to talk about active authentication.
So the active authentication mechanism is similar to the mechanism of terminal authentication, but in a reverse way. Here the terminal needs to authenticate the card. For that the terminal reads data group 15 on the card. And if that data group exists on the card, that means the card supports active authentication mechanism… …then the terminal can read the public key for active authentication from the data group. Then the terminal sends some random challenge to the card and if the card is able to sign this challenge with it’s private key… …then the terminal can be sure that the private key on the card is the original one… …and therefore the card is the original one as well. The chip authentication is as well based on Key-agreement protocol and for that again, if this card support this mechanism… …then data group 14 contains some security options and security features for this mechanism… …and the terminal reads the security options from this data group and establishes a public/private key pair… …and establishes secure messaging with the card.
And if secure messaging is established correctly and communication is set up with the card… …then the terminal can be sure that the chip contains the original certificate and the card is the original as well. And as we know these data groups are optional it means some data groups could be present or not be present on some cards. And that means that this mechanism is not supported by some document types. But basically at least one of these or even both of these data groups have been placed on the card. Most of the documents support at least one of these mechanisms.
And coming back to the verification process we can see that NFC can improve this process a lot. So now user doesn’t need to enter data manually because we can read this data from the NFC chip on the card. And also you don’t need to take pictures of identity documents… …because now verification can be greatly improved with the security mechanism which we just discussed. And you probably not need to ask your user for selfie because as we know we also can extract the photo… …from the document in good quality. And that means that we can improve this part… NFC can improve this part of the verification as well.
And then all of these things should be implemented on our side… …and most probably, if you want to do it in production, most probably you want to do it on your backend side… …because the frontend side is not secure and it can be easily compromised. And most probably in production you will just read data from the card with your device… …and just send this data to the backend. And on the backend you will do this verification magic on backend side… …and just maybe return some response to the device, like if verification succeeded or failed. Also this is an open source project… …which I highly recommend you to check. Here you can see how to use Core NFC… …to scan identity documents.
How to implement such mechanisms as basic access control, passive authentication, active authentication… …how to read some data groups from the card. So all these things currently implemented in this repository. So I recommend you to check this. To conclude you can see that identity verification process is not perfect. There are some problems and NFC can be a solution for these problems. In iOS all the work with NFC is based on the system Core NFC framework.
But custom use cases as reading document data or verifying authenticity of documents or detecting cloning… ….should be implemented on our side. For that we can use Doc 9303 because it contains all the details of these processes and how to implement them. And also the open source project can be used to deep dive in this topic. And that’s all from my side. Thank you very much for your attention. I will be very happy to answer any of your questions.
And for any discussion regarding Core NFC and so on… …please approach me on Twitter. Thank you! Looking forward to your questions. Hey, thank you for attention and hope you enjoyed the presentation. If you have any questions please type them in YouTube chat or the Slack channel and so far I can see this… Let’s see. Yeah we have some questions and the first question is from Bart.
If a person gets a…. If a person gets a new passport is the public key the same again? As you can block the same person as before. Guess the question regarding the… I guess the question is regarding the country signing certificate authority public key.
And as far as I understand this public key is updated from time to time… …and if you need to verify the passport for this document, then you need to get new keys from time to time. A question from Mario: is there a way to prevent the reader to read the document? Probably yes. Some document types can have this opportunity to block reading of the document. Maybe some countries support this mechanism. Basically I think it’s by default open. It’s like everybody can read and also it depends on the basic access control.
Let’s say if it’s basic access control, then to read the document… …you need to provide some some piece of data to be able to read document. Then from this from this side I think it depends on the the mechanism. If basic access control is available, then the reader can use mechanism for this document. I hope this answers your question. If you need more clarification please let you know.
Let’s check the chat from YouTube… So there is a comment: I have no use case for checking identity documents… …but I still like this talk just to know how it works. Thanks Rens! And yeah, exactly this… I would say not very popular topic maybe like SwiftUI or Combine and so on… …but here is a good opportunity for us as a community to know about this about this opportunity… and a if if there’s something or a use case in your project then it’s good to know. Good to know about this opportunity. So thank you for your comments guys. Question from Marius: So you need to you need approval from the government… …to even be able to reach these documents? Again, it’s depends on which data you want to read. If you want to read like …. the first two data groups like…
…basic data in the photo on the document you don’t need… ..don’t need any approval from the government. But there are some exceptions like as I mentioned in presentation… …German identity documents, German ID cards, German driving license permits… Especially German driving license permits issued since last year… …they don’t comply with Doc 9303. They comply partially and so they don’t support reading some data with mechanisms like basic access control… …and they required some additional authentication to read the documents… …so it means that for these document types, as far as I know… …you need some additional certificate from the government. But basically you can read any document. Most of the documents, by default, can be read just with this basic access control. Question from David: do you use this method in your on-boarding at N26? Yeah, good question and I would love to share more information, but unfortunately no. It’s private and so on. Yeah, we’re working on on this direction about NFC verification, but unfortunately I can’t share it today.
A lot of knowledge about how we used it and how we’re going to use it. Questions from Bart: you did this using only the Apple provided Core NFC? Yeah… Native framework of Core NFC provides the opportunity to set up the channel with the chip on the card… …and all other things like reading data, doing this basic access control or extended access control… …should be done on your side. For that you need to use Core NFC API but it should be on your side. But basically yes, it’s totally enough to use Core NFC API. So native API is enough to get a connection with the chip on the card. Thank you Bart for repeating the questions, I guess I answered both of the questions… Question from Mario: any link telling which country supports what with their documents, in the EU at least? I would say no, there’s not like a general map where you can see like this country support this and this country doesn’t support it.
But you know there is no commonplace where you can see which document support what and which not… …but you need to go to some country specific authorities… …and check what they support regarding NFC and regarding passports and identity documents. But I would say this couple of good reports from 3rd party providers who provide this feature… …and they provide some kind of information regarding the countries and the which document is supported in this country. So I guess I can show you some links later in the channel for these reports so you can see. You can check these reports and I would say it’s pretty useful to understand this and what is popular in the world.
Which kind of documents in which country can support with this opportunity. Now I can’t see any more questions… Just in case you watch my video recording later and you would like to… …you can ask more questions here in Slack or reach me on Twitter… ..or put some comments on the YouTube video and I can answer these questions later as well. So last call for questions… OK, no more questions I think… Thank you very much again for your attention and your questions. And yeah… For any more questions, please approach me. Thank you for your time.
Have a nice evening. Bye.. bye..
2020-12-27