Here at the CESA 4.0 2016 in Versailles a dedicated session on automotive security was held today. Great presentations and good discussions around this theme. Cars get connected and a new world of Car2x communication is started and will get enhanced with other features as we move on. Between 2013 and 2016 known car hacks have multiplied EIGHT fold!!!.

PSA in the keynote speech already presented that a VPN stack (virtual private network) will be the security interface between the car and the outside world (also called backend).  Some OEMs seem to be in agreement with that. But will this be accepted by the consumer, entering a password and how will that work for a car with gas engine optimized for low battery consumption? What if battery drops out completely?

If a self-parking car can be operated by a mobile phone, this network can also be affected by a hacker during operation. Do the ISO 26262 regulations help here and urge for proven functional safety levels? Signals need to be checked, time stamps, security updates and software development processes need to be watched. Test and verification need to close the loop from feature to requirement to implementation and test.

All that is fine and technology will make a self-parking car possible. But it is strange for a consumer getting out of his car and watching it parking on its own. The end user needs to gain trust into this technology in order to love it.

Same applies for autonomous driving, here the consumer also needs to learn how the system works and I remember when I first tested ACC (automatic cruise control) I had my foot on the braking paddle to see and learn how the system reacts – building up trust.

Security is not that visible for the consumer. Only when the car is affected and something does not work, the effect becomes visible. Another effect is the development cycle of a car. Today an IVI system is developed in 2-3 years and a car in 4-5 years. But who knows that the security threat from today is the same in 5 years from now? For sure there will be new ones. So, development time needs to get reduced and software needs to be updated easier and quicker. Firmware update over the air is one way to improve that.

How to handle cyber security is quite well under control for the mobile devices, PC, backend and network side. But the car is the new mobile device and the goal is to have an end-to-end security. In automotive software architectures the outside world (meaning the network stack) needs to be separated from safety oriented software stacks, so that they are not affected by attacks. One good way in doing so is by hypervisor technology, that e.g. SYSGO is offering. A hypervisor can run different operating systems (Linux, Android, POSIX, …) or software stacks (like Autosar, Network stack) in a variety of partitions. Via separation of time and space over several partitions security use cases can be addressed in a better way. This technology is already successfully applied for aerospace and defense. Via certification needs (especially for autonomous driving) I see a hypervisor technology as a MUST have.

Now, one can say, ok I can also have this by a multicore hardware concept. Well, just for separation of functions, yes, but not for time and space handling. Also a hypervisor can add a multitude of partitions in a flexible way during development process. Flexibility is a strong argument for using SYSGO, as our hypervisor is embedded in the real time operating system PikeOS. This means that a code used for a development project since the beginning can get enhanced by hypervisor technology later during the development process without having to use another product and to re-write the code again or negotiate new prices for the project.

Interesting how the future will look like, but safety and security will play an important role there.