Preventing external access to vehicle electronics
Connectivity is the big buzzword that is on everyone's lips
Connectivity is the big buzzword that is on everyone's lips. Yet connectivity does not only play a role in the passenger car sector, if one thinks of autonomous driving. Vehicles are linked with one another and also connected with other systems such as infotainment systems and telematics portals. The driver hands over the control of the vehicle to autonomously operating systems. Thus the transport sector will also experience enormous changes in the coming years due to growing connectivity. Following the takeover of the EU Council Presidency by the Netherlands in the first half of 2016, the focus was on the topics of automation and networking. Platooning, that is the automated slipstreaming of heavy goods vehicles, has increasingly gained public awareness, not least through the European Truck Platooning Challenge, whereby six European truck manufacturers set out on a platooning rally to Rotterdam. The advantages of platoon driving are not only the significant CO2 reduction and simultaneous fuel savings of up to ten percent. The associated Car2Car communication also reduces the risks of human error which is often the reason for serious accidents on European roads.
A platoon consists of at least two trucks, which drive one behind the other at a distance of ten meters and are coupled to each other via a so-called electronic drawbar. In the process, the following vehicle ultimately transfers the driver's own longitudinal and transverse steering to the driver of the guidance vehicle. These platoon trips are covered by extensive environmental sensors and safety functions.
Another example of increased networking in the transport sector is the connectivity of vehicles via the Internet, which can be used to query vehicle information in real-time. Thus, for example, in the transportation of refrigerated goods, the location and the condition of the goods is of great interest. The protection of the seamless cold chain plays a central role here.
The means of transport will therefore be connected, so that all information is available in real time over the Internet and the “Internet of Things” becomes a reality. Foreign software from third-party providers is increasingly being implemented in the vehicles of the future, as is already emerging today in infotainment. Various “apps” will interact with various mobile devices and also with the vehicle itself via the internet, so they must be prevented from accessing the vehicle electronics in a harmful way.
The resultant data streams provide a variety of attack points, which can be used to manipulate and misuse these data. In current press reports on interference and successful tampering, the infotainment and diagnostic interface are time and again cited as critical interfaces, but are they the only ones?
Manufacturers and suppliers must take steps that relate, on the one hand, to the technical conception and, on the other hand, to the design of the development process.
The expansion of the established standard for software architectures, AUTOSAR, which now also contains security mechanisms, shows that these issues have already taken hold in the automotive industry.
Vehicles are no longer isolated objects, they are integrated, in data streams, with virtual entities on the various systems that correspond to them.
Vulnerabilities in the data streams and the system communication must be recognised as early as possible and should be remedied or prevented. Here, both the information about the goods transported as well as the connectivity of the means of transport itself must be considered. Whether on wheels, by rail, over the water or through the air - each domain has its own specific security measures, in addition to the general issues.
Security aspects must be considered in the same way as for current functional security. From development, through production and all the way to the operation of the vehicle, and probably even beyond that to when we think about personal data or business confidentiality, a security process must be established and followed by all stakeholders.
An essential difference between functional safety and security must not be overlooked here: security measures are intended to function against an unknown but nevertheless real and creative adversary who is working in a solution-oriented way. Therefore, it is important to involve employees with diverse experiences, who think in different ways, in the development of such safety concepts.
An appropriate standard on how to proceed with this has not yet been established. IEC 62443 “IT security for industrial control systems - network and system protection” can be used as a basis, but this needs major adaptations in order to fit transport situations. Another starting point is ISO 26262, which is applied in many analogous situations: for example, a fault tree analysis (FTA) of potential attacks and their presumed success, whereby the possible weak points which may have led to that success can be analysed.
In the field of development, security activities must already be included when the requirements are gathered and the functionality defined, since the appropriate protective measures are directly linked to the desired or expected functionality. So the desire for a remote diagnostic access, which should be made possible up to the actuator tests for individual control devices, can have a great influence on the overall concept. During the development process, the security activities not only run parallel to the activities in the V model, they must also be integrated into them and must not be considered independently. The development process requires a sufficient degree of maturity, so that a reliable statement about the security of the vehicle can be made at the end. These process requirements concern not only the OEM itself, but must also be considered by suppliers and the interface partners on the internet. Due to the growing complexity of the vehicle electronics and connectivity outside the vehicles, a comprehensive quality assurance has to be established, which firstly makes suitable protection against attacks possible. Security is not a botch job for a single developer in a laboratory. It is a collaborative effort across multiple levels, which requires functioning and practiced processes.
In order to be able to secure future vehicle electronics against external access, the companies involved must create a sufficient security culture which makes it possible to physically protect both the vehicle and the shared data over the entire life cycle.
An analysis of the potential attack scenarios and a risk assessment begin the development of such a safety culture. Henceforth, this will have to take place via the isolated consideration of the vehicle itself for the entire chain over which vehicle data will be exchanged in the future. Internet-based telematics portals could be used as gateways for the manipulation of a vehicle, even if the entire communication in the vehicle and with the vehicle is encrypted.
When the attack scenarios are established, then four elementary threats can be assumed:
the loss of authenticity, if someone can not manipulate authorised data, faulty updates to a control device can flash if there is any doubt,
the loss of confidentiality if someone can not intercept authorised data, such as trend data or traffic data,
the loss of availability if essential data flows are disturbed and, for example, faults in the cold chain can not be responded to promptly,
and the loss of integrity if the received data for the vehicle electronics can no longer be assured to be unchanged.
The analysis must therefore fully reveal the potential threats and must be repeated at all stages of abstraction in the development process. In this way, the architectures and technologies used can also be examined for possible security weaknesses. In the analysis process, all results and decisions must be accurately recorded and reflected against a cost-benefit analysis so that every system can be secured as needed against attacks from the outside. However, performance losses due to additional security measures can call into question the economic feasibility and maintainability of the system. Consequently, security can not be considered in isolation.
Security targets are developed from the attack scenarios and these are refined into security system requirements. Also in this step, all stakeholders must be involved in the process and all participants have the relevant information.
The goal is to design the system so that it meets the security objectives and is defended against potential attacks. Architectural decisions in system design lay the foundation for validating the vehicle. It should be considered, for example, how well the infotainment, which is more likely to support features of third-party companies, can be isolated from the relevant driving functions. In system design, the permitted entry points for the vehicle must also be defined and analysed.
When considering the technical implementation, the previously mentioned elementary threats, which primarily concern the transport and network layers of the systems, come into focus again. Confidentiality is a matter of encrypted communication with the vehicle or with individual control devices. Here, established methods or tools are used. For authenticity, keys must be exchanged, the storage and care of which, however, again affects the entire chain from the control unit to the connected partner on the internet.
Examples of hacker attacks on vehicles and other means of transport show that security can not be achieved solely by technical procedures, but that the potential weak points must be analysed throughout the entire process chain. There are recurring problems:
Incorrect or missing requirements
Incorrect configuration of the system
Errors from the integration of external components
Lack of overview due to the complexity of the system
A purely technological solution alone does not achieve the aim, rather it requires a change in the working method: requirements can only be improved via a functioning requirements management that fully includes security aspects. The manufacturer can protect itself against defective implementations through systematic testing, but must also consider the methods used during development. In the case of configuration errors, the question arises whether the system can somehow prevent them, or whether remedial training and documentation can be improved. In the case of the integration of external components, interfaces are frequently insufficiently specified. Often the user is deprived of relevant information, and so the general collaboration of the participating companies must also be considered. Finally, a process-oriented and modular approach is necessary in order to be able to master the complexity.
ServiceXpert Gesellschaft für Service-Informationssysteme mbH provides support both as an external service provider as well as a development partner by means of a company-neutral process review, starting with an actual analysis and the creation of a roadmap, up to a complete process consultancy. Sound expertise in vehicle diagnostics as well as a passion for the product are always incorporated in the work of the ServiceXpert engineers in order to make systems more secure.
ServiceXpert, an ESG-Group company, employs over 85 staff in Hamburg and Munich. ServiceXpert is a Europe-wide operating system and software house with a focused service portfolio for Lifecycle management of EE information for leading manufacturers of commercial vehicle and their supplier industry