JC101-9C: Authentication and lifecycle

We now have reached the point where we have a fully functional password manager, which is able to store login information. However, this application is not complete, since it does not include any protection of these sensitive assets. Anybody who is able to select the application and who knows the application’s protocol will be able to get all the sensitive information.

The first level of protection is to enforce some kind of user authentication. The sensitive assets will then be available only to authenticated users. In our case, the authentication will be based on a password, since it is the only method that is supported on all Java Card devices.

The fact that the reference password must be initialized will then lead us to discuss the lifecycle of smart cards, and to provide a first introduction to the GlobalPlatform specification.

Authentication

Adding authentication to an application is rather simple, and it involves three distinct activities:

  • Authenticating the user. This simply consists in comparing authentication data provided by the user to reference data stored by the application. In our case, this will consist in verifying a PIN value.
  • Checking authentication. Before processing a protected command, the application needs to check that the user is properly authenticated. In our case, this will simply consist in checking that the correct PIN has been presented in the current session.
  • Managing authentication data. There are at least two items that need to be managed. First, the reference data needs to be initialized. Then, the authentication method may need to be unblocked, if the user blocks its PIN code. In our case, we will simply support the initialization of reference data.

We have here chosen not to include a way to unblock a blocked PIN. The direct consequence is that, if a user blocks a PIN by presenting the wrong password too many times, the application’s data will be impossible to access. This definitely is an issue, and I will justify why I chose not to handle it.

Let’s consider what happens in real life. If you block your (French) banking card, there is a way to unblock the PIN; however, the banks (at least, my bank) will not do it, and they will simply issue a new card. If you block your SIM card’s PIN code (by presenting the wrong PIN 3 times), you need to get a PUK from your operator and to enter it on the phone. And if you enter that code wrong 10 more times, your SIM card is dead.

The main reason for which we haven’t included such a mechanism in our application is that it needs to rely on a trusted third party, i.e., on someone who knows the unlocking code, and who is able to keep it safe from attackers (you don’t want the guy who stole your phone to get his hands on the PUK). This is too complex for our application, which we want to keep personal.

Application lifecycle

As we have mentioned before, there is at least one management operation that we can’t avoid: the reference password needs to be initialized in a way or another. There are two ways to do so:

  • Providing the reference password in the installation process. The PIN code value can be included in the application’s installation parameters, which are passed to the install method.
  • Providing the reference password after the installation process, and before the normal use of the application.

We have chosen to use the second approach, because it corresponds better to the way in which application provisioning is usually performed on smart cards. But let’s first look at the traditional lifecycle of smart cards. There are basically four steps in this lifecycle:

  • Pre-production. In traditional ROM-based cards, most code needs to be developed before the production of the card, including the full operating system and the card’s basic applications (for instance, the SIM application in a SIM card).
  • Initialization. This is the first step in the card’s life after production of the card’s chip. On traditional cards, it includes some testing, as well as the provisioning of non-sensitive data (card identification data and similar information) and, if necessary, the loading of code patches and updates. In open cards, this phase may also include the loading of applications. In flash-based cards, the initialization phase may also include the loading of most of the card’s software. This operation is usually performed during the card production process, when the smart card chips are embedded into modules and cards.
  • Personalization. This last step in the production process consists in loading the sensitive data in the cards. In most cases, this step is performed on actual cards, under the control of the issuer. This task involves the handling of issuer secret data (for instance, cryptographic keys), and it can only be performed by actors that have been certified by the issuer (specialized personalization bureaus, or smart card manufacturers).
  • End of life. At some point, the card reaches its end of life. In some cases, nothing happens. In others, the card is transitioned into a specific state, which may be reversible or not, or which may or not include an audit mode.

With open multi-application cards, this process has become more complex: the platform itself must be personalized, because it manages secrets, and the applications also need to be personalized with their own secrets. And naturally, different application providers do not trust each other, and non of them trusts the card issuer.

Let’s know look in greater details at the steps in the provisioning of an application:

  • Application loading. This phase simply consists in loading the application code into the card, and then linking it to the previously installed libraries.
  • Application installation. In Java Card, this phase simply consists in invoking the static install method declared in an applet class. This is considered to be strongly linked to the loading phase as a part of the card initialization process, and as such, the installation parameters are not expected to include any sensitive data.
  • Application personalization. This phase simply is the translation of card personalization to an application. The application’s secrets are provisioned during that phase, which is performed by specifically certified entities.

You may have noticed that the Java Card specification provides a very limited coverage of this application provisioning process((Basically, this is Chapter 11 of the JCRE specification, in which the notion of installer is defined.)). In fact, all these topics are covered in another specification, defined by the GlobalPlatform consortium.

GlobalPlatform’s mission statement is as follows, and it basically says eveything: Our mission is to establish, maintain and drive adoption of standards to enable an open and interoperable infrastructure for smart cards, devices and systems that simplifies and accelerates development, deployment and management of applications across industries.

The topic of interest here is the GlobalPlatform Card Specification, which defines content management procedures. The current release is v2.2, but most existing cards still remain based on the older v2.1.1 specification. The GlobalPlatform Card Specification is a big one, and it defines many interesting features. Let’s list a few here:

  • Content management commands. These commands are used to load, install, delete applications, as well as other lesser-known operations such as extradition. You are extremely likely to use these commands if you use actual cards.
  • Secure channel management. These secure channels are used to authenticate the various actors, and to then provide integrity and/or confidentiality protection to the content exchanged over the secure channel.
  • Representation of multiple actors. It is possible to associate security domains to every actor represented on the card, regardless of their role (issuer, application provider, certification authority, etc.).
  • Collaboration between actors. It is possible to make various actors collaborate. For instance, an application provider’s security domain may provide a secure channel to one of its applications so that it can perform its personalization. The issuer may also authorize other actors to manage content, or it may onlny delegate content management rights, while keeping some controls on the operations performed.
  • Global services. Many services are provided to applications and security domains, ranging from the management of card and application lifecycles to the management of global PIN codes and many other things.

This list is far from exhaustive, and we will come back to GlobalPlatform later on. In the present case, we will only consider the management of application lifecycles. GlobalPlatform provides a service that includes some predefined states, and it also allows applications to use their own proprietary lifecycle states. The predefined states are as follows:

  • INSTALLED. This is the default state after installing an application. Normally, the application has been instantiated and initialized, but it can still not be selected directly. It may, however, be personalized by its security domain.
  • SELECTABLE. From GlobalPlatform’s point of view, this is the normal operating phase. The application has been initialized, and it can now be selected and process incoming commands.
  • BLOCKED. In this state, the application is blocked. It cannot be selected, but this state is reversible, and the application can be unblocked by its security domain.

Because we want to keep our application independent of other entities, and in particular independent of a security domain, we will not be able to use the INSTALLED and BLOCKED states, which are only useful in a context where the application actively collaborates with its security domain. Instead, we will use the GlobalPlatform-defined SELECTABLE state to represent the state of the card before personalization. We will also define a proprietary PERSONALIZED state to represent the state of the card after personalization, i.e., after initializing the password.

Update of the specification

Finally, we need to update the specification of our application, in order to cover the new feature. The first thing consists in covering the two newly introduced commands.

Verify password

This command is used to authenticate a user by the presentation of a password.

CLA 00, the default value
INS 20, the standard instruction byte
P1 00, RFU in ISO7816-4
P2 80, indicating the use of a local code
Incoming Data The proposed value, without any encapsulation

The incoming data is not structured, since there is a single value to be sent. A command can therefore be very simple, as shown below for a command that presents the password “aBc12E4″. Note that the encoding of the password is outside of the scope of this specification, so users need to be careful to consistently use the same encoding to send information.

00 20 00 80 07 61 42 63 31 32 45 34

The processing to be performed for this command is as follows:

  • Check the application state.
    1. If the state is not PERSONALIZED, send back status word 6985
  • Check the command parameters (P1-P2).
    1. If P1-P2 is not 00 80, send back status word 6A86
  • If there are no more remaining tries (the password is blocked), send back status word 6984
  • If there is no incoming data (Lc=0)
    1. If the password has been successfully verified in the session, send back status word 9000 (success)
    2. Otherwise, send back status word 63cx, where x is the number of remaining tries.
  • Receive the incoming data.
  • Check the value of the password.
    1. If the password length is greater than the maximum password size, send back status word 6A80.
    2. Clear the validated flag.
    3. Decrease the number of remaining tries.
    4. Compare the provided password with the reference.
    5. If they are different, send back status word 63cx, where x is the number of remaining tries.
    6. If they are equal, set the validated flag, reset the number of remaining tries to the maximum number of tries, and send back status word 9000 (success)

