...
- Problem statement 1
- There are a series of initiatives in the automotive industry that will touch the mobile environment
- There is work going on in the mobile/IoT industry that will need to interoperate with automobiles
- It is important for all not to waste resources by “reinventing the wheel”
- Use good protocols that already exist and are deployed
- There are a number of one-to-one company level programs underway, there is NOT a conversation happening at the industry-to-industry level to insure standards-based interoperability and reduce fragmentation of protocols across automotive interacting with IoT and mobile services
- The overall needs of the automotive industry are not being translated into mobile/IoT industry developments – harmonization of requirements and solutions between the mobile and the automobile environments. What are the problems the automotive industry are trying to solve?
- Problem statement 2
- The auto industry wants to ensure openness and mobile device interoperability in relation to the automotive telematics systems
- Automakers run the risk of becoming a “dumb device” with no control over user data
- Operators and automakers could be forced to the sidelines where consumer touch, data collection and ownership are no longer future revenue sources
- Existing automotive approach of proprietary implementations is no longer working
- SDL - Smart Device Link, an open source implementation of Ford’s AppLink (Ford Sync) software libraries enabling smartphone integration across all radio levels and brands of devices (Apple, Android, Windows, etc.)
- RVI - Remote Vehicle Interaction, an open source project by JLR Research Centre in Portland, OR. Enables universal connectivity to the vehicle bus transparently across LTE, Wi-Fi, Bluetooth, 3G, NFC and future networking technologies by embedding a standard software module in the vehicle head unit. SOTA - Software Over The Air (included in RVI above) through the entire vehicle (ASIL grade Safety and Security)
- Problem statement 3 - Security
Vehicle Security
Vehicle security is a very wide subject. Over the past 10 to 20 years the number of computers (ECUs) on the car and the amount of software running on these ECUs grew exponentially. Today’s cars are equipped with tens of ECUs connected by several networks. Unfortunately, the vehicle and the network of ECUs it includes, were not designed with security in mind and were definitely not designed to be connected to the external world.
Figure 1- Numbers to illustrate the automotive software crisis scale
The introduction of the connected car puts the automotive industry in a situation that is very similar to the introduction of the connected computer back in the late 90s. Connecting computers to the internet back then required IT to build the infrastructure to protect the computers on the internal networks. Fortunately, most of this IT software could be leveraged to protect the communication of the car to the external world. However, protecting the communication between the car computers and between the hostile environment and the car computers is still a challenge.
The huge amounts of software on the car exposes many vulnerabilities that might be exploited by hostile agents to cause harm to the driver, to steal private information or to spy on the driver whereabouts. Software update Over-the-Air (OTA) is a mandatory element enabling the OEM to fix the software vulnerabilities without the need of an expensive recall. The connected car introduced a serious problem that OTA is solving taking advantage of the car connectivity.
Figure 2- Some examples of the vulnerabilities of a modern car
OTA Software Update Security
When it comes to OTA software update the security goals of the end-to-end OTA system include the following aspects:
- Authentication
- Authorization
- Confidentiality
- Integrity
Authentication ensures which actors are allowed to work within the OTA system. It could be an admin authenticating to the OTA server, the car authenticating itself to the OTA server, or each software package being validated right before the installation. Authorization make sure that every actor works within the policies dictated by the OTA system designer. Admin have role-based access, software for one ECU cannot be installed on a different ECU etc.
Confidentiality requires that all software artifacts are properly protected, so software and IP does not end up at the wrong hands and potentially exploited. Integrity verifies that every piece of software, in transit or at rest has not been maliciously or otherwise modified.
OMA DM was designed with such security design goals in mind. For the past decade, OMA DM has been successfully used on billions of mobile devices to securely deliver software updates over the air. Adopting the OMA DM protocol to deliver OTA services for the automotive market is the right direction.
Figure 3- End to end OTA Software Update
4.2 Hot Projects in Open Automotive
...