Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Hacking the Model S for evil...

This site may earn commission on affiliate links.
Herbys, perhaps this car is not for you. I would be shocked to see Tesla release all the information you are asking for. Has any other car manufacturer done all that?
No other car has the potential to be hacked through a 3G network at any time, and crashed into a tree. There are potential exploits in other cars, but very unlikely to be feasible. Whether they are feasible on the Tesla or not is what I'm asking about, but all the information I have so far says "feasible".
If, based on these concerns, the car is not for me, then it is not for anyone, sorry. I'm not particularly paranoid, but if a car manufacturer is the first to introduce capabilities that make it feasible for the car to be hijacked remotely and driven into a ditch, it's not the geek or the paranoid that need to be scared. If said car manufacturers has taken these issues into consideration and implemented the necessary countermeasures, then they should say it. Just to be sure I'm not paranoid, I showed the car to two other computer security experts. The two said things very in line to what I asked. And no, the fact that only computer security experts worry about it is not reassuring. The rest simply wouldn't know about the risk.
OK, here's my last claim on the issue: before one year, either Tesla will have published a comprehensive security assessment of the car or at least a set of principles that put my fears to rest, or this will be in the front page of mainstream newspapers. Hackers are not slow nor dumb, and they are driven by money. And there's definitely money to make on this.

- - - Updated - - -

How many of those cars have the ability to receive instructions through the 3G network (not audio calls, but actually data calls making them take action), allow software commands coming from THAT SAME COMPUTER RECEIVING THE INSTRUCTIONS) to alter the driving dynamics and have a Linux-based computer controlling all this?
Yes, the attacks on other cars are feasible, but all things being equal, the attack is a few orders of magnitude more practical on the Tesla. What I want to be sure is that "all other things are not equal".
And also to be clear, encryption is not nearly enough. Most (important) computer to computer communications are encrypted and people still get hacked. An attacker could get access to the relevant private keys through the PKI org (it has happened before), there could be vulnerabilities in the encryption mechanisms (it happens all the time, less so on the well-published ones), the attacker could bypass the whole thing by using legitimate channels (e.g. getting your password from a XSS bug on Tesla.com or even some other site where you are using the same password) an then abusing an unchecked input parameter or a buffer overrun or something like that to get to issue commands that are not supposed to be executable remotely. That's just one example. Not saying that it is possible, but it is definitely possible if Tesla didn't do things right. Doing all that through OnStar on a car where the comm channels are much more restricted (OnStar doesn't allow you to call the car from YOUR phone), where the computer is running a proprietary OS (which doesn't add value to security but does slow down things a bit) and where the integration between the on-board computer and the car controllers is very limited (the Tesla offers more flexibility than any other car I know regarding controlling the drivetrain behavior from the UI) is much, much harded.

- - - Updated - - -

> For me, I'll wait until there is a confirmed threat before I start lining my garage with copper.

That principle usually works well for anything OTHER than security.

- - - Updated - - -

Why? Do you think that once a hacker knows how to trash a Tesla they won't trash ALL of them?
 
Give me an example of the type of documentation you are inquiring about.

Then give me an example of that type in the automotive industry.

Maybe once we understand what you are asking for, we can provide or get Tesla to provide. But right now your request seems terribly vague to the uninitiated.
 
No other car has the potential to be hacked through a 3G network at any time, and crashed into a tree.

There is no reason to believe this is possible. You can reboot the 3G connected computer while you are driving. The 3G connected computer
does not have control of the steering or the acceleration controls of the car.

Other cars however do have more direct embedded control of these systems. Explain how it's not worse to have a car with "intelligent parking assist"
like in this Lexus video

 
Last edited by a moderator:
No other car has the potential to be hacked through a 3G network at any time, and crashed into a tree.

The car is not steer-by-wire - it's mechanical with electric assist.
The car also has a traditional hydraulic brake system with electric assist.

Even if EVERYTHING ELSE (including accelerator function) were compromised, the car could be slowed and steered to the side of the road and held there.
 
I do wonder how creep was patched in. The idea that a function that controls the accelerator can be added after the fact does give me pause... Tesla had better have some stellar QA going on and some seriously safe and robust code.

As to the rest of the discussion, I'm not any more worried about some hacker remotely controlling the car than I'm worried about them remotely controlling my iPhone. They would likely have to make changes at the firmware level, and I'm assuming the MS has strict requirements for firmware updates including signing the binaries, etc... and while all of that can be hacked eventually, doing so without in vehicle user interaction strikes me as extremely unlikely. Even jail breaking an iPhone requires a USB connection to access the hardware at that level (this wasn't always the case). It may eventually be possible for someone to create a malicious jailbreakme.com style hack for the Model S but I wouldn't count on it. Contrary to what was said in previous posts I don't think there's any money in doing so.
 
