Java Card Security: How Smart Cards and Java Mix Section 1 — Java Security Goes Both Ways| | There are a large and growing number of Java systems running the gamut from Java gizmos such as Java rings, through smart cards with built-in Java interpreters (the subject of this chapter), to complete Java Development Kits and Integrated Development Environments (IDEs). Java is simultaneously making in-roads on many fronts. In distributed systems, Java-based servers and servlets are becoming as common as Java clients.
As with any platform meant to interact in a networked world, there are security concerns with each flavor of Java.
These concerns take on a new urgency when it comes to e-commerce. When electronic blips are money, the stakes change considerably. It may be an inconvenience to lose a Web server that amounts to fancy brochureware; it is something else entirely if the Web server and its associated backend perform all customer transactions. The security concerns raised by e-commerce are a large enough topic in their own right that there is no way we can do them justice here.
Of course, because Java is commonly used at all levels in e-commerce systems, the risks we identify have serious e-commerce implications. This is especially true for Java cards. Counterintuitively, Java is both growing and shrinking at the same time. On one hand, the JDK, now up to Java 2, is doubling in size with each major release. Just to complicate matters, at the same time as the explosive growth of the code base is occurring, the security architecture is undergoing major reorganization.
Chapter 2, “The Base Java Security Model: The Original Applet Sandbox,” and Chapter 3, “Beyond the Sandbox: Signed Code and Java 2,” detail the new model. On the other hand, embedded Java systems like Card Java 2. x strip Java functionality down to bare bones. The security model is not immune to this effect and has been deeply affected by Java’s migration to smart cards. These two diverse directions both have important security implications. Java 2 involves fundamental changes to the Java security model as the Java sandbox metamorphoses itself into a trust-based system built on code signing.
Card Java 2. x removes much of the sandbox, leaving smart card applets more room to misbehave. Section 2 — What Is a Smart Card? | | A smart card looks just like a credit card, only with a chip embedded in its plastic. Imagine replacing the hologram on a standard credit card with a similarly thin chip and you get the idea. Most smart card chips are about the size of a dime (only thinner) and can be recognized by their distinctive gold terminals. Figure 8. 1 shows a Visa smart card. Figure 8. 1 Visa has been active in the development of the Java Card.
Visa’s Open Platform classes interact with Java Card to provide a secure framework for which to develop smart card applications. (This figure used by permission from Visa. )| A smart card chip is actually a complete little computer with nonvolatile memory, storage, a card operating system (COS), and accompanying communication protocols. The most advanced smart cards on the market have the processing power once found in an IBM-XT (with less memory, of course). There are many different uses for smart cards.
Smart cards can serve as: * Security cards that are able to identify the carrier using advanced authentication algorithms and can safely store secrets like private keys * Electronic wallet cards that use several different approaches to store value and provide a kind of electronic cash * Transaction cards that take over the role once played by the magnetic stripe commonly found on the back of credit cards * Processor cards that carry out proprietary calculations in a black box fashion * Memory cards that act as highly portable databases Cards with Virtual Machines that run Java applets Unlike traditional computers, smart cards are not delivered with a built-in power supply, a keyboard, or a display device. That means smart cards require a terminal in order to work. Such a terminal is usually called a smart card reader or a card acceptance device (CAD). Some of these readers can be quite small and provide limited capabilities. For example, one CAD popular in Europe among users of stored-value telephone cards is not much bigger than a smart card itself. This CAD’s sole purpose is to display the balance of money stored on the card. Having a trusted device with which to query a card you own is important for consumer peace of mind, especially when spending money at businesses that are of questionable trustworthiness. Plus, it’s nice to be able to verify that transactions, like adding money to a card, actually happen properly. ) CADs are also present at merchant sites (usually in the form of point-of-sale devices) and at issuing banks. These CADs may look much like a typical point-of-sale credit card processor, with a small display screen and a few buttons for answering queries or entering PINs.
In similar fashion to today’s ATMs, a smart card is inserted directly into the reader. The reader then provides power to the card and sets it up to receive software commands. Although a CAD of this sort may look like an ATM on the outside, a smart card is much more powerful than an ATM card or a mag-stripe credit card. These latter cards store only a few kilobytes of information on the magnetic stripe and are not capable of performing computations. Smart cards can store many megabytes of information and carry out sophisticated cryptographic calculations.
Another sort of CAD more commonly encountered by developers is a CAD connected directly to the serial port of a standard PC. Using development environments similar to those used in normal application development, programmers can create code for smart cards, download it into a prototyping card, and in this way create new smart card applications. Most major smart card vendors have proprietary Java development environments: Gemplus offers the GemXpresso environment; Schlumberger offers Cyberflex.
There are many custom command sets for smart cards. In fact, there are so many custom environments and they are so specialized that the number of smart card programmers is very small. Considering that smart cards are traditionally programmed in platform-specific assembly languages and that each vendor has a different language, the small number of programmers should come as little surprise. The situation could be worse, of course. At least all of the major vendors conform to a set of common communications standards.
The ISO 7816 specifications provide at least some common ground and ensure that smart cards have similar terminal pin-outs, accept standard protocol messages, and store some information in databases of common design [ISO7816, 1987]. ISO 7816 defines some commands in great detail and lays out communication protocols used by smart cards. Because of the existence of 7816, a smart card made by, say, Gemplus, can interface with a CAD meant for, say, Schlumberger cards. Smart cards have long been associated with security since they provide a partial solution to the need for personal identification and nonrepudiation.
Because smart cards provide more nonvolatile storage than other highly portable devices, they make ideal storage compartments for digital identities. They can also compute hashes, session keys, digital signatures, and MACs right on the card. To the extent that a card is tamper resistant (something we will discuss further later in this chapter), it can be used to store important secrets such as DES keys or Section 3 — Why Put Java on a Smart Card? | | As we mentioned earlier, one obstacle blocking widespread use of smart cards in U. S. arkets has been the large number of incompatible and often obscure development languages available for writing smart card applications. Regardless of the ISO 7816 specifications, programming languages for smart cards have traditionally amounted to special-purpose assembly languages. Few developers were familiar with card application languages, the upshot being that only a handful of people could develop smart card code. As cards become computationally more powerful, new application languages are being designed and put into use. One of the most interesting new systems is Java Card 2. (seewww. javasoft. com/products/javacard/index. html). The problem of multiple, noninteroperable platforms is not limited to smart cards, of course. A major part of Java’s appeal is that it was designed as a cross-platform solution. Developers have always wanted a solution to the platform problem (other than the adoption of one single proprietary platform controlled by a monopoly). Java is one good way of addressing the platform problem on smart cards. A Java card is a smart card that is able to execute Java byte code, similar to the way Java-enabled browsers can.
But standard Java with all of its libraries (especially in the Java 2 guise) is far too big to fit on a smart card. A solution to this problem is to create a stripped-down flavor of Java. Card Java is just such a flavor. It’s based on a subset of the Java API plus some special-purpose card commands. Besides providing developers with a more familiar development environment, Card Java also allows smart cards to have multiple applications on them. For the most part, existing smart card products (especially in the financial arena) have only one application per card.
This application is automatically invoked when power is provided to the card or the card is otherwise reset. The one-application-per-card paradigm doesn’t scale well, to say the least. Who wants to carry 20 credit cards around? Card Java can solve this problem by allowing multiple applications, potentially written by different organizations, to exist on the same card. The idea of multiple applications running on the same VM by potential competitors raises a number of Section 4 — How Can Java Fit on a Card? | | Even a stripped-down version of Java and its accompanying VM requires a fair amount of computational power in order to work.
To be capable of running Card Java, a smart card must have at least 16K of read-only memory, 8K of EEPROM, and 256 bytes of random access memory. Given a Java Virtual Machine on a smart card, the number of possible new applications is mind-boggling. With an off-the-shelf (or off-the-Net) application development environment for Card Java, thousands of Java developers will be able to program smart cards. Gemplus and Schlumberger both distribute commercial Card Java environments. Of course, the memory and interface constraints of smart cards deeply affect programming style, testing concerns, and other aspects of program development.
Card Java has many features familiar to Java developers, especially those developers familiar with JDK 1. 0. 2. Card Java includes: * Packages * Dynamic object creation * Virtual methods * Interfaces * Exceptions Elements of Java that are not supported include: * Dynamic class loading * A security manager * Threads * Cloning * Garbage collection * Finalization A number of limitations are also imposed on runtime card application (or cardlet) behavior. The “Java Card 2. 0 Language Subset and Virtual Machine Specification,” a Sun Microsystems document available on the Web at www. javasoft. om/products/javacard/index. html, describes the smart card version of Java in more detail. In the current Card Java paradigm, applets live on a card forever once they are installed during a process commonly called personalization. More specifically, although an applet’s byte code may stay on the card forever once it is masked onto a card, an applet can be marked as unavailable and thus be permanently disabled. All applets that will be used on a card are installed at one time, before the card is issued to a consumer. These applets are selected and deselected by the Java Card Runtime Environment (JCRE).
The JCRE is made up of the Virtual Machine and the core classes of the Java Card API. It keeps track of applets that are selected and currently active. The JCRE is in this sense the card executive, receiving messages (known as APDUs) on the input lines and carrying out the appropriate activities such as selecting an applet. Only one applet can run at a time in current Card Java implementations. Future versions of Card Java are likely to allow applets to be loaded onto an existing card even after it has been issued to a consumer (much the same way that applet code is loaded into a browser’s VM).
This introduces a number of security risks, including the risk that downloaded applet code will behave maliciously (in the manner of the hostile applets detailed inChapter 4, “Malicious Applets: Avoiding a Common Nuisance,” and Chapter 5, “Attack Applets: Exploiting Holes in the Security Model”) and the risk that poorly engineered code will disable or otherwise break the platform. Unlike VMs inside browsers, a smart card VM is not quite as easy to restart, nor are the security mechanisms as rigorous. By this point, it should be clear that Card Java has important security implications.
These implications take on even more importance when smart cards are used in e-commerce systems. Section 5 — How Secure Are Smart Cards? | | 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. The Terminal Problem 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: * The smart card requires a PIN before it can be used. Through a browser interface, you are queried for your PIN (which you faithfully enter). The corrupted browser sees the PIN go by and stores it for later illicit use. The PC is used as a listening post in order to carry out capture/replay attacks against the smart card (these kinds of attack often work against cryptographic protocols unless the protocols are carefully designed to address this problem). * The PC steals the private key off the smart card and is able to “legally” represent you by digital signature. What is needed is a trusted display. Some researchers have suggested that PDAs such as 3Com PalmPilots might serve as trusted displays. The idea is that the PDA can interact directly with the user during security-critical operations like PIN input.
In fact, the PDA can replace the smart card entirely since it can easily carry out all the required computations. (PDAs are probably too unwieldy for this idea. It’s much easier to slide a smart card into your wallet than a PalmPilot. ) 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. Physical Attacks on Smart Cards
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.
Boneh, DeMillo, and Lipton Boneh, DeMillo, and Lipton, three Bellcore researchers, published a paper called On the Importance of Checking Cryptographic Protocols for Faults in which they pointed out that an adversary who can introduce computational errors into a smart card can deduce the values of cryptographic keys hidden in the smart card [Boneh, et al. , 1997]. The surprising part is that an attacker can do this even without precisely controlling the nature of the errors or even the exact timing of the errors.
By comparing the result of an erroneous encryption with the result of a correct encryption of the same data, the attacker can learn something about the correct encryption key. By doing enough of these comparisons, the attacker can learn enough information to deduce the entire encryption key. 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. Anderson and Kuhn In a paper entitled Tamper Resistance – A Cautionary Note (www. cl. cam. ac. k /users/cm213/Publications/tamper. html), Anderson and Kuhn point out that “smart cards are broken routinely” and to the extent that their secure use requires tamper resistance, smart cards “should be treated with circumspection. ” The paper describes a number of smart card attacks, many of which can be carried out by amateur attackers with very limited resources [Anderson and Kuhn, 1996]. Attacks described include voltage manipulation, temperature manipulation, chip removal (for easier probing), UV light attacks, and microprobing.
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. Differential Power Analysis In 1998, Researchers at Cryptography Research, Inc. , led by Paul Kocher, publicly announced a new set of attacks against smart cards called Differential Power Analysis (DPA). DPA can be carried out successfully against most smart cards currently in production.
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.
Figure 8. 2 Differential Power Analysis. Paul Kocher and his colleagues at Cryptography Research devised a monitoring attack on smart cards based on information leaked through card power consumption. This figure used by permission from Cryptography Research. | 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. No Free Lunch 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 Section 6 — What Role Can Smart Cards Play in E-Commerce Systems? | | E-commerce means different things to different people.
Some people, for example, limit the meaning of e-commerce to commerce conducted over the Internet and the Web. For the purposes of this chapter, we’re going to use the term more widely. So, by e-commerce, we mean everything from electronic business-to-business traffic (for example, Electronic Data Interchange), through Internet-based systems, to any system in which money is represented as bits. Under this admittedly overly broad definition, almost the entire economy is touched by some aspect of e-commerce.
We’re intentionally invoking this broad definition to emphasize the utility of smart cards for transacting business. Smart cards are seemingly an excellent medium for carrying password-protected personal data. Private information such as medical records or secret crypto keys can be stored on a card in a form accessible only to the card carrier (or at least someone who knows the right secrets). In addition, smart cards can store value. Card carriers can decide with whom to share data and with whom to transact business and use their cards only with those vendors they choose to trust.
The most common form of smart card for commerce is the register-based, stored-value card. Somewhat ironically, one of the most unfortunate consequences of this kind of smart card is that secret keys on the card are known only to the issuing bank and must remain secret from the owner. If the card owner can somehow retrieve a secret key, then he or she can mint electronic cash. In light of the physical attacks sketched earlier in the chapter, this is a serious problem. Multiple-application smart cards like the Java Card should directly impact the marketability of smart card technology for e-commerce.
When a single card can replace the many cards most consumers carry around today, people are likely to want it. Imagine a single card that both holds personal information (such as driver’s license, social security, medical information, auto insurance, voter registration, workplace ID, Web site passwords, keys for making digital signatures and encrypting data) and also provides multiple functions (working as a phone card, a charge card for a store, a video rental credit tracker, a credit card, a debit card, and an electronic cash repository). Leading Web vendors like Netscape are developing APIs for smart card interfaces.
The idea is to use a smart card to store cryptographic data for use with existing protocols such as SSL. This will allow Netscape users to interact over the Web with a well-understood (and widely accepted) protocol. Microsoft is also building smart card interfaces into its products. The first use of smart cards for e-commerce is likely to be as a key/identity repository. In this case, smart cards act as highly portable hardware tokens that can be uniquely identified. Smart cards can store personal digital certificates for use with the SET protocol and other authentication-based protocols [Ghosh, 1998].
This could make it possible to carry out Web-based commerce on Internet kiosk systems of the sort occasionally found in airports and coffee shops. Section 7 — How Does the Use of Java Impact Smart Card Security? | | Much of the base security model found in Java’s JDK 1. 0. 2 (and explained in Chapter 2) is not present in Card Java. For example, Card Java has no Security Manager class. This means the whole concept of security for Card Java applets is significantly different from the case of applets running on a standard browser-based VM.
Fortunately, some of Card Java’s “missing parts” may actually enhance the security situation; unfortunately, some of the changes introduce new security risks. How Card Java Lessens Security Risks One of the most difficult problems in Java security is figuring out how to preserve type safety, while at the same time allowing dynamic class loading (see Chapter 2). If you can confuse the VM about the types of objects it is manipulating, you can break the security model. In its current form, Card Java takes care of this problem by removing dynamic class loading, making type safety easier to enforce.
Class loading has always been problematic in Java and has introduced a number of serious security holes. Because it has no dynamic class loading, Card Java is less risky than regular Java from this perspective. Another constraint imposed by Card Java, lack of threading, makes security analysis of applet code much easier than it is normally. Threading is difficult to implement properly and to use properly, plus threading takes a fair amount of overhead in the VM and significantly impacts the VM footprint. Although there can be multiple applets resident on the same smart card, Card Java systems allow only one applet to be selected t a time. (The multiple-resident-applications concept introduces risks of its own, which we address later. ) How Card Java Increases Security Risks Lack of threads and the absence of dynamic class loading impact security in a positive way, but the opposite effect can be seen with other Card Java features. In other words, the removal of some features of Java (clearly intended to make possible the migration to Card Java) may introduce new security problems. Risks that are introduced involve: * Lack of garbage collection * Exception propagation problems Multiple applications and applet firewalling * Object-sharing loopholes * Access to native code These problems and their risks are discussed next. Garbage collection is a good example of a feature whose absence has a security impact. Without a system for freeing allocated memory, the problem of denial-of-service attacks is exacerbated. The Card Java 2. 0 specification does not require implementation of garbage collection on a card (in fact, implementing garbage collection on a card would be no small feat). As a result, even subtle programming errors can wreak havoc on a smart card.
Memory leaks are a classic problem in languages such as C++ that do not support automatic garbage collection [Hastings and Joyce, 1992]. (Note that the term memory leak refers to memory becoming full when objects are inefficiently created and destroyed. ) Since Card Java does not support garbage collection, logic errors in applet code may over time exhaust free memory, rendering the card useless. This problem is especially acute on cards with limited memory resources. Another closely related issue is the “dangling reference” problem, in which a program frees memory even though it still has a pointer to that memory.
The problem is that the freed memory may be recycled for another purpose, and then the old “dangling” pointer may be used, resulting in memory corruption. Unfortunately, garbage collection is expensive in terms of both time and computational resources. Nevertheless, the risk of memory leaks is real. The requirement to ensure that these kinds of errors do not occur raises the need for extensive testing and analysis of Card Java applet code. Exception propagation is an interesting issue for Card Java as well, since uncaught exceptions could lead to a card being muted (disabled for normal use).
The potentially fatal effect of unhandled exceptions implies another significant exposure to unintended denial of service, once again resulting from subtle programming errors. As with memory exhaustion, the requirement to ensure that these kinds of errors do not occur raises the requirements for extensive testing and analysis of the Card Java applet code. Since Card Java allows multiple applications to be resident on the same smart card, there is a risk of interapplication attacks. This risk is especially relevant in situations where applets may be provided by competing vendors.
Card Java defines applet firewalls meant to protect applets from one another, although it is not exactly clear what technology underlies this terminology. It appears that the main protections between applets are related to memory management; in particular, applets are not allowed to access memory arbitrarily on the card. As a default, they can only get access to objects that they own (which are mapped into card memory during applet installation). It is clear that the memory protection mechanisms must be perfectly implemented to allow safe use of multiple applets.
Plans are in the works for smart card applications that cooperate with each other. Imagine, for example, a card that works both as a debit card and as a frequent flyer card. Such plans may introduce more security risk than they are worth. One feature that is in high demand in systems with multiple applications is object sharing. Card Java 2. 0 includes an object sharing approach that includes a loophole. The current approach is described as follows: The JCRE keeps track of the currently selected applet as well as the currently active applet. The currently active applet value is referred to as the applet execution context.
When a virtual method is invoked on an object, the applet execution context is changed to correspond to the applet that owns that object. When that method returns, the previous context is restored. Invocations of static methods have no effect on the applet execution context. The applet execution context and sharing status of an object together determine if access to an object is permissible [Sun Microsystems, 1997]. To illustrate the implications of this approach, consider an example with three applets named A, B, and C as shown in Figure 8. 3. Applet A shares an object it owns, x, with applet B.
Applet B shares an object it owns, y, with applet C. A virtual method in the object owned by B, called y. bar, and shared with C invokes a virtual method in the object owned by A, called x. foo. Now if applet C is selected, it has permission to invoke virtual methods of the object owned by applet B, including the one that in turn invokes the virtual method in an object owned by applet A. In other words, C indirectly invokes x. foo. Figure 8. 3 Sharing a virtual method with another applet is tantamount to allowing that applet complete control over the method. The problem is illustrated here.
Applet A may think it is sharing method foo() only with Applet B, but Applet B can in turn share the method (through method bar()) with Applet C. If A doesn’t want to share with C, this may be a problem. PLEASE NOTE: In the above image, between Applets B and C should read “share (y,C). “| In short, if virtual methods are used, granting an applet permission to access an object amounts to also granting that applet the ability to export indirect access to that object to any other applet. This has a clear weakening effect on any assurance about the protection of an object.
For static methods, such access is prohibited, since static methods do not change the applet context. Restricting virtual methods in the same way that static methods are restricted may add some complexity to sharing schemes. The upshot of this change would be that an applet will be forced to share the object explicitly with all other applets that directly or indirectly need to be granted access permission. By far the biggest risk presented in the design of Card Java is a potential ability for a vendor to add and use Native methods on the platform.
Obviously, this will compromise portability (applets that use Native methods will not be automatically portable to other cards), and it may expose the card to dangerous code that exists outside the applet firewalls. In fact, if Native methods are available, the concept of firewalls deteriorates. Native code is not restricted by the JCRE mediation of access, and misuse is possible. The very real security concern is that an attack applet will make use of Native code to carry out operations that would otherwise be stopped by the JCRE.
When Native code executes, all bets are off for the Java Virtual Machine and its protection mechanisms. Native code in applets completely breaks the idea behind Java security. Attack applets are likely to make use of Native method calls. The five new risks we have covered were introduced into Java with its transformation to Card Java. Although Card Java certainly presents an intriguing new set of risks in terms of security, it does nothing to address several important fundamental security concerns associated with smart cards, including the problem of physical attacks and the terminal problem (both discussed earlier in the chapter).
It is important to keep in mind that the non-Java-related problems have a real impact on card security and that they are not solved by Card Java. Section 8 — Managing Risks| | New functionality in the form of smart cards promises to help solve some tough, real-world problems and address important security concerns. With new functionality, however, comes new risks. The security dilemma remains: How much risk are you willing to take, and to what benefit?
Cite this Java Card Security
Java Card Security. (2018, Jun 21). Retrieved from https://graduateway.com/java-card-security-essay/