Category Archives: Security

Topics about the security of Java Card programs, and more particularly about the possible countermeasures.

Fault induction for dummies

Yesterday, I gave a talk at the SIT Smart Card Workshop in Darmstadt, a German conference on smart cards. It was my first appearance talking about Java Card 3, and the presentation was prepared on short notice. Still, there was a great welcome, although not everybody was convinced that this move was realistic. We’ll get

Should we deprecate DESKey.getKey() ?

The DESKey.getKey(byte[], short) method definitely is one of the most controversial methods of the Java Card 2.1 API. This method is quite simple; as stated in its description, it “Returns the Key data in plain text”. This definition is of course a nightmare for smart card security people: not only does it access the value

Open Source or Security through Obscurity ?

I strongly believe that keeping things secret is not a good idea, and that security cannot be achieved through obscurity. There are many convincing examples of this, even in the smart card industry. The infamous GSM algorithms are a perfect example: cryptography using secret algorithms is a bad idea, because the algorithms get broken. Following

Cards are OK, but is Chip & PIN OK ?

A significant part of my job is to evaluate the security of smart cards, in particular in the banking sector. The level of security achieved in today’s card is definitely quite good, and getting a PIN out of a banking smart card remains a very difficult task. Nevertheless, the latest paper of Cambridge’s research lab

Defensive virtual machines

The notion of defensive virtual machine is a bit awkward. The official presentation of the Java (Card) Virtual Machine describes it as inherently secure, so the notion of defensive is a bit contradictory with this message. In fact, the notion of defensive virtual machine is the result of a long process: Virtual machines usually present

Cloning e-passports

Bruce Shneier has pointed to another article on the security of e-passports. This one focuses on cloning, but contrarily to a previous article, which simply mentioned that cloning was possible (which is natural, since nothing is done to avoid it), the authors now look for ways to actually exploit the cloned passports. The ideas are

An efficient sensitive section API

e-Smart, day 3. Benoît Gonzalvo is from Gemalto’s security group, and he also participates to the Java Card Forum’s security work. The issue is to protect against attacks (side-channel observation or fault induction) [Gon06]. The two current approaches are: Protecting the whole VM, which is secure but potentially very slow. Protecting the application code, which

Designing chips against fault induction

e-Smart, day 1. The title of the talk by ST’s Christophe Tremlet was very appealing [Tre06]; the talk was interesting, but a bit under my expectations (the problem is not completely solved). Nevertheless, Christophe gave a very nice and interesting presentation of fault induction attacks, showing the different parameters that can be acted upon at

e-passport security

There have been several posts on Bruce Schneier’s blog about e-passports, including a recent one. Bruce’s views are interesting, and he raises interesting issues about RFID on passports. On the other hand, the comments posted on this post and related ones, show that there are lots of misunderstandings about the technology. Of course, this is

Java Card cards are less secure than native cards

This argument is often used by Java Card foes, often in conjunction to the “Java Card is slow” argument. The statement is effective, because most people don’t even bother to look deeper into its meaning. Here, we do not look at detailed figures and analyses, but we do look at possible reasons why this statement