Slashdot Mirror

← Back to Stories (view on slashdot.org)

Poor, Homegrown Encryption Threatens Open Smart Grid Protocol

Posted by Soulskill on from the leave-it-to-the-experts dept.

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."

22 of 111 comments (clear)

  1. Homegrown by darkain · · Score: 3, Funny

    Damn those eco-friendly nuts always trying to grow things at home!

    1. Re: Homegrown by umghhh · · Score: 2

      Everybody makes mistakes. But I had to work with shit made by OMA 'experts' on other issues and quite frankly if I got my hands on them they would be running around: without balls and smeared in tar and feathers. The OMA specs or at least those few I have seen are abomination - hyperlinked documentation written by people with attention span of a chicken after its head been cut off. I actually have no problem believing the security hole is as big as said in TFA.

    2. Re: Homegrown by fisted · · Score: 4, Insightful

      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!
    3. Re: Homegrown by Opportunist · · Score: 4, Insightful

      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.
    4. Re: Homegrown by TechyImmigrant · · Score: 2

      In fact, we've often seen these "experts" exhibit hostility toward anyone who dares to question them and their systems, even when the questioner has found massive and easily exploitable security flaws.

      [Citation needed]

      If you know what you are doing and are competent to design crypto primitives, you've probably had a lot of practice and so want to meet others with similar interests and so you probably have been to the odd IACR conference (CRYPTO, EUROCRYPT, ASIACRYPT etc.) to meet these people. You would know where to publish your algorithms to receive serious cryptographic review by your peers.

      Anyone can be a dick, but being a competent crypto primitive designer entitles you to behaviour that from the outside looks dickish, but it really just a case of telling to truth to people who don't know what they don't know.
       

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    5. Re: Homegrown by swillden · · Score: 5, Insightful

      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.
    6. Re: Homegrown by swillden · · Score: 2

      No one who knows what they're doing creates new crypto for production work

      In the generalized cases, I fully agree with you. However, the successful suites of cryptography software were written by someone, presumably someone who knew what they were doing, so I'd wager that the statement is a bit over broad. Might I suggest...Only a tiny fraction of people who know what they are doing even manage to do it successfully

      No.

      The statement is precisely accurate, not overbroad at all. Yes the suites were created... but not for production use. All of the bits and pieces were created first, then analyzed and attacked for years, and only then put into production.

      And as the raft of SSL implementation and protocol bugs over the last year demonstrate quite conclusively, many of them are still put into production too soon.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  2. Head/desk... by fuzzyfuzzyfungus · · Score: 5, Interesting

    Hasn't "Don't roll your own crypto, dumbass" been one of the cardinal rules of security since sometime before WEP violated it?

    The least you can do is implement a real algorithm; but screw it up somehow (key handling is always a good place for that); but just making it up? How did they sneak this past a standards body?

    1. Re:Head/desk... by afidel · · Score: 5, Insightful

      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.
    2. Re:Head/desk... by William-Ely · · Score: 3

      There are many MCU's that have hardware acceleration for AES256 and SHA256 so there's no real performance based excuse not to use it.

      --
      Mod me down with all of your hatred, and your journey towards the dark side will be complete!
    3. Re:Head/desk... by Translation+Error · · Score: 2

      Yeah, it's the easiest thing in the world to come up with an encryption scheme that you can't break.

      --
      When someone says, "Any fool can see ..." they're usually exactly right.
    4. Re:Head/desk... by mysidia · · Score: 4, Insightful

      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.

    5. Re:Head/desk... by tlhIngan · · Score: 3

      Hasn't "Don't roll your own crypto, dumbass" been one of the cardinal rules of security since sometime before WEP violated it?

      The least you can do is implement a real algorithm; but screw it up somehow (key handling is always a good place for that); but just making it up? How did they sneak this past a standards body?

      WEP used a standard algorithm - RC4. They just accidentally screwed it up because of the way RC4 works (related to key handling and IVs).

      A homegrown algorithm for WiFi is TKIP, which was created because RC4 had hardware acceleration, while AES didn't at the time. So they created TKIP to leverage the hardware crypto alongside several protections to mitigate several shortcomings that were found.

      Even for something as simple as AES it's a chore to find an open implementation that's actively being maintained and that works with your system; and when you do one of your expensive security consultant mandates that you stop using AES for being too old and not cool enough.

      AES is fixed by standard. There is no need to "maintain" it - as long as the code compiles properly you're done.

      And for AES, because it's an official encryption algorithm, NIST has the official specification document, and the original author has the reference code.

      Of course, the vast majority of people will just use OpenSSL or LibreSSL, being BSD licensed and all that. Even on embedded systems there is often a reference AES implementation.

      That alone should be disincentive to roll your own algorithm - the fact that the standard ones are available everywhere for practically no cost and very little effort. Why write your own algorithm when you can copy and paste an existing one in? Even the lazy should see the benefits.

  3. Hipster crypto by red_dragon · · Score: 3, Funny

    "We use a custom-made encryption algorithm with organic S-boxes and artisanal feistels. You probably have never heard of it."

    --
    In Soviet Russia, Jesus asks: "What Would You Do?"
  4. Re:How many times do we have to say it? by mlts · · Score: 4, Informative

    Homegrown crypto has been a constant menace since the 1990s when people sold numerous encryption programs, usually sporting their own encryption algorithm and DES.

    A few I've seen were running 1-2 rounds of DES at most (FWB Hammer's hard disk drivers for Macs did this, but at the time, it was the best encryption one could get due to the relatively slow CPUs like 68000s at the time.) Others were seeding random() with a CRC of the password and XORing the output with the plaintext.

    However, back then, there were no government entities standardizing functions like is done now with AES, RSA, and other algos, so people had to write their own, and if it jumbled and unjumbled stuff, it was good enough, since not much in the way of ciphertext was really being attacked.

    Times are different now.

    These days, with most ARM, AMD, SPARC, POWER, and Intel CPUs having hardware AES acceleration, why would one want to roll their own algorithm?

    If one thinks AES is backdoored, cascade it with another known good algorithm like SERPENT, Threefish, heck, maybe even an older one like IDEA, 3DES, or even 3-Skipjack. There are other less known algorithms which have withstood testing as well. Cascading isn't intended to expand the bit width, but to have protection should one algorithm get broken. TrueCrypt offers/offered this functionality.

    Same with public key algorithms. Worried about RSA? Have two signatures, one RSA, and one with ECC or a lattice based algorithm that is resistant to TWIRL and quantum factoring, and validate both sigs.

    As for crypto implementations, if a user needs to encrypt a file, OpenPGP is a known standard. For communicating across the wire, SSH and SSL are known standards that are decently robust. For encrypting stuff in RAM, almost all modern operating systems have a facility like KeyChain to keep sensitive data from being swapped out, or if it is, have it encrypted.

    With almost every programming language offering hooks for AES and RSA, there isn't a need to roll crypto, even for obfuscation reasons. If one just needs obfuscation, use an AES() function with all zeroes as the key.

  5. Obligatory XKCD by Anonymous Coward · · Score: 2, Funny

    If you are going to implement your own crypto, you will screw it up, so at least make it entertaining:

    https://xkcd.com/153/

  6. Re:How many times do we have to say it? by PRMan · · Score: 3, Interesting

    In fact, you can use AES but not the recommended default values. Satoshi did this with Bitcoin, just in case the NSA was recommending those values for a reason.

    --
    Peter predicted that you would "deliberately forget" creation 2000 years ago...
  7. Re:How many times do we have to say it? by PRMan · · Score: 4, Informative

    Here is a link to the article: https://bitcoinmagazine.com/7781/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet/

    --
    Peter predicted that you would "deliberately forget" creation 2000 years ago...
  8. Re:don't fall for it. by Darinbob · · Score: 2

    Only one elliptic curve method using a set of parameters that may be been chosen by the NSA is at risk. Elliptic curve in itself is still secure as far as I know.

  9. Re:don't fall for it. by mysidia · · Score: 3

    The "pre-broken" Eliptic curve technology is a backdoored random number generator, not a cipher.

    It is not ECC itself that is broken or backdoored, only the Dual_EC_DRBG random number generator with specific input parameters.

  10. Re:Quick tell the FBI! by Anonymous Coward · · Score: 2, Insightful

    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?

  11. Re:how do i... by pushing-robot · · Score: 2

    Troll? What else would make a public utility monopoly change its ways?

    --
    How can I believe you when you tell me what I don't want to hear?