On the road to Bandol » Google

Google’s vision of Secure Elements

Eric Vétillard — Fri, 30 Dec 2011 14:35:39 +0000

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.

GoogleIO suggestions for new NFC apps

Eric Vétillard — Wed, 11 May 2011 16:26:21 +0000

GoogleIO is happening right now in San Francisco. On the agenda, there has been (only?) one talk on NFC in the Android track. During this talk, the speakers gave an introduction to NFC technology, but for someone who knows the basics on NFC, the most interesting parts were the demos, showing interesting NFC applications.

But first, let’s see what they have to say about the characteristics of NFC. I kinda like their presentation of things:

Low friction. The main advantage that they have been advertising. The idea is here that when you scan a NFC tag, the appropriate application is instantly launched, which is a much better user experience than using QR-codes.

Low range. Some good, and some bad. On the good side, the low range is a security guarantee: in order to start a NFC exchange, an attacker will need to be uncomfortably close to his victim. On the bad side, if you want to do something, NFC will be used to bootstrap, but another wireless connection (Bluetooth, WiFi) will need to be set up.

Low data rate. Not good, and another reason to switch to another wireless connection after bootstrap.

So, in Google IO, the main message is that NFC has “low friction” and allows developers to instantly start their application, based on a contextual information (a NDEF tag, or another phone in P2P mode). The examples for tags were basic but demonstrative, as they actually triggered an action (or at least, they tried to, because as usual in big conferences, network was a problem).

The P2P examples were even more demonstrative. The most basic one used NFC in a gaming environment: (1) take two phones on which the same 2-player application is installed, (2) start the application on one, (3) move the second phone in NFC range. Then, the magic occurs: the application is started on the second phone, and a Bluetooth connection is setup. The players can now start a new game and play. Now, that’s user experience.

This concept can then be extended, and this will actually happen in the next release (dubbed Ice Cream Sandwich, one of my favorite American junk foods). Then, some of the core applications will be NFC-enabled. For instance, to share a contact, simply open the contact, and have the recipient put his phone in range: the contact goes to the other phone. Same thing to exchange a URL, to confirm an appointment, or a few more things. Very impressive indeed, and for me, a whole new set of applications for NFC.

I kept one for the end. If we reconsider the gaming example, but the second player does not have the application installed, what will happen? He will be forwarded to Android Market, of course, to purchase the application. This just works.

Google even gets a reward for this: since both people exchanging data on a P2P NFC connection are likely to be connected to their Google account, such recommendations are really easy to track, or even to reward. More information for the Google database.

Hadopi, Google, and a few illegal things

Eric Vétillard — Fri, 12 Mar 2010 21:43:28 +0000

We European have strange laws. The French Hadopi law is a law that is intended to protect copyright owners against big bad teenage copiers. That law has been voted, and it is in the process of being enacted. Of course, it won’t work; such laws just don’t work.

ReadWriteWeb has published an article about Hadopi economics (in French, sorry). I will try to provide a quick outline here, but it’s far better to read the full thing.

Before Hadopi, the music industry was losing money because many French youngsters exchanged “free” music through P2P, helped by The Pirate Bay and similar organizations, who made no real money out of this. Then came the law, directly targeting the use of P2P tools. Such exchanges are now monitored, and it looks quite dangerous to continue doing it (after all, if you get caught three times, you can lose your Internet connection).

Well, using P2P is dangerous, but using direct downloads from servers sitting outside of France remains safe (it seems to tbe the way the law is applied). So now, the effect of the law is to promote a new technology. So far, nothing big: the law is just not working, and it isn’t the first one. It gets better when you realize that the companies providing the new technology are actually making money from it. Pirates are paying for the ability to download content illegally.

Now, that makes a big difference. The law has created a viable business model, possibly an entire ecosystem. Most likely illegal in France, but hosted in countries in which such laws can’t be enforced, and ready to move in a few minutes when needed. And guess what? On the other side, the music industry still doesn’t have a viable business model for selling their music. Conclusion; the law is not only inefficient, it is counter-productive, because it builds a viable (although illegal) alternative to the legal music industry.

In Italy, they have privacy laws that prohibit the publication of images that make fun of people, especially if they can’t defend themselves; such a law defends human dignity. That’s a good law, and it got some Google executives comdemned to suspended prison terms over the publication of an offending video on Youtube. Google calls this a serious threat to the Web, and gathered support from many. That’s because their role is very limited in this; after all, they only acted as a hosting platform. That’s true, but … they also made money from that video, because Google also is an ad broker who displays advertising on Youtube pages. And when I look at it from that perspective, I don’t just see a hosting platform operator.

I see a company that makes money by exploiting illegal material in a highly profitable ecosystem. The internet is great: with all its shades of grey, we have to love it.

Google ads in Java Card 3 ?

Eric Vétillard — Mon, 30 Mar 2009 21:14:03 +0000

You may have noticed that I have added Google Ads to this blog. Well, it’s the crisis, and you never know, it may bring in a few extra bucks. Of course, I know that I don’t have millions of readers, so this is not the only motivation.

I have been busy in the past week preparing a tutorial and training on Java Card, and this has included learning about JavaScript (yuk!), and a little bit about mashups. And of course, when you talk about mashups, Google Adsense is an interesting idea. So, I decided to sign in to Adsense, to see how it worked.

Well, it is definitely simple to use, and it only took me a few minutes to start, and less than two hours to tune. So now, this blog includes some ads. I also have included a Google-based search on the site, which happens to be work better than the default search, which reminds us of how Google started. If you have strong feelings about it (good or bad), just let me know by sending a comment.

The next question is: could I include such ads in a Java Card 3.0 ad?

Well, maybe, but at least, it won’t be easy. Here are a few of the reasons:

Adsense wants to analyze your content, and it may not be that easy to analyze the content of a Java Card 3.0 application.

When using Sun’s RI, the default URI is http://localhost:8019, and cards are quite likely to have a very local address. Not that easy for Google.

Obviously, Adsense has not been designed to work with Java Card 3.0, as Java Card 3.0 cards are a new kind of personal Web servers, with very personal Web applications. So personal that they are actually difficult to analyze with the traditional means. However, there is a potential market here, as these personal Web servers are quite likely to be able to serve very well targeted ads (remember, they are supposed to be used for really personal information).

Maybe the next step for Google.

What happened since 2001?

Eric Vétillard — Sat, 04 Oct 2008 11:15:21 +0000

To celebrate its birthday, Google is giving us he opportunity to search the Web as it was in 2001. So, let’s try to catch a few differences.

The Web has grown. In 2001, when searching for my last name, 9 out of 10 entries in the first page were about me. Today, it is only 1 out of 10 (and it related to my thesis work from 15 years ago).

Many companies were not around, including Gemalto. Even Axalto was not born yet. Trusted Labs was not around either.

Java Card searches have not changed much. Some references like JavaWorld’s articles are getting old, but the search results definitely look familiar

Smart card web servers already existed in 2001! Jim Rees, from CITI, implemented a “WebCard” on a Cyberflex.

“Java Card 3.0″ was already in the news. Some early believers in two French universities (LIP6 and Avignon) offered master thesis topics on Java Card 3.0. Definitely visionaries.

Well, I could go on forever, but this is enough fun for today.