Java Card Luminary: Eric Vétillard of Trusted Labs

Print-friendly Version

Java Card Luminary - Eric Vétillard of Trusted Labs answers questions on smart card and Java Card technology.

Dr. Eric Vétillard is the CTO of Trusted Labs, a spin-off from Trusted Logic that provides vendors and operators in the world of wireless communications with security-related services, including conducting risk analyses and managing CC evaluations: certification processes based on the Common Criteria for Information Technology Security Evaluation. His particular responsibility is evaluation of the security of embedded Java platforms and applications – those based on Java Card technology and the Java 2 Platform, Micro Edition (J2ME). Eric has been chief architect at Trusted Logic, and Java architect at Gemplus. He has been an active member of the Java Card Forum since its inception in 1997, and has contributed to all Java Card specifications. He has been working on various development tools and methodologies for more than years. He holds an MS from Florida State University, and a PhD from the University of Marseille. He will present Developing High-Security Java Card Applications at JavaOne 2005.

In this interview, Eric gives us his insights into the future of JavaCard technology and more.

Qusay Mahmoud: What is the most challenging part of your job?

Eric Vétillard: The challenge we face every day is to raise the level of security of the systems used and produced by our customers. For instance, figuring out which security measures should be sufficient to protect our customers and their end users five years from now is quite difficult. And getting device vendors to implement these security measures is even more difficult.

QM: You've been working for companies that deal with smart cards. What is a smart card?

EV: A smart card is a tiny computer, which fits on a single chip. Its name comes from its usual packaging, which has the shape of a credit card. A smart card can be a contact card, in which case there will be contacts on the card. It can also be a contactless card, which is like an RFID tag on steroids. In both cases, it contains a CPU, between 16 and 512Kb of ROM, between 4 and 128 Kb of persistent memory, usually EEPROM, and a few kilobytes of RAM. Many smart cards also include a specialized cryptoprocessor.

A smart card is also characterized by the things it does not have. For instance, it does not include a clock or a power source; it relies on the outside for these things. Its only connection with the outside is a serial link, typically a basic 9600-bps link. Things are evolving fast, however, and USB links are getting more common, just as cards are becoming integrated with large memories, up to several megabytes, as in USB tokens.

QM: How does a smart card work?

EV: A smart card is like a secure personal information server. Most of the time, it simply stores the information in some kind of vault. When it receives requests from the outside world, it responds to these requests, sometimes letting some information out. The important feature is the card's ability to process data. When a card performs a cryptographic computation, the key always remains in the card; it does not need to be copied outside, where it would be vulnerable. This feature is very important, because it allows smart cards to be used as security tokens, which means that they contain some secrets like cryptographic keys and authentication data.

QM: What products and services does Trusted Labs offer?

EV: Trusted Labs offers a range of services around information security, embedded systems, open systems, and formal techniques. In the Java world, we focus on the Java Card and MIDP platforms. In both cases, we work with both vendors and operators. For vendors, we perform specification, design, or code review, and we help them go through CC certifications. For operators, we perform security studies such as risk analyses, and we set up and manage certification programs for both platforms and applications, from the establishment of guidelines to security evaluations. We also offer security training to vendors and operators.

QM: What is Java Card?

EV: Java Card is a technology that enables developers to write smart card applications in the Java programming language, for execution on the many Java Card-compliant smart cards. The Java Card platform is almost 10 years old; it is a mature technology that has been deployed in vast numbers in all smart card application sectors. The bulk of the volume is in the GSM market, where most SIM cards are now Java-powered. After a relatively slow take-off, the banking segment represents a promising area, notably with low-end Java Card platforms for the EMV [Europay, MasterCard, and Visa] migration, after the so-called Visa low-cost programs. The next best opportunity is in the identity and e-passport markets, where Java Card-based pilots are already making significant progress.

QM: What has been the effect of Java Card technology on the smart card industry?

EV: It's been a strong unification force in the industry, allowing most open smart cards to be interoperable today – particularly in the GSM business, where telecom operators faced many interoperability problems at the time the first SIM cards were deployed.

QM:How difficult is it to develop smart card applications?

EV: The first difficulty is the size of the thing, and in particular the very small amount of RAM available on cards. This is a simple engineering problem, however, which can be solved by any decent developer. The real challenge comes from the fact that smart cards are often used as security tokens, which means that the applications must provide a good level of security. For mainstream developers, the issue is to know against which attacks they need to defend their applications. This knowledge is not public, and it is quite difficult to obtain.

QM: How does Java Card technology simplify the task of developing smart card applications?

