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?
Root Key Types
The boot ROM requires the root public key programmed in eFuse and its associated public key to authenticate the second-stage boot loader if the key contained within eFuse, the FPGA or header file (test only) mandates an authenticated flow. Several root key types are available that you can store on the device or second-stage boot loader image.
Note: Using the image itself for storage of the root key is not considered a secure method. Intel recommends that you use this method for testing purposes only.
|Root Key||Is it stored on the device?||Description|
|Secure User Key||Yes||You generate 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 your bitstream. The key is stored in FPGA on-chip RAM and accessed by the first stage boot ROM for image authentication. When you store the FPGA key in on-chip RAM, you must turn on the Enable boot from fpga signals option on the FPGA Interfaces tab of the Intel® Arria® 10 Hard Processor System Intel® Arria® 10 FPGA IP GUI.|
|Unsecured User Key||No||You generate a secure key pair but it is not stored on the device. This configuration is considered unsecure. You include the root key result in the image header and the boot ROM uses it for authentication.|
Did you find the information on this page useful?