Introduction

Scan chains are a crucial part of modern integrated circuit (IC) testing and debugging. They are used in Design-for-Testability (DfT) techniques to facilitate easier testing of digital circuits, particularly complex System-on-Chip (SoC) designs. A scan chain is essentially a series of flip-flops connected in a shift register-like configuration, allowing for internal circuit states to be accessed externally. This helps in diagnosing manufacturing defects by shifting test patterns (test vectors) into the circuit and reading out responses.

However, while scan chains are valuable for testing, they can also introduce a security vulnerability. Scan chain attacks exploit these test mechanisms to extract sensitive information from chips, such as cryptographic keys. Since scan chains expose internal states, an attacker with access to scan-out data can reconstruct secret information by analyzing the circuit’s responses to controlled inputs. In this lab, you will learn about scan chains and try attacking one implemented for you on the Hackster platform.

Goals:

1. Understand the basics of a scan chain attack on cryptographic hardware a. Interact with the scan chain in the custom hardware provided for you b. Identify basic data elements within the target scan chain (e.g. input register, SPI register, control registers, encryption round registers).
2. Perform a complete scan chain attack on an AES IP block to steal intermedia values from the encryption rounds.
3. Use the intermediate values obtained from the scan chain attack to perform a simple key recovery attack on the AES implementation.
4. Implement a defense of your choice to mitigate the basic scan chain attack and demonstrate its effectiveness.

Getting Started

1. Do a git pull to get the latest version of the lab materials.
2. Open up the examples/spi_aes_scan/ project
3. Load the example bitstream onto the fpga with make run_fpga, this contains a bitstream with a known AES key (0x2b7e151628aed2a6abf7976676151301).
4. Using the provided spi_aes_scanchain.py MicroPython script for the AppMicro, encrypt and then decrypt some data.
5. Now, modify that script. After loading the value to encrypt using NORM_CS_N as before, add new code to use the SCAN_CS_N pin to put the core into scan mode and then shift out the values in the scan chain. You should be able to see the value you’ve just loaded to the SPI, as well as some other registers.
6. Modify your code again to shift in and out the values of the scan chain at every clock cycle during the IP’s operation. This will allow you to see the intermediate values of the encryption rounds, which are the most useful for the attack.
7. This IP does not have a randomised scan chain, so you could now follow the instructions from the “scan chain attack” section of the paper by Bo Yang et al. to perform a key recovery attack using the intermediate values you obtained from the scan chain.
8. When you are ready to proceed, download lab01_scan_files.zip from Moodle and extract it. This zip file contains the unique AES IP file for you to attack, as well as a template for the csv file you need to fill out for the attack. You’ll just be attacking your own [zID].bin file, so make sure to use the correct one for your zID.
9. You will now need to identify the scan chain order in your unique AES IP file and fill out the csv file, before writing your attack code to extract the intermediate values and perform the key recovery attack.
10. Once you have completed your attack, you can start working on your defense. You can choose any defense mechanism you like (preferably one we taught in class), but it should be effective against the basic scan chain attack you performed in this lab. Build it into the code provided.
11. Finally, write up your summary and submit all your files in a zip file on Moodle according to the instructions below.

Deliverables and Weightings:

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

• Submit to Moodle a single zip file containing:
  • aes_scan_attack/:
    • This directory contains the attack on your provided AES IP, with at least the following files:
      • [zID].bin:
        • This is the unique AES IP file we provided you with. Provide a copy of it back to us.
      • [zID].csv:
        • This file should provide details of your IP’s unique scan chain layout. It provides evidence that you were able to at least extract information about the scan chain. Complete the table as provided. The LSB is provided for you.
      • aes_scan_attack.micro.py:
        • (MicroPython suitable to run on the Application processor)
        • This program should launch and complete the entire AES attack sequence. It can optionally also complete the brute-forcing. If so, you need no other files.
      • aes_scan_attack_brute_force.py:
        • (OPTIONAL Python script suitable to run on a normal host machine)
        • This program, if provided, should complete the attack by running the brute-forcing over the partial data provided by the aes_scan_attack.micro.py file.
      • [zID].aes_key.txt:
        • This file should contain the hexadecimal value of the key you recovered from the attack. If you were not able to recover the key, do not include this file, but provide an explanation in the summary.pdf of why you think you were not able to recover the key and what you think went wrong. If you were able to recover the key, provide a short explanation in the summary.pdf.
  • aes_scan_defense/:
    • This directory contains your defense against the scan chain attack, with at least the following files:
      • spi_aes_scan_defended/:
        • This directory should contain the Verilog code for your defense. Start it by copying the spi_aes_scan/ directory provided in the eaxmples/ of the hackster-programmer repository. You should modify the code in this directory to implement your defense.
  • summary.pdf:
    • This file should briefly explain your attack and if you were successful or not.
    • Then, in more detail, it should cover the defense you implemented, how it works, and how to test it. It should also include a demonstration of the effectiveness of your defense (e.g. screenshots of attack failure, etc.).
    • For full marks, the summary should also include a discussion of how your defense works and its limitations against new or more sophisticated scan chain attacks from the literature. Limit 4 pages, any reasonable format.

