CHES2016 CTF

CHES 2016 will have a brand new Capture The Flag (CTF) event. This event will challenge novice and advanced embedded security researchers alike, by providing a platform to exchange AES implementations with various countermeasures (including against power analysis, and against firmware analysis using white box crypto). See the credits below for details of who's behind this.

Access the website at https://ctf.newae.com .

You can see a video overview of the contest:

Attack Website

There are two types of cryptographic implementations available for your browsing pleasure. They are either:

1. AES-128 running on Atmel XMEGA, with power analysis. Key not stored in firmware (attack via DPA).
2. AES-128 running on Linux computer, without power analysis. Key stored in firmware (White box).

As a user, you can submit source-code to accomplish #1, which will run the code on an embedded hardware platform.

Point System

• 'Stage-Gate' flags (such as basic CPA) are worth 10 points for all user.
• User-submitted flags are worth 50 points for the first person to capture the flag, 30 for the next, and 10 for all others.
• Capturing the flag for your own implementation is worth 30 points (to encourage users to not submit impossible implementations) for the first 4 implementations you submit (i.e., you do not receive self-points for more than 4 implementations)
• White-box crypto is worth 100 points, and does not decrease over time.

Getting Help

If you have trouble, please post at newae.com/forum. If the server appears to be down please email ctfhelp -AT- newae.com. Please DO NOT email the help for general questions, as we would like those to be answered on the forum where others will see the questions.

Note there is 3 separate servers on the backend. This website is run by one (which hosts the database), a second server is responsible for compiling & validating your C code, and a third server is responsible for performing power analysis captures.

Performing the power analysis capture takes some time (5-10 mins), so if your job has the status "running" for that long please check back later. However if your job is stuck in either "uploaded" or "queued" status, it's likely our backend server(s) have died and require a manual kick.

The following shows the server connections. Note that the wiki (this host) and the support forum are totally disconnected from the CHES CTF. Attacking these servers will not help you (they have no connection), and will make us very sad as we don't have much time to fix them.

Side Channel Power Analysis

This is a capture the flag that involves both power analysis and work creating secure implementations. It's interactive because you can both submit implementations AND break them. An automated system performs some basic validation that your AES-128 implementation is working, but relies on you to not cheat the system by doing dumb things like just adding a big delay before processing encryption.

The crypto implementations are run on an ATXMEGA128D4 processor, as part of a ChipWhisperer-Lite target. If you aren't familiar with this you can see the following resources:

• Online Documentation
• Schematic
• Original Kickstarter

Breaking Challenges

On the "Challenge" page, you'll see something that looks like this:

You can use the Traces, Source Code, and ".hex file" to help you in breaking the challenge. The following describes the format of the trace files, which you can use with your power-analysis attacks.

Trace File Format

The trace-file is a 7Zip file with a number of subfolders. 7Zip has free implementations on all systems (on Linux/Mac OS you can install the 'p7zip' or 'p7zip-full' from your repo).

First, there are folders where you ARE told the encryption key. Use these to investigate the leakage of the implementation:

Folder Name	Description
knownfixed_rand	Fixed encryption key, Random plaintext. These traces would be used in a classic CPA attack.
knownrand_fixed	Random encryption key, Fixed plaintext.
knownrand_rand	Random encryption key, Random plaintext. Typically used for HW-template generation.
knownfixed_fixed	Fixed encryption key, Fixed plaintext.

There is also a set of traces where you ARE NOT told the encryption key. This encryption key is the secret flag you must find. It will be submitted as a hex string.

Folder Name	Description
secretfixed_rand	Fixed encryption key, Random plaintext (Encryption key NOT provided to you).
secretfixed_fixed	Fixed encryption key, Fixed plaintext (Encryption key NOT provided to you).

Each folder also contains the exact script used to capture the traces on the ChipWhisperer-Lite, the text input/output, the trace data in NumPy format (can be converted to MATLAB easily), and the encryption key (except for the 'secret' capture options). The 'secret' key is not recorded anywhere, only a hash of the correct key is stored in the CTF database.

In addition a file called firmware.hex is provided, which can be programmed into an Atmel XMEGA 128D4 (such as on the ChipWhisperer-Lite or ChipWhisperer Multi-Target board). It expects an external 7.37MHz clock and uses the ChipWhisperer 'SimpleSerial' protocol (described at this page). You can use this image if you require additional investigation or want to capture more than the provided 1000 traces.

You can convert traces to a variety of formats. The following are very basic examples of such conversions, you can find more details on the File Formats page.

Converting Traces to MATLAB

