Today’s vehicles provide amazing capabilities to create a true “connected vehicle” delivering an exciting frontier

of opportunities for automakers, drivers, and entrepreneurs. With these opportunities comes significant risk from

hackers and other malicious threats. Relying on device managed security via machine-to-machine has proven

insufficient. Only a centralized Secure Network Platform can deliver a successful connected vehicle experience.

A secure network platform prevents unauthorized intrusion to the vehicle, protects personal and private informa-

tion, prevents denial of service attacks, avoids provision and de-provisioning complications, and improves user

experience of access multiple cloud-based services from the vehicle. Covisint introduces such a needed platform.

Creating a SeCure ConneCted VehiCle

4

Cover Story NeTWORkiNg

Situation

On average, drivers can spend between one and a half to two hours each day in their cars. With this “down” time and the growth in use of the mobile internet, driv-ers expect to be able to connect to vital personal and business services at any time during their commute. According to Thilo Koslowski from Gartner Research, “By 2016 the majority of average car buy-ers for a standard (volume) brand vehicle will expect at least basic web-based infor-mation availability in their next new auto-mobiles.” This demand has driven auto-makers to rapidly increase their offerings with respect to infotainment and telemat-ics. While these features and capabilities are exciting, they also enable the vehicle to be digitally attacked by “hackers” and other malicious threats.

threat Profile: Mobile DeviCe to vehiCle

The modern vehicle now has an extensive number of ECUs (Electronic Control Units) that are managed through one or more shared internal network buses. There exists only rudimentary network security protection within the vehicle due to inter-operability requirements, multi-supplier environments, and the vehicle develop-ment life cycle. It is therefore quite easy to gain unwarranted access to these ECUs through sniffing and fuzzing mobile device traffic into the vehicle. Additionally, the Onboard Diagnostics (OBD II) port under

the dash in virtually all vehicles provides a direct and standard access to the inter-nal vehicle networks, ❶. The proliferation of applications and devices that have access to the internal vehicle network greatly increases the probably of mali-cious attacks.

Machine-to-machine (M2M) communi-cation technologies that are utilized to allow devices to communicate directly with each other create another significant threat profile. The key transport mecha-nism for M2M communication is SMS due to GSM networks and its relatively low cost. Security experts such as Don Bailey from iSEC partners have demonstrated its possible to take control of vehicle func-tions such as door unlock, and remote start through SMS. To prevent these kinds of attacks, further security and encryption must be implemented adding significant cost and complexity to vehicle systems developers. These designs often require new processors, more system memory, and more code that must run concurrently with the host application. Furthermore the application itself must be rewritten, tested, and deployed.

Bluetooth is a very popular and useful integration technique linking two devices through the use of pre-shared key authen-tication and encryption. The strength of Bluetooth security protocol lies with the length and randomness of the passkey. Its weakness lies in the discoverability and connectability settings. There have been many documented attacks involving iden-tity detection, location tracking, denial of

tiMothy r. evavolDis Director Solution Delivery Partners

at Covisint in Detroit (USA).

DaviD Milleris Chief Security Officer

at Covisint in Detroit (USA).

AUTHORS

❶ Threat profile: mobile device to vehicle

506i2011 Volume 6

service, and unauthorized control and access of data and voice channels.

Another significant threat profile is the mobile applications that are granted access to the vehicle. As Android has become the second most popular mobile OS, its appli-cations pose the greatest risk at the current time. Android applications utilize flimsy passwords creating an easy access path for hackers to steal broadband and abus-ing VPN connections. There is no hard-ware data encryption, so if the automaker is relying on the device to protect person-ally identifiable data, they are at risk. Android’s popularity and openness is drawing hackers creating SMShing threats which are the text version of phishing. The most concerning security risk is the creation of repackaged and fraudulent apps. A repackaged app is where a legitimate application is taken, reverse engineered to identify the security and identity tokens and then creating a malicious application that uses these tokens to represent itself.

threat Profile: vehiCle to internet

As with the utilization of the traditional web, utilization of the mobile web via the vehicle presents many potential con-fidentiality threats. A primary concern is exposure to confidential or personally identifiable information. Exposure threats are present wherever this data is intercepted, whether at the source, desti-nation, or any intermediate node in the network, ❷. Sometimes not only is the

message sensitive, but the fact that the message even exists can also be sensi-tive. Unwarranted traffic analysis can occur creating unwanted knowledge of transactions, traffic, or utilization that can be used in harmful ways.

Integrity threats occur when every piece of data does not remain consistent with the manner in which it was sent by the source. Applications consume mes-sages with an implicit trust paradigm. This paradigm is taken advantage of by hackers by falsifying, or tampering with message content. Examples include: changing some/all of the message con-tent, replacing message entirely, replaying old messages, combining pieces of mes-sages, redirecting messages, and destroy-ing messages.

Denial of service attacks are also a major risk within an insecure connected vehicle environment. This is not only denial of service for the vehicle applica-tions, but more importantly turning the vehicle into a tool to create denial of serv-ice attacks on external entities.

PaSt aPProaCheS

To-date the approach to securing the connected vehicle has been to create point-to-point secure connections between applications and devices relying on the strength of each individual component’s security profile. As we’ve seen the inter-nal vehicle network is inherently insecure due to its ubiquitous access and light security profiles. The network connectiv-

ity may be fairly secure, but the traffic and message content can be broken. Lastly, each application whether it’s an in-vehicle app, or mobile web app, has a unique security approach delivering varying cap-abilities. This creates a very fragile secu-rity environment where malicious threats can enter from many points.

SeCure network PlatforM

To resolve the fragility of the complex connected car security environment, a secure network platform is required. This type of security platform offers compre-hensive security and identity management to and from the vehicle. The secure net-work platform provides authentication services which directly bind an identity (e.g., user, mobile device, vehicle, applica-tion) to their digital identity and then pro-vides the identity with a specific security token, ❸. The platform provides self-serv-ice features for obtaining a forgotten ID or creating a new password if the user has forgotten their password. The user can use this platform to register for an account, register a device (e.g., mobile phone) and check on their registration status.

A robust secure network platform will provide a risk-based authentication solu-tion. Risk-based authentication is an authentication approach that utilizes both user provided (e.g., user name) and sys-tem collected information (e.g., IP address, MAC, PID, VIN, GPS, etc.) to authenticate the user’s request to access/perform the protected target resources/applications. Risk-based authentication assessments occur at initial login or at time of federa-tion. They can also be performed each time a user requests access to resources or conducts transactions that require a higher level of protection. The rules that govern these authentications can be changed cen-trally in the secure network platform obvi-ating the need to deploy the rules to each consuming application or device. This sig-nificantly reduces costs and implementa-tion time, but it also provides a future proof platform for dealing with the rapidly changing and regional legal landscape. The following are a sample list of risk cri-teria: IdP trust level (the pre-specified authorized trust level for that Id), regis-tered device (computer, mobile device), registered network, time of day, GPS loca-tion, vehicular activity, time lapse since ❷ Threat profile: vehicle to internet

Cover Story NeTWORkiNg

6

DO

I: 10

.136

5/s3

8314

-011

-005

6-z

last access, high frequency of access, repetitive access, first-time login.

At the heart of the secure network plat-form is the secure token service. It is the hackers objective to “own” a device or identity, that is to take control of it. As such they seek to obtain information from the vehicle, device, or intercepting com-munications between devices in such a way to impersonate the identity. If all of the security takes place on the device (or vehicle), the vehicle is vulnerable due to the weaknesses mentioned earlier. If all of the security takes place on the network, then the vehicle is left vulnerable if the network is compromised (e.g., fuzzing, sniffing etc.). When a centralized secure

token service is utilized to secure the device/vehicle, each time access or action is requested, both token and the network have to be compromised to breech secu-rity. This makes hacking into the con-nected vehicle very difficult.

The type of token utilized could be a SAML format or it could utilize the new emerging OAUTH protocol. Security Asser-tion Markup Language (SAML) is an XML-based open standard for exchanging authentication security between an inden-tify provider and a service provider. Open Authorization (OAUTH) is an open stand-ard for authorization that allows users to share their private resources stored on one site with another site without having

to provide their credentials. The protocol selected is secondary to the technique used to manage the secure interaction. The use of a self authenticating token is what makes the token service as robust as it is. The components in the vehicle do very little provisioning, therefore they can support many different use cases without having to change (i.e., re-flash the ECU, or OBD modules). The secure token serv-ice has the ability to determine what cap -abilities are supported for both the driver and the car. It then uses a PKI encryption service to create a token that can only be read by the car. This type of architecture makes it very difficult for an external party to hack into the system.

❸ This use case is for when the driver wants to use his phone to either act on or retrieve data from the vehicle (remotely)

1. Driver access the phone. In most cases this is seen as running an application on the phone. This application will then provide all of the functional access.2. The application needs to authenticate. This authentication will require the phones PID at the least. In the case that the action requires a more secure interaction (unlock doors), then the user may have to provide his credential also.3. Once the driver/device is authenticated, the STS will look up the vehicle certificate and then provide the device with a secure token that can be used to initiate the action.4. The phone will then provide the token to the OEM back office service. This service can double check the signature of the token and audit the access. This step is required because the assumption is that for embedded vehicles, the network service to the vehicle would be managed by the OEM.5. The last step is to pass the token along to the cell phone network to be consumed by the vehicle. The vehicle at this point would follow the process outlined in the component description above.

706i2011 Volume 6