Local Chip-to-chip Security

Feature activation

If the module has already completed the bootstrap, the feature shall be enabled before the usage accessing to the u-blox Thingstream platform. 

You are anyway suggested to activate Local C2C feature in your production line, before the bootstrap. Activation before the bootstrap is possible even if the feature has not been activated in the platform. In this case, when the module performs the bootstrap the feature is automatically disabled unless you have enabled it in u-blox Thingstream portal during Device Profile configuration.

C2C encapsulation and encryption protocol

C2C binary encapsulation format

The frame structure of C2C packet exchanged between the MCU and the module is:

C2C encryption protocol

The communication process with the C2C encapsulation and encryption through SEND / RECEIVE is presented below.

Send:

1. step GENERATE DATA CHUNKS from the DATA

• •  - AT commands         - maximum chunk size TBD

  •  - File data in raw mode - maximum chunk size TBD

  •  - Other data in raw mode - maximum chunk size TBD

2. step ECRYPT DATA CHUNK ENCRYPTED_DATA_CHUNK = DATA_ENCRYPTION (k1, k2, TE_SECRET, DATA_CHUNK)

3. step GENERATE C2C FRAME C2C_FRAME = (0xf9, DATA_CHUNK_SIZE, ENCRYPTED_DATA_CHUNK, 0x0000, 0xf9)

4. step ADD CHECKSUM to the C2C FRAME C2C_FRAME.ADD_CHCK_FCS16(C2C_FRAME)

5. step send the frame using the serial interface

Repeat STEPS 2. 3. 4. 5. for every chunk in CHUNKS

Receive:

1. step retrieve a C2C_FRAME by observing the 0xf9 frame start and frame end flag

2. step verify the CHECKSUM of the retrieved C2C_FRAME using the CHCK_FCS16

3. step extract the ENCRYPTED_DATA_CHUNK from the C2C_FRAME

4. step decrypt the ENCRYPTED_DATA_CHUNK to get the DATA_CHUNK

5. step add the DATA_CHUNK to a DATA_CHUNKS_BUFFER

6. interpret the DATA_CHUNKS_BUFFER

Key pairing

It is the process used by MCU to obtain the keys. In this section we will take a look at the process, command s and the functional requirements of local C2C key pairing.

Local C2C key paring process:

Each MCU (if more than one) has its own encryption key obtained as described below:

• Each MCU (if more than one) should generates a <te_secret> and send it to module via “+USECC2C=0, <te_secret>” AT command.

• The module generates the encryption key generation material:

  • <slave_secret> random number

  • < module_secret> chip_id

• The module retrieves the terminal device name of the AT terminal executing the command.

• The module stores the <te_secret, at_dev_name, slave_secret, module_secret> record where:

  • <te_secret, at_dev_name > are record identifiers

  • <slave_secret, module_secret> are used to generate the encryption key

• Module reports to the MCU the generated encryption key 

Local C2C Key paring commands:

• AT+USECC2C = 0, <TE_SECRET>

  • <TE_SE CRET> parameter used to identify the key generation material. Not used as material for key generation

• Up to 8 different TE_SECRET/TERMINAL_DEVICE_NAME combinations.

• C2C Key Pairing stage available “before” USEC bootstrap.

  • once per TE_SECRET/TERMINAL_DEVICE_NAME combination

  • The command can be executed up to reaching the LocalDPR limit

  • can NOT override an already present TE_SECRET/TERMINAL_DEVICE_NAME combination.

• C2C Key Pairing stage available “after” USEC bootstrap when C2CKeyPairing AFA is enabled.

  • if and only if the LocalC2C AFA is enabled.

  • if and only if the LocalC2CKeyPairing AFA is enabled.

  • can override an already present TE_SECRET/TERMINAL_DEVICE_NAME combination / provides a new C2C key.

• The C2C KeyPairing command creates a record in the DB which enforces the security.

  • Record_structure {<TE_SECRET>,<TERMINAL_DEV_NAME>,<MasterSecret>,<ClientSecret>}

  • MasterSecret and ClientSecret used to create the C2C key using the sclC2cGeneratePSK 

Local C2C key paring functional requirements:

• The <te_secret, at_dev_name, slave_secret, module_secret> records are stored in a local file (USR/usec/c2c_db) which is encrypted using the local encryption using the key_slot 1.

• Please note that the process needs to be executed in customer production in a “sanitized environment”, as the C2C encryption key is not encrypted.

• The customer must execute the key pairing process for all 8 encryption keys to provide the highest level of security.

• The customer must securely store the encryption keys.

• If the encryption key is lost a C2CKeyPairing FeatureAuthorization can be enabled to request a new key pairing process within a non-secure session.

Although the guideline is that key pairing should happen in production phase and in a sanitize environment (so before bootstrap) please note that this process can happen in 3 different scenarios:

(Please note that ISEP is a component of the u-blox Thingstream platform.)

