The automobile industry is poised for its first technological revolution. Unlike any previous automotive advancement, connected car technology will soon change the very purpose of the vehicle. Rather than merely taking us from point A to Point B, vehicles will now be capable of ordering our meals — and paying for them, scheduling their own repairs at the service center, and even communicating with IoT-enabled devices within our homes. But the new generation of automobiles come with some potentially deadly cargo: the potential for connected car hacking.
Industry forecasts estimate that more than 150 million connected cars will be on the road by 2020. As automakers roll out the new generation of Internet-enabled vehicles, connected car cyber security is among their chief concerns. And rightly so. As we have seen, no personal computer, no mobile device, no corporate network, and no government agency is immune from cyber attack. What makes us expect connected vehicles will be any more secure? Technology-wise, they aren’t. If anything, the sheer newness of connected car technology makes such systems more vulnerable now than they will ever be.
To meet the challenges of automotive cyber security, automakers are partnering with OEM vendors and 3rd party developers to address the issues. As with any technology still in its infancy, requirements for connected car OEM platforms and smartphone applications are rapidly evolving. In this article we will explore five requirements that developers must be prepared to meet in order to penetrate this lucrative new market.
Bluetooth Hardening
The prevalence of Bluetooth connectivity, even before vehicles had onboard IoT systems, makes it a prime target for cyber criminals. Hackers already understand Bluetooth, and they know how to exploit its vulnerabilities. With each version increment comes both advances and compromises, with security often taking back seat to speed, reduced power, and other features.
Take the newest version, 5.0, for example. It offers twice the speed and four times the range of V4.2. That’s good for expanded functionality and improved performance, but bad for security. Unlike earlier versions, which were designed to be slow, short-range data channels, the new version will extend the range at which a hacker can access the device, and allow them to transfer malicious code, or download private data, faster than ever.
The increased speed and range of Bluetooth 5.0, and a broadcast capacity boost of 800%, put it in direct competition with WiFi technology for connecting IoT devices in the home. Even though many connected vehicles will include their own WiFi hotspot, Bluetooth is certain to dominate car-to-device connections.
The primary risk Bluetooth poses to connected cars is that hackers can use device-to-device connections in order to access deeper connected-car systems. The challenge for developers, then, is to develop a love-hate relationship with Bluetooth. They must use new Bluetooth features and capabilities to empower their applications, while ruthlessly seeking out vulnerabilities and closing them quickly.
For developers wishing to develop Bluetooth applications for the connected car industry, working familiarity with new Bluetooth specifications is not enough. They must know them well enough to be able to close vulnerabilities. Moreover, developing secure applications will also require staying on top of current research into Bluetooth vulnerabilities.
Over the Air (OTA) Updates
Keeping any computerized system secure begins with keeping operating systems and software current. This is no less true for the connected car. Nevertheless, expecting owners to bring their vehicles into the shop for updates is not the way to keep their vehicle IoT/OEM systems updated. Neither is it practical to assume that drivers will download updates and install them on their own. The number of XP machines still in operation prove that isn’t going to happen.
The only feasible way to keep connected vehicle platforms and applications updated is to use Over-the-Air, or OTA technology, where updates are downloaded wirelessly. OTA typically applies to mobile devices, but can also be used to keep connected vehicle systems current. It is quite possible that connected car versions of OTA will emerge as the industry matures — the innovative developer will see opportunity here.
The responsibility to keep their applications updated must be a crucial part of the design process for developers entering the connected car application space. Forced, automatic OTA updates is how they will accomplish this.
Regulatory Compliance
In 2015. the U.S. House passed the Spy Car Act, which compels the National Highway Traffic Safety Administration (NHTSA) to enact rules governing automobile cyber security. The purpose of the bill is to require makers of automobiles sold in the United States to protect connected car data. While the European Parliament has adopted rules that focus more on driver data privacy, the growing number of connected cars will, no doubt, result in more far-reaching legislation by nations around the world.
Regulations aimed at automobile makers will, in turn, affect the acceptance requirements that makers establish for both 3rd party and OEM applications. Developers intending to win automaker acceptance for their applications will keep a keen eye on U.S. and European legislation that speaks to connected car data security.
Data Privacy
Apart from whatever legislation requirements may affect connected car data protection, developers have a responsibility to protect the personal information of persons who use their connected car applications. Consumers are more sensitive than ever to threats that can jeopardize their personal data, and connected car technology must win their confidence if it is to succeed.
Whenever a connected vehicle app requires or allows a user to enter personal information, that information must be protected. Such information includes:
- Personally identifiable information, such as name, address, and phone number
- Account information for connected vehicle cloud-based services
- Banking or other payment information
- Medical information
- Any other information the user could realistically be expected to want to keep private
The best way to keep personal information secure is to not request it, or even allow it to be entered into an app, unless it is necessary for providing the user the particular service they desire. Information that must be accepted should be secured when processed by the app, and encrypted while in transit and when stored at the destination. Ideally, some form of tokenization should be used to private data secure.
Keeping personal data secure while enabling users to access services is a balancing act, to be sure. But for developers wishing to satisfy automakers and their customers, it is an act they must master.
Attack Capture Retention
Attack evidence capture is a concept that is unfamiliar to many developers, for it has had limited applications until now. The concept involves collecting operational data from a system and storing that data for causal analysis in the event of a system failure. Think airline black box for vehicles. Actually, since 2015, all new vehicles sold in the U.S. have been required to have a vehicle Event Data Recorder, or EDR, for recording certain information on vehicle operation. Such information can be used by insurance companies and law enforcement agencies when investigating an accident.
Although the EDR does, indeed, record a great deal of information about the vehicle, including speed, acceleration, and vehicle occupancy, to name a few, it is not our focus. We just wanted you to know it was there.
Evidence capture, as related to connected car software, has one primary purpose: to capture information related to a cyber attack on the vehicle systems or applications. This is important, because when (not if) cyber attacks occur, the response automakers and applications vendors take must include recognizing exactly how the breach occurred so that the vulnerability can be closed quickly. A forensic analysis of all relevant data is the most reliable way to identify how an attack was perpetrated.
The need to retain certain data for this purpose provides two opportunities for the innovative developer:
- Providing applications that include evidence capture as a built-in feature
- Developing stand-alone or OEM-integrated evidence capture solutions
Automakers will show favor to developers whose applications include this capability. Having your application provide the doorway to a full-on attack on the vehicle systems would be bad enough. Worse, still, would be having no traceability for the events that lead to the attack.
A great opportunity exists for developers that can create solutions that can be installed on Smartphone-based telematics platforms, or that can be integrated with OEM platforms. Such a solution might record information related to ongoing data transfers, network traffic, device configuration, and other data that can be used to reconstruct the events that preceded an attack. The data retention period could be minutes or hours, or even days, but does not need to be long-term. Keeping the data store, itself, secure from hackers would be a challenges that would also need to be addressed. The cloud would be an ideal platform for such applications.
How Ignite Can Help?
With the connected car revolution comes not only lucrative opportunities for developers, but also the challenge to defend their applications against cyber attack. Responding to both opportunities and challenges in this new market will require a unique combination of skills, including expertise in automotive technology, IoT, and cyber security. Not all software development firms have what it takes.
That is why technology providers around the world partner with Ignite for their outsource development needs. We have teams of experts working in R&D labs across Europe. We are specialists in automotive technology, Internet of Things, and security of data and networks. If your connected car project needs a developer to bring it to life, and to market, why not contact us today for a no-cost consultation?