It is important for our machines to be connected. From industrial asset trackers for inexpensive off-road vehicles to satellite telemetry solutions for business jets, original equipment manufacturers (OEMs) are counting on embedded connectivity solutions to deliver high business value for them and their operators. To deliver this value, connectivity devices are networked to critical onboard engine, hydraulic, display, and navigation equipment to provide the rich data needed to exploit the business value of the connected tractor, loader, or aircraft.
With all of these interconnections and access to critical machine or aircraft systems, there is an obvious need to ensure the connections are secure. Security is a confusing and acronym-laden space that can leave buyers uncomfortable or uncertain. To combat this, we’ll focus in on the top two areas that you should have a strategy for:
1. The hardware and software on the device itself
2. Transportation of data from device to cloud
First, it’s important to understand the concept of a “key” when discussing security concepts for telematic devices. In a simple sense, information is scrambled using an algorithm, and the key unlocks that information. If you’ve ever used paper cutouts over a page of text or a pinwheel decoder to extract a secret message, you’ve experienced an encryption, or cipher, and a key. There are many different manifestations of encryption and key structure, but the concept of an algorithmic encryption and key to enter/exit that encryption are consistent across these concepts.
In a simple sense you can divide security concerns within a telematic device into hardware and software. You need to be confident that the software on the device is genuine, has not been corrupted by some bad actor, and is not attempting to do anything nefarious. You also need to be sure that the hardware is secure, so the electronics are protecting the data on the device (including the secret decoder keys that unlock the encryption the device uses to communicate).
Hardware Security Onboard a Device
There are some spectacular tools available to device manufactures to secure applications and storage onboard telematic controllers. For example, Arm TrustZone allows the device manufacturer to secure certain ranges of memory and flash from snooping and sniffing. This security extends to the application software onboard the device, so even applications running on the device cannot read that data off the flash and send it to the cloud.
Why is this important?
One example of a security vulnerability is to send a false application update to a device, whose purpose is to serve as the first component of a multi-stage attack to steal the encryption keys from the device. During the attack, the application is falsely deployed to the device and retrieves the keys. Even though it fails to update, the device uses its telematic capability to offboard the keys and enable a subsequent, more dangerous attack. With hardware security enabled, you would not be able to read the protected memory locations, the false application update would be rejected, and the device would continue on its way.
A different approach to hardware security is through the utilization of trusted platform modules (TPM). Keys are stored entirely within a secure, integrated circuit that is separate from the core product’s processor/memory, and the keys never leave the module. TPMs can also play a role in secure boot as a special sequence initialized only by the correct software, in the correct order, to unlock the TPM.
What level of hardware security is appropriate for your application will vary based on your deployment’s risk profile, the capabilities of your device, and the technologies supported by your server-side infrastructure. It’s important that consideration is made for securing your device at the hardware level, and that you and your device manufacturing partner are united in your approach to telematic hardware security.
Software Security Onboard a Device
With good hardware security and key storage in place, updating the application onboard the device can be secured, regardless of whether it is through firmware updated over the air, or by physically connecting. This security is achieved by having the application signed with a private key, ensuring that the software is trusted before allowing it to be run, and no bad actor can replace or modify the software onboard your device.
In data transmission, there is the protocol being used to transmit data and the method of security that is applied to that protocol. Typically the security and protocol are separate considerations. Whether you are using a popular telematic protocol like MQTT or a UDP IP based protocol like CoAP, there are methods by which that data can be encrypted in its transfer from the device to the Internet, where it then transits to the server. In this sense, most typical security concerns are focused on the data’s pathway through the Internet on its way to its server location more so than the radiation of the data in free space from the device’s antenna.
In the world of data encryption there are two high-level concepts that are important to understand: symmetric encryption and asymmetric communication of data.
Symmetric encryption is when you open a “secure channel” for two-way communication. The red telephone for the President of the United States is a very good analogy for symmetric encryption. For applications where the receiver and sender are in the same organization, or the device and end-point receiving the data are designed by the same company, this system is commonly and effectively employed. This technology is commonly used in applications like banking transactions and data at rest (not in transit from one server to another).
In this method of security, there is a public key that can be used to encrypt data to be sent to a receiver, but a secret key that is possessed by the receiver is the only way to decrypt the data. Where different organizations are communicating with one another, or when several organizations might be contributing data to a common dataset, this methodology is very effective. Asymmetric encryption is commonly used in applications like digital signatures, and is a feature of transport layer security (TLS) or secure socket layer (SSL) communications.
One of the shortcomings of asymmetric encryption is that it is much slower to implement and use on devices because the encryption algorithms are complex and require more computational power to run. This is unfortunate for embedded devices where processing capabilities are often a significant limitation. Although symmetric encryption doesn’t require as much computational power, it requires that secret keys be effectively distributed and maintained, which is a separate challenge.
With consideration for the challenges above, it is common in messaging and telematic applications to employ a hybrid model. With this model, an asymmetric message is used to open a secure channel and exchange keys to begin the session between the client and the host, so that session can be done with safe, secure, lower-overhead symmetric encryption. For example, the client can use a public key to send a message to a host describing all of the information the host needs to connect back to the client using symmetric encryption (a shared secret key).
No One-Size-Fits-All Approach
A good security strategy is a collaborative effort between the device manufacturer and the OEM. For example, in a simple asset tracking use case with an asset tracker that needs to optimize battery life for a longer duration, the asymmetric public key transfer could use 6k of data in the process of sending a one-time 500-byte message. Throughout the lifespan of the device, more than 90% of the precious battery life would be consumed securing the device’s messages. In such cases, like inexpensive IoT sensors feeding asset tracking or environmental intelligence to machinery management systems, the costs in battery life and data transmission may necessitate other approaches to security.
In a future blog article we’ll cover how a device manufacturer, in collaboration with the cellular or satellite carrier, can be creative in the manner that data is received off the device at the network infrastructure to keep that data off the internet. Approaches like this can be of considerable assistance when combatting power/data budgets for use cases like the above IoT sensor.
When considering your connected vehicle deployment, ensure you and your device manufacturer have hardware level key security, signed certificates for software deployment, and a right-sized strategy for encryption of communication to/from the device.
David Batcheller – President & CBO