Hacker News Reader

Comment by josteink | Hacker News Reader

Translated into not-evading-responsibility-esque:

The fact that the communication protocol used is openly known, much like all internet communications, means that an attack is easy to craft.

Somehow that is a solved problem with internet and all other open security architecture. Why isn't it solved on these cars?

This sounds like either NIH combined with piss poor security engineering done in the name of looking fancy, result of financial constraints or both.

I'm sure some engineers objected that "this is fundamentally insecure!" but got turned down from someone doing the budgets.

View on HN

It isn't solved for computer networks, this is exactly the same as the current debate about secure boot. Secure boot is an open standard, but we've not agreed about who can hold the keys: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot

Here, the EU has effectively said that someone with physical access to the car can generate their own keys (since anyone can pretend to be a mechanic, and all mechanics are allowed to generate keys), and the car manufacturers are saying that they should have the root keys, so that only approved dealers can create new ones. Much like Microsoft saying to ARM tablet manufacturers that they have to allow only Microsoft's keys in ARM tablets, blocking end users from installing their self-signed OS.

tl;dr: the problem is not protocols, it is key management.

It isn't solved for computer networks, this is exactly the same as the current debate about secure boot.

I would disagree. To me this sounds like a perfect scenario for asymmetric encryption, which would solve this in a secure fashion.

Obviously someone should have a secure repository for official keys issued, so that duplicates can be made, upon request, upon owners' authorization. It might be bothersome and cumbersome, but the point is it should be a possible process, even for third party mechanical shops.

And for me the car-manufacturer sounds like a natural holder of this repo.

On the other hand, if you have access to the car and the key, it should be open enough to allow you to (re-)program it with your own keys if you like.

As far as I can see, that should satisfy everyone involved, while maintaining a secure architecture.

this sounds like a perfect scenario for asymmetric encryption

I suspect that they are already using asymmetric encryption, with some sort of mechanism to allow third party mechanics (and thieves pretending to be mechanics) to sign new fobs.

the point is it should be a possible process, even for third party mechanical shops.

Yes, agreed. The issue seems to be how much faith you put in the manufacturers to play ball. If they have to incur a cost to manage keys, that might lead to legislation around putting limits on the amount they can charge for access. It seems like a rabbit hole full of problems to leave them in charge. What happens when someone who has lost the keys to their second hand car goes to a third party mechanic to unlock the computer in their car built by a manufacturer who has gone out of business?

it should be open enough to allow you to (re-)program it with your own keys

With this strategy, the solution the the above question is to hope that the user added their own key/certificate to the car in advance. I suspect that the people who would do that would intersect strongly with those who are meticulous with keeping a spare key in a secure place anyway, so it would only help a minority of people.

Some of the other ideas, like time locks or falling back to a physical key to create new fobs, sound like they may do a better job of ensuring user freedom. Those solutions might apply to secure boot too, but it still seems unsolved in practice.

There is a difference, which is that a car is a physical thing.

Imagine that we had the current process. Except that every time a key gets reprogrammed, a record was made of which mechanic's key was used, and we have a mechanism to revoke particular issued keys.

This will not stop my car from being stolen. But we can identify which mechanic's key was used to do it, and I'm able to brick that car remotely.

You've just increased the cost of stealing a car this way, and reduced the cost of having it stolen. That may well be enough to convince thieves to move on to an easier type of target.

>Somehow that is a solved problem with internet and all other open security architecture. Why isn't it solved on these cars?

>I'm sure some engineers objected that "this is fundamentally insecure!" but got turned down from someone doing the budgets.

You're missing a couple of key points here:

1) This is not a network attack, so the internet is largely irrelevant.

2) This is similar to having an attacker sit down at the physical computer they're attacking (a much harder problem).

3) Legislation in Europe forces car manufacturers to use an insecure design.

Anti-competition legislation in Europe dictates that the manufacturer cannot stand in the way of the transfer of secret keys. This means that the entire security communication must occur between the on-board computer and the OBD-II tool. Other than a physical lockout on the OBD-II port, I can't think of a good defense against this attack.

In the US, many car manufacturers take a different approach. The security key is provided by the manufacturer, not the on-board computer, so you can't simply walk up and re-program a key. I don't know if this is true of all manufacturers though.

What's wrong a simple "Okay sir, before you can drive away with your new car you need to pick a password. And before anybody can service the car they'll need your password so please don't forget it, but if you do you can always provide proof of ownership to your nearest dealer and they'll help you reset your password."? That way non-franchise garages can still do repairs, as well.

They'd have to provide the 'password restore' functionality to non-franchise garages as well, I guess. Otherwise they could do this except without the password: 'Okay sir, here's your key. Anybody can service the car, but they'll need the key. If you lose it, provide proof of ownership to nearest dealer and they'll make you a new one'.

Good point; a physical key is just as good as a password and has the benefit that people will treat it properly.

That's a great idea, but IANAL, so I can't say if it passes muster for EU anti-anti-competition laws. I'm going to go out on a limb and venture two guesses:

1) Any mechanism that requires manufacturer intervention is going to draw the eye of these legislators, which would likely mean some means of resetting that password for third-parties, which significantly diminishes the security utility.

2) If you've ever worked with consumers and "passwords", you know that they don't remember them. I think this bolsters support for regulations that require the reset procedure to be accessible by third-parties.

Thieves will help themselves to reset the password too, and they naturally waive the proof of ownership clause.

1) This is not a network attack, so the internet is largely irrelevant.

Security protocols that can be used on two points on the Internet can also be used between two pieces of hardware, like a programmer/diagnostic tool and an embedded computer.

I don't disagree with that, but it's still irrelevant in the context of this particular attack, because there's no main-in-the-middle component required. Yes, you must secure the transport, and the same applies for even basic serial communications, but that's not what's happening here at all. This is an exploit of the implementation constraints at a legislate level.

Engineers look at this problem and see the engineering problem, but it's cynical (albeit warranted) to believe that the engineers at BMW didn't see the same problems. I bet they are well aware of this vulnerability, but they're unable to do anything about it.

There's a valuable lesson to be learned. It ties in to the old adage: be careful what you wish for, you might just get it. There's a lot of rumbling about new privacy legislation in the US, but the entire concept makes me really nervous. What are the chances that legislators understand the internet well enough to craft effective legislation? Not good, I'm afraid.

> I don't disagree with that, but it's still irrelevant in the context of this particular attack, because there's no main-in-the-middle component required.

Non-sequitur. If you can interpose the man in the middle, then most protocols are broken.

> What are the chances that legislators understand the internet well enough to craft effective legislation? Not good, I'm afraid.

From what I've seen, the average level of security knowledge in the startup community is woefully inadequate -- with almost everybody believing they are above average.

> Non-sequitur. If you can interpose the man in the middle, then most protocols are broken.

It does follow. There is no basis for the belief that the transport channel isn't secure! For all we know, it's well-encrypted.

Yes, MITM is a concern with all communications that are intended to be secure. Granted. Established. Not an argument. But, it's not relevant to this attack.

Even using the best crypto available won't save you if the client barfs the security keys to unauthenticated clients upon request. The challenges here are in the authentication and authorization layer, not the transport layer. But there are non-technical constraints at play.

Backing up a bit, this even better illustrates the root of the problem. The way the law is written, you can never build a secure system, because the law mandates that the computer in your car trust all clients. Any system that does not secure the channel between an identified client and server is not secure. Hence, when all clients are permitted, the system is not secure by specification.

> In the US, many car manufacturers take a different approach. The security key is provided by the manufacturer, not the on-board computer, so you can't simply walk up and re-program a key.

And the consequence is that a replacement key costs $150. No joke.

Try 500$. BMW owner. This was my quote from the Dealer when I thought I lost my key.

4) Nobody said they had to use the OBDII port for this.

4a) Nobody said that OBDII ports had to work while the alarm is armed.

Regarding 4a: if you lose your key (and thus you have lost the ability to disarm the alarm) the entire vehicle is bricked?

No, you just get the dealer to plug something into the (possibly proprietary) port that's used by the alarm system.

The assumption that this kind of thing needs to be done via the OBD-II port is wacky from the get-go. It may have been easier for some lazy system integrators at BMW to do it that way, but it certainly wasn't necessary, or apparently advisable.

I'm not seeing how that will deter thieves. Instead of plugging into the ODB port they will just plug into the alarm system's port. Even if it's proprietary, they'll employ/bribe/coerce an official technician to figure out whatever Rube Goldberg sequence of events that are required to re-enable the vehicle.

Presumably there would be more opportunities for secure handshaking with a proprietary port. It doesn't need to involve security by obscurity -- it just needs not to be barkingly stupid.

The best practices in auto security are probably reflected by whatever the leading Japanese brands are doing these days. Traditionally Hondas have been the biggest theft targets, but a glance at the list of most-stolen cars in America ( http://editorial.autos.msn.com/article.aspx?cp-documentid=43... ) suggests that they've more or less solved the problem, as of the mid-1990s. I seriously doubt there's that much need for further innovation.

Yes, secure handshaking via PKI is a well known and already solved problem. However, as mentioned in the post you originally replied to: "Anti-competition legislation in Europe dictates that the manufacturer cannot stand in the way of the transfer of secret keys." Keys, here, referring to the private half of a public/private keypair.

This means that a manufacturer can't be the exclusive source of resetting a key much in the same way that Verisign isn't the exclusive source of SSL certificates. Due to the anti-competition legislation, you should be able to take your vehicle to any local garage and have it fully serviced whether for a tune-up or to get a key reset. And if a local garage can be employed to reset your key because they have access to the private key required to sign the key request, thieves can do it just as easily.

Are you speaking from knowledge of the anti-competition legislation, or just from the summaries we've seen upthread? It strikes me that we're taking a car blog's throwaway description of the law as a presumed engineering constraint.

Every reputable website with details beyond the "scary, scary news" headlines have made mention of the legal aspect. There's a lot of information in this thread over at Bimmerpost.com as well:

http://www.1addicts.com/forums/showthread.php?t=712717

Are you sure you linked to the right thread? I didn't see any discussion of the legal aspect at all - other than "can we sue BMW?"

> Other than a physical lockout on the OBD-II port, I can't think of a good defense against this attack.

Make the key changing process VERY slow, as in 24h+. If you really really lost your key you wouldn't mind leaving the car 24h at a mechanic but a thief would have a much harder time hiding a car that long. At least compared to 2mins at a dark parking lot.

Somehow that is a solved problem with internet and all other open security architecture.

Just to play devil's advocate, I'm not sure that's entirely true; would you say that every computer user on the entire planet is 100% secured? The vast malware landscape would very much disagree.

I think that it is harder with cars, if only because they have to have an open gate to the heart of their system. Plug in, turn on laptop, access! Apparently that's enshrined in both EU and US law, so not very easy to overcome in the near future.

I do agree with the heart of your message though: this is the year 2012, and whilst as a non-security bod it's easy for me to say, these things really shouldn't be happening.

Reply on news.ycombinator.com