Tag Archives for " telematic control unit "
Top two security issues for connected machines
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, these 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 that such 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
Understanding Keys
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 a sort of 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 resident 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 ability to secure these ranges from the application software onboard the device itself, so even the application running on the device cannot read that data off the flash and send said data to the cloud.
Why is this important?
One example of a security vulnerability is to send a false application update to a device, whose express purpose is not to successfully corrupt/replace the application software, but instead is the first component of a multi-stage attack in which the initial attack’s objective is to steal the encryption keys from the device. In such a situation, the application is falsely deployed to the device and retrieves the keys. Even though it fails to update, the device uses the telematic capability of the device to offboard the keys and enable a subsequent, more dangerous attack. With such 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). In this case the keys are stored entirely within a different, secure, integrated circuit that is separate from the core product’s processor/memory, and the keys never leave the TPM. Trusted platform modules 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. What is important is that some 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, the updating of the application onboard the device itself can be secured, regardless of whether that update is through firmware updated over the air, or by connecting physically to a device. This security ensures that no bad actor can replace or modify the software onboard your device. This security is achieved by having the application signed with a secret/private key. The signing of this application ensures that the device can verify that the software is genuine, or trusted, before allowing the software to be run on the device.
When transmitting data, 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. So 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
Symmetric encryption is when you open a “secure channel.” If you think about the President of the United States and the red phone for secure calls, that is a very good analogy for symmetric encryption. This is a secure two-way channel for communication. 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).
Asymmetric Encryption
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, such a security methodology is very effectively used. 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.
Hybrid Approach
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 subsequently 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 a battery powered 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. That means that throughout the life of the device, more than 90% of the precious battery life the device is trying to optimize for 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 message 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 and further contribute to a security solution. Approaches like this can be of considerable assistance when combatting power/data budgets for use cases like the above IoT sensor.
Summary
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
https://www.appareo.com/2020/12/07/top-two-security-issues-for-connected-machines/
Choosing the Bluetooth That’s Right For You
Since the introduction of Bluetooth Low Energy (BLE) in Bluetooth 4.0, there are now four technologies used under Bluetooth 4.0 and later revisions. Although the history of naming these technologies has led to much confusion, the generally accepted names are Bluetooth Classic and Bluetooth Low Energy. Bluetooth Classic represents the BR, EDR, and HS (AMP) technologies, while Bluetooth LE represents the LE technology.
Bluetooth Classic devices are typically used in applications requiring streaming of data, such as audio. The physical layer and protocol of BR/EDR make socket-like streaming of data easy to accomplish. Rates of these data streams may be around 2-3 Mbps.
Bluetooth Low Energy brings about some great features beyond low energy operation, such as one-to-many and many-to-many communications, as well as connectionless services. BLE is often used for data transmission, location services, and device network applications. These interactions operate much more like a shared database of characteristics through the use of a Generic Attribute Profile (GATT). Most mobile devices such as phones, tablets, and computers support both Bluetooth Classic and Low Energy; however, many devices use one or the other.
Due to the differences in the physical layer modulation and demodulation, BLE cannot talk with Bluetooth Classic and vice versa. Similarly a BLE device cannot use Bluetooth Classic network and transport protocols when talking to a dual mode Bluetooth device. This is critically important for machinery manufacturers because although Bluetooth devices can typically communicate over a local area network to tablets and phones reliably, if you are going to use Bluetooth to communicate between machines and attachments, or between machine ECUs, you’ll need to select a protocol for the network of devices you’re managing.
- BLE can manage the data rates necessary to transfer typica data loads from mobile equipment busses (e.g. CAN buses running J1939)
- Bluetooth Classic can handle a lot more data
- Bluetooth Classic supports mobile devices tethering to telematic gateways or control units onboard machines and letting one device use the other’s data plan
- Bluetooth Classic is much more energy intensive than BLE, so if you have a battery-powered application BLE is the way to go
In summary, if you have a network demand for a fairly large amount of data, and you have access to vehicle power (or battery life management is not a concern), Bluetooth Classic is a good way to go. If you’re a battery-powered application or do not require transfer of significant volumes of data, BLE provides attractive networking flexibility, low power, and a low price.
Michael Hoffman – Sales Manager, Land Mobile
https://www.appareo.com/2020/11/02/choosing-the-bluetooth-thats-right-for-you/