Close

Does this project spark your interest?

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

ChipWhisperer®: Security Research

Open Source Hardware Security Analysis

7 148 124
Enjoy this project?
Share on twitter   Share on Facebook

This project was created on 04/29/2014 and last updated 2 days 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 $30k+), making this the project that brings all sorts of fun tools to every engineer or developer interested in embedded security. It's fully documented (including tutorials) making it possible to really get started on your own, at a cost of $300 instead of $30000.

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

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.

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, 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 audiance. I'm hopng 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.

What's Involved?

And here is basically what the system entails. It's 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.

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. This can also mean doing analysis at the same time as capture via a SQL database, or even doing analysis on larger clusters of computers.

The capture software controls the ChipWhisperer FPGA board or another oscilloscope along with the target device. The GUI is a pretty full-featured piece of software which looks something like this:

_images/capture.png

You should also look over the full documentation - there is a whole bunch of tutorials, so you can even get started without building the hardware! If anything kills open source projects it's not having simple getting started documentation, so I'm trying to ensure that doesn't happen to me. Here's a quick shot of some of the official documentation:


Interesting FPGA Blocks

This project has a number of FPGA blocks - all the ones below I've designed as part of this project, and not pulled from somewhere else. Many of them can be ripped out for use in your own project (I've tried to keep everything as modular as possible). Where possible I re-used existing blocks (such...

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
  • AES-256 Is Not Enough: Breaking a Bootloader

    3 days ago • 0 comments

    I'd been pushing hard trying to get a demo of how you can break an AES-256 bootloader. This type of bootloader is often used in products for protecting firmware updates and a good demonstration of why you should care about side channel attacks as an embedded engineer.

    It's not pretty but it does work, so I wanted to put some documentation and details up here. To start with, what bootloader should I target? I don’t want to give someone a bad name, since the point of this blog post is that any similar bootloader can be attacked. For this reason I’ve chosen to implement my own, but basing it on a number of real bootloaders I studied.

    Hopefully this will demonstrate that it's not enough just to check the box that says 'AES', even if you've done everything else right (not using ECB mode, etc.).

    Note: If you've linked directly to this page, check out my Complete ChipWhisperer project on Hackaday.io too for other interesting posts!

    Background

    The bootloader uses AES-256 in CBC (Cipher Block Chaining) mode. The system is used like this:

    A nice ‘feature’ of CBC mode from our perspective is that (A) we don’t need to worry about the secret Initialization Vector (IV) for performing the  Channel Analysis (SCA), and (B) once we have the encryption key we only need the IV to decrypt the first block, since we use the ciphertext which we know as the other input to the XOR.

    Anyway the complete AES-256 decryption looks like this (lifted from the AES implementation I'm using  Ilya O. Levin, http://www.literatecode.com ):

    aes_addRoundKey_cpy(buf, ctx->deckey, ctx->key); aes_shiftRows_inv(buf); aes_subBytes_inv(buf); for (i = 14, rcon = 0x80; --i;) { if( ( i & 1 ) ) { aes_expandDecKey(ctx->key, &rcon); aes_addRoundKey(buf, &ctx->key[16]); } else aes_addRoundKey(buf, ctx->key); aes_mixColumns_inv(buf); aes_shiftRows_inv(buf); aes_subBytes_inv(buf); } aes_addRoundKey( buf, ctx->key);

    The XORing of the IV is done with the final output of that function, since that function is the 'Electronic Code Book (ECB)' implementation.

    The critical thing to notice is that we’ll actually do a SCA attack twice in a row. The first time we target the output of the first S-Box. This gives us the first 128 bits of the decryption key. We then use that knowledge of the first 128-bits to target the next round of the decryption, which gives us the following 128-bits.

    Getting the second half of the 256-bit key is a little tricky. The ‘mixColumns’ operation uses 4 bytes of input to generate 4 bytes of output, which at first would make it seem like we would need to be guessing 4 bytes. But due to the linear nature of mixcolumns, we can slide it further along in the algorithm. This means we won’t directly determine the next 128 bits, but instead will determine a version of the key, which when passed through mixcolumns generates the correct key.

    To obtain power measurement traces, we’ll just send some garbage data to the system. This works because most bootloaders look something like this:

    The system will decrypt the garbage data. The signature will fail meaning the data is thrown away, we don’t care about that (yet). We’ll be able to get the correct signature later to force the system to accept our new image. We can obtain the encryption key without finding that signature.

    Side Channel Analysis to Encryption Keys

    So when capturing traces, the power measurements look like this:

    If we line up a bunch (say 20) traces we see the following:

    You can see they remain very well synchronized until about point 7100. At this point the AES actually has non-constant execution time, as this implementation has a timing side-channel as well! This will make our life a tiny bit harder, as I’ll need to resynchronize the last half of the traces. Anyway after running an attack as normal, the first 128 bits (16 bytes) of the decryption key are revealed after about 50 traces (i.e. I sent 50 packets to the device only):

    The correct key is selected based on the output...

    Read more »

  • Glitching an Android Smartphone

    11 days ago • 0 comments

    Here's another interesting glitch attack: a regular Smartphone. I've made a small demo video to show you what happens, I just presented this at the HTCIA Atlantic conference here in Halifax, NS, Canada. So I thought I'd share it more widely as I bet it's of interest to you. I couldn't get the embedded video to work on this project log, so here's a link to it on YouTube (you can't actually click the image sorry):

    The details are similar to my Linux glitch demo from below, so I won't duplicate too much. It uses a MOSFET again to cause the glitch, which shorts the power pins to the SoC device on the android phone. My target code is again a double-loop which increments a variable.

    Again I'm able to glitch the application without crashing the phone or causing other negative effects! This is pretty interesting as it shows you can cause incorrect data to be processed... this could cause anything from bypassing the lock screen to inserting faults in the encryption running on your phone.

  • Updated Build Instructions + BOM, New FPGA Programming

    a month ago • 0 comments

    I've been working on a few things. The first is an updated support forum at https://newae.com/forum which will serve as a method of users discussing the project. This is not only for ChipWhisperer-specific stuff, but any general open-source side-channel analysis projects (or that's the idea).

    I've also updated the main Wiki Page with a little more clear links to information. Along with this I went through & updated the BOM + Build instructions for the ChipWhisperer Baseboard, and added those for the LNA + Differential Probe. So it's not major updates but makes things a lot more useful I think!

    Finally on the SW side: the FPGA Project is now programmed from a zip file with all the partial reconfiguration information present. No longer do you need to deal with ensuring two different files match or worry about changing line ends when getting a file from GIT. The zip system makes your life easy.

View all 9 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 a month 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 3 months ago null point

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

Are you sure? [yes] / [no]

coflynn wrote 3 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 4 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 4 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 5 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]