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 forces reliance on potentially less experienced developers, may reduce application portability, but can be adapted easily for new attacks.
The idea of the talk is that the application code level is the appropriate one to identify sensitive sections, and the platform code is the good level for implementing protections.
The proposed solution is to design an API that makes the platform enter a secure execution mode, which performs additional checks on data operations (preserving intergruty and/or confidentiality), or code operations (preserving the execution flow).
There are two elements in there:
- A secure execution mode, in which additional checks are performed.
- Secure objects, in which content accesses are secured through additional checks. The secure properties, however, do not propagate through the object graph: only the fields of the object are protected, and not the objects referred by it.
Of course, Benoît gave a lot of details, in particular about the relationship of these two elements.
In practice, the idea is to use Java annotations. It is easy for methods, which can be tagged as sensitive, with some qualifier (integrity, confidentiality). For objects, things are more difficult: tagging the classes is not very satisfactory, in particular because API objects cannot be made sensitive. Another option is to tag some methods in order to tell that any object created in this method will be sensitive.
The use of annotations is interesting, because it then becomes possible to increase the security of an application without modifying its code: it can be done by a security team, or it does not require any retesting after strengthening security.
There are still many details to be ironed out, and implementation may not be that easy. In particular, inheritance will be a major pain. nevertheless, the idea looks great, because it addresses one of the major problems that we see in today’s evaluations. Together with better defenses against fault inductions at the hardware levels, we get closer to a solution.
This “Sensitive API” raises interesting questions about the security we get, as application developers. If we declare a code section as “sensitive”, what is going to happen at the OS level exactly? Which protection do we have? What about the rest of our application? To which point is it secured since we didn’t ask for it?
Anyway, the situation today is not better. We have no way to tell what needs to be secured and what doesn’t. But we are still unable to answer the questions above. We can suppose that a JC2 VM secures all our application, but what does it do exactly? Does it use checksums? Random delays? We don’t know.
I remember that in Windows95, it was not possible to choose the clusters size of the FAT file system (as far as I remeber, it was 4096 bytes). Starting from Windows98, it became possible. The first time I saw the combo box offering 1024, 2048 and 4096 bytes, I didn’t know what to do. Small clusters are good for space consumption. Big cluster are better for performance. In which extent? I really didn’t know, and I think few person in the world would have been able to take a truly wise decision (my hard drive was only 1.2 GB at that time). Maybe I would have prefered not being asked. Although Windows95 was not more qualified than me to choose (was it?), at least I wouldn’t have responsible for the consequences. Stupid, and human.
Back to Java Card. What may change is that for the first time, the application developer is asked for the low-level protections he needs. He won’t know what to answer unless he is told what is behind exactly. And the JCF (I guess) will have to explain.