The last part consists in defining the possible responses to the message. This is quite simple, since there is no outgoing data (the standard answers are not mentioned here):

Lr Out data SW Outcome
00 None 9000 Password verification succeeded
00 None 6984 Password is blocked
00 None 6A80 Password is too long
00 None 63Cx Password verification failed

Change reference data

This command is used to change the value of the reference data, or to initialize it.

CLA 00, the default value
INS 24, the standard instruction byte
P1 00 for initialization, 01 for for password change
P2 80, indicating the use of a local code
Incoming Data The proposed value in LV encoding, possibly prfixed by the current password value in LV encoding.

The incoming data is lightly structured in LV format, with a length on a single byte, followed by the value itself. There are two different uses of the command. In the SELECTABLE state, it is used to personalize the value of the password. Here is an example that sets the password to “aBc12E4″:

00 24 00 80 08 07 61 42 63 31 32 45 34

In the PERSONALIZED state, it is used to change that value. Here is an example that changes the password from “aBc12E4″ to “1234”:

00 24 00 80 0D 07 61 42 63 31 32 45 34 04 31 32 33 34

The processing to be performed for this command is as follows:

  • Check the command parameters (P1-P2).
    1. If P2 is not 80, send back status word 6A86
    2. If P1 is 00 and the state is not SELECTABLE, send back status word 6A86
    3. If P1 is 01 and the state is not PERSONALIZED, send back status word 6A86
    4. If P1 is neither 00 nor 01, send back status word 6A86
  • If there are no more remaining tries (the password is blocked), send back status word 6984
  • If there is no incoming data (Lc=0)
    1. If the password has been successfully verified in the session, send back status word 9000 (success)
    2. Otherwise, send back status word 63cx, where x is the number of remaining tries.
  • Receive the incoming data.
  • If the length of the incoming data is under 2, send back status word 6700.
  • If P1=0, check the value of the password.
    1. Get the password length (first data byte).
    2. If the length of the incoming data is less than 3 plus that length, send back status word 6700.
    3. If the password length is greater than the maximum password size, send back status word 6A80.
    4. Clear the validated flag.
    5. Decrease the number of remaining tries.
    6. Compare the provided password with the reference.
    7. If they are different, send back status word 63cx, where x is the number of remaining tries.
    8. If they are equal, set the validated flag, reset the number of remaining tries to the maximum number of tries.
  • If all cases, sets the new value of the password.
    1. Get the new password length (next data byte).
    2. If the length of the remaining data is not equal to that length, send back status word 6700.
    3. If the password length is greater than the maximum password size, send back status word 6A80.
    4. Clear the validated flag.
    5. Change the password’s reference value to the new value.
  • If P1=0, set the application state to PERSONALIZED

The last part consists in defining the possible responses to the message. This is quite simple, since there is no outgoing data (the standard answers are not mentioned here):

Lr Out data SW Outcome
00 None 9000 The command succeeded
00 None 6984 Password is blocked
00 None 6A80 password is too long
00 None 63Cx Password verification failed

Changes to other commands

Since we are adding general security measures, some changes are required in the other commands, in order to enforce these new measures. The changes in the processing are quite simple, and they simply consist in adding a prefix to the specification of each command:

  • Check the application state.
    1. If the state is SELECTABLE, send back status word 6D00
    2. If the state is neither SELECTABLE nor PERSONALIZED, send back status word 6985
  • Check the authentication status.
    1. If the password has not been correctly presented in the session, send back status word 6982

We then need to add some possible responses to the message, which will come in addition to those already defined for each command:

Lr Out data SW Outcome
00 None 6D00 If the current state is SELECTABLE
00 None 6985 If the current state is unknown
00 None 6982 Security conditions not satisfied

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *