IOT: Controlling Device Access, security through obscurity no longer an option

Article
08/21/2015

References:

Motivation for this blog

One of the major vehicle manufacturers, using a well defined communication system inside of their vehicle, was successfully attacked by good hackers who reported the hack. This hack was implemented using a cell phone network and the good hackers were not in the vehicle, the good hackers phoned it in.

In a Wired Video, an SUV brakes were made uncontrollable by the driver by hackers through the driver’s cellphone. This scenario could only occur at speeds less than about 22 KPH, but a vehicle or person could be damaged at that speed. This blog is not questioning the quality of the engineering at the manufacturing corporation, this is an IOT problem overall. This blog looks at the specifics of hardening vehicle controller network. The SUV uses a network titled: Controller Area Network or CAN, and has been mandated since 2008 for all US Vehicles. These systems use the OBD II specification for diagnostic trouble codes (DTC). Many of the definitions and assumptions can also be used for non-vehicle IOT system modeling. Since most of the readers of this blog either own a car or will own a car eventually we all want our cars to be secure against exploits. Defining how to harden vehicles against being exploited may help improve the ease of securing or hardening IOT used for scientific, hobby, academic and engineering against exploits.

Required for developing any system with code is to make sure the whole team, not just the software team has security and privacy training. This is an expense, but system exploitation can impact the larger system security, safety and privacy information. A system exploit can be much more expensive than the training.

Background

So in reading the mass media reports like the ones from CNN and Wired magazine, we see that two guys with one vehicle were able to work out a security exploit of the vehicle using a cellphone. The Wired Magazine showed that one vehicle model could be exploited, and likely it isn’t the only exploitable vehicle. Everyone who does IOT realizes that security is an issue, but what to do? Well it looks like the two security specialists, Charlie Miller and Chris Valasek, did something and I hope that this is a positive situation for the IOT environment. Let’s take a look at the generalized vehicle diagram as I see it:

The network in your car might look like the following, bear in mind that if you don’t have an option, the network may still have the software for that option:

What is CAN and how was it utilized for the exploit?

The Wired Magazine Video exploit utilized the automobiles CAN or Controller Area Network. The use of CAN has removed a great deal of weight from vehicles, but since the CAN is digital, it is open to hacking attacks. When CAN is used, you can see that the number of copper wire drops quite a bit, less copper wire, less weight! It is an expensive technology, and nodes may use a less expensive system similar to “one wire” called “Local Interconnect Network” or LIN, this network is not discussed in this blog.

CAN has been added to vehicles to increase reliability, cut costs, decrease vehicle weight and to ease engineering costs. For my 2005 mini-van, the CAN system saved 11 kilograms in weight, a significant savings. The CAN also allows the manufacturer to improve systems over the life of the car with little costs. On the other hand the possibility of system exploits become possible for the first time.

CAN has a number of specifications, as is normal for most technologies: SAE J1939 or ISO 15765 or Borsch CAN specifications. The United States has required the use of the CAN in all cars sold in the US since 2008. In addition to the CAN, which uses a two-wire system similar to RS-422, a less expensive network called Local Interconnect Network is also used inside of the various Nodes. The LIN is a one-wire system similar to the I2C network used with IOT, and it is the subject of another blog. LIN is less expensive to implement than the CAN, but must be used within a Node.

Let’s take a look at the vehicle hack

Now that the damage has been done to the 400,000 or so vehicles shipped and the internal “tiger” team has the recall under control. What should we do for the future work? Let’s break down the different components, and see how our future requirements might include a stronger discussion about security:

Cell Network to Cell Phone
- Current: Bluetooth, type in Bluetooth security code
- Question: Could an App maliciously call “home” and implement the hack or provide personal information like location, etc.
Smartphone
- User must have cellphone connected to the Infotainment System
- Question: Could a malicious app might be designed to seize control. Is that possible? If it isn’t, prove it.
Link A
- Bluetooth security
- Question: Could another phone in the car get on the Bluetooth Infotainment system?
Infotainment System in Vehicle
- Infotainment system can only be connected to phone via a Bluetooth connection?
- Question: Could the infotainment hold critical data that could be used in the CAN network?
- Question: Could the infotainment hold personal data?
Link B
- Wire/physical security?
- Question: Could the wired link be compromised via strong radio signals?
- Question: Could the engine be immobilized via strong signals or electrical surges (exception Carrington Event EMP levels)
CAN, controller area network
- ~~Are each Node (sensor, device) be compromised during the lifetime of the node?~~
- List the possible or known exploits for nodes on the Controller Area Network.
- List:
  - Masquerade attack
  - Fabrication attack
  - Modiﬁcation attack
  - Replay attack
- Question: Are there a “good practices” that will prevent each of the possible exploits with the current level of technology?
Vehicle CPU
- CAN interface
- Question: Is it possible that the Vehicle Engine Controller Unit CPU could be reprogrammed via the infotainment system?
- Question: Is it possible that the braking system be reprogrammed via the infotainment system?

For future design using SDL defined processes, each of these points need to have someone who owns the items. Having a “gate question” for each of the points that will allow the release of the software. The “gate” is a way to demonstrate to the other stakeholders that the system is secure. Using modeling tools will assist the non-software stakeholders to have visual or actual proof. For automobiles modeling will also assist in lawsuits.

Security-Aware Design Methodology

In the article: Security Mechanisms and Security-Aware Mapping for Real-Time Distributed, the figure below shows the security-aware mappings. Note that abstractions should be part of the security mechanisms. Also, a security-aware design problem may not designate a specific architecture. The goal is to select the appropriate security mechanisms. For the IOT Designer, this process has not been well defined, for example what would the appropriate requirement gates to sign off the security components by non-software designers on the design team?

The security-aware mapping problem for architecture selection, in this case the software architecture for the security-aware problems would use the same set of variables and parameters so that the architecture and security-aware mapping are a single problem. [Lin, 2015, page 7]

Is it possible to secure the CAN?

Yes, but a well defined design methodology is required. For most vehicle systems, computer models will need to be created that have high fidelity, so that design, hardware or other considerations can be tested before implementing the modifications. To create high fidelity models or simulations, design methodologies must be created. Methodologies definitions are needed, for these I have generated the list from Security Mechanisms and Security-Aware Mapping for Real-Time Distributed, which is a well-written thesis (nice job Dr. Lin!), see below.

System and Attacker Model Definitions [Lin, 2015, page 13]

How to model the attacker and system? First there needs to be definitions, which are in Security Mechanisms and Security-Aware Mapping for Real-Time Distributed , and duplicated here is full:

Assumption 1: Network assumption
- The network architecture has only one CAN bus, and all ECUs are connected to the bus.
Assumption 2: Memory
- - A node can use volatile (RAM) and/or non-volatile (FLASH) memory to store data. Data stored in RAM is no longer available after a node reset; data in FLASH is available after a node reset.
Deﬁnition 1: What is a Node?
- A node is an ECU. An ECU is a device or sensor,
- Nodes can send or receive in different bus transactions
Deﬁnition 2: Sender
- The sender of a message is the node sending the message.
Deﬁnition 3: Receiver
- A receiver of a message is a node receiving the message and accepting it by comparing the message ID to the list of its acceptable message ID’s.
  A sender sends a message by broadcasting it on the CAN bus. Since the CAN protocol is a broadcast protocol, every node “receives” the message, but only receivers (as we have deﬁned them) accept the message.
