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
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.
Confidentiality
Confidentiality 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.
Authentication and Encryption
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:
Widespread adoption means the standard has been thoroughly field-tested, and it has proven itself as secure.
The algorithm does not require huge amounts of computational power and is quick to implement, so performance does not suffer. We use a 256-bit encryption key as part of the scheme.
The number of operations required to brute force such a cipher is 3.31 x 10^56 – which is roughly equal to the number of atoms in the universe. So, with current computing power, AES-256 can’t be cracked.
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.
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.
Third-Party Integration
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®
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.
For more information on LoRaWAN® Security please visit lora-alliance.org.
