Proving programs is hard, but the hardness of the proof greatly depends on what you want to prove. We can split proofs in two groups:

• Proving generic properties on programs. In that case, we are simply trying to prove that a given program (for instance, a Java Card program), satisfies a given property. This can be very simple. For instance, the property “The program does not use sharing” can be proven simply by ensuring that the program does not refer to any shareable interface. In such a case, a syntactical check (which does not look at all at what the program actually does) is sufficient. Sometimes, the proof is not as simple. For instance, the property “The program only sends SMS’s to French phone numbers” (on a MIDP program) is more complex to prove, because it requires an analysis of the data used by the program. In that case, the prover needs to simulate the way in which the program works in order to figure out all possible phone numbers that can be used to send SMS’s, and then analyze that. In that case, a semantic check (which somehow looks at what the program does) is required.
• Proving that a program actually implements its specification. Now, this is the hard part. The first difficulty is actually to write the specification in a way that can be understood by a prover (i.e., a formal specification). Many languages exist to do that, and they are quite complicated. On Java Card, a famous result has been to prove that the verifier actually does its work and guarantees that programs run safely. Multos also had a similar result, in which they proved that running a program was safe(memory-wise). In both cases, it resulted to high-level security certifications (good for publicity and marketing).

Now, how useful are these results?

The first kind of proof is called static analysis. We actually think about using this technique in the deployment of certified NFC applications, because it allows us to prove that an application does not interfere with other applications. And we also have been using this technique in the security evaluation of applications for years. Its main advantage is that is works on binary code, which means that it integrates easily in a signature scheme (a program is signed only if static analysis succeeds).

For formal proofs, we are not as close to direct exploitation. In the case of Java Card, it resulted in the discovery of a few interesting bugs in the specification of the Java Card Virtual Machine and API, which have been fixed in subsequent releases. This often occurs, as the construction of a formal specification forces developers to look into minute details of the spec, which often happen to be the source of issues and bugs.

In quite recent news, an Australian team (NICTA) has announced that they have built a complete formal proof of an operating system kernel, which could be used in mobile devices. This piece of software represents 7500 lines of code, but the formal proof represents 200,000 lines, and it took 4 years to a team of 12 people to build it. Even if they didn’t work on this full time, this means that we are not going to see such proofs on a daily basis. However, this could become more common, because of the side results of this work, as explained by its leader in the press release:

“This work goes beyond the usual checks for the absence of certain specific errors. Instead, it verifies full compliance with the system specification. The project has yielded not only a verified microkernel but a body of techniques that can be used to develop other verified software.”

Hopefully, we will see more of it, since proving programs can definitely lead to more stable programs, and we need that.

Another good news is that the technology is apparently open source, and that it will be transferred to Open Kernel Labs, a well-known Australian company in the field of mobile hypervisors.

Once again, it reminds us that mobile security is a hot topic, and there is still hope that our mobile devices will not become our next PC platform, ridden with vulnerabilities and malware.

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.