As the internet of things (IoT) develops, the issue of security is taking centre stage. The connectivity and protocol standardisation that the IoT entails increases the threat to devices and, through them, the service networks to which they provide access. A number of threats have already become apparent, such as the hacking of motor vehicles through their Internet-connected infotainment systems and a variety of attacks on industrial as well as home devices and even toys.
In many cases the hacks were comparatively basic because of weak precautions taken by the manufacturers. Devices are often shipped with a standard and easy-to-guess password. The apps used to program IoT devices often contain information about their internal data structures, providing hackers with useful ammunition.
By focusing on IoT endpoints and devices, hackers can enable a number of attack types, from simple observation for gaining information useful for a larger infrastructural attack to direct manipulation of the device or the network. What is needed is an architecture for IoT devices that builds upon a true root of trust.
A root of trust provides a means to set up secure communication with only certified users and applications, reducing the ability of hackers to send messages to a device that may compromise its security. The root of trust also provides a means for the network itself to authenticate the device to prevent hackers from using their own hardware to break into systems by impersonating approved devices.
The keys and certificates used by secure protocols need to be stored in memory, but this needs to be a memory area that is separate from that used for application data. To be trusted, those keys and certificates need not only be valid but be protected from inspection by secure circuits in the hardware that prevent readout by any unauthorised user. Cryptographic processors complete the implementation by providing direct support for the protocols needed to securely authenticate and communicate with the device without risking the exposure of the full secret keys and certificates to other software running within the device.
Although there has been widespread criticism of the poor security of early IoT products, infrastructures based on the root-of-trust concept already exist and are in mass production. One example is that of the digital mobile phone, designed to support the GSM and later 3GPP standards, that has incorporated strong security as a key part of its makeup.
For it to be able to access the cellular wireless network, every phone must include a subscriber identity module (SIM) that provides the means for operators to authenticate and communicate with the handset or device. A similar hardware construct is the Trusted Processor Module (TPM) originally developed for personal computers and now used in embedded products such as point-of-sale (POS) terminals. At the heart of these modules is the public key infrastructure (PKI) architecture. It is an architecture that provides a number of facilities to support the various security needs of IoT devices and has begun to appear not just in devices developed for phones and PCs but leaner embedded systems.
PKI revolves around the concept of asymmetric cryptography, in which documents and other software objects are signed and checked using a combination of private and public keys. The mathematics of PKI relies on the inability to easily derive a private key from an associated public key. The public key may be disseminated freely. The private key needs to be protected. Within an embedded device, a securely made cryptoprocessor with protected memory provides the ideal substrate. One example is the PIC24FJ128GB204 with 128 KB of on-chip RAM and hardware cryptographic support. It is a member of the PIC24F GB2 family of microcontrollers made by Microchip Technology.
A key facility of a hardware trust module processor is to ensure that when the device boots it is running only authorised code and that an unknown outsider has not compromised it. This is known as secure boot. When the device starts up and reads the code from onboard read-only memory (ROM) it checks that each major segment has been signed by an authorised supplier. The supplier uses a private key to sign the code block. This signing process creates a one-way hash of the code itself combined with the private key. The hardware trust component examines the hash to check it for authenticity. Any changes to the codebase need to be signed using an appropriate key that the trust module checks before installation or update continues.
If the device encounters a block of code that is incorrectly signed, it will typically block the loading of the affected software and may move into a recovery state that attempts to obtain authorised code from the original supplier – possibly reverting to factory code stored in ROM – and send an alert, if it is able, to a server.
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. The processor in the hardware trust module can enforce security by performing decryption of key parts of the firmware on behalf of the host processor only if the hash is correct and to refuse decryption service to any software component that does not have a correct hash or key. With the ability to protect on-chip keys and prevent them being changed or read out by an attacker, Microsemi’s range of Flash-based FPGAs, such as the SmartFusion 2, can be used to support secure boot and other security functions.
Once the device has booted correctly, it can authenticate itself to the network using PKI mechanisms. Typically, the device will set up secure communications using a protocol such as Transport Layer Security (TLS), an adjunct to the commonly used HyperText Transfer Protocol (HTTP). Digitally signed certificates stored within the hardware trust module provide remote servers with the confidence that they are communicating with a known resource. The actual certificate is stored within the trust module so that only publicly accessible data is supplied over the network and the device’s own internal bus to prevent hackers from being able to make use of eavesdropping techniques.
Without a hardware trust module, the hacker may be able to use a logic analyser or other instrument to probe the memory of the device and obtain the secret keys and certificates that can then be used to spoof the network servers. Conversely, the IoT device needs to be sure that it is taking commands only from other devices or servers that it can trust. By having the hardware trust module check the certificates of those other devices against keys stored in protected memory the device can ensure it is communicating only with authorised systems.
As service profiles will change over time, the use of PKI exchanges allows certificates to be added or deleted. This ensures not only that services can be enhanced over time but other systems that are no longer part of the network or which are known to be compromised can be taken off the trusted list.
By taking advantage of the experience and technological infrastructure that has been developed for mobile telephony and computing, IoT manufacturers can gain a head start in providing a secure base for their products. The availability of devices such as members of
Microchip’s PIC24 GB2 family and the Flash-based FPGAs from Microsemi provides IoT manufacturers with easy access to those technologies, giving them a solid foundation for the secure IoT.
For more information contact TRX Electronics, +27 (0)12 997 0509, info@trxe.com, www.trxe.com
| Fax: | 0862 346 870 |
| 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