On January 20, 2015 NFC World, SIMalliance and EnStream explored the role of the secure element in the evolving NFC landscape. As a result of the webinar, questions were submitted and the answers are below. You can watch the 1 hour webinar here. You can download the slideshow here.
Questions and Answers
Q: With regards to EnStream’s Hub approach, can you narrate what efforts are in place and challenges to prevent from becoming market’s bottleneck?
EnStream: As we described in the presentation, EnStream’s hub approach involves providing all 3 elements: SP TSM services to Issuers; SEM services to MNOs and single-point-of-contact commercial connections between them. One of the benefits is, in fact, speed and efficiency – the opposite of bottleneck. With EnStream, the steps provide connection to multiple MNOs rather than one. It is particularly efficient now when an Issuer chooses technology which is compatible with the one being used for the MNO SEMs, but even if a different SP TSM is used, the time to deployment is dropping rapidly. It is also key to point out that EnStream as a hub is purely a choice made by customers. If there is another provider of SP TSM solutions, for example, that can do better in terms of connection, timing and price, the market is completely open to that.
Q: As a developer, is there any solution to get access to the Secure Element without manufacturer agreement?
SIMalliance: No it is not possible. Only the issuer of the secure element can grant access to trusted parties.
EnStream: In Canada, all connections to date use the secure element in the SIM Card. (ApplePay, which uses the embedded secure element instead of one on a SIM Card, is not yet available in Canada.) Access to the SIM Card requires the agreement of the MNO.
Q: How can OEM allow developers access their SE simply?
SIMalliance: Convince them with a good business model.
EnStream: There is a lot of control put in place to make sure the secure element is“Secure”. MNOs and issuers are very selective about granting other parties the access to the secure element due to the security nature of the service.
Q: Are there any hardware or software limitations in the NFC chip / controller that curtails HCE support in an NFC device running android 4.4+ android?
SIMalliance: HCE is a core feature of Android 4.4 and is a requirement to pass theAndroid certification. SIMalliance is not aware of a way to perform this limitation. If such a limitation exists, it would be based on an OEM-by-OEM implementation.
EnStream: We are not aware of any limitations. We believe in an open environment that serves each client based on their own needs.
Q: Can it be expected that the use of eSE for HCE mobile payment is likely to be prematurely curtailed on a fully functional UE by the expiry of EMVco certification of the eSE OS & chip hardware?
SIMalliance: If the known EMVCo and payment scheme certification constraints / durations are applied to the eSE, then the lifetime of the device for payment use cases could be limited. If the device was sold within the first two years of the EMVCo ICCN being granted on the chip however, then payment credentials could be secured for at least four years, knowing that the typical upgrade cycle revolves around two years. The advantage of the NFC SIM versus this model is that it can be replaced should the need arise when payment scheme certificates are no longer valid.
EnStream: We think the chip hardware vendors and EMVCo will work out a solution out to cover the needs.
Q: Regarding the SE implementation in Canada most of these implementations are SIM-SE?
EnStream: All of the commercial deployments to date in Canada use the SIM-based secure element. ApplePay uses the embedded secure element, but is not yet available in Canada. There is one HCE (non-SE) trial happening (RBC, an employee-only pilot), but there remain major questions about the level of security with storing credentials in the cloud, and customer satisfaction with the more cumbersome tokenization.
Q: If you are storing full credentials on the Secure Element on the phone, doesn’t that mean that if the user loses his phone, someone could fraudulently use his payment process?
SIMalliance: No, because normally there is a second factor of authentication (the PIN or biometrics) and if you don’t have that, you can do nothing with the credentials. In addition, once the device is declared lost / stolen then the tokens issued are blocked on the back end.
EnStream: The protection afforded when a phone is lost versus losing a physical wallet and physical card are as follows:
- phones allow the use of a PIN to gain initial access to the phone;
- most if not all wallets or payment apps include the ability to have a second PIN to get to the app.
- Currently there are limits of up to $100 per terminal purchase without a PIN needed – for larger amounts it is expected that the terminal may require a PIN, just as it does now with a Chip and PIN, which we understand should be involve a relatively simple software update at the retail level.
- Unlike a lost wallet which can take some time, most phones now allow you to turn off their functionality OTA for security and privacy if you realize it’s gone.
- Unlike losing a physical wallet with physical cards, you can download a ‘new card’ immediately with a new phone.
Q: What technical requirement do we have on the SIM Cards for the hybrid mode of HCE. Do the MNO needs to change the SIM Card of the user and deploy a “special NFC SIM Card” to support this kind of services or a standard Telco SIM Card could be enough?
SIMalliance: Both solutions can be considered, however reusing standard NFC SIM card is the objective to benefit from the installed base.
EnStream: It depends on the specific HCE implementation. Most likely, the hybrid solution will use GP 2.2 compatible applet and will not require a SIM Card change.
Q: If we choose to store a token (like VISA token) or virtual credit card associated to a unique mobile device ID, what is the benefit of the secure element to store it? Since if the token/VCC is stolen, it’s not usable to pay. Is the fact not to use SE might impact fraud liability shift?
SIMalliance: When you download tokens, you need to do it securely. Storing them securely is part of this process and that needs a higher security (e.g. ApplePay). And you can potentially monetize the higher level of security provided.
EnStream: Simply put, secure elements provide greater security, using extremely secure hard chips, versus software alone. Secure elements also provide separate memory for each application with no interaction between them. Both tokenization and use of a secure element can offer the Issuer levels of security, but come with costs. We understand both the costs and the high levels of security associated with the secure element. Neither the costs nor the security of a tokenized service are yet well understood. We believe that the secure element is as secure as a card present transaction and will continue to offer an attractive value proposition to Issuers.
Also, unlike the secure element, the device ID is not something securely protected, and can be hacked and alerted on a device. It is relatively easy to fake the device ID on a device and use then use stolen tokens for payment.
Q: How many SIM/SE based financial payments transactions have been made over the EnStream HUB to date? Will you support Apple? How many transactions do you project will be empowered by EnStream by the end of 2015?
EnStream: EnStream only delivers the credentials to the secure element and maintains it there. We don’t ‘see’ any transactions associated with the credential once it has been delivered, so we don’t know how many actual transactions have been made. At the retail level, the POS terminal “sees” the same credentials whether the card is tapped or passed over the terminal, or whether the phone holding the credentials is tapped or passed over the terminal. It is form-agnostic, so we do not have the information as to what form a particular purchase takes. (Some Issuers can track this, and some retailers, but at EnStream we do not have that information.)
Q: How does the Sale of Softcard to Google rumour affect EnStream’s ability to attract issuers in Canada…assuming Google pushes their services into Canada?
EnStream: EnStream’s ability to attract issuers is based on EnStream’s technical, pricing and commercial capabilities and connections. We already have (and therefore in turn offer to any new Issuer) the required technical and commercial connections for all of Canada’s major MNOs. We would be happy to work with Google, and we are watching developments with interest.
Q: I am pro HCE to be fair. Time to Market for HCE can be as little as 4 weeks.
EnStream: At EnStream, we are neither pro nor anti HCE, but all of our current customers are security conscious, and we respond to their needs.
HCE with tokenization simply does not provide the same level of security offered by a secure element based solution. For some Issuers, this may not be of concern, but to many it is.
HCE with credentials in the cloud comes with its own challenges and issues, from device fragmentation to scalability and availability. From business, technical and operational point of view, it is hard to say which one is easier and cheaper to use, especially in Canada where UICC based secure element is readily available, reliable and increasingly cost-effective.
“Time to market” is only one factor, and must be tied to performance, reliability, scalability, capacity, availability, security, and functionality with multiple OSs, etc. It all involves different level of trade-offs. EnStream’s UICC SE based solution can go to market in not much longer than 4 weeks, but with similar level yet different trade-offs. To date our clients have preferred otherwise.
For banks and other security-conscious issuers, time to market is much less of a factor than those other considerations. In that context, we also challenge the anti-secure element arguments that are used to promote HCE – we are living proof that the SE solution works, is now shown in the marketplace to be much easier than opponents attempt to say (including that working with the MNOs has been fine), and is increasingly quick, simple and cost-effective to deploy. We at EnStream therefore recommend a secure element solution for applications that require a high level of security.
Q: If banks are ok with HCE for both debit and credit…how will that impact EnStream? Recently there was an announcement from RBC.
EnStream: The point is that few banks ARE “ok” with HCE for credit and debit. RBC in Canada is trialling an option with employees this winter, but without an acceptable level of security, consumers will be very hesitant. In Canada, all banks doing mobile payments use a secure element – even RBC’s current commercial “cloud” solution still loads the necessary applets onto SIM based secure elements.
We believe that the payment industry will evolve in the future based on different security and risk levels of each approach. The retailers, banks or issuers will ultimately make decisions on whether to pay for the risk or pay for the security, based on their own unique needs and the services they provide.
Q: Does EnStream work with the OEM embedded SIM?
EnStream: There are two answers to this question: An embedded secure element (such as the one in the iPhone 6), is managed by the OEM (in this case Apple), so a separate secure element management (SEM) function such as EnStream’s is not required. Issuers, however, will need the SP TSM function to download their credentials to the eSE. Commercial relationships will also be required – with an eSE they will have to be with the OEM instead of the MNOs. EnStream provides both SP TSM services and commercial connections.
Q: Will the 2 sets of slides be forwarded to the webinar attendees?
A: This is something that will be made available by NFC World. You can download it here.
Q: The Royal Bank of Canada has launched the HCE solution few months back. What was their approach? Was it pure HCE solution or a hybrid solution?
EnStream: Due to confidentiality obligations this is not something we can discuss. According to RBC’s press release, it is only an employee pilot for now.
Q: Technically how would the UICC be used to add in the additional security? To store the tokens like Apple Pay does?
SIMalliance: Yes exactly. The only difference is that you would need a business agreement with the MNO or group of MNOs (e.g. EnStream) instead of with the OEM (e.g. Apple).
EnStream: Tokenization with SE provides higher security, and advantages for e-commerce at the same time. With the SE, both the storage of the token and the process of retrieving the token are protected. Also, the token can have a longer life span and is not required to be replaced often, which will increase the availability of the service and acceptability of the user experience.
Q: No mention of TEE – how does this fit into the hybrid approach?
EnStream: TEE does provide similar security protection as Secure Element. At the same time, it requires similar agreement and integration with the OEM or TEE operators.
Q: How does HCE and cloud security affect the EnStream business model?
EnStream: At EnStream, we are neither pro nor anti HCE. However, we do not recommend HCE to any customers that require a certain level of security.
In terms of EnStream’s business model, where a full HCE solution, with tokenization, will not require secure element management, EnStream’s secure element management services would not be needed. However, as an SP TSM and supplier to Issuers, EnStream can offer HCE-related services and/or tokenization services to Issuers as requested.
In most cases, we do not recommend HCE because, even with the help of tokenisation, it simply does not provide the same level of security offered by a secure element based solution. For some applications, this may not be of concern, but to many it is. There is as yet no certification framework; we find tokenisation cumbersome and potentially less consumer user-friendly (having to repeatedly download tokens, need for network service, device needs to be “on”, etc.). There is much fragmentation in the ecosystem, including with the many and ever-changing versions of device operating systems, and most deployments are still at trial stages and have yet to be proven. “Time to market” is only one factor, and must be tied to performance, reliability, security, functionality with multiple OSs, etc. For banks and other security-conscious issuers, time to market is much less of a factor than those other considerations.
In that context, we also challenge the anti-secure element arguments that are used to promote HCE – we are living proof that the SE solution works, is now shown in the marketplace to be much easier than opponents attempt to say (including that working with the MNOs has been fine), and is increasingly quick, simple and cost-effective to deploy. We at EnStream therefore recommend a secure element solution for applications that require a high level of security.
Q: What is the critical mass to make the business sustainable? Some guess on penetration minimum?
SIMalliance: This depends on the market, the service providers / OEMs / MNOs on board, use cases, and business relationships. If we look at Apple, they have about 12-13% of worldwide market share, yet Apple Pay is creating a buzz which could be seen as creating a snowball effect.
EnStream: This is a fundamental question, but one which is very hard to answer at this stage. As with the early days of wireless, or banking ATMs, almost all business cases end up being revised multiple times, sometimes up, sometimes down, before the ecosystem settles into clear lines of cost, price, consumer uptake, etc. Again, as with wireless, those involved are assuming a significant business case – it’s just that no one is sure what the exact numbers at any part of the equation will be.
Q: What do you think about User Centric Security Model for Tamper-Resistant Services?
SIMalliance: This could simplify the life cycle of applications as management of the application life cycle would be done by the end users.
Q: Why is the retailer adoption so different in Canada?
EnStream: Over 84% of major retailers in Canada now use NFC-based contactless terminals. The main reason is that Canada experienced the liability shift, and the shift to EMV cards and chip and PIN, in March of 2011. This is quite different from the United States where the liability shift has not yet happened and will only do so in late 2015. Most of the US does not even use chip and PIN. As the shift approaches, Issuers issue EMV cards, retailers will replace mag stripe terminals with the new ones, which are NFC-capable. The introduction of ApplePay in the US is expected to spur this growth.
Q: Isn’t contactless in Canada limited to transactions below $50? and even though you are EMV with chip and PIN, there is no CVM required on contactless cards.
EnStream: Most retailers that have contactless terminals now accept up to $100 without a PIN. The decision lies with the retailer. As everyone becomes more comfortable, the retailers will be able to program their terminals to accept a higher amount, or accept higher amounts with a PIN entered into the terminal as we do now with the chip and PIN.
Q: What would EnStream’s role be in an HCE deployment?
EnStream: We view tokenization as a way to increase the security not only on m-commerce but also on e-commerce. It brings many benefits for Issuers and merchants. EnStream is actively working on the services related to the tokenization. We don’t recommend full HCE for financial transactions due to security concerns, but we do support HCE where the same level of security is not needed.
Q: Isn’t there a limit on the number of tenders that can be loaded into a Secure element? Say around 4 payment credentials?
EnStream: It is determined by the UICC SIM card storage size when MNOs order them. In Canada’s deployments, it can host many times more than just 4 credentials.
Q: There are rather secure toll road systems – how do those systems relate to NFC payment security? Isn’t it pretty similar? Can one learn from providers of those systems?
SIMalliance: Toll systems mainly use two technologies: medium range and short range. For the medium range technology (typically a gate on the road), NFC is not applicable. To pay the toll, however, NFC is useable using either payment schemes (e.g. Visa / MasterCard) or proprietary schemes.
EnStream: Toll road systems usually involve a closed loop system, whereas NFC payment is mainly for an open loop system. The distance requirements for toll systems and payment systems are also quite different. As a result, they were each built on top of different technology standards to address their respective unique needs.
Q: How do you see NFC being used outside of the mobile payment arena? For example, the efforts from the FIDO Alliance for integrating security tokens with handsets via NFC and Bluetooth Smart. Do you think there will be a consumer demand for 2-factor authentication with the phones as a reader and U2F tokens?
SIMalliance: There are many existing applications in transportation, physical access and new markets like automotive.
EnStream: Applications we can already expect include public transit, physical access, government identification such as drivers’ licences and health cards, lost car keys – the opportunities are tremendous.
Q: What have the payment networks provided on the approval/certification policies, to date, for HCE models?
SIMalliance: Some HCE certifications have now been released, however most of the current deployments are under waivers. Payment schemes have been providing some high-level draft information about certification through their technology partner programmes. You should request access to the information you seek through the relevant programmes.
EnStream: We can just repeat the SIMAlliance answer: “Some HCE certifications have now been released, however most of the current deployments are under waivers. Payment schemes have been providing some high-level draft information about certification through their technology partner programmes. You should request access to the information you seek through the relevant programmes.”
Q: I’m sure that SE can guarantee le security for payment but what about passive NFC tag? Is it possible to implement a sort of SE in such things as key ring, bracelet, and business cards and so on? Can I run low-amount payment on passive NFC tag?
SIMalliance: Yes, wearable devices could be either HCE or secured with an SE. This also a potential new market for the SE.
EnStream: Passive NFC tags usually do not have secure elements or the connectivity required for payment, although some of the wearable devices now have those capabilities and can be used for payment purposes.
Q: After attending the NFC World Webinar on evaluating NFC security strategies, which was very interesting might I add, I would like to hear EnStream or Ms Hall Findlay’s opinion on the development of NFC in the USA. I am concerned that the current migration to EMV “Chip and Pin” occurring in the USA at the moment will cause problems for the uptake of NFC by the end user. I am not questioning that NFC is viable but I feel that having the end user having to develop a reflex for two fairly different payment methods at the till will cause NFC growth to be stunted.
I would very much like to hear your opinion on this matter, especially as you have such a firm understanding on the neighbouring and fairly comparable market of Canada.
EnStream: Fundamentally, consumers are pretty adaptable. Canadians have had no trouble adapting to the “tap or pass” (now also possible with phones) option for contactless at the terminals that they use for chip and PIN. I am amazed at hearing some in the US still worried about how quickly and willingly customers will adapt to chip and PIN – we can vouch for the fact that it simply wasn’t a problem in Canada – and I’m not sure retail customers are that much different here than south of our border. Indeed, as US customers may be seeing both alternatives at once may lead to an even greater adoption of the NFC contactless options, due to not having to learn twice. We’re very confident that US retail customers will be more than willing to embrace both chip and PIN for their plastic cards and contactless for their cards or phones where offered.