Manufacturers and engineers have to get it through their head that IF you can change the firmware ANYONE can change the firmware. If the firmware is SECURITY CRITICAL then the only way to change it can be through physical presence, loading encrypted and and signed firmware, with external validation. (something like the car asking for a third party to authenticate the operation ala nuclear launch codes). You can still get screwed but it will be hard enough to do that otherwise low value targets will remain relatively safe.

1: http://boingboing.net/2015/05/21/gm-says-you-dont-own-your-c...

Disclaimer: I work for GM.

1) By default the cat is "locked", and uses a manufacturer-issued public key to verify the signature of updates

2) A car owner can "unlock" the car, by creating a key pair, and asking the manufacturer to add / replace (debatable) the new public key to the car. Right after that, the owner has an ability to modify the firmware, but everything is still secure. And it's up to the adult owners to manage their private keys and be careful with updates.

3) There should be a simple way to factory-reset the car (with either the owner, or the manufacturer signature).

As usual, technology isn't the reason. It's marketing, profit per unit, and profit in maintenance phase.

The first part does minimal initialization and then gives control to the second part, which is where most of the functionality is.

The first part is also the part responsible for implementing the firmware update protocol and the reset procedure. The first part would either not allow any update to replace the first part, or it would only allow the first part to replace with factory signed firmware.

Alternatively (or in addition) they could have a diagnostic connector that lets external hardware read the firmware memory. You could then do the factory reset on your used car, and then hook something up to that diagnostic connector and have it compute a hash of the firmware that you can check to make sure it is the right firmware. An Arduino should be sufficient as the thing to read and hash the firmware.

Then, if you want to be sure that the firmware isn't hacked, simply remove the SD card, put it in a computer, and verify the contents. If paranoid, overwrite the SD card with the official firmware. If extremely paranoid, throw away the SD card, buy a new one, and write the official firmware to it.

E.g., rms says he used a Lemote Yeeloong because of its free BIOS, but AFAIK he couldn't have reprogrammed it unless he removed the BIOS chip from the motherboard.

Similarly, you move into a new apartment and the super gives you the key (to the door, not a cryptographic one). You installed a new lock, right?

Cursory searching reveals the procedure for manually adding blank keyfobs to Audis, but what you describe above seems... a fairly technically complex system to take on faith. (Given the article we're talking about)

Modern keys are complex things. Gone are the days where you can have a piece of metal re-cut for $5 at Home Depot. A replacement key for modern cars is an expensive proposition: they have to be custom-ordered from the factory (with proof of identity and insurance) then programmed by your dealer. Replacement keys for modern Audis/BMWs/Mercedes run $300-400 all-in. (Remember that scene from Gone in 60 Seconds? And that was 15 years ago. And also a movie.)

You can buy blanks, sure, but without programming, it's nothing more than a hunk of metal.

Is it somehow possible to "clone" a key? Never underestimate hackers, but it ain't easy. Per Brian-Puccio's use-case, unless the previous owner is presenting auto exploits at DefCon, you don't have to worry about someone having a copy of a key you don't know about. (And if they've lost it, you can go to the dealer and have it un-registered.)

Aside: Google around for articles on new car theft: you'll find that no thieves are copying keys or hot wiring or anything like that. In fact, the "new thing" is to get a signal amplifier that allows a car's keyless entry/start system to "find" a key that's sitting 100 feet away inside someone's house or office, then just drive away.

http://pixady.com/image/6ds

Both with pros and cons, ofc.

I see at least two ways to implement that, but I certainly don't see how practical they are, if implemented at scale:

1) Every component has unmodifiable update logic that supports just that: factory reset for itself, and propagating it to the subcomponents.

This is still where we can say "the owner does not own the car", but in this case it could be treated as a part of hardware (that could not be modified either), rather than "user-space" firmware.

2) Allow easy reinstallation of the critical electronics components, which can be bought from the manufacturer. I don't quite like this "hard" way, but it's a possibility.

If the hardware of the firmware is tamper resistant you can pretty much be sure that it's unmodified. If the attacker can modify tamper resistant hardware I don't think that the car is your first concern.

Remote control over your breaks/steering is a pretty scary scenario. Someone having your physical keys mostly means they can steal your car.

This would still allow enthusiasts and security researchers to "own" their vehicle and would keep malicious actors out (for the most part).

Or heck, just put a switch on the controller that must be manually closed for a firmware update to proceed. What matters most is preventing quiet firmware updates over the air.

My second idea does not accomplish any new authentication (beyond what over the air updates already do). However it does prevent silent updates, which is an improvement over today.

Today, not only can a vehicle owner not tell if an update came from the manufacturer or hacker, they can't even tell that an update happened at all.

