January 17, 2019

By: Christophe Tremlet  Executive Business Manager, Maxim Integrated

Stephane di Vito  Sr. Principal Member of the Technical Staff, Embedded Security, Maxim Integrated

Safeguarding internet of things (IoT) applications from security threats involves device and server authentication, protection of sensitive data and intellectual property, and preservation of confidentiality and device and communications integrity. For example, consider an IoT node device. Such a device needs to have a secure bootloader and up-to-date secure firmware in order to safely send sensor data to a server over a TLS connection and to store sensitive data in flash memory. A key component in this equation is a security IC, used as a companion IC to application processors to ensure secure data exchange and to protect the data.

There are some different choices in security ICs for this role. Traditionally, a popular choice has been chips based on the Trusted Computing Group™ (TCG) defined Trusted Platform Module (TPM) standard. These discrete chips provide tamper-resistant, cryptographic co-processors for consumer PCs and servers. They’re designed to enable trust between computers that exchange data over a network, to protect user data, and to securely store some data (such as keys). For those with the expertise, TPM chips can also be used to support the implementation of very complex security policies that define who can do what and when. Because of this use case, the learning curve for the TPM standard is quite high. This complexity also makes it more difficult to verify the security of the system. And when it comes to small embedded systems, TPM chips are, simply put, challenging to integrate into the simple systems that are in the realm of the IoT, due to their initial design and platform resource requirements.

Figure 1. Integrating security ICs, which can store sensitive data such as keys, into connected devices can protect them from threats.

Now there’s another security IC option available to serve as a companion IC. Maxim’s MAXQ1061 and MAXQ1062 are designed to bring high-security certificate, key, and data secure storage, along with secure cryptographic primitives, to small, low-cost embedded systems. These compact, tamper-resistant devices were created especially for simple, embedded, connected devices, based on requirements derived from internal, customer, and public, cryptographic-modules specifications. They can be used for device integration into public key infrastructures, device and server authentication, confidentiality and integrity of data, and device integrity. With their set of 40 commands to achieve these purposes, the ICs eliminate unneeded complexity for embedded security. Their simple access control policy and feature set are suited for most of the security scenarios that are relevant for IoT devices. In this blog post, we’ll compare the differences between the two options to demonstrate the suitability of MAXQ1061 and MAXQ1062 for protecting small embedded systems such as IoT designs. Figure 2 provides a block diagram showing the integration of the MAXQ1061 and MAXQ1062.

Figure 2. Example of integration of the MAXQ1061/MAXQ1062.

Why Use a Security IC?
Security ICs provide a variety of benefits for embedded systems, including:

• Increased security of the key storage
• Secure cryptographic implementations that resist fault injection and side-channel attacks
• Strict isolation from other software running on the platform, as the only interaction channel is the command bus
• Data protection and other security functions where software alone is insufficient
• Hardware root of trust via its trusted behavior
• Offloading the host processor from the memory footprint and computation resources needed for security functions

Meeting Unique Requirements for the IoT
Providing security for IoT designs involves some unique considerations, given the typically small size and sometimes battery-operated nature of these electronic devices. As such, low power consumption of the underlying components is essential to support extended battery life. MAXQ1061 and MAXQ1062 have a typical standby current of 25µA, which is much lower than the considered chips based on the TPM standard that draw typically more than 100µA and, often, up to 300µA. In addition, the MAXQ1061 and MAXQ1062 have a 30ms boot time and can be completely powered off when not used but still made available very quickly when needed. Sufficient internal nonvolatile storage of security ICs is another important consideration for preserving sensitive data such as secret keys and certificates. The tamper-resistant internal memory of MAXQ1061 and MAXQ1062 is suitable for storing X.509 certificates, pairs of ECDSA keys, or other secret keys or arbitrary data. This internal storage is organized as a simple file system gated by user-defined access control. Chips based on the TPM standard also have internal, tamper-proof, nonvolatile storage—enough for large key stores that aren’t typical of IoT applications. The MAXQ1061 and MAXQ1062 also support the communication protocols that are aligned closely with embedded designs: the devices connect to a host processor via an I²C or SPI bus. While chips based on the TPM standard also have SPI interfaces, they feature other interfaces such as LPC that are primarily for PC architectures versus embedded systems.

Tougher Learning Curve for TPM Chips
One of the most challenging aspects of using chips based on TPM is the learning curve. The TPM standard-compliant host-side software is large and complex, dedicated to large systems featuring operating systems such as Linux and Windows. Memory footprint is in the 100KB to 1MB range. There aren’t many programming resources available online. The software components include the TCG Software Stack (TSS), with its large and complex specification; the TPM standard-compliant driver, whose API is complicated and sits at a very low level; and the feature API, which has a simple usage but a complex security policy definition.

