POWER PLAY — 512-bit RSA key in home energy system gives control of virtual power plant It took $70 and 24 hours for Ryan Castellucci to gain access to 200 MW of capacity.
Dan Goodin – Aug 9, 2024 1:07 pm UTC Enlarge reader comments 15
When Ryan Castellucci recently acquired solar panels and a battery storage system for their home just outside of London, they were drawn to the ability to use an open source dashboard to monitor and control the flow of electricity being generated. Instead, they gained much, much moresome 200 megawatts of programmable capacity to charge or discharge to the grid at will. Thats enough energy to power roughly 40,000 homes.
Castellucci, whose pronouns are they/them, acquired this remarkable control after gaining access to the administrative account for GivEnergy, the UK-based energy management provider who supplied the systems. In addition to the control over an estimated 60,000 installed systems, the admin accountwhich amounts to root control of the company’s cloud-connected productsalso made it possible for them to enumerate names, email addresses, usernames, phone numbers, and addresses of all other GivEnergy customers (something the researcher didn’t actually do).
My plan is to set up Home Assistant and integrate it with that, but in the meantime, I decided to let it talk to the cloud, Castellucci wrote Thursday, referring to the recently installed gear. I set up some scheduled charging, then started experimenting with the API. The next evening, I had control over a virtual power plant comprised of tens of thousands of grid connected batteries. Still broken after all these years
The cause of the authentication bypass Castellucci discovered was a programming interface that was protected by an RSA cryptographic key of just 512 bits. The key signs authentication tokens and is the rough equivalent of a master-key. The bit sizes allowed Castellucci to factor the private key underpinning the entire API. The factoring required $70 in cloud computing costs and less than 24 hours. GivEnergy introduced a fix within 24 hours of Castellucci privately disclosing the weakness.
Further ReadingBreaking 512-bit RSA with Amazon EC2 is a cinch. So why all the weak keys?The first publicly known instance of 512-bit RSA being factored came in 1999 by an international team of more than a dozen researchers. The feat took a supercomputer and hundreds of other computers seven months to carry out. By 2009 hobbyists spent about three weeks to factor 13 512-bit keys protecting firmware in Texas Instruments calculators from being copied. In 2015, researchers demonstrated factoring as a service, a method that used Amazon cloud computing, cost $75, and took about four hours. As processing power has increased, the resources required to factor keys has become ever less.
Its tempting to fault GivEnergy engineers for pinning the security of its infrastructure on a key thats trivial to break. Castellucci, however, said the responsibility is better assigned to the makers of code libraries developers rely on to implement complex cryptographic processes.
Expecting developers to know that 512 bit RSA is insecure clearly doesnt work, the security researcher wrote. Theyre not cryptographers. This is not their job. The failure wasnt that someone used 512 bit RSA. It was that a library they were relying on let them.
Castellucci noted that OpenSSL, the most widely used cryptographic code library, still offers the option of using 512-bit keys. So does the Go crypto library. Coincidentally, the Python cryptography library removed the option only a few weeks ago (the commit for the change was made in January).
In an email, a GivEnergy representative reinforced Castelluccis assessment, writing:
In this case, the problematic encryption approach was picked up via a 3rd party library many years ago, when we were a tiny startup company with only 2, fairly junior software developers & limited experience. Their assumption at the time was that because this encryption was available within the library, it was safe to use. This approach was passed through the intervening years and this part of the codebase was not changed significantly since implementation (so hadn’t passed through the review of the more experienced team we now have in place). Page: 1 2 Next → reader comments 15 Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at @dangoodin on Mastodon. Advertisement Channel Ars Technica ← Previous story Next story → Related Stories Today on Ars
