DEFCONConference
1 HN recommender · recommended in 3 months, 2016–2018
49:49 · 84K views · Dec 2, 2015
A DEF CON 23 talk by Marc Rogers and Kevin Mahaffey walking through the architecture of the Tesla Model S, what Tesla got right and wrong, and how the interconnected systems can be hacked. It also covers the data the car collects.
HN cites it as a detailed technical reference on Tesla's security design, especially the firewalling of infotainment from the CAN bus.
5 comments from Hacker News
At DEF CON 23 there were two car-hacking talks that made an impression on me: one about hacking a Tesla [1] and one about hacking a Jeep [2]. FWIW, I came away thinking that the software architecture of the Tesla was light-years ahead of what Jeep (and presumably many other legacy manufacturers) was shipping: [1] this video [2] [LINK]
It is an interesting question. A while a go, 2 guys made a presentation at DEFCON with a presentation about their findings on hacking a Tesla Model S. They were able to successfully get root access to the car's system (not chroot, real full root access) and with that they were able to fully access to the car's API within Tesla OS. They even showed a video about one of the guys driving the car at low speed and the other one remotely accessing to the car's Linux shell by SSH and shutting down the whole car while the first guy was riding. The interesting thing is that for higher speeds, for example more than 50 km/h, the car seems to override any of the Linux systems and the root access becomes useless, it stops working. In another words, the car is able to decouple itself from the Tesla OS. You can check the presentation from those guys here: this video
Ignoring the infotainment system for this argument (as they firewall it off from CANBUS and other life critical systems [1]), I argue that their IT infrastructure is safety related, as it governs Tesla's velocity in getting patches and security fixes out to vehicles in a timely manner. Can you imagine a zero day being found in Windows with Windows Update being down? [1] this video
Indeed. Sending CAN frames directly is essentially a remote privilege escalation (think sudo user with no password). One of the shining examples of this done properly is Tesla; they have a gateway that you can issue commands to over the internal network, but it alone issues the CAN commands. You cannot issue CAN commands directly. this video
Thankfully, the critical reactive components of the Tesla vehicles do seem to be run by an RTOS -- spesifically FreeRTOS [0]. [0]: this video