IT Security of Commercial Vehicles

Transcription

1 IT Security of Commercial Vehicles Public Key Infrastructures and their Contribution to Safety and New Business Models Hakan Cankaya 1, Daniel Estor 2, and Moritz Minzlaff 1 1 ESCRYPT GmbH, Bismarckstr. 71, Berlin 2 ESCRYPT GmbH, Leopoldstr. 244, München Abstract. Driven by the goals to improve efficiency and safety, commercial vehicles become increasingly interconnected. In addition, new features and business models such as selling or leasing feature sets are based on ever larger amounts of software. If these and similar developements are not accompanied by appropriate IT security measures, then they expose OEMs, drivers, and other users to uneccessary risks. Therefore, public key infrastructures (PKI) which serve as a central ingredient to many protective measures become increasingly relevant. This article contains three contributions to a discussion of PKIs: First, to clarify the impact a PKI can have, we consider its applications to commercial vehicles from a use-case point of view. Second, we highlight the required components, actors, and the roles they play, and give examples from other industries where PKIs are already or are becoming established. Based on these considerations, we finally discuss specific aspects of a PKI deployment for commercial vehicles referring to the previously mentioned examples. 1 Introduction In many industries, computerization and digitalization of production processes are major factors to reduce costs, increase saefty and quality, and protect the environment, e.g. through more efficient use of chemicals [1]. Commercial vehicles are no exception to these trends. Increasingly, these efficieny gains are made through connecting formerly isolated systems. The aim is to not only optimize processes at a single production step but throughout the whole production chain. For example, what started with so-called precision farming, e.g. using sensors in each tractor to find the ideal amount of fertilizer for a particular patch of farmland, is becoming smart farming [2], i.e. the integration of all vehicles on a farm to better coordinate their joint work. Along with this trend for more networked vehicles, new approaches to safety such as conditional safety certificates are developed. Their goal is to keep (or increase) safety levels in face of a very diverse network of machines where many decisions need to be made at runtime [3]. This computerization also allows to save production cost for OEMs or even allows new business models. It becomes possible to differentiate various models in software only, thus saving the high costs of developing multiple hardware platforms. On-demand feature activation takes this one step further: The leaser or owner of a construction vehicle, for example, may need additional power for only a certain amount of time. Upon calling the OEM and paying a fee, the software in the vehicle will then unlock

2 the desired feature. It also becomes possible to sell features sets which the customer may keep while upgrading from one vehicle to a new model. It is clear that feature activation (or selling feature sets) only makes sense when it is sufficiently secure, i.e. when only the OEM is able to unlock new/for-pay features. But the same also applies to the overall trend of increasing computerization: As software is much easier to manipulate than hardware, the number of potential attack points grows together with the amount of software in commercial vehicles. Moreover, as vehicles get more and more connected, a potential attacker does not even have to be physically close to carry out an attack. Worse, a single attack might affect or be easily ported to many vehicles at once. Machine-to-machine communication needs protective measure for another reason as well: For example, when safety assurances are calculated and communicated based on conditional safety certificates, then those same certificates must be authentic and be protected against manipulation. Whenever a given vehicle or component needs to process information from an unknown source (such as in open networks of multiple machines) or delivered via unsecure interfaces (such as ISOBUS) [4], public key infrastructures (PKI) can play a major role in providing the desired security properties. The central task of such a PKI is to bind information, for example ownership or permissible use cases, to cryptographic keys in so-called certificates. This enables the automated verficiation of, say, origin or content of a message with the help of cryptographic mechanisms and the information in these certificates. Further tasks of a PKI are key generation in a secure environment, key and certificate distribution, secure storage and more. These PKIs in the context of commercial vehicles, their applications and setup, are the focus of this article. Related work PKIs as a means to improve efficiency and safety have been discussed for some time now. The primary focus so far has been in the context of V2X applications, which are largely driven by the Car 2 Car Communication Consortium in Europe [5] and by the Department of transportation in the USA [6], [7]. The concepts in this area are already quite mature resulting in the NHTSA considering to make V2X technologoy mandatory [8]. With regard to commercial vehicles, one major use case of a V2X PKI is finding suitable parking for highway trucks in order find the optimal available parking space that drivers can reach within their regulated hours of service, thus increasing both efficiency and safety [9]. Further V2X PKI use cases include bridge height warnings, or increasing the fuel efficiency by providing detailed congestion or traffic light information [10]. Our contribution Motivated by the scenarios and use cases mentioned above and others such as tuning protection, software update, and securing of diagnosis interfaces, we describe potential roles a PKI can play in the area of commercial vehicles. Based on these considerations, we discuss the details of a potential PKI deployment. We will highlight the different components and actors that are involved in a PKI setup. To this end, we also analyze similarities and differences with other industries where PKI use is already established.

