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.