Deﬁnition 4: Strong Attacker
- A strong attacker is an existing node where malicious software is able to gain control with full access to any critical data.
Deﬁnition 5 : Weak Attacker
- A weak attacker is a node where malicious software is able to gain control but no critical data is available (mainly because it was never stored in memory).
Deﬁnition 6: Legitimate Node:
- A legitimate node is a node which is neither a strong attacker nor a weak attacker.
Definition 7: Masquerade
- A masquerade attack is the scenario that an attacker sends a message in which it claims to be a node other than itself.
- Note that a masquerade attack can lead to a fabrication attack, a modiﬁcation attack, or as a special case, a replay attack.
Definition 8: Replay Attack
- A replay attack is the scenario that an attacker sends a message that it has received without any modiﬁcation.
Deﬁnition 9: False Acceptance
- A false acceptance is the scenario that a node accepts messages which it should reject.
Deﬁnition 10: False Rejection
- A false rejection is the scenario that a node rejects messages which it should accept.
Definition 11: Sending Counter
- A sending counter for a message is the counter stored in its sender.
Definition 12: Receiving counter
- A receiving counter for a message is the counter stored in one of its receiver.

Basic Exploitation Prevention Mechanisms

To implement exploitation prevention, one of the ways to do so is to would be to have every node maintain it’s ID Table, pair-wise keys and counters [Lin, 2015] .

So to prevent a device masquerade attacks the send and receive flowchart might look like the figure below.

With this flow diagram, the software designers would then have the ability to show that they have a solution in hand to prevent a device masquerade exploit using the CAN design wisely.

During the requirements sequence in the SDL process, more question might be asked:

Why does the infotainment system have the ability to communicate with the instrument panel? Doesn’t the infotainment have it’s own display?
- The answer could be: It is uses the instrument panel to show the current radio or mode of the infotainment system. The focus groups found that drivers like a multiple areas for information displays. As a result the vehicle instrument panel can be driver selected to display certain infotainment center.
- That answer might lead to an investigation into improving the software in the instrument panel to limit the infotainment to a minimum amount of information and screen. Or a number of other possible solutions.
Other stakeholders might have the further question: How do you prevent the infotainment system from modifying the vehicle speed indicator?
- The software designers would then have to demonstrate that the infotainment system could not masquerade as the Engine Control ~~Unit~~ Module ~~Note~~ Node (ECM)
- Of course, the hacker might have asked the same question, but with an extension: Can the infotainment also send velocity data and change the speedometer?
  - In the case of the Wired Video, it appears that the answer is yes.

This would not be a true security mechanism, but it would solve two exploits that would be impactful in a vehicle:

Masquerading, and the replay exploit with an addition of a message count, would also be prevented. These are two exploits could impact IOT devices that could become a problem for industries, vehicles and even that toy you are working on for the mid-Winter holidays.

Conclusion

In this article we have began determination of a structured methodology based on the Controller Area Network (CAN) used mostly in wheeled vehicles. Using the definitions we will be able to construct a modeling technique that could be used in setting up security gates for the IOT Requirements. Bear in mind that IOT encompasses devices (Nodes) that connect to a network or wire. Developing models that can simulate the CAN network in a vehicle will be important as vehicles get smarter, and with vehicle to vehicle communications. Bench top simulations using existing components may catch many of the errors, and act to verify the virtual modeling using software. With all of the possible combinations available, software simulations will extend the ability to catch exploitable sensor design, however, the simulations must be checked against real products. Bench-top simulations using the actual components combined with software modeling will allow the engineers and stakeholders to understand better how the vehicle networks can be hardened against exploits

Reviewing a recent exploit discussed in the media, using ideas from a doctoral thesis, and the 20/20 vision of hindsight, we can see that without adding encryption the CAN system can quickly be improved. Also, with respect to IOT, as we design our multiple CPU systems some of these ideas can be implemented with very little overhead by the hobbyist, student and researchers. These ideas should not be viewed as encryption, but rather a hardening of the system.

As to creating secure systems in IOT, the large vehicle marketplace will drive the need for all IOT developers to improve their software to prevent exploits and to secure their sensors against external intrusion.