Telematics devices can often collect and report a variety of potentially critical or sensitive data. We have implemented comprehensive security protocols on our devices
to protect against attacks on the integrity and confidentiality of telematics data.
The two main benefits provided by the security scheme are:
Verifying that the device is authentic and that the server is a legitimate server, and in addition verifying the data hasn’t been tampered with. This protects against ‘spoofing’ attacks where someone can simply send data in the right format, pretending to be a device in order to send false data.
Ensuring that information is transmitted securely. Data is encrypted prior to transit such that even if it were to be intercepted by a 3rd party, it is unable to 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.
- The widespread adoption means that it 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. Click image to enlarge
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 fulfils 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.
Other links in the chain
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 full end to end data security.
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. Get in touch
to learn more about the security protocols implemented to protect your telematics data.