Open Source or Security through Obscurity ?

I strongly believe that keeping things secret is not a good idea, and that security cannot be achieved through obscurity. There are many convincing examples of this, even in the smart card industry. The infamous GSM algorithms are a perfect example: cryptography using secret algorithms is a bad idea, because the algorithms get broken.

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.

3 Comments

  • Crispan wrote:

    A concise posting. I can agree on the argumentation and the conclusion. The interesting question is can enough momemtum be build up to develop a living Java Card OS open-source community? I hope so. :-)

  • lexdabear wrote:

    Eric, great post. Now it clear to me why there is no open source Java Card OS.

    I still want to stress one point. You state that smart cards are built to withstand that kind of threat level. So wouldn’t it be sufficient just to keep the hardware counter measures secret? I mean if new kinds of attack appear anyway. And the ones you listed are not of the software kind (malicious/evil applets). My idea is that the community reviews the OS code and finds flaws now, which is better than later in the field. Sorry, but still don’t agree on: Obscurity is an interesting layer of defense.

  • I must admit that I don’t agree with myself, at least on the principle: Obscurity is not a good layer of defense.

    However, I don’t believe that the smart card industry has yet found a way to live without it. Among the problems mentioned in the post, the “long lifecycle, no possible updates, new attacks” is the really annoying one. We can’t shrink the lifecycle, we can’t avoid new attacks, so the only workaround is to allow updates.

    It seems easy, but an update mechanism introduces its own range of weaknesses. I can think about a few ways to make a really secure update mechanism, which resists to all the attacks I know. But then, I can’t think about designing one that will work against attacks that I don’t know.

    About countermeasures, there is no clear boundary between hardware and software, and most hardware attacks are countered by a combination of hardware and software, so restricting obscurity to the hardware does not help.

    Finally, I still believe that things have to evolve slowly, and that the first step cannot be to open source an industrial product. This means that we have to start with some kind of academic work, and first ensure that some license allows them to do so.

Leave a Reply

Your email is never shared.Required fields are marked *