You can also convert files from .npy to matlab. The following shows a simple Python script which opens all the .npy file and saves it as a .mat file. If you don't have Python installed, you can install WinPython on Windows to quickly get this script running.

import scipy.io
import numpy as np

prefix = r'2016.02.24-19.07.03'
#Can point to full directory like:
#prefix = r'C:\Temp\demo\traces_capdir48\knownrand_fixed\knownrand_fixed_P48_data\traces\2016.02.24-19.07.03'

tracedata = np.load(prefix + '_traces.npy')
textin = np.load(prefix + '_textin.npy')
textout = np.load(prefix + '_textout.npy')
key = np.load(prefix + '_keylist.npy')

scipy.io.savemat('fileout.mat', {
 "traces":tracedata,
 "textin":textin,
 "textout":textout,
 "key":key
})

Converting Traces to Binary Format (used by Daredevil attack)

The following are specific instructions which you can use to make trace formats required by the Daredevil open-source high-order CPA tool.

The resulting binary files should be placed in the same directory as the "daredevil" binary you build. You'll have make a config file (see the example CONFIG file) which includes the data printed. Replace sections of the example config file which overlap, and then adjust the type of attack you request Daredevil to perform.

import numpy as np
import struct

traces = np.load('2016.05.30-14.11.56_traces.npy')
textin = np.load('2016.05.30-14.11.56_textin.npy')

f = open('tracefile', 'wb')

for t in traces.flatten():
    f.write(struct.pack('f', t))
    
f.close()

f = open('plaintext', 'wb')
for t in textin.flatten():
    f.write(struct.pack('B', t))
f.close()

print "Add following to CONFIG:\n"
print "[Traces]"
print "files=1"
print "trace_type=f"
print "transpose=true"
print "index=0"
print "nsamples=%d"%traces.shape[1]
print "trace=tracefile %d %d"%(traces.shape[0], traces.shape[1])
print ""
print "[Guesses]"
print "files=1"
print "guess_type=u"
print "transpose=true"
print "guess=plaintext %d %d"%(textin.shape[0], textin.shape[1])

Example CPA Attack

The default challenge will fall to a straight-forward CPA attack. You must determine what secret key was used during the encryption operation. You can submit the "flag" as the hex key, for example as shown in the following photo. Be sure to select the flag you are attacking by the drop-down. Ones you've already discovered will not be populated.

Submitting a Challenge

Submitting a challenge is done by running your code through the 'virtual hardware lab'. Once the system runs the capture, you will have the opportunity to submit this AES implementation as a challenge. Flags will be removed if it's determined the challenge doesn't meet the restrictions mentioned below.

In order to submit a challenge, you must have an AES-128 implementation that meets the following rules:

• Runs on Atmel XMEGA Platform.
• Sensitive operation occurs for all 16 bytes less than 10000 clock cycles from call to encrypt function (you can perform operations such as key expansion in an "init" call that happens before power measurements are recorded).
• Does not modify clock settings of XMEGA device.
• Doesn't try dumb stuff to reveal key (like saving secret key of job #1 to EEPROM and hoping you can run job #2 on the same hardware right after, and read job #1 key out).
• Includes actual source code (you can't dumb a binary blob in the middle of a C wrapper). You can make the source code complicated however you want though.

The requirement for performing sensitive operations (such as S-Box of input) within 10000 clock cycles is because we currently have limited the system to record a total of 10000 samples at a frequency that is 1x the clock rate.

If necessary this can be increased, but will require manual intervention. To limit server bandwidth we are trying to keep the traces as small as possible! As an example the default AES-128 implementation in C only requires 3000 samples to break, so we are using 10000 as a reasonable trade-off between allowing a slower AES implementation and our internet bandwidth.

We don't want you to modify the clock settings, as the objective is everyone has the same baseline acquisition environment. Making the clock asynchronous or speeding it up will make your implementation harder to break with the baseline setup, but is relatively easy to counter by tweaking the acquisition environment. Since users cannot tweak the acquisition hardware it's only fair you don't modify the clock.

As you obtain a small number of points for breaking your OWN implementation, people might try to be clever to read-out the key used during a previous run. All such methods are disallowed, as is hacking the website or other attacks that do not involve using the power measurements. Trying to be clever like that is not allowed. Please keep a copy of the secret key you submit if it's successful. We may need to verify them to ensure no database tampering happened. Note the secret keys are NOT stored on the database - only a hash of the correct key is, so getting a dump of the database will not be useful.

Note once you submit an implementation, you do receive points for breaking it. Breaking your own implementation means you do NOT receive the time-bonus (since you have access to the traces before anyone else), but instead always receive some fixed points (currently 30 points).

Required AES-128 Format

Init Call

The init call lets you setup any variables you might need. This is called once on reset (i.e., not between encryptions). It is not recorded in the power consumption traces. The following shows an example where no setup is required:

void aes_indep_init(void)
{
    ;
}

Key Setup Call The key setup call loads the encryption key. It will be called before calling the encrypt function. It is not recorded in the power consumption traces. The following shows an example where we just store the encryption key for use later.

void aes_indep_key(uint8_t * key)
{
    for (uint8_t i = 0; i < 16; i++){
        _stored_key[i] = key[i];
    }
}

NOTE: If the key setup takes longer than 100mS, there is a chance the AES core will miss some of the plaintext sent. Commonly this results in incorrect encryption outputs even though your implementation seems to be correct. Please contact us if this happens, but it's preferable to keep your key setup call < 737000 cycles to avoid this issue. You can do a lot in 737000 cycles so it shouldn't be an issue in most systems.

Encryption Function

This function call happens immediately after the trigger for the power consumption recording goes high. You must encrypt the 16 bytes in the passed buffer, and write them back into the same buffer. The following shows an example where we call our encrypt function and copy the output back:

void aes_indep_enc(uint8_t * pt)
{
	_stored_ct = aes(pt, _stored_key);
    
    for (uint8_t i = 0; i < 16; i++){
        pt[i] = _stored_ct[i];
    }
}

As mentioned you MUST ensure the sensitive operations occur within 10000 cycles of this function call.

Zip-File Contents

For your convenience, you can download an example zip-file. This zip-file contains an AES-128 implementation in C, along with the required wrapper files.

To use this zip-file, delete the "aes.c" and "aes.h" files, and modify the "aes-challenge-c.c" file as required. If you are using assembly code it must be inserted into the "aes-challenge-asm.S" file.

The zip-file must contain the following files at minimum:

• aes-challenge.h
• aes-challenge-asm.c
• aes-challenge-c.S

ONLY those files will be compiled by the automated system. If you require additional files, you must use #include directives to include them directly into the C source code. Download the example source code for the "Basic AES-128 Implementation" to get an idea of how this will work.

You must include both the .c file and the .S file. Leave a file blank if not using (i.e., if only using C you can leave the .S file blank, as in the example).

As part of the compilation & validation the server will tell you of any errors. You must resubmit a new attempt if your compilation or validation fails (even if it's a problem on our end).

If you wish to compile the code on your own (HIGHLY recommended during debugging to avoid taxing the server systems), please download the full source code directory, described below.

Compiling Firmware as Server Does

To compile as the server does, simply download the build directory. To use this directory:

1. Unzip that directory somewhere (for example in the "firmware" directory).
2. Copy your source-codeto the firmware\simpleserial-aes\user_crypto directory.
3. To build run make in simpleserial-aes.

Running make will require avr-gcc & avr-binutils installed. You can do this on Linux platforms with something like:

sudo apt-get install avr-gcc avr-binutils

On Windows platforms, install WinAVR.

Timing your AES Implementation

One of the requirements is that leakage occurs before 10 000 cycles. How can you test this? Luckily it's possible with the Atmel Studio simulator (you can also try other simulators, but it's unknown their support for the XMEGA device).

Details of running the simulator are on the page Simulating the XMEGA Target Code.

Note what it means that "leakage" is occurring is somewhat vague. For example Stage-gate #3B does NOT cover all the first-round S-Boxs in 10 000 cycles, but people were still able to break it. Generally your AES should have somehow touched all the secret material inside that window is the objective.

White Box Cryptography

The CTF also includes a chance to apply techniques against white-box crypto. For this you are given a Linux binary, where the secret key is somehow encoded inside this binary! Extract the AES-128 key for victory.

Looking for some white-box crypto background? As a starter you might check out the paper Differential Computation Analysis: Hiding your White-Box Designs is Not Enough by Joppe W. Bos, Charles Hubain, Wil Michiels, and Philippe Teuwen.

This paper has an associated series of tools & examples you can access at https://github.com/SideChannelMarvels - hopefully this gets you started in white-box analysis.

Credits

The CHES Challenge 2016 is run by Colin O'Flynn with much external help:

• Joppe Bos, Jan Hoogerbrugge, Van Huynh Le, and Wils Michiels: Providing the whitebox crypto Implementation
• Emmanuel Prouff and Adrian Thillard: Help with setup of rules, prizes, and overall assistance
• Resources (server, ChipWhisperer framework, hosting, etc.) by NewAE Technology Inc.