EV: It frees the application developer from dealing with the low-level layers. For instance, the Java Card API provides a PIN facility, ready for use by developers. Something like a PIN seems easy to implement, but in fact it is quite easy to attack. There aren't that many developers in the world who can program a PIN facility that withstands the efforts of the best laboratories.

QM: In the public eye, smart cards are associated with security. Why is that?

EV: As I mentioned before, smart cards are often used as security tokens. In SIM cards, they contain the keys that authenticate a user to the network, as well as the PIN that authenticates the user to the SIM. Banking applications use them to authenticate all the parties involved in the transaction, and to make cryptographic computations which prove that all parties approved the transaction.

QM: What is differential power analysis (DPA)?

EV: Power analysis is a sequence of observation attacks. The attackers record the power consumption pattern of a card, and try to identify some patterns that will allow them to determine what the card is doing, and even what data it is processing. The objective of these attacks is to find the values of the cryptographic keys used in a computation. The obvious countermeasure against power attacks is randomness. For instance, the chip can introduce random delays in the computation by the chip, making it difficult to identify the power consumption patterns. The chip can also include an element that simply consumes a random amount of power, just to make the measurements more difficult. Asynchronous hardware design is another radical way to achieve the required randomness. Differential power analysis is the attackers' response to randomness. If they collect enough samples and average them, the randomness disappears, and the patterns appear again. It 's like flipping coins: If you keep doing it for hours, you can get as close as you want to 50% heads, 50% tails: the randomness disappears.

QM: How can smart cards be made resistant to such attacks?

EV: This is a cat and mouse game. The implementers design new countermeasures, which spur the attackers to design new attacks. In the case of simple DPA, adding more randomness to the program in the appropriate way is sufficient – but attackers are working on high-order DPA, which will require new countermeasures.

Smart card attacks, however, are not like attacks against PCs. They are hardware attacks, which can be designed only by trained professionals who have access to expensive equipment: very precise laser beams, electron microscopes, and so on. For this reason, most attacks are in fact designed in research laboratories and in evaluation laboratories, rather than by actual attackers.

QM: Tell me about the security certification that smart card applications must undergo.

EV: Security certifications are a natural extension of the classical functional certifications that many products undergo before deployment. In the case of smart cards, security is an especially important factor. Security certifications usually combine two phases. The first focuses on the card's software. The platform and application code are studied, either through a code review in a white-box evaluation, or through extensive tests and logical attacks in a black-box evaluation. The second phase consists of physical attacks. The smart card is given to a test laboratory, which is in charge of performing a predefined list of attacks, based on the results of the first phase.

The immediate objective of a security evaluation is to assess the level of a smart card's resistance. If the card is resistant enough, it gets certified. There is also a long-term objective, which is to enhance the global security level of cards, mostly by warning vendors of vulnerabilities that may affect their products in the future.

QM: What are the most common certification schemes?

EV: There is an ISO standard that defines a certification process called the Common Criteria for Information Technology Security Evaluation, usually shortened to CC. This evaluation process is organized by governments. For instance, in the USA it is organized by NIST and NSA. One advantage of these evaluations is that they are quite complete. A CC evaluation usually includes design and code reviews, full product testing, and significant hardware testing. In addition, because CC is an international standard, the certification of a product acquired in the US may be recognized in Europe or Japan, and vice versa.

Smart cards based on Java Card technology have been evaluated through CC by several vendors, including one at the highest possible level, called EAL7, by Axalto and Trusted Labs. We also have developed with Sun a Protection Profile for Java Card, which helps vendors set up the evaluation of their products.

These evaluations are quite heavy, however, and it is not possible to use them on all products. They are often reserved to products that will be used in government programs, such as national ID and e-passport programs. For this reason, private entities, such as banking associations, usually rely on their own proprietary schemes.

QM: Tell me a bit more about the the proprietary schemes used by the banking associations.

EV: There are many such schemes, but the most well-known are those that Visa and MasterCard use. The objective of these proprietary schemes is to obtain a high level of assurance without requiring the same formality as a CC evaluation. An example is MasterCard's CAST process. To certify a product, a vendor must simply prove that this product satisfies the guidelines defined by MasterCard. This is usually done through a specific evaluation, but the process is flexible enough to accept other forms of assurance, for instance the result of another evaluation, such as a CC evaluation.

QM: What areas should applications developers focus on in order to get their applications certified?

EV: The most important thing is to know your enemy. The most blatant security flaws in smart card applications often result from ignorance: Developers cannot protect against attacks they don't know about. The first step is to get this information, either through a security consulting company or by asking for references to somebody who is involved in a certification process.

