Intel sets team on thwarting car hackers

[raymond]

From a distance it looks like the computer that runs the browser on the center console is able to control quite a large part of the car. Setting up a malware web page that triggers a bug in the Model S browser, just how much damage can be caused?

If TM can update the car's firmware over the air, wouldn't it be nice / reassuring to know just how they have secured that function so that really only TM can do that?

See also: Intel sets team on thwarting car hackers

 

[dtich]

oh this is a MUST. i assume that there is strong encryption and enterprise/international banking style handshaking on this stuff. firmware needs to be signed, hashes and checksums, all that. likewise the link with handheld apps. this is not something that can be halfway. these control and update channels must be locked up tight. no hacking my car please and thankyou. not even a question.

 

[raymond]

It is a must, absolutely! But my experience is that it is very easy to get your encryption, checksumming, handshaking, etc, wrong. The chain is as weak as its weakest link.

Who would have thought a few years ago that even with a proper firewall a hacker could force entry by triggering a buffer overflow bug in a JPEG library?

It is hard (but possible) to get everything right, but potentially disastrous (for my stock position in TSLA) to get it wrong.

Shouldn't car manufacturers hire people to the both black and white box testing? (No, I'm not in that business...)

 

[nrcooled]

Shouldn't car manufacturers hire people to the both black and white box testing? (No, I'm not in that business...)

I am in that business and they should!

The easy way to do this would be to create a central authenticated server that Tesla controls. Setup a local DNS lookup table that only allows the Model S to connect to it through a designated and secured port for updates. Establish a secure connection using a "VPN-like" solution w/ an encrypted tunnel and only pass signed packets with a simple key algorithym.

My solution is a wrapper and a half solution that would eliminate/thwart a lot a potential attacks. It isn't fool-proof though and is still vulnerable based upon how the VPN-like solution exchanges keys.

 

[dtich]

exactly.

 

[smorgasbord]

Who would have thought a few years ago that even with a proper firewall a hacker could force entry by triggering a buffer overflow bug in a JPEG library?

My previous company spent a lot of engineering time and effort at least a decade ago detecting and then prevent buffer overflows in its pretty wildly used products. I suspect they still do.

Tesla needs to understand the potential risks first. One obvious thing is protecting Model S from using firmware not provided by Tesla. A public-private signing/encryption key pair is probably a good secure choice there (sign with private key, verify with public), but that can't be the end. Tesla also wants to protect its firmware from being reverse engineered and then used to figure out either other potential hacks on Model S or the theft of trade secrets on how the car works. That means that "public" decryption keys really can't be public. As we saw with the DVD (CSS) and Blu-Ray (AACS) exploits, that's harder to accomplish.

It's interesting that what happened with DVDs and Blu-Rays was not that any algorithm was hacked, it was that the decryption keys were stolen. On a PC, it's literally impossible to completely protect decrypted decryption keys from being stolen (see http://en.wikipedia.org/wiki/Security_of_Advanced_Access_Content_System for instance). Those are easier to protect in closed systems like a car. And, even if the keys do get stolen, since Model S is a relatively small closed system, Tesla could always issue a recall to load new keys and load firmware to disregard firmware encrypted with the old keys - that's something that was impractical for DVD players.

Like I said, a security risk analysis needs to be performed. For instance, rather than hacking the firmware, I would expect that the first attempts will be made on any mobile phone software Tesla ships that lets people control their cars remotely. That's almost certainly an easier platform on which to monitor what's being transmitted and what is being used to encode/decode and authenticate those transmissions than getting a hold of a Model S and tapping into its hardware.

That all said, I'd be surprised if Tesla wasn't on top of all this.

BTW, as real security experts can probably tell, I'm not an expert on cyber security.

 

[RubberToe]

Anything that can be hacked, will be hacked... eventually. I would bet anyone on this forum that within 2 years of delivering the first Model S, that someone figures out how to completely replace the entire operating system of the car with their own version. I would not be surprised to see it happen sooner than that even. That's cracking open their own vehicle and making the modifications. Breaking into someone else's vehicle remotely and causing havoc is another level of complexity entirely.

Look up cyanogenmod for one example of how the original operating system for various Android phones gets removed and replaced with a version that is much more powerful. It would take an awful lot to convince me that the Tesla software developers are smarter than the Google software developers WRT locking things down...

RT

 

[smorgasbord]

It would take an awful lot to convince me that the Tesla software developers are smarter than the Google software developers WRT locking things down...

It's not as much a question of smarts as it is a question of access. Android phones can load all sorts of user-written applications that can test the operating system and extract information. Cars do not. It's a lot harder to get something on the car that will help you figure out what's going on.

The original proposed risk was that someone would put a trojan on a web page that's likely to be visited from within the car. If possible, then maybe that trojan could wreak havoc with the car, even if it only has access to the CAN bus. Another risk is that since Tesla can update firmware wirelessly, that trojan would download new firmware onto the car from a hacker's site instead of Tesla and that could do even more damage.

Figuring out how to do those things is a lot easier on a phone with apps you can write than it is on a car with embedded hardware. Other aspects are that the target audience is small (look at PC versus Mac attacks) and the benefits to the hacker are minimal (e.g., bragging rights).

 

[RubberToe]

It's not as much a question of smarts as it is a question of access. Android phones can load all sorts of user-written applications that can test the operating system and extract information. Cars do not. It's a lot harder to get something on the car that will help you figure out what's going on....

Figuring out how to do those things is a lot easier on a phone with apps you can write than it is on a car with embedded hardware. Other aspects are that the target audience is small (look at PC versus Mac attacks) and the benefits to the hacker are minimal (e.g., bragging rights).

Smorgas,
I would agree with the latter part, but point out that bragging rights is what hackers live for. Being able to customize the battery draw/charge code could yield better performance, which would be pretty big bragging rights. Concerning the first part, at the lowest level (i.e. the *first* code that runs after booting up the cars computer, or after installing a new SW release), the most secure code in the system would be stored on a EEPROM chip of some kind. First order of business is taking that chip off and connecting it to a device that allows it to be read out. You then have native assembly code for the processor that is then likely used to load up the remaining software that actually controls the cars functions. Of course, that can be encrypted too.

I wouldn't be surprised to find out that once the cars main computer "boots up", it remains running at some level at all times. So turning off your car might actually only put the computer into the equivalent of say a Windows "sleep" mode. That keeps power consumption to an absolute minimum, while still allowing you to "start" your car in a reasonable amount of time, unlike booting up your computer :smile: It is no doubt running an RTOS like vxWorks or Posix. They use Posix on the SpaceX vehicles, so maybe they use the same OS on the Model S. It would save development costs.

RT