Resources

• Bo Yang, Kaijie Wu, and Ramesh Karri. 2005. Secure scan: a design-for-test architecture for crypto chips. In Proceedings of the 42nd annual Design Automation Conference (DAC ‘05). Association for Computing Machinery, New York, NY, USA, 135–140. https://doi.org/10.1145/1065579.1065617
  • Section 2 lays out the method for a scan attack on AES.

Grading Rubric

Attack (6%)

• Criterion:
  • (2%) Correct identification of scan chain elements:
    • Poor (0.5%): Solely identifies the spi_shift_reg elements.
    • Fair (1%): Correctly locates more than 50% of the aes_text AND aes_control elements.
    • Good (1.5%): Correctly locates more than 75% of the aes_text AND aes_control element.
    • Excellent (2%): Correctly locates all spi_shift_reg, aes_text, AND aes_control elements.
  • (2%) Successful extraction of intermediate values:
    • Poor (0.5%): Fails to extract any intermediate values from the scan chain.
    • Fair (1%): Extracts some intermediate values but with significant errors or omissions.
    • Good (1.5%): Successfully extracts most intermediate values with minor errors.
    • Excellent (2%): Accurately extracts all relevant intermediate values from the scan chain.
  • (2%) Key recovery attack:
    • Attempted (0.25%-1%): Some attempt at key recovery is made, but it is incomplete or incorrect (i.e. candidate keys are identified but brute forcing is not performed, or brute forcing is performed but does not yield the correct key).
    • Successful (2%): Successfully recovers the key using the intermediate values obtained from the scan chain attack.

Defense (4%)

• Criterion:
  • (2%) Implementation of defense mechanism:
    • Poor (0.5%): The defense mechanism is poorly implemented or does not function as intended. The implementation may be incomplete or contain significant errors (i.e. it does not compile or run).
    • Weak Defense (1-1.5%): The defense mechanism is implemented but it is flawed or only partially effective. The implementation may have some issues that limit its effectiveness against the scan chain attack, i.e. it may only prevent some types of basic scan attacks.
    • Excellent (2%): The defense mechanism is robustly implemented and effectively mitigates the basic scan chain attacks covered in class.
  • (2%) Written explanation and demonstration of defense effectiveness:
    • Poor (0.5%): Poorly written explanation with little to no demonstration of the defense’s effectiveness. The explanation may be unclear, incomplete, or lack evidence of the defense’s impact on the attack.
    • Fair (1%): A written explanation is provided, but it may lack clarity or depth. The demonstration of the defense’s effectiveness may be weak or not fully convincing.
    • Good (1.5%): A clear written explanation of the defense is provided, along with a demonstration (i.e. screenshots, logs, or other evidence) that shows some effectiveness against the scan chain attack. The explanation should include a discussion of how the defense works and its limitations against new or more sophisticated scan chain attacks from the literature. Does not exceed 4 pages and has a reasonable format.
    • Excellent (2%): A comprehensive and well-written explanation and evidence that clearly shows that the defense effectively prevents the scan chain attack. The explanation should include a discussion of how the defense works and its limitations against new or more sophisticated scan chain attacks from the literature. Does not exceed 4 pages, has a reasonable format, and is enjoyable to read.