ChipWhisperer®: Security Research

It's happening! For the past few months I've been working on making a lower-cost version of the ChipWhisperer. I've now completed enough prototype tests to be confident of my ChipWhisperer-Lite:

Because the cool thing to do is have crowd-funding, I'm running a Kickstarter to make this widely available! The assembled/tested boards will go for about $180 USD. The single-unit Digikey parts cost is about $90 USD and it's a 4-layer PCB, so it's a pretty reasonable price (I think). Of course it's still open-source so you can build your own or do whatever else you want.

I'll have more details of this coming up, but the Kickstarter is live so please check it out! I've got some prototype boards made up already so plan on having a give-away if there is enough to spare (got to check they all work first).

Hard to believe it's been 2+ months since my last update! Anyway I've been working on an updated software release, along with firmware for the new ChipWhisperer-Lite. But to go with the new software release I wanted to (finally) have signed drivers, so you can do something like this:

No more "unsigned driver" warning! Unfortunately it just costs money to do this - there's no easy way around it, so I had put it off for the longest time. There's a great guide by David Grayson to the whole process which I used.

If you also need to repeat this I posed some step-by-step instructions to my own blog too. They are basically just notes I used form David, so don't add much. So in conclusion, that is the least fun way to spend $562 (the cost of a 3-year certificate). On to more fun ways to spend money!

Lately I've also been having fun with a combination of the T962A oven with open-source firmware for soldering, and a Silhoutte Cameo for cutting solder paste stencils. It's a much faster way of assembling compared to my mostly hand-soldering or hot-air iron I'd been using in the past. I hope to have a complete video up on that - for now I've got a quick video on the stencil cutter part:

This also gives you a view of the assembly of the ChipWhisperer-Lite board! Hope you find it interesting.

For a while now I've been planning the low-cost version of ChipWhisperer, which I call 'ChipWhisperer Lite'. The idea is to integrate everything onto a single board, and use a lower-cost FPGA (Spartan 6 LX9 instead of LX25). Some features will have to be dropped (such as the SAD trigger) to fit this device, but for most users it'll be perfect. I also plan on bringing this hardware with me for the training course I'll be running.

Here's a quick screen-shot of the basic PCB parts placement. The right half is the 'Target Board', which will be a break-away from the capture hardware (left half):

One of the more interesting aspects of the design will be the change of USB interface chip. To keep costs down I'm not using the Cypress EZ-USB chip. Instead I'll be using a Atmel SAM3U, and providing my own firmware. I'm hoping to publish the firmware for use in other projects - lots of people want high-speed USB connectivity for their FPGA project. I think this can be made into a nice generic solution, and will be cheaper than anything else (including the FTDI FT2232H).

I've got a SAM3U-EK dev-kit which I've done some experiments on, and it seems to be 'sufficiently fast'. It won't be as high-bandwidth as the EZ-USB solution which can almost max out the USB transfer bandwidth, but considering that this board doesn't have on-board SDRAM, that won't be an issue (not as much data to transfer!).

As a side-note: I've got some longer-term plans to release a whole bunch of USB firmware solutions for low-cost chips. Both Atmel & Microchip make some nice USB microcontrollers which are very low-cost - with the right firmware they could be turned into USB-Serial, USB-Parallel Port, USB-Keyboards, etc. But back to the project at hand:

Current estimates of the BOM cost are about $100 in single-unit quantities (the analog portion alone is ~$40), so would expect to sell around $300 (BOM x3 is fairly reasonable estimate). But this version won't have BGA parts - all TQFP (albeit small pitch), so it should be well within the realm of 'hand assembly' possible. This will make it the lowest cost version available by a long shot, and I really want to keep a version of this hardware at the "hand-assembly" level.

I also appreciate all the kind remarks about this project getting second place for HaD Prize too! It's been an honour to make it so far in the face of such intense competition, and having seeing a *lot* of the other cool projects that were involved (beyond just the final five), I was very pleased with those results. It's been a fun ride of course, but lots of work still to do, so no time to rest yet ;-)

