JC101-19C: Secure channel protocol

Starting a session

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 a1 … a16 to Bob.
  2. Bob replies with his own 16-byte random number b1 … b16.
  3. Alice and Bob both encrypt a1 … a16 with their shared secret, getting the value α1 … α16.
  4. Alice and Bob both encrypt b1 … b16 with their shared secret, getting the value β1 … β16.
  5. The session key becomes α9 … α16 β1 … β8.
  6. Alice sends the value β9 … β16 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 … α8 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.

CLA 00, the default value
INS 38, our own instruction byte
P1 00, The current step, 00 for random data exchange, and 01 for the authentication step.
P2 80, 00, and also RFU.
Incoming Data On step 00, the random value a1 … a16 sent by the terminal; on step 01, the authentication value β9 … β16 encrypted with the session key.

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.
Lr Out data SW Outcome
10 b1 … b16 9000 On step 00, the outgoing data is the random value returned by the card.
08 α1 … α8 9000 On step 01, the outgoing data is α1 … α8, encrypted with the session key.
00 None 6A80 Data is not as expected
00 None 6984 Terminal authentication failed

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.

CLA 00, the default value
INS 3A, our own instruction byte
P1 00, The MSB of the command sequence number.
P2 80, LSB of the command sequence number.
Incoming Data 251 bytes, including the protected command, followed by some random padding and by a cryptographic checksum.

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.

Lr Out data SW Outcome
F8 Encrypted response of the other command 9000 All outcomes

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.

CLA 00, the default value
INS 3C, our own instruction byte
P1 00, as RFU
P2 00, as RFU
Incoming Data 8 bytes, including the sequence number, encrypted by the session key

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.

Lr Out data SW Outcome
10 Encrypted session control value 9000 Success
00 None 6700 Received other than 8 bytes
00 None 6984 Wrong sequence number

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.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *