How to Set Up a Secure Applications Boot with the MAXQ1061
Technology is constantly under attack. For microcontroller-based applications, attacks are extremely high. If left exposed and vulnerable, these applications are susceptible to malware, leading to their full takeover in many ways, including:
- Modifying their behavior in a favorable way for the attacker, sometimes in a very discrete manner
- Stopping their overall functioning (denial of service)
- Retrieving/extracting valuable secret stored information
- Stealing industrial property (IP)
It is critical then to prevent this malicious control. One of the best answers against the above threats is a secure boot using an external chip, which makes it an attractive option for a generic device/application. This application ote discusses how the MAXQ1061 DeepCover® cryptographic controller for embedded devices and the provided associated tware code allow access to this secure boot function at a very low cost. We’ll also see how, thanks to the MAXQ1061, we can extend the secure boot principle to secure, trusted access to data and assets hosted and protected by the MAXQ1061.
Why Use a Secure Boot?
The secure boot principle is relatively simple. Legitimate applications are digitally signed. The signatures are the result of a computation involving the legitimate application file and a secret cryptographic key, only owned by the authorized provider. Only when the digital signature is verified will the application be granted permission to execute. The secure boot ensures that only applications with valid, verifiable signatures are allowed to perform intended instructions. In this context, devices can discriminate authorized applications from unauthorized applications, the latter being rejected for not having a valid signature.
So even though the secure boot principle is simple, the implementation is actually more complicated because it depends on several constraints. Device specifications and development are usually conditioned by the devices’ functional use and their cost. If a security mechanism is too expensive, it is not implemented. Those designing end-applications are more focused on the applications’ features, cost, longevity, ease of use, and integration. In markets where security is not applicable (or a highest priority), the end-applications’ associated functions and mechanisms are usually not considered. Additionally, there are time constraints on development and validation. Design teams may not have the skills for (efficiently) implementing these mechanisms. All these factors leave security protection an afterthought.
But designers have the secure boot option using the MAXQ1061.
Encrypting Application Files with the MAXQ1061
The defense scenario we present is the best one allowed by the MAXQ1061: encrypting an application file. Doing so enables us to handle the authorized application file in a signed way and in an encrypted way. The encryption option protects the application file against any reverse-engineering attempt.
Distributing application files is generally neither controlled nor controllable. The distribution exposes the binary file that contains application instructions to examination and scrutiny that could help to understand its functioning. Even though the file is made of instructions from a low-level language (assembly language), that alone is not enough of a deterrent and should not be considered as a means to prevent a determined attacker from accessing the application functioning logic. Understanding the application functionality and having all details of the implementation allow us to either recover sensitive information (algorithms, passwords, keys) or to find weaknesses in the implementation, with such weaknesses being potentially exploited to attack the device.
So, encrypting an application file is a highly reasonable measure.
Our scenario to encrypt the application file allows us to not only authorize the application execution, after decryption and signature verification, but also to provide access to sensitive data, stored in the MAXQ1061.
To do this, let’s look at all the prerequisites.
First, select the cryptographic primitives. For the digital signature, Maxim recommends the public key algorithm named ECDSA (elliptic curve digital signature algorithm), with 256-bit curves and the secure hash function SHA-256. We have chosen them because these algorithms combine several benefits such as being industry standards, having a very high level of security for many years, and having a reasonable (not too large) signature size, adapted to the device’s data size. For encryption, the best choice is the AES (advanced encryption standard). Using these, we apply the Kerckhoffs principle, so only the secret key knowledge allows us to build valid signatures.
Next, we set up a trust environment, where the secret keys are stored under the most secure conditions consisting of how control of the keys and the device(s) work.
The keys used for encrypting or signing the application files are generated and stored within tamper-resistant security modules (TRSMs) where usage is strictly codified. TSRMs are electronic devices proposing security functions such as keys generation, and storage and handling in highly secure conditions (erasure in case of tampering, robust cryptographic computations, dual-control access control policy). These devices are typically hardware security modules (HSMs). They are often FIPS 140-2 and/or payment card industry (PCI) HSM certified.
We use the “dual-control” rule, where one single person is not allowed access to the key or its use. The keys used for decrypting the application files are stored within the device, especially in the MAXQ1061, to guarantee the best level of protection.
Digital Signature Key
The digital signature key, named KS, is generated in a trusted environment. Its use is also authorized only in this rusted environment. This key is the cornerstone of the digital signature security.
As the algorithm is based on public key cryptography, the generated key is made of two parts: one private/secret and one public. The public part, which allows us to check the digital signature, is programmed within the device to enable the application file verification before its execution.
For added security and key protection in managing file encryption and decryption (as presented above), we generate an AES key at least 128 bits long named KC. We generate two separate trusted environments.
In a first trusted environment, similar to the one where we created KS, the key encrypts the file to protect it during transit in a nontrusted/nonsecure environment. The KC key is used to decrypt the application file. A second trusted environment, managed by the MAXQ1061, enables the decryption. KC is stored in this second trusted environment.
Secure Channel Key
To exchange sensitive and authenticated data between the device’s microcontroller and the MAXQ1061, a secure channel must be set up between them. This channel is based on a shared secret, a AES key 128 bits long minimum named KE. This key, generated on the MAXQ1061, is exported and stored within the device’s microcontroller.
Other Sensitive Data
The MAXQ1061 is the best means for storing sensitive data (secrets, passwords, privacy data, algorithmic data) in a robust, long-term, secure way. The types of data access (read, write, erase, use, export) can be conditioned using various criteria, providing great flexibility. We discuss how to do that in the following sections.
The infrastructure and the mechanisms exposed above correctly work if and only if the keys are correctly distributed in the MAXQ1061, the microcontrollers, and the TRSMs. This distribution is performed in a trusted environment in order to guarantee that the verification public key is actually within the MAXQ1061 before releasing it into the field. If not, the application file is not verified and, therefore, is not run on the device.
There are very strong constraints on the encryption key programming. The first constraint is the confidentiality requirement: this key (KS) being handled in plain form in the provisioning environment. The second constraint is a synchronization requirement: the key (KC) used for the application file encryption is the same as the one stored in the device to be used for the decryption.
Finally, the secure channel key (KE) is available in the device, both on the microcontroller side and on the MAXQ1061 side. This provisioning occurs after the final object assembly, when the microcontroller and the MAXQ1061 are together on the same board, typically at a preparation step, before the device is put in the field.
An answer to the security requirements at the (public and secret) keys programming phase is provided by the security mechanisms proposed by the MAXQ1061.
The sequence is the following:
- The control (host) PC authenticates itself against the MAXQ1061, through the communication interface. This
technique is a called a challenge-response.
- The control PC now imports the application signature verification ECDSA public key within the MAXQ1061.
- The control PC then imports the encryption/decryption AES key (KC). This import phase is associated with a
strict definition of the access rules for this key during the use. The MAXQ1061 defines and proposes a very rich
set of access conditions and attributes for the data objects it hosts. For example, the “secret key” data object is
configured at its creation by setting its attributes to no read access, no modification right, no delete right,
and use by the microcontroller.
- At this stage, the MAXQ1061 embeds the elements for application decryption and signature verification.
- The only remaining step is to generate the secure channel key between the device microcontroller and the
MAXQ1061. While the steps above can be performed before the final assembly of the object, this KE generation can
only be performed once the assembly completed.
- Beyond the provisioning for enabling the secure boot scenario, we can also program data in the MAXQ1061 nonvolatile memory. As seen above, the MAXQ1061 provides a set of access conditions and attributes for the data it hosts. We use with a great benefit the « SECURE BOOT » access condition for the data related to the application. This condition grants the access to the data only if the application signature verification has been successful (see below).
The application can now be signed and then (optionally) encrypted by the application provider, or at least the player authorized to access to the keys. Then, this file is provided to the device either directly at the provisioning phase (for the application first version) or through a communication channel for any application update in the field.
The application is therefore stored (optionally) encrypted and signed in the object storage memory (typically a flash memory).
Once this programming phase performed, the device can be deployed in the field for its effective use. The device is functional and contains every security element required for enforcing its defined security policy.
We’ll now describe the device secure boot scenario.
- Secure channel setup: the microcontroller and the MAXQ1061 set up a secure channel, i.e., a link providing
confidentiality and integrity for the exchanged data. To reach this objective, the microcontroller has to first
prove to the MAXQ1061 it effectively knows the secure channel key, KE, without transmitting it.
- This proof is given by using a challenge-response operation.
- The microcontroller and the MAXQ1061 now sharing the KE can compute on their own side the AES keys for encryption and for integrity (the secure channel key is never directly used for the session encryption): These keys are named KENC and KMAC.
- Now the secure channel is ready: the exchanged data is encrypted and protected against modification.
- Encrypted application sending to the MAXQ1061 for decryption (optional):
- The application is sliced in multiple chunks: the microcontroller reads its storage memory where the application is stored and sends the application through the secure channel (either I2C or SPI) to the MAXQ1061 for decryption.
- The MAXQ1061 decrypts the data using the KE. Then, these plain data are sent back to the microcontroller through the secure channel (protected using KENC and KMAC): no eavesdropping is possible on this link.
- The microcontroller stores these data by aggregating them to form the application initial plain image, ready for execution.
- Now the microcontroller initiates the application file digital signature verification.
- The microcontroller sends the application file in plain to the MAXQ1061 after having asked for a SHA-256 hashing operation.
- The MAXQ1061 accumulates the data hashing digest with the received data as a temporary result.
- Once the file is completely hashed, the microcontroller sends the digital signature using the VERIFY-BOOT command to the MAXQ1061.
- The MAXQ1061 uses the ECDSA KSPUB public key and the application file hash digest to verify the digital signature.
- In case of success, the MAXQ1061 sends a OK status (0x0000) to the microcontroller.
- The microcontroller can now consider the application file as a genuine and authorized one; it can run it.
- In parallel, the MAXQ1061 activates the SECURE-BOOT condition, which authorizes the microcontroller to access to any data protected with this attribute.
- In case of failure, the MAXQ1061 can enable the signal RESET_OUT. This signal is used for resetting the object; this failure is considered as an attempt to submit a not-authorized application file, therefore, the decision is to not execute it and to restart the object.
We have seen in this document how the MAXQ1061 easily offers a secure boot service to any kind of microcontroller-based electronic device. This service relies on the various features provided by the MAXQ1061, including symmetric and asymmetric cryptographic algorithms, data storage mechanisms, keys generations, certificates verification.Resources