The next step is then to apply the recommendations put forward by the experts. It takes a while to get used to it, but programming for security is an interesting and challenging task.

QM: How big is the market for smart card applications?

EV: This is a tough question. The market is significant, but it is very concentrated, in particular in the banking and telecom sectors, which remain dominated by smart card vendors. Things are changing a bit with government-sponsored identity programs, because large integrators control these programs, and they are ready to build a smart card by assembling components from various vendors, with a chip, a Java Card platform, and an application coming from three different vendors. Trusted Logic, our parent company, is quite active in that field, and licensing a Java Card platform implementation to these integrators. And they are not alone: at Trusted Labs, we see more and more products that are built by small software houses.

The smart card application market also has significant growth potential. Multi-application smart cards could be used outside the telecom sector, if somebody came up with a good way to manage a card issued by several actors. Also, the deployment of RFID poses a great opportunity. RFID tags are smart cards, and Java Card-based contactless smart cards, as high-end RFID tags, could have many interesting uses.

QM: How common are smart cards in North America and Europe?

EV: Smart cards are quite common in Europe. I always carry at least five of them with me: two banking cards, one SIM card, one health card, and the access badge to my office. They are less common in North America, but some markets are growing fast, in wireless phones and identity.

QM: Are there any interoperability problems with smart cards and readers produced by different vendors? Are there any working groups in place to address these concerns?

EV: There are plenty of groups available. They compete with each other, and I don't want to get involved in that competition. The good news in this field come from the Java Community Process. With the Security and Trust Services API developed in JSR 177, it is now possible to access a smart card from a MIDP application. And recently Sun has initiated JSR 268, whose objective is to add a smart card I/O API to J2SE. We can hope that in the next release of J2SE it will be possible to communicate with a smart card from any Java-based application.

QM: How dominant is Java Card technology in the smart card market?

EV: The most common platform for running smart card applications is the SIM card, present in every GSM handset. If you have a GSM phone, your SIM card almost certainly contains a few applications, and they are quite likely to be based on Java Card. In other markets, which are most cost-driven, open cards are less common, although a program like Java Card S, which allows vendors to develop low-cost Java Card-based cards, could change things.

QM: What advanced smart card applications are we going to see by 2010?

EV: I think that major innovation can come in the identity and RFID markets. Smart cards are present in many government identity programs, like electronic passports. They are also present in the private identity and authentication market, which could lead to an explosion of multi-application smart cards. The same corporate badge can be used to control physical access, for network authentication, as an electronic purse, and for many other uses. Smart card technology is also likely to be adopted in most applications requiring strong authentication and secure data storage, although not necessarily in the form of a card. I think we'll see this technology in trusted modules, MMC, USB tokens, and other forms. Similarly, RFID is just starting, and I am convinced we will see plenty of very interesting applications.

Of course, these new markets are very dangerous for the smart card industry. Together with well-defined and well-managed applications, we are likely to see a few applications which, knowingly or not, will cause privacy breaches: broadcasting our personal information, or using it for questionable purposes. The smart card industry is now quite mature, however, and it will be able to overcome these growth crises.

QM: Do you have any advice for developers of applications on the Java Card platform?

EV: Forget about the Java programming language at first. All Java Card rookies have the same problem: They write programs that are so beautifully structured that they are too big and too slow for a smart card. When you start, you first have to program for a card, and run your program on an actual card to learn how fast it is. Then, in a second step, you can think again about Java language and program structure, but in the Java Card way, which is quite different from the way developers approach other Java platforms – for instance when applications need to collaborate.

At some point, you also need to think about security. Even experienced smart card programmers have a tendency to be lax about security when they use a high-level language. Regardless of your background, you need to understand the responsibilities of your Java Card-based application, and to assume them.

QM: Any last words?

EV: Yes, I have a strong message for developers. Computer security, just like testing, can be very interesting, and a lot of fun. Working as a tester, or as a security evaluator, is simply another facet of development, which is just as interesting as writing code. Designing a test suite that actually finds bugs is a real challenge. Security is even more interesting, because it is a field that evolves constantly, and in which there is no absolute truth. No product is absolutely secure; our only hope is that it is secure enough for what we want to do with it, and that's what we strive for.

Qusay H. Mahmoud provides Java consulting and training services. He has published dozens of articles on Java, and is the author of Distributed Programming with Java (Manning Publications, 1999) and Learning Wireless Java (O'Reilly, 2002).