Making your device secure
The internet of things is faced with a major security challenge. Compared to traditional, often unconnected embedded systems, the nature of IoT devices radically increases the risk of attack not just on devices but on the services with which they interact. The ability to connect to IoT devices over the internet makes them, in principle, accessible from any other user of the global internet. That has made it possible for hackers not just to break into devices but recruit them for use in botnets, as the Mirai malware infestation of 2016 demonstrated so powerfully.
by Mark Patrick, Mouser Electronics
One of the reasons why the Mirai hack was so effective was the decision by manufacturers of affected devices such as home routers to make it easy to gain access to them and change their firmware. Many of the devices had shared passwords and security credentials. An attack on one would be successful on all.
Providing each device with its own security credentials for identification and access is the first step to securing IoT devices. But on the scale of the IoT it is potentially an expensive mechanism if an installer has to configure and provision each individual node manually. The answer is to make provisioning a fundamental part of the device’s security architecture by building the system around a root of trust.
Other machines need to be able to trust the device. And, before it attempts to start providing services to other machines, the device needs to trust them. Any other attempts to communicate need to be treated as if they come from imposters unless they can provide the right credentials. Man-in-the-middle attacks are becoming increasingly common. The system designer has to assume there will be attempts made to impersonate legitimate servers or devices in order to gain access to secure details. Not only is it essential to establish connections only to trusted devices but to encrypt and digitally sign the packets to prevent eavesdropping. The signing process makes it possible to detect tampering by network equipment that has been subverted.
The X.509 standard is one mechanism for achieving trusted communications. The standard is based on public key infrastructure (PKI) technology to associate a public key with the identity of the certificate’s owner and enforces a chain of trust based on the private key held by the certificate holder to ensure that interlopers cannot provide forgeries.
In the X.509, certificates refer back to a core root certificate maintained by a known provider. Through the Distinguished Name of the issuer on each child certificate, a client can obtain the public key of the certificate further up the hierarchy to check that the signature of the certificate is legitimate. An IoT device supplier might choose to employ a three-tier hierarchy. In this, the root certificate is held by the manufacturer. A group of devices might use a certificate derived from that root. Most importantly, each device has its own certificate derived from the device-family certificate that can easily be checked to ensure that it is a true derivative of the original root certificate.
With the chain of certificates established, the manufacturer is then faced with creating a mechanism for installing a unique certificate on each device it sells. A key requirement is that the certificate is stored in non-volatile memory that offers tamper resistance. Some companies in the finance sector use battery-backed SRAM to do this. If tampering is suspected, the battery connection is temporarily removed so that the key is destroyed rather than risk it falling into the wrong hands. But the storage mechanism is only part of the solution. The manufacturer needs a convenient but secure way to transfer private keys to individual devices. This can be difficult in today’s distributed supply chains. The manufacturer may have to deliver private keys to subcontractors that cannot provide strong security guarantees.
One solution is to use a device with a readymade certificate infrastructure. The Microchip Atmel ATECC508A is a cryptocontroller with key storage based on the Elliptic Curve Diffie–Hellman (ECDH) technology that employs cryptographic countermeasures to guard against physical attacks.
Microchip supports the device with a secure key-management infrastructure. Instead of being programmed at the manufacturer’s subcontractors, the application or customer certificates are created and stored on the Microchip secure manufacturing line. Once programmed, can be soldered onto the target PCB with no further intervention. It works with a host microcontroller attached using I2C to perform authentication functions.
A further benefit is that Microchip is working with Amazon Web Services (AWS) to handle the tasks of authentication and provisioning when the device attaches to the internet after deployment. More information on this zero-touch provisioning solution can be found here.
To be trustworthy to others, the device needs its own root of trust. Although secure key storage ensures digital certificates remain correct, on its own it does not stop hackers from breaking into the system and loading their own code that makes use of those certificates to spoof other systems on the network. There needs to be mechanisms in place to ensure that the code on which the system boots has not itself been tampered with.
Secure boot, assisted by hardware authentication, ensures the validity of code. The process ensures that the device boots only using authorised code. When the device starts up and reads the code from onboard read-only memory (ROM) it checks that each block has a valid signature from an authorised supplier. This can be achieved using the same digital certificates employed for network communication. The code signature is generally created as a one-way hash of the code itself combined with the private key. If the device encounters a block of code that is incorrectly signed, it stops loading the compromised software. At that point, it can move into a factory-programmed state and request maintenance.
A key advantage of secure boot is that it provides an infrastructure that makes firmware over-the-air (FOTA) a safe process. Using digital certificates, the device can check first that the update comes from an approved source. Once downloaded and inserted into program memory, the secure-boot process can check the code-block signatures as they load. If they have been compromised, the device can roll back to the earlier firmware if it has enough space to hold both, or move into the recovery state.
Although it is possible to implement some forms of secure boot without a hardware trust module, it is hard to ensure that the boot process will halt correctly if the hacker has penetrated far enough into the firmware. A growing number of microcontrollers have built-in support for the cryptographic functions needed to support secure boot together. Examples include Silicon Labs’ Jade and Pearl Gecko microcontrollers.
At the module level, Digi International has made security a key element of its DigiConnect 6 and 6UL, which are based around NXP Semiconductors’ I.MX6 applications processors. The TrustFence technology, see Figure 3, used by the modules provides out-of-the-box support for secure boot, in addition to encrypted local storage and certificate management features.
Although the ubiquity of the internet makes any IoT device a potential victim of hacks and attacks there are ways to protect against these problems. By investing in solutions that build upon a root of trust with proven PKI technologies, service providers can be sure the IoT devices they use are legitimate and that their precious data is protected.