Google’s vision of Secure Elements

Google has launched its Google Wallet service, which uses a secure element in the phone to provide some security. Of course, Java card is in every one of these secure elements, but it is not the point today. I have just stumbled upon the Google Wallet page. Initially, I was looking for information about how to load the Google Wallet on my Nexus S during a visit to the U.S. I haven’t found this information (if you know, I am interested). However, I have found how Google talks about its wallet’s security.

Here is the sentence that first drew my attention:

A wallet you can lock. Stay safe with the Google Wallet PIN and with secure underlying technology.

This started again my love/hate relationship with Google. A wallet you can lock? It’s just brilliant, far better than anything else I have seen on the same topic. Where do they find these things? Now, let’s see how the rest fares, from their Security section.

Google Wallet stores your encrypted payment card credentials on a computer chip on your phone called the Secure Element.

Sounds good. The Secure Element is explicitly defined as a separate chip. I find it interesting that they feel the need to mention that the credentials are encrypted.

Think of the Secure Element as a separate computer, capable of running programs and storing data. The Secure Element is separate from your Android phone’s memory.

Once again, all of this sounds good. Very nice way to describe a smart card.

The chip is designed to only allow trusted programs on the Secure Element itself to access the payment credentials stored therein.

Uh oh! I really recognize my favorite Java Card firewall, isolating applications from each other. But I am a bit disappointed to read that the “chip” is designed to support that. Yes, the chip’s memory can only be accessed from the chip itself; but on the chip, the isolation is software-based.

Next step, the FAQ’s Security and Privacy section. Among basic questions about lost phones, there are two good questions related to secure elements:

  • What is the Secure Element and how secure is it?
  • Could a malicious application access my credit card on the Secure Element?

You can read the complete answers there. However, here is what should be the most important sentence, since it ends the answers to both questions:

There are multiple levels of protection for data stored on the Secure Element and it is protected at the hardware level from snooping or tampering.

Of course, smart card specialists know about all the terrible attacks hidden behind the “snooping and tampering”, and how to protect from them. But the sole mention of data is a bit disappointing.

The answers also mention several times that only the Google Wallet (and other authorized programs) can access the Secure Element, and that this access control is strictly enforced. This is good, and we all like the fact that access control is present.

Now, what’s missing? You may have guessed it from my “data only” disappointment. There is no mention of the fact that the secure element can do more than payment. So, Google, if you are reading this, I will go as far as writing the missing FAQ piece:

Can I use my Secure Element for protecting other assets?

Your Secure Element is a small but powerful chip, which runs its own applications to manage sensitive data. It can even host several applications, to provide different security-related services. Of course, since the access to the Secure Element is strictly controlled, only authorized developers can write applications for it. We have selected a limited number of partners, who provide applications that rely on the Secure Element to manage their security credentials. These offers include VPN application, secure authentication applications, and much more.

Hoping that it will become useful someday. And if you need more material on Java Card, just let me know.

5 Comments

  • lexdabear wrote:

    Maybe one of your first visits should be to Google? Of course if you don’t have same dilemma as with Gemalto regarding IP :).

  • Hi, Do you know if this secure element is the UICC, or another card ?

  • Google is using an embedded secure element, i.e., a smart card chip soldered in the device itself.

    There is no UICC in the plan, because this would mean that Google would have to negotiate individually with each MNO to deploy its wallet. Of course, in application to the “no free lunch” rule, there is a problem associated to that: In countries where MNOs have a lot of power (in particular where they subsidize the phone), Google will not be able to deploy their wallet. For instance, this seems to be the situation in France (although this initial situation may of course evolve, for instance if/when one of the MNOs accepts to launch the wallet…).

  • Hi, Thanks for your answer! My understanding is that European countries and France particularly are strongly pushing for the use as UICC as the secure element.
    I have the feeling that the UICC would prevent some vulnerability like the PIN exposure that has been discovered lately.
    Google will have difficulties to develop their standard in europe if they are not following the global stream !

  • From the business point of view, I am sure that Google will have to deal with MNOs in a way or another. However, from the technical point of view, I doubt that the use of the UICC will make things easier.

    Just one simple remark: An embedded SE can be controlled, directly or indirectly, by Google or another wallet provider. By itself, this simplifies the security situation, because there are less actors to deal with.

    There is one point for which the UICC is better, though: Total failure. It is possible (and expensive) to replace a UICC altogether if a flaw is found in the depth of the UICC. For an embedded SE, the only solution is to disable it or to replace the device, which is even more expensive.

    About the PIN attack, I will comment on a separate thread, because some remarks in some articles are very surprising.

Leave a Reply

Your email is never shared.Required fields are marked *