CARDIS

As a reminder: I'm headed to CARDIS next week in Paris, so hopefully get a chance to meet some people in person!

Mooltipass

I had a few questions about if this project could attack the Mooltipass project. I haven't had a lot of time to look it over in detail, but the actual AES-256 implementation isn't too critical for that project. That's because the only time the key is in use is when you physically have the card inserted into the device - without the card the system won't be processing encryptions.

From a side-channel analysis perspective, attacking the Mooltipass main unit would be pointless. If you had physical access to tamper with the hardware, there is easier things to do. The real question is how secure is the Smart Card used for storing the secret key. This is something I haven't investigated... I know there was previously published attacks against these devices, see for example these slides and paper [2011], also this paper [2012] and this paper [2010]. I've barely had time to read those in depth, so will reserve any judgement until I've got more time! In the mean-time I ordered a bunch of the smartcards used by the Mooltipass to play with. The most likely scenario is that it's possible to break the card, but it takes long enough that you would (hopefully) notice it missing, and could invalidate the affected passwords. If someone really wanted to get your passwords they could always use a big wrench anyway, so it's all about managing the threat.

EDIT: Something else that's worth point out, is it's trivial to purchase smart cards with higher security levels. They are considerably more expensive than the ones being used in the Mooltipass, but if you really wanted to ensure your Smart Card is secure it's possible to do. This might require some work on both the smart card & the mooltipass itself, but one of the nice parts of open hardware is nothing is set in stone. If this was a commercial solution they would probably only ever support the one card, but you aren't locked in like that due to the open-source nature.

0.08 Release

I pushed the 0.08 release. This includes a few goodies, the most interesting is a tutorial on replicating the XMEGA attack. It also includes some fixes for VISA-connected scopes along with documentation for them. That's all for now!

Long ago when I started prototyping ideas, I was using a $89 FPGA Board (Avnet LX9 board). The ChipWhisperer system has always supported this board, but it's not as well documented as my newer, fancier hardware. I wanted to make a log post to demonstrate this system still working, as if you have a 'passing interest' in side channel analysis (SCA), this setup is a MUCH cheaper method of getting started. It's a lot slower than the full ChipWhisperer Capture Rev 2 hardware and due to the smaller FPGA doesn't support any features besides simple analog capture. It's all the same FPGA code (using my project management described in another log file), just with stuff missing to fit into the LX9 device.

This isn't the only cheap option, the Papillio Pro can also be used too which is even cheaper ($85), and there is a cheaper OpenADC you can build with more limited sample rate called the OpenADC Lite. Here's some of the cheap options:

Setting up the LX9 board with the homemade OpenADC looks like this, where the total cost will be in the $150 vicinity ($89 for FPGA, about $50 to build the OpenADC, $10 for random stuff):

You can also build an AVR target on a breadboard, here shown with a 'commercial' OpenADC module:

For your viewing pleasure here is a video version of the complete setup & attacking AES on the AVR. You can see it still only takes about 30 measurements of the power consumption to break AES, so it's the same resulting attack performance as my full-blown hardware. The main difference you see here is the slower capture, but it still takes under 2 minuites to perform all 50 power measurements, so it's far from unreasonable speed!

Fun with Plot.ly

Through other entries in the HaD Prize I became aware of plot.ly, which is basically something akin to a 'cloud-based' plotting service. This sounds somewhat insane at first - of all the things I want in the cloud, plotting complicated mathematical graphs probably isn't one of them.

But when combined with distributed analysis and remote solving, this might be more reasonable than you expect. In particular if you have multiple processes running, at some point you need to collect and plot (or otherwise analyze) this data. Due to the mentioned embarrassingly parallel nature of the side-channel analysis problem (see project details for more on this), you can frequently plot the output of each analyser instance independently. Since each instance is probably headless, and you almost definitely wouldn't want to manually combine this data, using a cloud-based service actually might be easier than writing a protocol to collect the data and then plot it locally. In addition if you are using something like Amazon EC2 anyway, using plot.ly means you would be communicating from Amazon's network directly to plot.ly, which is probably going to be much faster than my internet connection downloading data from all the independent nodes!

So despite by misgivings about cloud-based plotting service, I do see for some limited applications where it is easier than plotting locally on my computer. So if you are willing to be dragged kicking and screaming through a cloud-based plotting example, I'll show you how it works. The objective is to end up with a web-based graph which looks like this for example (correlation output vs. sample number):

If you want to see this yourself go to https://plot.ly/~coflynn/1 (and ignore the attempt to get you to sign up). This is showing you that for Byte 0, the maximum correlation was detected around sample point 38, with the correct key-byte hypothesis of 0x2B. I'll demonstrate how I created this graph on my attack system.

First off, we'll again use the Python-based analysis script. One of the default API calls which will be attempted is called doneAnalysis() once the attack is complete. It's at this point we'll plot the required data. The default template does not have a doneAnalysis() call, so you can simply add one like the following shows:

Inside that doneAnalysis() function, you can paste the following, where the user & token can be seen by going to the example plot page when you are signed in:

    def doneAnalysis(self):
        data = self.attack.getStatistics()
        data = data.diffs

        py.sign_in("YOUR_USER", "YOUR_TOKEN")
        traceList = []

        #Example plots first byte only
        for bnum in range(0,1):
            diffs = data[bnum]
            prange = self.results.graphoutput.getPrange(bnum, diffs)

            #Get correct key from plotting module, can override here too
            self.results.graphoutput.setupHighlights()
            highlights = self.results.graphoutput.highlights

            newdiff = np.array(diffs)
            for j in highlights[bnum]:
               newdiff[j] = 0

            maxlimit = np.amax(newdiff, 0)
            minlimit = np.amin(newdiff, 0)
            hyp = highlights[bnum][0]
            traceList = [Scatter(x=prange, y=minlimit, fill='tozeroy',
                                       line=Line(color='green'), name='Min Others'),
                         Scatter(x=prange, y=maxlimit, fill='tozeroy',
                                       line=Line(color='green'), name='Max Others'),
                         Scatter(x=prange, y=diffs[hyp],
                                       line=Line(color='red'), name='Byte %d=%02x'%(bnum, hyp))
                        ]

        data = Data(traceList)
        plot_url = py.plot(data, filename='CPA Attack Example')
        print plot_url

Then you have to add some imports at the beginning of the file:

import numpy as np
import plotly.plotly as py
from plotly.graph_objs import *

Pretty easy! Most of the above code was adapted from my OutputVsTime class in the ResultsPlotting.py file, including the min/max fill code. This is required since you'd otherwise be plotting 256 lines overtop of each other, which is very slow when displaying on plot.ly (see a test if you don't believe me). You can of course just plot all the lines if you want, but this way you only have to plot 3, which is much much faster.

There is some other reasonable use-cases for plot.ly too. You can monitor the output of an attack on a small computer (i.e. checking your smart phone whilst you are at the pub waiting for it to finish), and it would be ideal for sharing scientific results. Having the graph on plot.ly would be a big step up from just a rasterized version of the results, since it gives people access to the data in a usable form.

If you really want, it's possible to add an Upload to Plot.ly button to the GUI, since the API calls are almost the same as the internal plotting functions. But for me the only situations that make sense to use plot.ly are where you can't see/control the GUI, such as remote/headless computers, so I don't see much value in such a button.

Updated LNA PCBs

Enough cloud stuff for now, let's talk hardware again before getting back to cloudy things. I've made some small updates to the LNA PCB. Mostly improvements in the silkscreen, but I also add some exposed copper such that you can solder a shield over the RF portion. The shield would actually connect onto the SMA jacks themselves, so would have to be a custom-bent piece of metal, or possibly even just some copper tape. It wouldn't be pretty, but it should work a treat.

There's also updates to the Differential Probe PCB, along with some small fixes to the other boards pushed to GIT. I plan on adding a new feature to the diff probe which shows you when the null offset is correctly set, avoiding the need to check the offset voltage before use, so will post details of that when I get a chance.

