This content is part of the Essential Guide: Mitigate IoT security risks with a strong defense strategy
Tip

Three IoT encryption alternatives for enterprises to consider

The use of cryptography alternatives for IoT devices grants users certain benefits and potential security challenges. Learn more about each alternative with expert Judith Myerson.

The quest to secure internet of things and connected devices while consuming less energy and computing power is one that seems endless. A major obstacle in this pursuit involves encryption, as many of these devices don't have the power requirements to handle standard cryptography.

In this article, we'll consider three IoT encryption alternatives:

  • physical unclonable function circuitry;
  • elliptic curve cryptography in fog-computing-based subscriber and publisher protocols; and
  • entropy as a service.

Alternative No. 1: Physical unclonable function circuitry

Small memory sizes in IoT systems can physically limit cryptography and computation. One solution to the IoT encryption problem is the physical unclonable function (PUF) circuitry to generate randomness of a secret private key that cannot be cloned or duplicated on a different chip.

The PUF is based on physical variations that occur naturally during the manufacturing of chips while the technology uses variations specific to a device, serving to the device's unique identifier. The device's owner doesn't have access to the private key, because the key is generated when a message is ready to be signed before it is transmitted. When the key is no longer needed, it is destroyed, as it is not possible to store it in the microcontroller's small memory map.

Different device manufacturers have different ways of using PUF technology for IoT devices. In a typical scenario, a device manufacturer can issue commands to the device to compute a public key that corresponds to the private key, as the manufacturer needs a corporate private key to sign the public key. A certificate further ensures the public key presented by the device matches the public key the manufacturer created. After deployment of a device, the message recipient has only the public key to verify the device sent the message.

Furthermore, researchers at the University of California, Los Angeles, have proposed several PUF technology services, as some PUFs were found to be unstable. Stable PUFs and digital public PUFs can better secure data.

Alternative No. 2: Elliptic curve cryptography in publish-subscribe fog computing

One problem with adopting fog-computing-based subscriber and publisher protocols is security mechanisms for resource-constrained IoT devices don't exist.

Fog computing has been used increasingly to process the events of the IoT device closer to the source for faster response. Subscriber and publisher protocols have been used in decoupling the sending, or publishing, party and the receiving, or subscriber, party, where the message broker -- like in Message Queue Telemetry Transport and Advanced Message Queuing Protocol -- sends new messages to all subscribers.

One problem with adopting fog-computing-based subscriber and publisher protocols is security mechanisms for resource-constrained IoT devices don't exist. Traditional protocols like SSL and TLS require the consumption of large resources to encrypt communications over insecure networks. In addition, as fog network systems get larger, performance overhead increases.

Researchers at La Trobe University in Australia set up a man-in-the-middle attack scenario to demonstrate the weakness of the SSL and TLS protocols. As ethical hackers, the researchers exchanged messages between the subscriber and publisher and the fog broker. The two parties believed they were directly communicating with each other when the entire conversation was controlled by the researchers.

To meet the challenges of IoT encryption, the researchers proposed using elliptic curve cryptography (ECC) to secure fog computing based on the publisher and subscriber lightweight protocol. The ECC provides shorter key lengths, smaller message sizes and lower resource usages, while fog nodes offload some of the computation and storage overheads from IoT nodes in proximity. Combining lightweight schemes allows for better scalability and fewer overheads than RSA-based schemes employed in SSL and TLS.

Alternative No. 3: Entropy as a service

Strong cryptography secures data on laptops, workstations and servers that have adequate resources to compute randomness of cryptography keys. Different light cryptographic keys have been implemented to work with IoT devices that tend to be small, resource-constrained, headless or embedded. Entropy random data from IoT devices is not sufficient to generate strong cryptographic keys. IoT devices are entropy-starved, as they lack reliable entropy sources, such as mouse movements. And hard-disk characteristics of laptops need to produce hard-to-guess random data.

To overcome issues with light cryptography, the National Institute of Standards and Technology (NIST) recommends entropy as a service (EaaS) to provide time and quantum entropy sources to IoT devices. The main components are the quantum entropy device, the EaaS server and a hardware root-of-trust device -- such as Trusted Platform Module, Intel Identity Protection Technology and ARM TrustZone -- in the client system.

As NIST explains, EaaS doesn't generate keys, but enables client systems to generate strong cryptographic keys. The EaaS server has no way of finding out how the keys are generated by the client systems, as entropy to IoT devices is provided by EaaS on boot. To transfer entropy payloads from the service to clients, EaaS uses HTTP, while the server encrypts the data using the public key provided by a client. To complete the transmission, the server uses its own private key to digitally sign the payload.

Conclusion

IoT circuitry needs to be redesigned in order to increase entropy for less energy consumption. In the meantime, full cryptography alternatives will grow to meet the challenges of securing IoT devices that are resource-constrained and entropy-starved.

Dig Deeper on Threats and vulnerabilities

Networking
CIO
Enterprise Desktop
Cloud Computing
ComputerWeekly.com
Close