status-im
/
status-keycard
mirror of https://github.com/status-im/status-keycard.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
status-keycard/SECURE_CHANNEL.MD

8.7 KiB
Raw Blame History

Secure Channel

Overview

A Secure Channel must be established to allow communication between the applet and the client. This secure channel has the concept of pairing with multiple devices (how many clients can be paired at the same time is defined by the applet). The SecureChannel guarantees protection from snooping, MITM, replay attacks and provides message integrity and authentication for each APDU.

A short description of establishing a session is as follows

  1. The client selects the application on card. The application responds with a public EC key.
  2. The client sends an OPEN SECURE CHANNEL command with its public key. The EC-DH algorithm is used by both parties to generate a shared 256-bit secret (more details below).
  3. The generated secret is used as an AES key to encrypt all further communication. CBC mode is used with a random IV generated for each APDU and prepended to the APDU payload. Both command and responses are encrypted.
  4. The client sends a MUTUALLY AUTHENTICATE command to verify that the keys are matching and thus the secure channel is successfully established.

The EC keyset used by the card for the EC-DH algorithm is generated on-card on applet installation and is not used for anything else. The EC keyset used by the client is generated every time a new secure channel session must be opened.

APDU format

OPEN SECURE CHANNEL

  • CLA = 0x80
  • INS = 0x10
  • P1 = the pairing index
  • P2 = 0x00
  • Data = An EC-256 public key on the SECP256k1 curve encoded as an uncompressed point.
  • Response Data = A 256-bit salt and a 128-bit seed IV
  • Response SW = 0x9000 on success, 0x6A86 if P1 is invalid, 0x6A80 if the data is not a public key

This APDU is the first step to establish a Secure Channel session. A session is aborted when the application is deselected, either directly or because of a card reset/tear.

The card generates a random 256-bit salt which is sent to the client. Both the client and the card do the following for key derivation

  1. Use their private key and the counterpart public key to generate a secret using the EC-DH algorithm.
  2. The generated secret, the pairing key and the salt are concatenated and the SHA-512 of the concatenated value is calculated.
  3. The output of the SHA-512 algorithm is split in two parts of 256-bit. The first part is used as the encryption key and the second part is used as the MAC key for further communication.

The seed IV is used by the client as the IV for the next encrypted APDU.

MUTUALLY AUTHENTICATE

  • CLA = 0x80
  • INS = 0x11
  • P1 = 0x00
  • P2 = 0x00
  • Data = 256-bit random number
  • Response Data = 256-bit random number
  • Response SW = 0x9000 on success, 0x6985 if the previous successfully executed APDU was not OPEN SECURE CHANNEL, 0x6982 if authentication failed or the data is not 256-bit long

This APDU allows both parties to verify that the keys generated in the OPEN SECURE CHANNEL step are matching and thus guarantee authentication of the counterpart. The data sent by both parties is a 256-bit random number The APDU data is sent encrypted with the keys generated in the OPEN SECURE CHANNEL step. Each party must verify the MAC of the received APDU. If the MAC can be verified, it means that both parties are using the same keys. Only after this step has been executed the secure channel can be considered to be open and other commands can be sent. If the authentication fails the card must respond with 0x6982. In this case the OPEN SECURE CHANNEL command must be repeated to generate new keys.

PAIR

  • CLA = 0x80
  • INS = 0x12
  • P1 = pairing phase
  • P2 = 0x00
  • Data = see below
  • Response Data = see below
  • Response SW = 0x9000 on success, 0x6A80 if the data is in the wrong format, 0x6982 if client cryptogram verification fails, 0x6A84 if all available pairing slot are taken, 0x6A86 if P1 is invalid or is 0x01 but the first phase was not completed, 0x6985 if a secure channel is open

P1:

  • 0x00: First step
  • 0x01: Final step

Data:

  • On first step: a 256-bit random client challenge
  • On second step: the client cryptogram as SHA-256(shared secret, card challenge)

Response Data:

  • On first step: the card cryptogram as SHA-256(shared secret, client challenge) followed by a 256-bit card challenge
  • On second step: the pairing index followed by a 256-bit salt

This APDU is sent to pair a client. Pairing is performed with two commands which must be sent immediately one after the other.

In the first phase the client sends a random challenge to the card. The card replies with the SHA-256 hash of the challenge and the shared secret followed by its random challenge. The client is thus able to authenticate the card by verifying the card cryptogram (since the client can generate the same and verify that it matches).

In the second phase the client sends the client cryptogram which is the SHA-256 hash of the shared secret and the card challenge. The card verifies the cryptogram and thus authenticates the client. On success the card generates a random 256-bit salt which is appended to the shared secret. The SHA-256 hash of the concatenated value is stored in the fist available pairing slot and will be further used to derive session keys. The card responds with the pairing index (which the client must send in all OPEN SECURE CHANNEL commands) and the salt used to generate the key, so that the client can generate and store the same key.

The shared secret is a 256-bit value which must be be known to both parts being paired. The exact means of how this happens depend on the specific applet.

UNPAIR

  • CLA = 0x80
  • INS = 0x13
  • P1 = the index to unpair
  • P2 = 0x00
  • Response SW = 0x9000 on success, 0x6985 if security conditions are not met, 0x6A86 if the index is higher than the highest possible pairing index.

This APDU is sent to unpair a client. An existing secure channel session must be open. The application implementing this protocol may apply additional restrictions, such as the verification of a user PIN. On success the pairing slot at the given index will be freed and will be made available to pair other clients. If the index is already free nothing will happen.

Encrypted APDUs

After a successful OPEN SECURE CHANNEL command all communication between card and client is encrypted. Note that only the data fields of C-APDU are encrypted, which means that CLA, INS, P1, P2 for C-APDU are plaintext. This means no sensitive data should be sent in these parameters. Additionally a MAC is calculated for the entire APDU, including the unencrypted fields.

Because R-APDU can only contain data if their SW is a success or warning status word (0x9000, 0x62XX, 0x63XX), when the secure channel is open all responses will have SW 0x9000. The actual SW is always appended at the end of the response data before encryption, which means the client must interpret the last two bytes of the plaintext response as the SW. An exception to this is SW 0x6982, which indicates that the SecureChannel has been aborted and as such is returned without any MAC.

To encrypt the data both the card and the client do the following:

  1. The data is padded using the ISO/IEC 9797-1 Method 2 algorithm.
  2. The data is encrypted using AES in CBC mode using the session key.
  3. An AES CBC-MAC is calculated over the entire APDU data
  4. The data field of the APDU is set to the MAC followed by the encrypted data.

To decrypt the data both the card and the client do the following:

  1. The first 16 bytes of the APDU data are the MAC to be verified
  2. The remaining data is decrypted using AES in CBC mode using the session key.
  3. The padding is removed.

The IV used for the encryption is the last seen MAC from the counterpart. This optimizes the number of transmitted bytes and guarantees protection from replay attacks. For the MAC generation, a zero IV is always used.

MAC generation for C-APDUs is calculated on the concatenation of CLA INS P1 P2 LC 00 00 00 00 00 00 00 00 00 00 00 and the encrypted data field. The 11-byte long padding does not become part of the data field and does not affect LC

MAC generation fo R-APDUs is calculated on the concatenation of Lr 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 and the encrypted data field. The 15-byte long padding does not become part of the response field. Lr is the length of the encrypted response data field and is not transmitted.

Because AES in CBC mode requires the data field length in bytes to be a multiple of 16, the maximum effective APDU size becomes 240 bytes. Of these 16 bytes are used for the MAC and minimum of 1 byte for padding, making the maximum payload size in a single APDU 223 bytes, meaning about a 13,5% overhead.

Error conditions

  1. If a sensitive command is received without an active Secure Channel, the card shall respond with SW 0x6985 ( SW_CONDITIONS_NOT_SATISFIED)
  2. If a MAC cannot be verified the card shall respond 0x6982 and the Secure Channel must be closed