Security and the IoT (Internet of Things) are inextricably linked, yet it is apparent that far too many end-points are still being brought to market with little or no security features. In the recent past, manufacturers may have underestimated the resolve of hackers targeting seemingly innocuous devices such as connected thermostats, but high-profile instances of data losses have made the threat only too apparent.
Through cloud connectivity, unsecured end-points can easily become open windows into an organisation’s back office, exposing customers’ financial details to the criminal element.
While these cases have successfully raised awareness of the problem for both manufacturers and consumers, understanding the solution could still be a hurdle. Implementing security is difficult, particularly in headless devices like IoT end-points and even more so for devices based on very low-resourced microcontrollers. For embedded developers in particular, security can be an unknown domain that demands an entirely new set of skills and technologies.
Chain of trust
While technologies, such as the Advanced Encryption Standard (AES), are now implemented as hardware blocks in many microcontrollers, and do a great job of turning plain text into something that can only be deciphered by the intended recipient, the process of encryption and decryption relies on keys. In order to be useful both parties need to have the relevant key, which is where security gets really interesting.
Key management is arguably the most critical part of a security protocol. They must be generated, distributed and stored in a way that shields them from nefarious elements. The IoT is expected to comprise tens of billions of devices in the near future, so while AES is largely accessible, key management in the IoT could be viewed as the real problem with adding security to end-points.
In effect, every single one of those billions of IoT end-points needs to be identifiable in a unique way, in order to know with certainty that it is genuine and authorised to be part of the network. Only then can it be trusted with the key(s) required to implement cryptography.
There are further implications with this topology; keys that have been distributed to trusted end-points are typically generated and stored centrally, in a database. If that database is compromised, all of the keys stored and, therefore, all of the devices in the field with those keys, also become compromised. That means every single key needs to be regenerated and redistributed. Not all IoT end-points will be equipped with over-the-air updates and if they are, it may not be implemented securely, which just compounds the problem even further.
Secure at every level
Often, discussions about security in the IoT focus on the exchange of data over the network, or the way those communication channels may be exploited. But encryption is also used to secure a design, more specifically the firmware in an embedded device, typically referred to as Secure Boot.
In order to validate the firmware hasn’t been changed it needs to be signed and, again, this requires a key. However, storing the key locally in Flash is an inherently insecure solution and one that introduces even more design complexity.
For security reasons, keys are typically installed at the time of manufacture, a process referred to as provisioning. To preserve the chain of trust, keys must be unique and auditable, a process that large manufacturers are empowered to handle in-house but smaller developers need to source; relying on a key provider, known as Certificate Authorities (CA). Once the device is put into service, or commissioned, it becomes a unique and authenticated device on a network.
Local provisioning
Using a CA also incurs a cost for every key issued, which can have implications for low-cost IoT end-points. In addition, many end-points will be based on low-resource microcontrollers that may not have the processing power required to execute complex cryptography algorithms in an efficient way.
To address these challenges a new class of device has emerged, one that provides security functions for resource-limited embedded devices. These crypto engine authentication devices provide hardware features for the secure storage of keys, but they go much further.
The ATECC508A and ATECC608A are members of Microchip’s CryptoAuthentication family and provide a number of security functions. This includes protecting firmware and other digital data through secure boot features, and the secure storage of that data. They can also be used to authenticate the device itself and thereby protect against counterfeit goods; this could be used to validate a peripheral or daughter board, for example, as well as other removable media (such as print cartridges). Figure 1 shows how the device might be used in an embedded design.
But perhaps the most relevant function these devices provide, in terms of the IoT, is the authentication of an end-point’s identification and support for key agreement and key creation for message encryption. These co-processors effectively provide hardware-based execution of public key algorithms at high speed, offloading it from the host processor.
Both elliptic curve digital signature algorithm (ECDSA) and elliptic curve Diffie-Hellman algorithm (ECDH) functions are supported and each device has a unique 72-bit serial number. The built-in RNG (random number generator) supports the cryptography functions and is designed to meet the requirements specified by the National Institute of Standards and Technology (NIST).
Deep dive
The devices are capable of implementing a complete asymmetric key cryptographic signature solution using a public and private key, up to 1000 times faster than a software-based implementation. It follows the elliptic curve cryptography and ECDSA signature protocol using hardware-acceleration of the P256 prime curve standard from NIST. This covers a wide range of functions including private key generation, ESDSA public key signature verification and signature generation, and ECDH key agreement.
Despite integrating all these advanced features the devices are small and low-power enough to be used in practically any IoT application. The host processor, which could now be an ultra-low-cost 8-bit microcontroller without any security features, communicates with the CryptoAuthentication device over either I²C or single-wire interface, so it only requires a single GPIO. The serial bus can operate at up to 1 Mbps and it is possible to connect several CryptoAuthentication devices to a single bus, in applications that use removable hardware or media, for example.
The two devices are largely compatible although the ATECC608A introduces some new features, such as secure boot function with I/O encryption and authentication, several new commands (including AES encrypt/decrypt) and an updated NIST SP800-90 A/BC RNG. It also includes a self-test command that can be configured to execute at power-up.
Secure key storage
Both devices are able to generate a private key and store it, so that it is never divulged to any other device. The public key associated with a stored private key is returned when the key is generated or can be calculated at a later time along with other secure elements derived from the private key.
As the key is generated and stored in the device itself during provisioning, there is no need for a central database. Figure 2 illustrates the various ways provisioning can be achieved using the CryptoAuthentication devices, for large, small or prototype volumes, without the need to invest in a hardware secure module (HSM).
With growing demand for security solutions developed specifically for IoT end-points and other resource-constrained devices, developers now have a viable alternative to ‘security through obscurity’ or power-hungry, software-based implementations.
For more information contact TRX Electronics, authorised Mouser partner in South Africa, +27 12 997 0509, info@trxe.com, www.trxe.com
| Tel: | 086 111 2844 |
| Fax: | 086 234 6870 |
| Email: | info@trxe.com |
| www: | www.trxe.com |
| Articles: | More information and articles about TRX Electronics |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version