IoT security requires an end-to-end approach

Nicolas Demoulin, Microchip Technology

A law passed at the end of September 2018 by the Californian senate that represents one of the attempts by governments around the world to deal with the problem of security in connected devices is an indication of the way in which society is slowly coming to terms with the reality of widespread hacking and cybercrime. But enforced steps like these will not combat the core problem.

Hacks are becoming more sophisticated and often designed to exploit multiple devices at once so they can be used as access points in distributed denial of service (DDoS) attacks or recruited into large-scale botnets to carry out other cybercrime operations. The ability of hackers to automate attacks to penetrate multiple copies of the same device is frequently the result of a poor security architecture and weak protection of security credentials.

Very often, the reason why hackers find systems to be so vulnerable is because the product designers favoured ease of installation rather than trying to achieve acceptable security. Weak passwords - sometimes as simple as four zeroes in a row are an easy short-cut - make it easy for users to perform initial setup.

Even complex passwords, if shared across devices, threaten the entire population of installed devices. Once hackers are able to decipher the password by analysing a single unit, perhaps using sophisticated side-channel attacks, they can apply that same password to any target units.

In end-user devices such as home gateways one solution adopted by manufacturers, and which would be acceptable under law enshrined in the California "Information Privacy: Connected Devices" act, is to program a unique password into the device and place a sticker on the unit to inform the customer or installer. However, this is not a solution that scales well in the age of the internet of things (IoT). Many applications call for automated commissioning and provisioning. Even if an installation engineer is available, there are design issues with password-based protection. Not only does the lack of a user interface suitable for entering passwords make this traditional approach to securing an IoT device impractical, attaching a visible password to any device risks exposing it to any unauthorised person who has access to the unit. Although individual passwords can limit the extent of a single attack, there remains a high risk to the network of devices being accessed and reprogrammed maliciously and which may then exploit other weaknesses. What is required is an automated way of deploying secure credentials to the simplest of devices.

As an IoT device needs to connect to a server to perform its full set of functions, a simple mechanism is for a device to connect to a network using a standard set of credentials and a unique digital-identity code that is used to identify each individual unit. Once it recognises the device’s digital-identity code, the server can set up an encrypted channel and relay the information needed for the device to log in to a secure server and report its data.

There is a critical flaw in the design of this simple mechanism. All that an attacker needs to do is use trial and error to find unused but valid digital-identity codes or use obvious patterns in the way that the codes seem to be generated and then spoof them using their own tools. They can, alternatively, obtain a list of valid digital-identity codes through social-engineering techniques or interception at the factory where the devices are programmed and use those to gain access to the network. With access to wireless gateways, hackers can also intercept communications using man-in-the-middle attacks. With their own malicious devices in place following commissioning, attackers can attempt to hack into other parts of the network or disrupt the core service itself.

Figure 1: ECCx08 in usage

What is required is a means of identifying devices reliably using credentials that cannot be obtained by other means. This can only be achieved by using appropriate security practices and by taking the entire supply chain into account.

The first problem is to identify an IoT device is legitimate. This is an attribute that can be achieved using keys, either we refer to public key infrastructure (PKI) technology and digital certificates that contain the public key or simple public/private key pair without certificate involvement. Under a PKI, each device has a unique private key that is related mathematically to a known good digital certificate that is kept secure by the manufacturer. This private key is used to sign a challenge to identify the device uniquely to any server that has access to the corresponding public key. The public key is a publicly visible set of information and so does not present a risk if that key is distributed to unauthorised users.

Digital certificates can be managed using standard protocols such as X.509. Under this standard, all digital certificates refer back to a core OEM certificate through a hierarchy of child certificates. Through the name of the issuer on each child certificate, a client can obtain the public key of the certificate further up the hierarchy to verify that the signature of the dependant certificate is legitimate.

A three-tier hierarchy of digital certificates is a suitable choice for many IoT applications. In this, the OEM certificate is held by the end product manufacturer. Each individual customer would then use ansigner-level certificate derived from that OEM certificate to generate device-level certificates. Once each device has its own certificate, the information it contains can be checked to ensure that it is a true derivative of the original OEM certificate.

Figure 2: Secure flow with Microchip

X.509 provides a mechanism to make it possible to identify devices as being legitimate. And it does not suffer from plaintext systems such as serial numbers. But it is insufficient on its own to guarantee that intermediate- or device-level certificates and associated private key cannot be compromised at some point in the supply chain. In many supply-chain scenarios, the certificate data needs to be programmed into each device during or after board-level assembly. A manufacturer might use a serial flash programmer to load the certificates and associated private keys into non-volatile memory on each unit on the manufacturing line. A customer could use an externally accessible serial port to load blank devices with the appropriate keys and certificates when they take delivery. But with these approaches there are major risks that private keys can be accessed using network-based hacks or social engineering.

A further issue is that of post-sales interception. A hacker with physical or network access may be able to extract private keys later on or corrupt the device if the non-volatile memory is not protected. A key requirement for ensuring these errors are mitigated is to have a hardware-enforced root of trust. The root of trust ensures there is no known mechanism by which the private keys or other critical credentials can be leaked by the embedded system. This involves both tamper proofing, side channel attack protections and support for firmware validation.

Secure boot ensures the IoT device can only run authorised code. Any attempt to run code loaded by a hacker that may act maliciously is blocked at the hardware level. In operation, the device can only boot from code blocks that are hashed and signed with a private key owned by the OEM. If the device encounters a block of code that is incorrectly signed, it stops loading the compromised software and attempts to revert to a factory-programmed state or, if unable, deactivate.
Firmware validation is also fundamental to making it possible to provide firmware over-the-air (FOTA) updates to IoT devices without risking them being compromised. Digitally signed updates can be checked in a similar manner to boot code for authenticity before the update is applied. Once in place the code stored inside will have to pass similar secure-boot tests as the firmware it replaces.

One approach to enforcing secure boot and key storage is to incorporate all of the required blocks into a microcontroller. However, such secure microcontrollers are not available in the many variants that embedded designers can come to expect, which can increase the system cost. A scalable alternative is to employ a dedicated secure element such as the ATECC608a. This device provides a combination of key storage and cryptographic acceleration functions that can complement any kind of microcontroller and processors. When the microcontroller needs to load code from bootROM, the microcontroller requests verification from the truly immutable public key held by the ATECC608a.

In a complementary way, communications with a remote server can be initiated using PKI protocols that derive ephemeral keys necessary for TLS sessions from the stored private key. The private key itself never leaves the ATECC608a as it is generated inside the device, by the device, inside Microchip secure factories equipped with hardware secure modules (HSM). Furthermore, the secure element uses a variety of mechanisms to secure the keys from extraction even in the event of physical attacks such as decapping. For example, an active metal shield over the die will deactivate functions of the chip if an attacker interferes with the shield in an attempt to probe the device physically. Countermeasures against known side attack channels such as glitching attacks and differential power analysis prevent the key data from being obtained using some of the penetration testing tools easily accessible on the market.

Figure 3: Firmware validation setup

In contrast to many manufacturing processes, the design and manufacture of the ATECC608a takes account of the supply-chain challenge that faces IoT developers as well as the logistic complexity of distributing keys. Rather than supplied blank for later programming, the secure element is shipped from Microchip’s secure facilities to the customer or contract manufacturer with keys and necessary certificates already in place. This ensures the keys are never revealed nor exposed to third parties, minimising significantly the risk of disclosure.

The final link in the supply chain is during installation and provisioning. The device needs to be sure it is connecting to a legitimate service in the cloud when it starts up and is not being spoofed by a man-in-the-middle attack that might be used to reveal secrets collected by the device itself. The device can ensure it is talking to an authorised server using PKI interactions.

To provide the server with a certificate or public key, Microchip sends the customer matching signer certificates or public keys: generating them using the HSM setup before shipment. The customer can choose to use these certificates andpublic keys directly on their on-premise server or leverage them to a third party cloud-services provider such as Amazon Web Services (AWS) and Google Cloud Platform to handle the chain of trust that guarantee each valid device is talking to an authorised server directly. Once the necessary connections are set up, the IoT device becomes a full member of the network with a unique, trusted, protected and managed identity, passing data using securely through encrypted protocols such as TLS.

Although digital certificates and PKI provide access to a wide range of web services, the overhead on the simplest sensors nodes can be considerable. Cloud providers have developed mechanisms that take advantage of the PKI infrastructure without demanding the use of full X.509 certificates on each end devices. Google Cloud, for example, working in partnership with Microchip can deliver the benefits of secure provisioning and operation to even the simplest of IoT devices. Google Cloud IoT core authorisation does not require the creation of full digital certificates. Instead, it makes use of simpler “JSON web tokens” (JWT) that are generated based on the private key held inside the ATECC608a.

When a device first connects to the network, it accesses the Google Cloud at mqtt.google.com. Conventionally, this is a password-based login. However, Google Cloud also accepts a JSON web token (JWT) in place of the password and uses this data to both authorise a new device and associate it with its digital twin in the cloud. The simple protocol allows implementation on simple 8bit microcontrollers without compromising security in any way. The close partnership between Microchip and Google ensures end-to-end secure handling of device credentials.

Through services such as the Google Cloud Platform, users of the ATECC608a gain access to cloud services securely from practically anywhere in the world and without the burden of owning private servers in a secure way. The end-to-end supply-chain model offered by Microchip to work with cloud services such as Google and AWS means that IoT developers also do not have to implement their own provisioning technologies either - and risk making mistakes that give hackers access to their core data. The result is a holistic approach to connected-device security that is ready for the present and future IoT.