Let’s start by secret keys, used in symmetric algorithms like AES and DES. Such keys are just random values of a given length, without any strong mathematical property((Keys must verify some properties, though, as some values will not provide an adequate protection; however, the probability to get one of these keys is quite low, and no test is usually performed on the keys that are generated on a smart card.

A secret key therefore starts its life as a byte array filled with random data. For a triple DES key, we need 16 bytes of data. Two origins are possible for this data: it may be imported from the outside through a personalization command, or it may be generated on the card using a random number generator. Here is an example using a RNG:

  byte[] keyBytes = JCSystem.getTransientByteArray(COD,16);
  RandomData rng = RandomData.getInstance(ALG_SECURE_RANDOM);

  rng.generateData(keyBytes,0,16);

The next step consists in creating the key object and assigning the random data to the key object:

  DESKey key = KeyBuilder.buildKey(ALG_DES, LENGTH_3DES_2KEY);
  key.setKey(keyBytes);

When that is done, the essential is done. At this point, applet developers are not responsible any more for the protection of the key. The Java Card platform is in charge of implementing the key container classes in a way that protects keys from disclosure at all times (when they are stored and when they are used). In most cases, this means that the key values will be encrypted using another key, managed by the platform.

Applet developers should refrain from any attempt to protect cryptographic keys when they are stored in Key objects. However, the values of keys still need to be protected, whenever they are not stored in the proper containers. For instance, the raw data used to initialize the key should be cleared after the initialization. The initialization code therefore is as follows:

  try {
    rng.generateData(keyBytes,0,16);
    key.setKey(keyBytes);
  } finally {
    Util.arrayFillNonAtomic(keyBytes,0);
  }

With private keys (used in assymetric algorithms like RSA), things are even simpler, since there is a dedicated class to generate key pairs (a public key and a private key). This means that the actual key values are kept during the entire process under the protection of the platform.

Basically, the two rules about keys are:

• Keys stored in Key container are protected by the platform, and only by the platform.
• Plaintext key values should not be stored in byte arrays, expect for very short periods of time when absolutely needed, and the values should be cleared when then are not used any more.

Following them is a good start in the proper protection of cryptographic keys.

The NFC Forum has recently added the possibility to include a signature record in tags. Adding such a signature can be used to ensure that the content of the tag (say, a URL) has been written by the person who sign it, and not modified afterwards. OK, so what does such a signature really bring in terms of security?

Well, I must admit that I am not really sure. Of course, one of the reasons is that I am yet to see a phone that verifies these signatures; I may also not have all the information. So far, I have read the NDEF spec, and the thesis by Markus KilÃ¥s on this topic. So, let’s say that this entry will get modified at some point.

Let’s continue with the URL example, on a very simple, innocuous example: a tag in Nice that contains a URL pointing to explanations about the Ste-Reparate Cathedral. If this tag is signed, then we can expect that a mobile phone would verify the signature before to forward the URL to the browser. However, the mobile phone would also be able to read unsigned tags.

Let’s now consider the two main attacks on this kind of tags:

• Cloning. The entire record can be read freely, so a signature doesn’t protect at all against cloning. A Nice supporter may be able to put a Ste-Reparate tag on a Notre-Dame de Paris poster.
• Tag replacement. The signature does not protect against this. If a Paris supporter comes to Nice, removes the Ste-Reparate tag and replaces it with a Notre-Dame de Paris tag, this will work with a browser. Of course, the phone may display a small “Trusted” icon for a recognized signature, but unless all tags rapidly become signed, I doubt that users will notice this icon any time soon.

So, my conclusion is that signatures are likely to be useless for this URL use case, at least before the industry reaches a global agreement on a way to define how signatures should be handled on phones.

Of course, signatures may still be very useful in proprietary applications, which may be used in the industry. In such cases, the signatures will be verified by a specific application. In that case, it would solve part of the tag replacement attacks, since it would mean that a tag from a given company could only be replaced by another tag from the same company (or a clone of it). This means that a good level of tamper-evidence will also be required.

Not really good looking so far, but if I have missed something, I would be really glad to update this to something more positive.

NFC is red hot these days, and NFC phones are starting to come out. So, what kind of attacks can we do with these phones? Are there really new things? Let’s try to look at a few things.

First, let me recall a few things about NFC. NFC is a complex standard, with several modes of operation. To simplify things, we will only consider two:

• Reader mode. In that case, the phone acts as a card/tag reader. This mode is activated by default, and will be used in particular to detect smart posters and other fun things of the sort.
• Card emulation mode. In that case, the phone acts as a smart card. You can use your phone as a payment card (for instance, using an EMV protocol), or as a transport card. This mode is usually not active by default. In card emulation mode, the applications typically run on a Secure Element (SE), which may be the UICC (SIM card), an Embedded Secure Element (soldered on the phone), or even a removable Secure MicroSD card (not yet widely supported, though).

The first attack that most people think about is the unintended use of the smart card emulation applications. This is quite strange, because this is definitely an aspect in which the use of NFC enhances security. When you have a contactless card in your pocket, this card is always active; if it gets in a proper field, it will wake up and (maybe) start a transaction. With a NFC phone, it is possible to deactivate the listening; in that case, the phone will only listen after an explicit action from the user (for instance, starting a payment application). You don’t have to do that, and you can also leave your phone activated by default. This is a compromise between security and ease of use that is left to the end user’s decision. However, in all cases, the security is at least as good as what you get with a standard contactless card.

The next category of attacks comes from mobile applications, still in card emulation mode. Why mobile applications, since the card emulation applications run on a Secure Element? Well, the applications are running on a mobile phone, and mobile phone users are expecting some kind of interaction when they use their phone. For instance, when doing a payment, the user would expect some message on the screen explaining that there is an ongoing payment. And this message is quite likely to be displayed by a mobile application.

In most NFC phones, an event is triggered when an application is selected on a SE. This event can then be forwarded to an application. That’s when things get interesting: if this mobile application wants to display interesting information to the user, it will need to interact with the SE application. This means that it should be able to use a SE Access API. If this API is not well secured, it’s an open bar for attackers, who can select an application, send commands to any applications, etc. Of course, if the SE applications are well secured, there is not much to do, except denial-of-service attacks. But then, that already is a combination f two “if”‘s: a bit much for security.

Securing a SE Access API is easy in principle. You can for instance take a look at JSR-177, which proposes a solution that works very well. More precisely, it works will on the UICC, because the UICC belongs to the mobile operator, and the use of JSR-177 requires a signature by the mobile operator. Now, if a bank wants to deploy an application on a MicroSD, does it want to depend on a mobile operator? Maybe not.

Similar problems occur everywhere. If Apple does NFC on iPhone, they are quite likely to include an embedded SE that they will tightly control, and the problem for the bank will be the same, replacing the operator by Apple. On open systems like Android, the problem is different but not easier: in a system based on self-certification, who is in charge of enseuring that secure elements are not abused? These things will be clarified, but we can expect to have some room for attacks here, at least in the beginning. Of course, this does not mean that interesting attacks are feasible, as that depends on the target applications. Since the first applications will be ports of well-known card applications, the expectations should not be too high.

The last potential attack that I will mention is about tag reading. It may be possible to “hijack” a tag reading through a mobile application, and replace the content of the tag with another content, for instance linking an ad to an activist site fighting the advertiser. As long as tags are used for advertising, such attacks will be just fun, but they may get more interesting if tags are used for more sensitive applications. Note that very similar attacks already exist today with QR-codes.

This is definitely not a complete list, and I am sure that a few unexpected things will happen with NFC, leading to vulnerabilities, attack paths, and interesting work. We’ll see.

You have been warned in the previous posts. The Connected Edition of Java Card 3.0 is very different from Java Card 2.x. But, how exactly are these two versions different? Well, there are differences at all levels, from the virtual machine to the application model and the deployment framework.

So, let’s take a close look at all these differences, going from the low-level to the high-level differences.

At the virtual machine level

At the virtual machine level, the main difference is that the Java Card virtual machine is now strongly inspired from the 32-bit CLDC virtual machine, with which it shares a lot of characteristics. Among these characteristics, we have:

• 32-bit integer by default. Yes, some of the casts are now gone for good, as Java Card 3.0 now performs 32-bit computations.
• More basic types. Java Card 3.0 now supports all standard integral types, including the (unsigned 16-bit) char and (signed 64-bit) long types.
• Mandatory bytecode verification. A serious security flaw is now gone, and reverse engineering a Java Card 3.0 card may well be a difficult task. Since the inspiration comes from CLDC, the verification uses precomputed stack maps.
• Standard distribution formats. Java Card 3.0 classes are compiled into class files, which are distribution inside JAR files, using standard encoding and compression.

However, some things still didn’t come to Java Card. For instance, don’t expect any floating-point numbers, as there is little use for them, and the hardware coprocessors remain a bit too expensive.

At the runtime environment level

At the runtime environment level, there is one major change, memory management. Java Card 3.0 explicitly supports temporary objects, and objects are made persistent when they become reachable from a “persistence root”. The consequence is that it is now possible to allocate objects temporarily in RAM, and they will even be automatically garbage collected.

The transaction model has also been greatly enhanced, and it is now possible to use nested transactions, using a very flexible model. In particular, it is now possible to write libraries that use transactions in a clean way.

Finally, the sharing model has been enhanced. The firewall is still around, and the basic sharing mechanism remains the same. However, it has been complemented by a few mechanisms that allow two applications to exchange object instances, making the sharing framework really usable.

At the API level

At the API level, there are quite a few significant additions. The first one is of course the String class, which is quite mandatory is we are to handle HTML pages. Of course, this class does not come alone, and StringBuffer and a few other friends are also present.

In fact, a significant subset of java.util is present. In particular, it is now possible to manage data with other things than simple arrays, as Vector and Hashtable are available. However, these are the “old” versions of the classes, as the new container framework is too complex.

In addition to these basic utilities, the Generic Connection Framework (GCF) has been imported from the CLDC core library. It allows a Java Card application to open local and network connections, and to use stream-based I/O, which can be very useful, for instance to consume incoming data.

At the security level

The Java Card 2 security model is extremely simplified, mostly because there are very few resources to protect on a small smart card. With Java Card 3, this simplified model is not sustainable, because there are many more resources that need to be protected. Therefore, Java Card 3.0 defines a permission model that provides fine-grained access control to sensitive resources. Permissions are required for many operations, such as network accesses, local file accesses, context switching, shareable object access, and many more.

Naturally, the Web framework also comes with a security framework. Application-level security for Web applications is a subset of the standard servlet security framework, as used on J2EE servers. It controls how Web applications can be accessed from various kinds of clients.

Finally, Java Card 3.0 includes a declarative role-based security model, which separates the declaration of the security rules based on abstract roles, defined at development time, from the mapping of these abstract roles to actual users and authentication means.

At the application level

Naturally, the main change is the new servlet application model, which allow Web applications to be developed and deployed on a Java Card smart card. This change also comes with another related change, at a lower level; Java Card 3.0 now defines a TCP/IP-based communication model, which allows Java Card applications to serve Web requests and to establish connections with the outside using the Generic Connection Framework.

Another important evolution for applications is the enhanced sharing framework. A major shortcoming of the Java Card 2 sharing framework is the fact that it is very difficult to exchange data between applications, because only global arrays can be exchanged (in most cases, this means that only the APDU buffer can be used). Java Card 3.0 addresses this issue by allowing applications to transfer the ownership of some of their objects to another application. With this mechanism, it becomes possible to exchange data safely between two applications. In addition, the fine-grained permissions that control sharing provide an extra protection to applications that share objects.

At the deployment level

In Java Card 3.0, an application is not simply limited to a set of classes. It also includes some static content (Web pages, images, etc.), as well as several descriptors. One of them, the manifest, contains information that should be provided by the person/entity responsible for the deployment of the application rather than by the application developer. This separation of functions facilitates the development of portable applications.

To conclude, we can also recall that, even in its Connected Edition, Java Card 3.0 remains backward-compatible with Java Card 2.x. It remains possible to run all previously developed Java Card 2.x applications. The only constraint is that the binary files need to be converted in a new format.

Beware! As mentioned before, this is only an example, not intended for real use. In addition, the code has not been actually tested so far …

If our secure channel is to be used by several applications, it should be defined in a shared library.

Definition of the API

The first step is here to define the API. The objective of such an API is to bring as little disruption as possible to the applications that use it. We will base our API on a pattern that is inspired from the one used in the GlobalPlatform API.

The main API for applications here contains four methods, as indicated below:

  public short unwrap(APDU apdu);

  public void wrapAndSend(
      APDU apdu,
      byte[] buffer,
      short outOffset,
      short outLen,
      short sw );

  public void processSecurity(APDU apdu);

  public boolean isCommandProtected();

The behavior of these methods is as follows:

• The unwrap() method removes the protection of a method, after verifying its authenticity. It also works for unprotected commands, in which case it does nothing.
• The wrapAndSend() method adds the protection around the response and sends it back. It also work for unprotected commands, in which case it simply sends the response. Note that the response is complete and also includes the status word.
• The processSecurity() method is used to process the commands related to the secure channel protocol. The idea is here to send to it all the commands that the application does not know, and this method will throw the appropriate exception for unknown instructions.
• The isSessionOpen() is used to determine whether or not a session is currently open.
• Finally, the is CommandProtected() method is used to determine whether or not the current command is protected. This method must be called during the handling of commands that require some protection.

This API is quite simple to use, and it does not change significantly the way in which programs should be written. We also have defined a constructor and a few management methods, which are shown below:

  public SecureChannel();
  public void setSharedSecret(byte[] buffer, short ofs);
  public void closeSession();
  public void clear()

The explanations for these methods are:

• The SecureChannel() constructor has no arguments and simply allocates the data required.
• The setSharedSecret() method is used to initialize the shared secret and make the instance ready to be used.
• The closeSession() method is used to abruptly close a session, for instance as part of a security countermeasure.
• Finally, the clear() method clears all information, and in particular the shared secret. It can be used as cleanup or as a countermeasure.

This API is as simple as it gets, and it does not include any optional feature, such as the management of a state for the secure channel instance. The idea is here to keep it as simple as possible.

Example client program

Our example will be some kind of “Hello World” program, with two commands defined: one without security, and one with security. Both commands will do the same thing: return two concatenated copies of the input data.
Let’s start our program with the simple declarations:

package com.vetilles.securehello;

import com.vetilles.security.SecureChannel;
import javacard.framework.*;

public class Hello extends Applet {

It is quite simple and classical, except of course that it imports my library class SecureChannel. We can continue by the definition of constants:

  // The instruction bytes
  private static final byte INS_HELLO        = 0x02 ;
  private static final byte INS_SECURE_HELLO = 0x04 ;

  // The static secret
  private static final byte[] secret =
  { 0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 
    0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F } ;

We here have the two instruction bytes that we expect, as well as a static secret. We have done this in order to keep the program simple, but it definitely is not wise in terms of security, for at least two reasons:

• First, all instances of that class will use the same static shared secret, which makes the application’s security brittle. If the key for a single instance is leaked, then all keys are compromised.
• Then, in a less obvious way, the value of the key is defined as a constant, and as such, it will appear in clear in the binary file for the application (the CAP file, and more specifically here, its static field component). The distribution of this file may be difficult to control, and it is unlikely to be encrypted when it is transferred to the card. In other words, the CAP file is a very bad place to put secrets in.

There is a single field, which is used to hold a reference to the secure channel instance:

  private SecureChannel sc;

Then, the installation sequence (installer and constructor) is very simple:

  public static void install(
    byte[] bArray, short bOffset, byte bLength)
  {
    new Hello().register();
  }

  private Hello()
  {
    sc = new SecureChannel();
    sc.setSharedSecret(secret, (short)0);
  }

The constructor simply allocates a secure channel instance, and initializes its shared secret with the value in the CAP file. Once again, this is not the standard way to go; in a normal application, the initialization of the secret would be part of the application’s personalization process.
We then get to the main command processing method. It starts in a very classical way:

  public void process(APDU apdu) {
    byte[] buffer = apdu.getBuffer();
    short len ;

    if (selectingApplet())
      return;

    switch (buffer[ISO7816.OFFSET_INS]) {

The first instruction is the standard implementation of a command without security:

    case INS_HELLO:
      len = apdu.setIncomingAndReceive();
      len = sayHello(buffer,len);
      apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, len);
      break;

Note that the processing is performed in an external method, which is quite classical. Now, we can look at the secure version of that command:

    case INS_SECURE_HELLO:
      // Receives and unwraps the data
      apdu.setIncomingAndReceive();
      len = sc.unwrap(apdu);

      // Verifies that the command was protected
      if (!sc.isCommandProtected())
        ISOException.throwIt(
            ISO7816.SW_SECURITY_STATUS_NOT_SATISFIED);

      //Processes the command itself
      len = sayHello(buffer,len);
      
      // Wraps the response data
      sc.wrapAndSend(
          apdu, buffer,
          ISO7816.OFFSET_CDATA, len,
          (short)0x9000);
      break;

There are here four steps to be included:

• First, the data is received, and the command is unwrapped. If an attempt is performed to unwrap a command without first opening a secure session, or if the received command is not correct, an exception will b thrown. Otherwise, the command will be simply unwrapped, and its actual length will be returned.
• Then, the application verifies that the command is actually protected. This is very important, since the unwrap method works perfectly on standard commands. It is therefore the application’s responsibility to verify that the command was actually protected.
• The third part is the application processing itself, which has not been modified.
• The fourth and final part is to wrap the response data and then send it out, to finish the processing.

The last item in the switch will handle all other incoming commands:

    default:
      sc.processSecurity(apdu);

The processSecurity() method handles all the secure session management commands, and rejects all the other ones.

This example is very small, and it shows the difference between a protected command and a non-protected command. Note that there is no real need to distinguish between the two, as the “unwrap” and “wrap” methods are designed to work on standard commands. All we have to do is here to modify the test that verifies that the command is protected to only require encryption if a session is open:

      // Verifies that the command was protected
      if (!sc.isCommandProtected() && sc.isSessionOpen())
        ISOException.throwIt(
            ISO7816.SW_SECURITY_STATUS_NOT_SATISFIED);

This small change shows how important that test about the status of the command is. Note that the very common GlobalPlatform API uses a similar architecture, in which the same kind of tests is required.

Two editions

As mentioned earlier, Java Card 2.x represents 5 billion cards today, and over a billion are issued each year. This represents a very significant part of the smart card business in volume, and an even larger part in value, because Java Card is typically included in high-end cards.

Not a single salesperson would take a chance to disturb such a significant market by forcing their customers to switch from a technology to a radically different one, which also happens to be more expensive. In fact, this is exactly what the smart card industry is doing, and the reason for these two editions: one of them caters to the existing smart card market, whereas the other one targets a future market of IP-connected smart cards and related devices.

Classic Edition

The Classic Edition, as we can guess by its name, is a direct successor to the Java Card 2.2.2 specification. In practice, the changes are so small that its normal name (with the Java Card numbering rules) should have been Java Card 2.2.3. Nothing really new has been introduced.

The changes can be summarized in a few lines. Apart from fixing typos and small bugs, the Classic Edition only introduces support for a few new cryptographic algorithms (like RSA 4096), as well as slight improvements in which contactless transactions are handled, and improvements in the handling of the ISO7816-4/2005 specification.

Java Card 3.0 Classic cards therefore behave exactly like Java Card 2.x cards. They are based on the same 16-bit virtual machine, with the same restrictions (no threads, no garbage collection), the same very limited APIs, and the same single application model. They solely target APDU-based applications (contact or contactless), just like their predecessors.

Classic cards are also backward compatible with older cards, even at the binary level. There is no need to recompile your applications, and not even to reconvert them. Existing CAP files will run directly on Java Card 3.0 Classic cards, without modifying a single bit.

The objective is here to keep a product for the billion cards per year market that comes for Java Card 2, and that has a few more years of existence. Over the years, the proportion of Classic cards is expected to decrease, and eventually to become a platform for low-end cards.

Connected Edition

The Connected Edition is the real Java Card 3.0, i.e., the really new specification, with a new virtual machine, a new application framework, and everything else.

The Connected Edition includes a 32-bit virtual machine, it can run multiple threads, it includes a much larger API, it includes real garbage collection, and many other things. As a consequence, it is much more complex than the Classic Edition, and it targets the most sophisticated chips available in 2009 (note that this situation is better than Java Card 2’s situation 10 years ago, for which no reasonable chip existed at the time).

In terms of applications, the Connected Edition introduces IP-based Web applications, a significant change from existing smart card applications, corresponding to the new uses of computing, in which the client often is a generic browser, which gathers information from a variety of information sources, a.k.a. servers. Connected Edition defines the way in which we can all have one (or many) personal servers that handle our personal and sensitive data.

Even with these major changes, Java Card 3.0 remains backward compatible with existing Java Card 2.x applications. However, this compatibility is only possible at the source code level. A Java Card 2.x application needs to be recompiled and packaged into a Connected Edition binary format (some kind of JAR file). After that, it will work correctly; the specification even allows it to interact (in a limited way) with new applications.

The Connected Edition does not target a well-defined market, as it includes a new application model, and includes specifications that do not correspond to any immediate market demand. For instance, Oberthur’s Gigantic Wuaow, which got a Sesames Award last year, is a big SIM card with a USB interface. The corresponding standard for phones exists, but not a single device is available at the beginning of 2009. The Connected Edition therefore remains a forward-looking technology, who stands significant chances to become a major component of tomorrow’s cards, but still needs to prove its worth.

Nevertheless, this tutorial on Java Card 3.0 will focus almost exclusively on the Connected Edition, which includes all the innovation in this new spec release.

Protocol

For our session start, we will here use a classical architecture, but with slightly different commands. First, here is a definition of the exchanges between two actors (say, Alice and Bob) to start a secure session:

1. Alice sends a 16-byte random number to a₁ … a₁₆ to Bob.
2. Bob replies with his own 16-byte random number b₁ … b₁₆.
3. Alice and Bob both encrypt a₁ … a₁₆ with their shared secret, getting the value α₁ … α₁₆.
4. Alice and Bob both encrypt b₁ … b₁₆ with their shared secret, getting the value β₁ … β₁₆.
5. The session key becomes α₉ … α₁₆ β₁ … β₈.
6. Alice sends the value β₉ … β₁₆ to Bob, encrypted with the session key, as a proof of authentication.
7. Bob verifies that the value is correct.
8. Bob then sends the value α1 … α₈ to Alice, encrypted with the session key, as a proof of authentication.
9. Alice verifies that the value is correct.
10. The session has started.

I will not attempt to prove that this algorithm has many interesting properties, but I will just highlight a few of its features:

• In steps 1 and 2, both Alice and Bob generate random data that is used in the session startup process, and the session key depends on both sets of random data, as a measure against replay attacks.
• In steps 3 and 4, the simple encryption used here can be replaced by a more complex algorithm, in order to make it more difficult for an attacker to derive the shared secret from a session key.
• The value returned by Alice to Bob on step 6 (and vice-versa on step 8) as proof of authentication shows that Alice got Bob’s random data, and that Alice knows the shared secret.
• The value returned in steps 6 and 8 are both encrypted with the session key, in order to avoid giving away precious information about the shared secret to a potential attacker.

APDU commands

The next step is to transform this protocol in a sequence of APDU commands exchanged between a card terminal (as Alice), and a card (as Bob). Standard commands exist to do that (INITIALIZE UPDATE and EXTERNAL AUTHENTICATE). However, since our protocol is specific, I will define a specific command to do so, that I will call START SECURE SESSION.

The algorithm to process a command is as follows:

• If P1≠00 and P1≠01, return status word 6A86.
• If P1=00, manage step 00, the generation of random data.
  1. If Lr≠16, return status word 6700.
  2. Copy received data; generate 16 bytes of new random data.
  3. Compute the new session key, and the card’s authentication data.
  4. Send the 16 bytes of new random data, with status word 9000.
• If P1=01, manage step 01, the authentication step.
  1. If Lr≠8, return status word 6700.
  2. Compute expected authentication data, and compare it to received one.
  3. If the comparison fails, return 6982.
  4. Otherwise, encrypt card’s authentication data with the session key, and return it to the terminal with status word 9000.

Exchanging messages

Protocol

During a session, some security features need to be added to the messages exchanged between the card and the terminal. We will need to do two things here:

• Encrypt the content of the command or response in order to protect the confidentiality of its content.
• Include a cryptographic checksum of the command or response in order to protect the integrity of its content.

In order to keep our protocol simple and secure, we will consider the following simple rule for determining whether or not to apply these messages:

• All secure session commands will be considered as embedded in a special SEND SECURE COMMAND command.
• All other commands will be considered as not covered by the secure session.

There is a security rationale behind this. As we have mentioned before, attackers may analyze the commands sent to the card in order to get some information for their attacks. By always using the same command to send secure commands, we provide an elementary protection against this. We will even go a little further by doing the following:

• Incoming data will always be 251 bytes, regardless of the actual size of the command data (we leave five bytes for the original header).
• Similarly, outgoing data will always be 255 bytes, regardless of the actual size of the response data.

Of course, such a protocol introduces some overhead. For instance, here, the overhead will be 6 bytes for the header data plus 8 bytes for the command’s cryptographic checksum, leaving a maximum of 241 actual bytes of incoming data. For outgoing data, the overhead will be 3 bytes for the header (status word and length), and 8 bytes for the the response’s cryptographic checksum, leaving a maximum of 244 actual bytes of outgoing data.

Another important point is that we want to make sure that no command can be lost during a secure session. Since we are defining a specific command, we have several ways to do that, including:

• Managing a session command counter. A counter is increased at every command, and checked on the card. The counter value must be included in the data protected by the command signature.
• Change the session key for each command. This is a very common way of dealing with this issue, which has other advantages, like the fact that the key changes for each command.

In order to keep things simple, we will here use a command counter.

APDU commands

We can now define the handling of the SEND SECURE COMMAND command.

The algorithm to process a command is as follows:

• If the concatenation of P1 and P2 is not equal to the expected sequence number (previous one plus one)
  1. Close the secure channel session.
  2. Return status word 6A86.
• If Lr≠251, return status word 6700. Otherwise, receive the data.
• Verify the cryptogram and decrypt the command data.
  1. Compute the signature of the 248 first bytes of the APDU buffer using the session key in CBC mode.
  2. Compare this value to the 8 last bytes of the command.
  3. If the values are different, close the secure channel session, and return status word 6982.
  4. Otherwise, decipher the first 240 bytes of command data into the 240 first bytes of the APDU buffer.
  5. If the 5th byte of the APDU buffer (Lr of secure command) is 0, replace it with the 6th byte of the APDU buffer (Le of secure command).
• Process the secure command normally.
• When the outgoing data is ready to be sent, together with the status word,
  1. If the length of the outgoing data is greater than 237, replace it with a 0-length data and a status word of 6A80.
  2. Copy the outgoing data into the APDU buffer, starting at offset 3.
  3. Copy the provided status word into the APDU buffer at offset 0.
  4. Copy the length of the outgoing data into the APDU buffer as an unsigned byte at offset 2.
  5. If necessary, fill with random data up to offset 240.
  6. Encrypt these 240 bytes on place with the session key.
  7. Compute a digital signature of these 240 bytes using the session key in CBC mode, and store it at offset 240 of the APDU buffer.
  8. Send the 248 bytes of data, with a status word of 9000.

This description deserves a few explanations about the use of the DES algorithm, which will be provided in the section about implementation.

Closing a session

Protocol

The final step of the secure channel protocol is the closing of a session. The objective is here to get a token that proves that the entire session has taken place, and that the session can be considered as successful.

In order to do that, we will use a value that is a XOR of all the digital signature computed during the session, on 16 bytes (8 bytes for incoming command signatures, 8 bytes for outgoing responses signatures).

Upon receipt of a specific command, which will includes a signature computed by the terminal, the card will return this control value, encrypted with the session key. This value could then be used as a proof that the session actually took place, and that it contained a given set of commands.

APDU commands

The first thing to do is to update the handling of the SEND SECURE COMMAND APDU command, in order to include in it the management of the session control value, which should be updated during the handling of each command.

The next thing is to define the CLOSE SECURE SESSION command that will be used to close a session and get the session control value.

The algorithm to process a command is as follows:

• If Lr≠8, return status word 6700. Otherwise, receive the data.
• Decrypt the command data and verify it.
  1. Decipher the 8 bytes of command data.
  2. Compare the 2 first bytes of data to the current sequence number.
  3. If they are different, close the secure channel session and return the status word 6984.
• Send the control value.
  1. Copy the control value data into the APDU buffer, starting at offset 0.
  2. Encrypt these 16 bytes on place with the session key.
  3. Close the secure session.
  4. Send the 16 bytes of data, with a status word of 9000.

This description deserves a few explanations about the use of the DES algorithm, which will be provided in the section about implementation.

Wrap-up

We have provided a definition of a secure channel protocol, as an exercise to better understand the principles of smart card security. Although this protocol has been designed with security in mind, it hasn’t been subjected to any kind of peer review, and I don’t even claim to have all the skills required to design a secure channel protocol that can withstand the current stats-of-the-art of cryptographic attacks.

So, please, don’t even think about using this secure channel protocol directly in a smart card application, without first submitting to an in-depth analysis by a security professional with a strong cryptography background, as it may include major flaws.

And if you can’t have this review performed, you are always better off to use a well-known, standard protocol, like those offered by GlobalPlatform, which are available on almost all cards available today, and that have been subjected to a great deal of scrutiny in the past few years.

Be careful, this is not a tutorial on cryptography. I am not a cryptography expert, and I will just repeat basic ideas. If you want to learn about cryptograpy, consider getting a book like this Bruce Schneier Compilation

The shared secret

An essential part of most secure channel protocol is the shared secret (in our case a cryptographic key), and the way in which this secret is protected from disclosure. An attacker is likely to try to get the secret in order to break the protocol. There are two very important properties of the protocol and its keys:

• Strength. The key strength is usually measured by the number of possible values for the key, which can be considered proportional to the time required to break a single key.
• Resilience. The resilience of a protocol is about the consequences of a successful attack. If Charlie is able to find the encryption key for a message, will he be able to decipher all messages between Alice and Bob? Will he also be able to decipher the messages exchanged by all users of the same protocol? If a protocol is able to limit the consequences of a successful attack, it is considered as resilient.

Key strength

Let’s start by the strength; by studying an example. The DES algorithm uses a 8-byte key, in which only 7 bits per byte are used (the last one is used as checksum, or parity bit). This make 56 bits, and the number of possible keys is:

2^56 = 72057594037927936 ~ 7.2 x 10^16

This looks like a large number, but today’s computers are fast. If we consider that it takes one microsecond to try a key on a message, we then need only 7.2×10^10 second, or 2×10^7 hours, or about 2284 years. At first, this sounds good enough, as nobody expects their application to last that long. But then, think about a hacker who controls a botnet with 100,000 computers (apparently, these are quite common). With that many computers doing the work, it will take less than 10 days to break a key. And that is way too small for any serious application.

Protocol resilience

That’s where resilience becomes important. Let’ say that that Charlie has discovered the key used by Alice to encipher a message. If the same key is used for every communication by the protocol, he may be able to decipher all messages exchanged by anybody who uses the protocol. That would definitely be a bad protocol, and an interesting way for an attacker to keep a botnet busy. There are two classical ways to reduce these consequences and make the protocol more resilient:

• Session keys. The idea is here to generate a new key for every session, that will be somehow derived from the shared secret. That way, if Charlie breaks a session key, it will only apply to a single session. If measure are taken to ensure that a session only lasts a limited time (a few seconds are sufficient for most sessions), then the attacker has to be very fast (in our example, it would take a botnet of a billion computers to break a DES key in 20 seconds; and that’s not realistic today).
• Diversified keys. The idea is here to generate a master key that is known by a centralized entity (let’s say, a bank), and to compute a diversified key for every card, for instance by using the card’s number. That way, if Charlie breaks a message sent by Alice, the secret that he will get will only be good for the messages sent by Alice, and not for those sent by anybody else.

Principles of the solution

Now, let’s see what we can do in our case. We will combine a few measures:

• We will use a triple-DES key, i.e., a 16-byte key from which 112 bits are used (you can do the computation that shows that such a key is quite difficult to break).
• We will use diversified keys, i.e., we will consider that the key used by the each card application instance is in fact computed from a master key and from an instance identification number.
• We will use session keys, i.e., we will compute a specific key for each session, in order to minimize the use of the actual card keys.

Stating this is a good start, but we all have read horror stories about little details that led to the demise of some cryptographic protocol, so there are more things to consider.

Key diversification

The objective of key diversification is to use a single “big” secret to secure a large number of application instances. As mentioned previously, the typical example is a bank, or payment system, in which the master secret is known by the bank, but individual customers only get a diversified key, computed from the master secret and from their account number.

Of course, in a case like that, an attacker may try to guess the master secret by breaking the diversification function. Since the account number (or any number used to diversify a key) must be considered public, the complexity of breaking the master secret only depends on the size of the secret and the strength of the diversification function. Let’s consider a few functions:

• Triple-DES encryption. The idea is here that the diversified key is the result of the encryption of the diversification data by the master key. With today’s technology, this is not bad.
• Triple-DES encryption, after XOR with a secret random number (or any other transformation of the diversification data). This sounds like a good idea, because it makes it impossible for an attacker to check that they have indeed found the appropriate key (since they cannot compare the result of the decrypted diversified key with the diversification data). In fact, it simply forces them to attack two diversified keys at once exercise.
• RSA signature. The idea is the same as the first one, except that the encryption is here performed using a RSA private key. Making the public key available would allow anybody to verify the validity of a diversified key, but this is not interesting (these keys are supposed to be secret). It is therefore better not to disclose the public key.

We have here seen that it is not as obvious as it seems to design such a function. Among the three solutions presented above, I would personally prefer the third one, mostly because it relies on a different technology than the rest of the protocol, which could make it more resilient: if the triple-DES technology is broken, it will have no consequences on RSA, so the diversification algorithm will still be valid.

Anyway, the diversification algorithm is out of the scope of our discussion here, since we are only going to implement the card side of the algorithm, where the key is just considered diversified.

Session key computation

Some of the security issues for session key computation algorithms are similar to those encountered for key diversification algorithms, and in particular the fact that it must be difficult to get to the instance key from a session key.

In addition, session keys are also used to ensure that it is not possible to “replay” a transaction, which means that it must not be possible to generate the same key twice. Since such a replay attack must be impossible for both parties, this means that we will need to use some random data coming from each party.

In addition, the computation of the session keys is normally used at the beginning of a session in order to perform the mutual authentication. Since the computation of the key requires both sides to perform computations using the shared secret, this works out fine.

Next time, we will try to map our protocol to APDU commands.

The push factor

The first reason, of course, is due to a mix of engineering push (we can do it, so let’s do it), and of commercial push (we can get more money out of it, so let’s do it).

The most obvious push factor, though, is Moore’s law. Smart card chips continuously become more powerful, and they pack more and more ptechnologies. Java Card 2 has been designed for 8-bit processors, and 32-bit processors are becoming quite common today. The amount of RAM available has also significantly increased, with 8k being common, and 16-32k becoming available on high-end cards. Persistent memory has also increased, with hundreds of kilobytes of ROM, and large amount of mutable persistent memory (EEPROM or flash). Another important change is the availability of high-speed I/O interfaces, such as USB (soon coming in a SIM card near you).

As the capacities of smart cards increase, the limits of Java Card 2 become more and more visible, in two different ways. First, some applicatione are not possible, or at least are difficult to develop using the Java Card 2 model. Then, as applications become more complex, the usability issues of Java Card 2 become obvious

This leads us to another push factor. 10 years ago, Java Card has been a great progress over existing development techniques for smart cards. It is well suited for small applications, but it is also quite limited, in ways that could be easily fixed on today’s chips. Encoding strings as byte arrays and performing systematic casts feels uselss and outdated, and the demand for an updated programming model grows from developers (this is a push factor, because Java Card developers rarely work for the end customers, but rather for the card manufacturers of for specialized consultants.

Another push factor, and also the most powerful, is the struggle for value inside the mobile phone. All actors strongly believe that mobile computing represents a major opportunity in the coming years, so everybody wants the biggest possible share of the cake. The smart card industry wants to use its long relationship with telcos (SIM cards have represented telcos on mobile phones for quite a while), combined with its experience in handling sensitive applications, to put value-added services on the SIM card, rather than putting them on the mobile phone. Of course, in order to compete with mobile phones, smart card manufacturers ned to put forward a modern programming model that integrates well in today’s Web-everywhere architecture. Hence, Java Card 3 and its servlet model.

The pull factor

Despite all the good reasons to push a new technology, Java Card 3 would not exist if there weren’t a few reasons to believe that there is a market for the technology, i.e., a pull factor.

The first one comes from the mobile operators, who want to enable richer applications, and believe that at least some of them can fit on their SIM cards. They keep pushing for smart card Web servers, because it allows them to keep a provisioning model that they know well from SIM Toolkit, and because it offers a much improved user interaction.

Another important pull factor is NFC. SIM cards are one of the strongest options for implementing NFC, and at least some of the deployments will happen with SIM cards. NFC is also very interesting for smart cards, because it is likely to lead to the deployment of really multi-applicative platforms, possibly with multiple application providers. Once again, the interaction model offered by Java Card 3 represents a strong opportunity, as it will be very tempting to add an interface to these contactless applications. Java Card and GlobalPlatform are at the heart of all NFC deployments, and Java Card 3 is likely to emerge as a natural evolution when more sophisticated interactions will be required, or when more complex applications will be required.

Another factor is slowly building today, but we expect it to become a major argument. Internet security issues put a positive light on every device that provides a feeling of security. Secure tokens based on Java Card 3 are likely to be such devices, and it should be possible to build good hype on this basis, if we are able to provide a real improvement in terms of security.

Targeted markets

As you can guess from the comments above, the key market for Java Card 3, at least as it is perceived today, is the mobile communication market. SIM cards are a strategic asset for operators, they want to add more value to these assets, and smart card manufacturers want to help them (SIM cards represent at least two thirds of their revenues).

The interesting part is that, even though mobile telecom is the targeted market, all other traditional smart card markets are also involved. Mobile payment and mobile banking are two great opportunities, getting a lot of interest these days. This means that the financial sector is also involved. We can say the same thing for mobile ticketing, for mobile V (i.e., mobile DRM), and some government-related applications could also be deployed. With multi-applicatoin SIM cards, it is even possible to think about new smart card applications, even though this does not happen very often, and it is likely that only few applicaionts will succeed.

Another market with interesting potential is IT security. With Java Card 3, a smart card is more likely to be used as a personal secure token, in particular if it is able to provide some protection of personal data. However, the demand on such devices remains unclear today.

We have only mentioned so far emerging or transforming markets. However, today’s Java Card market represents about 2 billion cards per year, and the first priority of the smart card industry is to secure this market for the coming years. This market has a lot of inertia, and innovations take a long time to pick up. Some markets haven’t yet picked up Java Card as mainstream technology; in most cases, these are not ready to move to Java Card 3’s servlet model.

The consequence is here that Java Card 3 must address all smart card markets, from the commodity markets for mass deployments to the high-end markets for early adopters of the Smart Web. We will see in the next post how this has been addressed.

Your first program

If you are going to work with Java Card 3, your first program is quite likely to look something like the following:

public class EchoServlet extends HttpServlet {

  @Override
  public void doGet(
          HttpServletRequest request,
          HttpServletResponse response)
              throws IOException {
    String message =
      request.getPathInfo().substring(1);
    StringBuffer echo = new StringBuffer();
    echo.append(HTML[0]);
    for(int i = 1; i < HTML.length; i++)
    {
      echo.append(message);
      echo.append(HTML[i]);
    }
    PrintWriter out = response.getWriter();
    out.print(echo.toString());
  }

  private static final String HTML[] = {
            "<html><header><title>Echo</title></header>"
         + "<body><center>
    	 + "<h1>Echo</h1><br><br><br>"
         + "<font color=\"#000000\">" , "</font><br>"
         + "<font color=\"#444444\">" , "</font><br>"
         + "<font color=\"#888888\">" , "</font><br>"
         + "<font color=\"#cccccc\">" , "</font><br>"
         + "</center><br><br>"
         + "<small><p align=\"center\">"
         + "Yes, this servlet runs on a Java Card.</p></small>"
         + "</center></body></html>"};
}

Quite a shocker, isn’t it? This doesn’ look at all like a Java Card program. There is nothing specific for card in this program; it could run on any Java EE Web server. On the program, I have outlined a few words that somehow define what Java Card 3.0 is; let’s take a look at them:

• int. Everyobdy expected this one eventually, and here it is. Java Card 3.0 is a pure 32-bit virtual machine, and there is no reason to cast computation into short and byte, expect for storage. Of course, this also means that Java Card 3.0 will only work on chips that include a 32-bit processor.
• String. Another long-time dream of Java Card developers, in particular those working on text-intensive SIM Toolkit applets. Well, strings are supported in Java Card 3.0.
• new. It is nos possible to allocate objects temporarily, i.e., to program in a more standard Java way. This is made possible by the availability of a real garbage collector, and by the fact that some objects are actually stored in RAM. Of course, this also means that Java Card 3.0 will only work on chips that include enough RAM (at least 16 kilobytes).
• @Override. This annotation is not very useful in itself, but its availability means that Java Card 3.0 is based on a recent release of Java, which supports annotations. In fact, Java Card 3.0 is based on the latest release, Java 6, and it includes supports for quite a few advanced features, including generics and others.
• HttpServlet. I have kept the best one for the end. Yes, this application is a servlet, and not an applet. It means that a Java Card 3.0 card is expected to be a Web server, receiving HTTP requests over a TCP/IP connection and answering appropiately with a Web page that will be displayed in your browser.

Now, can we run this application? Of course, we can, and the result is shown below:

A question that often comes to mind about these applications is “Is this still Java Card?” The answer is unclear:

• No, it’s not! It is a Web server, it talks to your browser. It basically supports Java, and there is no Java Card-specific stuff any more.
• Of course it is … This thing runs on a smart card, i.e., on devices that keep the interesting properties of a smart card (secure, portable, cheap, manageable), as well as their drawbacks (too small, too slow). So yes, there is still plenty of Java Card-specific stuff to know about Java Card 3.0 and servlets.

That’s it for today! We will get to the real stuff in a few days or weeks. For now, you have an opportunity to come visit my home turf and learn about Java Card 3.0 by attending Smart University session on The Art of Java Card 3.0 Programming on September 16th and 17th in Sophia Antipolis. If you missed the JavaOne bash, don’t miss this opportunity to meet with the Java Card 3 community. See you there!