Keywords: MAXQ1061, secure boot, IoT, ECDSA, digital signature, encryption, SHA,AES,trust, SPI, I2C,
This document is written for a highly specific application and contains information about proprietary technology, and is only available to customers whose requirements closely match the application. To request the full document, please complete the form below.Please enter information in English only.
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:
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.
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.
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.
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.
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.
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 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.
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