In this early 2019, the Road to Bandol can be quite dangerous, as exemplified by the video below:

Yep, that’s the Bandol toll barrier burning during a gilets jaunes demonstration. I am not sure to be fully sympathetic to these gilets jaunes, but they represent the French way to signal major unease in the population: rioting.

What they want is not clear, but what they express is very clear: it was better before. And I have to admit that the latest serious books that I have read kinda make me feel somewhat like this:

• Bruce Schneier’s Click Here to Kill Everybody: Security and Survival in a Hyper-Connected World promises us an IoT apocalypse that sounds just plausible to me.
• Yuval Harari’s Homo Deus: A Brief History of Tomorrow promises us another dystopian future, where AI is the scary thing, and gives a good background to the gilets jaunes by his description of the current failure of the capitalist religion.
• Research book Agnotology: The Making and Unmaking of Ignorance provides chilling insights into how fake news is just one of the ways to build ignorance of the masses willfully for the benefit of a few.

I guess that the year 2019 is going to be interesting, but it takes me a lot of positive energy to be optimistic about the near future. But then, who knows, because

The times, they are a changing…

So let’s go for a good change.

Just imagine a world where a company can deploy its preferred network security application on all devices, while benefitting from SE-based security, or where innovative ccompanies ccan design security applications that rely on SE applications. Sounds good? Well, too good, because this is just not our world, at least not today.

There is an obvious reason for this: the “owners” of these eSE’s, whether they are phone vendors (Nokia, Samsung, …), wallet vendors (Google, Isis, …), or others, are not opening their devices. It is therefore very difficult to load applications on them. The most open environment that I know is in France, with AFSCM, but as far as I know, this is an operator-dominated, SIM-based world, which has a long history of managing resource-constrained SIM cards.

So, why is it different with the relatively new players who own/manage embedded Secure Elements? My gut feeling is that memory limitations are part of the problem, if not the entire problem. If you think of an iPhone, memory is almost infinite: if you are missing memory, simply remove one or two songs out of the 2000 that your phone contains, and it fits. On an eSE, things are different: think of a 64k SE. If it already contains 4 applications, each using 15k of memory, there is no way to add a fifth one. The numbers are here very different, and the choices are much more limited. I don’t think that many iPhone users ever get to the point where they need to eliminate content that they really need to fit another content that they also really need. On a card, no such luck. And for a platform manager, this is very difficult to deal with, so their priority will be to get their applications on this, or at least the applications that can bring them immeddiate and/or obvious returns.

The problem is very different with a Trusted Execution Environment (TEE). Applications are here stored in the phone’s main memory, so there is no shortage of memory. This means that, for TEEs, it should not be too hard to actually use app stores or similar infrastructures. For eSE’s, we will need to work a bit more in order to achieve the same result.

However, there are really few open source developments in the area of smart card operating systems and runtime environments. This is why the recent release of the OPAL library by the University of Limoges is significant. This library offers a client-side implementation of the latest GlobalPlatform specifications, greatly simplifying the development of applications that manage applications on smart cards.

In particular, this development could be the basis for interoperable and open smart card testing tools. For instance, the Mesure project, which defines benchmarks for Java Card, could use an open and complete GlobalPlatform implementation.

Now, can we go further than that? Is it possible to really get into the smart cards, and have open source operating systems, or parts of operating systems? Well, there are a few good reasons not to do it:

• Licenses. The specificatoins like GlobalPlatform and Java Card are free to access, but after going through a click-wrap license, including some restrictions. For GlobalPlatform, the restricions are limited, mostly because GlobalPlatform is a community effort, and both the license to use the specification and to sell products bassed on it are free. The Java Card license is more restrictive, because it is owned by Oracle. Java Card is free for developers, but implementers need to pay a license.
• IP rights. The smart card industry is highly competitive, and has not always been very open source-friendly in the past. There are literally thousands of patents that have been filed on the technology, and it is hard not to infringe on any of them while writing a smart card operating system. Companies don’t have to enforce their IP, but they can, which means that any open source project is in under a constant threat.
• Security. This argument may not be as strong, but the smart card security community is very well organized, with manufacturers, labs, national authorities, etc. They have developed a significant set of documentation and guidelines aound Common Criteria certifications of cards, which is one of the best industry efforts available today. The industry may not be eager to see an active open-source community working on attacks and countermeasures in parallel to their own efforts. And if they are not happy, they may activate the IP rights argument.

Of course, there is here a difference between academic projects and industrial projects. Consider Simulity’s DKard project, a microcontroller (i.e., smart card) virtual machine based on Android’s Dalvik VM. Google may have published Android as an open-source project (we can assume that the spec lcense part is covered), but this doesn’t make them safe from IP rights. If they start encountering the slightest success, somebody will remember that they infringe on their IP; and since this somebody is likely to be much larger than Simulity, this is not good news.

From my point of view, we can close the industrial part. It would be foolish to start a company with a business model based on open source software for smart card operating systems, unless it is strongly backed by at least one major manufacturer, with the ability to protect the small player from IP claims by competitors.

Now, we are left with the academic projects. There is an active research community around smart cards, focusing in particular on security aspects, particularly in Europe. One of the main problems faced by this community is that they don’t have a good playground: there is no open smart card operating system platform on which they can experiment.

Card vendors are not too keen to see academics use their products for experiments and attacks, because they don’t want to see publications claiming that their card was broken. As a consequence, card development kits usually come with licenses and non disclosure agreements that do not allow the use of the cards for research purposes.

The “obvious” solution is to develop an open source platform, just for research purposes. But then, we get back to the licenses and IP and everything. There are several choices, every one with pros and cons:

• Implement Java Card. Here, a conflict is likely with the industry, especially if the implementation is good and can help outsiders develop/enhance their products.
• Implement something else. This could work, but the difficulty is to find the right balance between mimicking Java Card and differentiating from the spec.

I don’t believe that the solution is ready here. Without industry support, getting funding for the research will likely be difficult. And the industry players may not look forward to sueing a few academic institutions. In the end, the stakeholderes need to talk to each other, really looking for a solution that suits everybody. This discussion never really took place in the past, let’s hope that it will happen some day, so we can at least remember that we tried.

Thoughts and remarks welcome, as comments or direct contact.

OK. But let’s try to analyze this a bit deeper.

First, the attack:

• It relies on cloning. A good point for smart cards, which claim to be more difficult to clone.
• It can interest organized crime. We are talking millions here. If this can be repeated, it is a strong point in favor of good security, because the attackers can invest a few thousand dollars in breaking the card.

Again, I told you so! But I also need to bring up a few not so strong points:

• No authentication issues. Apparently, in these attacks, the attackers know the PIN code, either because they own the original card, or because they stole the PIN code with the card (not that hard, try it while waiting in supermarket of money dispenser lanes).
• A key part of the attack consists in hacking a server somewhere, to make a system believe that a card has no limit (or a very high limit). No card involved here, so no good point for a smart card.

Of course, I will now tell you that these arguments don’t hold.

• Smart card PIN authentication also authenticates the card. When performing an EMV transaction, the PIN is verified by the card, and that fact allows a cryptogram to be generated. When the payment terminal or server verifies its cryptogram, it will know that the user has been authenticated and the original card has been used. That links authentication to cloning, which is good for our case.
• About servers, there is nothing to say. There are so many breaches in all kinds of servers worldwide that nobody would rely solely on servers for reaching a good level of security.

So, I can now safely conclude that this attack would not work without actually cloning the card, which means that smart cards are better than magstripe, because they are in all cases harder to clone (even on cards with very poor security, there is no command to get the value of the secret; some kind of attack is required to get it). In addition, since the potential revenue is important, such schemes may interest organized crime, which means that they should be able to get the secrets out of at least the weakest available cards.

That leads us to the bleak side of things. A typical smart card in use today has been issued in 2007, by a bank who selected a platform vendor in 2005 after one year of negotiation with a card certified in 2003. And since 2003, a lot of attacks have been invented, and I am quite convinced that at least most CC-approved labs would be able to break these cards.

