Carvoyant applies best practices to protecting data once it lands in our servers.  Additionally, we make it a point to stay abreast of what other parties are doing to protect vehicle data before, and while, it is en-route to Carvoyant.

At this point you can Google “Connected Car Security” or “Connected Car Hacking” and come up with a variety of media posts on the topic.  Naturally, by the time main stream media is touting the dangers of a topic, those deep in the space have been thinking about that topic for a while.  This is most certainly the case when is comes to connected car security.

We will set aside the debate of someone pursuing harm digitally when they could more easily spray nails across the freeway to cause harm.

Carvoyant’s CTO, Matt Galvin, exchanged in a dialogue on ars technica, which the full string can be found here.  The abbreviated summary is what follows.

In terms of aftermarket OBD dongles getting vehicles on the internet, most have very similar (ie, missing) security features. They rely on the security of the cellular network and the presumption that it’s hard to reverse engineer their firmware files. Clearly this provides very little true security. These device makers chose to limit their security features in exchange for simpler hardware and a smaller network traffic footprint.

There have been several hacks documented over the past few months; some very publicly. In all cases the demonstrated attacks required either physical access to the device (to effectively “sideload” the custom firmware through a serial port) or a cell interrupter. Both vectors are pretty easily exploited given the right circumstance. That said, it’s FAR easier to gain access to the vehicle through the bluetooth interfaces exposed through most vehicles’ infotainment systems. The vast majority of OEM bluetooth systems are not isolated from the vehicle CANBus. So an exploit through the bluetooth layer can gain direct access to vehicle controls. In fact, there was a proof of concept attack a few years ago that allowed a laptop outside of the vehicle, with no previous access, to engage the brakes on a vehicle while it was driving. The industry has had bluetooth support in some capacity for at least a decade. The “Carpacolypse” has yet to arrive. The point here is not to excuse the poor security provided by the hardware manufacturers. The point is to simply highlight that if someone wanted to wreak havoc there are far easier ways to do it. In all likelihood the security decisions made by many device manufacturers are based on that idea.

Carvoyant recently began working with another device manufacturer named Velio.  Velio has not made the same security decisions. All traffic to and from their device is encrypted and firmware files are signed. This probably is not impossible to hack, but it’s certainly harder than the other devices. So there are some companies out there interested in approaching security as a core part of the build.

 According to National Insurance Crime Bureau a vehicle is stolen in the US every 33 seconds! Therefore, we are all more likely to see the activity on the left happening rather than on the right in the above picture.
Unfortunately, until the end consumer starts demanding improved security, and is willing to pay for the expense of adding it, very little is going to change. It really boils down to the risk/return question and given the ease of other attacks against a vehicle every consumer we’ve spoken to has been accepting of the current risk levels.

As a result we will continue to remain nimble for the best mix of price and functionality in the devices we engage so our clients can meet their client demands with the best suite of functions – security included.

Again, if you want to read the full ars technia article and string of comments click here.  As always, feel free to review Carvoyant’s API Documentation and get started with a free sandbox developer account TODAY!