Key Security is Foundational to IoT Application Security

IoT devices present a particularly vulnerable target to bad actors because physical security – the linchpin of most security policies – is generally impossible to achieve for IoT applications. As engineers look to lock down IoT designs, security mechanisms such as encryption and authentication typically gain the lion's share of attention. Yet, without robust key security even the most comprehensive security policies can become compromised. Using a combination of design techniques and specialized ICs for secure key management, designers can build a foundation of greater security for IoT applications.

IoT devices lack even the dubious protection afforded conventional Internet applications. While the assets for Web-based applications can rely to some measure on the physical security associated with production data centers, IoT applications depend on dispersion of large numbers of physical devices, often in easily accessible, unprotected locations. Consequently, bad actors can easily acquire these devices and work on exploits at their leisure.

In fact, successful attacks on conventional connected applications are less likely to come from direct penetration and more likely to arise from social hacking or zero-day exploits such as Heartbleed. In contrast, IoT devices are less exposed to social-based exploits than traditional Web-based applications, but their physical exposure offers opportunities for more direct attacks.

Silicon manufacturers can protect devices from sophisticated attacks such as differential power analysis. In addition, manufacturers can implement hardware-based security measures that make the cost in time and resources of successful penetration outweigh the likely benefit. For the IoT, a greater threat vector lies in breakdowns in protection of cryptography keys arising from storing keys in unsecured memory, transferring key values across easily accessible hardware interfaces, or even deriving key values created using "random" number generators with predictable patterns.

Key importance

Outside of social or zero-day exploits, compromised keys represent one of the most insidious attack vectors. With a legitimate key in hand, bad actors can gain trusted status that allows them to bypass every security measure designed to exclude unauthorized users. Normal protection from firewalls, virtual private networks, and authentication mechanisms, among others, will dissolve when presented with the compromised but otherwise valid security credentials.

Secret keys underlie every particular cryptographic method, and every crypto method relies utterly on the protection of keys. Cryptographers have long understood the fundamental importance of key security. In a treatise that foreshadowed the nature of the IoT security challenge, 19th century Dutch cryptographer Auguste Kerckhoffs observed that a cryptography system should remain secure even if it falls into enemy hands. The only real secrets are the keys themselves.

Crypto key protection is an industry unto itself but key management units, such as hardware security modules (HSMs) used in data centers, are too expensive and bulky for field deployment with IoT devices. Instead, semiconductor manufacturers provide effective solutions based on security mechanisms integrated into MCUs and specialized security devices. The nature of the hardware-based mechanisms varies widely but these mechanisms serve as the foundation for critical crypto operations performed by dedicated hardware engines or associated software libraries.

Zone protection

Semiconductors are responding to IoT security concerns with a greater range of suitable features integrated into MCUs. Texas Instruments offers a straightforward approach that takes advantage of the flexibility of FRAM integrated in members of the MSP430FRxx FRAM MCU family such as the MSP430FR69721 MCU. With this MCU, developers can protect both software and critical data such as crypto keys by placing them in IP Encapsulation (IPE) zones. Once protected, data within a particular IPE zone may be accessed only by code within that zone (Figure 1).

Figure 1: The TI MSP430FR69721 FRAM MCU provides IP Encapsulation (IPE) zones that permit access to data within an IPE zone only to software code within that same IPE zone. TI uses this approach in its own secure bootloader (SBL) utility, which reconfigures IPE zone access rights during the load process. (Image courtesy of Texas Instruments)

Using this approach, developers can place crypto keys along with their algorithms in the same IPE zone and lock it down to prevent any external access through JTAG debuggers, bootloaders, DMA, or even direct register reads. Unlike flash, FRAM does not require pre-erase or charge pumps for writing – and it boasts virtually unlimited endurance. As a result, developers can employ crypto methods using Diffie-Hellman-like public-key protocols that routinely generate and discard secret data including secure session keys, data encryption keys, or message authentication codes. The TI MSP430FR69721 also includes an on-chip AES crypto coprocessor and true random number seed, providing all the functionality needed to generate secure keys rapidly.

For IoT designs where requirements dictate use of an MCU without integrated key-management functionality, Atmel's ATECC508A CryptoAuthentication IC offers an effective solution. On behalf of a host MCU, the ATECC508A handles the mechanics of secure key-exchange, using its integrated secure key storage and its built-in engines for execution of ECDH (Elliptic Curve Diffie–Hellman) and ECDSA (Elliptic Curve Digital Signature Algorithm). Along with power and ground pins, the device uses only two additional pins for serial data and serial clock input to connect with the host MCU. Designed for low-power operation, the ATECC508A offers a near drop-in solution for supplementing an MCU-based design with secure key management capabilities (Figure 2).

Figure 2: The Atmel ATECC508A CryptoAuthentication IC combines secure key storage with crypto functionality to simplify addition of public-key cryptography capabilities to any MCU through a 2-wire hardware interface. (Image courtesy of Atmel)

Public-key protocols can be particularly effective in the IoT, where devices need to communicate securely across a medium that fundamentally cannot be truly secured. With these protocols, the communicating partners actually establish a shared secret over the insecure connection and use that for the duration of the session or even just for the individual data transmission. Because a new set of keys may apply for the each transaction, eavesdroppers cannot mine the transmissions in an attempt to recreate the key.

Devices such as the TI MSP430FR69721 MCU and the Atmel ATECC508A are well suited for dynamically creating and discarding secret keys. Still, an IoT application might rely on different security policies. For example, a common security approach depends on permanent storage of a crypto key or other secret generated by the manufacturer before shipping, or by the developer before deployment.

Permanent storage

For applications requiring permanent key storage, designers can take advantage of secure one-time programmable (OTP) memory in devices such as the Microchip Technology PIC24FJ256GB410 MCU and the Atmel AT88SC6416C. OTP memory can be particularly effective because it can be easily programmed either in the factory or in the field just before installation. Once written, however, OTP data can be neither cleared by software command or hardware reset nor erased by reprogramming the device.

The Microchip PIC24FJ256GB410 MCU embeds an OTP memory array deep within its integrated crypto engine (Figure 3). For an encryption/decryption operation, register CRYKEY stores the crypto key for the operation. Registers CRYTXTA and CRYTXTB serve as inputs to the operation, and CRYTXTC stores the final output. Data can only be written to the CRYKEY from the MCU's special function registers or from the OTP array but any data placed in that register cannot be read back by any run-time operation – thus ensuring the security of any key data.

Figure 3: The Microchip Technology PIC24FJ256GB410 MCU's integrated crypto engine can perform encryption/decryption operations using keys dynamically created as part of a security transaction or permanently stored in the device's one-time programmable (OTP) memory. (Image courtesy of Microchip Technology)

OTP contents are accessible only to the CRYKEY register. In fact, the MCU includes no provision for reading data from OTP memory into any user-accessible memory space in any operating mode. Indeed, the only way to verify that OTP memory has been correctly programmed is to confirm that a crypto operation using OTP generates expected results.

For designs using an MCU with these security capabilities, the Atmel AT88SC6416C provides similar functionality. A member of the Atmel CryptoMemory family, the AT88SC6416C is an 8-KB EEPROM configured as sixteen 512-byte zones and secured with integrated crypto features. Besides the 8-KB secure read/write memory, the device offers an OTP partition for permanent, secure key storage. Engineers can configure each of the device's sixteen 512-byte zones with different access rights or combine them into larger partitions. In addition, the device can be configured to encrypt all data exchanged between the device and the host.

Engineers can take advantage of simple hardware and software interfaces for integrating the AT88SC6416C or other members of the CryptoMemory family in a design. On the hardware side, CryptoMemory devices use a two-wire interface for connecting to an MCU and are even available with the same pinout as 2-wire serial EEPROMs. For software programming, these devices accept a four-byte instruction comprising a command, two bytes corresponding to the address (or subcommand), and one byte containing the number of data bytes associated with the command.

CryptoMemory devices support commands for writing and reading user zones, data and the device password as well as verifying authentication and encryption. So, for example, writing data would involve specifying the user zone to use:

B4 03 00 00

Where:

B4 indicates that this is a system write operation

03 indicates that this is a zone selection operation

00 indicates the zone selected (zone 0 in this example)

In this case, the final byte in this instruction has a value of zero (00) because this type of instruction has no additional data bytes associated with it.

With zone 0 now selected, the next instruction allows writing data to that zone:

B0 00 00 0B 5A 6F 6E 65 20 30 20 44 61 74 61

Where:

B0 indicates that this is a user zone write operation

00 00 indicates the starting address of the write

0B indicates the number of bytes to written

With the remaining bytes being the data values to be written to zone 0 starting at address 0.

Using this approach, even fairly complex operations such as device initialization resolve to a simple stream of byte sequences (Figure 4).

Figure 4: Atmel's CryptoMemory devices use simple byte sequences to read and write data as well as perform more complex operations such as authentication and encryption verification. Here, this sequence initializes a CryptoMemory device (the Atmel AT88SC0104C in this case). Lines beginning with an asterisk are comments. (Source: Atmel)

Conclusion

As the IoT evolves, security threats will test developers' abilities to ensure that IoT applications stand protected and IoT device data remains uncorrupted. Although security mechanisms and policies will continue to evolve as threats arise, every security measure ultimately depends on the secrecy of the underlying cryptography keys. By taking advantage of MCUs and dedicated ICs able to provide key security, developers will lay the foundation for improved IoT security.