Cloud-based security platform: How to protect the connected car from hacker attacks
The demand for digital services in vehicles is continually rising. Gartner Research expects that as early as 2016, the availability of intelligent, network-based services for telematics and infotainment will play a decisive role in the purchasing process. Just like for all internet-based applications, security is key. In the case of a vehicle, this includes protection from manipulating and overcoming digitally controlled theft protection systems, but also the guarantee that access credentials used for internet-based services cannot be stolen by hackers. At the same time, the required security measures must be designed in a way that they don’t distract or annoy vehicle owners. In this context, it does not matter whether the access is realized via mobile device or embedded systems (antenna-based).
The basis for integrating and protecting digital services is a secure ICT network platform which includes robust frameworks for connectivity, identity management and security. These security tools prevent unauthorized access to the vehicle’s IT and guarantee secure communication between OEMs, customers and service providers. In addition, they allow for secure, automated and user-friendly provisioning and de-provisioning of unique digital identities, which is especially important with regard to later changes in vehicle ownership. What’s more, an ideal network platform also enables easy and fast software updates for in-vehicle IT systems as well as secure access to cloud services. (Graphic 1)
Fig. 1.
Closing loopholes
The in-vehicle network of today’s cars only offers limited protection from unauthorized access. This is due to the heterogeneity of the applied systems and the great number of suppliers. For example, the on-board diagnosis interface is a gateway for unauthorized access to the digital controls of the vehicle electronics. Connecting the vehicle to the internet makes it easy for hackers to exploit these given vulnerabilities, no matter if the connection is realized via in-built devices or via wireless interfaces to mobile devices. Thus far, researchers have demonstrated multiple times how easy it can be for internet criminals to manipulate or steal data by means of exploiting weaknesses in SMS, Bluetooth or mobile operating systems like Android. One of the weak points of conventional point-to-point connections lies within the data streams, that are flowing between the vehicle and other devices, but outside of network boundaries. If the whole security architecture is being implemented within a single communication network, the vehicle is vulnerable as soon as one associated network component has a weak spot.
Although a commonly used transmission type such as Bluetooth for instance does offer flexible encryption of the communication between two devices, it suffers from the fact that the related master key can be uncovered fairly easily. The smartphone operating system Android on the other hand doesn’t even offer hardware-based encryption and is thus a high security risk not only if insecure passwords are being used, but also because malicious code can be injected by manipulated apps without much effort. That way, VPN connections believed to be secure can be hijacked by hackers and passwords of sensitive applications can be stolen. Below the line, the security of the connected vehicle depends crucially on the security profile of each single component within the vehicle network. Trying to secure all of the many weak spots in such a system is essentially hopeless.
Risk-based authentication
A secure network platform is based on a comprehensive security and identity management for the vehicle, but also goes beyond. To achieve that, implementing risk-based authentication using a set of different tools is vital. This includes pairing the various identities of vehicle applications, users or mobile devices with their digital counterparts. The platform enables car owners to create accounts and registrations as well as restoring passwords and digital identities. In practical terms, this means that the authentication solution minimizes risk by coupling all user-related information with the respective data provided through the system, such as vehicle identification number or access rights. This guarantees that only authorized users are allowed to access and operate specific applications and services. Depending on the desired level of security, rules can be set that govern for which user-initiated requests risk-based authentication is required. Again, the network platform comes into play: the rules can be defined centrally and don’t have to be adjusted and implemented for each single application or device. Besides minimizing cost and effort, this central administration also eliminates possible problems and errors associated with setup.
The applied encryption technology can be based on SAML (Security Assertion Markup Language) for example. SAML is a XML framework by the OASIS consortium, which is especially popular for securing web services and which supports single sign-on procedures. The information needed for secure authentication is hereby being exchanged between user and service. Another protocol option is OAuth, a younger relative of the well-established OpenID approach, which – in contrast to OpenID – allows for centralized data exchange and authentication processes. Such a self-authenticating encryption applies to all vehicle components and is able to assign unique security features for each individual vehicle via PKI (Public Key Infrastructure). Within such a system, all information in the network is digitally signed and encrypted. To authenticate, users need a digital certificate. The longer and more complex the encryption key, the more bothersome and difficult it is for hackers to break the encryption.
Secure access via tokens
A Security Token Service (STS) functions as the basis for all security components that govern interaction with the vehicle. The service creates encrypted tokens that can only be decrypted by the associated/related vehicle. This is being achieved through PKI: a pair of keys, one of them being a public key, is assigned to each individual vehicle. The STS can access the public key and will use it to create an encrypted Token for each requested interaction. Thus, only the vehicle is able to decrypt the token and determine the associated task. Since a new token is being created for each single interaction, it is possible to fine-tune the type and scope of each interaction with the vehicle. The Head Unit Token Service receives the incoming token via the vehicle’s network connection and conducts the defined security checks. If the security token cannot be identified with the help of the private key, it is considered to have been faked. Being able to validate the sender of a token enables a better control of the services because different token services are being used for different applications. This way, the in-vehicle Security Token Service can determine whether or not the requesting service has the required security level and is thus eligible to initiate the task in question. If this is true, then the task will be processed by addressing the appropriate interface. (Graphic 2)
Fig. 2. For full resolution click here.
Summary
A central network platform not only prevents unauthorized access to the vehicle, but also secures personal information and avoids service outages. Risk-based authentication evades issues associated with the setup and deletion of components and services. In addition, it realizes secure access to cloud-based services from within the vehicle. At the heart lies a Token Service that uses PKI encryption and security methods like out-of-band to enable secure registration and usage of internet services via both, cell connection or antenna. Being a cloud service itself, the central network platform is easy to implement, cost-transparent and can be operated in the most flexible ways.
Info boxes:
Token functionality: an example
The driver seeks to setup his smartphone as an access point for interacting with in-vehicle services. To do so, the device must be paired with the security framework so that only this registered mobile device is able to successfully request a token. In order to register, the car owner accesses the registration service via his personal computer. The reason is that by separating the initial authentication setup from the device for which it is meant (here: smartphone), hackers cannot compromise the setup process. This procedure is called out-of-band method. In the next step, the user authenticates himself using the credentials he provided during the initial setup. The Security Token Service then sends an out-of-band registration code to the smartphone that is going to be registered. Normally, this happens via SMS text, but can also be achieved by phone call. The user can now unlock his smartphone using the one-time registration code he just received. This code is then being stored together with the user credentials and the physical ID of the smartphone so that this information is readily available for later device authentications. Ultimately, the driver needs to authenticate once more to make sure the registration process was indeed initiated by himself.
|
How the car becomes intelligent The connected vehicle offer almost unlimited possibilities. They include safety features such as automatic SOS calls in case of breakdowns or accidents, vehicle retrieval via GPS and anti-theft technologies like remote vehicle slowdown. Maintenance functions which are already available today can help determine the best time for oil changes or V-belt replacements based on up-to-date data from the vehicle. Comfort-oriented services for task planning, e-mail and related services based on speech-recognition turn the vehicle into a rolling office. Internet applications like social network services are also entering the passenger compartment. In some industries like logistics, an internet-enabled vehicle can even be a business-critical solution. Thanks to constant data exchange with the headquarters or originators, driving routes can be adjusted in real-time helping to raise the fleet’s load factors. |
About the author: David Miller is Chief Security Officer, Covisint
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