• [Scenario 1] Before the module bootstrap (module NOT registered with ISEP) and NOT claimed 

Host MCU --> AT+USECC2C=0, <te_secret>

                    <--  +USECC2C:0,0, <c2c_encryption_key>

MCU is responsible to store the te_secret and encryption_key.

• [Scenario 2] After the module bootstrap (module Registered with ISEP) but NOT claimed

Host MCU -->  AT+USECC2C=0, <te_secret>

                       <--  NOT_ALLOWED

MCU can try again after device has been claimed.

•  [Scenario 3] After bootstrap (Registered with ISEP) and claimed

Host MCU --> AT+USECC2C=0, <te_secret>

                    <-- +USECC2C:0,0, <c2c_encryption_key>

MCU is responsible to store the te_secret and encryption_key.

Open secure session

Open C2C channel:

• AT+USECC2C = 1, <TE_SECRET>

• A C2C channel is opened

•  The <TE_SECRET> and <TERMINAL_DEV_NAME> are used to identify the key generation material

• The identified material is used to generate a C2C key which is passed to the MSIO layer which handles the encryption and decryption using the passed key.

• The <TERMINAL_DEV_NAME> is retrieved automatically from the ID of the AT terminal which is being used to execute the c2c open channel command.

• A list of currently opened sessions is maintained. A new record is put on the list when a C2C channel is opened.

C2C Secure session open

The +USECC2C=1, <te_secret> command opens a secure channel.

There is no guideline or recommendation when to open a secure session.  This can happen in three different scenarios.

• Before bootstrap (NOT registered with ISEP) and NOT claimed 

Host MCU --> AT+USECC2C=1, <te_secret>

                    <-- PLAIN_TEXT_AT_OK

                    --> ENCRYPTED_AT_COMMAND

                    <-- ENCRYPTED_AT_OK

Having the right c2c_encryption_key (obtained in c2c key pairing phase) now MCU can decrypt the ENCRYPTED_AT_OK message and get the AT_OK.

You only need to pay attention to the grace (or evaluation) period.

Grace period < registered to isep.

Grace period allows execution of localDPR 100 times.

Grace period allows execution of C2C open (-1)/close (-1) 100 times.

• After bootstrap (Registered with ISEP) but NOT claimed

Host MCU --> AT+USECC2C=1, <te_secret>

                    <--  NOT_ALLOWED

MCU can try again after device has been claimed.

• After bootstrap (Registered with ISEP) and claimed

Host MCU --> AT+USECC2C=1, <te_secret>

                   <--  PLAIN_TEXT_AT_OK

                    --> ENCRYPTED_AT_COMMAND

                    <-- ENCRYPTED_AT_OK

Having the right c2c_encryption_key now MCU can decrypt the ENCRYPTED_AT_OK message and get the AT_OK.

Close secure session

The +USECC2C=2 command closes a secure channel.

You can close a session at any time (of course if you have already opened one).

(Please note that ISEP is a component of u-blox Thingstream platform.)

• Before bootstrap (NOT registered with ISEP) and NOT claimed  

Host MCU --> AT+USECC2C=2

                    <-- ENCRYPTED_AT_OK

Having the right c2c_encryption_key (obtained in c2c key pairing phase) now MCU can decrypt the ENCRYPTED_AT_OK message and get the AT_OK.

• After bootstrap (Registered with ISEP) and claimed

Host MCU should first retrieve the c2c_encryption_key using the te_secrect. Then using the right key encrypt AT+USECC2C=2

Host MCU --> ENCRYPTED AT COMMAND (AT+USECC2C=2)

                    <-- ENCRYPTED_AT_OK

Having the right c2c_encryption_key (obtained in c2c key pairing phase) now MCU can decrypt the ENCRYPTED_AT_OK message and get the AT_OK.

Rekeying

The +USECC2C=3 command triggers a rekeying of the current secure session. This can only be called during a secure session.

The re-keying can only be executed within a C2C session. The session used for rekeying is closed.

Host MCU should first retrieve the c2c_encryption_key using the te_secrect. Then using the right key encrypt AT+USECC2C=3

Host MCU -->ENCRYPTED AT COMMAND (AT+USECC2C=3)

                    <-- ENCRYPTED_AT_OK

Having the right c2c_encryption_key (obtained in c2c key pairing phase) now MCU can decrypt the ENCRYPTED_AT_OK message and get the AT_OK.

Use case

The Chip-to-Chip process includes two stages:

1. Key pairing: in this phase new keys are created for a specific secure channel (identified by a HEX string TE_SECRET) between the MT and the TE. Key pairing is available before bootstrap as a trial, for about 50 operations. Once the module has bootstrapped, the key pairing is available when the “LocalC2CKeyPairing” feature is enabled.

2. Usage: in this phase a secure channel, identified by TE_SECRET, is opened or closed between the MT and the TE. C2C usage is available only after bootstrap, when the “LocalC2C” feature is enabled.

R5<->MCU C2C key pairing example: