
Weak Homegrown Crypto Dooms Open Smart Grid Protocol - tptacek
https://threatpost.com/weak-homegrown-crypto-dooms-open-smart-grid-protocol/112680
======
tptacek
Click through to the paper. I could not be more thrilled; we had been looking
for an excuse to publish Cryptopals challenges for differential attacks, and
Alex had even written one, but we opted not to because they'd never been
valuable to us in a real-world setting. Now we can build a small sequence of
them.

I rag on people's crypto projects a lot, but it's worth knowing that almost
nothing you could reasonably do with your own crypto could so thoroughly bone
you. This paper has _three different key recovery attacks_ from both
controlled and partially inferred plaintexts (chosen and known plaintexts, in
the jargon). Chosen plaintext attacks are common. Key recovery attacks? Less
common. This is masterfully terrible cryptography.

Looking forward to digging into the attacks in actual code.

~~~
dankohn1
It was "masterfully terrible". Can you predict whether it was intentionally
terrible or just incompetence at play? My impression is that the NSA likes
their key leaking and similar approaches to be more subtle.

~~~
mpyne
"The Open Smart Grid Protocol (OSGP) is a family of specifications published
by the European Telecommunications Standards Institute (ETSI) used in
conjunction with the ISO/IEC 14908 control networking standard for smart grid
applications."

Not sure who to blame if it is deliberate, but seems unlikely to be NSA, and
not just because of the unsubtlety (though NSA was also behind the quickly-
spotted Dual EC DRBG).

Even back before the Crypto Wars the NSA usually tried to have their cake and
eat it too though, trying to make their crypto breakages to types of breakage
that could only be exploited by a state-level adversary like themselves.
Leaving 3 different key recoveries available is 2 more than NSA would have
needed, and the additional weaknesses simply make it more likely that a first-
year CS student would eventually figure out the problems.

~~~
raverbashing
"Published"

Most likely it was created by the biggest SCADA vendors (which will remain
unnamed) and know as much about computer security, best practices and modern
developments as I know about 17th century Japanese history...

------
brohee
The actual standard :
[http://www.etsi.org/deliver/etsi_gs/osg/001_099/001/01.01.01...](http://www.etsi.org/deliver/etsi_gs/osg/001_099/001/01.01.01_60/gs_osg001v010101p.pdf)

There are only 3 pages on security (plus annexes). There is the broken MAC,
but the cipher standardized is actually RC4... Without using the constructions
that make it less insecure like discarding the first 3kb bytes of output.

Also that little gem : An "invalid digest" response is never encrypted.

Which is likely a textbook oracle.

All of this is completely inexcusable for a specification published in 2012, a
lot of it could have been stopped just reading a few Wikipedia entries.

I guess a lot of the devices are going to landfills.

~~~
tptacek
Just a quick pedantic note that RC4 is broken even if you discard keystream.

~~~
brohee
Hence, "less insecure".

~~~
tptacek
RC4 is meaningfully, materially insecure virtually no matter what you do with
it. I don't think you're disagreeing, but the nerdal lobe in my brain won't
let me leave the discussion without it ending on that note. :)

------
happimess
I know that it is considered suicidally hubristic to use homegrown
cryptography; does that apply to writing your own implementation of a trusted
protocol?

It seems like it'd be a cool project, but I don't want my github profile to
advertise that I'm the kind of fool that rolls his own crypto.

~~~
saalweachter
Writing your own crypto implementation is just like every other instance of
reinventing the wheel, but more so. Namely, don't be a dilettante.

It's actually perfectly OK to reinvent wheels. Reinventing wheels is how
people learn to build wheels and eventually invent new, never before seen
wheels. Where we as programmers get in trouble is that we frequently reinvent
a wheel once, and then drive around on it for the rest of our lives.

If you find cryptography interesting, try your hand at it. But don't just code
up the first implementation once, slap it on a web app, and use it to protect
your customers PII. Don't be a dilettante. Write lots of crypto
implementations, and try to find the flaws in them. Read lots of books, read
lots of other people's implementations. Whenever a new exploit of one comes
out, try to understand it and try to find similar problems in your own code or
other implementations (or figure out why a particular implementation doesn't
have that flaw). Write more implementations, read more books, talk to other
cryptographers.

It's not a crime to be interested in difficult things, but it is important to
recognize that difficult things take a certain level of skill and devotion.
Each of us has to decide which difficult things we want to devote our time to
and which we want to casually watch from the sidelines.

~~~
lfowles
To further the analogy: Most of us don't have the resources or knowledge to
properly test our wheels after we reinvent them.

------
lotsofmangos
_“The No. 1 rule of cryptography is ‘Don’t invent your own. '”_

I'd say that's rule No. 2 and needs the obvious caveat of _" unless you really
know what you are doing."_ Encryption didn't come from nowhere.

Rule No. 1 is _" Know what you are doing."_

~~~
hueving
The people that know what they are doing when it comes to cryptography need to
be employed as full-time cryptographers to stay with the state of the art.

So the rule should be, "if the person inventing your crypto does anything else
for a living, it's going to be full of holes".

------
garyrichardson
Can any BC Hydro customers confirm if these are the smart meters we have?

~~~
afreak
This is the device that BC Hydro uses I think:

[https://www.itron.com/na/productsAndServices/Pages/OpenWay%2...](https://www.itron.com/na/productsAndServices/Pages/OpenWay%20CENTRON.aspx)

And here is the spec sheet on the CENTRON itself:

[https://www.itron.com/na/PublishedContent/OpenWay%20CENTRON%...](https://www.itron.com/na/PublishedContent/OpenWay%20CENTRON%20Meter.pdf)

According to the linked to paper and the data sheet, they use the same
standards so I would wager "yes" on BC Hydro's power meters being affected.

~~~
Animats
That's a meter with "remote disconnect" capability. So now someone can turn
off house power over a cellular link.

~~~
MertsA
And turn off power over a wide area and then start a couple of jammers. That
could be very very disruptive but can this attack let you send commands to the
meter? Or is it limited to just spoofing the meter itself?

If so I really hope that this can be fixed in the field with a firmware
update.

------
justinsb
Do we know that the alternative protocols are better? Are we finding so many
problems because the protocol was badly designed, or are we finding them
because an open protocol is much easier to analyze?

(I suspect it is both badly designed and easy to analyze, but I do wonder
about the state of the alternative protocols)

~~~
bdamm
Well, I work for a smart grid vendor (SSNI) and I know for a fact that our
protocols are better. We actually use strong primitives, for starters.

I can't understand why they rolled their own MAC, when robust and tiny
implementations are rather plentiful. That just seems like a foolish waste of
time, frankly. An ATMega can do HMAC-SHA256 for crying out loud. There is no
excuse.

~~~
tptacek
There are AVRs that can reasonably "do" SHA2, but many have text size
limitations, which motivates vendors to minimize the number of primitives they
use (for instance, it might lead someone to use CBC-MAC instead of HMAC).

Also: however capable your hardware is, if you're doing long-range RF (and not
GSM), you've got a much more significant space and round-trip constraint to
deal with.

~~~
bdamm
CMAC is fine too if done properly. And RF constraints is no excuse for a weak
MAC.

~~~
tptacek
CBC-MAC is really not fine. :)

In any case, just making a descriptive comment, not a normative one. Broken
crypto is broken crypto, I agree. I just have a little bit of exposure to this
particular design challenge, and those are two reasons I see people not using
"best practices" simple cryptography in these kinds of applications.

~~~
sdevlin
CBC-MAC and CMAC are similar, but not the same.

~~~
tptacek
D'oh. Thanks.

------
davidgerard
The Internet of UNFIXABLE HEARTBLEED EVERYWHERE FOREVER

------
lasermike026
I wonder if the power companies want a smart grid. Don't they charge by the
watt?

~~~
TwiztidK
Yes, now they will charge by the watt and time of day to reduce peak load.
Although, I actually think the main idea is that it will make them aware of
outages in real-time so they can recover faster, which one of the factors used
to judge publicly traded utilities (also know as CAIDI, customer average
interruption duration index).