Doesn't the creep option need to be enabled by the driver?

Yes, but still I agree with scriptacus that in fact this was an over-the-air software update that changed the behaviour of the drive-by-wire system, in a way proof of concept that even if the "software control system" is physically separe from the "drive system" (as shown by the fact that you can keep driving without issues while rebooting both screens) there is still a very direct connection between the two, where at least the user controllable software system can either directly, in indirectly (by reprogramming), control the drive system. This also applies to regen setting (high, low) and steering modes for example. So I would also be intereseted in knowing how these systemes are separated, what "firewalls" (lack of better word) are in place between them, how are the updates digitally signed etc etc???
 
All these embedded micro controllers (steering assist, regen controller, communications module, charger, dashboard, console, etc) are "physically" connected to a CANbus, like in any car. The CANbus allows the many embedded controllers to talk to one another independently and without all being orchestrated by a central computer. This distributed architecture is what allows the console to reboot without effecting the other components.

What we don't know is the complete data path for new firmware updates. Nor do we know how many independant systems are capable of being upgraded with new firmware. Clearly updates can come over 3G today, likely as a big tarball with checksums and install scripts for the embedded Linux controller to run. They probably download over HTTPS like the other communications to/from the car. However I am quite sure the USB ports and ODBII ports in the car allow similar and more direct access.

For more on CANbus see the following:

CAN bus - Wikipedia, the free encyclopedia

Tesla is not the only car company doing this stuff. They use the same commercially available components, such as these from Bosch.

http://www.bosch-semiconductors.de/en/ubk_semiconductors/safe/ip_modules/m_can/m_can.html

I don't know the specific components they a using and I am providing this link just as an example to show that Tesla is not as unique as the original poster is trying to portray.
 
I'm still not understanding the motivation of these alleged black hat hackers. While there are plenty of examples of black hat attacks on various devices, I have yet to see a case where murder is the intent. As a software engineer myself, I certainly want to see security done well, but I fail to see the great looming danger of someone trying to kill you by controlling your car versus just being a poor driver.
 
@Jason S: The SDL, as published by Microsoft, is one clear example. An example of a different kind are the security specs for any Windows, Linux or other OSs are also good, where they explain their capabilities such as ASLR, automated buffer bounds checking, privilege isolation, etc. as implemented in specific version of the OSs. Or the declarations of processes for responsible disclosure of buts. Finally, most platforms (even closed-source ones) have a source code sharing process through which special organizations can perform audits and reviews of the source code to ensure they meet their needs (in the case of a car this could be less applicable, but well-reputed researchers could participate in such analysis).
But if Tesla can't release any of that, at least I would like to see some level of acknowledgment that they have given car security a very good thought. Something as basic as a statement like "we have followed X standards for secure coding, we do have a responsible vulnerability disclosure program and our driveline systems are isolated from our end-user systems" would give me enough assurances to keep my Tesla stock without worrying that it might be worth zero one day soon. Not that I own too much, but it's been good to me so far.
 
In that case, you should take a look at the CAN bus info provided in the Bosch links in a previous reply.

The Microsoft one is interesting and, well... what if Tesla just came out and said they follow the same processes? Would that be good enough?
Phase 3: Implementation for example. Includes such nice paragraphs as:
For online services and/or LOB applications that implement web services, use an approved XML parser.
... which makes me wonder where that leaves the obviously REST interface used within the mobile app. But it should at least follow:
For online services and/or LOB applications, follow data input validation and output encoding requirements to address potential cross-site scripting vulnerabilities.
 
In that case, you should take a look at the CAN bus info provided in the Bosch links in a previous reply.

The Microsoft one is interesting and, well... what if Tesla just came out and said they follow the same processes? Would that be good enough?
Phase 3: Implementation for example. Includes such nice paragraphs as:
... which makes me wonder where that leaves the obviously REST interface used within the mobile app. But it should at least follow:

A specific process does not automatically lead to a specific quality bar. Two companies can use the SDL and get to different software quality bars based on how much security is a priority. What something like the SDL does is give you the ability to define such a bar, have known and measurable software quality levels, and be efficient and consistent at it. I don't think the quality bar for consumer or even enterprise products that are not rated to be use in critical or life-support systems is the same as that for the systems that have any effect on the driveline of a car, where people's lives are at stake. But the SDL (or other such processes) can be used at both. What's important is that you follow a formal process, and you are not relying on developers doing their best according to their own criteria. That was Microsoft did in the nineties and those old enough remember how Microsoft's products were at that time (and how products by other companies that refused to adopt a security discipline were until just recently, with for example Adobe and Oracle accounting for a large percentage of the vulnerabilities detected by outsiders in the whole market, with a tiny percentage of the products). A security discipline doesn't guarantee quality, but it enables you to define a bar and achieve it if that's your objective.
 
