 Good afternoon, everyone. Thanks for attending this talk. I'm Samuel. I work for Intel. And I'm going to talk about mobile payments. So first of all, a little background on why I want to talk about that. I'm the NFC maintainer in the kernel. And one mode of NFC is called card emulation. And this is the last mode that we enabled. And card emulation is actually about payment and transactions. So this is the last remaining mode to support to be able to claim that NFC support in the kernel is full and complete. So I got dragged into this stuff. And I'm going to talk about it now. So what are we going to talk about? So first of all, what's a mobile payment? Just to make sure we're talking about the same thing. There's several kinds of mobile payments. So I'm not going to talk about all of them, but just a specific one. How does it work? So what does it mean to do a mobile payment? How the transaction flows and so on. We're going to look at the existing bits in Linux. Can we do that already with Linux? And if not, what's missing? And finally, well, obviously if I'm talking about this, we cannot do it fully. So we have a proposal to do that completely. So what's a mobile payment? Well, it's a money transaction or simply put a transaction from a mobile device. It's simple as that. There are several kinds of mobile payments. You have SMS payments, direct billing to your operator, and contactless payments. So today I want to focus on contactless payments. SMS payments, direct billing. If you have a real telephony stack on your device, then you can do that already. So not really interesting to talk about. So what's a contactless payment? Contactless payment is basically a payment where NFC is the carrier between your mobile device and a point of sale. Like in this picture where this guy's paying for his coffee with his phone. It's not only about payments. It's also about coupons, loyalty tickets, actually events, tickets, and that kind of stuff. But also, some car manufacturers are starting to talk about having keyless cars or rental cars. So you could rent your car on the internet, and your phone becomes your key. And you don't have to go through all the, you don't have to go through the desk and everything. Same thing for the hotel, where even in this hotel, for example, the keys are RFID already. So you could simply use your phone and not do the checking, for example, do everything online. Contactless payment is actually already existed. I mean, it's a widely deployed technology. In a lot of transit network, for example, in Europe, I don't know about the US, but I hope it's also the case. But in a lot of transit network in Europe, you actually can already pay with some RFID card. And that's a contactless payment right there. So you have the point of sale. In that case, it's the metro reader. And you have your card, which is a smart card, with a little storage that contains the credentials and credits. And what you do is you just put your card in front of the reader. Magnetic fields go up, or go through, actually, and your storage removes some credit from the card. And this is contactless payment right there. So what we want is to be able to use our mobile device, our phone, to do all of this. Not only pay for your metro, but also for your rental car, for anything that accepts contactless payments. And to do that, we use the special mode of NFC, which is called card emulation. So we want to use NFC card emulation to do contactless payments. To be relevant and to be usable, it has to be at least as secure as contactless payment as it is today with an actual card. And the advantage of this, obviously, is to have everything in one device. So your mobile phone, your credit card device, your transit card, and everything else. So one device, a lot of services. So this is what we want, but this is what card issuers want. So EMDs, your card, MasterCard, Visa, all those guys work together, they actually allow you to do contactless payments under some very strict requirements. So to do that, you have your platform of the tamper resistant. It has to have security domain and very secure storage. And it has to be FIPS and CC certified crypto engines on the platform. So this is basically what the card issuer require from the mobile device OEMs and from the network operators. So you won't be able to even certify a mobile platform if you don't fulfill all those requirements. And this is not exactly what you find on your typical mobile SoC. So the Qualcomm, NVIDIA, SoC that you find in your mobile phone are not capable of doing that. Actually, not capable of fulfilling those requirements. I'm not saying they're relevant. I'm not saying they make sense. But this is what the EMDs will require from you. So their answer to those requirements are called secure elements. So secure element is basically a security, a secure platform that fulfill the requirements that I just listed. It's typically a very small platform that stores and run a few applications. Your SIM card is a secure element. But you also find other secure elements on a mobile phone. So all the mobile phones that have an NFC controller do have what we call an embedded secure element. So when you put an NFC controller on your mobile phone, the NFC controller manufacturer is smart enough to add a secure element on there that you could use for transaction and payments. It's really crucial because, as I'm saying here, a secure element is basically a space to rent for the secure element manufacturer. So whoever owns the secure element actually owns the transaction and allows you to put an application there. Because this is the application that runs on the secure element and on the host that's going to do the transaction. So as the secure element owner, if you say, I don't know, the Macy's application, I don't want it to be on my secure element, then Macy is out of your ecosystem. And this is typically Visa or MasterCard that decide on this stuff in agreement with the secure element owner. So it's really the key of the mobile payment world that it's currently happening. So who owns the secure element and what it does with it? And as long as you can say who can actually leave on your secure element, you can obviously take care of the transaction. So this is why it's crucial. So we know that now the transaction happens from the secure element. So how does all this work? So POS is the point of sale. So it's basically the transaction reader. So it's several steps. First of all, the point of sale sees the device and recognizes it as a card. So your device must run the NFC card emulation mode to be able to be seen as a smart card. So from the point of sale point of view, it doesn't make a difference if you're a mobile phone or an actual card. It doesn't see the difference, it's the same thing. Once it sees it and selects you as a smart card, it will actually select a specific application on the secure element. So if your point of sale is distributed by MasterCard, it will select the MasterCard application to simplify it, to put it simply. Once the application is selected, it actually runs on the secure element and it will start talking with the reader with the point of sale and talk to ISO 7816 APDUs. And this is where the transaction happens. So once the application is selected and running, everything is exactly like you would do with an actual contact card. So when you put your credit card on a credit card reader, once the point of sale has selected the secure element on the application on the secure element, this is exactly the same thing. So credentials are exchanged and then the point of sale get in touch with the bank and the car issuer to make sure that you have the credits and the transaction happens this way. Once the transaction is done, the secure element will typically try to modify the host if needed. If it decides that it needs to notify it that the transaction is done or that it needs more input from the user. So the host will be notified and you have a counter part to the application running on the secure element that's running on the host that will pop up and tell you, hey, the transaction is done or I need a PIN code or whatever. Whatever the application of the secure element decides to notify the host. So in that configuration, the NFC controller is really nothing but a pass through. So it gives an antenna to the secure element application and after that, from the host point of view, you don't really see what's happening. You just get a notification, as I said, if the application of the secure element decides to notify you. Yes, a certify API, you mean? Is that the question? No, it's, there's a Similiance API that typically EMVs will ask you to implement. But then you have stuff like Google Wallet, for example, that doesn't implement this. And they have their own stuff and they don't really care about EMVs. Although they have deals with them but they're so big that they can afford not implementing this API. But yes, there is an API. It's not mandatory but it's strongly required by the EMVs. So to summarize what I just said and so you have the host with the payment application running on the host, that's not the application that does the transaction. The one that does the transaction is provision on the SIM card. So first of all, the payment application will typically enable a secure element because this is another issue. Now you have a SIM card and you have the NFC manufacturer that gives you an embedded secure element. So you have two secure elements and typically the OEMs will provision the embedded secure element with some payment application and then the mobile operators will also provision the SIM secure element with other application. So your payment application running on the host needs to know which secure element it has to enable because many of those NFC controller actually don't run really well with two secure elements enabled. So the first thing you do is selecting which secure element you want to enable. After that you actually have a physical link between the NFC controller and the SIM card. I'm taking the SIM card here as an example. You have a dedicated line between the SIM card and the NFC controller. So you need to have a SIM card that's NFC enabled that has this specific line actually running. And after that the point of sale tries to detect you. So it sends some 14, 4, 3 frames that you would typically, oops, reply to. And after that you basically have an NFC link established between your point of sale and the NFC controller. At that point the host stops seeing, I mean it knows that it has an NFC controller but any of the NFC traffic is just, you don't see it anymore. It just goes through the NFC link through the SIM and backward. So the point of sale selects a specific application on the SIM card and this is the application that's gonna do the transaction. Like I said, when we reach that point, it's exactly like a contact card. So the point of sale will talk through NFC as it would talk over actual physical lines. It talks to the application on the SIM card, credentials are exchanged, and the next thing that the point of sale does is talking to your bank asking for, hey, does this guy have enough credit? If it wants to, in practice, busy business actually do batching, so they don't talk to your bank until the end of the day and they only accept small amount of money if you have to pay for, I don't know. I think the typical limit is $50. So if you have to pay more than $50, it would talk to your bank, otherwise it will try to avoid it and just ask at the end of the day or the week. Once the transaction is done, the secure limit application may notify you of the transaction termination and success or failure and the payment is done. So what do we need in Linux to actually enable all of this? As you probably understand now, most of the payment actually happen on the secure limit, so what we really need is a secure limit manager. So you may think that maybe only enable a secure limit is enough, once the secure limit is enabled then the transaction goes without any of your help, but there are more requirements than that, so the EMVs will require you to be able to talk to the secure limit, and not specifically to the payment application, but for example, so they have other meta applications that manages all the outlets installed there, all the payment application and they want you to be able from the host to know which application are installed and maybe even talk to some of this payment application to for example, ask what's your credit on your bus ticket. So the EMVs, these are mastercard people, will require you to do that, so you have to implement something from the host to be able to send those APDUs and request whatever the payment application on the host will request. They also require you to implement access control, so there is an access control list in the secure limit that you're supposed to fetch when you detect the secure limit that will tell you which application is allowed to send which APDUs to which application on the secure limit, so it's basically a whitelist of application and APDUs. On the host you also must be able to route notifications, so you get notification of transactions and you should be able to push that to the right application on the host. And finally, this is the API that you were talking about. It's not a mandatory requirement, but you probably want to implement that. So it's defined by the CMLI answer and it's a set of APIs that payment application on the host are typically expecting to find on your platform and they will implement their payment application on the host based on those APIs defined by the CMLI. So do we have that on Linux? Well, we have something called SIG for Android while SIG stands for secure limit evaluation kit. It's open source, it's Apache 2 license, but it's really specifically designed for Android and it's implemented by a TSM, which is TSMs are companies that are allowed to provision secure limits. So this company actually implement SIG for Android to show you how you would do that on Android. So it's really an evaluation kit more than anything else and specifically designed for Android. It has very limited hardware support, so you can run that on the Android emulator and you can run that on fairly old Android platform, some of the old Nexus. What we're seeing is some manufacturers are actually using SIG for Android as their payment framework. So I think Sony Ericsson used that for implemented their wallets. It's very seam centric, so it doesn't support the embedded secure limit really well and it doesn't support the SDIO secure limit really well neither. It has only Java APIs, so not really nice. And as I said, this is not your Google wallets, so the Google wallet doesn't use SIG for Android. It has its own implementation. It doesn't even implement the SIEM Alliance APIs. So what we propose for implementing a payment, a mobile payment framework on Linux is first of all extending the NFC netting API. As you saw from the previous diagrams, the only piece of hardware that actually knows where the secure limit are is the NFC controller. So it's the only piece of hardware that can tell you if there is a SIEM card that contains a secure limit and if there is an embedded secure limit on the system. So we extended the NFC netting API to send you a notification of available secure limit on the system. And we added a couple, well one netting command to enable or disable those secure limit. And the last thing that we defined but haven't implemented yet is of the NFC event. So when the transaction is done or when the secure limit, the application of secure limit needs you to provide some input. It sends some specific NFC events and you're supposed to broadcast or unicast that to a specific application and we have to forward that through NFC as well, to netlink as well. We obviously need a secure limit digmint to manage the secure limit, implement the access control that I was talking about and do all the APUs implementations. And finally the SIEM Alliance API. We want to implement that through debuts for application to, for payment application to use that as a SIEM Alliance compatible API. So this is what, this is how it looks like. We have the secure limit daemon there. It's plugin based so you can talk to your favorite telephone stack or you can talk to your favorite NFC stack. Obviously on Linux there is basically only one which is nerd and so the secure limit daemon abstracts the APUs for you. So abstracts the APUs handling for you. So if you want to send a specific APUs, your specific secure limit, you will go through either the telephone stack or the NFC stack without you having to bother about it. You don't know if the secure limit is on the NFC controller or if it's SIEM based, you just need to send this APU. And the debuts API you will see will be, we hope it will be used for implementing payment application on the host on top of it. So as I said, the Netting API is used for secure limit discovery and enablement. It's already upstream. It's even implemented for the PN544 which is currently the most popular mobile NFC controller. It's found on still most of the Android devices. Android switched to a Broadcom chipset recently but it's still not really widespread. The Netting API also allows you to send the APUs. It's implemented on a specific branch on NFCnext. It's not upstream yet. Those APUs are typically a few bytes and the payment application for a specific payment will send at least at most a couple of them. It's really low traffic and very small tables. And finally the NFC events for transaction termination inputs providing. Those are, they're defined but they're not implemented yet. So we don't broadcast them yet. This is something we're gonna do later. The secure limit demon. So it does all the APUs at fraction and we currently only support NFC and telephony. We don't do the ASSD because the secure, the SD consortium define as a specification for doing NFC secure elements on an SD card. This is something that I personally never seen. I don't know of any hardware that does that. It's basically an SD card with a couple of additional lines to be able to talk with your NFC controller. So from the NFC controller point of view it's really seen as yet another secure limit. We don't support that. If someone has this kind of hardware, I'm happy to buy it. From the secure limit demon we also implement the access control list which is specified by the global platform which is a consortium of network operators, ENVs, so these are master card people are there as well that are trying to define a set of specification for secure limit. So this specification tells you that the enforcement of this access control is entirely done on the host. So the secure limit doesn't do any enforcement of this access control. So if your platform is not certified you basically can send any kind of APUs to any kind of application on the secure limit. It will probably fail because typically the payload on the APUs are encrypted but still if you don't have this access control implemented on the host basically you can talk to any application on the secure limit and send in any payload you want. There's a fallback mechanism because this is a fairly recent specification that's based on basically a SIM file system. So there are some files on the SIM file system that will give you this access control list as well but we have not implemented yet. And NFC events are not supported yet. And finally the DeBus API, we want it to be compatible with the Simo INS API because as I said also it's not required by ENVs. It's typically the API that payment application companies will expect to find a new host. So if they have an Android application that's running on top of SICK for Android for example, it will be a lot easier for them to port that into a Linux based system. So the DeBus API lists allows you to see all the secure elements and enable, disable them. It gives you access to the basic channel. So there's one specific IO channel on the SIM card that's called the basic channel, where you do all the management of the SIM card. And it allows you to open a logical channel linked to a specific application ID. So if you want to talk to a specific application on the SIM card, you have to open a logical channel, link it to a specific, to this specific application and then you can talk to your application. Most of the SIM card support that and this is a way for them to do multitasking. So with several logical channels, they can run several applications at the same time. Well, not really at the same time obviously, but yeah, that's what they do for multitasking. And it gives you logical channel IO access. And the secure element demon will be released with Nerd. So Nerd is the NFC demon and it will be part of the Nerd releases. It's not yet there, but it's gonna be there quite soon. So the next step, I've been talking about the physical secure element, so the secure element that you find on the SIM card and on the NFC controller. But there are two new kinds of secure elements that are making their way to reality. The first one is the software secure element. So even though they're less secure than actual physical secure elements, a lot of people are starting to implement secure element through trusted execution environment on the host. So the ARM trust zone, for example, and X86 also has many TEs implementation should allow you to implement software secure element, host-based secure element that will, I mean, EMVs will tell you that the security is not as high as an actual secure element on the SIM card, for example, but a lot of companies are finding it's way enough to implement stuff like ticketing, loyalty coupons, and that kind of stuff. If you wanna do real payment and you probably don't want to put your master card on the software secure element right now, and EMVs will actually forbid you to do that. But for other use cases, it's perfectly enough. There are other secure elements, cloud-based secure elements. So there are several solutions for that. The Google wallet is almost there. It's almost a cloud-based secure element. So we want to be able to implement that through the secure element demand and see cloud-based secure element as just regular secure elements and talk to them the same way. We have to implement the access control for that mechanism. This is mandatory for satisfying your platform through EMVs and NFC events again. And finally, we want to be able to provide hooks for provisioning the embedded secure element. So one of the problem with mobile payment right now is that someone has to write into your SIM card to add the payment application. And that's someone need to be trusted, really, really trusted. And there are a few companies called TSNs that do that for mobile operators and EMVs. So we call them TSN, Trusted Security Managers. And those are the one that are provisioning your secure element with the right application. So when you, for example, install the Google wallet on your Android device, there's a trusted, there's a TSN that is contacted and that opens a secure channel between your SIM card and their servers and provision your SIM card without you actually seeing anything happening. But for the embedded secure, I mean, for the SIM card, it all goes through the telephony stack and everything is there. It already exists for doing that. But for the embedded secure element, we need to provide hooks. And those hookups are specified by the global platform and the SIM alliance that will allow TSN to also provision your embedded secure element through the NFC stack and the NFC controller. So that's missing right now. And I'm done. So if you have any questions, the EMVs. So the EMVs will tell you if it's secure or not. And, well, you can do that, but I mean, this is basically what the software secure elements are. They're almost that, but you can do that and you can say, hey, this is my secure element. But then to be able to have any TSN provisioning your secure element, you need to go through EMV certification. And EMV certification will look at your setup at your platform and they will just tell you this is not something we want. So basically you have a secure element, but it's empty. An existing what? Yes, the security is in the SIM card. It's in the secure element. So the payment credentials are in the SIM card. And according to EMVs, this is something you cannot get easily. This is what makes it secure. Yeah, yes, it's, their biggest problem is about, yeah, crypto engines and how it's certified and also storage. So where you store the credential material and is a X86 or an ARM platform secure enough? According to them, it's not. So they don't want to put any of their payment application right now on a whole space secure element. It will obviously cut the dependency on TSMs and the telephony stack and network operators that you could just provision it through any networking connection. But yeah, we're not there yet. But EMVs are right now accepting software secure elements. So secure elements running on the host on trusted execution environments for low security use cases. So ticketing, yeah, loyalty coupons, that kind of stuff. They're fine with that but not with actual payment. Yes, ARM trust zone is the specified software secure element but EMVs still don't want to do payment through ARM trust zone. They're fine with doing most of everything else, transaction, but not actual payment. Say that again, sorry. They can move it to anything. I mean, as long as they consider it secure enough, so yeah, if your watch does have an NFC controller with an embedded secure element, they just fine with it, it's no problem because it's certified by them. So people will provision it. Actually, with embedded secure element, it's pre-provisioned because typically you don't have the network connection to provision it properly and the TSM wouldn't want to do that without going through the telephone attack. So it's pre-provisioned. Google does that, for example. The Google wallet, you get your embedded secure element pre-provisioned with the Google wallet master card virtual application already there. So when you buy a mobile phone, if the OEMs agreed with Google to use the Google wallet, you already have your embedded secure element pre-provisioned with the right application. So you could do exactly the same with a watch or anything like this. Thank you.