A Security Analysis of an In Vehicle Infotainment and App Platform Sahar Mazloomy Mohammad Rezaeirady Aaron Hunter George Mason University George Mason University George Mason University Damon McCoy New York University y Lead co-authors contributed equally to this work Abstract an attacker that has internal access to the Vehicle’s Con- troller Area Network (CAN) bus or can remotely connect There is an increasing trend in the automotive indus- to automotive systems [14, 18, 21, 11, 22, 25, 35]. try towards integrating trusted third-party apps with Despite these risks, the number of external devices that In-Vehicle-Infotainment systems (IVI) via smartphones. are connected to both an automotive system and the In- This integration is typically facilitated by a pair of apps, ternet continues to increase. In particular, there is an one that executes on the smartphone and the other exe- increasing trend towards the integration of smartphones cutes on the IVI which is connected to the Vehicle’s Con- and In-Vehicle-Infotainment systems (IVI) connected to troller Area Network (CAN) bus. Throughout the evolu- the CAN bus. This integration between IVI and smart- tion of these IVI and App platforms, there has been little phone is typically facilitated by a pair of apps, one that public analysis of the security of these protocols and the executes on the smartphone and the other executes on the frameworks that implement these apps on the IVI. This IVI. Currently these app platforms are a closed ecosys- raises the question: to what extent are these apps, proto- tem of trusted third-party developers, but many automo- cols and underlining IVI implementations vulnerable to tive manufactures plan to open up their IVI app platforms an attacker who might gain control of a driver’s smart- to a larger pool of less vetted app developers [27]. The phone? initial app platforms, such as Toyota Entune [5], BMW In this paper, we focus on gaining insights into this ConnectedDrive [4], Cadillac CUE [2], Ford Sync Ap- question by performing a comprehensive security analy- pLink [3], were largely proprietary to a single manu- sis on an IVI system that is included in at least one 2015 facturer and caused issues for developers who needed model vehicle from a major automotive manufacturer. to support large numbers of protocols and legacy sup- This IVI system included vestigial support for the Mir- port. Recently a number of standardized protocols have rorLink protocol which is intentionally disabled but can emerged to enable seamless connectivity between smart- be enabled by updating a single configuration value af- phones and the car infotainment systems, such as An- ter applying a publicly available firmware update that is droid Auto [7], Apple CarPlay [8], GENIVI [6], and Mir- securely signed by the manufacturer. Based on our anal- rorLink [12]. ysis, we document and demonstrate insecurities in the MirrorLink protocol and IVI implementation that could Throughout the evolution of these IVI and app plat- potentially enable an attacker with control of a driver’s forms, there has been little public analysis of the security smartphone to send malicious messages on the vehicle’s of these protocols. This raises the question: to what ex- internal network. tent are these apps, protocols and underlining IVI imple- mentations vulnerable to an attacker who can gain con- trol of a driver’s smartphone? This paper focuses on 1 Introduction gaining insight into this question by performing a me- thodical empirical analysis of the security of a single on Modern automobiles are increasingly controlled by com- the road IVI, along with its corresponding smartphone puterized systems that are directly or indirectly con- App, and communication protocol. Note that the Mirror- nected to the Internet. This in turn, means that automo- Link code on this IVI is vestigial functionality that is dis- biles are potentially vulnerable to attack from adversaries abled by default and there is no indication that the manu- who can gain control of one of these external devices. facturer intended to allow drivers to enable it. However, Previous works have demonstrated cars are vulnerable to MirrorLink can be enabled on this IVI by changing a sin- gle configuration value in a file. We also found evidence 2.1 MirrorLink Protocol Specification that some drivers have likely enabled this functionality 1 and there are instructions online which document how to The MirrorLink standard specifies a protocol that facili- do so. tates the integration of a smartphone to an automotive in- fotainment system. The main goal is to offer the user the Motivation: Recent studies have demonstrated that ability to use her smartphone applications on the larger internal and remote attacks against safety critical au- screen of the infotainment system instead of purchasing tomotive systems are possible. However, this paper a more expensive IVI with built in Internet connectiv- presents, to the best of our knowledge, the first compre- ity and applications. So in this case, for instance, she hensive empirical security analysis of a smartphone to can use her smartphone navigation apps instead of pay- modern IVI app protocol included in at least one 2015 ing extra for a navigation system tied to the car. More- model vehicle from a major automotive manufacturer. over, upgrading an infotainment system is not as easy as This IVI system includes vestigial support for the Mir- a smartphone. This paradigm is based on a client-server rorLink protocol. Though this protocol is disabled by model in which the smartphone acts as a server and the default, it can be enabled by changing a single config- infotainment system is its client. In this model, all of the uration value after a publicly available firmware update applications will run natively on the smartphone, and the that is securely signed by the manufacturer. As part of screen of the smartphone will be replicated on the info- our analysis, we: tainment screen. There are some user interaction meth- ods implemented in the car system such as steering wheel 1. Document and perform a security analysis of the control keys, rotating knobs, touch screen or even voice- MirrorLink protocol standard and how the protocol activated control that enable the head unit to be able to is implemented. send user requests to the smartphone. The MirrorLink server (smartphone) runs the requested applications na- 2. Perform a security analysis of critical parts of the tively and then mirrors the display of the application on IVI MirrorLink app implementation that parse po- the infotainment screen. tentially malicious input from the smartphone using The MirrorLink specification defines connectivity lay- static and dynamic analysis. ers as illustrated in Figure 1. Physical and data link layer: MirrorLink requires at 3. Demonstrate the vulnerabilities in the IVI Mirror- least USB 2.0, because it meets minimum bandwidth re- Link app implementation that can potentially lead quirement and at the same time provides a charging so- to a malicious smartphone causing the IVI to send lution for the mobile device. Among different USB pro- arbitrary CAN massages. files, CDC/NCM was chosen for USB networking. Sup- port for WLAN and Bluetooth is optional. 4. Discuss how these protocols and IVI firmware can Networking and Transport layer: IPv4 is specified for be rearchitected to improve the security of these the networking layer with both UDP and TCP used as systems against potentially malicious smartphones. transport layer protocols. Both the client (IVI) and server (smartphone) must support DHCP for IPv4 addressing. Session and Application layer: The MirrorLink appli- 2 Background cation layer comprises of four basic session layer compo- nents and it utilizes either TCP or UDP sockets to inter- In this section, we provide background on the Mirror- act with these components: (1) UPnP: is used for service Link protocol and the IVI platform integrated into sev- negotiation, advertisement of MirrorLink enabled server eral 2015 and 2016 vehicles currently on the road. The devices and client profiles, as well as control of Mirror- MirrorLink code on this IVI is vestigial functionality that Link server based applications. It uses UDP for broad- is disabled by default, but it can be enabled by changing a casting and advertisement, and TCP for remote applica- single configuration value. We found evidence that some tion control. UPnP is designed to allow networked de- drivers have enabled this functionality and step-by-step vices to seamlessly discover each other using the Simple instructions are available online documenting how to en- Service Discovery Protocol (SSDP) and establish useful able MirrorLink. The IVI also includes several apps, network service connections using a variety of other pro- such as Pandora streaming music and BringGo naviga- tion, that use proprietary protocols. However, given that 1The MirrorLink standard started out as a research project under the most automotive manufacturers are moving away from name of Terminal Mode, which was originally proposed by Nokia [10]. proprietary protocols and towards standardized protocols The Car Connectivity Consortium (CCC) is made up of various auto and electronic manufacturers who have joined together to establish an for future IVI app platforms, we focus on one of these, industry standard for certifying apps and devices that are both safe and MirrorLink, in our study. useful for drivers, called MirrorLink. 2 cates and the attestation mechanisms that are standard- ized by the Trusted Computing Group (TCG). This en- ables the MirrorLink server device to authenticate (or at- test) itself to the MirrorLink client device using a manu- facturer’s certificate, which is included in the DAP mes- sage exchange. The MirrorLink client should have the CA’s public key (in the MirrorLink context, Car Connec- tivity Consortium (CCC) is the certificate authority) to validate the MirrorLink server’s certificate.