Bell ID launches NFC secure element in the cloud platform

The new service enables keys, certificates and NFC credentials to be stored securely in a remote location, rather than in the mobile device, is fully compatible with standard EMV contactless payments terminals and enables card issuers to deploy NFC solutions without the need to partner with mobile network operators or other third parties.

Bell ID
SUNNY OUTLOOK: Bell’s cloud-based solution promises secure NFC without having to negotiate with physical secure element gatekeepers

Bell ID has launched Secure Element in the Cloud, a new platform that enables card issuers to store keys, certificates and NFC credentials in a secure remote environment rather than in their customers’ mobile device.

The solution provides application issuers “with the independence and control to manage their credentials without the need for third party involvement,” says Bell ID.

The platform is commercially available today and has already been deployed “at a leading bank in one of the most advanced contactless payment regions in the world.”

When a consumer makes a transaction using Bell ID’s solution, their NFC credential is accessed from a remote secure element, located in the cloud. This then generates the appropriate command for the transaction and sends it back through the mobile device to the merchant’s point-of-sale terminal.

“The data is presented in the same format as that used in standard card-present transactions,” says Bell ID. The solution works with both standard contactless terminals and acceptance infrastructures.

The secure element in the cloud platform can also be used to pre-authorise payments, allowing consumers to make transactions even when a connection to the server cannot be established.

The direct access offered by the new software to the SE also supports instant fraud detection and allows immediate blocking of an application when necessary, the company adds. “Additionally, having the SE in the cloud increases computing power and storage in comparison to a physical SE. This provides more options regarding advanced on-device risk management, as well as the ability to support virtually any number of NFC services.”

SE IN THE CLOUD: How it compares with physical secure elements. Click to enlarge.
SE IN THE CLOUD: How it compares with physical secure elements. Click to enlarge.

“By moving the SE from a physical device to a remote environment, application issuers are able to directly provision their applications to an SE,” explains David Orme, CEO of Bell ID. “This enables them to take full control of their relationship with the customer and ensure a consistent brand and user experience across all available channels and services.”

“With our Secure Element in the Cloud software, we offer an easy, affordable and flexible alternative to the complex deployment models used in today’s NFC marketplace,” adds Pat Curran, executive chairman at Bell ID. “This makes mobile NFC services accessible to a much wider audience, including banks, service providers, mobile network operators, payment processors and card personalisation bureaus. We believe this is the next breakthrough in the adoption of mobile NFC services, which is already proven by the high demand for this solution from our customer base.”

Next: Visit the NFCW Expo to find new suppliers and solutions

