Build a secure supply chain for asset management with ease

One of the biggest advantages of the Internet of Things (IoT) is the ability to receive live data on devices, not just on their status but their location. This makes it easy for operators to see where assets are at any one time, how they are being used and whether that usage complies with service-level agreements. However, the connectivity needed for devices to report their location at regular intervals leads to vulnerabilities that can, potentially, be exploited by hackers.

Exposing vulnerabilities

Without effective security, a hack that can disrupt asset management is the replay attack. In this form of attack, the hacker eavesdrops on the data packets that a device uses to report its status to a gateway or other devices on the network. The hacker analyses this data to look for patterns in an attempt to reverse-engineer the protocol used for status updates that they can use later in an attack.

One possible attack is a denial-of-service (DOS) attack that floods the network with seemingly authentic messages that contain spurious location updates and other data that corrupt the database of assets. A more subtle and simpler attack is to disable the tag on an asset before it is moved illegally and then replay messages that show the asset as being in its original location.

Above: Unlike many other IoT-oriented networks, LoRaWAN implements end-to-end encryption for the application data transferred between sensor nodes and application servers

Another form of attack that is difficult to detect but which can have serious consequences for legitimate users and operators is the man-in-the-middle attack. In this scenario, the hacker introduces their own wireless gateway to intercept messages from devices. The fake gateway manipulates the data before passing it to the server. Replies from the server through that gateway can be altered the same way. Such an attack can have serious consequences as it allows the hacker to take control of part of the system and, using that as a base, to launch further attacks on the service.

IoT-based systems must have end-to-end security

To prevent these and other attacks, end-to-end security is a vital component of any IoT-based system, especially one that needs accurate location updates. The problem for IoT devices and location tags in particular is that they have severe constraints on energy usage. This calls for location technologies and a security infrastructure that can operate as efficiently as possible. It is a design constraint that rules out the technologies and components that have been developed for smartphone and tablets, even though there are many devices that can, when used together, support the core requirements of the application.

A key advantage of LoRaWAN is its inherent security. Unlike many other IoT-oriented networks, LoRaWAN implements end-to-end encryption for the application data transferred between sensor nodes and application servers. A device cannot even join a LoRaWAN network unless it can provide credentials that satisfy a server that controls access. As it was designed specifically for IoT devices that have constrained power envelopes, the LoRaWAN architects were careful to choose a framework that takes energy efficiency as one of its core objectives without sacrificing adherence to widely accepted industry standards. The best combination of security and power efficiency identified by the architects lay in the AES cryptographic algorithms, which have become widely adopted as reliable and effective for constrained nodes and networks.

Each LoRaWAN-compatible device needs to be personalised with a set of unique identifiers and AES encryption keys that will be used not just to let applications protect the data they send but to join the network when it is commissioned and attempts to go online. The commissioning process involves a request to a Join Server that performs the initial authentication routines and checks the device’s credentials.

It performs this check using the AES cipher-based message-authentication code (CMAC) protocol. Once the authentication code has been computed and verified, the join server and device cooperate to create set of session keys. The keys are distributed to the device and to relevant application servers, to ensure a separation between application data and network management messages. By doing so, there is no need for applications and the network operator to share keys.

Secure key storage and programming

All traffic is protected using the session keys. In addition, payloads are protected using the AES counter (AES-CTR) mode, which embeds integrity codes into each packet. The combination of protections helps prevent packet-replay attacks and man-in-the-middle attacks. However, due to the need to have keys embedded in a device before it can join the IoT and start work, the security of any device is interwoven with the supply chain. To maximise security, the root key should never be used directly. Instead it is used to generate derived keys that can be used for short periods of time and for specific uses.

The device itself needs to be designed in such a way that, once injected, the root key and its derivatives cannot be read out by accessing memory. Instead, the device should only use the key to encrypt data, generate hashes and digital signatures that are used to verify authenticity. The design of the LoRaWAN network stack fully supports this approach through the use of protocols that make it possible to link encryption keys with identifiers to identify devices and applications remotely.

To guarantee that keys are kept protected and not disclosed inadvertently or through cyber crime, the organisation of the supply chain is of critical importance. An AES key, especially one that provides the core credentials for a device must be protected at all times, in every step from key generation through insertion into the device to final decommissioning when records both in the device and in communicating systems are finally deleted. An issue for many OEMs and integrators is that they do not have full control over the supply chain. Most use outsourced manufacturing to provide them with cost-effective hardware. To program keys into a device, unless they deploy their own device programmers in-house, they have to reveal key data to third parties. A hacker with access to the programmer used by the contract manufacturer is able to intercept the keys and copy them for use later.

There are mechanisms that support secure key transfer and programming. Typically these involve a hardware security module (HSM) integrated into the manufacturing line. Although a HSM safeguards key data, its incorporation into a supply chain often involves high setup and management costs, making it harder to justify for many users.

Maximising security at low cost

Designed for use with LoRaWAN, the Semtech LR1110 solves both the problem of secure key storage and programming. Semtech has incorporated a HSM into the core production flow of the LR1110 to ensure private keys and personalised network IDs are injected in securely before delivery to the OEM or contract manufacturer. A customer does not have to use the programmed keys. They have the ability to overwrite them in their own facility or with the help of supply-chain partners if they need specific codes. All keys, whether programmed by a customer in their own facility or in Semtech’s HSM, are accessible only by an on-chip cryptoengine and cannot be read out through an external bus or port.

Designed to enable the secure connections needed for LoRaWAN, the cryptoengine implements a standard set of security routines that are employed by an external microcontroller to implement IoT and location-tag functions. The simple API offered by the LR1110 provides an easy way to have application data encrypted before transmissions and to perform other services such as hash functions to check the integrity of data. As the cryptoengine is on the same die as the secure memory and secure protocols, such as those used for LoRaWAN, never use stored keys directly, but generate derived keys to encrypt messages - the architecture maximises protection.

Like LoRaWAN itself, the cryptoengine is optimised for low power consumption. This better supports the needs of devices such as asset-management tags. Many off-the-shelf secure-element ICs are designed to handle a wide range of encryption technologies, which tends to increase cost and power consumption.

The default configuration provides each device with the core credentials needed to join LoRaWAN with the help of an ID code transmitted to the OEM that ensures the device can identify itself properly to a Join Server when it is commissioned.

In addition to its LoRaWAN and security features, the LR1110 implements the core functionality needed to receive data from GNSS and WiFi transceivers, which provides further cost and power savings through an innovative cloud-based solution. For example, rather than incur the processing overheads typically needed to decode and interpret GNSS packets, the device can use the LoRa Cloud service to process that information remotely and deliver location updates over the LoRaWAN connection. By doing so, the design maximises battery life. A typical asset-management tag can enjoy a lifetime of several years from a single charge in contrast to the three-to-six months encountered with non-integrated designs that use separate secure-element and GNSS and WiFi front-end silicon. The result is a solution that maximises security at low cost and with far easier systems and supply-chain integration compared to other approaches on the market.