Security for IoT Devices and Communication

As we enter the era of Ambient Computing and get immersed in lifestyle enabled by technology, IoT devices need to protect their users in such a way that they are not vulnerable to hacking from malicious entities.

Internet of Things (IoT) is made up of very small connected devices. These devices collect information using sensors and send the data to Cloud Servers. These devices may also control access, or provide access based on their sensors. Examples are Door locks, Fingerprint scanners, Thermostats, and now even vehicles are getting connected.

There are a few principles that an IoT solution architect must understand, for implementing secure communication.

• Symmetric Encryption protects communication, with a shared key. AES128 is the most well supported in the IoT devices.
• Sharing the Key requires Asymmetric encryption. Asymmetric keys are Public/Private key pairs, which are complimentary to each other. A private key will decrypt/verify message encrypted by a public key and vice-versa. ECDH (Elliptic Curve Diffie Hellman) is a very popular method for generating a shared key using an Asymmetric Elliptic Curve keys. Elliptic Curve keys use much smaller keys compared to the older methods, and are much more efficient, in using bandwidth and processing power.
• Asymmetric key Cryptography is much slower compared to Symmetric key Cryptography and so is used majorly for sharing keys or authenticating documents.
• Normally pre-generated Asymmetric keys are used. And the keys are signed by a known entity, called Certificate Authority. An Authentication method is required if Ephemeral Asymmetric keys are used, instead of pre-authenticated keys.
• Asymmetric key support is patchy in IoT microcontrollers, requiring pre-shared symmetric keys.
• In case of pre-shared symmetric keys, effort should be taken to produce different symmetric keys for different devices. Same key MUST NOT be used on all devices.
• TLS/DTLS is the best method for securing communication if available.
• Cryptographically secure Hash Algorithms like SHA256 are used to ensure integrity of documents. The hash values are then encrypted by the private key, so that anybody can verify with the publicly known Public key, that the document has not been tampered with. The encrypted Hash value is called a Digital Signature.
• Public keys are digitally signed by Certificate Authority to create Certificates, which are basically verifiable public keys.
• Cloud Server security is a separate and very important requirement.

IoT devices which are securing access to sensitive data or preventing physical access, must also implement device integrity features. Following principles must be followed by a designer for Device integrity.

• The device must only run code that is authorized to run on the device.
• Secure boot makes sure that only signed firmware binaries can be used during Firmware upgrade.
• Asymmetric Public Keys are used for verifying signed firmware binaries.
• Asymmetric Public Keys must be stored in Protected Non-Volatile Storage. Using Write Once memories are also good, for this purpose.
• Code which does the verification must also be protected from overwriting, or replacement.
• Basically, Secure Boot is a must for Device Integrity.

Different communication methods are amenable to different security solutions. We have worked on several wireless communication protocols in the IoT domain as we as a company specialize in Wireless communication. Following is a short summary of different communication standards and the appropriate security methods for each.

• The only BLE beacon protocol that provides privacy/security is the Eddystone-EID with Eddystone-TLM for data in the scan response. Eddystone-EID provides device anonymity and Eddystone-TLM provides Symmetric encryption protected data channel.
• BLE Connection mode uses Pairing Keys for communication encryption. Sharing pairing keys is done manually, and then the two ends communicate to create a shared key. Prior to BLE4.2 the process for creating shared key was not secure at all. The newer version is still not very secure, but is better now. BLE should not be used for devices that secure critical resources, unless a more secure encryption mechanism is built over the plain BLE communication channel.
• TLS/HTTPS should be used over Telecom Networks with high bandwidth, like LTE.
• For CATM1/NBIoT where the bandwidth is not sufficient, DTLS/COAP/REST is the preferred solution.
• For 3G, where the bandwidth can be sufficient but not reliably, it is better to use TLS for creating shared symmetric key. And then using it to encrypt data sent over TCP/HTTP protocols.
• 2G+GPRS cannot even support enough bandwidth to create shared symmetric key. It is necessary to use pre-shared keys, and then send encrypted data over UDP, with proper retries.
• WIFI Advertisements are not secure, but it is possible to have secure communication between IoT devices, with encrypted messages in Vendor Specific field.
• WIFI Communication should be secured with TLS/HTTPS.

We have worked on several devices with most of the above protocols. The security levels used depends on the requirement of the project and the capability of the processor. Below we will consider a couple of case studies and why the required security measures were used. Both of these do not support Device integrity features, as the devices do not control access to critical assets, and the devices themselves are not high value.

Bluetooth Beacon project

In this project BLE5 beacon device based on NRF52810 was built. This particular device has very low Flash storage 192Kb, and the required Softdevice (Nordic firmware providing Bluetooth stack and utilities), uses half of it, at 96Kb. Also, for every project we build, we make sure to include Over the Air upgradeability. This is very important for fixing bugs that inevitably creep into the software. The OTA bootloader uses a large part of the flash. This project required connection-oriented functionality. For this ideal would be to use Pairing keys based encryption. Unfortunately, there was not enough memory left to include the software required to add pairing code provided by Nordic.

We included the following security measures.

• After connection, the first service to be invoked needed to provide a pass code. If the pass code is not received within a few seconds, after connection, the connection was disconnected.
• The passcode was made per device, defined at the time of manufacturing.
• All the communication between mobile and device were done with a couple of services. The data exchanged is basically a stream of bytes which is encrypted using AES128 with the passcode. This means that the data cannot be understood without knowing the passcode.
• The data contains all the actual command/response codes and values.
• Even if somebody discovers the passcode of the device, only that device can be manipulated.
• The uC does not have hardware support for Public Key encryption, but Nordic Bootloader provides software-based support for Asymmetric Encryption. It requires that Application firmware must be signed before it is uploaded to the device. The Bootloader verifies the firmware’s signature, before upgrading the device.

Asset Tracker

In this project we have made a NBIoT/CATM1 based asset tracker. It provides location information over NBIoT/CATM1 network. It needs to be as power efficient as possible, as it is a battery-operated device. It has a STM32 based microcontroller. It uses the following security features.

• NBIoT/CATM1 is not fast enough to do HTTPS communication. The PDP context is not saved for a long enough time for the device to be able to sleep for long times, required for power saving.
• We used a TCP connection to the server. The data is encrypted using AES128.
• The uC does not provide Public Key Cryptography. A home grown 2048bit RSA Public Key decryption algorithm is used to decrypt the AES key, which is provided by the Server every few days.
• The RSA public key is also used to verify the hash of the firmware image, during OTA.
• OTA software is home grown for this device.

Conclusions

Internet Connected devices must support encryption to prevent, snooping and hacking from malicious entities. This document provides several important aspects that must be considered during implementation of IoT devices.