Side-Channel as a Service

Unlike all my other posts, this topic will describe some ideas to give you an idea where this project might go. The features described here do not exist in the codebase though, I haven't had time yet, but thought it would be interesting to read where this project might go.

I realized that many academic researchers don't actually care about the hardware, and are simply interested in testing their algorithms in hardware (i.e. for side-channel resistance). As such it would be possible to build a rack of ChipWhisperer + Target boards, and researchers could simply 'rent' access on those boards. They would like to be able to download algorithms to the target device, control the ChipWhisperer device, etc. They don't necessarily need to physically have the hardware on their desk.

This would ideally allow the researcher to communicate with the ChipWhisperer hardware over a network connection, i.e. using the same GUI to touch a device anywhere in the world. Whilst the current level of abstraction would allow this easily by packaging commands in UDP/TCP connections, this might seem like too much of a hack, instead of using something more along the lines of a REST API to touch features of the ChipWhisperer hardware.

But deploying a REST API without considering if it's really the best solution would also be a hack. Having considerable experience with various IoT projects (including being part of developing Zigbee-IP, 6LoWPAN, Contiki-uipv6, and some miscellaneous events), and having seen the over-application of certain technologies, I'm always a little sceptical that REST is always the solution. So Sidechannel as a Service might need to wait a bit to figure out the real use-cases, and determine what makes the most sense for an interface.

For now I've been using these devices remotely via a VNC connection. I actually have one server with a ChipWhisperer-Capture connected to it. When I need to do long captures I connect to this computer via a VNC client, setup the capture, and then run the capture over VNC. Because there is more than just sending commands to the ChipWhisperer-Capture (i.e. you also need to communicate with the target device, which might rely on drivers on the host computer), this solution has worked well for me. It allows me to easily disconnect from the server and log in periodically to check progress. But it requires some thought about how to move forward.

First off - I decided to write some FAQs. I was going to add them to the main project details, but I've hit a maximum character limit in my detail! So for now I've copy/pasted them here, sorry for the big old wall of text! I also wanted to talk about my FPGA project management, see after the FAQs for those details.

FAQs

Q: Why did you use an FPGA, they are pretty complicated, can you get away using a raspberry pi or something?

A: Unfortunately it's not possible. You need to capture at a very fast rate, even something like the HackRF would be very boarderline on the capture speed. The objective is to capture on every clock edge - so even a 7.37MHz micro needs at least 7.37 MS/s, but I usually use 4x the clock rate, requiring 29.4 MS/s. This isn't even for a medium-speed ARM type device!

It's possible to use Software Defined Radio (SDR) tools, but it's far from ideal, and you'll be limited in your attack targets. The SDR tools without an FPGA cannot perform the advanced pattern-based trigger, and may not even support a basic edge-type trigger.

If you are capturing with a regular oscilloscope instead of my synchronous capture method the bandwidth requirement is about 10x the clock rate of the DUT, sometimes even (much) higher for hardware encryption implementations. In addition the FPGA adds a lot of features such as triggering based on analog pattern and super high resolution glitch generation which is impossible without the FPGA.

Q: Couldn't you just have used a Red Pitaya for the hardware?

A: Had the Red Pitaya existed when I first started this project, I probably would have tried to use it, as it's a pretty nice development environment! Unfortunately it still cannot be used as-is, so I still would have ended up with something like the ChipWhisperer in it's current form. The front-end of my OpenADC adds up to +55dB gain which is software adjustable, whereas the Red Pitaya has only a fixed small range which would require an external amplifier. The OpenADC also has a huge analog bandwidth (beyond the sample rate for undersampling applications, which the synchronous sampling can exploit), whereas the Red Pitaya limits you to the Nyquist rate. Finally the ChipWhisperer still adds a bunch of extra features such as the target programming interface, power supplies for probes, high-slew-rate level translators for clock input and output, an external PLL chip for low-frequency operation, and a high-speed USB interface.

Q: Couldn't you have just used GNURadio as a software framework?

