Slashdot Mirror
Poor, Homegrown Encryption Threatens Open Smart Grid Protocol
An anonymous reader writes: Millions of smart meters, solar panels, and other grid-based devices rely on the Open smart grid protocol for communication and control — it's similar to SCADA's role for industrial systems. But new research shows that its creators made the common mistake of rolling their own encryption, and doing a poor job of it. The researchers believe this threatens the entire system. They say, "This function has been found to be extremely weak, and cannot be assumed to provide any authenticity guarantee whatsoever." Security analyst Adam Crain added, "Protocol designers should stick to known good algorithms or even the 'NIST-approved' short list. In this instance, the researchers analyzed the OMA digest function and found weaknesses in it. The weaknesses in it can be used to determine the private key in a very small number of trials."
The least you can do is implement a real algorithm; but screw it up somehow
That's why the best recommendation is to not only use the approved algorithm, but also the standard implementation. Don't get cute, don't try to optimize it, just use it as is. AES was required to run on emdedded systems 13+ years ago, any modern chip should have zero problem running the standard C implementation today.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Every crypto is roll your own at some point in its life
At this point in its life; it has no place in new protocol specifications or production systems, not until the new crypto is published and disseminated by the community and found to have no flaws that any researchers can find.
Even for something as simple as AES it's a chore to find an open implementation that's actively being maintained
No... there are many implementations that are actively maintained; your implementation doesn't have to be Open source, so long as the implementation of the specified ciphers and hashes is a correct implementation....
It is a small price to pay to use standardized ciphers or standardized implementations known to be secure, instead of risk everything on a homegrown cipher.
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
Holy fuck you're dumb as bricks. How exactly could the TSA be "Obama's legacy" when it was created during George W's presidency and before Obama was even a US Senator?
There's an implicit "unless you *really* know what you're doing" to the sentence, which just tends to not be the case for most people, which is mainly because most people aren't crypto nerds, and the consequences of failing crypto are typically serious. Much more serious than doing your own science at home (provided you aren't going nuclear; "don't do your own nuclear science at home" doesn't sound so absurd, does it?) and ending up with wrong results, or composing music and ending up with horrible garbage.
CLI paste? paste.pr0.tips!
An algorithm that has been in use for years, especially if said algo has been used by companies that value the security of their data where there is also a huge incentive for third parties to break that security (like, say, financial institutes, insurances, journalism, governments), you may rest assured that they all hired various, very different, people with the goal to see whether that algo is actually as secure as they claim it to be. Not to mention a lot of other experts who do it on their own time for the sake of being the one who found a critical flaw in it (which is usually a HUGE boost in credibility and peer esteem, which can easily be converted to more income and better jobs).
There are a LOT of people with nothing better to do than testing those cryptos. You may rest assured that thousands of hours have been thrown against common encryption standards. And while many companies (governments especially) would of course keep such findings secret to exploit them if their opponents use them and consider themselves secure, most others would not only publish it (especially pretty much all security companies out there), to be the one that broke it. As I said, if you could e.g. show that you broke AES, your company becomes the de facto security industry leader.
The hostility you may observe is less about people who "dare" to muscle into their territory. We're in general quite open to criticism and we do want to hear about new algorithms. They drive the industry. When PFS became a reality, we were more than happy to embrace it because it does offer a decisive increase in security. It took away a single point of failure and meant a lot more effort on the side of an attacker, which was something that boosted security considerably.
What irks us is the snakeoil peddlers that litter the industry. Idiots who make impossible claims, knowing that most of this "security stuff" is not really easily understood by someone who isn't privy to the inner workings of encryption. So it's easy for some smooth talking con artist to sell them anything as long as it's sprinkled with buzzwords and makes outlandish claims about the key size. And here the old meme actually is true: It's not the size that matters.
And this is why we're usually wary of anything "homegrown". No "self made" security system so far could come close to the security of the tried and tested systems. And here again first and foremost because of the old axiom that nobody ever managed to crack his own security. By definition. If he could, he would have built it differently. So even if the "homegrower" was a top level security expert... think Rivest, Shamir, Schneier und Adleman rolled into a single brain ... he himself could not sensibly test his own security system because he will never ever find the flaws in it.
And the even bigger problem: Few of those that build such a "homegrown" system come close to a single one of those four, let alone all of them. Because I'm dead sure, those 4 would reach for one of the old, tried algos. Not only because most of them were actually developed by one of them (or, as in RSA, three of them).
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
There's an implicit "unless you *really* know what you're doing" to the sentence, which just tends to not be the case for most people
It's not the case for any people. You won't see professional cryptographers rolling their own crypto and using it, either.
I'm not a cryptographer myself, but I am a very experienced cryptographic security systems engineer, and I work with a bunch of serious cryptographers, who are well-published and extremely well-respected in academic circles -- exactly the sort of people who you'd expect to be most capable of designing and building custom systems. And you know what? They don't.
And I'm not just talking about creating new ciphers. Even when I go to them with novel requirements that seem to demand some sort of new construction using existing algorithms and techniques, the very first thing they do is go to the literature to see what has been done, how long it's been in use, how widely it's been reviewed and analyzed, etc. The less knowledgeable (like me, frankly, though I'm getting better) tend to start by cooking up some new scheme. Real experts avoid that if at all possible, and if they have to do something new they look really hard at how they can prove its security by reducing it to known constructions.
Even the guys who do create new ciphers do it with great care, often spending years designing and attacking and tweaking, and then their next step is to publish it so others can attack it. Only after it has survived lots of other review does anyone, especially the author, begin to trust it for real use. But the most common outcome, when something new is designed, even by serious experts, is that it gets broken shortly after publication. It's quite common for new algorithms and constructions to be broken at the same conference they're initially presented.
I reiterate: No one who knows what they're doing creates new crypto for production work.
Moreover, people who know what they're doing even approach implementation of known and trusted algorithms with trepidation! There are so many very subtle things you can get wrong. Heh, just last week someone pointed out that my implementation of a constant-time memcmp had a subtle bug that caused it to be not quite constant-time on some architectures. Novices have no idea why it even matters in crypto that memcmp always run in the same amount of time for a given buffer size, irrespective of the contents of the buffers, and assume that the C library's memcmp is fine. More knowledgeable engineers know why it matters, but really deep expertise is required to get it right. That's just one tiny example. My primary mistake wasn't the bug in my implementation, it was trying to write memcmp at all. I should have found a well-vetted implementation and used that.
Doing your own crypto is nothing like doing your own science or doing your own music. The thing about security is that it's only as strong as the weakest link; the tiniest crevice can give the attacker a wedge to bust your system wide open. Other fields are forgiving of minor flaws, you can do useful and interesting work even if it has some defects. In security, and crypto is often at the heart of security solutions, one tiny mistake can render the totality of what you did not only useless, but actively dangerous to your users.
If writing a good secure memcmp is too hard for an engineer with 25 years' experience, including 20 years doing cryptographic security, what does that say about trying to write something that doesn't appear to be trivial? Crypto is hard. Really, really hard. The more you learn about it the harder it gets, because you understand more about what can go wrong.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.