Secure IoT Device Communications with a Single Chip

IoT Security

The IoT landscape is increasingly becoming aware of the need for security, IoT developers are facing increased demands for tighter security. IoT security is more than just secure sessions underlying secret keys and secure messaging. However, an intact security chain is complex to design and implement more so factoring in the cost of production. To allow designers to deliver on this expectations and requirements, IoT applications need to be built on root-of-trust with secure boot and firmware updates at the device level. Luckily a single chip can be used to implement a wide range of security mechanisms required to ensure that the necessary security mechanisms required for IoT application security are met.

A single chip for IoT security

The CEC1702 is such a chip that can be used to implement IoT security. Its cryptographic embedded controller enables developers to address heightened security measures with minimal effort without affecting the performance of the system. It is designed to support diverse nature of IoT security requirements. The CEC1702 employs both the ARM Cortex M4F processor alongside a full scale of peripherals and a multi-channel ADC, GPIOs, LED interfaces, UARTs, I2C, Timers, and SPI controllers.

The CEC1702’s distinguishing feature lies in its security capabilities. It combines secure storage and data protection features with several cryptographic engines. The chip also engages EAS crypto engine that embodies a crypto hash engine and public key engine that offers hardware support for numerous algorithms including RSA, ECDH, ECDSA among others. Hardware security can perform crypto algorithms orders of magnitude faster than any software-based methods can. This, in turn, enables developers to introduce strong encryption and authentication without affecting the performance of the application.

The CEC1702 can be used as a standalone MCU in an IoT design be used alongside an existing MCU. In such a setup the CEC102 is connected to the existing MCU added through SPI connections. On top serving more traditional needs for secure communications, the chip’s security mechanisms offer important support for wider lifecycle security requirements.

Secure boot

In an MCU-based IoT system, the CEC1702 connects to the flash memory storing firmware through the SPI. During startup, the CEC1702 begins running in the process holding the MCU in reset as it authenticates the security of the application code that used to boot the host MCU.

RoT lies with the sequential approach of the CEC102 toward firmware authentication required for a secure boot. On startup, the CEC102 powers up and then run the boot firmware stored in the ROM. The ROM code cannot be changed hence this step in the boot process creates a trusted foundation. This process is however not compulsory as developers can choose to load the application firmware without either the authentication or encryption. However, using these security measures helps in the continuation of the chain of trust to the end of the boot process.

During this secure booting process, the CEC1702 utilizes the security data that is held in its integrated Efuse one-time programmable memory so as to validate the firmware against information held in the firmware envelope. To successfully conduct authentication, the CEC1702 uses a public key contained in the Efuse to validate the firmware envelope’s ECDSA signature that is generated during image creation.

The signature is generated using a private key held by the customer thus it ensures that the firmware source is legitimate. When a developer engages encrypted firmware, the CEC 1702 winds up the authentication process with a decryption using ECDH key exchange so as to create the decryption key. In this process, the ECDH combines the NIST P-256 curve generator contained in the Efuse, the private key and the public key found in the embedded in the firmware envelope to derive the key to be used in decrypting the final image.

Easy implementation

Despite CEC1702’s complex security mechanism, the chip made it easy for developers to capitalize on the chip’s firmware authentication and encryption capabilities. For a software implementation, has been made easy by the company’s simple interface that is used to specify ECDSA and ECDH keys and generate Efuse data. For hardware development, the SecureloT1702 demo board offers a simple platform to jumpstart hardware development. The board has pushbuttons, LEDs, LCD and SST26VF016 16Mbit flash device for storing firmware images. These two tools ensure rapid development of highly secure IoT system easy and rapid.

Conclusion

IoT continues to be embraced rapidly across the globe. This means that poorly secured IoT devices pose a huge threat to IoT networks and applications. The single chip for IoT security offers a simple and affordable way to ensure proper IoT security.