pqps (Post-Quantum Power Sandwich)

2019-10-01 Markku-Juhani O. Saarinen [email protected]

Experimental tools for PQC energy measurements.

2019-12-02: There's a write-up about this now on arXiv: Mobile Energy Requirements of the Upcoming NIST Post-Quantum Cryptography Standards. The results were first presented at the 7th ETSI/IQC Quantum Safe Cryptography Workshop in Seattle on November 7, 2019: slides.

What's this about ?

My original motivation was to establish a straightforward model from "cycle counts" to "Joules" for new (post-quantum) asymmetric cryptographic algorithms. The null hypothesis was that the relationship is largely linear and algorithm-independent. This turned out not to be true for the Cortex M4 microcontrollers; there is 50+% variation in average power depending on what type of cryptographic primitive the MCU is processing. See bottom of this page for an initial summary.

I also "modded" the SUPERCOP Cryptographic Benchmark to do similar energy measurements on desktop/laptop/server systems using Intel's built-in RAPL energy counters. See the directory pqps/suppercop for a discussion about that.

Embedded Measurements

This little tutorial and software package explains how to use the X-NUCLEO-LPM01A -- a high-precision controlled power supply board -- to measure power consumption of cryptographic algorithms of a Cortex M4 target. The board is commonly called "PowerShield" in ST documentation, and I'll use that name here as well. Note that PowerShield is also used in the "industry standard" Ultra-Low Power (ULP) benchmark ULPMark.

PowerShield can be used in many ways, but its main intended configuration is to create a development board sandwich with a STM32 Nucleo-32/64/144 board (the number refers to number of pins in the LQFP or UFQFPN packaging of the MCU chip) using Arduino connectors on both boards. So we have two boards on top of each other, PowerShield on top, supplying power to the target board:

This set-up excludes some older boards such as STM32F407G-DISC1 that is used by the PQM4 project where I will be lifting most of the evaluation targets from. The "discovery board" is also little bit awkward as it requires an additional USB serial dongle (or a hardware mod) for serial communications.

So I chose to use a little bit cheaper NUCLEO-F411RE board. This board also supports external SMPS (switched-mode power supply) for Vcore logic supply, which is precisely what we want and use. Mostly the specs of STM32F411RE (the chip on this Nucleo64) are similar to STM32F407VGT6 (the chip on Discovery); importantly both are Cortex M4 with (single-precision) floating point and DSP instructions. The F411RE has only 512kB of Flash and 128kB of SRAM and lacks a TRNG, and can be clocked only to 100 MHz; however it comes from the "Dynamic Efficiency" product line, being hopefully more efficient than the Discovery.

Manuals

• UM2243 User Manual: STM32 Nucleo expansion board for power consumption measurement

• UM2269 User manual: Getting started with PowerShield firmware

• UM1724 User Manual: STM32 Nucleo-64 boards (MB1136)

• STM32F411RE Datasheet: STM32F411xC STM32F411xE Arm Cortex-M4 32b MCU+FPU, 125 DMIPS, 512KB Flash, 128KB RAM, USB OTG FS, 11 TIMs, 1 ADC, 13 comm. interfaces

• RM0383 Reference Manual: STM32F411xC/E advanced Arm-based 32-bit MCUs (big!)

So.. What kind of gear do I need?

I use Ubuntu Linux 18.04 LTS and only open source software tools for this lab.

We paid £53.68 for the X-NUCLEO-LPM01A (PowerShield) board and £10.48 for NUCLEO-F411RE (Target) with a local UK component retailer in September 2019. There seems to be good availablity of these boards; we had them delivered the following day.

The PowerShield has a micro-B USB connector, while Nucleo-64 boards have a Mini-B connector. So you need both of these cables to connect to your PC's Type-A (that common big USB) or Type-C (new) connectors (£5).

It's helpful to have an USB extension cable and an USB hub with individual on/off switches for each ports (something like £10).

Software

For building on Debian/Ubuntu you'll need "make" and other build essentials (sudo apt install build-essential) and also a suitable ARM cross compiler.