Even if a rival car maker or an oil company hacked every car they would:

A. Have to wreck them spread out over time so suspicions would be on the car and not some sort of outside force.

B. Have to do so perfectly to hide their hack tracks as not to be found in their lair, but also not have a security expert even discover the cars had been hacked or the company will not be blamed in he lawsuits that would happen. Though even if the hacking was found to be work of ne'er do wells it would likely bring a nascent Tesla to bankruptcy.

C. Have to hack the cars in such a way that they don't commit murder or manslaughter. This would get many people angry.
 
All automakers, and not just Tesla, need to address computer security issues. Although many cars do not have their own 3G/4G network connections, most now have USB and Bluetooth interfaces that connect to mobile phones which DO have wireless broadband access. That's a vector for attack, and consumers have no idea how critical functions of a car are protected from attack or sabotage.

I'm not that concerned about corporate sabotage. I think that extortion ("Pay us $$$ or we will lock up your car!" scams), and sabotage "for the lulz" as a digital form of joyriding, are going to be the major concerns for everyday drivers.
 
Motivation? How about it would be all over the news. It would be a huge deal, if a hacker suddenly caused hundreds or thousands of cars to drive off the road all at once. I think that's motivation enough.

Just so I'm clear on something (apologies for the lack of technical knowledge): the connection between the steering wheel and wheels, and the brakes and wheels, is mechanical? It's not simply software? I'm asking for hacking purposes, but also over concerns of software bugs, or - a lot more mundane - if the car's electrical system goes out. In a "regular" car I can still steer and use the brakes with some difficulty. Is that the same here?
 
Motivation? How about it would be all over the news. It would be a huge deal, if a hacker suddenly caused hundreds or thousands of cars to drive off the road all at once. I think that's motivation enough.

Just so I'm clear on something (apologies for the lack of technical knowledge): the connection between the steering wheel and wheels, and the brakes and wheels, is mechanical? It's not simply software? I'm asking for hacking purposes, but also over concerns of software bugs, or - a lot more mundane - if the car's electrical system goes out. In a "regular" car I can still steer and use the brakes with some difficulty. Is that the same here?

The steering is mechanical with electric motor assist, from what I am reading here: http://www.teslamotorsclub.com/show...fully-electronic-or-is-there-a-steering-shaft

The parking brake is listed as "electronically actuated": http://www.teslamotors.com/models/specs

I don't know about the main brakes though -- someone else will have to answer that.
 
Herby - I agree with you that having some basic security lifecycle information would be good information - but would it just be a 'checkbox' deliverable for your peace of mind? It's sort of like asking to see their crash test plans; not just their ratings.

For example I'd love to see threat models, what they consider to be assets or not etc. - without getting into detailed countermeasures for specific attacks (which I think is ok to be their proprietary info). But mostly as a learning/curiosity exercise. You would also want to see how superchargers are updated; if they also have OTA firmware updates they could also be a vulnerability to you and your car, etc. But I believe Tesla would be taking care of this as much as they think about axle design, passenger cabin integrity in crashes, battery safety, etc.

Security by osmosis doesn't exist, but with the cultural/discipline cross pollination between SpaceX and Tesla and a past in Paypal by Elon I assume basic understanding of operational envelopes and the design, lifecycle & QA processes that come with them for business-critical and life-critical situations are part of everyday design conversations - including information security.



OK, here's my last claim on the issue: before one year, either Tesla will have published a comprehensive security assessment of the car or at least a set of principles that put my fears to rest, or this will be in the front page of mainstream newspapers. Hackers are not slow nor dumb, and they are driven by money. And there's definitely money to make on this.
I strongly hope you getting the assessment and an issue appearing on the newspapers are not mutually exclusive or causally related - are you pitching your consulting services to Tesla to help them get this doc out? :)

I do worry about media over-hyping the risk (with gentle nodding by incumbents?). The fact that a Tesla model S is electric and that it has a larger screen and more buttons doesn't mean it has an ultimately larger attack surface area than other cars, and certainly not for critical subsystems, but the general population and media may play that FUD angle "Look it has two huge screens and it's electric with a laptop-like battery - must be eminently hackable!". I also worry about sabotage by incumbents. All you need is to increase chances of occasional random annoying glitches, focusing on high VIN numbers (not the tolerating enthusiasts). Like unlocking doors randomly, turning on climate if unplugged,and so on - I don't want to share the more insidious ideas.


Note to whoever questioned punch-cards: you can authenticate them by including a private-key based signature. Just means you have more boxes of cards to punch in when you get an update - from a truck-full to a truck-full and a half maybe. :). Prius firmware can get updated in 10' via a special read only USB stick that you put into a USB port of the car. In theory you should be able to do it yourself but they are only doing it at dealerships.