3 Finally, we sketch concrete concepts for certain applications of a PKI for commercial vehicles. Our ideas may be used as a starting point for an actual deployment. 2 PKI applications for commercial vehicles In the introduction we remarked that certificates of a PKI bind information to cryptographic keys. This in turn allows to put meaning to certain cryptographic operations thus enabling security measures that protect assets. We will now discuss various examples, grouped according to a common theme, e.g. protection of OEM interestes. 2.1 Protection of OEM interests One major application of PKIs in vehicle production is tuning protection. Take for example the case of a construction vehicle OEM that offer variously priced and powered models based on the same hardware platform. To protect the firmware of the vehicle against unauthorized manipulation (say, by the user who wants to gain unauthorized access to a more powerful vehicle), a PKI could provide certificates that prove that a certain cryptographic key belongs to the OEM s firmware developer. Assume it is known that a certain key belongs to a developer of the tractor implement manufacturer. A digital signature created with this key under the vehicle s firmware can then be used as a mechanism to verify the authenticity and integrity of the firmware. When this verification is done during the flashing of the firmware, this is often called secure flashing. A similar situation arises with unprotected diagnostic interfaces. Not everyone should necessarily be allowed to access the diagnostic readouts of an ECU or to flash new firmware. To this end, an ECU with secure access would send a challenge to the user. Only when the user presents a valid signature together with a certificate from the PKI that proves the user s authority will the ECU open its diagnostic interface. Another application is theft protection. Obviously, the owner of a vehicle or a tractor implement suffers financial damage from theft to replace the stolen equipment. The owner might also miss an important (harvesting, construction project) deadline when the equipment could not be replaced in time. This also reflects badly on the OEM who in turn has incentive to take precautions against theft. One such measure, known as component identification, can do much more than theft protection and also prevent the use of counterfeit parts [11]. Here, components use certificates to prove that they are original parts and to allow them to form closed groups, for example, all components belonging to a given vehicle. With such a setup, it also becomes possible to protect against theft of the whole vehicle: The basic idea is that one of the vehicle s components is a smart card that is not kept with the vehicle when the vehicle is not in use, but without which all other components refuse to work. 2.2 Support of new business models Similar to tuning protection discussed in the previous section, secure feature activation protects a vehicle s software against unauthorized changes. This time, however, there is the explicit option to change some key parameters against payment. Such options

4 could include unlocking additional horse power in a construction vehicle or additional sensors in a tractor implement. To this end, the user would pay the OEM who runs a PKI backend server that in turn sends a freshly generated certificate to the vehicle (either directly or via the user as proxy). The vehicle then verifies the certificate s signature and unlocks the paid features as stated within the certificate. The certificate can also contain additional information to limit the use of those features to a certain usage time or location. Taking this idea one step further, an OEM could start selling feature sets : The OEM could offer contracts that upgrade the user to the latest vehicle hardware in regular intervals and the user can take their desired features from one vehicle to the next. The basic idea, that certificates protect the feature set, is as before. In both cases there are clearly additional details to take care of to prevent, e.g. double use of a given certificate. 2.3 Efficiency improvements So far we discussed PKI applications that benefit the OEM. In this subsection we discuss efficieny improvements that primarily benefit the operator of the vehicle. In the final section of this article, we will see that this change in focus also affects the architecture of the PKI. Machine-to-machine communication can save both time and costs through higher precision, tighter integration of construction or farming processes ( smart farming ), or advanced fleet management systems. The savings can lead to drastic reduction in fuel consumption and pesticide use, thus not only benefiting the farmer, but also the environment [12]. While the benefits are many, each interface of a vehicle to the outside world also opens new attack paths an attacker might exploit. Be it for fun, fame, or competition: With wireless communication interfaces, often connected to the public internet, the attacker does not have to be physically close to their target, thus drastically reducing the likelihood of their discovery. A PKI can counterbalance this advantage of the attacker, by raising the costs of the attack: Similar to component protection, all vehicles in one farming system, commercial fleet, or construction project need to be programmed in such a way that they require the counterparts to identify themselves through the use of digital signatures and certificates. Now if an attacker wants to interfere with a system by sending fake messages, the vehicles can identify and reject the fakes as they will not include authorized signatures. 2.4 Safety improvements Finally, modern information technology can improve safety. We already mentioned conditional safety certificates and V2X in the introduction. Both try to raise safety levels in an open system of machines of various OEMs and operators interact with each other and infrastructure. For example, a V2X system may provide bridge height or collision warnings. Of course, these system can only be effective when they can be trusted, in particular, when the information contained in conditional safety certificates and V2X messages is authentic and not manipulated. As we have discussed before, a PKI can provide the necessary trust: Through digital signatures under the conditional safety certificates or messages along with certificates that bind identities to those cryptographic keys that are used to create these signatures.

5 3 Components and roles of an embedded PKI Although Public Key Infrastructures exist in various realizations, they typically incorporate similar building blocks. In the following, we specially focus on PKIs in embedded environments and if possible, we refer to already existing deployments mainly in the automotive industry. 3.1 Technical components Common to all PKIs is the main task of providing certification of cryptographic keys and optionally further information about an entity by issuing a digital certificate. This is performed by a Certification Authority (CA) that generates digital signatures over the respective data. Typically, a PKI comprises multiple CAs which are hierarchically ordered meaning that there is one root CA that can issue certificates for other CAs who can then issue certificates for further CAs or for the actual users. The technical foundation of each CA is a module to perform cryptographic operations, which is clearly also the most sensitive part of the CA. A high level of security, especially with regard to cryptographic keys, can be achieved by using a dedicated hardware security module (HSM), whoose use is strongly recommended for every PKI. Depending on the scope of the PKI, requirements regarding the HSM may differ. For vehicle-to-vehicle (V2V) communication, for instance, huge numbers of certificates must be issued resulting in high performance requirements, whereas the HSM of a root CA must primarily satisfy maximum security requirements. Having an appropriate HSM in place, the next step is to establish technical means to control access to cryptographic keys and the respective operations. Especially if a PKI targets embedded devices, the user and permission management must be tailored to the specific usage scenario and is often much more complex than in classical IT systems. Contrary to a user-centric PKI issuing authentication certificates to be used outside of the PKI, a device-centric embedded PKI offers further functionality to different kinds of users. Software developers can be allowed to sign firmware, workers at a production site can be allowed to export keys from the PKI and inject them into devices or to authenticate at protected diagnostics interfaces, and even non-human, autonomous applications may be allowed to perform cryptographic operations for various use cases. The challenge of user and permission management is to realize mechanisms which can technically enforce these organizational requirements. Often, this functionality is performed by a separate component called registration authority (RA). Finally, the functionality of the PKI must be accessible by the intended users and thus provide multiple external interfaces that are optimized for the respective use case and accessing entity. Software developers can be provided with a web interface to sign firmware, but also machine-to-machine (M2M) interfaces are common, e.g. for provisioning vehicles with certificates for V2V communication. Furthermore, specialized client tools like e.g. a local registration authority (LRA) to avoid the requirement of an online connection during production processes, and tools for key injection and secured access to diagnostics interfaces increase usability and are often an essential requirement when realizing sophisticated embedded security mechanisms.

6 3.2 User roles The task of a trusted authority can only be carried out if a proper technical implementation goes along with well-founded organizational rules that all involved people strictly follow. A precise definition of possible user roles and the respective authorizations is the foundation of all rules and policies. First and foremost, administrative tasks have to be assigned to certain roles. To minimize the threat of insider attacks, a split of duties should be established if possible. A simple but effective approach is to split the administrative role into an IT administrator for technical tasks, an auditor who may read and evaluate audit logs about the operational usage of the PKI, and a user administrator who may create and delete users, modify user properties, and assign authorizations to users. Besides, there may be various roles for the actual users of the PKI which are, technically speaken, pre-defined collections of permissions. In the previous chapter, some possible roles like software developer, workshop staff, or staff at the production line were introduced. In an embedded PKI user roles can also represent non-human entities such as entities participating in V2V communication. The role concept must be carefully developed and adapted to the specific application scenario. At the one hand, each user should be assigned least permissions as possible to protect against unauthorized actions, but at the other hand, a role concept which is too scrict may undermine the user s acceptance and could also lead to problems in the regular business operation. Another aspect that must be taken into account is the granularity of the role concept. A fine-grained concept with many different permissions is flexible but may quickly become very complex and difficult to manage. All in all, care must be taken to find the right balance between strict access control and usability. 3.3 Life cycle management Finally, all process of a CA life cycle must be secured against attacks by external people and, if possible, also against internal attackers. The most critical process is the instantiation of the CA, which includes generation and backup of the CAs signature key. Rules regarding CA instantiation should demand sufficient logging to ensure accountability of the involved persons and enforce a foureye-principle meaning that at least two people are required for the process. This process is to be separated from operational processes such as registration of users and the usage of the CA keys to sign certificates. From a security perspective, operational processes do not have as strict security requirements as the instantiation of a CA and thus require different policies. While an attacker who mounts a successful attack during the instantiation could read the CAs private key or could replace the CA key by an own key, this is not possible during operational processes as long as the technical requirements are met. Hence, attacks during operational processes are limited to single users or certificates whereas attacks on the instantiation phase have impact on all users and the CA as such. At the other hand, policies for operational processes must allow for efficient execution of requests while preserving the required security properties. These policies include regulations on how the identity of users must be verified and under which circumstances a certificate may be issued. They strongly depend on the specific usage scenario.

