CHES2016 CTF

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.

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
})

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).

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 the fixed points that a latecomer would (currently 10 points).