Hacker News Reader

Comment by seigenblues | Hacker News Reader

I wish they mentioned any specific smart-meter vendors using those chipsets! Maybe this will get picked up by some greentech bloggers & develop into a real story.

View on HN

We've worked extensively in this field, primarily to help vendors ship these products more safely --- so we're enjoined against publishing specifics. But it's a real problem, and I'd refer you to IOActive (a competitor of ours) for details.

Two things to remember about embedded RF devices and security:

* The boards themselves are a hostile environment for developing crypto, because they're solid state (low entropy), severely power constrained, and have very little headroom for code storage; the difference between supporting SHA1 vs. MD5 could come down to blowing the instruction store budget.

* RF is a hostile place to deploy crypto, because it's group based, severely rate limited, slow, and every individual bit of message encoding is precious.

Very smart developers never get crypto right even in environments where a shift from an MD5 MAC to a digital signature is just a line of code, without regard to message sizes, and where the only constraint against adding protocol steps is breaking compatibility with software that can be upgraded in minutes. Draw your own conclusions about how hard this problem is.

(As Nate pointed out a year or two ago, the exact same problem exists with tolling systems).

they're solid state (low entropy)

That doesn't necessarily follow. It's easy to put a real RNG into silicon; the problem is simply that very few people bother.

It's not as simple as you make it out to be, but you have me at a disadvantage as I've actually worked on products like these and can't rebut with specifics.

In the meantime, I'd dispute the idea that embedded developers even understand the relationship between secure random number generation and cryptography, outside of the abstract.

It's also the case that amongst security practioners in general purpose code there is still precious little best-practice understanding of how to groom and maintain secure RNGs; a Black Hat talk from just a few years ago busted up a bunch of RNGs on security products, both with algorithmic attacks and things like cold-start entropy.

I'd dispute the idea that embedded developers even understand the relationship between secure random number generation and cryptography, outside of the abstract.

Sure, of course. My point was that, compare to issues such as power constraints, code size, bandwidth, et cetera, the problem of getting entropy was more of a "people are doing things wrong" issue and less of a "laws of physics get in the way" issue.

I'm of a mixed opinion on this. If the rest of the system used a secure PRNG that allowed for accumulating entropy, then such a thing couldn't hurt. However, many designers might depend only on that source, and without careful review, that might be a mistake.

Here's a paper on the Via hardware RNG I helped write. I have not seen this level of analysis from vendors of other hardware RNGs. In summary, the entropy source is pretty good but has some bad modes if you mess with some of the config bits.

http://www.cryptography.com/resources/whitepapers/VIA_rng.pd...

I crusaded for a long time for FreeBSD to not use this source directly. Instead, someone put in a Davies-Meyer AES hack that just whitens the last few bytes of output. So if you can get a predictable series of sequential bytes out of the Via RNG at any point, you've broken /dev/random on that machine.

Oh look, that code is still there:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/neh...

Here's where it swaps out the decent Yarrow PRNG for this ad-hoc one:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/pro...

So running FreeBSD on a Via machine is actually LESS secure because other entropy, such as disk IO, timers, etc. doesn't get hashed in. This is exactly what I'm arguing when I say a single hardware source can sometimes lead to less secure system choices.

BTW, I doubt this constitutes vuln disclosure since I wrote core@ about this about 4 years ago and the maintainer decided it wasn't important. Ironically, the reason given was that this is higher-performance than Yarrow and the hardware RNG appears good.

I agree, FreeBSD's entire approach to entropy could do with being thrown out and rebuilt from scratch; I'd love to do this myself, but I don't have the time/energy right now.

That said, I'd say that there are probably bigger issues in FreeBSD than this.

Can you make a note to yourself to do it after tarsnap makes you filthy rich?

And btw, tarnsap is awesome!

I have lots of notes of things to do after tarsnap makes me filthy rich. :-)

And btw, tarnsap is awesome!

Thanks! Good to see I'm not the only person who makes that typo...

Good to see I'm not the only person who makes that typo

Ah fudge!

I don't see much coming out of this other than giving more ammo to the refuseniks ("they put in a device that charges me extra $!") While I personally don't have a problem with remote power monitoring, I don't think these devices should allow remote shutoff.

The ROI on these devices is spectacular; they drastically reduce truck rolls. They're obviously going to happen.

Without getting into treacherous water, I can also point out that control loops with remote meters are a major part of what the win DOE thinks it will get from the "smart grid": customers will be able to check boxes on their bills to enter into contracts that reduce their usage during peak periods, allowing the power companies to allocate more efficiently.

Having attended a NIST/EPRI workshop, plug-in electric vehicles (on the buy side) and SOHO-scale renewable generators (on the sell side) seemed to be top of mind.

To make these systems all work the way NIST/EPRI seems to want them to, you need more than just a continuous feed of usage data.

Reply on news.ycombinator.com