As a conclusion, I would say that smart cards are a good defense against these attacks, because they significantly raise the cost of preparing for the attack. However, I have no clue of the amount of money that it would cost to break a typical card used today, and this may still be very accessible to your typical mafia guy.

Let’s start by one example, the banking industry. Most issuers don’t define specifications, nor do they perform security certifications. Instead, they delegate these tasks to specialized companies, like Visa, MasterCard, or JCB. At that stage, things start becoming difficult. Although the three companies cited above share common specifications in EMVCo, their processes are completely different. Some focus on a process that defines a common minimum level, whereas some others prefer more flexible solutions that encourage all vendors to improve security. Of course, some of the largest issuers can add their own requirements. In addition to that, national bodies and bank associations can add their own country-specific requirements (this is very common in particular in countries that have been using smart cards for a long time, like in France).

Other industries have their own issues. The Pay-TV industry has very strong security requirements, and every solution provider has its own set of security requirements, which they of course don’t want to share with their competitors. Digital signatures require a Common Criteria certification with a specific Protection Profile. Various identity programs have their own requirements. Of course, let’s not forget that many issuers require several sources, so porting on different chips has always been an important activity.

This looks really ugly, and we look like a doomed industry. Well, things were not that bad a while ago. A different product was developed for every market/ association/ country/ issuer, and each one had its own certification process. The entire process was very expensive, but smart cards were (relatively) expensive, and the entire thing was healthy.

In the recent years, things have changed greatly, in many different ways:

• Many products are often based on the same base, often a Java Card platform.
• The smart card market has grown in numbers, and the proce of smart cards has considerably fallen.

The use of open platforms has allowed vendors to save on development effort, by reusing the same platform code, and also by using high-level languages, allowing some code to be directly reused, without porting it. At the same time, the price of certification has not fallen; instead, it has increased, as new attacks kept on coming, and as the processes became more formal, for instance with ITSEC, and then Common Criteria. The consequence is that the relative cost of certification keeps on increasing, and over the years, it has become a bottleneck.

Vendors have started to complain bitterly about these high costs, and in particular about the fact that they pay laboratories again and again for performing the same work (or at least, very similar work). These complaints take many forms, but I think that I can group them in two categories:

• All private evaluations must be replaced by a single Common Criteria evaluation for each product. This line is pretty simple: make sure that every product is only certified once. The problem, of course, is that this certification must cover all requirements for that product (see above for a reminder of the problem), which is not always realistic.
• The Common Criteria process is too heavy, too slow, and too bureaucratic to be compatible with our industrial process.. The point is here clearly a reaction to the Common Criteria process: an evaluation can take over a year, it requires a big documentation effort, and laboratories can be tempted to focus more on bureaucracy (verifying paperwork) than on the quality of their vulnerability assessment. As a result, faster and more focused certification processes sometimes yield better results.

Both complaints are somehow right: repeated certifications are inefficient, and Common Criteria can also be inefficient. However, none of them brings a realistic solution. How can Common Criteria deal with the conflicting requirements of multiple issuers? If we remove Common Criteria, who will be in charge of defining the certification criteria?

Very recently, issuers (in particular in the telecom industry) have started to embrace true multi-application cards, on which sensitive applications (which require some kind of certification), owned by multiple providers, can be added after the issuance of the card. Here, the efficiency issue becomes a feasibility issue, as we don’t necessarily have the complete list of target applications when the card is first deployed.

I believe that the principles of the solution are quite simple:

• Multiple certification requirements and formal processes cannot be avoided. We will not make all issuers agree on security requirements, and if we remove Common Criteria, we will have to replace it with another similar scheme.
• The certification process must be optimized in a way similar to the development process. The idea is here to save by reusing the certification of the platform, and by limiting the porting costs from one platform to another.

In order to put these principles in action, we need to work on a few items:

• Optimize the composition of certifications.
• Define and maintain detailed and accepted security requirements for Java Card platforms and applications.
• Include these principles in the definition of future platforms, and encourage issuers and their representatives to consider them in the revision of their security requirements.

Some people in the industry are already working on this, and I hope that we can succeed in the (not too) long run. If you are interested in joining this effort, let me know…

