Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

ChipWhisperer®: Security Research

ChipWhisperer laughs at your AES-256 implementation.

18.4k 8 174 137

This project was created on 04/29/2014 and last updated 9 hours ago.

Description
ChipWhisperer is the first complete open-source solution for embedded hardware security research including side-channel power analysis and glitching. Tools from commercial vendors cost considerably more (think starting at $30k+), and they often have less features. This project that brings all sorts of fun tools to every engineer or developer interested in embedded security. It's fully documented, including tutorials to get you started, bridging the gap between academic research and in-the-trenches engineering.

The objective of the ChipWhisperer project is nothing short of revolutionizing the entire embedded security industry. Every engineer/hobbyist who needs to use encryption in their design should be able to perform a side-channel attack, and understand the ramifications of such an attack on their product. The open-source nature of the ChipWhisperer makes this possible, and my hope is that it becomes the start of a new era of hardware security research.
Details

**NOTE: I'm currently editing the project description for Hackaday Prize Final Submission, and things may appear badly organized until this is complete. This might take until the deadline of the 27th, so sorry about the fumbling around with all this**

Links to project details (GIT, Wiki, Docs) are on the left. The laziest introduction to this project is the 2-minuite video created for The Hackaday Prize quarterfinals (i.e. the first video I made):

A slightly longer introduction appeared as a 5-minuite video for the semifinals (i.e. the second video), see below:

The most commitment is reading this page! Well if you are still reading, strap yourself in...

What's This About?

Lots of people have tried to design secure systems, and alas there is lots of failures. But what if you did everything correct: no buffer overflows, no unsanitized inputs, no default passwords. Unfortunately this isn't good enough - even perfectly implemented encryption algorithms such as AES-256 will reveal encryption keys. It's not due to incorrect implementation, it's a fundamental artefact of their design.

This has been known for a long time - the first paper on this was published in 1998. But if you are an engineer or independent researcher tools to get started are expensive, or require you to do a lot of work yourself scripting together lower-cost tools. This project is my attempt to eliminate this problem.

I'm eliminating the problem for good by making my tools open source. Because this whole area is an active research area, the tools need to be open source. This isn't a case of attempting to seem sexy by adding the word 'open-source', but placing something of commercial value into the open-source domain, in the hope it spurns a larger community. Think of something like Wireshark - it's extremely valuable, and could easily be sold as a high-end product. But most of that value comes from it being open source, and hence containing a huge array of protocol dissectors, far beyond what a commercial vendor could support. For my designs, part of the larger community includes hours of tutorials on this area - the objective of ChipWhisperer is not just the cool engineering that went into the software and hardware, but having tutorials and documentation that could be used as a complete course in side-channel analysis and glitching.

It's also worth stressing that there is no 'tricks' in the open-source nature of this project. It's not just part of the design that's open source, I'm not using a restrictive non-commercial license, and I've already had people build these units from PCB design files (so I know they are complete!). Again the objective of this is project is to open up this area of research to a much wider audience. I'm hoping the commercial value I'm giving up (by allowing anyone to make these units, and not forcing them to buy them from me) is far outweighed by the community this project builds up.

It's useful to point out how critical this field of embedded security has become, and why it's interesting to see attacks against AES (which I tend to focus on in my demos). The 'Internet of Things' requires some wireless communication network - be it IEEE 802.15.4, ZigBee (which uses 802.15.4), or Bluetooth Low Energy. Since these are wireless protocols security is of paramount importance - and the designers acknowledge that. Attacks against AES are interesting because all three of the previous protocols use AES-128 for security. Unfortunately AES-128 isn't just a "check box" that indicates your system is secure, despite one document being bold enough to list that because Bluetooth low energy has 128 bit AES, it's "secure against attack and hacking" (see page 45). The idea that implementations are secure because the underlying algorithm is secure will cost somebody a lot of money when it blows up in their face, and they have to fix millions of already deployed devices.

