Device Security
Having a large fleet of devices in the field that are connected over the insecure internet comes with risks. Lobaro puts a lot of effort into making our devices secure and preventing them from being compromised. This is a complex topic that includes many different aspects. The devices themselves and the networks they are integrated into need to be set up correctly to achieve a secure setup.
This article describes concepts implemented in Lobaro devices to make them secure and gives an overview of what is needed to set up secure communication between your devices and your backend.
The information in this article describes the Gateway V4 Series of Lobaro Devices. Older devices may have some of the described features. For additional information on the details for other devices, please contact us.
Device Certificates
Each Lobaro Gateway V4 device has its own unique device certificate. The Private Key for this certificate is generated from a cryptographically secure random source on the device itself and stored only in the secure Key Management Unit, which is a feature of the Arm Cortex-M33. It is not accessible from the main application, and it never leaves the device. Lobaro does not know those keys and never has access to them during the complete production process nor during the lifetime of the device.
The subject of the device certificate has as common name (CN) the device's unique EUI-641 aka DevEUI, in urn format. The certificate is signed (indirectly) by the Lobaro Device CA. Any intermediate CAs are also included in the device.
During boot, before the main application starts, the device certificate chain (without the root CA) is printed to the log output. It looks like this:
-------------------------------------------------------------------------------
Device certificate chain:
1 CN=urn:dev:mac:70b3d5e050023d3a
1 SHA256=16:55:C7:DF:34:B3:C0:AD:39:32:9A:EF:39:04:43:FA:73:EF:2F:CC:DA:F2:49:7E:86:D4:3A:86:1C:C0:AF:74
1 SHA1=CE:3E:CB:96:14:10:6E:FE:1E:4B:76:DE:F6:A7:2A:1D:E0:5B:7F:F3
2 C=DE, ST=Hamburg, O=Lobaro GmbH, CN=eadrax CA
2 SHA256=58:C4:09:E1:28:85:F2:62:9D:C7:27:1E:BD:EF:AA:F9:DE:87:65:E8:30:D6:02:D9:5F:69:F1:DC:FE:8D:69:A5
2 SHA1=F9:B6:E3:04:6E:8B:D4:0C:A8:28:71:A0:A0:3B:71:FE:C4:02:C9:09
-------------------------------------------------------------------------------
In the example above, a certificate chain of 2 certificates is printed. For each certificate,
the subject and two fingerprints (SHA256 and SHA1) are listed. The certificate numbered 1 is
always the device certificate; it contains the unique EUI-64 of the device, in this case
70-B3-D5-E0-50-02-3D-3A. The certificate numbered 2 is one of Lobaro's intermediate CAs,
that was used to sign the device certificate. That certificate is signed by the
Lobaro Device CA.
On a TLS or DTLS handshake, all certificates in this list will be presented.
It is possible to extract the complete certificate from the device using the Lobaro Config Tool. You can also install your own certificate, signed by your own CA over the Config Tool, if you prefer.
Lobaro Device CA
The Lobaro Device CA is a self-signed certificate with this information:
Subject: CN = Lobaro Device CA, C = DE, ST = Hamburg, O = Lobaro GmbH
SHA256 Fingerprint = 1E:BF:5E:9A:B5:EB:47:23:B0:4E:1E:00:74:E5:19:FD:B0:29:3C:FA:06:7C:7B:78:BF:95:A0:D7:66:D3:CF:26
SHA1 Fingerprint = 70:5A:96:F6:2B:BF:CC:19:EF:57:87:C6:62:A4:C0:3B:84:35:2E:70
You can download the Lobaro Device CA here.
Backend Communication
Lobaro devices support multiple ways to communicate with backend servers. There is a proprietary CoAP protocol, that is used to communicate with the Lobaro IoT Platform. Alternatively MQTT is used for communication with third-party platforms. Both can be used with or without a TLS/DTLS security layer2.
Lobaro highly recommends using secure communication! You can define whether to use TLS/DTLS or not
when you specify the protocol in your host parameter. coaps and mqtts as protocols activate the
use of the secure layer (just like https does for HTTP in your browser). So the correct value for your
host configuration parameter would be coaps://platform.lobaro.com for your device to communicate
securely with the Lobaro IoT Platform.
Lobaro IoT Platform
The preferred way to connect your devices to the Lobaro IoT Platform is using the CoAP protocol and DTLS, so
setting the host to coaps://platform.lobaro.com is the norm. If you are using a dedicated instance of the
Lobaro IoT Platform, the host will be different, but the protocol should still be coaps.
It is possible to connect to the Platform using plain CoAP without DTLS. To do this, you must explicitly allow unencrypted, unauthenticated communication in the device's security settings. This is not recommended. If you enable this insecure communication, anyone who knows the device's EUI-64 will be able to impersonate it! With DTLS enforced, only connections from the device itself will be accepted to send data for this EUI-64, because the device is the only place that holds the private key.
The Platform stores the certificate of each device. You can check the certificate's fingerprint in the Security tab of the device in the Platform. Only secure connections using this exact certificate will be allowed to send uplinks (and receive downlinks) for this device. During manufacturing, the certificate generated on the device is uploaded to the Platform and assigned to that device.
The Platform does not do any validation of the certificate chain; only the device certificate (listed as
number 1 during boot). This allows the usage of custom CAs in your devices for connecting the Platform,
or even self-signed device certificates, without sacrificing security – as long as you verify that
the correct certificate is stored in the Platform for the device.
MQTT Communication
When you are not using the Lobaro IoT Platform as a backend, you are most likely using MQTT to connect your devices to your own backend3. Plain MQTT (without TLS) is supported, but not recommended, as it sends credentials unencrypted over the network and allows reading your communication and impersonating your devices.
When the device connects to an MQTT broker using TLS, it presents its certificate during the handshake.
The broker will most likely deny the connection, unless you add the Lobaro Device CA
to the list of trusted CAs in your broker. If you cannot add the certificate, but can set your broker to
allow connections without a certificate, it is possible to stop the device from sending its certificate,
by adding ?cert=0 to the host parameter. Again, this is not recommended.
Authentication using MQTT
It is possible to have certificate-based, password-free, per-device authentication on your MQTT broker. This happens when you connect to the Lobaro IoT Platform using MQTT with TLS. Similar to the handling of CoAP connections, the device is identified by its individual certificate during the handshake. Our broker only allows access to the topics that are explicitly used for this device (with its EUI-64 in the topic name). This allows easy and secure configuration of your devices without the need for any usernames or passwords. The strict separation isolates devices from each other and prevents access to your data by other customers using the same platform.
It is possible to replicate this behaviour in your own MQTT broker, but it will need work both when setting up the server and when managing your device fleet. There needs to be a database that stores the certificates per device and allows restricted access to each client depending on the certificate it presents.
There are simpler approaches with varying levels of security. A simple and solid solution would be to set
up a dedicated MQTT broker for your devices and your backend, that only trusts the Lobaro Device CA and
the certificate used by your backend. This way you can use an out-of-the-box MQTT broker with minimal
adjustment on the TLS configuration. You would need no adjustment on the devices, besides setting the host
parameter to your server, using something like mqtts://your.server.example.com4. You will
have a secure setup, where your backend can trust incoming messages and know from the topic alone, which
device sent the message – with certainty. With this setup, devices are theoretically able to see each other's
messages and impersonate each other, but Lobaro devices do not do that.
Alternatively it is possible to authenticate devices using username and password. You can add them to
the host parameter as you would in an HTTP URL: mqtts://<username>:<password>@your.server.example.com5.
If you are using a password based authentication approach, you must make sure to use strong, long enough passwords
from a secure random source. You should use individual users and passwords for your devices, so that no two
devices share their credentials. Credentials are stored encrypted on the devices and are not accessible if
the device is locked with a device passphrase. They are, however, uploaded to your backend on the first
connection, when the current configuration is uploaded. If access to MQTT-topics is not limited on your
broker, credentials of a single device can be used to sniff the credentials of all other devices. If you are
using MQTT without TLS, credentials are sent in plain text over the internet and can easily be sniffed by
an adversary.
Using password based authentication causes a lot of overhead and comes with some security pitfalls. We recommend using a certificate based authentication approach.
Securing MQTT topics
Lobaro's Gateway V4 Series devices use multiple MQTT topics for different purposes. They all include the
device's EUI-64 (the main address) in the name.
The device with the EUI-64 70b3d5e050023d3a will subscribe to LOB/70b3d5e050023d3a/down/#
and publish to LOB/70b3d5e050023d3a/up/+, and LOB/70b3d5e050023d3a/req/+ (the prefix LOB/ can be
adjusted if needed).
For a secure setup you must configure your broker in a way, that grants each device only publishing access
to its own up and req topics, and only to subscribing to its own down topics. Access to all other topics,
including topics with different EUI-64 should be denied. Your backend should be the only client with read
access on the up and req topics, and write access on the down topics. This isolation limits damage that
is caused, when the credentials of a single device are compromised.
Configuration Storage
Lobaro devices have a lot of configuration parameters. Some of these contain sensitive information, including LoRaWAN keys, APN credentials, SIM Pins, MQTT credentials, and more. All this information must be stored on the device and be accessible for the device to use it. At the same time, this information must be protected from unauthorized access. The configuration is stored in a dedicated part of the device's flash memory.
Starting with Version 0.10.0 of the origin firmware (which is the basis for the Gateway V4 Series), the
configuration is encrypted and authenticated using AES-GCM. The key used for this encryption is
stored in the secure Key Management Unit (KMU) of the Arm Cortex-M33. It is inaccessible by the firmware
and cannot be extracted, even by Lobaro. The configuration values are not printed in the log output during normal
operation (they are, however, uploaded to the backend, when using CoAP or MQTT communication; when using
TLS/DTLS and with a correctly set up backend, this is not an issue, as you know those values and need them
for device management).
Local access to the configuration (reading and writing values) is done over the Lobaro Config Tool. For your config values to be protected, you need to set a device password that limits access to it.
Lobaro Config Tool
The Lobaro Config Tool is a program (available for Windows, Linux, macOS, and Raspberry Pi), that allows diagnostic access and configuration of the device over a physical connection via the Lobaro USB Config Adapter. With the Config Tool you can:
- Examine the log output during operation, to diagnose problems and misconfigurations.
- Read and write the device's configuration.
- Install firmware updates on the device (only firmware signed by Lobaro will be executed by the device).
- Examine the complete device certificate chain (without the root CA), and the trusted CA.
- Install a custom certificate (self-signed or via CSR) and trusted CA.
- Change the device's passphrase.
Access to the configuration and certificate management is protected by a unique passphrase per device. Lobaro will provide you with the passphrase on purchase. You can change the passphrase, if you want. If you do, you must use a strong passphrase from a good random source. You must use an individual passphrase for each device. Your device fleet will not be secure, if you ignore this.
Make sure to keep the passphrase safe and do not lose it! There is no recovery process and no master password.
Device Protection
Arm Cortex-M33
The core component of the Lobaro Gateway V4 Series devices is the nRF9151 by Nordic Semiconductor. It is based on the Arm Cortex-M33 architecture, which provides a bundle of features meant to protect the finished product from unauthorised access and provide the tools needed for secure operations. Features include:
- The Arm TrustZone – a hardware-based security technology, that isolates critical code and hardware components from the main application. If there are any vulnerabilities in the main application, they cannot be used to access those critical components, which include session keys used for secure communication and access to other sensitive information.
- The Key Management Unit (KMU) – a secure storage for cryptographic keys, that can only be used from the secure world of the Arm TrustZone. Keys can be stored so that they cannot be extracted by the software, but still be used for cryptographic operations.
- The Arm CryptoCell 310 – a hardware-based cryptographic processor that executes cryptographic operations in a secure environment, providing resistance against side-channel attacks. It acts as a source for cryptographically secure random numbers.
- Access protection for the flash and memory, that can protect areas or the complete chip from being read from or written to. It can protect the flash from being altered by the firmware itself, so that the most critical parts of the firmware cannot be altered.
Device Identity
The device has multiple unique keys that are generated in the CryptoCell during manufacturing and stored only inside the secure KMU and cannot be extracted. Lobaro does not have access to these keys, and neither do you, as the device's owner. This includes the secret asymmetric key used for the device certificate. If an adversary succeeds in resetting the Arm Cortex to its factory state, these keys will be destroyed in the process.
As long as the device is using its original certificate for communication, you can be confident, that the device is not compromised.
Signed Firmware
The first stage bootloader of the device uses MCUboot. That is a well established secure bootloader that we use to verify the integrity and authenticity of the installed firmware, before it is executed.
Our firmware images are signed with a private key. Only if the firmware is intact and the signature is valid is it executed. If only a single bit has been altered, MCUboot will detect the manipulation and refuse to start the firmware. So if an adversary succeeds in installing a manipulated firmware, either through remote firmware update or by physical access, the device will not execute it.