The security of smart, connected devices is essential in ensuring customer trust. In the internet-of-things (IoT) world, with devices deployed in the wild, preventing attacks and counterfeiting should be a priority for device designers. However, not all designers are experts in cryptography, and many are focused on creating differentiated features while meeting stringent time-to-market targets.
For devices and transactions to be considered secure, authentication is a fundamental step. The process of authentication validates that communications between the device and the host are genuine, as are both of these end points. Public-key cryptography techniques can be used to verify the integrity and authenticity of digital content. It is based on pairs of keys: a private key that is stored secretly and a public key that is available to anyone. The private key can be used to sign digital content, while the issuer of the digital content uses its own secretly held private key to identify as the issuer. Signing content with a private key produces digital signatures that can be successfully verified only by the designated public key.
While it is relatively easy to load a common customer certificate or public key on some cryptographic devices, a more robust scheme is needed to have each device loaded with a unique certificate and private key. The former approach is easier to implement, but if the private key associated with the certificate is discovered, clone devices can easily be produced. The manufacturers do not have much of a choice, and they cannot revoke the certificate as all the devices in the field become useless.
A unique certificate and key pair per device provide a far better solution because if one device is compromised and the key is discovered, only one device can be cloned. The manufacturer can easily detect or even revoke that particular certificate and stop the attack.
Design engineers can create their own schemes and load each device with a unique certificate and key pair. But due to the complexity and development time, many prefer to receive devices with pre-loaded unique-per-device certificates and device keys.
This application note explains the implementation scheme, requirements, and options available.
By facilitating the distribution and identification of public encryption keys, a public key infrastructure (PKI) allows users and computers to securely exchange data over the internet. One of its benefits is its ability to verify the identity of the involved parties. PKIs typically include hardware, software, policies, and standards to manage critical aspects of digital certificates and keys, including their creation, administration, distribution, and revocation. A certificate authority (CA) issues digital certificates to involved parties after verifying their identity, signing the certificates with its private key, and making the public key available to interested parties in a self-signed CA certificate. Certificates contain the full identity of the sender (such as the domain name of the server, as well as the address, country, and phone number of the owning organization), the identity of the certification authority that issued the certificate, and the public key of the sender. The certificate is digitally signed by the CA, and the signature is appended to the certificate. The CA creates a chain of trust, and many of these root certificates are embedded in web browsers and integrated onto email clients, smartphones, and other hardware and software1.
A security IC with the right capabilities can support a PKI. If the chip has integrated nonvolatile memory (NVM), for example, it can store CA root certificates as well as keys there. A true random number generator (TRNG) is an important component in cryptography and is used to generate random cryptographic keys to transmit data securely. Some security ICs are built with a TRNG. A PKI end-entity designates the user of PKI certificates or the end-user system that is the subject of a certificate. An end-entity certificate appears at the end of a certificate path in the path validation process. It is not used to validate signatures on other certificates, so it does not contain a CA public key. A security IC can store end-entity certificates.
The MAXQ1061 DeepCover® cryptographic controller for embedded devices (Figure 1) provides a turnkey solution for secure storage, digital signature, encryption, secure boot, and TLS/SSL communication protocol. The device can be designed in from the beginning or even integrated into an existing design to bring confidentiality, authenticity, and integrity to that device. This application note uses this device to show how a security IC can be customized during production to serve as a PKI end-entity.
The MAXQ1061 contains modern cryptographic algorithms along with secure NVM storage. The device also includes a very high-entropy TRNG to guarantee a unique number each time when invoked. There is an on-chip, secure, encrypted 32kB EEPROM NVM that is used to store various keys and certificates. These features play an important role in successful certificate management.
Figure 1. MAXQ1061 system diagram.
The MAXQ1061 supports fast and easy implementation of full security for embedded, connected products without requiring firmware development.
A powerful hardware security module (HSM) is needed to trustfully create certificates for each device on-the-fly during the test. An HSM is a physical computing device that safeguards and manages digital keys for authentication and provides crypto processing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.
The physical location of the HSM can be at a Maxim test facility or at one of its subcontractor locations (on site).
Figure 2 shows the implementation and depicts the process of using an HSM to create certificates for each device on-the-fly.
Figure 2. HSM process to create certificates for each device on-the-fly.
After the initial setup of the HSM, the module generates a customer root key (CRK) pair (1). The private key remains in the HSM and the public key is exported. This key resides on the backend servers of the customer for PKI management and authentication purposes. A session has to be opened either remotely or locally by following security protocol, which is depicted in Figure 2 by the green dotted line or the internet connection.
During each MAXQ1061 test, a device key pair is generated on-board using the TRNG and the crypto toolbox of the MAXQ1061. The private key is stored internally (2) in the secure memory of the MAXQ1061 while the public part is sent to the tester. The tester, which has already established a secure channel to the HSM, transports the device public key (3). Once received by the HSM, the device public key is signed by the CRK private key and a certificate is created (4). The certificate is transported back to the tester through the established secure channel and placed in the secure memory of the MAXQ1061 (5). This process is repeated for every single MAXQ1061 device.
Once the devices are in the field and powered up, a TLS session can be initiated, as explained in application note 6436: "Using Secure Companion ICs to Protect a TLS Implementation", where devices or “clients” authenticate the “server.” Likewise, the server authenticates devices in the field (mutual authentication). This process can also be used to establish secure communication between devices.
This application note examined a versatile method to customize each and every MAXQ1061 during production. This method enables the MAXQ1061 as a PKI end-entity. Here are some of the benefits of using this method:
Refer to the MAXQ1061 for more information about the device, including access to the data sheet and reference designs.