Before we dig into the security implications raised by putting a Java VM on a smart card, we need to address the issue of basic smart card platform security. Smart cards are funny things. Depending on how they're used, smart cards can sometimes be meant to keep secrets from the very people who carry them around and use them. Consider, for example, a smart card that stores monetary value in an internal register. If the card user can figure out a way to change the value of the register outside of traditional means, he or she might be able to mint money! Smart cards like this make tempting targets for bad guys. Because smart cards are often used in security-critical situations, they have undergone a fair amount of scrutiny from security researchers. Two main results are worth considering before we get into security issues specific to Java: 1) the terminal problem, and 2) physical attacks on the card.
Smart cards need a way to interact with their users. Since there is no built-in display capability in most cards, the CAD must take on this responsibility. Any display used during critical transactions, such as transferring money, needs to have two properties: the display must be trustworthy, and it must be unspoofable. Making sure a terminal presents proper and trustworthy information to a user is known as the terminal problem. The terminal problem is really a trust issue. How is a card user to be sure that the card is doing what it is supposed to be doing during a transaction? How can a card user check to see whether account balances (for example) have been properly debited or credited? The problem is that cards are very much black boxes. Many systems now on the drawing board include the use of personal computers as client-side CADs. Consumers will use a PC to interact with the smart card and to address the concerns raised by the terminal problem. The problem is that PCs are notoriously insecure, especially when they're used to exchange lots of documents and programs, as most consumers do. If you use your computer this way, you're taking on a great deal of risk. One direct consequence of PC untrustworthiness is a PC's impotence relative to the terminal problem. If your PC can't be trusted, how can you believe that what it is telling you on behalf of your smart card is correct? In fact, one excellent reason for using smart cards at all is that PCs can't be trusted. The reasoning goes that it is better to store secrets like PINs, sensitive personal data, and private keys on a smart card than on a PC. That way, if the PC is compromised, your secrets can't be so easily stolen. However, this leaves us with the terminal problem. A scenario can make this more concrete. Imagine that someone has tampered with your Web browser either by hacking into your PC or by tampering with the Web browser executable before you downloaded it. Now clearly you can't trust the browser not to steal or rewrite data on the way from your smart card to you. Some things that might happen are:
Unfortunately, there is not much reason to trust a PalmPilot much more than a PC these days. The problem is that newer PalmPilots and other PDAs are designed to network with PCs directly (sometimes even using a TCP/IP stack). That's good news if you want to transfer data to and from your PDA, but it's risky. Just like a PC, a PalmPilot is probably insecure if you frequently download programs onto it. Crackers are currently devising hacks that work against PalmPilots. In the end, we're stuck with the terminal problem. As smart cards move into more widespread use on PCs, PC-based interfaces will be especially susceptible to this problem. An insecure Windows 95 OS in concert with a Web browser should not be trusted to display critical information to a smart card user. A PDA might do the trick, but is likely to carry similar risks.
The most obvious and direct attack on a smart card is a physical attack on the card itself. In the case of a stored-value card, this sort of attack may even be carried out by the owner of a card. Physical attacks attempt to reverse engineer the card and determine the secret key(s). Such attacks have been demonstrated in practice against commercial secure smart card chips, most notably by three groups of researchers: Dan Boneh, Richard DeMillo, and Richard Lipton of Bellcore; Ross Anderson of Cambridge and Marcus Kuhn of Purdue; and Paul Kocher and colleagues of Cryptography Research, Inc.
How does the attacker introduce errors? There are plenty of ways. The attacker can subject the smart card to fluctuations in temperature, input voltage, or clock rate; point a radiation source at the card; or hit the card with a rubber mallet. Anything that is likely to cause voltages inside the card to fluctuate will do. Biham and Shamir later generalized this attack with a technique called Differential Fault Analysis, which works against a wide range of cryptographic algorithms. The upshot of all this is that unless a smart card cryptography mechanism is very carefully designed, any secret keys stored inside the card might be extracted by a determined attacker.
More sophisticated attacks requiring professional equipment and materials involve uncovering the layers of a chip by etching, discerning chip behavior by advanced infrared probing, and reverse-engineering chip logic. The somewhat gloomy conclusion is that, at best, chip designers can only impose costs and delays on attackers, never providing guaranteed security. Many businesses that rely on smart card security realize this and do all they can to manage the risks prudently. Users should do the same. Some caveats: the Anderson and Kuhn work is somewhat dated and is based on attacks carried out in the lab against conventional micro-controllers, which are usually much simpler than today's smart cards. Micro-controllers provide a great deal of open access to potential attackers since they are meant to be interactively programmed. For example, micro-controllers often provide an interface for external memory; generally speaking, smart cards don't have this feature. Thus they provide less of a beachhead for attacks. Of course Java complicates this line of reasoning somewhat. Card Java provides a platform that is meant to be programmable in the sense that applets may be loaded onto a smart card after it is issued. Mechanisms for loading new code onto a smart card provide a good starting point for an attacker.
DPA is a complicated attack that relies on statistical inferences drawn on power consumption data measured during smart card computation. The equipment required to perform DPA is simple: a modified smart card reader and some off-the-shelf PCs. The algorithm itself is quite complex, but details have been widely published. Chips inside a smart card use different amounts of power to perform different operations. By hooking a card up to an oscilloscope, a pattern of power consumption can be measured. Particular computations create particular patterns of spikes in power consumption. Careful analysis of the peaks in a power consumption pattern can lead to the discovery of information about secret keys used during cryptographic computations. Sometimes the analysis is straightforward enough that a single transaction provides sufficient data to steal a key. More often, thousands of transactions are required. The types of sensitive information that can leak include PINs and private cryptographic keys. Figure 8.2 is a conceptual diagram of DPA.
Possible solutions include masking power consumption with digital noise or throwing random calculations into the mix. Another potential solution is randomizing the order of card computations so that in the end, the same computation is performed using different patterns of primitives. All of these potential technological solutions are ways to mask the giveaway patterns in the power consumption of the card. DPA is actually a variation on an earlier attack discovered by Kocher. The earlier attack exploited the fact that some operations require different amounts of time to finish, depending on which values they are computing. In the same way that DPA allows an attacker to piece together key information based on variations in power consumption, Kocher's timing attack allows an attacker to piece together a key based on variations in the amount of computing time required to encrypt various values. One thing to note is that legitimate users of smart cards don't have to worry too much about DPA or timing attacks, because the attack requires physical access to the card itself. Unless you lose your card or insert it directly into an attacker's machine, there is not much threat that your card itself will be cracked. The main risk that DPA presents is to companies that must concern themselves with widespread fraud of the sort carried out by organized crime. The best approach is to assume information will leak from a smart card and design systems in such a way that they remain secure even in the face of leaking information. An approach of this sort may preclude smart card systems designed to do all processing offline without a centralized clearinghouse. Detailed technical information about DPA can be found on the Web at www.cryptography.com/dpa/technical/index.html.
It should not be surprising that smart cards have their own set of risks- 100-percent security is an unattainable goal. Once again, risk management and defensive design are optimal strategies.
Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Copyright ©1999 Gary McGraw and Edward Felten. |
