|
Coming soon |
Please understand this is draft, thank you
1. SafeLink Module Presentation
The Safe link module allows for the secure communication between a Host and the STM32WW4, at the level of the SDIO interface. In particular, the Safe link module allows the Host to ensure it is communicating with a real STM32WW4 provisioned by ST, to compute a common session key between the two devices and to perform encryption, decryption and authentication of the data exchanged on the SDIO interface. Finally, the Safe link offers a mechanism that update the session key periodically.
To ensure the security of the communication channel between a Host and the STM32WW4, the following conditions must be respected:
- The SDIO/SPI link must allow authentication and confidentiality of messages
- Prevention against passive eavesdropping and/or active tampering (injection of fault) on the link
- Forward secrecy
- The Host must be connected to authentic Typhon from ST
- Secure storage of key agreement private key
- SCA and fault protection of key agreement private key
- Safe link Security strength up to 192-bit for WPA3-Enterprise-192
Following methods have been retained to meet these requirements:
- Asymmetric Key agreement based on ECDH-key agreement P-384 ECC or P-256 ECC.
- Symmetric Key agreement base on challenge method and CMAC key agreement AES-256.
- AES-GCM packet encryption.
- Support of ephemeral keys pair, on STM32WW4 and on Host.
- The Host checks Typhon Certificate signature built by ST authority, based on ECDSA.
- The STM32WW4 private key is stored in its OTP Upper storage, tamper protected and decrypted by a ROM secret at EWS provisioning.
- The STM32WW4 Safe link code is protected against side channel attacks.
2. Safe Link Module implementation
The Safe link establishment, to compute the session key, is done in a set of RPC commands that are specifically made for the Safe link. The encryption, decryption and authentication of data, on the fly is done by the CRYP module, integrated between the COM layer and the RPC layer.
The CRYP module handles RPC messages, encrypt them if necessary, and add a secure header on top of the RPC header. This secure header is never encrypted, and allows the CRYP module of the other device to know the basic information about the message.
To meet these conditions, the CRYP module adds padding
The Secure Header contains following information :
- cmdID (2 bytes) : RPC ID of the message
- Length (2 bytes) : length of the payload of the Secure Header
- NumID (4 bytes) : counter of transmitted messages (used by the COM layer) between the Host and the STM32WW4
- Tag (16 bytes) : the tag of the transmitted message
To maximize performances, the STM32WW4CRYP module uses DMA, to either copy or encrypt/decrypt data between an SDIO buffer and a TX / CMD buffer. These DMA channels impose two requirements:
- The address of the Secure Header payload must be 32-bit aligned.
- The size of the Secure Header payload must be 32-bit aligned.
To meet these conditions, the CRYP module adds padding to respect the address alignment and the size alignment:
Upong receiving a message from the other device, the CRYP module takes care of removing the padding and retreive the original size of the message, before it is sent to the upper module (RPC layer).
The typical communication, for a blocking RPC command, between a Host and the STM32WW4 follows this scheme :
- On Host side, the RPC layer sends a message to the CRYP module.
- Using a secure table, the CRYP module checks if the message must be sent clear or authenticated/encrypted.
- Once the message is ready, the CRYP sends the message to the COM layer.
- On WW4 side, the COM layer receives the clear or encrypted message and send it to the CRYP
- The CRYP check the secure table and performs copy (clear message) or decryption/authentication (encrypted message).
- Once ready, the CRYP sends the message to the RPC layer.
- The WW4 sends its response following the same process.
On the Host, a thread is dedicated to the CRYP module, to handle the encryption and decryption queues, to start the cryptographic processes, and send the messages to the COM or RPC layer. In the case where the user does not want to use the Safe link feature, the initialization and execution of this thread can be easily bypassed, to improve performances.
3. Safe Link establishment
[to do : explain the process (RPC commands involved)]
4. Safe Link user configuration
[to do: explain of to use the projects and how to configure them]
5. Safe Link performances analysis
[to do : show the impact of safelink of performances]