How to easily integrate authentication and encryption using SHE and HSMby Adrian Constantin
Inside this post, you’ll be able to discover the main features of Secure Hardware Extensions (SHE) and understand how to properly use them. You can also get a copy of the specification from autosar.org if you do a document search for „Specification of Secure Hardware Extensions”.
SHE is a simple standard that allows for easy integration of short-and-simple authentication and encryption functions for any messages, based on 128-bit AES (Advanced Encryption Standard). If your focus is on encryption strength over ease of integration, choose an HSM (Hardware Security Module) instead of SHE. There is no standard to define an HSM, each hardware implementation is free to implement and expose any cryptographic operations they see fit.
In simple terms, what SHE or HSM actually does is to protect the encryption keys in a cryptographic memory, while still allowing on-demand cryptographic operations using the keys. This way, the owner of the SHE or HSM hardware can operate as if they know the secret keys, while in reality keys are locked inside the security hardware and are never accessible. It is no longer possible to give the keys to someone else, except by giving them physical access to the secure hardware.
Interfacing with SHE or HSM
There is no standard interface defined for access to SHE or HSM hardware. As a hardware extension, every SHE implementation is required to define its access interface. For example, the SHE specification provides a list of possible errors and descriptions where each may occur, but the numeric values (error codes) to represent them are chosen by the implementation. The same is true for SHE commands: SHE specification defines the meaning and effects for the commands, but the interface, together with the registers or possible command codes used to access the commands, is defined by the hardware implementation.
Provisioning SHE keys
SHE provides a number of 10 AES-128 key slots, plus a volatile slot (RAM_KEY) that is not saved between power cycles (not persistent). In order to populate or update one of the 10 keys, you need to know either:
- the previous value of the key
- the value of a special key called ECU Master (or MASTER_ECU_KEY in the SHE specification)
- optionally, the Unique ID (UID) of the SHE hardware chip.
Upon delivery from the factory, the SHE hardware chip is in an “open” state, meaning the key slots are empty. To populate them, you need to use a value of all zeros for the previous key value (hex string 00000000000000000000000000000000). After a key slot is populated, there is no way to retrieve the key back from SHE. Except for the RAM key, which can be retrieved in encrypted form only, so the real value of the key is still not available.
Note that by safely keeping a copy of the ECU Master key, you will be able to work with a set of 10 AES-128 keys in SHE that are not known by anyone. And you will still be able to update them if needed.
The key value is never sent in clear text to the SHE hardware for initially populating the slots or for updating them later. Instead, the old and new key values, together with the slot number and some associated key flags, are used as input to a formula that will generate:
- a number of 3 input messages (called M1, M2, M3)
- a number of 2 output messages (M4, M5)
The input messages M1, M2, M3 are sent to the SHE hardware to import a new key, while the output messages M4, M5 are sent back by the SHE hardware to the application for validation.
The SHE hardware may come with a tool or script that implements this formula and computes the input and output messages. On the other hand, it is always possible to implement it from the SHE Specification, where it is described as the Memory Update Protocol.
A simple way to look at the Memory Update Protocol is to consider that keys can only be written in encrypted mode, as described in the Specification. The advantage of using the protocol is that keys can be generated and managed on a remote server (or a remote party in general), and the encrypted form cannot be decrypted without the old key value.
These remote servers are free to drop newly generated keys immediately after the input/output messages M1 to M5 are generated. Later on, they rely on the ECU Master key to update the same slots again, thus ensuring that such keys can never be known, even if the server is compromised.
Using SHE features
SHE hardware can both generate and validate a Message Authentication Code based on AES-128, called CMAC. This is used to ensure authenticity of a message upon receipt. The needed steps for authentication to work are:
- a message source computes CMAC for a new message and attaches it to the message content
- the message and the MAC are sent to the destination
- at destination. the MAC is re-computed with the same AES key
- if the generated CMAC matches the received value, the destination now has the guarantee that:
- the sender has the same AES-128 key as the destination
- the message has not been tampered during transport (is authentic)
- to avoid replay attacks, where a valid message is captured and sent again (injected) at a later time, the content of the message should always include the value of a monotonic counter, that increases for each new message.
- Secure Boot
Secure Boot is a special case of authentication (see above). A special key slot for the BOOT_MAC_KEY can be populated using the same Memory Update Protocol, together with a slot for the expected BOOT_MAC. Before loading the operating system image, a boot-loader that can be made read-only to avoid tampering can use the SECURE_BOOT command in SHE to verify that the image is authentic, and halt the boot process otherwise. Additionally, SHE hardware can protect any of the 10 AES key slots by automatically disabling them when secure boot is not successful.
- AES Encryption
SHE hardware can run AES-128 encryption and decryption in ECB and CBC modes. The input and output consist of blocks of 16 bytes (AES block size), meaning padding has to be ensured by the application. ECB mode can process only one block at a time, but CBC mode can cipher multi-block messages in one call.
CBC mode has the advantage of randomizing the encrypted output (cipher text), even if the input (plain text) is fixed or has visible cycles or patterns. For this reason, using ECB is generally not recommended. When using CBC mode, it’s highly recommended to randomize the Initialization Vector (IV) for each encryption operation.
- Random Number Generation
SHE can generate random numbers of a length of 16 bytes by encrypting the last number generated with a special PRNG_KEY. This should be used for cryptographic operations where it is important for the generated random numbers to be unpredictable.
The number generator has to be initialized after every power cycle, before random numbers can be generated. The output will always be 16 bytes in length, as more numbers can be generated by repeated calls.
Using an HSM
A Hardware Security Module (HSM) is quite similar to a SHE in that it protects a number of cryptographic keys and supports a number of cryptographic primitives using the keys. Unlike SHE, there is no specification for what primitives an HSM should provide. Both the access interface (programming interface) and the supported functionality depend on the hardware implementation.
Let’s take the MAC as an example. In the case of SHE using CMAC, the AES-128 key used for the MAC must be shared by at least 2 participants (the sender and receiver of the message). There can be more participants in a group conversation scenario. This way, it can be argued that the Message Authentication Code (MAC) does not uniquely identify the sender of the message, but several possible senders.
An HSM can solve this issue by implementing proper signatures instead of a MAC, based on asymmetric encryption like ECC (Elliptic Curve Cryptography). Such ECDSA signatures uniquely identify a private key, assigned to a single party. On the other hand, this usually introduces a need for certificates. In short, certificates provide a signature of the associated public key, in order to prove the private key is trusted. Actually, to prove the owner of the private key is trusted. The signing party, that will sign the public key, must be shared and trusted in advance (must be “well-known”).
Other HSM uses include:
- different block cipher modes, like AES-GCM instead of CBC or ECB
- providing more encryption algorithms, like:
- RSA. Note the strength of RSA does not increase proportionally with the key size. Instead, RSA strength increases less and less as you increase the key size (diminishing returns). For this reason, it’s now recommended to use ECC instead.
- implement ECDH (Elliptic Curve Diffie-Hellman) Key Exchange.
This is an algorithm allowing two parties over the network to negotiate a common key (or shared secret), without the need to transfer such key over the wire.
- Use ECC for signatures (ECDSA) and random number generation
- implement other MAC functions like HMAC
- implement hashing functions for SHA-256 for example
It is possible for an HSM to provide all the functions from SHE as specified in the standard, then add more primitives as needed by the HSM hardware implementation.