A: My original intention was to use GNURadio as a GUI, since it has a lot of built-in blocks such as filters which would be useful. But the requirements of side-channel analysis are different enough from communications systems to make the use of GNURaido seem like a hack, and would require considerably more work than my current GUI.

In addition the install procedure for GNURadio on Windows can be pretty complicated. I really wanted as straight-forward an application as possible, and I felt that the barrier to entry for most people would be considerably raised if using GNURadio. Long-term, I may end up with blocks for GNURadio that perform some of the analysis.

Q: What's the deal with the commercial version?

When I first started this project, one of the main requests was that people wanted to just buy the finished hardware. Spinning out of that is the complete commercial version with fancy waterproof case etc. It's no different from what you can build yourself, but comes fully tested and in a nice storage case!

The ChipWhisperer name is a registered trademark, and this was done in part to allow me to reliably sell a commercial version of the project. Only products sold via NewAE Technology Inc are allowed to use the ChipWhisperer name, but this doesn't stop someone else from selling a version under a different name. I want to ensure that the commercial version is of the highest quality, and wanted to avoid someone selling a cheap poorly-assembled version that at first appearance appeared to be a product from my company!

Xilinx Project File Managment

The second part of this log post is a little more interesting (I hope). The Xilinx ISE tools use an XML-based project file. Unfortunately it's difficult to commit that project file to the repository - it uses all sorts of automatically overwritten properties, including the version of the software:

What this means is that if you have two people working on the project, you are almost guaranteed to have merge conflicts, since if they have different versions, the file will change on both their machines in that line. Since each install is >10GB people tend to be pretty slow up updating the version of their software.

The other issue is that I want to support several versions of the hardware. This means supporting different FPGA devices with different modules enabled. This would otherwise mean multiple project files, and changes would have to be carefully managed across them. This is a recipe for failure! There is even COREGen blocks with are automatically generated, and normally have tons of options you must specify. For someone to port the design to a slightly different FPGA (different package of same FPGA, different device within same family, etc) they must manually recreate all those blocks. And if they forgot to set an option properly the design won't work.

I decided to fix this with a bit of Python, and I'm going to be forever grateful I did. Basically there is one '.in' file, which contains simple lines. The beginning of the file looks like this:

The InputFile is a 'template', which is really just a default Xilinx ISE project file. The next section simply finds parameters and overwrites their values, allowing you to overwrite ISE version, device type, etc. For example if you need to set a specific map command-line option, we can do that as follows:

Note how the option is set in the resulting .xise project file. Easy! If you want to generate a .xise file for another package, you simply change that one 'package' line as appropriate.

The next section of the input file has a list of all the source code. These are inserted into the .xise project file as such:

Finally we come to the COREGen files. This section can be used like the verilog sources, but the interesting part is the ability to autogenerate COREGen files based on an input. The first section simply lists all the COREGen files:

The next sections can list details of the files. For example for my ADC FIFO I can configure the depth. Not only does it set the proper depth in the resulting .xco COREGen file, it also calculates other required parameters such as output depth, assert values, etc:

Finally, the resulting .xco files are kept consistent with the device package that was configured earlier in the project file! So you no longer have to manually recreate the .xco COREGen files, they are automatically generated for you based on the single input settings! Yah!

The final section of the project file managment is the ability to write a "define" file. If you look back at my example Verilog files, there is one (setup.v) that is without a path. But it does have a name, which links to the section name in the project file:

This will simply create a file called setup.v, where the above will be defined. So the file looks like this:

For my project that file defines the hardware in use. It is included in each Verilog source file, and if there is hardware-specific configuration it can be managed with simple `ifdef `endif sections that include/exclude certain modules. The result is I end up with a single input file that defines everything about the FPGA project. You can run a Python script which then generates the 'dirty' ISE files. If we need to add a new configuration option to the project, you can trivially add it to the original project file.

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, which is still in progress. The pre-print is available from IACR E-Print service (not sure where the final version will end up yet, if anywhere). 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.

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.

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!