7 4 Model deployments for commercial vehicles The previous sections focused on potential PKI related use-cases and the individual components and roles required for a publick key infrastructure in general. In this section we will introduce three possible PKI deployments targeting commercial vehicles, an OEM controlled, a customer controlled and a public PKI. The description of each deployment defines the objectives of the setup and lists possible use-cases which can be realized with this setup. Afterwards, a possible deployment of the setup is introduced summarizing the individual components and roles for exemplary use-cases. 4.1 OEM controlled PKI In an OEM controlled PKI, the complete PKI is operated by the OEM back-end, which manages the relevant entities. The term entity is used in a broad sense and can refer to vehicles, coworkers of the OEM, technicians, third-party back-ends or coworkers of the customer. This setup is necessary when the OEM requires secure authentication among the entities and needs to grant privileges for the different roles depending on the use-cases. Typical scenarios for such a setup are Secure Flashing, Feature Activation, Secure Diagnostic Services, or Tuning Protection. The essential component of the setup is the OEM back-end which at the one hand acts as a trust anchor for the PKI, and at the other hand manages the registered entities and their respective cryptographic keys and privileges. The back-end hosts a database where all users of the PKI are registered and their authentication (e.g. symmetric key, public key, passwords) and authorization (e.g. privileges like access rights to vehicles or register other users etc.) information is stored. The back-end must be organizationally and technically protected by the OEM against unauthorized access. The most important issue regarding client interaction is a secure method for authentication. A password authentication is a simple method to create an access control mechanism, yet is prone to several weaknesses (e.g. password too simple, can be handed over to other persons etc.). A very secure method is the use of smart cards for human users and HSMs for HW components. This enables a secure authentication with assymmetric cryptography since the user or HW component can sign any message with its smart card and the signature of the message can be verified (for integrity and authenticity) by anyone owning the public certificate. Nevertheless, the selection of the authentication methods usually depends on the required security, cost and organizational requirements. More secure authentication methods may be requested for security critical services by the back-end, and more basic authentication methods are accepted for non-critical services. Figure 1 shows an exemplary setup and serves as an example to provide an insight into a realization of an OEM controlled PKI. The use case considered here is secure access to an ECU of a vehicle (e.g. for accessing diagnostic services). Two imaginary users are depicted in the setup. A PKI management officer is a user with the privileges of adding new users to the PKI and setting their access rights to the diagnostic services of the ECU s. The other user is a service technician who accesses the diagnostic interface of the ECU for maintenance work. The technician uses a PC and a diagnostic tool to connect to the vehicle s diagnostic interface. The tool, in turn, is connected to the

8 OEM s PKI, which in fact performs the authentication of the service technician and authorizes him to access the diagnostics interface. For authentication, the technician possesses a smart card that contains a digital certificate. The PKI server authenticates at the ECU either with a digital certificate which is stored securely or with a secret symmetric key that is shared between the PKI server and the ECU. If the technician wants to access the diagnostics interface, he first authenticates at the PKI server using his smart card. The PKI then checks whether the technician is authorized and in case of success triggers the ECU to grant access to the interface. Fig. 1. Exemplary PKI setup for secure vehicle access 4.2 Customer controlled PKI In a customer controlled PKI, the customer hosts a back-end which acts as a sub CA. It has a similar architecture and functionality as the OEM controlled PKI, with the difference that the root CA (OEM back-end) issues a certificate for the sub CA (customer back-end) to create a chain of trust. This certificate lists the privileges and the public key of the sub CA and is signed by the root CA. This setup fits use cases like fleet tracking, smart farming or configuration of the vehicle (e.g. due to added peripherals).

9 Figure 2 shows an exemplary setup. The setup is not related to a specific use-case but rather serves as an overview about how the CAs are related to each other. The functionality within the customer PKI is the same as the example given in secton 4.1. The same technical and organizational measures for the back-end security, storage of security critical data, authentication mechanisms and assignment of privileges have to be provided. As stated in section 4.1, the vehicle ECUs (or any other entity in the PKI) know the public key of the OEM back-end (root CA) and can verify a certificate issued by the root CA. The entitites in the customer PKI must be provided with the certificate issued by the root CA with the privileges and public key of the sub CA. With this certificate, all entities can trust the sub CA, verify certificates from the sub CA, and are aware of the privileges assigned to the sub CA by the root CA. Fig. 2. Exemplary PKI setup for a customer controlled PKI Multiple methods exist to deploy the issued certificates from the root CA. The certificates can either be sent to the entities during the authentication/authorization sequence for accessing a service (e.g. see section 4.1 secure access use-case) or the certificates can be deployed to the ECUs over the diagnostic interface with a dedicated service. 4.3 Public PKI A public PKI covers the situation where permission management and the usage of cryptographic keys is not exclusively controlled by an OEM or by a customer. A typical

10 setup which is also used in V2X communication is shown in figure 3. A common root CA is the trust anchor for all involved OEMs or other participants and issues certificates to other CAs. It defines common policies that all participants have to adhere to and can be operated commonly by the involved participants or by an independent organization. The sub CAs may be operated by an OEM, a customer or even an independent company. This is possible because the root CA audits the operators of each CA and issues certificates only if the CA fulfills all requirements stated in the respective policies. Fig. 3. Exemplary PKI setup for a public PKI A public PKI is necessary when vehicles of different manufacturers should interact and common policies are to be enforced. In this case, the common or independently operated root CA acts a trust anchor and additionally defines those policies that all participants have to adhere to. Regarding commercial vehicles, the integrity of Conditional Safety Certificates could be protected by such a public PKI. A common root CA would

11 have the role to define policies under which circumstances certain safety statements may be made in such a conditional safety certificate. 5 Conclusion Fortunately, developers of hardware and software become increasingly aware of the importance of IT security for their products. As pointed out in the beginning of this paper, there already exist some concepts that also include security mechanisms with the most significant example being V2X communication. However, we also identified use cases and deployment scenarios whoose security could be considerably increased by making use of a specially adapted public key infrastructure. Besides, implementation of security mechanisms not only protects against malicous attacks but may also increase efficiency by e.g., smart farming, fleet management tools, or traffic flow optimization and even enable new business models such as feature activation or leasing. In this paper, we present a general overview of potential use cases. It goes without saying that before an actual deployment of any of the presented use case, more detailed questions have to be solved. Finally, it is to be stressed that a PKI is a major but not the only component of a well-founded security concept. References 1. K. Köller. Landtechnische Innovationen auf der Agritechnica Website, Available online at visited on December 19th J. Knodel and D. Schneider. Sicher vernetzt. Funktionssicherheit am Beispiel Smart Farming. Mobile Maschinen 3/2013, D. Schneider, M. Becker, and M. Trapp. Approaching Runtime Trust Assurance in Open Adaptive Systems. Website, Available online at 7a Becker.pdf; visited on December 19th P. Fellmeth. CAN-based tractor - agricultural implement communication ISO CAN Newsletter September 2003, CAR 2 CAR Communication Consortium. Manifesto. Overview of the C2C-CC System, U.S. Department of Transportation. Connected Vehicles Applications. Vehicle-to- Vehicle (V2V) Communications for Safety. Website, Available online at visited on December 19th U.S. Department of Transportation. Connected Vehicles Applications. Vehicle-to- Infrastructure (V2I) Communications for Safety. Website, Available online at visited on December 19th T.P. Jeffrey. NHTSA May Mandate That New Cars Broadcast Location, Direction and Speed. Website, Available online at visited on December 19th European Commission. Directive 2010/40/EU. Framework for the Deployment of Intelligent Transport Systems, 2010.

12 10. Telematics update. V2X for Auto Safety & Mobility USA Website, Available online at visited on December 19th K. Höper, C. Paar, A. Weimerskirch, and M. Wolf. Cryptographic Component Identification: Enabler for Secure Vehicles. Proceedings 62nd IEEE Semiannual Vehicular Technology Conference, Carbon War Room. Machine to Machine Technologies: Unlocking the Potential of a $1 Trillion Industry. Website, Available online at visited on December 20th 2013.