Following this chain of idea, there is no reason to keep the code of smart cards secret. Why don’t card manufacturers publish the code of their cards? We all know that this would allow an interesting peer review, and would most likely lead to an improvement of the published code’s security. After all, the code for a lot of software is available, including loads of security software. We can get plenty of open source crypto libraries, and a lot of server software.

Well, there is a difference. The threat model between most workstations or servers and smart cards differs greatly. One of the most important differences if that for smart cards, the end user is among the potential threatening agents. In addition, the attacks that are available to this threatening agent include hardware attacks that can make the software behave in unexpected ways.

There is an image that I have used several times. A smart card is somehow comparable to an e-commerce server that sits in the street with no protection: hackers can try to login, they can reboot the machine, and try to interfere with it in many ways, including taking it apart. In such a situation, the threat level greatly increases. Server software is normally sensitive only to remote attacks; now people can do other things: try to boot in a suboptimal mode, remove the hard disk to analyze it (modify it?) in another machine, you name it. In such a hostile situation, you start thinking again about your assumption.

Smart cards are built to withstand that kind of threat level. Besides the fact that it is embedded in a tamper-resistant casing and that it includes many sensors that will basically destroy it when something bad (and expected) happens, it also includes software countermeasures against many attacks: its sensitive data is encrypted, its integrity is protected, and many more. Nevertheless, new attacks appear regularly, or move from theory to practice: DPA at the end of the 90’s, fault induction more recently, a new one will come soon.

When a new attack happens, the damage it does depends on the power of the attack, and on the other defenses on the system. Let’s consider the two examples cited above:

• DPA and counters. The effect of DPA is to disclose your cryptographic keys, provided that it can make a sufficient number of computations. One proper countermeasure is to use a counter to limit the number of computations. Applications that included such counters, even if their designer was unaware of DPA attacks, are (at least partly) protected against DPA.
• Fault induction and “proper” redundancy checks. Fault induction became a very practical attack a few years ago; a particularly interesting attack is to disrupt memory read operations. Because of this, most integrity protections had to be redesigned, because they were aimed at verifying the integrity of stored information, and trusted the read operation. Despite that, some implementations of integrity checks were already , and did not need to be fixed.

What this shows is that smart card security is achieved by stacking several layers of security, with some level of redundancy. The objective is double: first, it defends the card against the wide variety of known attacks. Second, developers hope that it can also protect the card against attacks that aren’t known at development time. And code confidentiality definitely is a good layer of defense: attacks are often difficult to setup, and timing is essential. The source code reveals very precisely what the countermeasures are, which can help attackers defeat some defense layers.

As a conclusion, smart cards are not ready for open source, for a combination of reasons:

• Very hostile threat environment.
• Long lifecycle, no update possible, new attacks.
• Obscurity is an interesting layer of defense.

Now, what I am talking about is commercial products. On the other hand, I would like to stress that there are cases in which open source is not a big issue:

• Reference implementations. A reference implementation is usually not intended to be ported directly in products. Before that, it needs to be improved in order to include more security countermeasures.
• Research prototypes. For research prototypes, attacks are expected, as the result of the research will be challenged by other laboratories. Having access to the source code will help these other laboratories identify the potential weaknesses of the prototype, and ultimately improve it.
• Low-liability projects. Not all project handle large amounts of money or national security. For instance, one could imagine a “personal password safe” project. Security is important here, but for most people, the security offered by a standard is sufficient, as no attacker will spend tens of thousands of euros to find somebody’s password. Of course, this depends greatly on the secrets stored in the card, but this would apply in most cases.

So, my final conclusion is that I don’t believe that all smart card operating systems should be open source, but that having some open source implementations of Java Card would be a great boost for the Java Card community, in particular for the researchers and other innovators.

On technical matters, we are faced with the classical issue. As we are adapting an existing framework to smart cards, how far should we go in ensuring that we can program smart cards like other machines? Are there any significant differences? One of the issues is here access control. Will smart card servlets require standard servlet access control, or will they require a different model?

This is an ongoing Java Card Forum discussion. Of course, I will not disclose the discussion here, and I just want to outline a few ideas and doubts that I have about this debate.

The basic temptation is to believe that developers work for themselves, and that they will use the same applications on classical Web servers and on smart cards. This is extremely unlikely, for two main reasons:

• The way in which applications are deployed on smart cards makes developers highly dependent on issuers (possibly, application providers). Nevertheless, their degree of freedom is very limited, and they will have to deal with many issues such as backward compatibility and other fun stuff that will make the adoption of any new model (and in particular of a security model) difficult.
• Smart cards are likely to remain quite specific platforms. For instance, the way in which persistence is achieved is likely to make developers write specific versions of their applications. Limited resources and APIs will do the rest.

This does not mean that adapting other frameworks is useless. It has several interesting uses. First, by reusing a well-known framework, we significantly reduce the chances of making bad design mistakes, because the framework has already been tested. Then, reusing another framework allows us to also reuse the tools developed for this framework.

The main issue is here declarative security. To make complicated things simple, declarative security works in three simple steps:

1. Each user (cardholder or remote user) is associated to a given role.
2. Each role is given some access rights.
3. Rights are checked in a generic way during the processing of a request.

The approach has numerous advantages. The most interesting one is that it makes the access control part of security orthogonal to the code (roles and rights are declared in a descriptor, not in the code itself; the code only checks that “declarative security is OK”).

The big question is: does this apply to smart card applications? There is no definitive answer, but there are at least two important points to consider:

• Security is at the core of smart card applications. For most smart card applications, security is a key feature, and one of the major objectives. This means that most security decisions are taken early in the process, and security is part of the application’s specification. In such cases, orthogonality is not that useful. In addition, if there is any kind of backward compatibility issue, it is most likely inapplicable.
• The association of users to roles is usually managed directly by smart card applications, using complex and often proprietary authentication schemes. This may change with Web server applications, but somehow I can’t completely convince myself. One example is the application provider authentication mechanism provided by GlobalPlatform (secure channel). Although this mechanisms matches quite well the requirements from smart card applications, itis seldom used in actual applications, except for the proprietary personalization phase.

The second argument is for me the most significant one. Smart card applications are likely to require strong user authentication. In particular, cryptographic mutual authentication and the establishment of some kind of secure channel is likely for remote users.

We need to make sure that whatever decision we make, we will be able to accomodate what the developers and application providers will invent. With smart card Web servers, we don’t have to deal with much history and backward compatibility. This is a good thing, as it removes many constraints; on the other hand, it gives us the responsibility of ensuring that we are not taking bad decisions that we will need to carry with us for many years.

Some may say that the SIM Toolkit framework is an exception to that rule, but not really. The proactive commands, through which a card application may request operations from the terminal or the network, can only be sent as a response to a command previously sent by the terminal. In SIM Toolkit, the card is not able to take the initiative to send a proactive commands when it is not active.

In Bandol, the situation is different. TCP/IP, unlike ISO7816, is quite symmetrical, and once the card is registered on the network, it is possible for it to initiate a connection, at least in theory. This raises two questions, that I will try to answer: Do we need that? Does that entail security issues?

First, do we need to initiate a transaction. Such an initiation can occur in two ways:

• As a response to an event coming from the outside. This case looks a lot like SIM Toolkit; the card does not really take the initiative, as it simply reacts to an outside event. There is however a major difference: the response is not necessarily targeted to the network node that triggered it.
• As a response to an internal event, usually a timer expiration. This does not look very applicable, because there is no real-time clock on the card. It may however happen as a late response to another event.

The main difference with SIM Toolkit is the ability for the card to initiate a connection with another entity. But even that is not all that new. On recent SIM cards, the BIP allows Toolkit applications to (painfully) connect to the outside.

So, what’s new? The main difference comes from the way in which this connection can be established, and how available it will be. And that has an impact on security. Today, Toolkit applications are in most cases developed by the operator or by trusted partners, and there are relatively few such applications.

If cards become more open, which is one objective of Bandol, then the security issue will become the same than with any server: is it posible to convince this servlet to send me critical information? Can I modify the way in which it establishes some connections?

So, finally, the issue is not so much the fact that it is possbile to open connections to the outside, but (1) the ease with which the applications are developed, and (2) the way in which people connect to the card application, since many more people know how to build problematic HTTP queries than ISO7816 commands.

When I am at home, DRM is evil: I listen to a lot of music, and I also buy a lot of music. I use daily a home stereo, a car stereo, two mobile MP3 players (no iPod), a smart phone, a personal PC (now in Windows, soon in Linux), and two office PCs. Since I like to listen to the music I buy on any device that I own, i basically despise DRM. I have not been using iTunes and other Web stores, because I believe that the DRM they use is unfair.

Of course, this situation is highly uncomfortable, since I don’t like much to promote professionally things I don’t practice personnally. There are many reasons to that: I fell dishonest, and also I feel that it is a recipe for failure. It reminds me too much of the WAP hype in the late 90’s. All smart card marketers were convinced that it was the coming killer app, but they did not want to use it (although they often were right in the eye of the target population). WAP failed miserably; I don’t mean that DRM will go the same way, but success is not yet completely guaranteed.

The next step is for me to reconcile my personal feelings with my professional views is to identify how DRM can be good. Well, there is one thing: what I am doing today is legal in France (or almost), since we pay a “private copy” tax on any sorage device on which music can be copied, and that allows us to do some amount of private copying (although most likely a bit less than what I do). However, the legality of the thing is not quite guaranteed. And in addition, it does not allow me to legally allow a friend to lilsten to a song I like; I have to let that friend copy the song from me, which is almost surely illegal.

So, what DRM could offer me is the ability to actually listen to my music on all my devices. This isn’t basic DRM, of course, but most of what I need is already included in the DRM schemes. There is a possibility to allow a limited number of copies, and also to let the system know that a version of the song was deleted, etc. We are still far from what exists today, but technology may not be the most important hurdle. Business seems to be the problem, as majors are not sure about the way to make money from flexibility.

In addition, there are some good news there. This entire scheme only works if the level of security provided by all devices is sufficient to guarantee that this private copy scheme won’t turn into a giant copy machine. And this means that there is a lot of work for me and all my friends in the mobile security business. I can sleep again.

This is a significant move from the existing framework, which is based on smart-card specific standards such as ISO7816. Of course, a smart card remains a small object (at least compared to a standard server), so we can’t take the entire J2EE framework. This means that some subsetting is required, which is a difficult problem.

We faced the problem before, at a different level. For Java Card 2.0, we had to subset the Java language, and for 2.1, the Java virtual machine. However, the problem is much more difficult this time, because of the sheer size of the thing to subset.

The first thing to do is to check the features that will be required:

• Network connectivity. The card needs to be connected through TCP/IP, and some of its applications will be servlets.
• Static and dynamic content. An application needs to be able to include static content (for instance, its look and feel) as well as dynamic content (the actual content, whether it comes from the card itself or from elsewhere).
• Access to mass storage. If cards have a lot of memory, it definitely is a good idea to make this memory accessible for applications, for matters like DRM (business-correct) or private data encryption (nerd-correct).
• Smart card security. Whatever marketers say, security remains a major differentiator for smart cards, and most likely one of its most important use cases. But this security is not your server security, because a card is not a typical server.

All we need exists in Java today, and most of it even exists in Java ME. However, we have to subset, to make hard decisions about each feature: keep it or throw it? Designing such subsets is difficult, and especially when the uses of the API being designed are not completely known.

I will just illustrate this on the security issue. The security model that has been disclosed by Sun at JavaOne and e-Smart is quite complex, and also quite similar to the one in use on servers. However, there are significant differences between a server in a rack and a server in a pocket:

• The server in a pocket has been designed to host several applications, which may collaborate even if they only share limited trust.
• The server in a pocket includes things like GlobalPlatform to manage its applications. It can host several applications, possibly by people that don’t trust each other, but they will always share some trust somewhere.
• The server in a pocket is quite likely to be difficult to reach for malware, for instance because of private networks, or more simply because it sits (unconnected) in a pocket.

There are many more differences like that, more or less subtle. These differences should of course be taken into account in the design of the new Java Card platform. Hopefully, we will take them into account, and make a nice platform.