On the road to Bandol

Java Card 3 applications are mobile applications (strangely enough, they are server-side applications on the mobile). As the launch of Java Card 3 becomes nearer, the deployment of mobile applications should be of interest of people who want to develop and deploy Java Card 3 applications.

Certifying mobile applications is a significant part of my day job, and I am quite confident that this work will continue, for various reasons. First, the most sensitive applications, for instance those related to payment and other money-related stuff, are quite likely to remain certified in a way or another. Then, some applications are “branded” and distributed by operators under their own name, or in packages. For these applications, some kind of certification can be expected, as operators want to guarantee that these applications respect their policies (security policies, but also portability, when applicable, or anything else).

The first Java Card 3 applications are likely to fall into that first category, especially for those that run on a SIM card. Either they will be “traditional” smart card applications (requiring a security certification), or they will be part of an operator program, and the operator is likely to require a third-party’s advice on these applications. However, if we want Java Card 3 to be a success, we need to reach beyond these use cases, and to get new kind of applications in the cards. And then, we get out of the “obviously certified” category of applications.

Some people claim that mobile certification has to go. Their negative arguments are quite good, and also fairly easy to make, as the major certification programs have major flaws, and are not adapted to the mobile application market.

• Formal certification and signature against a fee are very difficult to organize, especially has portability is not obvious and developers often manage (and certify?) tens or even hundreds of different versions. And if we look at the costs there, the management of the certification is likely to be just as high as the fees themselves.
• Most certification programs focus on look and feel guidelines. This is OK for the first years, but on a mature market, we should let the customers decide whether or not they want an application or not.

However, when we look at the alternatives, things are not as obvious. User prompting seems to be the standard solution, but it also has numerous drawbacks:

• Vista has numerous prompts, but it has not solved Windows’ problems. Social engineering keeps working very well on end users, for a variety of reasons, from incompetence to standard greed.
• end users are not really aware of their own rights, and they are often too ready to give away all their rights. As an example, consider the “new” Google Maps on Windows Mobile. Before a download, the user is warned that this application will make a heavy use of your data connection, and that it should only be used with an unlimited data plan; it does not warn the user about the fact that her location will be continuously transmitted to Google when using the application.
• User prompting may be good at protected end user assets, but it does not protect the operator’s assets. In such a case, applications will most likely not be able to access the SIM card directly, as it would give them a way to perform many attacks, for instance a massive denial-of-service attack (a SIM card can be “killed” quite easily with a relatively short sequence of commands). Operators are likely to fight this strongly, and we can already see that the most lax frameworks do not provide uncontrolled SIM access to applications.
• User prompting assumes that an application cannot attack another application. The state-of-the-art in mobile security tends to prove the opposite: the isolation between mobile applications is not very good. As a consequence, some security-minded application providers are not very happy to let the user choose its neighboring applications

The other commonly presented alternative, doing nothing and accepting a PC-like model, is a bit disappointing. Mobile phones are not much under attack, but this lack of interest from hackers is most likely due to a poor Return On Investment (ROI), due to fragmentation. The iPhone is here an interesting example: it represents a significant share of the smartphone market, with a single (consistent) model; it is also much more targeted by hackers than other similar phones. It simply shows that, when the ROI will be potentially good for hackers, they will look at phones.

There are other alternatives that are often overlooked, although they can be interesting in many cases:

• Bytecode verification has proved its worth. Building an attack using Java is quite difficult, because bytecode verification reduces the attack opportunities to bugs in the API implementation (hackers, don’t worry; I am sure that there are enough buffer overflow vulnerabilities in mobile phone software). Bytecode verification can be extended in order to check a few things like API uses and network accesses. This could enable application filtering on the device itself.
• Automated (self-)certification is another possibility. If the certification is based on a well-known set of rules, and if it can be integrated in the application build process, it then becomes a relatively small issue, close to enforcing a no-warning policy. This basically enables self-certification. Even signatures can be generated in the distribution process. This process could for instance be extremely interesting for the iPhone. Since all applications are distributed through Apple, it is possible for them to scan all applications for potential issues
• Application contracts and operator/end-user policies can also be interesting. Applications are associated to contracts (basically, an extended set of permissions), and each handset contains a set of policies, for instance an operator policy (for controlling access to operators assets like the SIM card) and an end user policy (for controlling access to the end-user assets). Each end-user can then have a preset policy, accepting some things and refusing others, and requiring explicit acceptance in other cases. The main issue with this is that it needs to be taken into account in the platform. Still, it could be a nice improvement for Android.

I have been advocating these approaches for years, first in the area of smart card applications, now in the area of mobile applications. These static analysis technologies work, and they are heavily used for server applications. They can also be used for mobile applications.

Finally, to come back to Java Card 3, there are here two ways to look at the issue:

• As part of the problem. Java Card 3 applications are just a different breed of applications, and they will hit the same certification issues. In a way, this would be good news, as it would indicate a high level of acceptance of the technology.
• As part of the solution. Java Card 3 applications are SIM-based applications, most likely under control of the operator, and they can provide security services to other mobile applications. This could ease some of the pains of mobile certification.

To be continued …