We have implemented comprehensive security protocols on our devices and software to protect against attacks on the integrity and confidentiality of your telematics data.
Authentication means verifying that the device is authentic, the server is legitimate, and verifying the data has not been tampered with. This protects against ‘spoofing’ attacks, or when malicious parties attempt to impersonate devices to steal data, spread malware, or bypass access controls.
Confidentially involves ensuring data is transmitted securely. Data is encrypted prior to transit, such that even if it were to be intercepted by a 3rd party, it cannot be deciphered.
Our devices operate in AES256CCM – CCM Mode using AES for block encryption with a 256-bit key.
The Advanced Encryption Standard (AES) was established by the US National Institute of Standards and Technology in 2001 and adopted by the US Government. Today its adoption is widespread and this, along with the scheme, provides several benefits:
Put simply, AES works by jumbling up the device data (a lot!) using a key. It can only then be ‘unjumbled’ by using the key at the other end. Unjumbling without knowledge of the key is so impractical (it would take so long as above) that it is regarded as impossible.
AES-256 is regarded as ‘military’ spec encryption, as it is used by the US military. If it is good enough for them, we think that it must be pretty impenetrable. A key is stored on the device, and securely on the OEM Server. Each key is randomly different for every device, so if a device was to be compromised somehow then the key cannot be used to decrypt data from other devices. A rolling code forms part of the cipher, meaning it changes on each connection – making the system even more secure.
AES256CCM also fulfills the requirement for authentication. As part of the process, a Message Authentication Code (MAC) is generated and appended to the message. Then the entire message is encrypted. The MAC provides the benefit that it can be used on the server-side to identify whether the message is authentic and if any data in the message has been altered either intentionally or via errors in transmission.
On top of this, the microcontrollers we use in our products are programmed entirely by us – including the bootloader and main firmware. This means we are not relying on any other code that could be malicious or vulnerable to known exploits.
The security discussed above covers the critical step of the transmission of data from the device to the OEM Server, our device management layer. In order to transmit data to a 3rd party server, we can send this data over HTTPS, providing a full end to end data security.
LoRaWAN® networks use AES-128 Encryption. Each LoRaWAN® device is personalized with a unique 128 bit AES key (called AppKey) and a globally unique identifier (EUI-64-based DevEUI), both of which are used during the device authentication process. Allocation of EUI-64 identifiers requires the assignor to have an Organizationally Unique Identifier (OUI) from the IEEE Registration Authority. Similarly, LoRaWAN® networks are identified by a 24-bit globally unique identifier assigned by the LoRa Alliance®.
LoRaWAN® application payloads are always encrypted end-to-end between the end-device and the application server. Integrity protection is provided in a hop-by-hop nature: one hop over the air through the integrity protection provided by LoRaWAN® protocol and the other hop between the network and application server by using secure transport solutions such as HTTPS and VPNs.