You can install the default compilers with sudo apt install gcc-arm-none-eabi (or similar). I'm using GNU Tools for Arm Embedded Processors 8-2019-q3-update downloaded from the ARM Website myself.

For flashing the target I use st-flash which is part of the open source stlink package. I built this from sources.

The scripts use bash and Python3 for serial communication (sudo apt install python3-serial and dependencies).

Measurement Mods

UM1724 states that "SB12 NRST (target STM32 RESET) must be OFF if CN4 pin 5 is used in the external application." Anyway, this is not your typical accidental solder bridge but a surface-mounted zero-ohm resistor. Just carefully heat both ends of the resistor until it comes off. Since there is some solder residue, I used a multimeter to check that the connection is really off.

There are other measurement options, but this is the currenct configuration used in measurements.

• On PowerShield: Jumpers of power supply pin: Close jumper AREF_ARD, open jumper 3V3_ARD.
• On Nucleo64: Open Jumper IDD.
• On Nucleo64: Remove solder bridge SB12 to disconnect reset signal from ST-Link part.
• On Nucleo64: Remove solder bridge SB2 disconnecting 3.3V voltage regulator LD39050PU33R.

I followed the instructions in Section 1.2 of UM2269 "Quick setup to measure current on board Nucleo64" (AREF_ARD, 3V3_ARD, IDD, SB12) and additionally disconnected SB2; Section 6.3.3 of UM1724 "External power supply input: +3.3V".

Jumpers on PowerShield.	IDD Jumper on Nucleo64.	Solder Bridge SB12.	Solder Bridge SB2.

The current measurement program (main.cpp) uses pin D7 on the Nucleo64 board to trigger beginning of measurements. This is supported by the standard firmware.

Note on the serial interface

We will be dealing with two serial interfaces simultaneously; on my system they appear as /dev/ttyACM0 and /dev/ttyACM1. In order to find their unique identifier paths, you can list and access them by their unique identifiers: ls /dev/serial/by-id.

The PowerShield line feed dicipline is little strange. For direct access I use picocom (sudo install picocom) like this (as noted, the path is little different for you due to the unique identifier):

picocom --echo --imap lfcrlf --omap crlf /dev/serial/by-id/usb-STMicroelectronics_PowerShield__Virtual_ComPort_in_FS_Mode__FFFFFFFEFFFF-if00

Try issuing the help command to get a command summary.

UM2269 states that the PowerShield baudrate is 3686400, but I really don't know how to make that work (and it actually sounds littble bit crazy). setserial -av <powershield device> gives a base rate of 38400 anyway.

My pqps firmware is configured to communicate at 115200 baud; add -b 115200 as a picocom parameter if needed. This is easily changed in main.cpp.

Compiling PQC implementations from PQM4

The measurement was ran on implementations from the pqm4 "Post-quantum crypto library for the ARM Cortex-M4". However I'm using a different target board and the ARM Mbed OS v2 runtime libraries instead of libopencm3 that the pqm4 uses.

So, first get the distribution and unpack pqm4 inside it:

git clone https://github.com/mjosaarinen/pqps.git
cd pqps
git clone --recursive https://github.com/mupq/pqm4.git

If everything is fine, you can attempt to build some target with

$ make PQALG=pqm4/crypto_kem/kyber768/m4

[CPP] main.cpp
[..]
[AS] fastntt.S
cp ../mbed/TARGET_NUCLEO_F411RE/TOOLCHAIN_GCC_ARM/STM32F411XE.ld pqps.link_script.ld
link: pqps.elf
arm-none-eabi-objcopy -O ihex pqps.elf pqps.hex

The PQALG argument is needed and points to a directory containing the target implementation.

Compiling ECDSA and ECDH from "micro-ecc"

The directory mecc contains wrappers that I wrote for Kem MacKay's micro-ecc, which may be used as a reference point. The compilation and testing mechanism is exactly the same as for PQM4 algorithms (ECDH is modeled as a KEM). See the mecc README for more information.

Flashing

If the build was successful, BUILD/pqps.hex contains a firmware image that can be flashed with stlink:

$ st-flash --format ihex write BUILD/pqps.hex

st-flash 1.5.1-16-g1165cf7
2019-10-01T13:36:18 INFO common.c: Loading device parameters....
2019-10-01T13:36:18 INFO common.c: Device connected is: F4 device (low power) - stm32f411re, id 0x10006431
2019-10-01T13:36:18 INFO common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2019-10-01T13:36:18 INFO common.c: Attempting to write 84332 (0x1496c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08010000 erasedEraseFlash - Sector:0x4 Size:0x10000 
2019-10-01T13:36:20 INFO common.c: Finished erasing 5 pages of 65536 (0x10000) bytes
2019-10-01T13:36:20 INFO common.c: Starting Flash write for F2/F4/L4
2019-10-01T13:36:20 INFO flash_loader.c: Successfully loaded flash loader in sram
Target voltage (51 mV) too low for 32-bit flash, using 8-bit flash writes
size: 32768
size: 32768
size: 18796
2019-10-01T13:36:22 INFO common.c: Starting verification of write complete
2019-10-01T13:36:23 INFO common.c: Flash written and verified! jolly good!

NOTE. The target board needs power to be programmed; on initial run you can allow this via the menus (and joystick) on the PowerShield; just press the big blue "ENTER" button and check the LCD display.

You can try interacting with the default firmware with (replace the device identifier with that of your target):

$ picocom --echo -b 115200 --imap lfcrlf --omap crlf /dev/serial/by-id/usb-STMicroelectronics_STM32_STLink_0672FF535155878281153855-if02

[...]
Terminal ready

[RESET] This is PQPowerShield! Welcome.

SystemCoreClock         96000000
CRYPTO_ALGNAME          Kyber768
CRYPTO_SECRETKEYBYTES   2400
CRYPTO_PUBLICKEYBYTES   1184
CRYPTO_CIPHERTEXTBYTES  1088
CRYPTO_BYTES            32
[INPUT] a = all, k = keygen, e = encaps, d = decaps
a
[START] measure(10000,kg,enc,dec)
[END] 10023 milliseconds, n=298 (0 errors)
*** KeyGen       978424 Kyber768
*** Encaps      1150505 Kyber768
*** Decaps      1099639 Kyber768
*** Total       3228569 Kyber768
[INPUT] a = all, k = keygen, e = encaps, d = decaps

Measurements

• Take a look at main.cpp to see what you want to actually measure.

• The script running a set of energy measurements is contained in psctrl.py; you'll have to modify at least the serial device identifiers for this to work.

• A shell script test_alg.sh will measure every implementation it can find, in random order and write results to logs.

• A python script parselog.py is used to interpret these results.

• After four randomized runs, which took a couple of days, I produced the file log/parsed_data.txt with

$ ./parselog.py log/* > log/parsed_data.txt

Preliminary Summary

• In practice we saw current wander between 10 mA and 38 mA with stabilized 3V voltage, corresponding to 30 mW .. 114 mW range. Algorithms were clocked at 96 MHz; cycle timing was used together with integrated average energy of each primitive to derive an energy profile for each tested algorithm.

• I can usually tell what algorithm you're running based on your wattage alone! Power consumption is not constant, but is largely dependent on the instruction mix of the particular algorithm being tested. Very consistently and unexpectedly e.g. the NTRU key generation routine requires only half of the wattage of decapsulation of the same algorithm.

• I did four randomized trials for each target algorithm, running each component for at least 10 seconds in each (typically tens or hundreds of iterations), and the results are quite consistent. You may look at the semi-processed data log/parsed_data.txt if you like.

Signature Energy

Sorted by increasing verify energy.

KEM Energy

Sorted by increasing total ("key exchange") energy.

NB. The SIKE energy numbers may be little off if the power consumption drifts during processing (average power measurements is based only on first 10 seconds but SIKE doesn't necessarily manage even a single iteration during that time).

There's a faster Cortex M4 SIKE implementation reported in IACR ePrint 2019/535, but the authors have not released their software so independent measurements are not possible. This improved implementation still has a reported latency of several seconds, so its power consumption can still be assumed to be hundreds of times higher than with most other candidates (if not thousands as is currently the case.)

NOTE

(c) 2019 PQShield Ltd. No warranty whatsoever; use at your own risk.