I only did a few risk analyses, but it taught me at least one thing: it can’t happen is never a valid conclusion, because every risk analysis includes some hypotheses. These hypotheses usually seem very reasonable, but the probability that these hypotheses can be broken is never 0. This means that the actual conclusion is

It can’t happen with the hypotheses considered in the present plan; however, in the unlikely case where these hypotheses are wrong, our analysis cannot give any guarantees

It doesn’t sound as good as the simplistic It can’t happen, but it is the truth. The problem today with out leaders (and more generally without society) is that we love our plans, and this entials many bad behaviors:

• Completeness assumption. When there is a plan, we have a tendency to assume that it covers all possible cases. We will also try to maintain this belief as long as possible, even after getting strong hints that our hypotheses are wrong.
• Irresponsibility outside the plan. When something happens outside of the plan, leaders fail to take responsibility for it. Statements like It is an act of God, or It was impossible to predict are typical examples of such irresponsibility. However, we would expect the exact contrary from a good leadership: we need them most when things go out of the plan. However, improvisation is hard, and nobody wants to try that.
• Reluctance to update the plan. The last point is that, even when the plan has been proven wrong, there is strong reluctance to update it. Engineers are not too bad here: nuclear engineers around the world will update their plans after the current disaster. Politicians are not as good: for instance, they failed to update the plan after the 2008 economic crisis, although it has proven that some of their hypotheses were wrong.

What can se do about this? We are not going to solve the world’s big problems, but we can try to make opinions shift in the right direction. First, by getting information; I have recently heard on the radio a very good interview with Patrick Lagadec (a risk management professor, who wrote a recent paper on these topics) who went much deeper than I did here and definitely helped me structure my thoughts. Let’s make sure that we share this information.

Then, we can apply it on our daily lives. This applies even more to the security community, where risk analyses are common. The point is that, beyond having a plan, we need to be prepared for action when facing a situation that is outside of the plan.

I can take one personal example, around Java Card. Java Card is perceived as a highly secure technology, and we have good plans in place to guarantee this, including Common Criteria evaluations, sharing of information regarding the latest attacks, etc. However, the plan doesn’t include any provision for the (unlikely) case that a Java Card weakness ends up exploited by attackers in a way that leads to major public exposure. Individual companies have plans for such situations, and they are likely to have crisis management procedures; however, the synchronization between the companies could be much harder to achieve. I will check on that in the coming months that the Java Card Forum can react safely in a crisis.

Finally, I would like to express my sympathy to people in Japan who read this, and my solidarity to all of those who are struggling through the currently unfolding crisis.

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.

But nobody ever used it. Nobody.

Why so? Because it solved the wrong problems. My passion at the time was to make developers’ life easier, and this passion was shared by many other members of the original GemXpresso team. We believed that making smart card application development available to many developers in a simple way would necessarily generate the next “killer app”. Of course, it didn’t, because the problem is not with the developers.

A smart card is not the Internet, and the next killer app will come from somebody who has a great idea about a novel way to establish trust between two entities, or something like that. And that guy will then subcontract the development to one of the happy few guys in the world who know how to write good Java Card code, optimized and secure.

So now, Java Card RMI mostly represents a few kilobytes of dead code in every Java Card on the market. Maybe that one of your cards is able to do RMI and you don’t even know it. Don’t worry for the future, the designers of Java Card RMI are still very much involved in the design of Java Card 3. We will most likely make a few mistakes in our design, but not this one.

To end with a happy note, it has been said that Java Card 3 would be fully backward compatible with Java Card 2.x, and it most likely will be true. Java Card RMI will then lie dormant in many more cards of the next generation. And maybe someone will use it.

The article discusses the fact that, when a plane crash occurs (at least in France), two investigations take place: an administrative investigation, which focuses on the technical aspects of the crash, and a judiciary investigation, which focuses on the legal aspects. In that particular case, the administrative investigation lasted 2 years, and the legal one 14. The author, Jean Paries, who headed the administrative investigation, claims that the legal investigation did not identify any new element, because the administrative investigation was very thorough and left no element behind.

Of course, this point is open to discussion. However, it is not his major point here. His major issue is that that there is a systematic legal investigation, in parallel with the technical investigation, and that the prospect of legal consequences makes the parties involved more careful about following the rules than willling to really improve security.

The first issue he mentions applies mostly to legal investigations. The airline industry traditionnally tries to identify vulnerabilities in a proactive way, not waiting for an accident to take action. However, since there is always a delay between the detection of an issue and the corresponding action, companies expose themselves to the accusation of “You knew it, and you did nothing about it.” The temptation is therefore quite strong not to perform any proactive action.

Similar issues may occur in security evaluations. If a card manufacturer knows about a vulnerability, they may not be encouraged to do anything about it, because the laboratory (in particular in a white-box evaluation) may then identify the countermeasure, “reverse engineer” the attack, and apply it. In that case, the temptation is to keep newly identified vulnerabilities secret as long as possible, rather than include protections in products as soon as possible. The second issue applies more generally, and in particular in the context of security evaluations. Here is a rough translation of the argument:

In any complex, and therefore incertain, system, risk management is based on a principle of individual responsibility. We expect from each individual, proportionally to its competencies, an understanding of the situation and of the consequences of their actions, and decisions based on the ethics of security that is one of the foundations of their job. Making individual failures a legal issue is intended to increase the conscience of this responsibility. It has exactly the opposite effect. The priority of each individual is not to manage the risk professionally, but to minimize their personal risk of indictment. The personal responsibility is replaced by the responsibility toward law enforcement. The culture of security is undermined by self-protecting attitudes, generalized caution, dissimulation. And most of all, the inflation of regulation.

This is of course where similar issues occur in security evaluations. The overall objective of a security evaluation should be to regularly increase the overall security of systems. Instead, most evaluations are performed against a predetermined checklist. In such contexts, the creativity of evaluators is not encouraged. If an evaluated manufacturer want to discard a vulnerability, they will not claim that “this vulnerability is not significant, because it cannot be exploited.” Instead, they will claim that “this vulnerability is not included in the requirements document.” In such a case, we witness the same shift from an objective of security improvement to an objective of regulation enforcement.

The issue is of course that regulations cannot evolve as fast as the state-of-the-art attacks. The situation of the smart card industry is in that respect quite unique, because there is no notion of full disclosure in the industry, and it is therefore quite safe to rely on regulations that are not regularly updated. This may last for many more years, but it my also stop quite rapidly if attacks start occurring in the wild, and smart card attacks gather more interest from security professionals.

In the GSM world, things are different, and there are many more applications: some operators have developed hundreds of applications. However, the number of applications remains very small. The main difference is of course that end users cannot choose the applications on their cards, that they cannot load applications freely, and of course that they cannot develop applications on their cards.

Such a market is extremely hostile to developers. Most applications are developed by the smart card manufacturers, rather than by independent software vendors. This means that the main motivation for these applications is to sell smart cards and associated services. In addition, the teams thinking about new applications and business models are all from the same school of thinking, which does not help.

We can hope that the model will change in the future, at least with the next generation Java Card platforms. But we need to remember than it is not very useful to get Java Card closer to mainstream Java (and Java developers) if application deployment model is not accessible to these developers. In the meantime, don’t expect millions of Java Card applications. A few hundreds will do, and few people will know about them.

• Issuers with higher security requirements may have less choice, since fewer products meet their requirements. In addition, they can expect higher prices. If no attack occurs to support the requirements, the position is difficult to sustain business-wise.
• High security requirements globally raise the price of smart cards, and may favor competing technologies

The issue therefore becomes to figure out which level of security is required, which is not an easy task. It basically depends on the available vulnerabilities, and on the level of risk that is acceptable. We can consider the current situation in three vertical domains:

• Pay-TV. In this field, the level of vulnerability is quite high, in particular because the cards are usually offline. The same content is broadcast to all customers, and the card is used to make this content available. The level of acceptable risk is quite high, since it only represents a loss of business. Nevertheless, the security requirements are high, most likely the highest in the smart card market. The reason is that the Pay-TV industry faces organized attackers, with a sound business model (make fake cards and sell them).
• Banking. In this field, the level of vulnerability is average, because the transactions performed with cards are verified in the backend. The level of acceptable risk is low, because banking card fraud usually implies stealing money from somebody. However, there have been very few actual attacks on banking smart cards, and it is therefore difficult to assess the profile of potential attackers. The level of security remains quite high, but it varies greatly from issuer to issuer.
• Telecom. For SIM cards, the level of vulnerability is quite low, because all cards are connected constantly, and many verifications are performed at the network level. In addition, the level of acceptable risk is quite high, since the main attack considered consist in using the network for free. The level of security for SIM cards is therefore quite low.

This all looks quite nice and consistent: Pay-TV operators are paranoid because they are under constant attack; bankers don’t take risks; telecom operators favor performance until a problem occurs. The problem is that the situation may not remain like that forever, and smart cards are not like Windows: generally, no patching is possible after issuance. Banking cards are often issued for two years, but products can be issued two or three years after their initial certification: this means that the products must resist to attacks available four or five years after their certification. The issues are similar, or even worse in the other domains: SIM cards are usually never changed, unless you switch operator, and pay-TV operators are reluctant to change their cards because of the cost. Overall, it is reasonable to believe that smart card products should remain secure for at least five years. So let’s take a quick look at what the markets will look like five years from now:

• Pay-TV. In this field, things may look a bit better. First, set-top boxes are more and more likely to be connected (think of all the people receiving TV through DSL), which means that controls are possible on the network. Then, there may be some diverification, for instance through Mobile TV, which is also connected. In both cases, the security requirements may go down. Of course, standard satellite/cable products may still be vistims of organized fraudsters.
• Banking. One reason why banking smart cards are not attacked is that it is so much easier to attack magstripe cards. Once the migration to EMV smart cards will be more general, there will be less magstripe cards to attack, and smart cards may become interesting targets. If attackers find good business models, they can hire the guys who used to crack Pay-TV cards and do some damage.
• Telecom. With convergence, SIM cards are becoming multiapplicative platforms, and they may host things like mobile payment or mobile TV applications. Of course, they will remain connected, but attackers may discover business models that use the SIM card without trying to make free calls, and this is likely to increase the level of risk.

Overall, it is very difficult for issuers to figure out what level of security requirements is requirred, and it remains an individual decision. Every company has security guys rambling about upcoming catastrophies, and business guys rambling about useless security measures. However, very few take the time to frequently review their security requirements, and more importantly to confront them with their five-year business plan. So the definition of security requirements will remain a guessing game, and vendors will have to complain again.

The main differences between Java Card and a native operating system are not related to Java, but to the its basic properties. A Java Card card is programmable, interoperable, and to a lesser extent, open, and the consequences of these properties are significant:

• Programmable. In Java Card, it is possible to load code into the card. There are other systems in which this is possible, including proprietary ones (a few years ago, it was possible to dynamically load SIM Toolkit applications in many proprietary SIM cards). Naturally, this ability includes a lot of risks, in particular since it allows attackers to load their own applications on the cards they attack.
• Interoperable. A Java Card application is supposed to behave in the same way on all Java Card implementations. This property is interesting for issuers, and also for attackers, who may be able to reuse the same attack on different platforms.
• Open. Java Card is not completely open, since the source of its reference implementation is not available to the general public. However, this reference implementation is available in binary form

Then, there are a few additional properties of Java Card that may make it less secure:

• Complex. Java Card is complex, and complexity is not good for security. However, the core security measures in Java Card are not that complex, and the risks are mostly functional.
• Available. For many vendors, it is far easier to buy a development kit for their Java Card implementation than for their proprietary cards. Attackers therefore have more opportnity to get cards to prepare their attacks.

All these reasons seem to imply that Java Card cards are less secure than native cards. But of course, they also imply that a Java Card card offers many more possibilities to issuers, for instance post-issuance application loading, and a relative independence from the manufacturer. In addition, these reasons also imply some advantages:

• Programmable. With Java Card, applications can evolve independently of the platform. This may allow an application provider to strengthen the security of an application aftr its issuance. Even more easily, the deployed application can evolve at a rapid pace, without requiring new masks at each iteration.
• Interoperable. Since application are portable, some countermeasures can be implemented at the application level. For instance, redundancy countermeasures are difficult to put in place. Developers are more likely to do it on portable code, because they can monitor the amount of work to be performed
• Open. The Java Card specifications have been refined for years, and the core specifications now take into account minute details and minor security issues. These specifications have also been reviewed in great details by security researchers. Some issues were even identified while building a formal model of the Virtual Machine.
• Complex. The complexity of Java Card also means that subtle things are possible. For instance, the sharing model is complex, but it also make possible interesting collaboration schemes between applications, while keeping a high level of security.
• Available. The large availability of development kits does not apply only to attackers, but also to students, security researchers, etc. This openness is good for Java Card.

The conclusion is that the above statement is not generally true. A card that includes Java Card also includes a few additional vulnerabilities, but they are well-known, and countermeasures exist for most of them. And in many cases, these vulnerabilities are balanced by the possibility to upgrade the application code more frequently.

I would therefore propose a few different statements:

• Programmable systems include more risks than closed systems.
  This is the one that Java Card foes use most, by confusing the general properties of programmable systems with the specific properties of Java Card.
• In the long run, open systems are more secure than proprietary systems.
  This issue is not specific to smart cards. For security, openness, experience, and peer review do help.
• Java Card is the most secure programmable system available for smart cards.
  This is of a personal opinion, most likely not shared by Multos people. But I believe that the amount of work put in the develoment, securization, and evaluation of Java Card systems largely surpasses whatever its competitors, including Multos, have done.