Intel Arria 10 SoC Secure Boot User Guide
Intel Arria 10 SoC Secure Boot User Guide
The Intel® Arria® 10 SoC device family and supported tools provide features and resources to create a secure boot system. Secure booting is essential to protect the design's intellectual property (through encryption) and prevent malicious software from running on the system (through authentication). A secure boot system establishes a chain of trust. Each piece of firmware or software is validated before running, and also validates the security signature on the next piece of software before loading it for execution.
This document provides methods and design examples for implementing an Arria 10 SoC secure boot system using tools from the Intel® SoC FPGA Embedded Design Suite (EDS)SoC Embedded Design Suite (SoC EDS) to secure the second-stage boot loader image. It shows how to generate a secure boot loader, creating and programming secure keys for image authentication and image encryption and decryption.
Prerequisites
- Supported development platforms:
- Red Hat Linux version 6 or higher
- Windows versions as supported by the Quartus Prime software
- Quartus Prime Standard or Pro Design Suite, version 16.0 or later
- SoC EDS version 16.0 or later
- c:\altera\16.0\embedded on Windows
- ~/altera/16.0/embedded on Linux
References
To make the best use of this guide, you should be familiar with the Intel® Arria® 10 SoC Boot User Guide, the Intel® Arria® 10 Hard Processor System Technical Reference Manual, and the Intel® FPGA SoC Embedded Design Suite User Guide.
Secure Boot Stages
The main purpose of a secure boot system is to ensure that software running on the Arria 10 SoC hard processor system (HPS) is trusted. To ensure this trust, after power-on reset, the HPS executes the trusted first stage boot ROM firmware stored in the device. Each subsequent stage is only loaded and executed if it is authenticated by the current boot stage.
The Intel® Arria® 10 secure boot stages are shown in the following figure.
For more information on the Intel® Arria® 10 boot stages and second-stage boot loader refer to the Intel® Arria® 10 SoC Boot User Guide.
Root of Trust
First-Stage Boot Loader (ROM)
After hardware system initialization is complete, the Intel® Arria® 10 SoC boot ROM firmware decrypts, authenticates, and executes the next boot stage. The boot ROM firmware is the root of trust: the trusted, inherently secure starting point for booting the Intel® Arria® 10 SoC.
- Determine which boot device contains the next boot stage image, the second-stage boot loader
- Discover the final code signing key (CSK) through a key chain service
- Use the CSK to authenticate the boot loader image
- If the boot loader image is encrypted, the boot ROM sends the image to the CSS for decryption.
- If boot loader authentication and decryption is successful, load the boot loader into on-chip RAM and execute it
For details about secure system initialization, refer to "Secure Initialization Overview" in the SoC Security chapter of the Intel® Arria® 10 Hard Processor System Technical Reference Manual.
Second-Stage Boot Loader
The boot loader can perform a number of required and optional tasks, such as:
- Configuring I/Os to enable the memory controller prior to FPGA configuration
- Configuring the FPGA portion of the device
- Accessing a file system in flash memory
- Initializing peripherals
In a secure boot implementation, the second-stage boot loader software executes from HPS on-chip RAM.
Third and Fourth Stages
If the stages following the second-stage boot loader need to be trusted, then you must implement features to support authentication in the third and fourth stage.
During the third boot stage, an operating system (OS) or stand alone application, such as Bare Metal, typically loads from flash storage into memory. During the fourth boot stage, the OS commonly launches secure user level applications.
Intel Arria 10 SoC Secure Boot Architecture
- Security Manager
- Boot ROM
- ECDSA Authentication
- Security Fuses
- AES Decryption Engine
- Security Key Storage
A dedicated Security Manager resides in the HPS. It supervises a secure initialization and boot of the system. The Security Manager determines the level of system security in the device by reading the HPS fuse settings after power-on reset (POR).
After the security level is determined, secure boot resources attempt to load software into HPS flash. The boot ROM supervises this bootstrapping process.
Software Image Authentication
Authentication of the second-stage boot loader software by the Intel® Arria® 10 SoC device provides confidence that it originates from a trusted source. Digital certificates and public key cryptography offer advanced authentication and privacy that less advanced security resources, such as passwords, cannot provide.
Authentication begins when the boot image is digitally signed. The Intel® Arria® 10 SoC device requires the image to be signed using an elliptical curve digital signature algorithm (ECDSA) that is based on elliptical curve (EC) cryptography.
Digital Signing
The signing process requires a security key pair and a signing tool to sign the image. The private and public key pair are generated based on a 256-bit ECDSA asymmetric digital signature. The private key has full entropy and is used to derive the public key.
The signing process creates a digital certificate with signatures based on elliptic curve cryptography. The signed image’s credentials during authentication are the digital signature and the public key.
Root of Trust and Root Key
The Root of Trust and the root key pair are the origin where the secure keys are generated. In this secured environment, you can also sign the boot image. A secure environment such as a device manufacturing site, retains the private key to protect it.
The manufacturer generates the root key pair. The root key is programmed into the SoC device and authenticates the software images. The image signing tool is run multiple times for each runtime software on the device. When security is compromised, you must generate a new public key.
Authentication of the Second-Stage Boot Loader
The security features of the Intel® Arria® 10 SoC provide you with resources to enforce that only a trusted second-stage boot loader is executed from the HPS. The boot ROM executes the first stage and enforces user security settings. During authentication, the Boot ROM verifies the HPS security fuse settings through the HPS_fusesec shadow registers.
- On FPGA power-up, the Configuration Subsystem (CSS) powers, initializes and loads the fuse bits. The CSS sends the FPGA its fuse configuration information. If the HPS is powered, the CSS sends the HPS fuse information to the Security Manager. This information is held in the HPS_fusesec shadow register in the Security Manager.
- When the Security Manager is released from reset, it requests configuration information from the CSS and performs security checks. At this point, the rest of the HPS is still in reset. The security checks validate whether the state of each security option is valid. The Security Manager decodes the fuse bits and brings the rest of the HPS out of reset.
- When the HPS is released from reset, the Security Manager sends signals to initialize the system blocks, such as the Clock Manager, FPGA Manager, and System Manager. The clock control fuse information is automatically sent to the Clock Manager, the memory control fuse information is automatically sent to the Reset Manager and all other fuse functions (authentication, encryption, and public key source and length) are stored in a memory-mapped location for the boot ROM code to read. After these tasks are successfully completed, CPU0 comes out of reset in a secure state.
- After CPU0 is released from reset, the boot ROM begins executing. At this time, the HPS is in a trusted state and the boot ROM code is guaranteed to execute as expected. For both secure and non-secure boot, all slave peripherals are brought out of reset in a secure state.
- The boot ROM determines the boot flash partition and verifies the security header settings of the second-stage boot loader image. The second-stage boot loader requires a signed certificate to be authenticated.
- The Boot ROM determines the source of the root key by reading the security header.
- The boot ROM attempts to authenticate the boot image. If authentication is successful, the boot ROM then continues with the process of loading and executing the image.
Security Level Staging
After power-on-reset, the Security Manager determines the initial security level by verifying and reading the fuse data. The Security Manager stores the fuse data in the fuse shadow register, HPS_fusesec. From this point, the boot ROM reads the fuse data from the shadow register and also verifies the security header, if present, in the boot image stored on boot flash partition. The second-stage boot loader is the boot image.
The security header may also contain information to raise the security level for a particular feature implemented in the fuses. The boot ROM merges the fuse values in the shadow registers with the security header values to establish the final security level of the system.
Signed Image
The signing of an image includes prepending an authentication header, including a security header.
Root Key Types
Root Key | Is it stored on the device? | Description |
---|---|---|
Secure User Key | Yes | User generates secure key pair for boot ROM to attempt authentication. The SHA256 hash of the public key is stored in the User Access Fuses (UAF) of the device. This configuration provides a secure boot. |
FPGA Key | Yes | The public key originates from the user bitstream. The key is stored in FPGA on-chip RAM and accessed by the first stage boot ROM for image authentication. |
Unsecured User Key | No | User generates a secure key pair but it is not stored on the device. This configuration is considered unsecure. The user includes the root key result in the image header and the boot ROM uses it for authentication. |
Root Public Key Authentication
Before boot ROM can use the root public key for authentication, it must authenticate the root public key against the root public key hash stored in eFuse.
The available key type options are detailed in the Programming the Secure Signing Key section.
Test Secure Boot Authentication
You can perform a secure boot test by using an unsecured key for authentication of the signed boot image. Refer to the Security Level Staging section for details of how to increase security on the device.
If you choose to implement the unsecure user key type, then the public key in the signed image is accepted and no check is performed against the SHA256 value stored in the device fuses. You can use this method for testing purposes before you burn the fuses.
Programming the Secure Signing Key
After the boot image is signed, the private key is retained in secure storage at the original equipment manufacturer (OEM) to protect it. The public key is programmed into the device. For some signing key types, a hash of the public key is programmed.
The signing key type determines the location of the public key. The available signing key types and corresponding locations are described in the following table.
Root Key | Key Type | Description |
---|---|---|
Secure User Key | Fuse |
User generates secure key pair for boot ROM to attempt authentication. The SHA256 hash of the public key is stored in the User Access Fuses (UAF) of the device. This configuration provides a secure boot. For information about secure fuses, refer to the Secure Fuses section in the SoC Security chapter of the Intel® Arria® 10 Hard Processor System Technical Reference Manual. |
FPGA Key | FPGA | The public key originates from the user bitstream. The key is stored in FPGA on-chip RAM and accessed by the first stage boot ROM for image authentication. |
Unsecured User Key | User | User generates a secure key pair but it is not stored on the device. This configuration is unsecure and is for testing only. The user includes the root key result in the image header and the boot ROM uses it for authentication. |
Boot Image Signing Flow
After you have generated the signing key pair, you can build and sign the boot image with the secure boot image tool.
Boot Image Authentication
- Determine the device’s security configuration settings (by reading the fuse values)
- Attempt to authenticate the boot image, using the root public key type from the configuration settings
Generating the Signing Key Pair with OpenSSL
You may generate the signing key pair using OpenSSL, an open-source toolkit that supports the Secure Socket Layer (SSL). OpenSSL is available in the SoC EDS embedded command shell, and is provided by common Linux distributions.
You invoke OpenSSL from the boot loader generator. OpenSSL applies the security settings that you select in the boot loader generator, and creates an EC key pair. The boot loader generator invokes OpenSSL as follows to generate the key pair:
$ openssl ecparam -genkey -name prime256v1 -out root_key.pem
In the example above, the generated key pair is stored in the root_key.pem file. You can use this file with the Intel® secure boot image tool to sign the image.
Overview of the Secure Boot Flow
- Encrypted only
- Authenticated only
- Encrypted and authenticated
Creating a Secure Boot System
Creating a secure boot loader image entails the following high-level steps:
- Determine the required security level of the second-stage boot loader: signed for authentication, encrypted, or both.
- Generate the appropriate secure keys for authentication, encryption, or both.
- Generate and build the secure boot loader image.
- Program the secure keys in the Intel® Arria® 10 SoC device.
- Configure the security fuses for the desired device security settings.
- Program the secure boot image to the boot device.
Software Image Encryption
Refer to the "Secure Boot Stages" figure for an overview of key usage.
AES Encryption and Decryption
The Arria 10 SoC device family supports secure boot with Advanced Encryption Standard (AES) encryption with a 256-bit key length. AES is a symmetric-key algorithm. AES decryption support is provided by the configuration subsystem (CSS) in the FPGA portion of the device. AES decryption is enabled through user fuse settings and software programming.
For information about the CSS, refer to the SoC Security chapter in the Arria 10 Hard Processor System Technical Reference Manual.
The FPGA portion of the secured device has a dedicated decryption block that uses the AES algorithm to decrypt the boot loader image with a user-defined 256-bit AES key. Before receiving the encrypted data, you must write the user-defined 128-bit key into the device.
The AES algorithm is a symmetrical block cipher that encrypts and decrypts data in blocks of 256 bits. The decryption block uses the AES algorithm to decrypt the boot loader image and configuration data before configuring the FPGA portion of the device. If encryption is not used, the AES decryptor is bypassed.
Encrypting the Boot Image and Configuration File
The Quartus Prime Design Suite includes the Quartus Prime Convert Programming File tool, quartus_cpf, which you use to generate the AES 256 encryption file.1 You invoke the Quartus Prime Convert Programming File tool as follows:
quartus_cpf -e -k <keyfile>:<key_id>[:<key_id>] <input_sof_file> <output_ekp_file>
If you configure the boot loader generator to encrypt the boot image, quartus_cpf requires the encryption key file as specified in the configuration tool’s security settings. For an overview of the tool flow, see the figure in "Software Image Authentication and Encryption".
For details of Quartus Prime Convert Programming File tool usage, refer to "How to Generate the Single-Device .ekp File and Encrypt Configuration File Using Quartus Prime Software with the Command-Line Interface" in AN-556: Using the Design Security Features in the Altera FPGAs.
Boot Image Encryption Flow
Programming the AES Encryption Key
The FPGA device provides both volatile and non-volatile key storage. After the encryption key is generated, you store the key, as described in "Creating an Encrypted Second-State Boot Loader Image". The key is later referenced by the AES-based algorithms that decrypt the boot image. See the "AES Decryption" figure in "AES Encryption and Decryption".
Software Image Authentication and Encryption
To provide the highest level of security during boot, you can apply both signing and encryption to a newly generated second-stage boot loader image. The image must be encrypted first, and then signed, so that the signature is available prior to decryption. During the boot process, the boot ROM firmware first attempts to authenticate the boot loader image. If authentication is successful, the device decrypts and loads the boot loader image.
You can use security settings in the boot loader generator to sign and encrypt a boot loader image.
SoC EDS Tools for Secure Boot
The SoC EDS includes tools for creating a secured second-stage boot loader image.
Tool |
Name |
Description |
---|---|---|
Boot loader generator |
bsp-editor |
Graphical second-stage boot loader generator |
Secure boot image tool |
alt-secure-boot |
Command line tool for image signing or encrypting |
Boot image format tool |
alt-image-cat |
Command line tool to format second-stage boot loader image |
Boot Loader Generator
- Create a new second-stage boot loader board support package (BSP)
- Edit an existing boot loader BSP
- Apply user-specified boot security settings to the boot loader
- Generate source files for the boot loader
For detailed usage of the boot loader generator, refer to "Boot Loader Generator Tool: BSP Editor" in the Arria 10 SoC Boot User Guide and to "Building the Arria 10 Bootloader" in the Intel® FPGA SoC Embedded Design Suite User Guide.
Security Settings in the Boot Loader Generator

