Adapting to Security Threats with FPGAs

ID 672292
Updated 8/31/2017
Version Latest




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 have not been modified or revealed to an unauthorized party eavesdropping on the communications. 

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. 

Please note: The security algorithms used in this example were designed to address the needs of post-quantum cryptography for which there are no industry-accepted standards today. The US National Institute of Standards and Technology (NIST) has initiated a process to evaluate, and standardize on one or more quantum-resistant public-key cryptographic algorithms; a process that will take several years to complete. SecureRF’s Walnut DSA algorithm is one of several candidates currently under review in the NIST Post-Quantum Cryptography Round 1 Submissions and may, or may not, ultimately be approved as a standard. Because the security evaluation is on-going, Intel is not making any statement as to the fitness-for-use of this algorithm.

This situation illustrates a unique FPGA virtue – the ability to adapt to changing requirements. In this case, a security algorithm can be deployed today and changed later once a standard is approved, or to address a new threat. It shows how FPGAs help developers future-proof their systems’ security, providing an efficient way to replace cryptographic algorithms that have become less secure or obsolete. 

This tutorial will show you how to:

  1. Download an SD card image containing the design, and prepare the DE10-Nano board for use.
  2. Run a signature verification, and shared secret calculation from the command line.
  3. Compare the speed of shared secret calculations in software vs. hardware.
  4. Perform remote device authentication (e.g. sensor connected to IoT gateway).
  5. Learn how to adapt the sample code to your own design.

Level: Beginner with basic Windows or Linux* PC skills.


  1. 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.
  2. MicroSD* card (4-GB)
  3. MicroSD card adapter (e.g. USB to MicroSD)
  4. USB Type A to Mini-B cable
  5. Ethernet network cable
  6. Windows* or Linux* PC with terminal emulator program such as:
  7. Virtual COM port driver installed to enable UART over USB from (FTDI)

Initial setup

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 the URL here.

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.


If you are on a Linux PC (and assuming your SD card is mounted at sdb), the recommended command is “dd”, for example:

dd if=srf_de10-nano.img of=/dev/sdb bs=1m 

Additional SD card writing instructions may be found here.

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.

Photo of device, MSEL DIP switches (SW10)
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.

Photo of device, UART connector (J4)
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 a Windows operating system on your PC, you can determine the COM port assignment by opening Device Manager as shown in Fig. 3.

Screenshot of device manager showing UART COM port assignment
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.

Screenshot, PuTTY configuration screen
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.

Screenshot, Linux login screen
Fig.5: Linux login screen

Step 3.f: Login to the board

login: root
password: root

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* processor 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:

cd /home

Launch the signature verification application by typing:


Screenshot, Signature Verification
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:


Screenshot, Shared Secret Calculation
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:


screenshot,  Run ifconfig to determine IP address
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:

cd /home/root/Image_Painter_Demo

Launch application by typing:

node server.js”

You should receive the message “HTTP server listening on port 8888” as shown below:

Screenshot, Server.js message
Fig.9: Server.js message

Step 5.c: For example, if the board IP address discovered in step 5.a was, enter as the URL in your web browser.

In the terminal screen, you should see the message “Websocket connection received”.

Screenshot, websocket connection message
Fig.10: Websocket connection message

Step 5.d: You should see the web page shown in Fig. 11. below in your browser.

Screenshot, runtime comparison demo
Fig.11: Runtime comparison demo

Step 5.e: Click “Start” to run the demo.

After each side (hardware and software side) completes a shared secret calculation, it sends a message to the browser to draw the next horizontal line of lock image pixels. The padlock image is stored in the “public/images” folder under “Image_Painter_Demo”; when you launch the server.js app, Node.js reads the lock image from the images folder and transfers its contents to the JavaScript program that runs in the browser.

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 an Intel® Cyclone® V SoC device) 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.

Screenshot, block diagram of two IoT endpoints
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 CMD in 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:

cd /home/root/TCP_Sockets_Hardware_Demo/Ironwood/Debug

Launch the authentication application by typing:

./Ironwood 8025

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.

Screenshot, location of IoT_emulator application shortcut
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. “”).

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.

Screenshot of remote IoT device showing an authentication session
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).

Screenshot of DE10-Nano terminal showing an authentication session
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).

Note: 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® technology, 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.

Screenshot, location of demo sources
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 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 the SecureRF cryptography page.

About the Author

Founded in 2004, SecureRF develops and licenses quantum-resistant, public-key security tools for the low-resource processors powering the Internet of Things (IoT).

Terasic DE10-Nano