Introduction

Power analysis attacks are a type of side-channel attack that exploit variations in the power consumption of a device to extract sensitive information, such as cryptographic keys. These attacks are particularly effective against embedded systems and hardware implementations of cryptographic algorithms.

In this lab, you will learn about power analysis attacks and how they can be used to compromise the security of a cryptographic implementation of AES-128.

Goals:

1. Understand the basics of power analysis attacks on cryptographic hardware
2. Understand the target AES implementation and how to interact with it using the provided hardware and software tools
3. Design a suitable strategy for performing a correlation power analysis attack on the AES implementation by choosing a target clock cycle which would help you to identify the key
4. Perform a complete correlation power analysis attack on the AES implementation to recover the key

Getting Started

1. Do a git pull to get the latest version of the lab materials.
2. Open up the examples/power_aes_no_io/ project
3. Load the example bitstream onto the fpga with make run_fpga, this contains a bitstream with a known AES key (0x00112233445566778899aabbccddeeff). You won’t be able to observe very much - just dim colors on the ICE and RGB LEDs. This is expected, as:
4. This bitstream contains a simple AES-128 implementation which is connected to a 128-bit linear feedback shift register (LFSR) which is used to generate the plaintext input to the AES. Each operating cycle, the LFSR shifts and generates a new plaintext input to the AES, which then performs a complete encryption. The only output of the AES is provided via an LED.
5. The file top.v contains the top-level finite state machine which controls the operation of the AES and LFSR. Open it up and see how the LFSR and AES are being triggered, and how a few of the ouputs from the AES are being fed to the LEDs. Also see how the ICE_LED is being controlled.
6. This implementation is vulnerable to a power analysis attack, as the power consumption of the device will vary based on the operations being performed and the data being processed. By measuring the power consumption of the device during encryption, you can potentially extract information about the key being used.
7. Using your two provided SMA-BNC cables, connect the two SMA connectors on your Hackster to two channels of your oscilloscope. Now, configure the oscilloscope to use the ICE_TRIG signal as a trigger, and display the power consumption of the device on the other channel. You should be able to make a clear, repeating capture which shows the different clock cycles of the AES encryption process.
8. Now, you need to design a strategy for performing a correlation power analysis attack on this AES implementation. This will involve choosing a target clock cycle during the AES encryption process which you think will be most informative for recovering the key. You will then need to write a program in Python which will analyse the power traces you capture from the board and perform the correlation power analysis attack to recover the key.
9. In each “run” of the cryptographic hardware, the top-level module does the following:

• Waits N clock cycles
• Advances the LFSR to generate a new plaintext input
• Outputs the ICE_LED / ICE_TRIG signal to indicate the start of the encryption process (this is what you should be using as a trigger for your oscilloscope)
• Triggers the AES to perform an encryption with the new plaintext and the fixed key
• Repeats

10. By resetting the core, we can reconstruct the value of the LFSR at each of the encryption cycles, and therefore the plaintext input to the AES at each cycle. Then, because we know the key is fixed in each encryption, by correlating the power consumption data with the known plaintext and key values, we can identify which key is being used.
11. The LFSR is also implemented in top.v. It is a 128-bit LFSR with taps at bits 127, 109, 85, and 0. At reset it is initialised to 128'hACE1ACE159C359C3B386B386670D670C. Each cycle, the LFSR shifts left by one bit, and the new LSB is calculated as the XOR of the bits at the tap positions. You can use this information to reconstruct the plaintext input to the AES at each cycle.

• the first five cryptographic inputs it will generate are:
  • Plaintext 0: 59C359C2B386B387670D670CCE1ACE18
  • Plaintext 1: B386B385670D670ECE1ACE199C359C30
  • Plaintext 2: 670D670ACE1ACE1D9C359C33386B3860
  • Plaintext 3: CE1ACE159C359C3B386B386670D670C1
  • Plaintext 4: 9C359C2B386B387670D670CCE1ACE183
    • Hopefully you can work it out from here!

12. This pattern of operations is what makes it possible for us to perform the CPA attack straightforwardly.
13. To automatically collect the power traces for the core, run make run_fpga_power. This resets the board and captures 5000*1024 power values from the Hackster’s internal ADC, which are then saved to a file called power_data.txt. These are collected based on the trigger signal, so they are aligned with the AES encryption cycles. You can use this data to perform your correlation power analysis attack.
14. Open up this file and take a look.

• It will have many repeating rows of power consumption
• Each capture is separated by four zeros, making them easy to distinguish.

15. When you are ready to proceed, you should download from Moodle the Lab2_Bitstreams.zip and find the (your zID)_lab2_spi_aes.bin and (your zID)_lab2_power_aes_no_io.bin corresponding to you.

    • You can run these bitstreams by:

      • Power bitstream (regular operation for oscilloscope capture):

      $ ZID=(your ZID) make run_fpga
      

      • Power bitstream (capture power using onboard ADC):

      $ ZID=(your ZID) make run_fpga_power
      

16. These are variants of the AES implementation you have been working with, but with a unique key.

17. To begin with, use the oscilloscope to capture the power trace of your implementation while it is running. You should see a similar pattern to what you saw with the example bitstream, but with different values. Once you have the oscilloscope set up, take a screenshot and save it to a USB drive. You will hand this in as part of you deliverables.

18. Your goal is to now perform the CPA attack on your implementation.

19. Once you think you are done, you can check your answer by using the lab2_spi_aes.bin bitstream, which contains the same AES implementation (with your same cryptographic key) but with an SPI interface rather than the LFSR. You can encrypt some values and see if the key you recovered from the CPA gives you the ciphertexts you would expect!

Deliverables and Weightings:

This lab is worth 10% of your final grade for this course.

• Submit to Moodle a single zip file containing:
  • aes_cpa_attack/:
    • This directory contains the attack on your provided AES IP, with at least the following files:
      • (your zID)_lab2_power_aes_no_io.bin, (your zID)_lab2_power_aes_no_io.bin:
        • These are the unique AES IP files we provided you with. Provide a copy of them back to us.
      • power_data.txt:
        • This file should contain the power trace data you captured from the board while running the lab2_power_aes_no_io.bin bitstream. You can capture this data by running make run_fpga_power ZID=(your ZID).
      • power_trace.png:
        • This file should contain a screenshot of the power trace you captured from the board while running your bitstream. You can capture this data by running make run_fpga_power ZID=(your ZID), and then taking a screenshot of the oscilloscope display showing the power trace. An example of what this should look like can be found in the lecture slides for Week 4, slide 24.
      • lfsr.py:
        • This file should contain a Python implementation of the LFSR which you can use to reconstruct the plaintext inputs to the AES at each encryption cycle. If called directly, it should print out the first 10 plaintext values generated by the LFSR in hexadecimal format.
      • aes_cpa_attack.py:
        • This program should launch and complete the entire CPA sequence by taking the power trace data from power_data.txt, reconstructing the plaintext inputs using the LFSR, and performing the correlation power analysis to recover the key. It should output the recovered key in hexadecimal format.
      • (your zID)_lab2_aes_key.txt:
        • If you obtained a key, this file should simply contain the hexadecimal value of the key you recovered from the attack.
        • If you were only able to recover some bytes of the key, this file should contain the hexadecimal value of the bytes you recovered, and a note about which bytes you think they correspond to (e.g. “Recovered bytes 0-3: 0x00112233”).
        • If you were not able to recover any bytes of the key, instead provide a brief explanation of the challenges you faced and why you think you were not able to recover the key.

Resources

• “Linear Feedback Shift Registers” - https://en.wikipedia.org/wiki/Linear-feedback_shift_register
• “Correlation Power Analysis with a Leakage Model” - https://link.springer.com/chapter/10.1007/978-3-540-28632-5_2
• “Correlation Power Analysis” - http://wiki.newae.com/Correlation_Power_Analysis

You will likely find the pseudo-code for the attack in the lecture slides for Week 4 helpful - see Slide 79.

Grading Rubric

Correlation Power Attack (10%)

• Criterion:
  • (2%) Power capture screenshot
    • Fail (0%) No attempt, or screenshot does not show power trace clearly.
    • Pass (2%) Clear screenshot showing the power trace captured from the oscilloscope.
  • (2%) Reconstruction of plaintext inputs using LFSR
    • Fail (0%) No attempt, or incorrect implementation of LFSR.
    • Pass (2%) Correct implementation of LFSR and successful reconstruction of plaintext inputs.
  • (6%) Successful recovery of AES key using CPA
    • Fail (0%) No attempt, or completely incoherent implementation of CPA attack.
    • Genuine Attempt (1-2%) Attempted CPA attack but did not recover any bytes of the key.
    • Limited Success (3%) Attempted CPA attack and recovered at least one byte of the key correctly.
    • Partial Success (4-5%) Attempted CPA attack and recovered at least half of the key.
    • Pass (6%) Correct implementation of CPA attack and successful recovery of the AES key.