Top 3 reasons your car won’t get hacked (today)

17th November 2011

ES Admin

0 0

After the malware attacks on mobile devices running the Android operating system, speculations about automotive viruses have soared again. Compared to IT and telecom, the plague of car viruses has not (yet) arrived in the automotive industry. Open networks appeared in IT in 1985, and appeared in telecom 15 years later. It wasn’t until 2005 that open networks made it to automotive. IT-based attacks started to make headlines as early as 1990, and telecom followed 15 years later. Last year was the “year” of media coverage about attacks on cars. Apply this simple time pattern to malware: The virus phenomenon was widely seen in IT starting in 1995, and today we see it the telecom and mobile platform industries. Automotive is still unperturbed. For now.

But it is high time to look at the car as a connected IT system. The software is just beginning to be standardized and countermeasures are starting to be put in place to prevent major threats in the near future.

Here are the main reasons why your car is still very hard to hack if you apply a few common sense rules:

#1 Physical access is required to reach “open interfaces” like the OBD II connector or USB plugs.
Keep your car locked when you leave it.

#2 Most malware routes into the car are indirect in nature via attacks on service equipment and infested consumer devices.
Make sure you have malware defense established on your smartphone.

#3 Wireless access points are still rare and should be well defended.
Security breaches reported recently were due to significant violations of good software design practices in the custom code, e.g. telematics units, so hold off on subscribing to telematics services for now.

At the automotive security panel discussion at the Freescale Technology Forum this year, there was wide agreement that the car industry has to go back to the basics of security which means know your friends, know who you are communicating with, and follow common sense security practices.

This new impetus for security will be addressed with the help of microcontrollers from Freescale, which provide security features.

•Whitelisting approved code in automotive electronic control units (ECUs) closes the main attack route of intruders and is accelerated by the security engine on the MPC5646C microcontroller.
•Security anchors on an automotive network (as proposed by the SEIS community) can be implemented using the secure flash memory and the cryptographic service engine on the MPC5646C microcontroller.
•The trust architecture of the ARM-based i.MX applications processors supports security strategies like platform virtualization, trusted execution, high assurance boot, secure storage and signed updates that beat intruders’ tools like privilege escalation and rootkitted firmware download.
With these countermeasures properly implemented, virtually all the threats that have been documented up to now could have been thwarted.

Check out more details of the security features of our latest Qorivva microcontrollers and i.MX applications processors