Health & Medicine

A model for safe and secure execution of downloaded vehicle applications

A model for safe and secure execution of downloaded vehicle applications
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A MODEL FOR SAFE AND SECURE EXECUTION OFDOWNLOADED VEHICLE APPLICATIONS Phu H. Phung*, Dennis Kengo Nilsson † * Department of Computer Science and EngineeringChalmers University of Technology,  † Syncron  Keywords: Vehicle software/firmware, language-basedsecurity, policy enforcement. Abstract Existing secure protocols and code signing mechanisms forvehicle systems to download and install software over the aircertify only the srcin and the integrity of software; thus, theydo not address errors that might not be detected in thedevelopment process and cannot ensure that the downloadedsoftware do not contain malicious code. In this paper, weidentify such possible threats by developing a threat modelfor the vehicle software architecture. We proposecountermeasures against the threats by preventing ormodifying inappropriate behaviour caused by, e.g., maliciousor poorly designed applications. We propose a model todeploy the approach which is based on modifying theapplication at the wireless gateway in the vehicle before beinginstalled. As a result, security policies are embedded into theapplication and intercepts security relevant execution events.Thus, the execution of downloaded vehicle applications ismonitored to ensure the safety and security for the vehiclesystem and to detect potential cyber attacks. 1 Introduction Current trends in vehicle systems are extensibility andopenness which allow software to be downloaded andinstalled over the air [1]. However, such extensible systemspotentially face difficult security problems. Although severalsecure protocols or code signing mechanisms [2,3,4] invehicle systems have been proposed, they certify only thesrcin and the integrity of software. These solutions cannotensure that the software do not contain malicious code noraddress errors that might not be detected in the developmentprocess.This paper analyses possible threats and potential cyberattacks in the vehicle software architectures including add-onsoftware and ECU (Electronic Control Unit) firmware. Foreach threat, we introduce a corresponding countermeasure. Inorder to implement the countermeasures, we study a classicapproach of imposing a security policy (defining acountermeasure) on downloaded software via a securityreference monitor. The reference monitor [5] is a trustedcomponent which intercepts security relevant resourcerequests and applies a security policy to decide whether togrant such requests.We analyse the difference between add-on software and ECUfirmware scenarios in vehicles and propose a model to deploya reference monitor for each scenario. Add-on software andECU firmware installation and updating over the air arethrough a wireless gateway in the vehicle. In our proposedmodel, a transformation module is located at the wirelessgateway as a proxy between the downloading module (as asecurity reference monitor) and the installation/updatingmodule. After downloading, the code is rewritten to “embed”(inline) security policies within it. Thus, the execution of themodified code is enforced by application-specific securitypolicies implementing countermeasures to prevent identifiedthreats. We illustrate the implementation of the referencemonitor for add-on software architecture in an aspect-orientedprogramming language [17] and propose a solution for theimplementation for the ECU firmware architecture. The maincontributions of this paper are: •   We have analysed threats in the scenarios of vehiclesoftware architectures and have proposedcountermeasures against the threats. •   We have proposed a model to deploy the securityreference monitor that can implement the proposedcountermeasures against threats in the vehicleapplication scenarios. •   We have illustrated the implementation of theproposed model in the vehicle add-on softwarearchitecture and have proposed a solution toimplement the model for the ECU firmwarearchitecture.The next section discusses related research in the area of security in vehicle systems. Section 3 reviews the architecturefor application scenarios in the in-vehicle system. Section 4defines the problem, analyses threats and presents theproposed countermeasures. Section 5 proposes a model(Section 5.1) to implement the proposed countermeasures byapplying the reference monitor approach (using codetransformation) into the vehicle software architecture. Therealisation of code transformation in the model for twovehicle application architectures is presented (Section 5.2)  with several examples illustrating security policies thatimplement countermeasures. Conclusion and future work directions are presented in Section 6. 2 Related work The Global System for Telematics (GST) project [1] providesa reference standard for vehicle systems. The standard isJava/OSGi [6] based, describes how a telematics clientapplication can be downloaded and installed over the air froma control centre, and specifies an interface for receivingvehicle data. The OSGi (Open Services Gateway initiative) isa standard framework providing an environment for themodularization of applications into smaller components called bundles . The bundles are developed in Java programminglanguage and run on a Java runtime environment. In practice,the OSGi framework has been used in in-vehicle systems byseveral car manufacturers. For instance, BMW has used theOSGi specifications as the base technology for its high-endinfotainment platform [7]. Open Arena Lab DemonstratorEnvironment (OALDE) is a project, collaborated by Volvo,Ericsson and Lindholmen Science Park [21], that aims tobuild a solution for information exchange and interfacesbetween driver, vehicle, transport management, society andinfrastructure. The OSGi framework is also used in OALDEfor the vehicle software architecture.The security sub-project of GST [2] considers the securityaspects of the GST project and intends to provide a large-scale infrastructure for telematics applications to ensuresecurity, privacy, and reliability requirements. The presentedsolutions focus in general on communications security andverifying the integrity of downloaded software in vehicles;however, safety and security of the software for the systemhas not been considered.The S3MS project [8] has developed a security-by-contract   technological solution which would allow users to downloadand use applications on a range of devices. A securitycontract can be defined and checked by a customer’s serviceprovider, a trusted third party, or even by the customer. Thesecurity contract determines the restrictions on data andresource usage of the customer device for the downloadedapplication. This requires an agreement between users anddevelopers.Fig 1. In-vehicle network consisting of several networks and awireless gateway.An emerging trend among vehicle manufacturers is toperform wireless ECU firmware updates [9]. Previousresearch [3,4] has focused on securing the communicationchannel in terms of data confidentiality, data integrity, anddata authentication. However, if the firmware contains a bugand an attacker exploits it, various attacks on the in-vehiclenetwork are possible [10,11,12]. Consequently, there is a needfor fine-grained security mechanisms such as security policyenforcement to monitor application execution. 3 Vehicle software architecture In this section, we describe details on the architecture for thesoftware download scenario in vehicle that we use for thiswork. A modern vehicle contains an in-vehicle network consisting of various ECUs and networks such as CAN(controller area network), MOST (media-oriented systemtransport), and LIN (local interconnect network) that areinterconnected through gateways. There is a wireless gatewayconnected to the CAN bus that allows the in-vehicle network to access external networks such as fleet-managementsystems and the Internet. The in-vehicle network is illustratedin Fig. 1. The vehicle contains various applications which canbe divided into two categories: add-on software and  ECU  firmware . The add-on software requires an underlyingplatform that runs the application. On the other hand, for ECUfirmware, the application is self-contained, flashed to aflashable ROM, and runs on a microprocessor [13]. Add-On Software In this work, we consider the vehicle software architecturesimilar to the architecture in OALDE project [21], which isbased on the open standard in the GST [1]. In thisarchitecture, software is installed and executed on the OSGiplatform [6], which runs on an operating system (OS) on anon-board vehicle computer. An application in OSGi consistsof one or more bundles. The on-board vehicle computer isconnected to the CAN bus and provides interfaces forapplications such that the applications could access theunderlying car infrastructure. The add-on software isdownloaded over the Internet via the wireless gateway and isthen installed and run within the OSGi framework. The add-on software is often used to provide infotainment services.Software that does not interfere with vehicle controls could beprovided by third party providers. As described in [1], theGST standard will provide an environment for an openmarket for online services establishing seamlessinternetworking . Moreover, there will be standard interfacesthat allow different parties to develop and deploy the newfunctionality or sub-systems. Such an application example,which could be supplied by a third party, is the location-basedservice for vehicle that provides information such asrestaurants in the vicinity. No connection to vehicle controland maneuverability ECUs should be allowed. ECU Firmware Specific firmware is flashed to the flashable ROM of eachECU. The firmware provides various functionalities for the External Communication Wireless Gateway ECUs   corresponding ECU. The firmware is typically issued by thevehicle manufacturer because the functionality of the specificECUs often require access to vehicle control software. Forexample, all driver assistance applications that communicatewith ECUs responsible for the control and maneuverability of the vehicle are built-in firmware. 4 Threat analysis In this section, we describe the assumptions we make aboutan attacker in the vehicle software architecture. We analysevarious threats based on the assumptions and designcountermeasures to address the threats. The countermeasuresare based on the monitoring of vehicle software execution toenable safe and secure execution. 4.1 Attacker assumptions As presented in Section 3, the add-on software is downloadedover the Internet via the wireless gateway. We assume thatthe downloading process is guaranteed to provide authenticityand integrity via a secure protocol, e.g., [3,14,4]. Thus, thedownloaded software is assumed to not be compromised byattackers. In this architecture, an attacker could be a maliciousthird party software developer that could easily createmalicious software. The malicious code could target otherECUs connected to the CAN bus. In addition, developersnormally focus on the functionality of software which couldlead to an oversight of security aspects such that trustedsoftware might contain threats. For ECU firmware, weassume that some firmware could be provided by third partydevelopers. The malicious code installed in an ECU couldsend messages on the connected CAN bus and potentiallyaffect other components in the in-vehicle network. Weseparate the attacker actions for the two different categories. Add-On Software The attacker creates add-on software to, e.g., the infotainmentsystem. The actions that the malicious code can take arelimited to the functions that the add-on software is allowed toperform. Moreover, the interface between the add-on softwareand the OS limits the attack actions. The malicious codecould try to read data from the OS that it normally should notaccess or spoof messages that it typically should not send. ECU Firmware The attacker creates a firmware that can perform arbitraryactions for the corresponding ECU. The firmware is flashedto the target ECU. For example, the ECU could be controlledto read messages that it normally should not have access to orspoof messages that it typically should not send. Since theECU firmware allows communication with vehicle controlECUs, an attacker can target the control and maneuverabilityof the vehicle. Examples of vehicle virus are found in [10]. 4.2 Threats and Countermeasures Design This section describes possible threats of software andfirmware in vehicle systems. We identify the threats for thetwo architectures and consider harmful behaviours that mightnot be prevented by existing download/installation protocolsand might not be controlled in the development process. Welist below possible threats together with a correspondingcountermeasure to enable safe and secure software execution. •    An unauthorised read event caused by an applicationshould be suppressed  . If the add-on software or the ECUfirmware tries to read messages in the OS or on the CANbus that are not meant for the running application, thosereads should be detected and suppressed. Therefore, it isimportant to establish policies to determine which readevents should be allowed for the particular application. •    An unauthorised send event caused by an applicationshould be suppressed  . If the add-on software or the ECUfirmware tries to send spoofed messages or replaymessages in the OS or on the CAN bus, those eventsshould be detected and suppressed. In addition, for theECU firmware, those events should be logged since theycould potentially target safety-critical ECUs. Policies thatdefine which messages are allowed to be sent for specificapplications must be carefully designed and developed. •    An unauthorised use of a critical resource by anapplication should be logged and suppressed, and analert should be generated  . If the ECU firmware or theadd-on software tries to access and use a criticalresource, such as vehicle control or engine managementthat it should not use, those events should be detected,logged, and suppressed. In addition, an alert about theevent should be generated and sent to the properauthorities. The alert should contain which applicationcaused the event, which resources the application tried toaccess, the nature of the access, and the time of the event.The alert could, e.g., be sent to the vehicle manufacturer,who then could investigate the event further. •    Authorised use of system and critical resources by anapplication should be limited  . ECU firmware and theadd-on software should be prevented from overusingsystem and critical resources. Applications couldpotentially abuse resources, and thus policies to preventsuch abuses must be defined and enforced. Eventsrequesting resources that exceed the limit should besuppressed. •   The execution of add-on software should be monitored bya global policy handler in the software framework  . Theframework should contain a global policy handlerresponsible for monitoring the execution of software add-on applications. The policy handler should aggregate thebehaviour for all monitored applications and applypolicies on a global view of the applications. •    Read and send events in ECU firmware are recorded together with the extracted content of messages . From thetrace of extracted information in each ECU, potentialcyber attacks can be detected (c.f. [15]).  Threats Countermeasures   Application reads unauthorisedmessages to the OSSuppress the eventApplication sends unauthorisedmessages to the OSSuppress the eventApplication accesses unauthorisedcritical system componentsGenerate alert, log andsuppress the eventApplication has high priorityprivilege that cannot be terminatedalthough it shows harmfulbehavioursPut it under the control of aglobal handlerApplication consumesconsiderable amount of resources,e.g., sending unwanted number of SMS or using high amount of memory (might be due toprogramming failure)Suppress the event if amountof allowed resource usage foran individual application isexceededA set of applications consumeresources within their limits buttheir total resource usage is highPolicy handler aggregatesresource usage for allapplications and the event issuppressed if amount of totalresource usage is exceeded Table 1: Threat model for add-on software. Threats Countermeasures   Application reads unauthorisedmessages on the CAN busSuppress the eventApplication sends unauthorisedmessages on the CAN busLog and suppress the eventApplication accesses unauthorisedcritical system componentsGenerate alert, log andsuppress the eventApplication consumesconsiderable amount of resources,e.g., using high amount of memory (might be due toprogramming failure)Suppress the event if amountof allowed resource usage foran individual application isexceeded Table 2: Threat model for ECU firmware. Threat Model As a result, Table 1 summaries the threatsposed by add-on software, and Table 2 presents the threatsposed by ECU firmware. A corresponding countermeasure foreach threat is also described in the tables. 5 Model for implementing the countermeasures The basic approach to implementing the proposedcountermeasures in this work is to intercept security relevantevents of vehicle applications before they are installed orupdated. These events can then be permitted to be run,rejected, modified, or recorded at the execution stageaccording to some predefined policies. This is a variation onthe classic idea of a security reference monitor  [5], and inwhat follows we will refer to this mechanism as the“reference monitor”.The implementation of this idea will be through atransformation of the code before it is installed or updated tothe vehicle. Program transformation to embed securitypolicies is an implementation of the reference monitorapproach in which a target program is modified so that itadheres security policies on security-relevant actions orevents when it executes. First we must decide on what isbeing intercepted and monitored. From the threat model, wederive that it is system calls to read/send data from/to the in-vehicle network, and to use critical resources that are thesecurity-relevant events. The countermeasures are defined interms of policies and inlined with these events. We describethe conceptual model to deploy the method in the followingsection. 5.1 The Transformation Model Important questions here are how and when the securitypolicy defining the corresponding countermeasure will beembedded into the code. This subsection presents a commonmodel for the two different vehicle software architectures. Asmentioned, vehicle applications are downloaded through thevehicle wireless gateway and guaranteed authenticity andintegrity by a secure download protocol. In our model, anadditional transformation module is placed at the gateway asa middle step of a software installation or updating, i.e., afterthe software is downloaded and before it is installed/updatedto the particular platform. The transformation modulereceives the downloaded software and transforms it to a newversion that adheres countermeasures in terms of securitypolicies. We assume that the security policies are defined atthe vehicle manufacturer and included in the transformationmodule. Thus, in this model, the policy-inlined firmware andsoftware woven with a set of countermeasures could preventvarious attacks. The model is illustrated in Fig. 2.Fig 2. The transformation procedure. 5.2 Realisation Since there are two categories of vehicle software, thetransformation is implemented differently. We present theimplementation possibilities for each architecture as follows. //here to import OSGi libraries import Global.PolicyHandler;  public   aspect ApplicationStart{  pointcut startApp(BundleContext context): execution (*BundleActivator+.start(BundleContext)) && args (context);  before (BundleContext context): startApp(context){PolicyHandler.monitor(context);}}  Listing 1. Put a starting application under the control of thepolicy handler. downloadingmoduletransformationmoduleinstallation/ updatingmodulesoftwaredownloaded fromexternal network downloadedsoftwaremodified softwareinject definedpoliciesinstall/updatethe software tothe in-vehiclesystemWireless gateway at the vehicle  a) Transformation for Add-on Software : As shown in ourprevious work [16], various sorts of security policies can bedefined and enforced in an open system like the OSGiframework using an aspect-oriented language [17]. In thiswork, we use a similar method to implement the proposedcountermeasures in terms of policy enforcement. Sinceapplications in vehicle software architecture are developed inJava and distributed in Java bytecode, an appropriate tool totransform such distribution is AspectJ language. AspectJ is an“industrial strength” aspect-oriented programming (AOP)language [17] that can provide programmatic means tomodularise crosscutting functionalities of complex softwaresystems so that program concerns in a software system can becaptured and encapsulated into so-called aspects. AspectJ is alanguage that extends the Java programming language andimplements the paradigm of AOP. The transformation modulefor add-on software uses the AspectJ weaver tool to modifythe downloaded software and embed aspects defined inAspectJ language to implement the proposedcountermeasures. Listing 1 gives a transformation examplethat a starting application in OSGi is monitored andcontrolled by a global policy handler (class PolicyHandler ) as designed in Section 4.1. Listing 2illustrates the definition of a policy implementing acountermeasure against unauthorised read events as shown inthe countermeasure table (Table 1). If the application reads anunauthorised message from the OS, the action will besuppressed. MessageControl in Listing 2 is a part of theglobal policy handler installed in advance in the OSGiframework. The handler is a part of the global library in theframework responsible for monitoring the execution of add-on software. For space reasons, we omit illustrationsimplementing the handler and other countermeasuresproposed in Table 1. Practical issues such as how to install alibrary is described in [16]. In conclusion, AspectJ couldprovide a complete and robust tool to modify add-on softwarefor vehicle systems such that the software adhere appropriatepolicies to prevent potential threats. In this work, we use theOSGi framework as a platform for add-on software thatsupports downloading of software from third parties. Thepolicies we have illustrated are defined in AspectJ and can bewoven into the Java bytecode, which is provided by a thirdparty provider, by the transformation module in the wirelessgateway. The modified software can then be installed to avehicle and executed properly. Ideally, the vehiclemanufacturers should define relevant policies since they arethe only ones who know the intended functionality of theapplication. In that sense, the nature and the functionality of the application should be analysed by the vehiclemanufacturer in order to define meaningful policies. Forexample, third party applications should not be allowed tointeract with safety critical in-vehicle components, as studiedin our previous work [18].b) Transformation for ECU Firmware : We discuss a similarmodel and propose a solution for the ECU firmware scenario.The major difference is that the add-on software is run in amiddleware, e.g., the OSGi framework and an underlying OSthat can handle policy enforcement, and the ECU firmware isrun directly on ECU itself. There exists no inherent supportfor transformation for ECU firmware.First, a platform like OSGi for ECU firmware should beprovided such that the firmware is run on some form of middleware running on an OS. Future directions for ECUdevelopment might include more powerful hardware that runsome form of lightweight OS and combine several ECUfunctionality to one single software. In this future scenario,the ECU firmware could be inlined with security policies.In addition, ECU firmware is typically developed in nesC orC, and thus aspect-oriented solutions for these programminglanguages could be used in order to apply our transformationmethod to implement the countermeasures. Recent researchprojects, such as Aspect nesC [19], ACC [20], have providedaspect-oriented solutions for nesC and C; however, they donot focus on security policy enforcement. Providing a securitypolicy enforcement mechanism for such languages using anaspect-oriented approach is a sensible solution for applyingour model.Moreover, the cost of using several ECU hardware could belowered if the ECUs are replaced with a more powerfulhardware providing a combined software solution. As seen inother areas, hardware solutions have incrementally beenreplaced with more advanced software solutions, and thevehicle software systems might follow the same path. 6 Conclusion and future work We have presented a model to deploy a reference monitorapproach for vehicle applications for monitoring theirexecution to enable safety and security. We distinguishbetween add-on software and ECU firmware and develop athreat model for each category. For each threat we describe acorresponding countermeasure that can be implemented as asecurity policy. We show a few examples of how to definesuch policies in AspectJ.Add-on software and ECU firmware are treated differentlydue to the nature of their application. Add-on software is runon a software framework on an underlying operating systemand is not allowed to interact with safety-critical vehicle // Global.MessageControl has been imported   pointcut Read(String message): call (* args (message); void around (String message): Read(message){ //check the content of the message if (MessageControl.check(message)){ //in authorised list, process normally  return proceed ();}else{ //the message violate the policy, log it Log.logging(“Unauthorised message:”+message); //do nothing here means suppress the event }}  Listing 2. Policy against unauthorised read events.
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks