Since then, there have been many debates about bytecode verification, and my own position has evolved over the years. Today, my opinion is a bit contrasted, some may even say contradictory. Nevertheless, here it is:

• Bytecode verification has limited use for Java Card runtime security.
• Extended bytecode verification is a very good tool for application vetting.

Let me give a few more details about these two opinions.

Bytecode verification and runtime security

The idea of runtime verification is that it is performed after getting the code, and right before to run it. The code that runs is therefore known correct, at least regarding bytecode execution (unrelated attacks remain possible, of course).

The first big issue with bytecode verification is that, in Java Card, with the split virtual machine model, verification is not performed on the card, but outside of the card, before/during/after converting the application into Java Card’s specific binary format (CAP file). Then, the application is sent to the card over some channel that may be attacked. Here, we rely on GlobalPlatform’s cryptography-based security to protect the integrity of the code. So, basically, we still need to establish trust, and we must say goodbye to the power of running untrusted code from arbitrary developers.

This is not a big issue in practice, because there is no business model that allows arbitrary code to be loaded on cards. However, this causes an organizational problem, as the verification process needs to be well organized. Researchers from Nijmegen and Limoges have shown that it is possible to fool the verification process with fake export files, and then load on a card verified code that will perform type confusion attacks.

Going beyond that, some people have designed applications that can be verified, but have been designed to be attacked through hardware attacks (fault induction, usually). Such attacks, usually known as hybrid attacks, completely fool the bytecode verification process.

Most security experts will then remind you at this point of the discussion that bytecode verification is only one part of the process, that GlobalPlatform is also important, that the origin of code is usually known, that this makes it very difficult to include attack code in an application, etc. By doing this, they are just about accepting the fact that bytecode verification is useless or at best marginally useful: the real security of cards is in the trust between issuers and application providers, and some cryptographic process. Basically, this works because the ecosystems are small enough to be controlled (which is true for cards, and fine for me).

Finally, some vendors claim to have developed defensive virtual machines, which do not require a bytecode verifier, and perform enough runtime verifications to accept any bytecode, good or bad, without any risk. In that case, bytecode verification is really useless, and I believe that it makes things much simpler. Of course, such virtual machines are difficult to design and implement efficiently, but this is definitely possible, and I think that it has been done in the past (or at least that some people has come very close to it).

To conclude, I will get back many years ago. In 2000, Trusted Logic was very proud of its on-card bytecode verifier; the technology worked, but it has not been widely adopted. I believe that the first factor was performance, as verification made the loading and linking process much slower. I also believe that a second factor, less obvious, is that on-card bytecode verification makes the card’s security more brittle, by encouraging VM developers to rely too much on static verification rather than runtime checks (which also prevent other runtime attacks, for instance using fault induction). More than ten years later, most people admit that this was not the way to go, and I just go one step further by stating that bytecode verification is not that useful for runtime security.

Bytecode verification and application vetting

Bytecode verification simply consists of a very simple static analysis of the application code. Basically, this is is a program proof, but a very simple one, whose complexity can be controlled. The objective of such simple proofs is not to demonstrate that a program is correct with respect to its specification, but that this program obeys a predefined set of properties.

For Java bytecode verification, these properties are related to the proper ues of the bytecode instructions. However, the same algorithms can be extended in order to prove many more properties, covering many aspects of application security. Among the things that can be proven, we have the following:

• Method M is not called.
• Method M is not called with arguments A1, …, An.
• Method M is always called before/after method N.
• Method M never throws a NullPointerException (or any other exception).
• Command INS can only return status codes SW1, …, SWn
• Toolkit buffers are only used when they are available.
• and many more.

Of course, there is no magic. When extending static analysis to many properties, it becomes more and more difficult to avoid false positives, i.e. errors that are caused by weaknesses in the algorithms. Put simply, an application is rejected although it is in fact correct.

Apart from working on the algorithms to make them better, there are two ways to deal with this issue:

• Providing the verification tool to developers, together with explanations about the rules to follow. Usually, it is rather simple for developers to ensure that their application can be verified, provided that they can use the tool throughout the development process.
• Use the tool in a vetting process as a guide for evaluators, who then perform additional verifications. In that case, broken rules are considered as warnings, and then verified by the evaluators. Simple applications can usually be verified easily, and more complex verification requires a few checks, simplified by the fact that the most boring tasks are performed automatically.

I believe in both approaches, but the second one has been proven efficient by my then colleagues of Trusted Labs. By using such a static analysis tool, they are able to optimize the vetting process of Java Card applications (and MIDlets, but this is another story) significantly, by allowing them to focus on the the most important parts of the applications.

In addition, this approach allows us to include many more security rules. For instance, hybrid applications must include code that can be modified into attack code through a simple attack. It is possible to build a library of patterns of such code sequences, and to check for them statically. Then, evaluators can be warned of the possible presence of an hybrid attack and check for it. This can be promising, because such checks (very boring to do, but very unlikely to lead to anything) are usually poorly performed by humans.

Finally, extended bytecode verification, or static analysis, has been proven to be a very efficient optimization tool. All optimizing compilers include a static analysis phase to perform their most complex optimizations. Java Card can take great advantage of this, because of the isolation between applications, and also because of the closed world hypothesis that is sometimes possible, when cards are closed (no additional applications can be downloaded).

So, bytecode verification has many uses in Java Card, but runtime security just isn’t the most compelling.

As I try to think about successes and frustrations, it is quite funny to realize that the topics that make me the proudest are also the ones that bring the most frustration, because of this feeling that we could have done so much more.

• The multi-application card ecosystem. When I joined Trusted Logic in 2000, 3 years after Java Card 2.0, I thought that the deployment of multi-application cards was imminent. I wa right for the cards, but the applications didn’t really come. 11 years later, we are still hoping; this time, we are looking at NFC as the technology that will bring real multi-provider multi-application cards later.
• Static analysis. That part remains my lifeline, from my Ph.D. thesis to some work today. The work we did was technically really good, but it fell as a victim of the problem above: the Java Card developer community is too small for tool vendors. The tool is still around, helping Trusted Labs evaluators in their daily jobs.

But more than all this, these 11 years have been a great human adventure, with many wonderful colleagues. Some of them are already gone, some are still in Trusted Logic or Gemalto, but they are the main factor that made me stay so long in the same company. Dear colleagues, I wish you all the best for the future, and I hope that we’ll have more opportunities to work or play together.

I will be taking a few weeks off before to start on a new job, taking the opportunity to get some family time, and hopefully to keep working on the Java Card tutorial, and posting a few things here.

See ya’ll later.

Basically, this attack shares the following characteristics with many other ones:

• Exploit Android permissions. Android permissions are very wide, and labeled in simple terms. This means that there are many ways to abuse people, especially with combinations. In that particular case, the use of two collaborating applications is a way to hide combinations, but it also makes the attack more difficult.
• Use a side channel for leaking data. Some side channels are obvious (like leaking data on Internet together with other data), and this one is trickier. In fact, there is always a tricky way to leak data, especially when you can do it one bit at a time.
• Be a proof-of-concept. This malware works, but only in a lab. In the real world, it needs someone to download two pieces of malware, dial a credit card support hotline, type a credit card number, and do that for another reason then blocking the card. Possible, quite unlikely.

My main claim is that such a malware is quite unlikely to represent any kind of danger. The scheme is so complex that by the time people get credit card numbers stolen, the malware is very likely to be detected. My second claim is that the Android permission system is not worse than the others around: iOS doesn’t really use permissions, MIDP uses overly detailed ones (granted by network operators in most cases), etc. My third claim is that what really count is that the Android Market is able to vet applications; even if it doesn’t do much today, we can rest assured that Google will make sure that 2011 doesn’t become the year of mobile malware.

Nevertheless, the paper points a few interesting things about Android permissions, and some of them could be fixed:

• The Read contact data permission gives access to the call history. I am not sure that I see the need for that. In fact, my main issue with that is that, in terms of privacy control, I believe that it’s very different to know who I know and who I actually call. I believe that this one should be fixed.
• The Record audio permission allows an application to record the content of phone communication (as well as recording audio in the background, actually). In fact, that’s again a privacy issue: an application that records audio while it is the currently running application is fine; allowing that application to record audio from the background is a very different thing, which worries me. This one also deserves to be fixed.
• The side channel actually doesn’t use any permission in most cases, since it uses channels that don’t require any, like setting the volume repeatedly. Here, I don’t think that there is a big problem, because getting data out is most likely not the main problem today. Five years ago, everybody was worried about connected applications; today, most people consider it normal for an application to be somehow connected to the net (for instance, an application can always claim to backup things, to have a social side, etc.). Malware doesn’t need to be bundled with sensitive, intelligent software, so complicated side channels probably represent a futile complexity.

To conclude, a word about hidden communication channels. I have worked on information flow static analysis, and we haven’t found many practical ways to identify hiddne information flows. Usually, these hidden flows do not use variables or communication APIs to leak data. Instead, they often leak a trickle of information using either an unnecesssarily convoluted computation (which is likely to attract the attention of a human reviewer, but is difficult to find for a static analyzer), or by looping on an apparently innocuous API method (this is what is done here, and we may have detected it using a static analyzer).

However, naming 2011 “The Year of Mobile Malware” also entails that this malware will have a real effect on users, and that ‘s where I am much less sure. The main reason for this doubt comes from the use of application stores as the dominant way to deploy applications. The fact that most mobile applications go through the same few filters (Apple’s App Store, Google’s Android Market, and a few more) is of great help against malware, for several reasons:

• Application vetting. On an application store, applications are vetted against a policy. The process depends greatly on the store, with Apple’s process being the most well-known, mostly because the policy it enforces is not compleltely clear, and the process is fully opaque. In all cases, the existence of a vetting process provides a good place to attempt the identification and rejection of malware.
• Application banning. As soon as an application is recognized as malware, it can be banned from an application store, immediately stopping its distribution. This also allows application store managers to analyze the application and enhance their vetting process to better catch similar malware.
• Kill switches. That’s the extra mile after banning, which is (confirmed?) implemented in both Apple’s and Google’s application stores. Once an application is banned from the store, it can be removed or deactivated on all devicess, as soon as they connect to the store (usually to check for updates). This also will lead to a reduction of the impact of malware.
• Other enforcement means. Some people argue that automated kill switches are overkill. Alternatives are possible, which may show up if the amount of malware rises significantly. For instance, once an application is identified as malware, a popup could be used to warn the user and propose the deactivation/removal of the application.

My background is on the vetting process, and more specifically, on the security analysis of mobile applications. At Trusted Labs, I have practiced several types of analysis of applications, including:

• In-depth white-box evaluations. That’s the best kind of analysis, in which the evaluator has access to the application’s source code and related documentation, in addition to the running code. Hiding malware is possible, of course, but it requires significant effort, and it is very hard to use the same technique twice (at least with the same evaluator/lab). However, such evaluations are very expensive, they require the developer to provide source code, and they are basically used only for really sensitive applications, like payment applications.
• In-depth black-box evaluations. Here, the evaluator only gets a copy of the application (i.e., binary code only), together with the user documentation. Usually, such an evaluation is performed in a fixed, limited time, and it relies heavily on the intuition of the evaluator. The process usually starts with some automated analysis of the application, at least a simple one. For instance, knowing which permissions are requested and in which APIs they are used already provides an interesting point of view on the application. For instance, it may help identify an application that requests access to Internet and read access to contact data, and combines them to dump its user’s contacts to a spam vendor. The costs are usually lower than for white-box evaluations, and all necessary information is available in application stores. However, such processes remain expensive, and should be reserved for some applications (for instance, suspicious applications, applications that require sensitive permissions, or high-profile applications.
• Shallow black-box evaluations. In that case, cost is the priority, and the process is likely to be mostly automated. Here, static code analysis is at the heart of the process. Here, the objective is to design an automated analysis with an extremely low rate of false negatives (applications that violate the policy and pass the evaluation), and the lowest possible rate of false positives (applications that follow the policy and are rejected by the evaluation). Of course, the policy must also be flexible enough to allow the most common behaviors to pass the evaluation. Here, the cost of the static analysis is very low, and the actual cost depends on the proportion of applications that need to undergo an in-depth evaluation.

When we discussed malware at the Barcamp, I claimed (live and on Twitter) that static analysis could be effective, and it seems that not everybody agreed with me, in particular Craig Heath, although we reach similar conclusions about mobile malware in 2011.

The basic reason for our disagreement may be the definition of static analysis, and what the target is. Here are a few things about static analysis:

• Static analysis is about analyzing binary code. We want to analyze the code that will actually run on the devices, so let’s not bother with source code analysis: source code analysis is a tool for developers, basically useless in application stores.
• Static analysis is about proving properties on this binary code. The notion of proof is important, as we want to make sure that the applications that pass static analysis actually satisfy all policy rules.
• Static analysis works much better on structured code, i.e., on code on which we have some guarantees, like Java bytecode. We can do really interesting things on bytecode-based frameworks, because the technology is now ready. On native code, the problem is more difficult, because it is much more difficult to prove properties. Nevertheless, technology keeps evolving, and native code analysis is progressing.
• Static analysis should not be fully automated. Instead, it should be complemented by other ways to verify what it wasn’t able to prove. Of course, the a good tool will reject few applications and require llittle human involvement, but it is always necessary to monitor the developer practices and manually approve or reject some applications.
• Static analysis should evolve, or at least the policies it checks should evolve. Policies usually evolve by replacing a very restrictive policy by a less restrictive and more precise one. On the first evaluations I did, a typical rule was “The application should not connect to Internet”; it beecame “The application should only connect to its issuer’s domain”, and then to “The application should only connect to statically defined domains”, to basically no rule (although in practice the last one should be satisfied by most applications, which only connect to a few fixed sites). Such changes follows the current practice, as well as the evolution of trust between users/operators/distributors and developers.

So, static analysis is a way to exploit the adapted Business Intelligence techniques that Craig Heath rightly favors. What I have noticed over several years of using static analysis tools in evaluations is that they greatly simplify the work of a human evaluator, but they have a hard time dealing with two things: very complex applications, and applications that are “borderline” with respect to the policy. Because of that, a human being needs to validate its results (at least, the rejections). As we know, borderline applications often are the disruptive ones, and it is not acceptable to reject them.

In 2011, we will see what kind of malware comes up, but at least on some platforms, static analysis will play a role in the application vetting process, making it much more efficient on the simple applications, and allowing evaluators to spend more time in the vetting of sensitive/complex applications. And in the end, the infrastructure is quite likely to win the fight with very limited impact on the end users. So, like in the past 10 years, we are not yet on the year of mobile malware.