Also: virtually every consumer in the world would choose safety from some 'evil hacker force' rather than the ability to maintain their factory entertainment system themselves. There's really zero reason the nav/entertainment system should be on the same communications network as the engine and brakes, anyway.

I'm not up to speed on CAN bus, but if it's not possible to secure it in this manner, then it cannot be considered an appropriate communications bus for safety-critical applications. Even the industrial guys are getting their heads around this with encrypted & validated signalling over ethernet.

I don't think it's necessary to throw away everything (as near as makes no difference) to address this problem. Real air gaps, real read-only circuitry etc. (as described in other comments) could do the job.

Any form of engineered design is unlikely to go backwards in terms of the functionality and flexibility that things like bus communications bring, but awareness of these new attack vectors needs to be included in the base design.

This is the path that industrial control systems are taking in light of attacks such as Stuxnet, I expect that the automotive guys (who are usually ahead of the game in terms of systems engineering) will follow suit.

Edit: The problem I have with people proposing air gaps and read-only circuitry, is that they just don't work in real applications. If there is a business case against it, such as the service these jeeps were offering, then air gaps and hardwired circuitry solutions will be overridden by that business case. Further than that, as can be seen with things like the Lenovo hardware fiasco, manufacturers cannot be trusted to abide by the rules (such as: air gaps are now mandatory), when there is a benefit for them to act otherwise. As Chrysler now has the ability to remote into their cars, they are very unlikely to remove this ability 'merely' due to safety concerns.

It's far safer on the whole to offer secure methods of achieving the existing or proposed functionality, than to try and walk backwards and make things harder and more costly to implement, for lesser functionality.

The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option. Establishing encrypted connections also comes with a safety risk if they fail, current architectures are designed to allow glitches in the physical connections and recover instantly once the connection is back. Really, many ECUs are designed to fail in every possible way, you can even pull the power of an ECU and plug it back in while driving and your car will keep going without you even noticing it(dont try this at home). You don't want to waste a second with encryption handshaking on a 100hz signal just because you lost a sequence number somewhere. And knowing the complexity and lack of quality in encryption libraries(openssl anyone?), adding more complexity would just introduce even more risk.

What you're saying here is fundamentally that because OpenSSL has bugs that everyone should be using HTTP instead. That opinion puts you in the minority of the technical world, to say the least.

> Only solution i can see that really works is if the true sender "breaks the bus" when it detects a malicious sender is using it's source address, as is done when you get ID-collisions

This is a solution that requires perfect implementation from every component. As long as this is actually a specified behavior, written down somewhere that you have to implement to mark your part as "CAN2-compliant", that would be OK, but I doubt that's going to happen.

In general, though, I oppose requiring every node on a network operate perfectly to maintain security.

> The bandwidth of CAN is quite limited so including cryptographic signatures with proper strength in every message is not an option.

So don't include a signature in every message. Nobody does that in the computer world, you authenticate a session. There's still no reason for the head unit to be opening up a session with the brakes, and the brakes should reject such a connection attempt.

I realize that this isn't possible with the architecture of the CAN bus, but the CAN bus is just not suitable for nodes which are connected to the internet and broadcast wifi hotspots. The failure case of a CAN bus attack is just not appropriate - once you're on, that's it, you can do anything. There's going to have to be some changes, and the sooner we accept that fact the sooner we can start working on a solution. If we need a network with a cleaner electrical source and more bandwidth, that can no longer be driven with 8-bit micros on an unfiltered alternator, well, that's the price of having nice things. We'll have to buy the $1 part instead of the $.30 part to get the power windows onto the network. When you're connected to the internet, blind trust is not an option.

Within a year or two we'd see micros with onboard crypto accelerators anyway, and we'd be back to the $0.30 parts.

The thing is, nobody lets their computer act based on arbitrary packets coming in from the internet. We at LEAST make them take place in the context of a TCP session (layer 5). More likely you'd require node authentication (a function of the application layer, layer 7).

I have real doubts that manufacturers can/will implement airgaps and read-only circuitry properly. Jeep tried, and now they're doing a recall. Auto companies are only starting to realize that they are actually in the business of computer security now, and it will be years before there's been enough of these recalls for them to come to terms with the magnitude of this task. The fact that they are still operating on the walled-garden concept - inside of which all messages are taken on face value - is ample evidence of this.

Real airgaps imply a severe degradation of functionality from what both consumers and auto companies have come to expect. The days of your entertainment unit being able to control anything in your car will be gone, as will things like over-the-air firmware updates, remote door unlocks, etc. This is just not going to happen in a feature-driven world. And all it takes is for someone to leave one firmware-flash bit unset and the entire thing is worthless. Expecting that airgaps and read-only circuitry will be implemented, and implemented perfectly, every time, is wildly unrealistic, and with that security model the failure case is brutal. Once they're into the garden, they're in.

Burying your head in the sand or bawling about the cost of the fix is pointless. Cars are now connected to the internet and broadcast wifi networks, they can no longer blindly trust messages on their internal networks. That's the thing auto companies have to fundamentally come to grips with, regarding them now being in the business of computer security. If you want cars to be on the internet, validating signing for messages, firmware updates, etc is not optional, regardless of what you would prefer. We need UEFI for car hardware, and we need messages authenticated on a session level. The brakes need to be able to realize that there's no valid reason for the head unit to be sending them commands.

The mistake is making it accessible over a cellular network. This was not careful air gapping. The OEMs will learn a lot from this. They had protections but they were not strong enough. There will be protections that are harder in the future thanks to this.

CAN is really quite good and in fact is used at times in industrial automation as well as automotive where it shines.

Physical access? So, hypothetically another car gets hacked, but this time there is no middleman in position to implement a mitigation like Sprint was in this case. How do you suggest a firmware rollout happens? Recalls? Mailing thumbdrives to end users?

Over the last week I've seen the infosec community warmer to the idea of OTA updates and all that baggage that entails compared to the alternative ways to update car firmware. You're posting pretty authoritatively though, if you've got some analysis that the rest of us don't, I'd love to hear it.

(I'm half joking here - I suspect that's not the case and won't be the case for a foreseeable future, but I'd be happy to learn I'm wrong here)

But, this hack reminds me that there's no such thing in a modern car; the whole thing is networked.

So, yeah, physical updates of firmware. Although, in the article, it's a subsystem's firmware, which physically protecting that is just not in the minds of engineers right now: think of all the ports you'd need.

Even if the physical kill switch left me with just (unpowered) steering and brakes, I would have a vastly different perspective on the safety inherent.

That can mean two things—either the software didn't implement writing but the hardware is capable of it, or the hardware isn't capable at all. Sounds like the former in this case. It should have been the latter.

So while I agree with you, unless it were federally mandated for all cars, the ones that didn't do it would have lower cost of ownership and get more buyers.

Cars go back for recalls all the time. Having to physically replace a part isn't a big deal. Dealers have a supply chain in place for obtaining parts from the manufacturer.

Unfortunately, at least for some cars, all these options are bundled together in packages. Unless you buy the base model, you'll get the Internet as part of a package of other features that you want.

I think that nowadays the better answer would be to go in and physically rip out the cellular antenna. Easier said than done.

But instead of giving this chip which should be read-only regulated by software direct access to the bus, route it through a bit of extra on board circuitry which physically prevents it from writing data to the bus. This would enforce the readonly client in hardware, not firmware.

We literally have the same information for any auto manufacturer that we have from Jeep - empty assurances that 'we design our cars with the utmost cyber-security protections, trust us'.

For other OEMs it e.g. might not be possible to directly send brake signals from there, as a gateway connects and filters the different CAN networks.

But of course, once you figure out how to remote update individual ECUs then you might also be able to modifiy the gateways and do all kind of bad stuff.

Given Musk's technical background, one would expect Tesla to understand that they're building a network-connected computer-controlled two-ton missile and to have both the desire and know how to properly secure such a thing.

But yeah, AFAIK, all we have from any manufacturer is assurances of security. :(

When you factor the total impact of firmware signing on the product lifecycle, a HSM is a drop in a bucket...

But it's just a nitpick, because the basic controls are certainly all there. The feature doesn't exist yet just because it's hard to do it safely and legally.

> [the] multimedia system’s controller itself can’t communicate directly with CAN bus, it actually can communicate with another component which is connected to CAN bus, the V850 controller

That... that's not what an air gap is. Usually I'm forgiving about security that's fudged, since it's hard and marketing and higher-ups rarely understand. That's the entire point of an air gap: there isn't anything to understand, it's a physical disconnection. It's either plugged in or it's not.

When asked "is there an air gap", if the answer is no and you answer yes then you're lying in the most blatant and bare-faced way I can imagine. It's like saying "that car is four wheel drive" when it's only two wheel drive, or saying "that car has an 18 gallon tank" when it has a 7 gallon tank.

Dr. Charlie Miller

Chris Valasek

August 10, 2015

http://illmatics.com/Remote%20Car%20Hacking.pdf

    While some of the research could proceed without the diagnostic equipment, many
    active tests and ECU unlocking require an analysis of the mechanic’s tools.
    After both authors of this paper sold plasma for several weeks, we were finally
    able to afford the system required to do diagnostics on the Jeep Cherokee (and
    all other Fiat-Chrysler vehicles)

It was a hair-raising experience learning that up until recently thousands of cars' head units could be controlled remotely at any given time by telneting to port 6667 (irc, hah!) and sending unauthenticated D-Bus commands over the Sprint 3G IP network.

[0] https://en.wikipedia.org/wiki/Michael_Hastings_(journalist)#...

>'In Copyright Dispute, GM Attorney Says Customers Just License Vehicle Use' http://www.autoblog.com/2015/05/20/general-motors-says-owns-...

Most people would not like to feed their location data to "the cloud", or open their car to anyone with an exploit in their pocket.

Traffic information can be distributed to cars via one-way mechanisms without sacrificing privacy -- using mechanisms such as FM RDS and Satellite Radio.

Safety Defect/Non Compliance Description and Safety Risk:

SOME 2013-2015 MY VEHICLES EQUIPPED WITH SPECIFIC RADIOS HAVE CERTAIN SOFTWARE SECURITY VULNERABILITIES WHICH COULD ALLOW UNAUTHORIZED THIRD-PARTY ACCESS TO SOME NETWORKED VEHICLE CONTROL SYSTEMS. A SUCCESSFUL EXPLOIT OF THIS SECURITY VULNERABILITY COULD RESULT IN UNAUTHORIZED REMOTE MODIFICATION AND CONTROL OF VEHICLE SYSTEMS. FCA US HAS NOT MADE A DETERMINATION THAT THIS SECURITY VULNERABILITY CONSTITUTES A DEFECT. ALTHOUGH FCA US HAS NOT DETERMINED THAT A DEFECT EXISTS, IT HAS DECIDED TO CONDUCT A REMEDIAL CAMPAIGN AS A SAFETY RECALL IN THE INTEREST OF PROTECTING ITS CUSTOMERS. EXPLOITATION OF THE SOFTWARE SECURITY VULNERABILITIES COULD LEAD TO EXPOSING THE DRIVER, THE VEHICLE OCCUPANTS OR ANY OTHER INDIVIDUAL OR VEHICLE WITH PROXIMITY TO THE AFFECTED VEHICLE TO A POTENTIAL RISK OF INJURY.

Repair Description:

CUSTOMERS AFFECTED BY THE RECALL WILL RECEIVE A USB DRIVE WHICH THEY MAY USE TO UPGRADE VEHICLE SOFTWARE, PROVIDING ADDITIONAL SECURITY FEATURES INDEPENDENT OF THE NETWORK-LEVEL MEASURES. ALTERNATELY, CUSTOMERS MAY VISIT HTTP://WWW.DRIVEUCONNECT.COM/SOFTWARE-UPDATE/ TO INPUT THEIR VEHICLE IDENTIFICATION NUMBERS (VINS) AND DETERMINE IF THEIR VEHICLES ARE INCLUDED IN THE RECALL. IF SO, THEY MAY DOWNLOAD THE SOFTWARE THEMSELVES, OR VISIT THEIR DEALERS, WHERE TECHNICIANS WILL PERFORM THE INSTALLATION. THERE IS NO CHARGE FOR THE SOFTWARE OR, IN THE CASE OF DEALER VISIT, INSTALLATION.

I'm getting a 404 on the update page [nevermind it's case sensitive and needs to be downcased]. Does anyone know if this update actually fixes the issue? From reading the exploit details it seems more like a systems design issue that can't easily be patched in software.

Edit: After reading the paper it looks like the update from Chrysler blocks inbound tcp/ip now, and Sprint is also filtering traffic more aggressively.

I'll just leave these here: http://jalopnik.com/why-its-unlikely-someone-killed-michael-...

http://jalopnik.com/aols-story-about-terrorist-carhacking-is...

I love that quip.

It reminds me a little of something we say, more or less: "this device does not read its data sheet". It comes up a lot when a physical device does not behave the way you might expect from reading its accompanying documentation.

It sounds like the weak point in this was the ability to rewrite the firmware of the V850 controller. If that could somehow signed then I'd feel safer.

(shouting) "Guys, I'm stuck on the highway."

"What'd he say?" "Dunno, I think he's panicking."

"Guys, I need the accelerator to work again!"

"Accelerator? It won't work. Ha ha!"

http://www.wired.com/2015/07/hackers-remotely-kill-jeep-high...

Turning the volume to maximum and preventing the driver from lowering it or turning off the sound would be much worse.

As for "probably aren't safe to be driving in the first place," that may be so, but I would estimate that about 80% of people on the road aren't really safe, and just muddle through by luck and generous margins. Causing unsafe drivers to crash when they otherwise wouldn't have is still bad.

However, picking the wanted Jeep is doable as well, thanks to the option of the GPS tracker.

Better double check that you're not crashing another Jeep which is in the wrong place at the wrong time...

If something really needs to be be read only, enforce it with physical diodes or similar.

This seems unlikely.

https://en.wikipedia.org/wiki/Power_steering#Electric_system...

Plus, the vehicle can park for you. Clearly it has the raw hardware to allow for this.