Five best practices for securing the connected car: Page 2 of 5

October 14, 2015 //By Jean-Pierre Joosting
The automotive industry is abuzz with the high-profile hack of a Jeep Cherokee by security researchers Charlie Miller and Chris Valasek. Miller and Valasek exploited a weakness in Fiat Chrysler’s UConnect system that allowed hackers who know a vehicle’s IP address to remotely control the vehicle – including disabling the brakes, disengaging the transmission and more.

How did the connected car get so insecure?

When it comes to connecting cars to outside networks, the automotive industry is playing significant catch-up. While cars have evolved over 100 years and the Internet over 25-45, depending on when you drop the flag, cars are relatively new as digital devices. Digital controls started replacing analog ones for essential onboard systems in the 1970’s, but onboard vehicle networking did not stabilize until Bosch freely released the first commercial automotive controller area networks (CAN) standard in 1986. CAN protocols are embodied in the International Standards Organization’s (ISO’s) 11898 standard, which covers device identification plus physical and datalink layer protocols.

The latest version is CAN 2.0, which was published in 1991. Note that this is two full years before GM released the first externally networked connected car service: OnStar. CAN 2.0 and all its preceding generations were designed as an internal network that is physically interfaced from time to time exclusively with trusted sources. Security considerations related to connecting this network to the outside world are simply not reflected in the standard.

Hence, connected car security needs to be applied through add-on applications and services which operate in parallel to and in a manner compatible with an existing vehicle’s CAN controller. Movimento’s recently released Over-The-Air (OTA) platform for the Software Defined Car™ is one example of an effective automobile security service.

Design category: