Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is only the tip of the iceberg as far as this kind of thing is concerned (this kind of thing being people relying on software to keep them and their belongings safe).

With peoples' lives at risk and with cars representing huge investments for many people, it's probably about time to get regulation that requires the software systems that are interacting with vehicles to be open to experts at large.

The same goes for things like in-home security software.

The competition should not be in the critical software. That much needs to be standard. The competition should be around fluff, construction quality, body design, brand, perks, horsepower, etc.

How is this kind of thing handled in the medical and aviation industries? How about NASA? Life-critical and safety-critical software isn't something you should hire the lowest bidder to create, nor is it something that should be hidden away in the belief that "obscurity is (the best, and the only) security."



While I agree with your general point of making car security openly auditable, I think the best short-term approach to fix this is via insurance companies. They have a direct financial loss from badly designed car locks, and probably sufficient power to issue direct pressure to the car makers as well as indirect pressure to car owners through astronomical insurance rates.


How is this kind of thing handled in the medical and aviation industries?

Since you ask, I'll draw on what I've learned from my childhood best friend (an electrical engineer who worked first in the aviation industry and now in the medical device industry) and my son (who was a summer intern for a medical device company). Simply put, safety-critical devices are heavily regulated in those industries, and everything new is assumed to be safety-critical by default. My son's summer work designing the doctor-facing user interface of a new bedside patient monitor was subject to a line-by-line code review by programmers on the FDA staff. He estimated that the product he worked on would take six years to get to market, even thought it was just version 2 of a device that already worked and had clinical usefulness. Federal government regulators try to be extra careful in review of new software that protects human lives in those industries.


> How is this kind of thing handled in the medical and aviation industries?

You need government approval (FDA or FAA respectively) to bring a product to market. Are you sure you want that kind of bureaucratic overhead (and the associated politics) in your car and home alarm?


I don't think "government" means "good engineering", I think that it should be thoroughly vetted by sufficient expertise.

I'm not sure if the FDA or FAA are capable of doing that, given how the government is really, really bad at building or contracting software (in general).

If only we could have some kind of standardized software to power these devices that is built by the community at large and thoroughly reviewed for correctness. Even at the cost of limiting hardware, I think that's an option.


It'd be neat if they could come to some sort of a standard on this so that its an open, reviewable piece of software that handles the crypto side of things and then passes that off and they (the Automakers) can "customize" the rest of the software all they want.

Somewhat (but also not at all) like a more advanced ODBII[0]

[0]http://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II


> The competition should not be in the critical software. That much needs to be standard. The competition should be around fluff, construction quality, body design, brand, perks, horsepower, etc.

Could you explain your reasoning for this claim? Does competition lead to better/more efficient products, or doesn't it? Why do you desire to leave non-critical parts to competitive forces, but not the critical parts?


It doesn't because 99% of people are entirely and completely ignorant of these systems and their importance. And no amount of discussion or even car theft is going to put it in terms that they understand. Here the news item is "with a black box that nobody understands." That wording is HORRIBLE for HN. Because it makes it sound like it's black magic and this group has found some genie that opens cars. Instead, it's more likely a simple exploit of a very vulnerable system. But that wording gives you a glimpse into how most people see technology. It's just magic. Their cares about how software works are nonexistent enough. There's no reference for "good" vs "bad" crypto, insecure design, etc.

Until we have a car that kills 500 people because of faulty software, it's just not that important to people, which means there's no pressure in industry to get it right. People understand "my car will kill me if X isn't good." That's why people understand getting their tires rotated and replaced. That's why they understand to get checkups and to replace belts, filters, oil, etc. That's why they understand you need to replace your brake pads and other such hardware, even if it feels a little expensive. But when you point out that very few people have ever even been injured by bad software in a car, they think "well it can't be that bad." And "good enough", especially in a market like the US where mediocre is what sells the most, is where the market stops innovating.

I hope a company like Tesla is a little more concerned with the quality, though. Maybe we can get a decent example of how to do things.


> Until we have a car that kills 500 people because of faulty software, it's just not that important to people, which means there's no pressure in industry to get it right.

I agree with that. But what is your alternate proposal, and where does the pressure to get it right come from in your proposal?


I don't think there's any other way to apply pressure to these companies other than regulation, unfortunately. They don't care much about what we think, and their customers don't care, so outside of forcing them to use a secure system (or else not be allowed to sell their products), it'll never happen.


But what I meant is: where does the "pressure to get it right" come from when government decides to regulate something? If the aggregation of actors' choices in a competitive market doesn't provide pressure to get it right, why would the aggregation of actors' choices in a government provide pressure to get it right?


I'm not saying it would. But the point is that it should, and it's stupid that it doesn't.

It's 2014.

"Someone stole my car by using a packaged exploit that is easier to find and abuse than breaking anything on DVL"

This is just unacceptable.

I think most of us (here) care about the software our cars are running. It's also absurd that we can't access the computers and put our own software on them. It may be difficult to get legislators to realize just how bad this software is and how much important it is to get right, but it's their job to listen. An alternative is to push for openness of these computing devices. Having access to put your own software on any computer you own may enable the existence of open source implementations that are better than the defaults, and sensationalist headlines might get enough attention of the right people to make something happen. "These hackers can keep your car from being stolen, for free."

Alternatively, headlines about this kind of issue need to be more specific. 'Mysterious "black box"' seems like the headline created by someone in the pocket of the industry. Instead, how about a headline like "a black box created by low-tech criminals exploiting massive security holes that car manufacturers know about allows anyone to unlock and start any car". Maybe it's a bit wordy, but it's somewhere to start. And it shines a light on the real problem. It doesn't paint it as a mystery with only the thieves at fault.


I'm surprised that it's taking so long for these kind of stories to hit the news. Here's a paper from three years ago describing some disturbing attack vectors on a modern automobile: http://www.autosec.org/pubs/cars-usenixsec2011.pdf




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: