Weak Homegrown Crypto Dooms Open Smart Grid Protocol
threatpost.com
threatpost.com
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.
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.
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...
1) do actually nothing to further security for critical infrastructure
2) push for more surveillance laws in disguise as "cybersecurity laws"
I mean for crying out loud WhiteHouse.com didn't even use HTTPS until people on Twitter started a public shaming campaign against them. THAT'S how pathetic the real "cybersecurity" is in the US. And they have absolutely no real plan to change that right now. Who's going to come up with one anyway? This guy?
http://www.govinfosecurity.com/interviews/michael-daniels-pa...
Their current "plan" is passing stuff like CISA which will do nothing to stop a major cyberattack against critical infrastructure.
Unless you ALSO wrote it in Javascript and dropped it on an HTTP-only webserver ;)
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.
I'm feeling doubtful that this will happen. More likely they live out their lives in insecurity until falling apart.
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.
As long as your README says that you're playing around with crypto and it's not production crypto, go wild -- nobody will care. Anyone who does isn't worth listening to, playing around never hurt anyone as long as at the end of the day you use real implementations by seasoned crypto developers.
Some of the issues in cryptography implementation are subtle things that can affect it like timing concerns, if you have a time optimization it can be exploited to leak information on the data or the key. This is one thing that a less experienced developer may fall into.
There are other side channel attacks as well that one needs to be cautious about. Optimizations for power usage may also leak information.
Part of writing crypto is to optimize for security on the expense of time and power.
The issues associated with every layer are considered extremely subtle and tricky to both identify and fix. But I would say this is especially true for implementation attacks, which are not really addressed by cryptographic theory.
So, no, writing your own protocol implementation is not secure, even if you trust the design of the protocol. You are still vulnerable to the trickiest class of security flaws. However, so long as you clearly label your project as "learning only" or "insecure," no one will think worse of you for having your own protocol implementation. In fact, I'd say re-implementing TLS is one of the few ways to become intimately familiar with its internals.
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.
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."
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".
https://www.itron.com/na/productsAndServices/Pages/OpenWay%2...
And here is the spec sheet on the CENTRON itself:
https://www.itron.com/na/PublishedContent/OpenWay%20CENTRON%...
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.
If so I really hope that this can be fixed in the field with a firmware update.
(I suspect it is both badly designed and easy to analyze, but I do wonder about the state of the alternative protocols)
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.
It would be an interesting exercise to compare and contrast what you do differently than OSGP.
The OSGP analysis has attacks on key generation, known-plaintext in padding, and an attack on the OMA digest itself. These don't apply to our protocols because (a) we use a much stronger and standard key generation sequence and (b) HMAC-SHA256 isn't vulnerable to padding attacks (directly) or the reversibility attack.
All that said, I will never claim that we have a perfect implementation, but our devices are field upgradable, they do get upgraded, and we have quite a bit of attention on attacking our devices already. Our customers have been pen testing us for years.
1. Running on an RTOS platform, not Linux, so no VPN builds cleanly
2. Running on constrained platforms for which code space is not available for all the crap that comes with a VPN codebase
3. Operating a very constrained RF protocol in which every bit in every transmitted frame has to be accounted for, so not only is there no room to run something like L2TP/IPSEC, but what crypto can be run is also compromised (this is what makes me worry about "we use strong primitives unlike OSGP").
4. Operating simple protocols with simple service models in which lots of round trips for session establishment are unworkable.
5. Can potentially get AES working on the platform, but less reasonable to use anything that requires bignum math, which makes Diffie-Hellman a problem; instead just using static keys, or some simple key rotation schedule.
- OpenVPN requires TLS (you really don't want to use static keying in OpenVPN), which is a total nonstarter: the TLS protocol itself has non-stop problems, is completely infeasible to implement from scratch, and does not have any implementations useful for a high-security embedded device. Also, the data channel protocol is ugly.
- DTLS-based VPNs are, well, DTLS-based (worse protocol than TLS, and still infeasible to implement).
- IPsec is comparatively sane if you limit yourself to statically-keyed tunnel-mode ESP with no internal NAT'ing (NAT-T is ok, though). IKE is a pain (and usually requires certificates, which are very hard to parse correctly), and supporting all the zillions of options is extremely expensive. On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys. Also, IPsec overhead usually ends up being rather high in practice, and e.g. IPsec/L2TP is even worse.
- In practice, anything that requires connection negotiation requires some surgery to support high-packet-loss scenarios. (Loss-tolerant protocols over statically keyed IPsec work decently well at packet loss rates that break most IKE implementations.)
Also, for any given device, you'd usually prefer to support as few algorithms as possible and/or tailor choose crypto primitives that are well-supported on your hardware.
Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)
* We really care about on-the-"wire" efficiency. So we like having control over that.
* We actually looked very hard at DTLS, and do support it, but it is still optimized for browsers and not devices and as such carries some thought-baggage that is tricky to work around. So DTLS doesn't carry the bulk of our traffic.
* IPSec turned out to be impossible to support at the back end. Equipment that supports IPSec tunnel termination often is sold in terms of tens of thousands of tunnel terminations per box. We need tens of millions. That scale does not work for us. We do use it in some specific circumstances though.
* Anything that requires TCP is a non-starter as well. Not at all for the same reasons as the QUIC people. The NoTCP joke was really funny to me.
I beg to differ. What's we've seen is non-stop problems from implementation mistakes when it comes to all of the extra extensions. Maybe this indicates there would be a market for an opinionated TLS embedded library...
>On the other hand, static keying has many pitfalls and pretty much requires a mechanism to send updated keys.
Static keying issues aren't unique to IPsec, they occur with every symmetric cipher. There is nothing stopping you from having a management tool that rotates the static key based on a master key and the day. Or if you want to send updated keys, you just encrypt them and send them over the IPsec connection using GPG or whatever your asymmetric choice is.
>Finally, building a secure VPN wire protocol just isn't that hard. (Key negotiation etc. is very tricky, though.)
I'm sorry for saying this, but that's what every single person that has implemented a broken protocol thinks. It's true that it's not hard to get one that encrypts and decrypts. The trick is getting one that doesn't leak any information. There is basically know way to know that without an extensive analysis by the entire crypto community.
Look at how long TLS has existed and they are still just finding issues now. RC4 is another example of one that looked pretty good for quite a while and then fell under scrutiny. Do you really think you are smart enough to know everything the entire crypto community knows?
* CRIME, which conceptually breaks the way TLS wants to handle compression
* POET, which is an oracle attack against the way TLS does CBC
* BEAST, which exploits IV chaining in the TLS CBC construction
* The RC4 flaws break one of the most popular TLS ciphers, which was ill-advisedly included in SSL3/TLS
I could probably go on. For instance, the JSSE Bleichenbacher flaw looks like an implementation issue today, but it's an implementation that fails to perfectly implement a clumsy countermeasure TLS builds in to Bleichenbacher's P1v15 attack which TLS was originally totally susceptible to.
These aren't "implementation extensions"; this is core functionality.
Heartbleed was an implementation flaw. TLS's security record is much worse than just the implementation flaws. You're actually unlikely to experience lots of Heartbleed-like flaws implementing TLS in a safe language, and equally likely to have them implementing something different in C.
It's amazing what you can get in tiny packages these days.
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.
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.