#Secure Communication

The Direct Protocol supports Secure Communication.

Secure Communication is activated by the PROTOCOL : AUTHENTICATE sequence.

#Principles

#Mutual authentication

The mutual authentication sequence

1. Allows the device to trust the host, and opens the access to functions that requires evelated priviledges such as writing a new configuration,

2. Allows the host to trust the device,

3. Initiate a secure communication channel, with 2 session keys K_ENC and K_MAC generated from the nonces.

Following the mutual authentication sequence on a communication channel, all exchanges on this channel must use secure messaging.

#Secure messaging

Secure messaging involves two concepts:

1. The content of the messages is ciphered (using K_ENC), to protect potentially-sensitive data against eavesdropping,

2. The message are authenticated by a CMAC (using K_MAC and a rolling init vector), to protect the channel against replay attacks, injection attacks, and even against the consequences of a lost message.

In the case of SpringCore Direct, there are 3 endpoints to consider:

• The Command endpoint (BulkOut USB endpoint, Direct_Command BLE characteristics) in the host to device direction,
• The Response endpoint (BulkIn USB endpoint, Direct_Response BLE characteristics) in the device to host direction,
• The Events endpoint (InterruptIn USB endpoint, Direct_Events BLE characteristics) in the device to host direction.

Every endpoint must have its own rolling init vector, that evolves independently of the init vectors of the other channels.

#Secure messaging over CCID channel

Refer to the CCID (PC/SC) over BLE implementation paragraph for details regarding the secure messaging for CCID over BLE.

Note 1: secure messaging is not available for CCID over USB (but mutual authentication is).

Note 2: in the case of CCID over BLE, the CCID_Status endpoint does not provide secure messaging (CCID_PC_To_RDR and and CCID_RDR_To_PC endpoints do).

#Cookbook

Both the host and the device shall maintain three init vectors:

• IV_COMMAND for the Command endpoint,
• IV_RESPONSE for the Response endpoint,
• IV_EVENTS for the Events endpoint.

After the authentication sequence, the three init vectors are initialized to IV₀ (see PROTOCOL : AUTHENTICATE for the definition of IV₀).

#Command endpoint

#Sender rules (host)

1. Create a valid SpringCore Direct Command message as usual, but set bit 5 (Secure) of PCB to 1 in the Header,

2. Compute CMAC = E_CBC ( K_MAC , Header || Payload || 8000..00 , IV_COMMAND,N )

   where

   • Header || Payload || 8000..00 is the plain message followed by 80 and padded with 00’s to reach a multiple of 16 bytes,
   • IV_COMMAND,N is the current init vector for sending on the Command endpoint. Keep the complete CMAC as IV_COMMAND,N+1 for the next transmission.

3. Add 80 at the end of the Payload and add as many 00’s as needed to reach a multiple of 16 bytes; adjust the LEN field in the header accordingly,

4. Cipher the Payload (not the Header!): Payload_CIPHER = E_CBC ( K_ENC , Payload_PLAIN || Padding , IV_COMMAND,N ),

5. Increase the LEN field in the Header by 8 bytes,

6. Transmit the 8 first bytes of the CMAC at the end of the message.

#Receiver rules (device)

1. Recognize a secure message from the bit 5 set in PCB,

2. Decrease the value of LEN by 8,

3. Decipher the Payload: Payload_PLAIN || Padding = E^-1_CBC ( K_ENC , Payload_CIPHER , IV_COMMAND,N )

4. Verify that the Padding is OK, decrease the value of LEN to drop the Padding bytes,

5. Compute CMAC = E_CBC ( K_MAC , Header || Payload_PLAIN || 8000..00 , IV_COMMAND,N )

   where

   • Header || Payload_PLAIN || 8000..00 is the plain message padded to reach a multiple of 16 bytes,
   • IV_COMMAND,N is the current init vector for receiving on the Command endpoint. Keep the complete CMAC as IV_COMMAND,N+1 for the next reception.

6. Verify that the 8 first bytes of the computed CMAC match with the ones received.

#Response endpoint

#Sender rules (device)

1. Create a valid SpringCore Direct Response message as usual, but set bit 5 (Secure) of PCB to 1 in the Header,

2. Compute CMAC = E_CBC ( K_MAC , Header || Payload || 8000..00 , IV_RESPONSE,N )

   where

   • Header || Payload || 8000..00 is the plain message followed by 80 and padded with 00’s to reach a multiple of 16 bytes,
   • IV_RESPONSE,N is the current init vector for sending on the Command endpoint. Keep the complete CMAC as IV_RESPONSE,N+1 for the next transmission.

3. Add 80 at the end of the Payload and add as many 00’s as needed to reach a multiple of 16 bytes; adjust the LEN field in the header accordingly,

4. Cipher the Payload (not the Header!): Payload_CIPHER = E_CBC ( K_ENC , Payload_PLAIN || Padding , IV_RESPONSE,N ),

5. Increase the LEN field in the Header by 8 bytes,

6. Transmit the 8 first bytes of the CMAC at the end of the message.

#Receiver rules (host)

1. Recognize a secure message from the bit 5 set in PCB,

2. Decrease the value of LEN by 8,

3. Decipher the Payload: Payload_PLAIN || Padding = E^-1_CBC ( K_ENC , Payload_CIPHER , IV_RESPONSE,N )

4. Verify that the Padding is OK, decrease the value of LEN to drop the Padding bytes,

5. Compute CMAC = E_CBC ( K_MAC , Header || Payload_PLAIN || 8000..00 , IV_RESPONSE,N )

   where

   • Header || Payload_PLAIN || 8000..00 is the plain message padded to reach a multiple of 16 bytes,
   • IV_RESPONSE,N is the current init vector for receiving on the Command endpoint. Keep the complete CMAC as IV_RESPONSE,N+1 for the next reception.

6. Verify that the 8 first bytes of the computed CMAC match with the ones received.

#Events endpoint

#Sender rules (device)

1. Create a valid SpringCore Direct Events message as usual, but set bit 5 (Secure) of PCB to 1 in the Header,

2. Compute CMAC = E_CBC ( K_MAC , Header || Payload || Message || 8000..00 , IV_EVENTS,N )

   where

   • Header || Payload || 8000..00 is the plain message followed by 80 and padded with 00’s to reach a multiple of 16 bytes,
   • IV_EVENTS,N is the current init vector for sending on the Command endpoint. Keep the complete CMAC as IV_EVENTS,N+1 for the next transmission.

3. Add 80 at the end of the Payload and add as many 00’s as needed to reach a multiple of 16 bytes; adjust the LEN field in the header accordingly,

4. Cipher the Payload (not the Header!): Payload_CIPHER = E_CBC ( K_ENC , Payload_PLAIN || Padding , IV_EVENTS,N ),

5. Increase the LEN field in the Header by 8 bytes,

6. Transmit the 8 first bytes of the CMAC at the end of the message.

#Receiver rules (host)

1. Recognize a secure message from the bit 5 set in PCB,

2. Decrease the value of LEN by 8,

3. Decipher the Payload: Payload_PLAIN || Padding = E^-1_CBC ( K_ENC , Payload_CIPHER , IV_EVENTS,N )

4. Verify that the Padding is OK, decrease the value of LEN to drop the Padding bytes,

5. Compute CMAC = E_CBC ( K_MAC , Header || Payload_PLAIN || 8000..00 , IV_EVENTS,N )

   where

   • Header || Payload_PLAIN || 8000..00 is the plain message padded to reach a multiple of 16 bytes,
   • IV_EVENTS,N is the current init vector for receiving on the Command endpoint. Keep the complete CMAC as IV_EVENTS,N+1 for the next reception.

6. Verify that the 8 first bytes of the computed CMAC match with the ones received.