To celebrate that, I have decide to attend the opening session this year. We started by an enthusiastic eID spporter from European Union, promising us all regulations and standards ready for 2014, which sounds interesting. After all, there are very interesting deployment in countries like Belgium and Estonia, which could be extended.

Then, we get a panel, with the question below. Speakers are Christian van der Valk, from TrustWeaver, Herrmann Sterzinger, from G&D, Massimo Cappelli, from Global CyberSecurity Center, and Marie Figarella, from Gemalto.

Why has eIAS services not been a success to date?

• Is it really the case? There haven’t been failures, there are many services ready to,use, and a lack of recognition, with a common perception that digital signature ismore difficult than it actually is.
• Citizen certificates are too expensive, and the use cases are not compelling enough. Thisis changing in some places, like in Austria, where the state pays the citizen certificate.
• Market fragmentation and lack of trust and confidence are the two main issues. They may even be linked because the fragmentation does not allow the development of global solutlons, deployed across Europe.
• Issues have been legal and societal, not technical. Fragmentation and lacking use case are the most important,

How would the new electronic identification and trust services regulation improve on this situation?

• Moving from directive to regulation is important
• Making it global would be good, but also hittin some limits, in particular regarding discrepancies in privacy requirements.
• Moving to a regulation will limit fragmentation, the scope will be larger, going beyond signatures to seals, timestamps, and more. Mobility between states will also be greatly improved. Finally, supervision should be improved.

What additional key actions would be necessary to make eIAS a success?

• Sharing identity and authentication between public and private spheres would help. Also,aligning with the global market with help, including private support, like Adobe. Also, the recognition of non-PKI solutions would be required (that sounds interesting)
• Moving beyond web authentication is required. Moving to global regulation loses things, such as already deployed eIDs, which do not comply to the new regulation, and also existing standads and existing profiles.
• Bureaucratic simplification associated to eIAS would be great help. We are also missing a common framework of expertise, with collaboration between national agencies. Thereisalso a digital and cultural divide, which hurts wide adoption. Finally, including soft identity would increase the use of strong identity, if it can be used in our everyday life.
• Associate reliable digital identity with a portable secure elemnt, to allow 2-factor authentication. Build an open and interoperale secure Internet. Privacy by design. Push digital identity on all SIM cards to benefit from NFC

Now, that’s quite interesting. The views from the panelists are quite consistent. The question that puzzles me most is the relationship between national and private identity. I am left wondering what opportunities will be given to private companies and web providers to leverage this eID. Making this happen would be a great boost to eIAS.

I also liked Gemalto’s analysis and proposals, which was short and to the point, except the last point, of course; mandating SIM-based identity for NFC is ludicrous and pure lobbying, at least because the SIM is not the only way to access NFC.

So, an interesting first panel, although there haven’t been many suprises and illuminating discussions.

This sounds interesting, and I will be listening to the show (maybe not live, but I will definitely get the podcast). I listened many times to France Culture’s science shows, and they are usually serious and interesting. Of course, the question (in English, how to enhance the security of bank cards?) is already a bit aggressive, and I am sure that some people would even challenge that question, claiming that there isn’t much to be enhanced. Well, we’ll see on Friday.

Most of us, who don’t know the EMV specs by heart, would believe that the PIN authentication is part of the card applet’s state machine. After all, Chip and PIN seem to be very tightly connected to each other. Well, it isn’t the case, and PIN verification is just something that may happen, or not. So, the discrepancy can go unnoticed.

When looking at the EMV protocol in greater details, like they do in the article, we notice that the information is actually present, but that we are missing a method to consolidate the various bits of information. Some items are optional, while some others (the IAD) use proprietary formats, and are not intended to be parsed on the terminal. Basically, there are solutions to counter the attack, but they are not obvious to implement. If you want all the technial details, refer to the full paper.

Now, what does this attack tell us about the EMV Protocol? Well, it has a vulnerability, like many (all?) other security protocols, at least in the way it is most often implemented in practice. It’s a rather big one, too, which shows that smart card protocols most likely get less interest than others. It also shows that simple is not only beautiful, but also secure, or at least that the complexity of systems like EMV, with all its options, is becoming a real security issue.

Then, another issue is that the ability to perform over-the-air software updates to fix vulnerabilities is becoming standard, on computers, on phones, and even on some TVs and soud systems, provided that they are connected to Internet. Well, such things remain hard to do on payment terminals, and also on smart cards, even though th security of these devices is critical. Can we really expect card operating systems to become more complex if we aren’t able to maintain them over their lifetime? Probably not, and that transition is going to be tough.

Another thing that this attack reminds us of is that smart cards are just another security measure, which cannot be perfect. The paper contains the usual attacks against UK banks who, according to the authors, make customers liable as soon as PIN authentication is used on a bad transaction. Here, the problem is not the technology, it is the system around it. Magstripe technology is far more broken, but if the insurance provided by US banks is better, then the consequence is that the customer, in the end, is better off with the lower security, because their insurance provided by their banks is better.

About PIN security itself, it is in fact very easy to guess the number typed by a person on a keypad, even without seeing the keypad. You can make the experience in any European supermarket line: simply try to guess the PIN typed by the people in front of you. You will notice that in many cases, you have the feeling that you got a lot of information about that PIN. Add to that the fact that you are far from being a trained professional, and you can get an idea of the problem: protecting a PIN is difficult. As far as I know, in France, where Chip and PIN has been the rule for many years, it is not too hard to avoid liability even if our PIN has been disclosed. The PIN is not a miracle, and it cannot solve all problems.

Finally, a positive note. We are getting quite a lot of attacks on smart cards these days. The program of Cardis 2010 includes 6 papers on attacks, and the published state-of-the-art is getting closer to the laboratories’ state-of-the-art. Some might say that this is dangerous for cards, but some others will say that this is actually a positive evolution, moving away from the “smart cards are secure” dogma into a “smart card can help build good security models” logic. And if we use that logic to build business models that ultimately benefit final customers, then all of this will have been a step in the right direction.

Android does not offer a Secure Element interface. Of course, Android phones are able to interact with SIM cards, but applications have no access to the cards, or to any other Secure Element (SE). And of course, forget about NFC access. Will that last? Of course not, as manufacturers and other service providers will make sure that they can build Android applications that use secure elements.

Apparently, Giesecke&Devrient has really started that war, by announcing a security solution for devices running Android. This is a combination of two things: a MicroSD card that embeds a smart card chip, and software that allows the Android platform to access it.

Cartes is about 10 days from now, so we can expect a few more announcements and demos to be made there. Trusted Logic has already announced a NFC stack for Android, and I bet that more will come.

For now, we can take a closer look to the G&D solution, especially because they have published their software on a Google Code Project.

This project is still evolving, so what I am writing is is a snapshot of its state on November 4, 2009. One of the latest additions is a paper called Security and Trust for Android. This paper contains a lot of information, as well as a nice vision, but it is also a bit confusing, and remains a proposal, as stated in the introduction.

This paper deserves to be read, though. Its main vision is that there are many SE’s that can be used (SIM card, MicroSD, TrustZone, Software SE), with different properties, and in particular with different security levels. Nevertheless, the paper insists on the fact that all these SE’s should be accessible through a regular API, and that there should be a similar way to program applications on all these SE’s. Now, that’s an interesting vision, although it is kind of hard to achieve (for instance, SIMs and MicroSDs both use Java Card applets, whereas TrustZone and software SE’s are usually based on native applications.

I have not looked in great details at what they offer, and I have not tried to use the software. However, I did take a look at the samples, in particular at the one based on the native interface. This interface looks quite nice and simple, and the sample is far easier to read than the one based on PC/SC.

Basically, this effort looks like a good way of making a SE interface available on Android, and to offer a way to interface with a particular kind of SE. This looks like basic software, and I am sure that we will need to consider many more aspects, like security, access control, and more. However, this is not the goal here, as the proof-of-concept definitely is the important part. Completeness (and complexity) will come later.

I would love to say more about the technical details, but it is late, and trying these things out takes time. I will therefore come back later to that topic. For now, I will close with a few non-technical comments:

• I like the fact that G&D has made the software open source. Obviously, the Android drivers and APIs are not how they intend to make money, so this sounds like the natural thing to do. However, this is the smart card industry, and secret is usually considered better.
• Hopefully, G&D will also work with the other actors of the industry in order to make this API the best possible. Since this would add more weight to their proposal, it also sounds like a natural thing to do.
• Even more hopefully, the industry as a whole will make sure that the Android developer community actually understands how to use these Secure Elements. This will require a strong educational message, which is just started by the G&D white paper.

The last remark goes to the Secure MicroSD product, together with its Android integration. It is a composite product, integrating a large memory and a smart card microcontroller; in addition, it is integrated on a Web-oriented platform. Well, that sure looks like a great target for Java Card 3.0 and its servlets. This would even greatly simplify the API requirements at the Android level, and also greatly enhance the appeal of the solution to Android developers.

There are a few exceptions to that rule. If you are lucky enough to be in a place that accepts American Express, these cards will be accepted even if they don’t have a chip (this is quite natural, since even those issued in Europe have no chip). But in many cases, you may well be really out of luck. Consider the subway example, for instance. In many places, it is becoming common to close all tellers at late hours, only to leave automated machines. And if you can’t get them to work, well, things may get ugly.

Things are only going to get worse, and apparently, some American companies have understood that. According to the NYTimes, Travelex is getting ready to issue prepaid smart cards for its customers in a bout a year from now. That means that, in a while, we should see American tourists with smart cards. And if it works, we are quite likely to start seeing American businessmen with smart cards as well, as corporate cards for international travellers will start having them as well.

Good news for smart cards? Not necessarily. If we consider that only 20% of all Americans have a passport, this also caps the number of Americans with that specific need. Most likely not the killer reason for American banks to switch to smart cards, which are still considered too expensive to manage.

Of course, this is too tempting not to imitate that. I therefore looked for “smart card” and “Java Card”. And the results were not that inspiring

When you search for smart cards, Google offers you … smart cards. Most of the offers on the side are advertisements for USA Smart Card or motechno, or Smart Card Source (my links are free). All these guys sell rather old smart cards at rather steep prices. On the other hand, for people who want to try using cards, this is often the only way to get their hands on actual cards, since it is quite hard to get some from the manufacturers.

This is really a sad situation, and we are kind of hurting ourselves. “How to get cards?” is the most common question that I get on this blog’s “Contact” link. I don’t have a good answer, and by making it hard to get cards, we are mostly hurting our allies. And if somebody worries about bad guys who get cards to attack them, I would tell them not to worry. Real bad guys are able to get the cards they need.

Of course, I would love to be proven wrong. So, if a manufacturer has a way to provide a kit with up-to-date Java Card cards (at least Java Card 2.2.2 with GlobalPlatform 2.1, preferably 2.2, wonderfully, Java Card 3.0), I will gladly provide free advertising. Just leave a comment or contact me.

Let me get you a biased timeline for this week, from Tuesday to Friday.

Let’s start by Tuesday:

• The Java Card 3.0 Programming course at Smart University lasts all Tuesday and Wednesday. My personal contribution in it is about security, on Tuesday afternoon. That should keep me busy for a full half-day.
• If you are into contests (or if you are broke; this event is free), the new SIMagine contest will be launched with a full-day conference on Tuesday. This is not a Gemalto contest any more, but a wider contest, which is not limited to cards any more (even though I guess that involving a card in this could be a good idea). If you have a good mobile security idea (with a SIM card), that could be of interest.

Wednesday will be very busy, in particular because there are events on the side of the main conferences:

• In the morning, the Java Card Forum organizes a meeting with academia, to see how we can help in promoting research about Java Card 3.0. This event is invitational, but if you are an academic, present at e-Smart, and you are interested, you are welcome at 10:00AM (I am not sure of the room, but I am sure that there will be an indication; follow the JCF logo).
• In the morning, I like the title of Jacques Bus’ keynote speech, Trust in digital life. I usually skip keynotes, but I may attend that one.
• In the afternoon, There are also interesting speeches at e-Smart. First, one of my colleagues, Guillaume Dufay, talking about a formal model of really open cards (old topic, with a new twist), around 3:00PM. Later in the afternoon, there will also be a speech from G&D about a secure runtime in the mobile; finally, Trusted Logic has a competitor in that field, moving forward to prove its interest.
• Finally, almost all of Smart Mobility‘s afternoon sessions sound interesting, for various reasons. Tough choices ahead …

Thursday will not be dull either, although I will finally be able to fully focus on the conferences:

• The morning at e-Smart will be a combination of NFC Security and Trusted Personal Devices. Two topics of interest for me, so I may be surfing between sessions.
• Smart Mobility will bring us some discussions about the NFC ecosystems (TSMs and more), and about user experience. Interesting, but I have the feeling that there a few more new things at e-Smart (I may be wrong, though).
• The first part of the afternoon is a no-brainer, at least for me. I will be on the stage, talking about Java Card 3.0 and Smart Card Web Server Security. My co-presenters, from Gemalto/Eurosmart and from Inside, will also have interesting speeches about cloud computing and about convergence.
• If this is not you cup of tea, the other session of e-Smart could be very interesting, about state-of-the-art security. I am likely to join that session after break.
• On the Smart Mobility side, my choice would go to the Mobile banking session, but mostly because I know about mots of the things presented in the other session.

Friday is morning only, but that is quite a dense morning:

• At e-Smart, it is the Java Card session. The first part is quite introductive, with the amusing PlaySIM project (already discussed here). The second part includes two speeches about attacks; expect to find me there.
• In parallel, Smart Mobility has a special TL session, with 4 consecutive speakers from Trusted Logic and Trusted Labs. I may miss some of them because of the Java Card session, but they are all worth it.

Finally, I will try to be connected, like usually in conferences. I will be on Twitter (evetillard), with the tag #esmart (join me using it), and I will also try to blog live about the most exciting things.

The idea is to put together a USB token containing a Linux distro and a smart card that will be used to provide security services, for encryption, authentication, and more. The idea definitely looks good: a self-contained Operating System with embedded smart card security (at least, there should be no problem addressing this smart card). To make it better, they intend to put a card that supports Java Card there, and we could imagine an API. Just add Java Card 3.0, and this would look quite perfect.

I definitely wish them the best for this project.