Written by: SecureRF
Intel® Cyclone® V SoC FPGA devices are ideally suited for use in base stations and IoT gateways that must interact with a large network of sensors and actuators in a secure way. Interacting in a secure way means that the two communicating devices trust each other and that commands, messages, and other data passed between the two has not been modified or revealed to an unauthorized party eavesdropping on the communications. If you are involved in the development of products that communicate over a network, this tutorial will introduce you to countermeasures that are easy-to-implement, and will help protect your products from well-known security exploits.
Communicating with devices in a secure way requires the use of cryptographic operations that are by necessity computationally intensive. What makes SoC FPGA devices ideal for this application is their ability to perform the most demanding operations in the FPGA’s programmable logic thereby expediting results and offloading the Hard Processor System (HPS) for other tasks.
This tutorial shows you how to incorporate a digital signature algorithm (DSA) and key agreement protocol (KAP) into the programmable FPGA fabric and HPS of the Cyclone® V SoC FPGA device on a DE10-Nano board. Because the DSA and KAP routines must also reside on any device the DE10-Nano wishes to communicate with—sensors, actuators, and other highly-constrained devices—the cryptography has been designed specifically to run on low-resource platforms including those powered by 8-bit microcontrollers. This tutorial will show you how to:
- Download an SD card image containing the design, and prepare the DE10-Nano board for use.
- Run a signature verification, and shared secret calculation from the command line.
- Compare the speed of shared secret calculations in software vs. hardware.
- Perform remote device authentication (e.g. sensor connected to IoT gateway).
- Learn how to adapt the sample code to your own design.
Level: Beginner with basic Windows or Linux* PC skills.
- Terasic DE10-Nano kit
The Terasic DE10-Nano development board, based on an Intel® Cyclone V SoC FPGA, provides a reconfigurable hardware design platform for makers, IoT developers and educators. You can buy the kit here.
- MicroSD card (4-GB)
- MicroSD card adapter (e.g. USB to MicroSD)
- USB Type A to Mini-B cable
- Ethernet network cable
- Windows* or Linux* PC with terminal emulator program such as:
- Virtual COM port driver installed to enable UART over USB from (FTDI)
Step 1: Download the SecureRF DE10-Nano SD card image file.
Step 1.a: On your workstation PC, open an internet browser and navigate to this URL: https://www.securerf.com/developer/intel-de10-nano/
Step 1.b: Click the Download the SD Card Image button.
Step 1.c: Unzip the SD Card image file (.img).
Step 2: Write the image file to the SD card
Step 2.a: If you are on a Windows PC, the recommended application for writing the image to the SD card is Win32 Disk Imager 0.9.5: https://sourceforge.net/projects/win32diskimager/files/Archive/
If you are on a Linux PC, the recommended command is “dd”, for example:
dd if=srf_de10-nano.img of=/dev/sdb bs=1m (assuming your SD card is mounted at sdb)
Additional SD card writing instructions may be found here: http://www.ev3dev.org/docs/tutorials/writing-sd-card-image-linux-command-line/
Step 3: Prepare the board for use
Step 3.a: Insert the SD card into the microSD card socket and ensure that the FPGA Configuration Mode Switches are set to ON OFF ON OFF ON ON as shown in Fig. 1. to boot the DE10-Nano board from the microSD card.
Fig.1: MSEL DIP switches (SW10)
Step 3.b: Plug a USB Type A to USB Mini-B cable into the DE10-Nano UART connector as shown in Fig. 2.
Fig.2: UART connector (J4)
Step 3.c: On your host PC, determine which COM port is assigned by the PC. (Note: the board does not need to be powered-up with the external +5V power supply to determine this assignment.) If you are running Windows* OS on your PC you can determine the COM port assignment by opening Device Manager as shown in Fig. 3.
Fig.3: Device Manager showing UART COM port assignment “COM21” (assignment on your PC may differ)
Step 3.d: Launch PuTTY, uCon, or other terminal emulator program on your host PC at 115,200 bps using the assigned COM port. See Fig. 4. for an example in PuTTY.
Fig.4: PuTTY configuration screen
Step 3.e: Apply +5V power to the board via the DC power adapter. You should see a Linux boot sequence in your serial terminal emulator followed by a login screen as shown in Fig. 5.
Fig.5: Linux login screen
Step 3.f: Login to the board
Demonstration and Example Code
The SecureRF DE10-Nano SD card image contains an FPGA IP implementation of SecureRF’s WalnutDSA signature verification engine as well as the shared secret computation engine for SecureRF’s Ironwood key agreement protocol (KAP). The image also contains software for the ARM® CPU that manages both hardware engines and helps facilitate the transfer of cryptographic keys.
The SD Card includes three separate applications to help demonstrate the operation of the signature algorithm and the key agreement protocol.
Basic Operation via Terminal Session
Two applications are provided:
- walnut_dsa: Performs a single signature verification using the WalnutDSA hardware engine. For this demonstration, the signature, which would usually be sent to the DE10-Nano from a remote endpoint, is hard-coded into the application.
- Ironwood: Performs a shared secret calculation using the Ironwood key agreement protocol engine.
Both applications report run time as well as the results.
Step 4.a: In your terminal session, navigate to the home directory by typing:
Launch the signature verification application by typing:
Fig.6: Signature Verification
In this example, it took the FPGA hardware 60µs to perform a single signature verification.
Step 4.b: Perform a single shared secret calculation using the Ironwood engine by typing:
Fig.7: Shared Secret Calculation
In this example, it took the FPGA hardware 980µs to perform a single shared secret calculation.
Comparing the Speed of Shared Secret Calculations in Software vs. Hardware
In all public key cryptography systems, computing the shared secret is by far the most time-consuming step when performing a key exchange operation to establish a device’s authenticity.
This demo compares the speed of shared secret calculations running in software, on the ARM Cortex-A9 processor, versus running in hardware, in the FPGA fabric. The demo is served by a Node.js* application that spawns both the software-only process and the hardware-only process. Both processes run concurrently. The Node.js app also serves-up the web page that you view in your browser.
Step 5.a: Connect your DE10-Nano board to your LAN via a network cable. Determine the board’s IP address by typing the following command in the terminal window as shown in figure 8:
Fig.8: Run ifconfig to determine IP address
Step 5.b: Launch the Node.js application
Change directory to the image painter demo folder by typing:
Launch application by typing:
You should receive the message “HTTP server listening on port 8888” as shown below:
Fig.9: Server.js message
Step 5.c: For example, if the board IP address discovered in step 5.a was 10.100.3.31, enter http://10.100.3.31:8888 as the URL in your web browser.
In the terminal screen, you should see the message “Websocket connection received”.
Fig.10: Websocket connection message
Step 5.d: You should see the web page shown in Fig. 11. below in your browser.
Fig.11: Runtime comparison demo
Step 5.e: Click “Start” to run the demo.
Both sides are programmed to compute shared secrets as fast as they can; therefore, the rate at which the lock image is painted is directly proportional to how fast the shared secret routines execute. As you will see, the hardware side performs the cryptographic calculations faster than the software side even though the software side is being clocked 16 times faster.
Step 5.f: To stop the Node.js process from running, type Ctrl+C and proceed to the next demo.
Authenticating a Remote Device
This demo most closely represents how you would use the DE10-Nano board (or Intel Cyclone® V SoC) in a real-world application. The demo includes software that enables the DE10-Nano board to authenticate a remote device that is connected via a TCP socket. The remote device is emulated in a Java app that runs on a Windows or Linux PC. The DE10-Nano board acts as a base station or gateway device, and the remote device acts as a low resource IoT product—a sensor or an actuator perhaps.
Fig.12: Block diagram of two IoT endpoints
Step 6.a: Install the “IoT Remote Device Emulator App” on your Windows or Linux PC.
A .msi installer is available for Windows PCs here (perform the installation as a Windows Administrator):
- How do I install a .msi file as an administrator?
Step 1: Open an elevated Command Prompt by typing
CMDin Start menu, or Start screen search box, and then simultaneously pressing Ctrl+Shift+Enter keys.
Step 2: In the Command Prompt, execute the following command to run MSI file as admin:
msiexec /a<path to the MSI file> For instance, if your IoT Emulator MSI file is in the Downloads folder, then you need to enter both path to the file as well as the name of the MSI file. For example:
msiexec /a C:\Users\Bob\Downloads\IoT_emulator-1.0.msi
For Linux PCs, a Debian installer is available here:
Step 6.b: Launch the Ironwood authentication application on the DE10-Nano board
In the DE10-Nano terminal window, navigate to the Ironwood debug folder. Type:
Launch the authentication application by typing:
Step 6.c: Launch the IoT Remote Device Emulator application (IoT_emulator) on the PC.
On a Windows PC locate the IoT_emulator application and run it. During installation, a shortcut was placed in the SecureRF folder as shown in figure 13.
Fig.13: Location of IoT_emulator application shortcut
Step 6.d: Enter the IP address of the DE10-Nano board into the “Connect to IP” field together with port 8025 (e.g. “10.100.3.201:8025”).
Step 6.e: Click the “Create Shared Secret” button.
The Log window in the emulator app should indicate the authentication protocol sequence as shown below.
Fig.14: Screenshot of remote IoT device showing an authentication session
The Remote IoT Emulator user interface allows you to select between five different Ironwood public/private key pairs. If you run the demo with one key pair then select another key pair and re-run the demo, you should notice that the shared secrets calculated are different. For this demo, the Ironwood public and private keys are hardcoded into the demo’s C program that resides on the SD card.
When the DE10-Nano board is instructed to authenticate the remote device, the board first reads the remote device’s signed public key then verifies the signature using the WalnutDSA verification engine residing in the FPGA fabric. If the signature verifies correctly, the board and the remote device complete a key exchange operation whereby the remote device proves that it can compute the same shared secret as the board (i.e., that it is in possession of an authentic, but unique, private key).
Fig.15: Screenshot of DE10-Nano terminal showing an authentication session
Having completed a successful key exchange, the DE10-Nano board and remote device can use their shared secrets to encrypt and decrypt data that is passed back and forth between the two. Sample code is provided on the SD Card that shows how this is done using AES encryption.
Note that the shared secrets themselves are not used to encrypt/decrypt the data because that might leak information to an attacker that was eavesdropping on the communications. Instead, the shared secrets are combined with a nonce (a one-time use random number) then hashed to produce the encryption/decryption session keys. The next time a session is run, a different nonce is used which results in different data thereby mitigating replay attacks (where an attacker records the data exchanged between two devices during the authentication process then plays it back in an attempt to spoof one of the devices).
In a real production deployment of an Ironwood IP core on an Intel FPGA, the Ironwood private key would be contained in a ROM within the FPGA fabric that is unreadable and unchangeable from outside the chip.
Adapting the Sample Code to Your Design
The C code to perform signature verification and key exchange is available for developers to adapt to their own products. Although this demo uses TCP sockets, the SecureRF cryptographic primitives are entirely communications agnostic.
For the DE10-Nano side, the C source code that implements remote device authentication (Demo 3) is included on the SD card in the folder: /home/root/TCP_Sockets_Hardware_Demo. The main demo code is located in ironwood_dma.c.
To reuse the code, replace the calls to the TCP socket functions with code that implements the actual communications protocol that your product uses (Bluetooth*, ZigBee, Z-Wave, 6LowPAN, Thread, WiFi, Cellular, LoRaWAN, etc.). You would likely invoke an authentication session each time the DE10-Nano needed to communicate with a remote device.
Fig.16: Location of demo source adaptable for your own design
For the remote side (usually a constrained IoT sensor, actuator, or other low resource device), SecureRF provides an IoT Embedded SDK (http://info.securerf.com/iot-embedded-sdk-development-kit) that implements the same methods found on the DE10-Nano but in software. Code libraries are available for a wide range of 8, 16, and 32-bit microcontrollers. Incorporating the IoT Embedded SDK into a remote product would enable it to authenticate—and be authenticated by—the DE10-Nano.
For background information on SecureRF’s low-resource, quantum-resistant security methods, please visit www.securerf.com/technology/cryptography/