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:
Level: Beginner with basic Windows or Linux* PC skills.
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.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.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 a Windows operating system 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* 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.
Two applications are provided:
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.
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.
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.
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).
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:
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).
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.
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.
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.
Founded in 2004, SecureRF develops and licenses quantum-resistant, public-key security tools for the low-resource processors powering the Internet of Things (IoT).
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804