On 20 June, 2016 Connected Car News published an article by Jay Coley of Akami, titled: “Closing Connected Car Vulnerabilities Quickly and Reliably – via the cloud”.
This article raises good points about the advantages of a cloud based OTA solution compared to dedicated servers. Of particular note is the reference to DDoS (Distributed Denial of Services) attacks, a risk scenario that should be on the viewscreen for auto-makers and automotive system OEMs, even if it has not been a point of failure in recent news stories about the vulnerabilities of automotive electronics systems.
But the title of the article makes a promise – and the content of the article does not deliver on that promise.
For the reader interested in understanding how to approach “Closing connected car vulnerabilities quickly and reliably,” the solution is not TCP optimization or edge caching in the cloud. Suggesting that it is demonstrates one of the fundamental challenges that tech sector companies have in bringing products and services to the automotive market.
When the issue is closing connected car vulnerabilities, “quickly” is of less concern … in particular the relative speed of the network topology is of almost no concern. The paramount concern is “reliably”. In the automotive field it may take weeks, or months, to develop and verify a fully reliable update. Saving seconds, minutes, or even hours on the network distribution of that solution is inconsequential. To help car makers do a quick update, help them get their reliability right, and we save them weeks, not seconds.
Connected car vulnerabilities are many. The article mentions a few:
“…their connection to the Internet can make them vulnerable to hacking. … and numerous news stories about … opening doors and sunroofs, switching off the engine or turning off the screens, even while driving, are just some examples of things that can be accomplished by exploiting communication weaknesses.”
Gulp.
It then goes on:
“Once detected, these security vulnerabilities must be solved as soon as possible using software updates and patches provided by the car makers …”
Let’s stop here. Why? Because this is where the writer loses the readers. This is where the “Silicon Valley” value set disconnects from the “Detroit” audience.
The tech sector is obsessed with speed. Technical speed. Processor speed. Bus speed. Network speed. Everything needs to be faster, quicker, instant. My topology saves 12 seconds versus his topology.
We should not boast of how we will resolve vulnerabilities “as soon as possible” by “using software updates and patches provided by the car makers”.
Ask a car maker or automotive system OEM, and the burning question is not “How do we get the software updates and patches to the car as soon as possible?” The burning question is “How do we ensure the reliability of software updates and patches?” We should not just assume that question away.
To contribute from the network side, we should focus on “How do we ensure the integrity of content and the reliability of its distribution?” That provides the auto maker with at least a part of a solution to their real concerns.
When it is a question of hundreds of thousands, or even millions, of vehicles that are already on the road, the focus needs to be on providing a more reliable update. If it takes an extra hour, or a day, or even a week to roll out that update, we are still answering the right concern. If we reduce the time of the roll-out to minutes or seconds, but do nothing to enhance the reliability of the update, we are answering the wrong concern. In fact there are lines of reasoning that suggest it might be better to take a week to roll-out a significant update to automotive systems.
A case example of this issue was reported earlier this month, when Lexus released an update to their head-end unit software that caused faulty operation in about half of the cars receiving the upgrade (see the story, dated June 8, 2016: https://www.bbc.com/news/technology-36478641 ). We must ask ourselves, seriously, would Lexus have benefited from a technical solution to speed the roll-out process from 12 hours to 12 minutes? To 12 seconds?
The DNA of the tech sector is different from the DNA of the automotive sector. Successful solutions to the vulnerabilities of connected cars will require a blending of DNAs, a merging of cultural values. Tech firms that just promote their own priorities and values to the automotive market may find their messages bounce.
PERMANENT FAILURE: message undeliverable
Guys, tune in. It isn’t about how quickly the auto maker can do upgrades. It’s about how reliably the auto maker can do upgrades.
Closing connected car vulnerabilities will require a total system architectural approach, which takes into account hardware in the vehicle, services in the cloud, qualification of apps, sources of data, and mechanisms of rolling out updates to vehicles.
Cloud-based OTA can be a part of the solution. TCP optimization and edge caching might even be a part of the solution. But we need be working together on the whole solution, not claiming our little portion will fix things by being fast. Or faster. Or fastest.
Leave a Comment