Researchers Break FPGA Encryption Using FPGA Encryption

FPGAs are awesome — they can be essentially configured into becoming any computing device you want. Simply load your selected bitstream into the device on boot, and it behaves like a different piece of hardware. With great power comes great responsibility.

You might try to hack a given FPGA system by getting between the EEPROM that stores the bitstream and the FPGA during bootup, but FPGA manufacturers are a step ahead of you. Xilinx 7 series FPGAs have an onboard encryption and signing engine, and facilities for storing a secret key. Once the security bit is set, bitstreams coming in have to be encrypted to protect from eavesdropping, and HMAC-signed to assure that they are authentic. You can’t simply read the bitstream in transit or inject your own.

Researchers at Ruhr University Bochum and Max Planck Institute for Cybersecurity and Privacy in Germany have figured out a way to use the FPGA’s own encryption engine against itself to break both of these security guarantees for the entire mainstream 7-series. The attack abuses a MultiBoot function that allows you to specify an address to begin execution after reboot. The researchers send 32 bits of the encoded payload as a MultiBoot address, the FPGA decrypts it and stores it in a register, and then resets because their command wasn’t correctly HMAC signed. But because the WBSTAR register is meant to be readable on boot after reset, the payload is still there in its decrypted form. Repeat for every 32 bits in the bitstream, and you’re done.

Pulling off this attack requires physical access to the FPGA’s debug pins and up to 12 hours, so you only have to worry about particularly dedicated adversaries, but the results are catastrophic — if you can reconfigure an FPGA, you can make it do essentially anything. Security-sensitive folks, we have three words of consolation for you: “restrict physical access”.

What does this mean for Hackaday? If you’re looking at a piece of hardware with a hardened Xilinx 7-series FPGA in it, you’ll be able to use it, although it’s horribly awkward for debugging due to the multi-hour encryption procedure. Anyone know of a good side-channel bootloader for these chips? On the other hand, if you’re just looking to dig secrets out from the bitstream, this is a one-time cost.

This hack is probably only tangentially relevant to the Symbiflow team’s effort to reverse-engineer an open-source toolchain for this series of FPGAs. They are using unencrypted bitstreams for all of their research, naturally, and are almost done anyway. Still, it widens the range of applicability just a little bit, and we’re all for that.

[Banner image is a Numato Lab Neso, and comes totally unlocked naturally.]

Oracle V Google Could Chill Software Development

Unless you’ve completely unplugged from the news, you probably are aware that the long-running feud between Oracle and Google had a new court decision this week. An appeal court found that Google’s excuse of fair use wasn’t acceptable and that they did infringe on Oracle’s copyrights to Java. Oracle has asked for about $9 billion in damages, although the actual amount is yet to be decided. In addition, it is pretty likely Google will take it up to the Supreme Court before any actual judgment is levied.

The news is aimed at normal people, so it is pretty glossy about what exactly happened. We set out to try to make sense of it all. We found a pretty good article from [Michaela Barry] about what the courts previously found.  There were three main parts:

  • There were 37 API (Application Programming Interface) declarations taken verbatim from Java. This would be like a C header file if you aren’t familiar with Java.
  • Google decompiled 8 security files and used them.
  • The rangeCheck function — 9 lines of Java code — were exactly the same in Oracle’s Java and Android.

Continue reading “Oracle V Google Could Chill Software Development”

Oracle CSO To Customers: Leave The Vulnerabilities To Us

[Mary Ann Davidson], chief security officer of Oracle, is having a bad Tuesday. The internet has been alight these past few hours over a blog post published and quickly taken down from oracle’s servers. (archive) We’re not 100% sure the whole thing isn’t a hack of some sort. Based on [Mary’s] previous writing though, it seems to be legit.

The TL;DR version of Mary’s post is that she’s sick and tired of customers reverse engineering Oracle’s code in an attempt to find security vulnerabilities. Doing so is a clear violation of Oracle’s license agreement. Beyond the message, the tone of the blog says a lot. This is the same sort of policy we’re seeing on the hardware side from companies like John Deere and Sony. Folks like [Cory Doctorow] and the EFF are doing all they can to fight it. We have to say that we do agree with [Mary] on one point: Operators should make sure their systems are locked down with the latest software versions, updates, and patches before doing anything else.

[Mary] states that “Bug bounties are the new boy band”, that they simply don’t make sense from a business standpoint. Only 3% of Oracles vulnerabilities came from security researchers. The rest come from internal company testing. The fact that Oracle doesn’t have a bug bounty program might have something to do with that. [Mary] need not worry. Bug Bounty or not, she’s placed her company squarely in the cross-hairs of plenty of hackers out there – white hat and black alike.

Wireless Weather Station

High schooler [Vlad] spent about a year building up his battery-operated, wireless weather station. Along the way, not only has he learnt a lot and picked up useful skills, but also managed to blog his progress.

The station measures temperature, humidity, pressure and battery voltage, and he plans to add sensors for wind speed, wind direction and rainfall soon. It is powered via a solar panel and can run on a charged battery for a full month. The sensor module transmits data to a remote receiver connected to a computer from where it is published to the internet. Barometric pressure is measured using the BMP180 and the DHT22 provides temperature and humidity values. The link between the transmit and receive sections uses a 433MHz Superhetrodyne RF Kit which gives [Vlad] a range of 50m. There’s an ATMega328 on the transmitter and receiver side. He’s taking measurements once every 12 minutes, and putting the micro controller in low power mode using the Rocket Scream Low Power Library. A 5W, 12V solar panel charges the 6V Lead Acid battery via a LM317 based charge circuit. This ensures the battery gets charged even when the solar panel is not receiving optimal radiation. One hour of sunlight provides enough charge to keep it going for 2 days. And a fully charged battery will keep it running for a full month even when there’s no sunlight.

The server software consists of two parts. The first pushes serial data to a mySQL database. This is written in Visual Studio C# using help from Oracle mySQL connector. The second part publishes the entries in the mySQL database to the web server. This is written in php, and uses  Libchart for graphing. He’s got the code, schematics, parts list and a lot of other information available for download on his blog. There’s a couple of items pending on his to-do list, so if you have any tips to offer post your comments below.