Karamba Says It Can Protect CAN

　　Automotive cyberattacks, once the stuff of science fiction, are a clear and present danger today for most car OEMs and tier ones.

　　A host of startups and tech companies are already proposing multiple layers of security for connected vehicles. But coming into sharp focus now is how to protect a 30-year-old CAN bus.

　　Israel-based Karamba Security unveiled this week a new security software called SafeCAN, designed for protection and authentication of in-vehicle CAN bus network communication.

　　Thus far, Trillium, a startup in Japan, has been the sole voice promoting CAN bus protection, with a product called SecureCAN. Trillium offers a CAN bus encryption and key management system for protecting payloads less than 8 bytes.

　　Maxed-out CAN bus

　　Now, Karamba is in the game, claiming it better because SafeCAN authenticates a CAN-bus-based network with “zero network overhead.”

　　Assaf Harel, Karamba Security CTO and co-founder, sees what he views as the currently saturated CAN bus as the problem. In modern cars, the number of controllers is 80 to 100. But network traffic flowing on the CAN has grown almost exponentially, “saturating the network bandwidth,” he said. Noting that CAN bus throughput is low at about 1 Mbps, Harel said, “In most cases, the CAN network is maxed out.”

　　Miroslav Pajic, assistant professor in the Department of Electrical and Computer Engineering at Duke University, observed, “Authenticating car networks is an urgent and important matter that the automotive industry has been coping with for several years.” He noted in a statement: “Saturated car networks created technological barriers in finding a solution that will authenticate all traffic to and from the car’s safety systems, such as brakes and airbags, exposing them to physical and cyberattacks.”

　　Hence, the focus of Karamba’s SafeCAN is on implementing network authentication “without overtaxing the car’s internal communications to protect and authenticate CAN bus communications.”

　　Native unencrypted bus

　　The protection of CAN bus is critical because it’s a native unencrypted bus. Today, all vehicles that depend on CAN bus for internal communication between safety ECUs have implemented no security features over that bus. As David Uze, Trillium’s CEO, once told us, “With CAN bus, it’s possible to access every function of the car, including control locks, steering, and brakes.” All that accessibility makes CAN bus a perfect playground for hackers.

　　Trillium’s solution uses its ultra-lightweight block cipher to encrypt CAN (and LIN) messages in real time. Uze claimed that Trillium’s symmetric block cipher and key management system allow SecureCAN to “encrypt, transmit, and decrypt within the 1-ms threshold,” which is required for automotive CAN bus real-time applications.

　　Karamba demurs. Karamba’s CTO told us, “Authentication or encryption requires additional network packets (such as keys and headers).” In the company’s view, any such additions of overhead will become unsustainable because the CAN network is chock-full. Karamba’s Harel observed, “Trillium’s solution requires changing the symmetric keys between ECUs several times every second. This adds a lot of overhead to the already saturated CAN bus.”

　　How SafeCAN works

　　If so, how does Karamba’s SafeCAN work?

　　Harel explained that the safety ECUs (e.g., brakes, airbags, etc.) are paired with a legitimate ECU that sends commands when the car is on the road (e.g., Body Control ECU). Source and destination ECUs exchange the keys and store them in memory, so no key exchange is required over the network. When the source ECU (e.g., Body Control) sends instructions to the destination ECU (brakes), it encrypts in real time. The encrypted message travels via the CAN network and opens at the destination ECU (brakes) with negligible performance impact.

　　He stressed, “The size of the encrypted message is identical to the size of the original (pre-SafeCAN) message. It means that there is no additional network overhead required for the encryption.”

　　In short, the safety ECU can receive only encrypted messages (i.e., sent by a legitimate ECU). Any unencrypted message is the result of a hack. The assumption is that the hacker doesn’t have the key because only the legitimate source has it. The safety ECU will ignore such messages.

　　Motivation

　　Many factors motivate carmakers and Tier Ones to get serious about automotive cybersecurity.

　　On one hand, regulators are breathing down their necks, demanding solutions. The auto industry faces the need to comply with security regulations now being laid out by the National Highway Traffic Safety Administration (NHTSA) and U.S. Department of Transportation (DOT). There is a newly published federal guidance, Automated Driving Systems (ADS): A Vision for Safety 2.0. The U.S. House of Representatives has passed guidelines defined in the SELF DRIVE Act.

　　Also, the automotive industry has become aware of the financial consequences of dawdling on security. The wakeup calls include Chrysler’s recall of 1.4 million vehicles and a flaw in General Motors’ OnStar RemoteLink system, through which a hacker found a way to remotely unlock doors and start engines.

　　Other examples include malicious messages sent via third-party dongles, as seen in the hack of a Progressive Insurance dongle, which was connected to the car to monitor a driver’s behavior for favorable insurance policy prices. Karamba’s Harel observed, “Such an attack enables the hacker to send malicious commands to a car’s safety system by impersonating a legitimate source.”

　　Security also gets even more critical for over-the-air updates. OTA mechanisms can be compromised, sending malicious updates to safety systems. Harel claimed, “SafeCAN will prevent such impersonations.”