16 comments on this article

  1. Yeah, great, let’s reduce EMV security back to mag stripe standard again … ! 🙂

  2. I think that this will definitely benefit payment card issuers greatly. No more need to interface with multiple MNOs with different technology requirements and adding to the costs. Less limitations in terms of supported devices

    @Franz not sure how you see this as “going back to the mag stripe standard” in terms of security? A.f.a.i.k. in the magstripe world nothing was in the cloud and moving the SE from a device into a secured environment maintained by the bank itself does not seem less secure to me in fact I’d trust my financial credentials to be more protected by the bank than by a mobile operator or apple! For the rest the transaction is still EMV compliant and secured as such…

  3. @Franz, Actually, we use EMV in this solution exactly as it is securely indented; as a smart card based payment system that provides the same improved security. So rest assured we are taking steps forwards instead of backwards.

    The EMV transactions can use the same PIN and cryptographic algorithms such as Triple-DES, RSA and SHA to provide authentication to the processing terminal and the card issuer’s host system. The only difference with common EMV contactless, is that the behavior and characteristics of a smart card secure element is now provided from the secure cloud server.

    1. I want to know who they are currently providing this service to? Sounds kinda loose.

      1. It’s not unusual for companies to not name customers, or for their customers to prefer to remain unidentified. There’s probably not much upside for the customer in showing its hand at this stage…

  4. Hi,
    of course this is a way to get things going. But it definitely reduces security. With a smartcard, you give the cryptographic key that is used to ‘sign’ a transaction to the cardholder in the most secure form. Putting the key in a hardware secure element can be almost equally secure, if all the security components like SE, HSMs and so on are properly built. Putting the key out of hands of the cardholder, in the ‘cloud’, reduces the security down to the mechanisms that are used for the cardholder or mobile to authenticate against the ‘cloud device’ that holds the key. Those mechanisms are almost certainly weaker than the ones used for smartcards or SEs, because without the use of a SE they have to rely on software, and they are most probably not publicly known and not verified by independent security specialists.

  5. Hi Franz, authentication for the secure channel is usually initialized by a two factor (out of band) activation procedure as with mobile banking. But we also see our solution being used in combination with authentication credentials stored on ordinary (non NFC) SIMs. This is however not a necessity and more an additional layer of security for the authentication.

    We are partnering on device security to ensure security of the data in transit, and make sure it is secured against interception and cloning, in-app cloning, misuse of API’s, data confidentiality and SW integrity. This ensures an on-par or even higher device application security as that provided with most mobile banking applications today. This technology is known and available.

    Keeping the private keys and personalisation data in the secure network and hardware security modules at the bank ensures that there are actually less potential entry points for malicious software. As well as leveraging the POS acceptance infrastructure, the bank can now leverage the same security infrastructure used to secure internet and mobile banking. Our software solutions are used in the secure and certified facilities at many of the largest banks and financial institutes worldwide, and have been for many years. The software is specifically designed to fulfil these security and carrier/transaction grade requirements.

  6. I’m curious about a couple of things:

    1) Supported devices.
    For sure, a device supporting Host OS Card Emulation is needed;
    a.f.a.i.k ,Blackberry is the only handset manufacturer who has
    decided to open the interface of its NFC chipset in such way that it
    can also talk to alternative SE form factors (e.g. SE in the cloud);
    what are (or how many) the devices you have tested?

    2) Schema rules (issuer’s consensus).
    At this stage I cannot be fully aware about the Bell ID solution (how
    could I be, otherwise …), anyway I wonder if the “EMV emulation”
    you provide upfront the terminal, by presenting a Card Present
    transaction like, is schema’s consensus independent; I mean, can
    any Issuer PSP be free to implement that solution, without
    previously asking for VISA/MC’s consensus?

    Tanks in advance for an answer.

  7. How do the credit card companies see the cloud based security – will they treat payments authorised this way as “customer present” or “customer not present” – the latter incurring higher charges?
    Thanks!

  8. Interesting solution, but I have 2 essential questions:

    1) I have some concerns about the security of this. The Bell ID response said: “The EMV transactions can use the same PIN and cryptographic algorithms such as Triple-DES, RSA and SHA to provide authentication to the processing terminal and the card issuer’s host system.”

    You need to talk to the “cloud server” from the smartphone. Where is the symmetric key (or private key for asymmetric) for this secure communication to the “cloud server” stored on the device? It’s fine that the NFC security credentials themselves are stored on the server, but the smartphone itself needs to access this stuff securely. If the NFC security credentials are stored in the secure element INSIDE the smartphone, you know it meets a certain standard of security. With your solution, I am concerned that it may not meet the same security since you need to store the crypto keys for securely talking with the “cloud server” somewhere. The whole chain is only as strong as the weakest link.

    Now, are these crypto keys required to establish secure session with the “cloud server” stored in some kind of secure element in the smartphone? Otherwise, a hacker just needs to get access to these keys, and the NFC credentials that are “securely” stored in the server is compromised. You can lock all the other paths to the NFC credentials on the server sitting behind a vault, but if you give an invitation with a red carpet to a hacker to steal the crypto keys from the smartphone to “securely” connect to the “cloud server”, that will obviously be a problem.

    Which brings to my 2nd question…

    2) It appears that with this system you are saying the bank can deal directly with customers and not worry about dealing with the carriers, smartphone manufacturers, etc. But, at some level, don’t you need their permission to install your “primary” app/data in the SE? Or do you not use the SE on the smartphone at all? To be more specific:
    a) if you use the SE on the device, how do you get approval from carriers, manufacturers to put this initial app/data, that will be used to subsequently completely bypass them through the “cloud server”; OR
    b) If you DON’T use the SE on the device, how do you deal with the security concerns that I raised in question (1)?

    I am “guessing”, your answer may be that you guys implement your own custom s/w secure storage solution that is OUTSIDE the smartphone’s h/w secure element (e.g. a software secure storage implementation to store the crypto keys)?

    Thanks. I look forward to your response Bell ID. This sounds like an interesting solution, but I do have my concerns from a security perspective. Btw, do you have a white paper with more specific details? The brochure on your website is just a marketing document, and obviously doesn’t answer the core questions.

    1. @Nilanka – In different configurations of the solution we can store and/or use the SIM or NFC USIM for storage of credentials, key elements, and strong authentication.

      There are other elements to this combined solution (SE in the Cloud and SIM/NFC USIM) which we cannot reveal considering non-disclosure agreements of running projects and clients.

      With regards to the creation of a secure session, for each of the scenarios mentioned, much like with mobile banking and other like solutions, during the initial registration and activation of ‘cloud cards’, each results in the creation of a user/card passcode that is required to set-up the first part of the session. It is initially coupled with the combined verification of an out of band supplied activation code. All are exchanged and stored at appropriate points in the sequence using UNs, said hashes with many different device, session, and user specific data.

      Only when the initial part for setting up the specific user/card has been passed, the session is extended to software elements running in further network segments.

      As you can imagine this is just a broad description. For each deployment we leverage existing security infrastructure and existing customer interactions to create a waterproof secure session management configuration. In most cases it will be a further extension to a configuration already in use for mobile banking solutions, i.e. in addition to requiring a passcode to unlock the basic mobile banking functionality, another level of security is introduced for mobile payments.

      Contact us for more information: [email protected]

      1. Hi Bell ID. Thanks for the quick response. However, I don’t think it goes to the heart of my questions.

        You mentioned that you can use SIM or NFC USIM in some configurations, but this would still need the corporation of carriers/manufacturers to store those credentials (question 2 above). I can totally understand your non-disclosure issues and I completely respect that. That said, my “general” confusion here is why would you expect carriers/manufacturers to sanction such a solution, which can take so much power/control out of their hands? If the banks can deal directly with customers using your solution, the carriers/manufacturers can be left hanging. But, it sounds like you need their support to get your “foundation layer” established (use SIM or NFC USIM) in the smartphones/devices to subsequently leverage the cloud as you propose as a secure element.

        It’s good to hear that you are doing out of band information to do the initial activation. Certainly, that is a required important step. However, what happens to the secret keys that are established from that activation? Where are they stored? If they are stored in the SIM/USIM, then my question above applies (getting permission from carriers/manufacturers). If they are not stored in the SIM/USIM, then anyone who steals the phone, “borrows” the phone, etc may be able to get at those post-activation keys. I am not saying it’s easy.. But it’s easier than if the keys were stored in h/w. Is this an accepted limitation of the solution?

        Also, I appreciate that you may layer this on top of existing banking infrastructure. However, if that is a required dependency, those configurations cannot be a stand-alone solution.

        Thanks, and I look forward to hearing from you. Once again, it sounds like a very interesting solution, but like others in this thread, I am concerned about the security of it.

  9. Hi, I am curios about one thing. The solution should also work without a connection to the server. How is possible to use payment information with the POS if it is not possible to retrieve them from the cloud? Are you storing it somewhere locally, e.g. in the real SE? Thank you.

Comments are closed.