How to use "fuzzy" technology to ensure the safety of automotive systems

    In 2010, American automakers introduced a novel feature that allows car owners to control the locks and start the engine from anywhere in the world via a smartphone. This connectivity relies on the car's telematics system, which is now standard on many models. Before the launch of this smartphone, a university research team published a research report that pointed out that by exploiting flaws in the car's embedded system, the car's key systems (such as brakes, engine throttle, etc.) can be easily manipulated by malicious people.

　　The researchers studied how to use 'fuzzing' techniques to break into critical systems from low-security networks. Brake failure and engine loss of control while the car was in motion showed that the attack could indeed put passengers in danger. Connecting the car to a wide area network is the culprit for introducing sophisticated attackers. A single flaw could allow a remote attacker to threaten a long line of vehicles driving side by side.

　　The researchers don’t tell us what we can do to improve embedded car security today. But as we’ll discuss later, we must make substantial changes to automotive technology to better isolate network subsystems from life-critical safety functions.

　　Current automotive electronics

　　The diagram below shows some of the electronic systems inside a modern car.

　　

　　Figure 1: Some of the electronic systems inside a modern car.

　　A high-end luxury car contains up to 200 microprocessors in a system totaling 100 components or electronic control units (ECUs). These ECUs are connected by different types of networks, such as controller area network (CAN), FlexRay, local interconnect network (LIN), and media-oriented system transport (MOST). Automotive OEMs need to integrate ECU components and software from dozens of Tier 1 and Tier 2 suppliers. But OEMs do not have tight control over the development process of their suppliers.

　　It is no surprise that this situation cannot be sustained. OEMs will suffer the consequences of the 'barrel theory': just one ECU with serious reliability problems could cause delivery delays or vehicle failures, thus damaging their reputation.

　　Security Threats and Mitigation Measures

　　Security threats to vehicles can be divided into three categories: local physical; remote; internal electronic. When these threats are combined, they often cause vehicle damage.

　　Local physical threat

　　An example of a localized physical threat is physically accessing the powertrain CAN network and disrupting communications. This type of invasive attack can easily disrupt critical car functions. However, a localized attacker, such as a disgruntled mechanic, can only compromise one car, so it is not enough to attract the attention of the design security team. In addition, the complex electronic systems of the car are difficult to truly protect against physical attacks. Therefore, we usually just hope for this type of threat.

　　However, there is an exception: somewhere inside one or more ECUs there is a private key stored to create a protected channel and provide local data protection services. The following figure shows some examples of long-range wireless connections used in next-generation cars.

　　

　　Figure 2: Long-range wireless connectivity used in next-generation cars.

　　Automotive algorithms, multimedia content, and confidential data may all require data protection. Private key storage must be resistant to aggressive invasive and non-invasive physical attacks, as the loss of even a single key could allow an attacker to establish a connection to a remote infrastructure device, where they could cause widespread damage.

　　OEMs must be able to ensure the security of keys throughout their lifecycle, from key generation and embedding into the ECU, to the ECU being delivered and installed in the car, to the car finally hitting the street. Specialized embedded encryption companies such as Green Hills Software, Mocana, and Certicom can help OEMs and their suppliers with guidance and oversight in this area.

　　Remote threats

　　Here is a typical attack method: Hackers find weaknesses in network security protocols, network services and applications by probing the long-distance wireless interface of the car to find ways to enter the internal electronic systems. Unlike data centers, cars generally cannot have complete IDS, IPS, firewalls and UTM. Recent intrusions into Sony, Citigroup, Amazon, Google and RSA have fully demonstrated that these defense mechanisms are useless in the face of sophisticated attackers.

　　In 2010, when Stuxnet (the super factory virus) was rampant, General Keith Alexander, commander of the U.S. Cyber ​​Command (CYBERCOM) under the U.S. Department of Defense, suggested building an isolated secure network for important U.S. infrastructure equipment, separate from the Internet. Although this approach seems too harsh, it is actually the idea we need. For driving safety, the critical systems of the car must be completely isolated from non-critical ECUs and networks.

　　Insider Electronic Threats

　　While physical network isolation is ideal, touchpoints are unavoidable. For example, in some markets, car navigation systems must be turned off while the car is in motion, which means communication and sensing between systems with very different safety standards. In addition, there is a strong trend in the industry to integrate designs—using more powerful multi-core microprocessors to implement different systems, thus turning many ECUs into virtual ECUs—which will increase the risk of software-based threats, such as privilege escalation caused by operating system flaws, side-channel attacks on cryptographic systems, and denial of service.

　　Therefore, for safety, the internal electronic architecture of the car must be redesigned. The interfaces between critical and non-critical systems and networks must be demonstrated and exhaustively analyzed at the highest management level and verified to the highest security standards such as ISO 15408 Evaluation Assurance Level (EAL) 6+ to confirm that there are no defects. The Principles for High Assurance Software/Safety Engineering Implementation (PHASE) protocol supports a significant simplification of complexity, software component architecture, the principle of least privilege, secure software and system development processes. OEMs must learn and adopt independent expert security verification and implement it throughout their supply chain.

　　Conclusion

　　Automakers and Tier 1 suppliers may not have considered safety requirements when designing cars on the road today, but it is clear that things are changing. Manufacturers should work closely with embedded security experts early in the design and architecture of in-vehicle electronics and networks, and must improve safety-oriented engineering and software security. Finally, the automotive industry urgently needs an independent standards organization to define and implement system-level safety certification programs for in-vehicle electronics.