By contrast, MAXQ1061 and MAXQ1062 require very simple software that suits the smallest microcontrollers. The host-side software is delivered in source, so it can be customized. Since it’s a library in C language with functions that directly map to the command set of the devices, you can implement complex use cases in a relatively straightforward manner using simple programs. The host library for these secure microcontrollers typically uses about 6KB of code and 4KB of RAM and can be built for any small processor such as the Arm^® Cortex^®-M0. Customized TLS client stacks, such as the mbedTLS for any kind of microcontrollers (e.g., Cortex-M0, microcontrollers similar to high-end microcontrollers) and OpenSSL^® for larger microcontrollers running embedded Linux or Windows, are provided on top of this library. The TLS client stacks use the devices’ TLS capabilities.

Offloading the Host Processor
An advantage to using a security IC in a system is to offload the main processor from sensitive cryptographic operations. See Table 1 for a comparison of low-level cryptographic algorithms supported by TPM chips and by MAXQ1061 and MAXQ1062.

Table 1. Supported Low-level Cryptographic Algorithms

Low-Level Cryptographic Features	Chips Based on the TPM Standard	MAXQ1061/MAXQ1062
Standard Cryptographic Algorithms	Yes	Yes
AES	AES-256 is optional in the TPM 2.0 standard	ECB, CBC, CCM 128/192/256 ECB/GCM 128, fast
Random Number Generator	SP800-90A, AIS31PTG2	Designed for SP800-90A SHA256DRBG*
Key Generation	RSA, ECDSA	ECDSA
Secure Hash Algorithm	SHA-1, 256	SHA-1, 256, 384, 512
RSA Signature	2048-bit	No
RSA Encryption	2048-bit	No
ECDSA Signature	NIST® P-256	NIST P-256, 384, 521 Brainpool 256, 384, 512
ECDH	Same curves as ECDSA	Same curves as ECDSA
HMAC	SHA-256	SHA-256, 384, 512
AES based MAC	No	Fast AES-CBC-MAC, AES-CMAC AES-GMAC with 128-bit keys on a dedicated SPI interface
TLS 1.2 PRF	No	SHA-256-based

*The design for this random number generator standard is not yet certified.

The way that the MAXQ1061 and MAXQ1062 run the cryptographic algorithms provide some advantages in terms of performance compared to TPM chips. MAXQ1061 and MAXQ1062 provide a fast AES engine over SPI for AES ECB and AES GCM encryption with 128-bit keys, with speeds up to 10MBps. The main processor, then, is relieved from having to handle some symmetric encryption tasks. In addition, the AES keys do not need to be exported to the main processor, where they could be exposed and revealed by side-channel attacks (causing the key to be retrieved through power consumption or electromagnetic emission analysis). With this onboard fast AES engine, the key is safely stored and manipulated in the MAXQ1061 and MAXQ1062. By comparison, chips based on the TPM standard do not have such a high-speed symmetric-encryption engine.

As noted in Table 1, the MAXQ1061 and MAXQ1062 do not support RSA. It is worthwhile to note that RSA is becoming more deprecated because of the long keys and digital signatures that can be several thousands of bits long compared to ECDSA, where keys and signatures are only a few hundred bits long.

TPM chips do not come with specific features to handle the TLS protocol. They can be used as basic cryptographic engines and long-term key storages, leveraged by certain TLS software stacks, such as wolfSSL^®, to perform atomic operations like certificate generation, signature verification, AES encryption or decryption, HMAC signature or verification, or ECDH as needed by the TLS handshake and record processing. With such chips, TLS session keys are computed in the host processor, which, as we’ve discussed, is more exposed to hackers. While keeping the TLS session keys internal to the volatile memory, the MAXQ1061 and MAXQ1062 can process a complete TLS 1.2 session from handshake to secure application data exchange. When exchanging application data over TLS, the TLS record layer is used and encryption and signature with negotiated keys is applied. The devices completely handle this TLS record layer, so the TLS session keys derived from the handshake phase can remain safe inside the chip and never exposed outside.

External memory encryption needs a symmetric key for encrypting/decrypting disk data. The symmetric approach (such as AES) provides speed. The security IC must hold the disk encryption/decryption key as it is encrypted, releasing it to the main CPU only if the CPU has booted into a secure state. For TPM chips, the secure state is determined using the PCR values that are updated during the bootstrap process. Only then does the TPM-standard chip release the key to the host processor, which performs the disk encryption/decryption by itself since the chip lacks the speed for such an operation. However, the key could be exposed while it is being transferred to the host processor. With the MAXQ1061 and MAXQ1062, a secure boot feature and an internal memory object that holds the disk decryption key implements this process. Once the platform has been securely booted, the MAXQ1061 and MAXQ1062 can choose to transfer the key to the external AES-SPI engine and perform high-speed encryption/decryption of the external memory, rather than transferring the key to the host processor. With this feature, external memory can be quickly decrypted without any exposure of the decryption key.

Summary
For an even deeper dive into the differences between chips based on the TPM standard and MAXQ1061/MAXQ1062 when it comes to protecting embedded devices, read our application note, “Fundamental Advantages of the MAXQ1061/MAXQ1062 Compared to Chips Based on the TPM 2.0 Standard.” Based on functions and features and the design considerations of small, connected, embedded devices, the MAXQ1061 and MAXQ1062 provide the ease of implementation, small footprint, power efficiency and, most importantly, the level of security required in a companion security IC.