All IIoT installations should concern themselves with security. In this article we will discuss the security architecture and various industry standards utilized between sensor “hubs” in the field, and the Valarm Tools servers.

Valarm Tools receives data primarily from two sources (hardware devices):

1. Yoctopuce Sensor Hubs (connected to the internet via WiFi, Ethernet or Cellular), and 2. Android “smart” devices running the Valarm Pro custom app. Both of these devices use a similar approach to security. Both are generically known as a “Device” by Valarm Tools.

In Valarm Tools, a Device is a provisioned module/sensor host/hub which has a system-wide unique Device ID and a customer-editable friendly name.

The Device ID is a BSON ObjectID. Here is an example: “5b7b2303f8c6c61dea68e9eb” (this is a real BSON ObjectID generated by one of our dev/test machines). A BSON ObjectID is not a simple, monotonically increasing integer, and will appear extremely distinct to the layperson. Without knowledge of other ObjectIDs utilized within a system, it would be rather difficult to “guess” an ObjectID that would be known as valid to the system in question.

However, BSON ObjectIDs are far from random, contain almost zero entropy, and should certainly not be considered a part of security. They are used by our system due to their speed of generation, and more importantly, the efficiency with which our underlying database can use them as indexed keys.

When a Device is newly provisioned in Valarm Tools, the system also generates an “API Key.” This API Key is (almost certainly) unique to each Device, and is used in combination with only a single Device ID. I say “almost certainly” because the key is generated by a random-key generating library, and while it is mathematically possible that the library might generate the same key twice in the context of all devices registered within Valarm Tools, it is tremendously unlikely.

This API key is a 20-digit alpha-numeric string, for example “siHQvXbiwe4NvNMpbw6f” (this is a real example generated by our test servers) – this string contains tremendous entropy and is impervious to dictionary and rainbow attacks. We offer no function to allow the user to edit this string or otherwise compromise its integrity. The point is, each Device has it’s own API Key, and that API Key is impossible to “guess” by anything other than brute force attack.

The API Key is available for use in multiple contexts as described below. First we will cover the integrity of data sent from the hardware in the field (“sensor hubs”), to the Valarm Tools servers.

Messages sent between the sensor hubs and the server are cryptographically “signed” using the Device API Key. When a sensor hub is configured for use with Valarm Tools, the Device API Key is stored in the sensor hub’s hardware (in NVRAM in the case of Yoctopuce sensor hubs). The hub uses the key to generate an HMAC-MD5 signature of the message packet to be sent to the Tools servers.

This HMAC-MD5 signature is not encryption. It is a cryptographic “hash” of the message itself, combined with the secret key (the Device API Key). If ANY part of the message is altered, the hash will be invalid. The API Key is not sent back to the server with this message, and it cannot be “reconstructed” or otherwise extracted from the message. Only the Device ID of the hub, the contents of the message, and the HMAC signature are sent across the wire. Upon receipt of the message, the servers use the Device ID to look up the API Key of the sending device, and use that key to generate a HMAC signature of the message. If the signatures do not match, the message is rejected, and the rejection event is recorded in the server’s logs.

By this mechanism, “spoofing” of data sent to the servers is made exceptionally difficult – one MUST obtain the secret Device API Key in order to generate messages that the server will treat as genuine.

One side benefit of this anti-spoofing measure is the very strong data-integrity function that comes along for the ride. The HMAC signature is effectively a strong whole-message checksum algorithm: if the message is corrupted in any way (e.g. radio interference, electrical noise, broken hardware anywhere along the network chain), it will be rejected as though it had been maliciously tampered with.

Astute readers will note that the MD5 hash-generation algorithm has been discredited by the cryptography community as a “weak” hashing algorithm with known vulnerabilities. However in the context of an HMAC signature, these vulnerabilities are not present. Further discussion of this topic is beyond the scope of this article, but curious readers are encouraged to dig deeper here: https://en.wikipedia.org/wiki/HMAC and here: https://tools.ietf.org/html/rfc6151 – an IETF RFC which states “attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code”.

It is worth noting that the actual payload – the data contained in the message between the hub and the server, is not encrypted by this process. It is sent in the clear, and an attacker who gained access to the network between the hubs and the servers could view the data using common network spying tools. They would then know all the conditions recorded by the hub and sent to the server, though they could not alter that message in any way, nor generate a new one with malicious or mischievous content, without the “spoofed” message being rejected by the server.

If secrecy of the data-in-transit is also of paramount importance, network tunneling solutions (e.g. VPN over SSL) exist which could be designed into any system using Yoctopuce sensor hubs.

The Valarm Pro Android app uses the same HMAC-MD5 algorithm as described above, but also conducts all communications via SSL encrypted HTTP (HTTPS). Thus making the messages also impervious to spying.

The Yoctopuce sensor hubs do not offer sufficient compute power (nor energy budget) to perform SSL encryption on all communications, thus the necessity of a separate device to perform encryption, if this step is deemed necessary by the specific IIoT deployment.

In further articles we will discuss the security measures utilized in the Valarm Tools cloud/cluster.

Are you ready to learn more? Have a gander at the next article in this security series – How secure is your Industrial IoT sensor data in the cloud?