Hacker News Reader

Comment by adrianN | Hacker News Reader

Big hardware companies like VW seem to still focus on "security by obscurity", because they're not used to a connected world with plenty of attackers with lots of free time on their hands.

I'm quite worried about the future of networked cars.

View on HN

I'd rather buy a Google robot car than a Ford (etc) robot car. When it's all about the software you want a software company, the actual car part is a commodity.

Same with computers, TVs, phones, IoT, routers etc.

They develop their software in a waterfall like method because they develop their hardware the same. These are still core engineering companies that don't fully value software.

I asked one of these companies about security, apparently the major governments insist by law on weak encryption and they only have to stand up to 15 minutes of hacking... Pretty terrible right?

Do you know for a fact that they do develop their software in a waterfall like method? I somehow doubt that a bit. At least they publicly say:

"Volkswagen Group IT consistently uses agile workstyles and intensive cooperation with universities, technology partners and Volkswagen Group departments to develop digital solutions."

http://www.volkswagenag.com/content/vwcorp/info_center/en/ne...

Of course, cars do have a lot of legacy (not least because of inertia caused by regulatory processes) but I think they do a bit of what they say.

Having worked on VW Software Projects i can assure you they drank all of the scrum koolaid.

How did hardware and software work together to iterate on a product? Or did they outsource it?

Worked for a vehicle company, it's "agile" as long as it fits within the limitations set by waterfall.

I guess this is a point people will argue for days, all I can say is I have been there. There is strong emphasis on incremental feature delivery with little risk management. It usually came down to engineers pulling magic wands from somewhere and soothing the software into a workable state.

Haha, that's a funny description of waterfall which more or less matches the agile process at my bank.

http://www.halfarsedagilemanifesto.org/

Perfect.

Didn't agile (or a least scrum) start from car manufacturers ?

http://the-agile-pmo.org/?p=54

It doesn't mean adoption was far reaching even if it did.

so "waterfall == bad and agile == good".... is that your point?

I would beg to differ... I've got pretty extensive experience of both and can say for sure that there is a negligible difference between the two as far as productivity goes.

That view is against popular opinion, but the only thing that really makes a difference is the commitment and intelligence of the people on the team... not the development process.

Also.... agile development is a less-good fit with hardware development... and the embedded software that goes on the hardware has to fall in line with that.

I've also had good experience with both. For me waterfall is perfectly fine if you don't have a hard deadline and agile is great for reducing risk (from what I've experienced).

I know agile and hardware doesn't go too well together and software of course is told by management to be more agile (because some manager heard it's great). The customer expects fixed incremental feature delivery (which they measure your performance on and scale your bonus with) and somehow as a software engineer you have to be agile in step with the waterfall process.

I think in general agile is better for software and waterfall is better for hardware - the problem is somehow they have to go together. It's not the best to say the least - often shipping with errors and bugs.

You realize that the concept of agile development was based on concepts practiced by the auto industry, right?

Not the American auto industry. You're thinking about Toyota not Ford.

The American auto industry has been practicing lean manufacturing techniques for quite some time now.

I think the companies themselves do, but they do an extreme amount of outsourcing too. I'm speaking from experience obviously, maybe it's a bad example.

Nobody (including me!) expected extremely cheap software-defined radio transmitters and receivers to be available. A short key and a rolling code seemed like a good enough obstacle for a door lock 20 years ago.

I don't know about not expecting it, I think as a general rule all expensive technology will likely be cheaper in the future, or simplified so that it's accessible to the masses. It's difficult to think of a counter example?

I don't think this actually needs fancy software-defined radio hardware. That looks like a cheap, generic 315/433MHz ASK receiver for the keyfob, and those have been widely available for decades. They're essentially what you'd find in the car side of a remote-unlock system, or in most bargain-basement RF remotes of any kind.

"ASK" is amplitude shift keying (shifting/changing between two amplitudes). In cheap transmitters (like the ones on keyfobs) one of the amplitudes commonly is "on", the other "off". This is morse, literally the first modulation ever invented to be used with radio waves.

Receivers for much more complicated modulation schemes have been built by amateurs for many decades, so I think in the case of analyzing the keyfobs' security SDRs were not a necessary tool.

But of course with the advent of cheap Rx and Tx capable SDRs the amount of people able to decode (and transmit) all kinds of modulated signal in all kinds of frequency bands has exploded, and for example my ability to quickly change from running a cell-tower to receiving satellites signals to decoding/analyzing/transmitting the keyfob radiwaves and unlocking a car is only one "./configure ; make" away, once I have acquired a sufficiently advanced SDR. No need to build, solder, tune, debug an electronic circuit tediously custom built for one application.

Yes, but SDR allows for the quick and easy experimentation, even if the hack ends up being implemented on other equipment.

The other aspect that makes SDR so appealing is wiring up software blocks in GNURadio that used to be implemented in hardware. This drastically reduces the testing cycles and lets you basically guess, measure, and muck around until it works.

And worse then sue to try and keep exploits hidden.

It is like the vehicle industry is stuck in the 1990s. We've moved so far beyond that elsewhere, software designed to be updated, working WITH not AGAINST white hats, and having designs secure on paper first before you implement.

Vehicle manufacturers put convenience and speed ahead of solid security principles, and it is only going to get worse with more wireless connectivity making it into vehicles year upon year.

Considering who's been the target of some of the more conspicuous hacks lately, my guess we're going to see some fairly draconian legislation during the upcoming Presidential and Congressional terms.

Don't look for the CFAA to be nerfed anytime soon, let's put it that way. The politicians will hit back at hacker culture with the only weapon they have.

Reply on news.ycombinator.com