Visible to Intel only — GUID: gug1500395004521
Ixiasoft
Prerequisites
References
Secure Boot Stages
Intel® Arria® 10 SoC Secure Boot Architecture
Software Image Authentication
Overview of the Secure Boot Flow
Software Image Encryption
Software Image Authentication and Encryption
Intel® Arria® 10 SoC FPGA Authentication Signing Utility
Secure Boot Examples
Appendix A: Secure Boot Image Python Script: alt_authtool.py
Appendix B: Frequently Asked Questions
Document Revision History for the AN 759: Using Secure Boot in Intel® Arria® 10 SoC Devices
What are the secure configurations for HPS JTAG debug and access?
Can the HPS perform decryption of the boot image instead of the FPGA CSS?
What happens if the first stage boot ROM is unsuccessful in authenticating the second-stage boot loader?
Can you use the first-stage root key as the subsequent stage root key?
When the second-stage image is authenticated, is the image header only copied to on-chip RAM for authentication?
Can the AES encryption key be updated by the HPS using JTAG hosting?
How does U-Boot (SSBL) authenticate next stage boot images?
Which elliptical cryptography is used for boot image signing and authentication?
How do I generate a signing key pair?
Where can I store the signing keys for second-stage boot loader authentication?
What type of cryptography is used for boot image encryption and decryption?
What FPGA locations are available for AES key storage?
How do I generate an AES key to encrypt a boot image?
How is secure boot defined within the Intel® Arria® 10 SoC product family?
What security choices are available for the second-stage boot image or user software?
Where is the authentication of the boot image performed?
Where is decryption of the boot image performed?
How can I configure the Intel® Arria® 10 SoC device so that it always performs authentication or authentication and decryption?
How can I program the key authentication key (KAK) into the Intel® Arria® 10 SoC device?
How can I configure the second stage boot loader image for the correct authentication signing key type?
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?
Visible to Intel only — GUID: gug1500395004521
Ixiasoft
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.
The entire authentication process starts after power-on or cold reset of the device. The process follows a particular order to ensure a secure boot is attempted:
- On FPGA power-up, the 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.
Did you find the information on this page useful?
Feedback Message
Characters remaining: