Looking at this from a Java Card point of view, the main question is to understand the limits of Java Card. Should it be just a smart card framework, or a more generic security framework? Are there good reasons to use or not use Java Card on a particular kind of security framework? That’s what we explore in this last installment of my farewell to Java Card.

What makes Java Card good?

Or in other terms, “what’s the value of Java Card”? Java Card is a security middleware framework, which presents a portable interface to security functions typically provided by smart card hardware, and it is valuable because:

• It allows the development of reference frameworks (such as the SIM toolkit framework), and of reference applications (like Visa’s payment application), which can then be made available on all Java Card-compliant devices.
• It provides to developers a security framework that is relatively easy to use, where all the key functions (cryptography, authentication) are already implemented and available with predictible qualities on many commercial platforms.
• It includes a full ecosystem, including laboratories and certification authorities that are specific to the security community.

That may not sound like much, but when it comes to programming security environments, this combination is quite unique.

What can Java Card run on?

That may first sound as a strange question, unless we reformulate it as “Beyond smart cards, what can Java Card run on”?

I have stated for quite a while that Java Card is suitable for any dedicated security subsystem. Such subsystems obviously include all kinds of smart cards and secure elements. Now, what about other security subsystems:

• In preparation for the deployment of eUICC, mobile chip vendors are getting ready to integrate a security element within the main mobile chipset (as they do with all new promising technologies). Here, the idea is to include secure hardware, similar to a secure element’s, and to use some kind of TEE to protect its access. This kind of security subsystem is quite obviously a Java Card target, at least because it will most likely need to support the SIM Toolkit Java Card framework.
• Going a step further, Java Card could run on any Trusted Execution Environment. Some experiments have been made, showing that Java Card could be successful in that area. The debate is here whether this extension of Java Card’s realm represents a risk (for the smart card/secure element industry) or an opportunity (for the security subsystem industry).
• Going even a bit further, Java Card can run on any system that offers virtualization and the ability to have a dedicated security VM. This could be very useful in particular for low-cost devices, where it doesn’t make financial sense to include a secure element or even a full-fledged TEE. Note that such a dedicated VM could still achieve a good security level, by leveraging hardware mechanisms like TrustZone (now available even on Cortex M cores), or software mechanisms like formally proven software stacks.

Note that such extensions could require an evolution of the Java Card platform, at least because the memory model of these chips is different from the model used in secure elements. In addition, some additional features may be required.

What uses for Java Card?

The final step is to combine the value of Java Card with these opportunities: How can Java Card bring significant added value in these areas? We can take a look at a few use cases:

• On mobile devices, eUICC is likely to be a game changer. The combination of secure element technology and TrustZone in a mobile processor allows the implementation of UICC-like functionality, and the flexibility required to manage the environments provided by several network operators can be easily addressed with Java Card, since most operators already use the technology and have applications ported to the platform. In addition, this secure environment could be leveraged in other ways: (1) the TEE is not clearly established today, so it could be replaced by this environment, which offers similar or higher security features; and (2) this secure environment could be leveraged to host the applications that run today in the mobile device’s embedded secure element, if implementers are able to prove that they can reach the required security level.
• In the IoT market, the opportunity is to address the security of endpoints (the things). This market remains wide open, with no established standard. Most actors also have limited security know-how, and development cycles are very short. The Java Card ecosystem can here prove to be an essential competitive advantage, as it is relatively easy to develop Java Card applications and evaluate their security. Yet, in this market, we are missing a category of actors that would build the basic security services and a framework to deploy them easily on top of the existing Java Card and GlobalPlatform frameworks.

I am sure that there is more, but these two markets represent the major opportunities available today.

Long live Java Card!

Java Card technology has dominated the smart card industry for a while, and it now faces the same challenges as this industry, which may also be a great opportunity. Security is becoming a priority in areas like mobile phones and IoT, but secure elements are being challenged by new technologies for the implementations of security subsystems.

Java Card has the ability to be one of the technologies that will bridge the “old” smart card world with this new world, and I will close this series by wishing the best to the Oracle, the Java Card Forum and the entire Java Card community, hoping that they will be able to seize this opportunity and keep Java Card great for many more years.

With iPay, Apple just proved to many people that mobile security can have a favorable economics. By embedding a biometric sensor and putting their critical credentials on an embedded secure element, they have been able to negotiate a lower transaction fees on their payments and save millions in the future. Mobile security brings millions instead of just boring geek stuff? Now, that’s innovation.

Of course, the security of the iPhone 6 must live up to these high expectations. As much as the latest announcements bring a boost to mobile security, the announcement of a hack allowing a guy to steal a phone and use it “illegally” has the power to bring us back to the dark ages.

The reasoning goes on with a comparison of the security merits of a credit card number stored on Passbook and a real card. Read the paper for the details, but an obvious comparison is that a real card is easier to lose/steal (because we stick to our phone more than we stick to our wallet), and also easily accessible (the phone will be at least somehow encrypted, requiring some technical skillls to access the card numbers). In addition, credit cards are easily replaceable, and they usually entail a zero liability insurance for the end-user.

What surprised me is the conclusion: “convenience wins in the consumer mind”, and more specifically, “convenience may win out over a little risk”. From the risk analysis, my feeling is that using Passbook is actually less risky than carrying real cards, and even if one doesn’t agree with that, zero-liability means that, for the customer, the risk is the same: zero.

Although we agreee that security is a way to reduce risk globally, there are many different ways to reduce risk for every actor. For the end-user, in that specific case, the key aspect is the zero-liaility insurance offered by the credit card company. If there is a major security flaw in Passbook, there may be a problem between Apple and credit card companies, but end users should remain largely unaffected. The worst thing that could happen to them is to lose the convenience of Passbook if credit card companies deny to Apple the right to store card numbers in it.

Just another friendly reminder that our job as security providers is not just to randomly increase security of things, but to actually reduce the level of risk for an actor, which should be our customer. Banking smart cards are sold to banks, not to end users, and there is not reason to change this relationshp when the cards are dematerialized into software: our customers are the banks, and we need to reduce their risk (which, hopefully, can help them offer a zero-liability insurance to their customers at a better cost).

Disclosure: I just finished reading Brice Schneier’s Liars and Outliers: Enabling the Trust That Society Needs to Thrive, which may explain why I have this unusual high-level view of security. Good book, by the way.

The fun part is of course that the FBI is now going after Google to find a solution to this problem, asking them plenty of information about the device and about the use that the bad guy did of it. Most of the things that they are requesting may indeed be in Google’s hands, if the bad guy is not very smart: e-mails, text messages, Web history, contacts, etc. Unless of course, the bad guy has been using non-default apps.

But it gets even more interesting when we get to the part asking for “Verbal and/or written instructions for overriding the ‘pattern lock’ installed on the” phone. Since this is a Samsung phone, does Google have this information? What if there is no way to override this? I am not sure that the people who design security protocols for Trusted Execution Environments and/or for Secure Elements actually include a backdoor everywhere. After all, in some cases, not having a backdoor makes security easier to enforce. Of course, in this particular case, the pattern lock can be overridden by the owner’s Google account, so I guess that Google has the information.

But, in a more general term, it brings us back to the question of the “right” security level. If there is an open market for TEE/SE applications, the “superlock” application definitely sounds like a good one. It will certainly benefit our privacy, and it will just as certainly annoy anybody who wants to violate someone’s privacy, with the same debates as usual regarding the limits of the law. I am not completely sure where I stand on this, since I don’t like the idea of letting police look at my information, but I don’t really like the idea that my wonderful security products are used by bad guys to protect their content from police Of course, we can trust most bad guys to be like regular guys and make blatant security mistakes, but sometimes, it just won’t work. Oh well, we’ll see, and it should be interesting.

The NFC Forum has recently added the possibility to include a signature record in tags. Adding such a signature can be used to ensure that the content of the tag (say, a URL) has been written by the person who sign it, and not modified afterwards. OK, so what does such a signature really bring in terms of security?

Well, I must admit that I am not really sure. Of course, one of the reasons is that I am yet to see a phone that verifies these signatures; I may also not have all the information. So far, I have read the NDEF spec, and the thesis by Markus KilÃ¥s on this topic. So, let’s say that this entry will get modified at some point.

Let’s continue with the URL example, on a very simple, innocuous example: a tag in Nice that contains a URL pointing to explanations about the Ste-Reparate Cathedral. If this tag is signed, then we can expect that a mobile phone would verify the signature before to forward the URL to the browser. However, the mobile phone would also be able to read unsigned tags.

Let’s now consider the two main attacks on this kind of tags:

• Cloning. The entire record can be read freely, so a signature doesn’t protect at all against cloning. A Nice supporter may be able to put a Ste-Reparate tag on a Notre-Dame de Paris poster.
• Tag replacement. The signature does not protect against this. If a Paris supporter comes to Nice, removes the Ste-Reparate tag and replaces it with a Notre-Dame de Paris tag, this will work with a browser. Of course, the phone may display a small “Trusted” icon for a recognized signature, but unless all tags rapidly become signed, I doubt that users will notice this icon any time soon.

So, my conclusion is that signatures are likely to be useless for this URL use case, at least before the industry reaches a global agreement on a way to define how signatures should be handled on phones.

Of course, signatures may still be very useful in proprietary applications, which may be used in the industry. In such cases, the signatures will be verified by a specific application. In that case, it would solve part of the tag replacement attacks, since it would mean that a tag from a given company could only be replaced by another tag from the same company (or a clone of it). This means that a good level of tamper-evidence will also be required.

Not really good looking so far, but if I have missed something, I would be really glad to update this to something more positive.

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.

• Personal. Mobile phones are becoming some kind of personal hub, on which all communications means are concentrated, in particular around social networks. A teenager’s mobile phone is likely to be the electronic device she uses most throughout the day.
• Universal. Everybody has one. In some countries, this has been a reality for adults since a few years, but it has now expanded to most of the world, and in developed countries to most kids 10 years old and over. The trend is easy to see.
• Connected. By definition, a mobile phone is connected. Internet connections are becoming more and more common, almost universal in some regions of the world. And in other regions, the SMS medium is available and used for a wide variety of services.
• Generative. Mobile phones generate content, from pictures and audio/video recordings to positioning data and movement information. More sensors are added regularly, endlessly increasing the device’s awareness of its operating environment.

All of these features, when put together, make us realize that mobile devices are becoming ready to be used in our everyday life to establish a bridge between the real and the virtual world. As Google’s Eric Schmidt commented when discussing the addition of NFC connectivity to Android, “these things are so highly personal and (…) location-aware” that we now need to think “mobile first.”

What excites people like Eric Schmidt about mobile phones is the ability to accompany the consumer throughout the buying decision process, until the final transaction between a consumer and a merchant. This ability to conduct transactions in the real worldis the main difference between a mobile and a desktop.

And of course, as we start talking about transactions, money becomes involved, and trust becomes an issue for all stakeholders. If you consider Internet payments, banks and vendors have recently introduced additional verification methods in order to restore trust. Similarly, a significant percentage of Internet users remain afraid on shopping on Internet, often because they don’t want to disclose their credit card number.

The challenge for mobile trust is to address these issues better, designing a solution that allows the establishment between stakeholders, in a way that is trusted by all these stakeholders. This challenge is not an easy one, but some systems are emerging with partial solutions, that we can use to illustrate the design principles.

The first example is the M-Pesa mobile financial system used in Africa. It allows individuals to exchange money using their mobile phones in a very simple way, providing a financial infrastructure to countries in which banks are rare.

The second one is the Bump application, which allows two individuals to connect (or agree on a transaction’s terms) by simply bumping their phones together. This is a simple, straightforward technique, uses the generative capacity of a mobile to bridge the real and virtual worlds.

Now, here are the design principles:

• Make mobility matter in the real world. Mobile trust is not about simplifying the entry of credit card numbers by selecting a virtual card in a mobile wallet. It is about using the qualities of a mobile to establish trust between two individuals, like Bump does, or between an individual and a (local) service provider.
• Focus on the details of the actual service. Mobile banking is boring. Mobile money transfer between individuals already sounds better, and it sounds even better with the detailed description of a very simple mechanism, like the M-Pesa process. So, let’s be specific and work on the details of the user experience very early in the design process.
• Put the human at the center. Trust is essentially needed between humans, and the process necessarily involves humans. So the human must be at the center. First through the user experience, making sure that our service is usable, without cumbersome steps. Second through our brain and psychology, using our intelligence and intuition in the trust establishment process.
• Design around trust, not security. The essence of a transaction system is to establish the trust between two entities; the result is the trust relation, not the security. And we must always remember that the very definition of trust is to reduce the security measures once it is established.
• Build it securely. Last but not least, we need to deal with the implementation. That’s where security becomes important, making sure that we are able to build a system that matches our security assumptions. The main difficulty is here to correctly assess the level of risk, and to choose the security measures accordingly.

This is the recipe for success in mobile trust. All we need to do now is to define a list of ingredients, in order to bake a tasty and tangy mobile transaction service. Of course, we’ll also need to sell our produce, but that’s another story.

On the technical side, these financial applications are all SIM Toolkit applications. This means that the applications are actually running on the SIM card, simply delegating the interaction part to the mobile. The interface with the remote servers is usually performed using SMS. Of course, this is a financial system, so the level of security must be sufficient to reduce fraud to a minimum.

Among the features that contribute to the security of the system, we have:

• Private network. Mobile networks are private, which makes them more the information that circulates on them more difficult to attack than the information that flows on Internet.
• Application running on the SIM, with some cryptography. SIM cards aren’t the most secure smart cards, but getting access to the data stored on a SIM card remains a long and difficult process, even for card evaluators. So, stealing/forging keys is hard.
• SIM Toolkit driver buried deep in the phone’s software. Since the application logic is on the SIM card, the mobile phone only provides a generic driver that manages the user interaction. This driver is handled by the phone’s baseband processor, which is usually not the most accessible piece of software. As a result, it is difficult to attack this interaction

Don’t get me wrong; I am not claiming that the system cannot be attacked. I am just claiming that the inherent security properties of SIM Toolkit applications are sufficient to guarantee the security of the small data transfers performed daily in developed countries. Now, if you want to use that system to buy a €500,000 house, I may want to take a very different stand.

Actually, the main reason for which this reasoning cannot be extended to developed countries is that SIM Toolkit definitely went out of fashion with the advent of smartphones. The STK text-based interface is simply not acceptable on today’s phones, where we expect fully interactive applications.

That means that our current status is quite different with our smartphone applications:

• Internet connectivity. Forget the private network, we are connected directly to the Internet, and that’s where we want to do our transactions.
• Mobile applications. We get our applications from our local application store, so protecting data (both in storage and in communication) is a bit hard.
• Customized interactions. We like our interactions to be customized for each application. In many cases, the interaction at least partly comes from Internet, and HTML5 is going to make this more common. Here, no need to attack a low-level device driver to get to our stuff.

So far, this is fear-inducing rhetoric. You should be afraid, because your applications are not secure. Yet, there aren’t that many attacks, and mobile transactions are becoming more common on phones. With the announced success of NFC and the announced Google wallet, the future is looking bright in 2011. One of the reasons is that secure elements are becoming fashionable again on smartphones. Another one is that Apple, Google, and the others are keeping a rather tight control on our devices, and the users feel safe. Jailbreakers pose a small problem, but this is marginal for transactions (hint: if a payment application gets hacked on your jailbroken phone, “losing” the phone and denying the jailbreak sounds like a good option). Overall, I have no problem performing transactions with my phone today.

The really interesting question is: Would I feel just as safe if one of the financial app became as popular as M-Pesa is in Africa? A financial transaction application installed by 50 million users in Europe and the U.S. would sure make a tempting target for hackers around the world, especially with the average balance of our accounts.

In such a case, I would be tempted to say that the various stakeholders would like to have a few additional guarantees. The smart card and security industries have some answers to that: Let’s perform Common Criteria security certifications on cards to prove their security! Let’s add a security layer in the phone to enhance its security! Let’s obfuscate this application to make it more difficult to hack!

All of these things work, and some of them even work well. Each counteremasure makes the cost of attacking the system slightly higher. But all these things provide incremental improvements, and they are definitely not disruptive. Disruption is more likely to come from the outside, from the “hundreds of start-up companies” promised by Eric Schmidt around NFC.

An example: Bump. It is not about NFC, but it is a mobile security measure that “makes connecting as simple as bumping two phones into each other”. It relies on humans to perform most of the security checks, and leverages this on Internet. This is the way to go as our mobile devices become more personal, as they get closer to actually representing us on the Internet; the human being who holds the device will need to participate actively in the security protocols, and not only be entering a code. Disruption will come from those who make the security experience better, not from those who make the mobile experience more secure.

A security and forensics company has recently looked into mobile applications, and got some coverage.

Theyhave been studying banking and payment applications, from major banks and service like Wells Fargo and Paypal, and they found some flaws. Nothing big so far, as flaws are to be expected. The problem is that finding flaws was quite easy:

• One of the application stores the username and password in cleartext on the device. Twitter doesn’t want apps to do that, so one would think that banking apps are more careful than that.
• Another one of the appplications opens a SSL connection, but it doesn’t check the certificate, which makes it vulnerable to man-in-the-middle attacks, for instance on WiFi networks.

These flaws have been there forever, and we have identified them from the very beginning of mobile security evaluations. The SSL flaw is particularly common, and I am surprised to see it today, now that even browsers have a tendency to perform checks on certificates.

The only satisfying thing is that the reviewer hasn’t reported any backdoor into these programs. A few years ago, such back doors were very common, allowing developers to use their applications in “debug mode”.

If these backdoors have disappeared, we are moving in the right direction. But still, we are moving slowly.

After that, I took a little time to examine the smudge left behind. Of course, it depends on environmental parameters: Have I cleaned the screen recently? Am I just stepping out of the shower, or eating fries in a fast food? In most cases, smudge is vividly present, but there is another parameter, which is not covered in the paper: the usage patterns of the phone. Let me take a few examples:

• If I turn on my phone because of an incoming SMS, things can get really bad; I will enter the pattern, leave smudge, and then barely touch the screen to start the messaging application. If I reply, things are better, because I will use the virtual keyboard on the bottom of the screen.
• Games are among the best smudge killers, in particular if interaction is through the touchscreen. After 2 or 3 minutes of play, nothing is left of the smudge.
• Another bad factor of Android phones comes from the keyboard, because it is possible to interact through keys, without touching the screen. For instance, when I browse content, I tend to use the wheel rather than the screen, and the smudge remains. If the phone includes a full keyboard, things are worse, because no virtual keyboard will be used, and it will be tempting to interact through the keyboard in many situations.

So, basically, playing is safer than anything else. Good news for some. Also, if you have a virtual keyboard, it may be interesting to have a part of the pattern action at the bottom of the screen, where key entry will add noise.

The real problem is with the countermeasures. The paper outlines the fact that not all phones are equal in front of smudge attacks, so there may be a way to optimize this. However, it will be hard to get something that works for phones stolen in fast food restaurants.

Interestingly, I have started wiping my phone’s screen in some situations. It works wonders, but it is a stupid gesture, contributing to the proof that this authentication mechanism i just poorly designed.

In the end, Android security could be better with another authentication mechanism, which takes smudge attacks into account. Allowing us to select an application to replace the mechanism will make us even safer, because it would transform a class attack into an attack on an individual phone, leaving the attacker to analyze the smudge specifically for each application.