Assuming designers aren't foolish enough to send encryption keys over SPI (see Travis Goodspeed with his example attacks), and have actually done the implementation correctly, and haven't introduced backdoors, we can still break the AES implementation. This isn't a theoretical attack, but a real-world attack that every embedded designer needs to understand. It's clear that very few embedded engineers are aware of this issue, based on how infrequently it is brought up when looking over datasheets, design specifications, and application notes. And no, it's not enough to use hardware accelerators - an attack has been demonstrated against the XMEGA crypto engine (presentation slides, details on page 77 of thesis, article at ACM behind paywall). See the 2684 pages of Bluetooth specification for example, not a hit for 'side channel' to be found:

ChipWhisperer won't secure the internet of things. But it will hopefully jolt people into believing that "secure because math" isn't a good enough answer. Even these theoretically unbreakable cryptographic algorithms have great weaknesses during implementation, and they may be much easier to break than you ever assumed. So let's start looking into how this works.

Side channel analysis takes advantage of the fact that it takes a small amount of power to change the state of digital lines. Switching from a 'zero' to a 'one' takes a small charge for example. Many digital ICs will also push the lines into a 'pre-charge' state in-between transitions to reduce the worst-case time delay, such that on every cycle the bus goes from an intermediate state to a final state. For us this means we can almost directly infer the Hamming Weight (number of one's) on a digital bus based on the power consumption.

So what does that give us? Consider that we had the following system, which is a simple XOR of some input data with a secret key, where we don't see the final output:

While we can build the following matrix, given some known inputs along with the associated hamming weights:

Then one can simply guess what the secret key was! Based on our guess we can determine which guess best aligns with the real measurements. In the following example if the secret key was 0xEF, we would end up with the hamming weight matching our observations:

Finally, the reason this works so well is that it allows us to break a single byte of the encryption key at a time! Thus the minimal guess-and check means guessing 256 possibilities for each byte, and doing that 16 times:

For more details see my write-up on the theory of a CPA attack, along with a nice example of step-by-step breaking of the AES using Python from my ChipWhisperer tutorial list. For the attack to work, we basically just need to be able to tell the encryption/decryption algorithm to operate while we monitor the power, and know either the output or input to the system.

This can be done with ~20 power traces on an AVR device for example, so it's not a case of taking an unrealistic number of measurements. For example see a real-time example of me breaking an AES-128 implementation in 120 seconds.

Glitching is another devious attack on embedded systems. This takes advantage of the fact that at some point in your code you'll have a test of the input password, signature, or whatever else. So consider we have this code:

It's actually possible to manipulate the system to cause that check to fail, or for instructions to be skipped. One method of doing this is inserting a quick glitch into the clock, as the following example from the ChipWhisperer shows:

This "double-edge" causes timing errors in the target device. The result of this varies, but often results in an instruction skip or the wrong result of a comparison to be loaded. As an example see my video showing clock glitching breaking a password check.

If you are looking for some additional detail see the full ChipWhisperer clock glitching tutorial, which includes a 35 minute video tutorial.

Even somewhat more interesting, is the fact you can do this with 'power glitching'. This means inserting some sort of low-voltage spike into the VCC line of the device you are targetting. This works even for advanced chips, like a Raspberry Pi or Android Smartphone. The VCC line glitch might look like this:

This can cause a user-land application to fail on something like an Android smartphone - here is an example where I'm causing an incorrect calculation, this example comes from my project log update:

There is a full ChipWhisperer VCC glitching tutorial too which targets an AVR microcontroller, in the same fashion as the clock glitching tutorial. Now that you get an idea of why these attacks are so interesting, let's look at what ChipWhisperer can do.

The system is a fusion of closely operating FPGA blocks and a Python interface communicating over a high-speed USB 2.0 interface. It even uses partial reconfiguration to reprogram the Spartan 6 FPGA during operation to fine-tune certain parameters that would otherwise be fixed when implementing the FPGA. Remote database storage of traces is used to power high-performance analysis, levelling the playing field for the independent researcher who doesn't have access to a very expensive computing hardware.

Having the computer connectivity of the hardware is fundamental to the operation of this device. In addition it's possible (and sometimes required) to have the device split over several locations via a network. This can mean the ChipWhisperer is running on one computer, with data being saved to a larger network store. Even for researchers who do have local access to a high-performance computer, the remote storage is often useful, since the physical attack may be occurring at a different spot from the analysis computer.

The blocks themselves can be implemented into many different FPGAs - this system is not limited to only the capture hardware created as part of this project.

Read more »

Components
  • 1 × NPCB-CWCR2-02, Assembled Main PCB See https://www.assembla.com/wiki/show/chipwhisperer/CWRev2_Capture_Component_Assembly_Procedure for details. Gerbers are present in repository, or can buy from HW Store.
  • 1 × ZTEX 1.11c FPGA Module ZTEX 1.11C FPGA Module, Spartan 6 LX25 Module. Buy from ztex.de.
  • 1 × NAE-OPENADC-0.02, Assembled ADC Module OpenADC Module, See OpenADC Project for assembly instructions. Can buy from HW store too.
  • 1 × Multi-Target Victim Board Can use Multi-Target board (see Wiki for details) or your own target device.
  • 1 × Misc. Cables 20-pin IDC Cable, SMA Cable, USB Cables

Project logs
  • HackadayPrize, 0.08RC1, Papers Please

    7 days ago • 0 comments

    Lots of fun updates! First, I'm honoured to have made it to the final five for the Hackaday Prize. There has been a ton of work showing up on all these projects, so it must have been a razor-thin margin between the projects that made it and the ones that didn't, and a lot of time spent by the judges! Thanks to all involved for this.

    Next, I've pushed the 0.08RC1 release, available on the software release page. The 0.08RC1 release supports all the features you need for the AES-256 bootloader attack, so go ahead and download the sample traces and break the bootloader yourself. This includes the Python-based analysis script feature which I think will become one of the core functions for the CW-Analyzer due to it's flexibility. I'm still hoping to add some additional support for remote networked capture boxes in the coming week or two.

    Finally, two academic papers that might be of interest to you (I swear). The first explores the use of clock recovery with the ChipWhisperer. You can read a version of it on IACR EPrint, and I'm happy to announce it was accepted into the Journal of Cryptographic Engineering, so will appear there at some point in the future. This paper goes to show that having open hardware and software will make it easier than ever for researchers to duplicate my work... it's simply not possible to have this level of transparency in how I obtained my research results without invoking the open-source model.

    The second is a paper based on my work attacking the AES-256 bootloader. The paper isn't totally finished yet, but I've got a version of it on my own website for now. Once it's more polished I'll upload it to IACR E-Print. But it goes to show the results of attacking the XOR operation in the I.V. of the AES CBC mode.

    Speaking of papers, I recently discovered that my OpenADC project has been used by a few other researchers doing work into low-power wireless networks and ended up in some published papers. It's definitely cool to see these tools propagating 'in the wild'. I've added links to my main project description with those papers.

  • AES256 Bootloader Tutorial

    10 days ago • 0 comments

    Just a quick update - I've got a major chunk of the documentation for the AES-256 bootloader attack online. This is uploaded as part of the online ChipWhisperer documentation. The fun thing is you don't need hardware to follow along - I've uploaded an example capture (part of the larger set of examples). You need to clone the ChipWhisperer GUI in GIT for this to work and follow the installation instructions elsewhere in the online documentation. I'm going to shortly make a release of the ChipWhisperer software which includes the features required for this tutorial. I hope to upload a video tutorial of this when I get some more time - so far the online documentation isn't quite complete (doesn't include the IV example yet or signature), but the cool part is there at least!

    So go ahead - spend an afternoon breaking an implementation of the AES-256 decryption! What fun! If you get stuck leave a comment here or register on the NewAE Forum. And if you'll be around Paris hunt me down at CARDIS 2014, as I'll be attending that next month.

  • CARDIS 2014, Product Testing

    12 days ago • 0 comments

    First off - I'm planning on attending CARDIS 2014 which is Nov 5-7 in Paris, France. If you happen to be going let me know, as will have my ChipWhisperer platform with me. I'll try to bring some blank PCBs to give away, although I've got to check on my stock status!

    The second thing I wanted to show is the iterations of my 'product test boards'. This part of the blog post isn't part of the ChipWhisperer open-source project but related to it. As part of selling a commercial version, I want to ensure that commercial version meets certain quality specifications. So I needed ways to test the board, and I wanted to catch even small errors (wrong part values mounted, etc). My first test jig was just to verify the switching regulators on the main board. This used mechanical switches to switch a load on-off, and a mask limit test on an oscilloscope for pass/fail:

    This was transitioned to a board under USB control, using a USB-HID implementation via the LUFA library. This now meant that the loads could be switched on/off electronically, with the same idea of an oscilloscope performing the mask limit testing. The left half of my test board provides this feature, but it also adds a lot more. Here is the automated power supply test jig:

    There's still a lot more things that need testing! In particular there is 6 GPIO connections. These are critical to the ChipWhisperer's function, as they are expected to pass everything from communications to high-speed glitches. A bad solder joint or missing decoupling capacitor on the driver might allow it to pass a 'simple' function test (high/low), but fail when you tried to use it in real life. So I use a bank of relays to allow me to turn on/off a termination resistor for each output, and also route the pins together. Since they are I/O pins I need to test both input and output. These allow me to check:

    • Drive Strength (driving high-frequency square wave into terminator resistor)
    • Shorted input/output pins (one pin turned into output at a time, rest are inputs. Toggling output pin shouldn't affect inputs, if it does suggests solder bridge on translation IC)

    In addition there is circuitry to check the 'AVR + XMEGA' programmer built into the ChipWhisperer, which is just a pair of chips mounted on the test board. As part of the test script it reprogram/verifies them multiple times at maximum supported SPI speed (~2MHz). There shouldn't be any errors, or it suggests problems with the physical signals.

    Finally there is a LVDS driver to check the LVDS clock input, and resistive loads to check the +7V/-7V power supply output voltage & ripple. The following photograph shows the rest of the connections to the test board. I haven't shown all the oscilloscope probes in either of these photos - if testing a number of boards all of the outputs are wired up to a scope, and a mask on each channel makes testing a lot quicker!

    Anyway I thought that might be of interest to some people! It's part of the answer to the question "how do you make money with open hardware?". In this case my answer is that a lot of people (companies, universities, etc) want to buy a finished product that they know works. For them they would rather buy something that is known to work, and not spend even half a day fixing/building it themselves!

View all 13 project logs

Discussions

Jasmine wrote 2 months ago null point

Hello coflynn, I think you've hit most of the requirements to be considered for the next round of the Hackaday Prize, but I couldn't see links to code repositories, libraries, licenses or permissions needed for your project. Please add these before August 20th.
Thanks for entering and good luck!

Are you sure? [yes] / [no]

coflynn wrote 2 months ago null point

Thanks for the notes - the code was hidden underneath another link ('sources') and the licenses were only mentioned there. I'll fix up the page to have clear links...

Are you sure? [yes] / [no]

Tiago wrote 4 months ago null point

Great project! How much does it cost you to manufacture it?

Are you sure? [yes] / [no]

coflynn wrote 4 months ago null point

Thanks! If you DIY everything I think it's about $300-$400 depending how much of it you build. The FPGA board is $200 which is the main cost, although it's possible to build part of the FPGA file for cheaper boards (Spartan 6 LX9 boards). These versions have less features but still useful...

Are you sure? [yes] / [no]

Mike Szczys wrote 5 months ago null point

Thanks for entering this one in The Hackaday Prize.

Good luck with your talk at Recon. Any chance that will be available online?

Are you sure? [yes] / [no]

coflynn wrote 5 months ago null point

Definitely will be available online - I'm not 100% sure if the RECON folks record the talks, but if not I'll upload my own version!

Are you sure? [yes] / [no]

Eric Evenchick wrote 6 months ago null point

Nice to see some open information on the black magic of side-channel analysis. Thanks for sharing this.

Are you sure? [yes] / [no]

Similar projects