The technology is now ready, and it has not evolved greatly in the past few years. Java Card and GlobalPlatform are mature, widely deployed technologies; many companies are able to develop and deploy cards. Of course, there are a few technical challenges remaining, to keep engineers busy. One of the most challenging tasks is the establishment of trust between the various actors of the industry; today, formal security certification is at the heart of this, but something a bit more innovative will most likely be required here.

The new frontier for cards and secure elements are applications. This is much harder than implementing technology, and requires a lot of innovation. Will we be able to differentiate smart cards from tags? Will we find a room for card applications between basic SIM authentication and TEE applications? Will there at some point be a way to work on this? That’s the Chip-to-Cloud challenge, and I hope to get a few interesting answers next September.

The Call for Papers is out now, so go ahead, propose things. I am convinced that this conference will remain one of the places where academics, industrial R&D, and technical marketing people are able to meet and exchange. See you there!

The first question is to understand how privacy and trust are similar and different from the typical security issue. A first interesting thing is that the smart card industry is one of the rare industries that is able to ship 4 billion personalized objects every year. That makes it suitable for use with companies like Google or Yahoo! who deal with hundreds of millions of customers.

The kind of things that smart card vendors usually propose in the Web arena are the following:

• Two-factor authentication. This can be provided in the form of OTP (one-time-password) applications, or solutions reusing the eID infrastructure using in goverment applications.
• Privacy enhancements. A card may securely store credentials, and only release them as needed and required (with appropriate proof), without disclosing the entire information. Think of a system that would simply assure that you are over 18, without disclosing your name.
• Identity management. Identity with a token can improve authentication with Web mail, instant messaging, and more, and then allow the enforcement of better access control policies.

The next issue is to figure out how this matches the needs of digital security, which are as follows:

• Protecting our digital identities. That’s something where smart objects can bring an immediate value, as we have seen ajust above.
• Protecting our digital assets. Our assets on the Web are very varied (contacts, images, and all kinds of content) need to be protected, from other people, and also from the Web service providers, who may be tempted to abuse them.
• Protecting our e-transactions. Online transactions today are often very simple, and involve a low-level of security. There are proposals from the smart card industry, but they do not always match the requirements of Web service providers.

This view is very valid, but it is also a very traditional view of digital security. It may be more interesting to look at the things that become possible when our digital assets are well protected. By bringing more security, we bring more value and more freedom to the users, because there will be new ways to exploit these assets, which are not possible today. Eventually, mandating a higher level of digital security brings more choices to the end user, not less choices.

If we dig a bit deeper into Web services, we all love them because of their ubiquity. They are accessible from anywhere, they don’t put constraints on us like updates and backups. We love this, but we also need to be aware that there is a tradeoff between availability and security.

As an example, the tendency towards free, viral services that later monetize their user’s data suffers a few exceptions. In particular, there are few such services around money management and personal health record management. This means that most users don’t place enough trust in Web services to allow them to manage what they regard as their most sensitive data. The kind of issues that Web services face include the following:

• No network, no service. This is slowly becoming a thing of the past. Slowly in some cases (roaming, for instance). We can provide solutions, but they should not be our main focus.
• Security limited to username and password. There isn’t much worse in terms of security.
• Privacy. Users basically have no choice. You need to accept the service provider’s conditions, or use another service.
• Trust. There are no standard metrics to establish trust like there can be in the smart card business.

If we focus even more on security, privacy and trust, the challenges for Web services are as follows, from the user’s prospective:

• Identity theft.
• Unclear data access control
• Unclear service definition
• Unclear terms and conditions

Another aspect of things is data protection, which is another set of user worries:

• Storage. Where is my data? What is the disaster process? How are permissions set? How can I control the access to my data?
• Revision Management. Is there a tracability of the changes? A possibility to be warned of canges? A possibility to track changes and review them later?
• Life cycle (retention/termination). How to terminate hosting data?

Next, we get into the heart of the topic: what is it possible to offer from the smart secure devices point of view? The first initiative is about transforming the World Wide Web into My Web, by combining several aspects that restrict accesses:

• IP Geo-Localization. Make some services accessible only when I am located in a given area or set of areas.
• Appliances ID restricted access. Make some services accessible only from some computer (based on a more or less secure characteristic of the computer).
• Time restricted access. Make some service accessible only at a given time, like allowing children to access instant messaging only between 4:00PM and 8:00PM.

Next, there are solutions for data protection:

• Data encryption, RAID applied to data centers, with smart secure devices controlling it.
• Smart Secure Devices acting as Proxy server. Re-route SOAP messaging via a proxy, and apply some filtering at that level.

The last idea consists in plugging a Smart Card Web Server into a fixed device (for instance, a home gateway, or “box”), and to make it accessible from Internet. Such a device can have many uses, and its main advantage is that it is not with you at all times. There are many applications for this, ranging from basic secure proxy/filter to two-factor authentication. Of course, there is a trick here, since your second factor is actually on the Internet, so you will need to use a different kind of credential on these things, to prove who you are. One of them, provided by Xavier Larduinat, consists in presenting you the pictures of 20 random Facebook members, including your friend Alice, and to ask you to click on Alice’s picture. I’ll come back on authentication in later posts, because there are many new ideas in this area.

To conclude, Eurosmart pushes in favor or regulation, in particular at the European level:

• Rules about identity ownership and accountability.
• Data protection as a fundamental right

Such regulations could be interesting, mostly because they would facilitate the establishment of trust between users and service providers, which would in turn make the development of new services, based on that new trust, that could grealty enhance the user experience.

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.

It seems that logical attacks on Java Card are quite trendy these days, as several teams seem to work on them. On the firewall, the idea is here that the Java Card specifications assume type correctness, but that this correctness is not actually guaranteed, because in most cases, bytecode verification is not performed on the card, which means that incorrect applications can be loaded.

The presentation starts with a few compliance tests, of course based on cornercases. They found a few issues, but nothing really bad. It may be possible in some cases to get the type of an object when you shouldn’t, or to use a transient array when it should not be accessible, but in the end, there is no way to get anythingreally interesting done.

The next item is much more interesting. His idea is to create type confusion on files that are apparently correct, simply by using two different definitions of the Shareable interface: one for the client, and one for the server, with different definitions. For instance:

On the client side:

public interface Bad extends Shareable {
  public void doDamage(AID aid);
}

On the server side:

public interface Bad extends Shareable {
  public void doDamage(byte[] ba);
}

If you verify the client with its definition of the interface, and the server with its own version, verification will succeed in both cases. However, the type confusion is obvious. And in this case, the “bad” part is that the AID is a JCRE entry-point object, with high privileges. and this allows an attacker to do bad things. I won’t go further here, but details are available on the slides.

Overall, it is nice to see that Java Card logical attacks get exposed. The potential impact is in practice minimal, because it is very difficult for hackers to load applications in deployed cards (since a GlobalPlatform authentication is typically required). Nevertheless, with NFC and other “open” schemes, the number of downloaded applications is likely to raise quite fast, and the risk of getting malware in the card may slightly increase (developers remain well identified, so the risk is likely to remain low).

This means that bytecode verification needs to be systematically performed, and that this verification needs to be performed by taking into account the actual context in which the application will be exploited. The exploit above is only possible because the server and client have been verified with respect to different contexts.

Recent multi-application projects, such as the Pegasus project in France, have defined strong requirements in this matter, and we are getting closer to exploiting a complete verification environment, which was my first assignment as a Trusted Logic employee, about 8 years ago. Time to get this code out of the closet…

Oh, I almost forgot. Of course, Java Card 3.0 addresses this issue, at least in its Connected edition, where on-card bytecode verification is mandatory.