Boot loader generator authentication settings:
- Enable Boot Loader Signing—When this option is turned on, generate a signed second-stage boot loader
-
Signing Key Type—Specifies where the
boot
ROM firmware should retrieve the signing keys from. Signing
keys can be stored in one of the following locations:
- User—Public
key is stored
boot
loader image header
Note: This is a non-secure configuration for testing only.
- Fuse—Hash of public key is stored in user fuses
- FPGA—Public key stored in FPGA memory.
- User—Public
key is stored
boot
loader image header
- Signing Key Pair File—File name of signing key pair (generated by OpenSSL)
- Signing Key FPGA Offset—Location of public signing key, if stored in FPGA memory.
Boot loader generator encryption settings:
- Enable Boot Loader Encryption—When this option is turned on, generate an encrypted second-stage boot loader.
- Encryption Key File—Name of AES encryption key file.
- Encryption Key Name—AES encryption key name (specified in the key file)
Secure Boot Image Tool
The secure boot image tool, alt-secure-boot, applies the security settings to the second-stage boot loader image.
If the boot loader is to be authenticated, the secure boot image tool signs the boot loader image with the private key from the previously-generated key pair file. The boot loader generator invokes the tool with the sign option and associated parameters from the security settings, as follows:
$ alt-secure-boot sign [<param1> <param2> ...]
If the boot loader is to be encrypted, the secure boot image tool encrypts the boot loader image with the key from the previously-generated AES key file. The boot loader generator invokes the tool with the encrypt option and associated parameters from the security settings, as follows:
$ alt-secure-boot encrypt [<param1> <param2> ...]
Boot Image Format Tool
The Arria 10 SoC boot ROM firmware supports up to four boot loader images in flash or FPGA memory, as described in the Arria 10 SoC Boot User Guide. When you create a secure boot loader, you must perform an extra step to combine multiple boot loader image files into a single image file.
The SoC EDS includes the boot image format tool, alt-image-cat, to combine up to four boot loader images and concatenate them into a single image file. Because the resulting image might span multiple flash memory partitions, the boot image format tool ensures that the images are aligned properly to partition boundaries.
The boot image format tool formats the boot loader image after it is built. You invoke this tool from the SoC EDS embedded command shell as follows:
$ alt-image-cat <input_image> <input_image2> –o <output_image> –A <alignment size>
The input files are .bin or .abin files that are typically generated by the boot loader generator. The output file is also a .bin or .abin file.
Secure Boot Examples
You can create a secure boot loader image for authentication, encryption, or both. "Creating a Signed Second-Stage Boot Loader Image" and "Creating an Encrypted Second-Stage Boot Loader Image" show examples of these processes.
Creating a Signed Second-Stage Boot Loader Image
The following example shows how to perform the following tasks:
- Create a secure signing key for boot loader image authentication, with the user signing key type.
- Generate and build a signed boot loader image with the secure signing key, using the SoC EDS.
- Demonstrate secure boot using the signed boot loader image.
User signing key types are described in "Programming the Secure Signing Key".
-
Launch the boot loader generator from the embedded command shell
with the following command
$ bsp-editor &
For general information about the boot loader generator, refer to "Second Stage Bootloader Support Package Generator" in the Intel® FPGA SoC Embedded Design Suite User Guide.
-
Create a new boot loader BSP for the
Intel®
Arria® 10
HPS.
For instructions to create a boot loader, refer to "BSP Generator Graphical User Interface" in the Intel® FPGA SoC Embedded Design Suite User Guide.Figure 14. Creating a New Second-Stage Boot Loader in the Boot Loader Generator. The boot loader generator dialog box
-
In the embedded command shell, change directories to the newly
created boot loader folder (BSP target directory), for example:
$ cd <SoC EDS installation directory>/examples/hardware/ \ a10_soc_devkit_ghrd_sb_auth/software/uboot_bsp
-
Type the following make command to generate
a signing key pair stored in a key pair file.
$ make generate-signing-key-pair-file
-
Type the following OpenSSL command to show the contents of the key
pair file and verify that it has been correctly created:
$ openssl ec –in root_key.pem –noout –text
Note: The Generating the Signing Key Pair with OpenSSL section describes this step in detail.The key file contents should be similar to the following:
read EC key Private-Key: (256 bit) priv: 00:85:fa:a0:18:e8:97:72:fd:d4:19:07:c0:d8:09: ae:e1:73:e8:80:fa:cf:35:bb:12:24:19:ec:7f:51: 56:34:f4 pub: 04:c1:a7:ba:ed:40:d6:0e:cc:08:97:c4:10:16:ac: 81:8b:33:73:ce:e2:d7:af:d6:78:ac:ea:48:f7:10: b2:80:c4:c4:ef:de:d5:c5:03:76:c5:1c:62:04:72: e7:1f:f7:32:aa:4c:a6:83:70:ae:b5:39:25:b1:e6: 51:0a:3a:74:ba ASN1 OID: prime256v1 $
-
Apply security settings for authentication as shown in the
following figure.
Figure 15. Security Settings in the Boot Loader Generator
- Turn on enable_bootloader_signing in the main boot loader generation settings.
- Set signing_key_type to user.
- Set signing_key_pair_file to the name of the file you created in the previous steps.
- Click Generate to generate the secure boot loader source.
- Exit the boot loader generator.
- On the command line, navigate to the boot loader source folder.
-
Build the boot loader image with the make
command:
$ make
-
Verify that the signed boot loader image was built by verifying
that the following file exists:
u-boot_w_dtb-mkpimage-encrypted-x4.abin
- Store the signed boot loader image from 11 in the appropriate flash boot device partition and reset the device.
Creating an Encrypted Second-Stage Boot Loader Image
The following example demonstrates how to perform the following tasks:
- Create an encryption key
- Generate and build an encrypted boot loader image using the SoC EDS
- Store the encryption key in the device's volatile key storage
- Demonstrate the secure boot using the encrypted boot image and encryption key
-
Launch the boot loader generator from the embedded command shell
with the following command.
$ bsp-editor &
For general information about the boot loader generator, refer to "Second Stage Bootloader Support Package Generator" in the Intel® SoC FPGA Embedded Design Suite User Guide. -
Create a new boot loader BSP for the Arria 10 HPS.
For instructions on how to create a boot loader, refer to "BSP Generator Graphical User Interface" in the Intel® SoC FPGA Embedded Design Suite User Guide. Also refer to the "Creating a New Second-Stage Boot Loader in the Boot Loader Generator" figure in "Creating a Signed Second-Stage Boot Loader Image".
-
Create an AES encryption key file using the Quartus Prime Convert
Programming File tool.
For details, refer to "How to Generate the Single-Device .ekp File and Encrypt Configuration File Using Software with the Command-Line Interface" in AN-556: Using the Design Security Features in Altera FPGAs.
-
Apply security settings for encryption as shown in the following
figure.
Figure 16. Creating an Encrypted Second-Stage Boot Loader Image in the Boot Loader Generator
- Turn on enable_bootloader_encryption in the main boot loader generation settings.
- Specify the name of the encryption key file.
- Specify the encryption key name (as found in the encryption key file).
- Click Generate to generate the secure boot loader source.
- Exit the boot loader generator.
- On the command line, navigate to the boot loader source folder.
-
Build the boot loader image with the make
command:
$ make
-
Verify that the encrypted boot loader image was built by verifying
that the following file exists:
u-boot_w_dtb-mkpimage-encrypted-x4.abin
-
Store the
AES encryption key in the device.
For details, refer to "Steps for Implementing a Secure Configuration Flow" in AN-556: Using the Design Security Features in Altera FPGAs.
-
Save the encrypted boot loader image from 9 in the
appropriate flash boot device partition using the SD card boot utility.
Note: Refer to the SD Card Boot Utility chapter of the Intel® SoC Embedded FPGA Design Suite User Guide.
-
Generate the encrypted key programming file using the encrypted key
file generated in 3.
Usage:
quartus_cpf --key <encryption key file: key name> <design.sof> \ <encryption key programming file>
Example:$ quartus_cpf --key encrypt_key.key:key1 ghrd_10as066n2.sof encrypt_key.ekp
This example generates encrypt_key.ekp. -
Make sure the updated SD card (11) is inserted into the kit.
Note: Do not power on the system in this step.
-
Connect the device to your development platform using the
Intel® FPGA Download Cable cable on the USB JTAG port, and
power on the system.
Note: The boot loader code will not execute at this time, because the encryption key has not been stored.
-
From the SoC EDS embedded command shell, verify that the device is
connected, and obtain the JTAG interface IDs, by running one of the following
commands:
- $ quartus_pgm -c USB-BlasterII –a
- $ jtagconfig -N
Note: Important! For the remaining steps DO NOT power off the system. -
Program the encryption key using the encryption programming key
file from 12.
quartus_pgm -c USB-BlasterII -m jtag -o "p;encrypt_key.ekp;10AS066H2ES" \ -o "s;SOCVHPS"
Note: Do not power off system until the key has been programmed. -
After the key has been successfully programmed, the system will
automatically reset and execute the encrypted boot image.
Note: You must repeat 14 each time the system has been power cycled.
Appendix A: SoC EDS Secure Boot Image Tool: alt-secure-boot
Secure Boot Image Tool Usage for Boot Image Authentication (Signing)
alt-secure-boot sign --help usage: alt-secure-boot sign [-h] \ --inputfile INPUTFILE --outputfile OUTPUTFILE \ [--fuseout FUSEOUT] [--pubkeyout PUBKEYOUT] \ [--rootkey-type {fuse,fpga,user}] \ [--keypair KEYPAIR] \ [--fpga-key-offset FPGA_KEY_OFFSET] Sign a bootloader image to allow BootROM verification optional arguments: -h, --help show this help message and exit --inputfile INPUTFILE, -i INPUTFILE Bootloader image to sign --outputfile OUTPUTFILE, -o OUTPUTFILE Signed output image --fuseout FUSEOUT, -fo FUSEOUT Hash of root public key, to be burned into device fuses --pubkeyout PUBKEYOUT, -pko PUBKEYOUT Root public key in raw data form. This data may then be built into the FPGA image for usage with --rootkey-type=fpga --rootkey-type {fuse,fpga,user}, -t {fuse,fpga,user} The trusted root key's type. (default: fuse) 'fuse': embed root pubkey in image. BootROM verifies its hash against device fuses. 'fpga': fetch trusted root pubkey from location in FPGA memory. 'user': embed root pubkey in image. BootROM does not verify. --keypair KEYPAIR, -k KEYPAIR Signature keypairs specified in order from the trusted root key to final user key --fpga-key-offset FPGA_KEY_OFFSET Offset from H2F bridge base address (0xC0000000) to location of logic-embedded root public key. Used for '--rootkey-type fpga' authentication.
Secure Boot Image Tool Usage for Boot Image Encryption
alt-secure-boot encrypt --help usage: alt-secure-boot encrypt [-h] \ --inputfile INPUTFILE --outputfile OUTPUTFILE \ --key KEY [--non-volatile] Convert a pimage into an encrypted boot image optional arguments: -h, --help show this help message and exit --inputfile INPUTFILE, -i INPUTFILE Bootloader image to encrypt --outputfile OUTPUTFILE, -o OUTPUTFILE Encrypted output image --key KEY, -k KEY File containing symmetric key to use for encryption --non-volatile Decryption key stored in non-volatile fuses, instead of battery-backed storage
Appendix B: Frequently Asked Questions
What are the secure configurations for HPS JTAG debug and access? How are these affected during warm or cold reset?
Two efuse bits, dbg_disable_access and dbg_lock_JTAG, control the secure JTAG debug configurations. You can read the programmed efuse values for your device through the HPS_fusesec register. A bit value of 1 in the HPS_fusesec register represents a "blown" fuse state and a 0 represents an "unblown" fuse state.
JTAG Configuration | dbg_disable_access | dbg_lock_JTAG | Description |
---|---|---|---|
HPS JTAG include | 0 | 1 |
|
HPS JTAG exclude | 1 | 1 | Permanently exclude the HPS from the JTAG chain. |
Default | 0 | 0 | Enable JTAG with software debug programmability. |
Can the HPS perform decryption of the boot image instead of the FPGA CSS?
The HPS portion of the SoC does not support AES operations. It can only perform public key-based authentication. The HPS can, however, push the boot image into the FPGA CSS and perform the same decryption used in the FPGA configuration flow.
When decryption is complete, the CSS returns the image to the HPS and the HPS uses that image as the boot image. The HPS and FPGA share the same AES root key which is stored in efuse. The CSS uses a simple key derivation function, AES (efuse or BBRAM key, #constant) for the HPS and FPGA configuration images.
What happens if the first stage boot ROM is unsuccessful in authenticating the second-stage boot loader?
The first stage boot ROM attempts to authenticate all four second stage images that are stored in the boot partitions of your flash device. If the device cannot authenticate the images or identifies the images as corrupt, then the boot ROM attempts to execute a fall back image located in the on-chip RAM of the FPGA.
Can you use the first-stage root key as the subsequent stage root key?
Intel recommends using a separate final signing key between different boot stages. Intel does not recommend using a root key for the first-stage or subsequent stage boot loader direct signing. Sharing the same root key between the first-stage and subsequent stage boot loader is only successful if you use the same ECC algorithm for each.
When the second-stage image is authenticated, is the image header only copied to on-chip RAM for authentication?
The entire boot loader image is always copied into the on-chip RAM and authenticated.
Can the AES encryption key be updated by the HPS using JTAG hosting?
You can only update the AES key in volatile memory through a connected JTAG interface. The HPS does not support JTAG hosting.
How does U-Boot (SSBL) authenticate next stage boot images?
The current GSRD U-Boot does not feature image authentication beyond the second stage bootloader (U-Boot). You can enable U-Boot to authenticate subsequent boot images (Linux®) by configuring or adding authentication capability to U-Boot. Reference the latest U-Boot releases for support on authentication. The user may also want to add specific third-party or open source solutions.
Which elliptical cryptography is used for boot image signing and authentication?
The Intel® Arria® 10 SoC device family uses the elliptical curve digital signing algorithm with NIST-approved ECDSA on NIST P-256 curve for signing and authentication of second-stage boot images.
How do I generate a signing key pair?
You may use the open source OpenSSL toolkit or your own tool to generate a key pair file that contains a private and public key pair. The SoC EDS boot tool requires a key pair file for signing an image. If you decide to use OpenSSL, you may refer to the OpenSSL website for more information about how to use the tool.
Where can I store the signing keys for second-stage boot loader authentication?
You can store the signing keys for second-stage boot loader authentication by the Intel® Arria® 10 SoC device in:
Root Key | Key Type | Description |
---|---|---|
Secure User Key | Fuse |
User generates secure key pair for boot ROM to attempt authentication. The SHA256 hash of the public key is stored in the User Access Fuses (UAF) of the device. This configuration provides a secure boot. For information about secure fuses, refer to the Secure Fuses section in the SoC Security chapter of the Intel® Arria® 10 Hard Processor System Technical Reference Manual. |
FPGA Key | FPGA | The public key originates from the user bitstream. The key is stored in FPGA on-chip RAM and accessed by the first stage boot ROM for image authentication. |
Unsecured User Key | User | User generates a secure key pair but it is not stored on the device. This configuration is unsecure and is for testing only. The user includes the root key result in the image header and the boot ROM uses it for authentication. |
What type of cryptography is used for boot image encryption and decryption?
The Intel® Arria® 10 SoC device family supports secure boot using the Advanced Encryption Standard (AES) encryption with a 256-bit key length. You can encrypt your boot image using quartus_cpf tools. The Arria 10 SoC AES engine only supports decryption.
What FPGA locations are available for AES key storage?
- User fuses (non-volatile memory)
- Battery-backed RAM (volatile memory) within the FPGA
The contents of the volatile key registers are retained between power-cycles with battery power. Non-volatile key registers are fuse-based and are one-time programmable.
How do I generate an AES key to encrypt a boot image?
The AES key file (.key) is a text file that you generate using a true random number generator (TRNG) or some other trusted tool. Refer to AN-556: Using the Design Security Features in Altera FPGAs for the content format of this file.
How is secure boot defined within the Intel Arria 10 SoC product family?
Within the Intel® Arria® 10 SoC device family, a secure boot implies that before the system loads any user (non-device modifiable) software, such as a second-stage boot loader image, it:
- Checks the image for authenticity
- Decrypts any encrypted image before signing it as certified
What security choices are available for the second-stage boot image or user software?
Authentication is provided for the second-stage boot loader code and both the HPS and FPGA can utilize the AES algorithms in the Configuration Subsystem (CSS) to decrypt boot images and POF files, respectively.
Three levels of boot are available to the device:
- Authentication only: The second-stage boot loader code is not encrypted, but there are public key signatures attached to the image and the code only executes if all of the signatures pass. ECDSA256 (SHA 256) is used for authenticated boot.
- Decryption only: The user boot code is encrypted and must be decrypted before execution. AES-based algorithms in the FPGA are used for decryption.
- Authentication and Decryption: The user boot code is encrypted and signed.
If authentication and decryption are enabled, the data is first authenticated and then decrypted using the AES algorithms. Authentication is performed using the public key authorization key (KAK) held in the user fuses. The KAK can be 256 bits. The KAK public key authentication fuses are lockable by the user in groups of 64 bits or less.
Where is the authentication of the boot image performed?
The HPS boot ROM authenticates the boot image in the SoC. The FPGA does not perform this authentication.
Where is decryption of the boot image performed?
If the boot ROM detects that the boot image is encrypted, it sends the image to the CSS for the AES to perform decryption.
How can I configure the Arria 10 SoC device so that it always performs authentication or authentication and decryption?
- Program the aes_en_f fuse so that an AES decryption of a flash image is always performed.
- Program the kak_src_f fuse to indicate where the key authorization key (KAK) resides
- Program the kak_len_f fuse to configure the length of the KAK
- Program the authen_en_f fuse so that HPS authentication is required for all flash images prior to execution
- Program the security authorization key in the location you have selected
How can I program the key authentication key (KAK) into the Arria 10 SoC device?
You can program the KAK into the device fuses permanently using the Intel® FPGA Download Cable and the programmer tool installed with the Design Tool Suite.
How can I configure the second stage boot loader image for the correct authentication signing key type?
You must select the appropriate security settings for authentication before generating the second-stage boot loader in the SoC EDS bsp-editor. After the settings are applied, you build the boot loader and the configurations are incorporated in the image. After these steps, you must build and sign the boot loader.
If you use the SoC EDS bsp-editor tool to generate the boot loader source, then you must build the image and then use alt-secure-boot tool to sign the final image.
How do I configure the second-stage boot loader image for encryption using the pre-generated AES key?
Is the ECDSA private and public key pair that is used for signing the boot image also used for authentication of the FPGA image?
The ECDSA signing key pair is only used for signing of the second-stage boot image. The FPGA does not support public key-based authentication.
Revision History
Date | Version | Changes |
---|---|---|
November 2017 | 2017.11.06 |
|
March 2016 | 2016.03.29 | Initial release |