Intel Stratix 10 Device Security User Guide

RSS

UG-S10SECURITY | 2021.02.17

Version Information

Updated for:
Intel® Quartus® Prime Design Suite 20.4

1. Important Notice to Customers Regarding Features Added in Intel Quartus Prime Pro Edition Software Version 20.4

The anti-tamper features are not available in Intel^® Quartus^® Prime Pro Edition software version 20.4. The anti-tamper information was removed from this user guide released version. The anti-tamper features are planned in a future release of Intel^® Quartus^® Prime Pro Edition software.

2. Intel Stratix 10 Device Security Overview

Intel^® Stratix^® 10 devices provide flexible and robust security features to help protect sensitive data, intellectual property, and the device itself under both remote and physical attacks.

The following security features are available to protect Intel^® Stratix^® 10 devices and your intellectual property:

Authentication

Authentication helps to ensure that both the firmware and the configuration bitstream are from a trusted source. Authentication is fundamental to Intel^® Stratix^® 10 security. You cannot enable any other Intel^® Stratix^® 10 security features without enabling owner authentication. Authentication uses following technology to protect your intellectual property and device:

Elliptic Curve Digital Signature Algorithm (ECDSA) Based Public-Key Authentication: Intel^® Stratix^® 10 devices always require firmware authentication for all Intel firmware that loads into silicon. The ECDSA authentication of firmware implements this requirement. Intel is the only source that provides the primary firmware for the Secure Device Manager (SDM) and all other firmware that runs on other configuration processors in the Intel^® Stratix^® 10 device.

eFuse programming to establish authentication requirements before configuration completes: You enable configuration bitstream authentication by programming the hash of your root public key into eFuses. This process establishes you as the owner of the device. After you enable configuration bitstream authentication, you must create a valid signature chain based on your root key for each configuration bitstream. Your Intel^® Stratix^® 10 device completes configuration after successful validation of your signature chain.

Encryption

Encryption helps to protect confidential information such as intellectual property or sensitive data from being extracted from the owner configuration bitstream. Encryption uses following technology to protect your device and intellectual property:

Advanced Encryption Standard (AES)-256 encryption, counter mode: This feature helps protect the confidentiality of intellectual property (IP) or sensitive data in the owner configuration bitstream. To reduce AES key exposure AES decryption only operates on data that has already passed public key authentication.
Side channel protection: This feature helps to protect the AES Key and confidential data from extraction through non-intrusive attacks. Intel^® Stratix^® 10 devices include the following functions to minimize any potential side channel leakage:
- The authentication first flow helps to protect against encrypted bitstream modifications that reveal an encryption key.
- A key update function reduces the amount of bitstream data encrypted with a single key.
- Long route data line scrambling reduces the exposure of decrypted configuration data on the chip-wide configuration network.
- A 256-bit wide direct key bus loading minimizes the transmission time of sensitive key material.
- Key scrambling limits any potential side-channel exposure when you store the AES root key in eFuses.
Advanced technology to store the AES root key choices: Intel^® Stratix^® 10 devices currently support the following storage locations for root AES keys:
- Battery backup RAM (BBRAM)
- eFuses: virtual ¹ or physical
- Quad SPI flash memory: wrapped in an Intrinsic* ID (IID) physically unclonable function (PUF)

These security features are available in Intel^® Stratix^® 10 devices that support advanced security. Devices with advanced security enabled can only load firmware shipped with Intel^® Quartus^® Prime Pro Edition software. The following table lists the security features that Intel^® Stratix^® 10 devices support.

Intel^® Stratix^® 10	Authentication	Advanced Security
GX	Yes	-AS suffix devices
GX 10M	Yes	No
SX	Yes	-AS suffix devices
MX	Yes	-AS suffix devices
TX	Yes	-AS suffix devices
DX	Yes	Yes, all devices

Additional Security Features

In addition to authentication and encryption Intel^® Stratix^® 10 devices support the following features to help secure your device and intellectual property:

eFuse support for security settings
Secure HPS debugging
JTAG disablement

The Related information section provides links to the topics that describe these features.

¹ Virtual eFuses are for test purpose only.

2.1. Intel Stratix 10 Secure Device Manager (SDM)

The Secure Device Manager (SDM) is a triple-redundant processor-based module that manages Intel^® Stratix^® 10 device configuration and security. The SDM authenticates and decrypts configuration data.

Figure 1. Secure Device Manager

Secure configuration includes the following steps:

If you have enabled authentication, the SDM checks that a trusted source, the device owner, has authorized the configuration bitstream.
The SDM always performs an integrity check over the bitstream using SHA-256 or SHA-384. This integrity check protects against intentional attacks and against accidental corruption of the bitstream, such as a bad write to flash.
If the configuration bitstream authenticates and you have enabled AES Encryption, the SDM decrypts the data. The SDM drives the decrypted data on the configuration network to Local Sector Managers (LSM) on the configuration network. Each LSM parses the sector configuration block data and configures the logic elements in the sector that it manages.

2.2. Enabling Intel Stratix 10 Security Features

Enabling any of the Intel^® Stratix^® 10 device security features first requires you to program the owner root public key hash into eFuse storage. Programming the hash of the root public key enables authentication, after which your configuration bitstreams must be signed. In addition, other security features such as bitstream encryption are available. Intel^® Stratix^® 10 devices support both virtual and physical eFuse programming. Before you program any security eFuse, Intel recommends that you use the virtual eFuse programming to test that the values being programmed are correct.

CAUTION:

Incorrect programming of security eFuses can permanently prevent the device from configuring.

When you program the owner root key hash, the programmer automatically programs the hash value, not the full key.

You can enable the following additional security options to further enhance the security level:

Advanced Encryption Standard (AES) Encryption protects your IP and secures your data. This option includes multiple sub-options relating to side channel mitigation.
Configuration firmware joint signature capability specifies that you, in addition to Intel, must sign the version of configuration firmware that runs on your device. If you enable the joint signature capability, the device only loads firmware signed by both Intel and by you, the device owner. An eFuse on the Intel^® Stratix^® 10 device enables this feature. For a full list of available eFuse security options, refer to Using eFuses.

eFuse programming sets a minimum-security strength. All eFuse enforced security options are permanent.

In addition to permanent security features, Intel^® Stratix^® 10 devices include some dynamic security options that you can control without using eFuses. Disabling HPS debugging is one example of a dynamic security feature. You control dynamic security options by setting optional fields in the configuration bitstream. The Intel^® Stratix^® 10 device enforces dynamic security options beginning with bitstream configuration, instead of at power-on, providing additional flexibility.

2.3. Owner Security Keys and Storage Options

Intel^® Stratix^® 10 devices support two types of security keys: The owner root public key hash and the owner AES key.

Owner Root Public Key Hash

Programming this key enables the owner configuration bitstream authentication. Configuration bitstream authentication is the fundamental security feature. You must enable configuration bitstream authentication before you can enable other security features. The Intel^® Stratix^® 10 device stores the SHA-256 or SHA-384 hash of this key in physical eFuses or virtual eFuses ². This hash validates the integrity of the root public key, which is the first step in the process to authenticate the configuration bitstream.

Owner AES Key

This optional key decrypts the encrypted owner image during the configuration process. You can store the AES key in virtual eFuses, physical eFuses, BBRAM, or in quad SPI flash as a PUF-wrapped key.

Table 1. Comparison of AES Key Storage Options
Storage Option	Customer Access	Persistence	Typical Applications
Virtual eFuses	Write/Erase	Volatile. Power cycling erases values.	Used to validate fuse values prior to programming physical eFuses. Virtual eFuse values may reside outside the protected key storage locations, and are reset by a power cycle or may be reset using the mailbox. Virtual eFuse storage is intended for use only in development or test environments, and you should not rely on virtual fuses to provide protection of keys in a production environment.
Physical eFuses	Write once.	Non-volatile. System must be powered on to read values.	Permanent on-chip storage. Once you program the AES root key into physical eFuses, you can no longer change or reprogram this key.
Battery Backup RAM	Write/Erase	Non-volatile while V_CCBAT is powered.³ Values are erased when power is removed from V_CCBAT.	On-chip AES key storage. You may reprogram as necessary or erase by removing power from V_CCBAT.
IID PUF-wrapped and stored in Quad SPI Flash	Write/Erase	Non-volatile.	Stores the AES key in external flash memory, encrypted with a secure device-unique key. Supports re-provisioning the AES key without requiring battery backup.

You program both the root public key hash and the AES key using JTAG. The configuration bitstream records the owner AES key location. For extra security, you can program eFuses to disable the other key storage locations. For example, if your design stores the AES key in eFuses, you can program the Disable encryption key in BBRAM and Disable PUF-wrapped encryption key eFuses for additional security.

Intel^® Stratix^® 10 devices support both unencrypted and encrypted AES key provisioning via JTAG. Encrypted AES key provisioning is known as a black key provisioning. Refer to Black Key Provisioning for more information about programming an encrypted AES key.

² Virtual eFuses do not provide full security.

³ For more information about required voltage ranges refer to the Intel^® Stratix^® 10 Device Family Pin Connection Guidelines.

2.4. Planned Security Features

Features mentioned in this section are planned for a future release of Intel^® Quartus^® Prime Pro Edition software.

2.4.1. Anti-Tampering

Anti-tampering features help detect and respond to certain physical attacks on silicon.

The SDM monitors operating conditions such as input clocks, voltage, and temperature to detect device tampering. Changes in these conditions may indicate a tampering event. You can choose an appropriate response to a detected event. Possible responses include but are not limited to the following actions:

Device reset
Device reset with configuration data zeroization
BBRAM AES key destruction

You enable anti-tampering features during the design process. The Intel^® Stratix^® 10 device activates the anti-tamper features as a configuration bitstream is loaded.

3. Design Authentication and Signature Chains

3.1. Design Authentication Overview

FPGA that runs the attackers' design rather than the owners' design may exhibit unintended behavior if the configuration bitstream is modified or replaced. Intel^® Stratix^® 10 FPGAs include a feature to authenticate the bitstream, which helps to ensure that the bitstream is from a trusted source. Authentication uses ECDSA signatures to validate the content of a bitstream. Authentication helps to prevent the Intel^® Stratix^® 10 FPGA from configuring with an unauthorized configuration bitstream.

When you use authentication, your manufacturing process programs the hash of the ECDSA root public key into FPGA eFuses. The configuration bitstream contains the full root public key. The SDM computes the hash of the root public key and compares the computed hash to the hash stored in eFuses. The SDM only proceeds to authenticate the bitstream if the values match.

Intel^® Stratix^® 10 devices support 256- or 384-bit key length for authentication. Intel strongly recommends that you use 384-bit authentication for all new designs. If you select 384-bit authentication, the Intel^® Stratix^® 10 device uses SHA-384 with ECDSA secp384r1. If you select 256-bit authentication, the Intel^® Stratix^® 10 device uses uses SHA-256 with ECDSA prime256v1. You cannot change the root key or the authentication key length after you program the eFuses. Choose 256-bit authentication only if you have legacy hardware, such as an HSM, that cannot handle 384 bit keys.

In the Intel^® Quartus^® Prime Software release 20.3 and earlier releases, selecting 384-bit keys results in a SHA384 hash being used in the authentication blocks in the bitstream. However, the remainder of the bitstream uses SHA256 for integrity checking. Support for SHA384 hashes in the bitstream is planned to be supported in a future release.

3.1.1. The Configuration Bitstream

The figure below shows an Intel^® Stratix^® 10 configuration bitstream that includes an FPGA and HPS. The firmware implements many functions including the functions listed here:

FPGA configuration
Voltage regulator configuration
Temperature measurements
HPS software load
HPS reset
Read, erase, and program flash memory
Device security, including authentication and encryption

The SDM always authenticates the firmware section of the configuration bitstream. The SDM authenticates the SDM firmware section using an Intel keychain. You may also choose to sign the SDM firmware by programming the Co-signed Firmware eFuse on the device. When you enable co-signed firmware you must co-sign the firmware before generating bitstreams. The SDM validates both the Intel signature and your signature before loading and running the SDM firmware.

Figure 2. Example of an Intel^® Stratix^® 10 Configuration Bitstream Structure

The I/O, HPS, and FPGA sections are dynamic and contain the device configuration information based on your design. Each dynamic section of the configuration bitstream stores information in the same format. Each section begins with a 4 kilobyte (KB) header block, followed by a signature block, hash blocks, and data.

Figure 3. Configuration Bitstream Section Layout

The header block contains a hash which validates hash block 0. Each hash block contains up to 125 SHA-256 hashes or 83 SHA-384 hashes. These hashes validate subsequent data blocks and the next hash block. A modification to any part of a section invalidates the signature. The modification results in configuration failure before the SDM processes the modified data.

3.1.2. Signature Block

The signature block validates the contents of the header block. After successfully validating the signatures, the SDM processes the data based on the signatures provided.

Figure 4. Signature Block FormatIn this figure the Root Key is the same in all signature chains.

For more information about how the quartus_sign command appends the public keys to the root key to create a signature chain refer to Figure 6.

Note: The Intel^® Quartus^® Prime Pro Edition Software GUI only supports one signature chain. You can use the quartus_sign command to create multiple signature chains for a Raw Binary File .rbf.

Table 2. Signature Block
Block	Description
SHA-384 hash of header block	This hash function checks for accidental changes in the header block.
Signature chains	Zero or more signature chains. Each signature chain can include up to 4 keys, including the owner public root key. You can assign the other 3 keys reduced permissions so that the keys can only sign a specific section of the configuration bitstream. The Intel^® Quartus^® Prime Software supports 2 keychains for firmware signing and up to 4 keychains for the configuration bitstream. Multiple keychains provide some flexibility.
Dynamic sector pointers	Locate the design sections for the remainder of the image when you store the image in flash memory.
32-bit CRC	Protects the block from accidental modification. The CRC does not provide security. Software tools can check the CRC to identify accidental modifications.

Signature Chain Details

Intel^® Stratix^® 10 FPGAs support up to four signature chains. If a signature chain is invalid, it is ignored. The FPGA starts validating the next signature chain. To pass authentication, at least one signature keychain must pass.

Table 3. Signature Chain Content
Content	Description
Root Key Entry	The Root Entry anchors the chain to a root key known to the device. The SDM calculates the hash of the root entry and checks if the it matches the expected hash. You store the root key hash in eFuses.
Public Key Entry	Signature chains enable flexible key management. Intel^® recommends at least one public key entry in each signature chain. The previous public key signs the new public key. The public key entry provides following capabilities: Key permission bit field to limit the sections of the configuration bitstream a public key entry can sign. For the `quartus_sign` command, specify these permissions as the equivalent hexadecimal value, 0x1, 0x2, 0x4, or 0x8. If more than one bit field is on, the key can sign more than one type of section. For example, if both bits 1 and 2 are on the permission value is 0x6 and the key can sign the FPGA I/O, core, PR, HPS I/O, and FSBL sections of the design. Cancellation ID: Specifies the fuse that cancels a key that is no longer valid. Intel^® Stratix^® 10 devices support 32 cancellation IDs. Cancellation IDs 0-31 cancel owner keys. Once you cancel a key, any previous designs signed by the canceled key are unusable. You can use this feature to prevent older designs from running on a device or as part of recovery from a compromised key. Refer to Understanding Permissions and Cancellation IDs for more information about how to manage cancellation IDs. Second- or third-level keys typically sign data. Intel^® Stratix^® 10 devices support signature chains containing up to 4 keys, including up to 3 public key entries.
Header Block Entry	The final entry in a signature chain contains the signature of one bitstream section Header Block. The Header Block Entry authenticates the first block of the section, and thus authenticates the whole section.

Understanding Permissions and Cancellation IDs

You use permissions to specify the types of sections that a key can sign. A 32-bit permission bit field specifies permissions. The bits grant permissions for a public signing key. All other permissions are reserved.

The table below describes the permission bits currently implemented.

Table 4. Available Permission Bits
Permission Bit	Used to Sign
0	Firmware co-signing
1	FPGA I/O, core and PR sections
2	HPS I/O and first stage bootloader (FSBL) sections
3	HPS debug certificate
4	Black key provisioning
6	AES root key certificate

You can use the same or different keys for different sections. When you create a key you assign it permissions and a cancellation ID which is an integer in the range -1-31. Cancellation ID -1 is for an uncancellable key. Uncancellable keys are useful as second- or third-level keys. You can use this key to for two purposes:

To sign other keys with the same or fewer permissions
To sign sections directly

If you use the same cancellation ID for more than one key, canceling any key with that cancellation ID cancels all keys using that cancellation ID. For example, if you assign the same cancellation ID to both the FPGA and HPS keys, canceling the HPS key also invalidates the FPGA key. You can revalidate subsequent uncanceled keys with a signature from another key.

You cannot cancel the root key. Consequently, the root key does not have a cancellation ID. However, you can cancel a signature chain that includes two or more signature levels. Intel strongly recommends that you create a signature chain with at least two levels to retain the ability to update your signature keychain.

A good signature chain includes the following components:

Root key which is not cancellable on Intel^® Stratix^® 10 devices.
First-level public key with a cancellation ID and restricted permissions.
Optional second- and third-level public keys. Normally, these keys are not cancellable and have same permissions as the first-level key which signed them. If you can cancel one key in a key chain you can conserve cancellation IDs by using keys that are not cancellable for the optional second- and third-level keys.

Here are some reasons that you may need to cancel a signature key:

A private key is accidentally released.
You find a vulnerability in your design.
You find a bug in the design after having created the signed configuration bitstream.
You want to update the current design as part of a normal release cycle.

The Programmer performs a logical AND to determine which sections of a design a key can sign. Consequently, to create separate permissions for Core, I/O and PR logic and the HPS and FSBL, you must create two first-level keychains as shown in the following figure.

Figure 5. Create Separate Signature Chains for Different Permissions

3.1.2.1. Canceling Intel Firmware ID

If you are using device security features, Intel recommends that you update your configuration firmware to the latest available release. Additionally, Intel recommends canceling the Intel firmware IDs for older versions of firmware to help ensure the device can only load the most current firmware. This section describes when and how Intel firmware IDs are canceled.

As of Intel^® Quartus^® Prime Pro Edition software version 20.3, Intel has used the following firmware IDs.

Table 5. Intel Firmware IDs
Firmware ID	Firmware Release
0-3	Early versions of firmware
4	Intel^® Quartus^® Prime Pro Edition 19.1 and 19.2
5	Intel^® Quartus^® Prime Pro Edition 19.3 and 19.4
6	Intel^® Quartus^® Prime Pro Edition 20.1
7	Intel^® Quartus^® Prime Pro Edition 20.2 and 20.3
8	Intel^® Quartus^® Prime Pro Edition 20.4

When you program the owner root public key hash into a device, the firmware also cancels ID eFuses to prevent older firmware from running. For example, if you use the 20.1 firmware to program the public key hash, this firmware automatically cancels IDs 0 to 5. The only situation where firmware automatically programs cancellation eFuses is during owner public key hash programming. In all other circumstances, you must use the Intel^® Quartus^® Prime Programmer or mailbox commands to program eFuses.

After you have upgraded to a new version of the firmware you should prevent older versions of firmware from running by following these steps:

Upgrade all bitstreams stored in flash to use the new firmware version. You do not need to recompile your designs. You can recreate them by using the new version of Programmer or quartus_pfg to convert the .sof into a programming file such as .rbf or Programmer Object File .pof. You can then program the upgraded firmware into flash memory.
If using RSU, follow the instructions in the Updates with the Factory Update Image topic in the Intel^® Stratix^® 10 Configuration User Guide to upgrade the decision firmware and factory images in the system to the latest version. The RSU upgrade procedure protects itself against disruptions such as power failure which could interrupt the upgrade.
Reconfigure your device with the updated image, then use the Intel^® Quartus^® Prime Pro Edition Programmer or the mailbox interface to cancel the appropriate Intel key IDs.
Prior to programming an AES root key, you must power cycle the device.

Note: You must program the Intel cancellation eFuses before power cycling the device.

The firmware does not automatically program cancellation eFuses in any case except programming the root public key hash. Consequently, you can upgrade the images in flash memory before programming the cancellation eFuses.

Intel recommends adopting the following practices:

Use the newest available firmware in your configuration bitstreams.
Program cancellation eFuses to prevent older firmware from running on the device.

3.1.2.2. Authentication for HPS Software

If you are using an SoC device, the HPS Boot Code is part of the bitstream that is authenticated by the SDM during configuration.

After you successfully load the HPS Boot Code on the Intel^® Stratix^® 10 device, you may need to ensure that the following boot stages of the HPS Software are also authenticated.

The Rocketboards web page includes an example that uses U-boot to authenticate the subsequent boot stages of the HPS software.

3.2. Creating a Signature Chain

To authenticate an Intel^® Stratix^® 10 FPGA configuration bitstream, you prepare an authentication signature chain which includes root and public keys.

You can use the quartus_sign command to create a signature chain.

The following figure provides an overview of the steps to create an authentication signature chain. It shows the steps for the following operations:

make_root (light yellow)
fuse_info (darker yellow)
append_key (light blue)
sign (light gray)

The make_private_pem and make_public_pem (top right of figure) prepare the public and private keys that are inputs to the four operations listed above.

Figure 6. Steps to Create a Signature Chain

3.2.1. Step 1: Creating the Root Key

The root key includes public and private components. These keys are in the Privacy Enhanced Mail Certificate (PEM) format and have the .pem extension.

Complete the following steps to generate the root private and public keys:

Bring up a Nios^® II command shell.

Option	Description
Windows	On the Start menu, point to Programs > Intel FPGA > Nios II EDS > `<version>` and click Nios II `<version>` Command Shell.
Linux	In a command shell change to the `<install_dir>`/nios2eds and run the following command: ./nios2_command_shell.sh

In the Nios^® II command shell, change to the directory that includes your .sof file.

Run the following command to create the private key which you use to generate the root public key.

Note: You can create the private key with or without passphrase protection. The passphrase encrypts the private key. Intel recommends following industry best practices to use a strong, random passphrase on all private key files. Intel also recommends changing the permissions on the private .pem file to read-only for the owner.

Option	Description
With passphrase	quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> <root_private.pem> Enter the passphrase when prompted to do so.
Without passphrase	quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> --no_passphrase <root_private.pem>

Option

Description

With passphrase

quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> <root_private.pem>
Enter the passphrase when prompted to do so.

Without passphrase

quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> --no_passphrase <root_private.pem>

Run the following command to create the root public key. The root_private.pem you generated in the previous step is an input to this command. You do not need to protect the root public key.
```
quartus_sign --family=stratix10 --operation=make_public_pem <root_private.pem> <root_public.pem>
```
Convert the root public key to the Intel^® Quartus^® Prime key file format (.qky). You use the Intel^® Quartus^® Prime Programmer or the quartus_pgm command to program the root public key into a Intel^® Stratix^® 10 device. The .qky file is a few hundred bytes in size.
```
quartus_sign --family=stratix10 --operation=make_root <root public.pem> <root_public.qky>
```

3.2.2. Step 2: Creating the Design Signing Key

You may need one or more design signing keys. You can create separate signing keys for the HPS and FPGA in Intel^® Stratix^® 10 SX devices. Creating multiple keys gives you the flexibility to cancel keys if you detect an error, uncover a vulnerability, or need to update the design.

Run the following command to create the first design signature private key. You use the design signature private key to create the design signature public key.

Note: Intel recommends following industry best practices to use a strong, random passphrase on all private key files. The curve argument in this command must be the same has the one you specified for the root key.

Option	Description
With passphrase	quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> <design0_sign_private.pem> Enter the passphrase when prompted to do so.
Without passphrase	quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> --no_passphrase <design0_sign_private.pem>

Option

Description

With passphrase

quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> <design0_sign_private.pem>
Enter the passphrase when prompted to do so.

Without passphrase

quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> --no_passphrase  <design0_sign_private.pem>

Run the following command to create the design signature public key.
```
quartus_sign --family=stratix10 --operation=make_public_pem <design0_sign_private.pem> <design0_sign_public.pem>
```
Enter your passphrase when prompted to do so.

3.2.3. Step 3: Appending the Design Signature Key to the Signature Chain

This step appends design signing keys to the signature chain. The append command implements the following operations:

Appends the 1st Level Public Key (design0_sign_public.pem) to the Root Public Key (root_public.qky) and generates the 1st Level Signature Chain (design0_sign_public.qky) that includes the root public key and design0 public key.
Signs the new 1st Level Signature Chain (design0_sign_chain.qky) using the Root Private Key (root_private.pem).

Run the following command to append the first design signature key to the root key, creating a two-level signature chain:

Setting the permission argument to 6 creates a signature that can sign the FPGA I/O, core, PR, and HPS sections. Setting the permission argument to 2 or 4 creates a signature that can sign only FPGA or HPS sections, respectively. Setting the cancellation argument to 0 means that eFuse0 can cancel this signature. eFuses 0-31 are available for owner cancellation.
```
quartus_sign --family=stratix10 --operation=append_key \
 --previous_pem=<root_private.pem> --previous_qky=<root_public.qky> \
 --permission=6 --cancel=0 <design0_sign_public.pem> \
 <design0_sign_chain.qky>
```
Useappend_key again to create a three-level signature chain:
1. Repeat the commands in Step 1, to generate both design1_sign_private.pem and design1_sign_public.pem.
2. Append design1_sign_public.pem to the signature chain.
  Setting the cancellation argument to 1, means that the second available cancellation eFuse, eFuse 1, cancels this signature.
```
quartus_sign --family=stratix10 --operation=append_key \
 --previous_pem=<design0_sign_private.pem> \ --previous_qky=<design0_sign_chain.qky> --permission=6 \
 --cancel=1 <design1_sign_public.pem> <design1_sign_chain.qky>
```
Enter the passphrase when prompted to do so.
If you are generating separate keychains for HPS and FPGA signing, repeat steps 1 and 2 with different PEM files. The FPGA signing chain should have permission=2. The HPS signing chain should have permission=4.

3.2.4. Step 4: Signing the Bitstream

Once you generate the private PEM and .qky files, you are ready to sign the bitstream. There several options for bitstream signing:

You use Intel^® Quartus^® Prime Programming File Generator to generate the signed bitstream from a .sof file. You specify the required format for your configuration scheme. The JTAG Indirect Configuration File (.jic) and Raw Programming Data File (.rpd) formats are available for Active Serial (AS) configuration. The Programmer Object File .pof and .rbf are available for Avalon^® Streaming ( Avalon^® -ST) configuration.
You can also use quartus_sign command to sign the bitstream. This command requires the .rbf as the input to generate a signed .rbf file.

Note:

If you are using the Jam* Standard Test and Programming Language (STAPL) Player to program over JTAG the following command converts an .rbf file to the .jam format that the Jam STAPL Player requires:

quartus_pfg -c signed_bitstream.rbf signed_bitstream.jam

3.2.5. Step 4a: Signing the Bitstream Using the Programming File Generator

The Programming File Generator requires the private key file (.pem) to sign the configuration bitstream. You append the generated signature chain (.qky) to your compiled design .sof. Attaching the signature chain to your .sof does not require you to recompile your design.

Complete the following steps to append the signature chain key file to the .sof file and generate the signed bitstream using the Programming File Generator.

Choose one of the following options to append the signature chain key file the configuration bitstream:
- Specify the .qky file using the Intel^® Quartus^® Prime software. On the Assignment tab, select Device > Device and Pin Options > Security > Quartus Key File. Then browse to your signature key chain file.
  Figure 7. Specifying the Quartus Key File
- Alternatively, you can add the following assignment statement to your Intel^® Quartus^® Prime Settings File (.qsf):
```
set_global_assignment -name QKY_FILE <signature_chain.qky>
```
- You can also specify the owner cancellation ID mask using the following assignment in your Intel^® Quartus^® Prime Settings File (.qsf):
```
set_global_assignment -name PERMITTED_OWNER_CANCELLATION_ID 4
```
To generate a .sof that includes design1_sign_keychain.qky select Processing > Start > Start Assembler.
The new .sof includes the design1_sign_keychain.qky signature chain.
On the Intel^® Quartus^® Prime file menu, select File > Programming File Generator.

Figure 8. Programming File Generator
For Device family, select Intel^® Stratix^® 10
For Configuration mode, select the configuration mode you plan to use. This example uses AVST x16.
For Output directory click Browse and navigate to your output files directory.
On the Output Files tab, select Raw Binary File (.rbf).
On the Input Files tab, click Add Bitstream then browse and select your .sof file.

Figure 9. Input File Properties
On the Input Files tab, click Properties… and make the following selections under Signing tool settings:
1. Select On for Enable signing tool.
2. For Private key file, select the final private signing key. For example, Figure 6 Steps to Create a Signature Chain shows a root private key and two private keys. For this key chain, you would select the second-level private .pem file.
  
  Note: If your .pem is password-protected, the GUI opens a dialog box to enter the password.

3.2.6. Step 4b: Signing the Bitstream Using the quartus_sign Command

The quartus_sign command takes the signature chain (.qky), a private signing key (.pem), and the unsigned raw binary file (.rbf) as inputs to generate the signed .rbf.

You can generate the unsigned bitstream in .rbf format using the following command:

quartus_pfg -c design.sof unsigned_bitstream.rbf

Run the following command to sign the bitstream using a command-line command:

> quartus_sign --family=stratix10 --operation=sign \ 
--qky=design1_sign_keychain.qky --pem=design1_sign_private.pem \
 unsigned_bitstream.rbf signed_bitstream.rbf

3.2.7. Step 5: Programming the Owner Root Public Key for Authentication

Your manufacturing process programs the hash of the owner root public key, root_public.qky, into eFuses available on the Intel^® Stratix^® 10 device. Programming the hash value into actual eFuses on the device is irreversible. During development, you can validate the hash value by programming this value into virtual eFuses. The virtual eFuses are volatile. Values stored in eFuses clear each time you power cycle the Intel^® Stratix^® 10 device. eFuses do not use the dedicated V_CCBAT power supply.Refer to the Intel^® Stratix^® 10 Device Family Pin Connection Guidelines for information about the power supply for writing eFuses.

You can use the Intel^® Quartus^® Prime Software to program the public root key for authentication. Alternatively, you can use a command-line command to accomplish this task.

3.2.8. Step 5a: Programming the Owner Root Public Key

On the Tools menu, select Programmer.
Right click the image of the Intel^® Stratix^® 10 device and select Edit > Add QKY/QEK/Fuse file ....
Browse to the owner root public key file and click Open.

Note: Once you have specified the QKY file, the programmer displays the compatible version of firmware that you use to program the device. The version of the Intel^® Quartus^® Prime Programmer and the firmware must match.
You can choose to program the non-volatile eFuses or simulate the actual hardware using virtual eFuses.

CAUTION:
Incorrect fuse programming can make your device unusable. Intel recommends that you test all eFuse programming sequences using virtual fusing before you program physical eFuses on your first device.
- To select virtual eFuses, on the Programmer Tools menu, select Options. Turn on Enable device security using a volatile security key if this option is not already on. By default this option is on. Then, select OK.
- To select the actual non-volatile eFuses, on the Programmer Tools menu, select Options. Turn off the Enable device security using a volatile security key option.
To verify that the fuse value and the hash value of the owner root public key match, turn on the Verify option in the Intel^® Quartus^® Prime software.
Click Start to program the owner root public key.

3.2.9. Step 5b: Calculating the Owner Root Public Key Hash

Use the quartus_sign command with the operation set to the fuse_info operation to generate the hash of the root public key, as follows:

quartus_sign --family=stratix10 --operation=fuse_info \
 public_root.qky hash_fuse.txt

To validate the owner root public key hash, you can compare the value of hash_fuse.txt to the value you observe when turn on the Examine option while configuring the Intel^® Stratix^® 10 device in the Intel^® Quartus^® Prime Pro Edition Programmer.

3.2.10. Verifying a Configuration Bitstream Signature

The Intel^® Quartus^® Prime Programming File Generator includes an option to check the integrity of a signed bitstream. This option also verifies the signature blocks in the bitstream and prints important information, such as the expected value of the root key hash, public key values, permissions, and the contents of each signature chain for each section.

The following command runs an integrity check;

$ quartus_pfg --check_integrity signed_bitstream.rbf

Here is an example of the output of the command:

Info: Command: quartus_pfg --check_integrity output_file_signed.rbf
Integrity status: OK

Section
Type: CMF
Signature Descriptor ...
Signature chain #0 (entries: 3, offset: 96)
Entry #0
Fuse: A1B9545C CAC4152D 9511A9AB 321778ED 1180A280 6DC58F2C
5607433E 02A872E3 F52B2AE5 F7B8BDE0 53FA000D 8FC7AC04
Generate key ...
Curve : secp384r1
X: FC28C88662DF1437DD98E61336467DC9CDA788F22F949D8F488DA755A9F8CC11AEC10006E2
   6490B3EAB8148E6C8AA8A1
Y: 95D1EA0FF4C7374B350FDF39CFAE3AD8D0AEA9451EA66B5B1DFD4084DA68BC4DAD3AF5CF37
   8D7C6FB62A10BA7C512276
Entry #1
Generate key ...
Curve : secp384r1
X: B11534AA67A30EF884B89819281522F1D0326BBAFF108BC483946717A14F9630C682ECDAE5
   40FECBADF3E66BC92A110A
Y: 0ED5F19E6A38D97148CE6F53B679227311198105BD9E1912AD41C075711F6185E1B095DE7F
   E2F4855851E78F9BF3D2C6
Entry #2
Keychain permission: SIGN_CODE
Keychain can be cancelled by ID: 5
Signature chain #1 (entries: 0, offset: 0)
Signature chain #2 (entries: 0, offset: 0)
Signature chain #3 (entries: 0, offset: 0)

Section
Type: IO
Signature Descriptor ...
Signature chain #0 (entries: 5, offset: 96)
Entry #0
Fuse: 46D2D1CD 666F6FA3 8CA6DF11 F09F1E84 41162254 D5E811F0 0B72B678 52D29F2F
Generate key ...
Curve : prime256v1
X: DD4E3FB89EC29E0F2C9435A8D74E0780F2282367EABF4F84FD207A80EFDA1552
Y: 9A8A74E440002AE72FF67716FE889C49DD5D0FD4FBC7195324DE267BFF06FF49

Entry #1
Generate key ...
Curve : prime256v1
X: 7EF9D2C6D246339E6D58B937D4127F83FF590B64663FEC316A418847AAA82505
Y: 29EE71EAFC4CDBB99414C2673EA7AD44B4EE4442E803D350590DA0D95A0F2EF5

Entry #2
Generate key ...
Curve : prime256v1
X: 3A9083FF4B91136EAC43041916C2E1FC887397ABCEA017DE42AF143DBEA17ED8
Y: 4DDDD1670C3F846EFFC4B071BC8D291FD9477EE035AD9C46B696DD20F5702809

Entry #3
Generate key ...
Curve : prime256v1
X: 8A1FBB3D3F0E5961E7FFF7D8E94AFD1836752169A9E66B79BB5861BBDA79E53F
Y: 361FE17E8C73DE0FB4277480FAED32363A3C134DD27D6961E6F046222F06D600

Entry #4
Keychain permission: SIGN_CORE, SIGN_HPS
Keychain can be cancelled by ID: 0, 0, 0
Signature chain #1 (entries: 0, offset: 0)
Signature chain #2 (entries: 0, offset: 0)
Signature chain #3 (entries: 0, offset: 0)

Section
Type: HPS
Signature Descriptor ...
Signature chain #0 (entries: 5, offset: 96)

Entry #0
Fuse: 46D2D1CD 666F6FA3 8CA6DF11 F09F1E84 41162254 D5E811F0 0B72B678 52D29F2F
Generate key ...
Curve : prime256v1
X: DD4E3FB89EC29E0F2C9435A8D74E0780F2282367EABF4F84FD207A80EFDA1552
Y: 9A8A74E440002AE72FF67716FE889C49DD5D0FD4FBC7195324DE267BFF06FF49

Entry #1
Generate key ...
Curve : prime256v1
X: 7EF9D2C6D246339E6D58B937D4127F83FF590B64663FEC316A418847AAA82505
Y: 29EE71EAFC4CDBB99414C2673EA7AD44B4EE4442E803D350590DA0D95A0F2EF5

Entry #2
Generate key ...
Curve : prime256v1
X: 3A9083FF4B91136EAC43041916C2E1FC887397ABCEA017DE42AF143DBEA17ED8
Y: 4DDDD1670C3F846EFFC4B071BC8D291FD9477EE035AD9C46B696DD20F5702809

Entry #3
 Generate key ...
Curve : prime256v1
X: 8A1FBB3D3F0E5961E7FFF7D8E94AFD1836752169A9E66B79BB5861BBDA79E53F
Y: 361FE17E8C73DE0FB4277480FAED32363A3C134DD27D6961E6F046222F06D600

Entry #4
Keychain permission: SIGN_CORE, SIGN_HPS
Keychain can be cancelled by ID: 0, 0, 0
Signature chain #1 (entries: 0, offset: 0)
Signature chain #2 (entries: 0, offset: 0)
Signature chain #3 (entries: 0, offset: 0)

Section
Type: CORE
Signature Descriptor ...
Signature chain #0 (entries: 5, offset: 96)

Entry #0
Fuse: 46D2D1CD 666F6FA3 8CA6DF11 F09F1E84 41162254 D5E811F0 0B72B678 52D29F2F
Generate key ...
Curve : prime256v1
X: DD4E3FB89EC29E0F2C9435A8D74E0780F2282367EABF4F84FD207A80EFDA1552
Y: 9A8A74E440002AE72FF67716FE889C49DD5D0FD4FBC7195324DE267BFF06FF49

Entry #1
 Generate key ...
Curve : prime256v1
X: 7EF9D2C6D246339E6D58B937D4127F83FF590B64663FEC316A418847AAA82505
Y: 29EE71EAFC4CDBB99414C2673EA7AD44B4EE4442E803D350590DA0D95A0F2EF5

Entry #2
Generate key ...
Curve : prime256v1
X: 3A9083FF4B91136EAC43041916C2E1FC887397ABCEA017DE42AF143DBEA17ED8
Y: 4DDDD1670C3F846EFFC4B071BC8D291FD9477EE035AD9C46B696DD20F5702809

Entry #3
Generate key ...
Curve : prime256v1
X: 8A1FBB3D3F0E5961E7FFF7D8E94AFD1836752169A9E66B79BB5861BBDA79E53F
Y: 361FE17E8C73DE0FB4277480FAED32363A3C134DD27D6961E6F046222F06D600

Entry #4
Keychain permission: SIGN_CORE, SIGN_HPS
Keychain can be cancelled by ID: 0, 0, 0
Signature chain #1 (entries: 0, offset: 0)
Signature chain #2 (entries: 0, offset: 0)
Signature chain #

3.3. Co-Signing Device Firmware Overview

Intel programs each Intel^® Stratix^® 10 device with an Intel root public key hash during the manufacturing process. Boot code stored in read-only memory in the Intel^® Stratix^® 10 SDM uses this hash to validate an Intel signature chain. This process helps to ensure that only firmware that Intel has approved can run on the device. Intel only signs firmware after a rigorous audit process.

The Intel^® Quartus^® Prime Software supports co-signing device firmware. Co-signing adds another layer of protection for device firmware. The joint signature capability allows you to sign device firmware with an owner signing key that you generate. You enable the co-signature by programming the owner root public key hash and the co-signed firmware eFuses. Once you program these security fuses, loading new firmware requires both Intel and owner signatures.

3.3.1. Using the Co-Signing Feature

The following figure provides an overview of the steps to create an signature chain to co-sign the device firmware.

Firmware Co-Signing Design Flow

It shows the steps for the following operations:

Generating an owner firmware key and appending this key owner FW public .pem) to the existing owner keychain (owner FW key.qky).
Co-signing the firmware. Add the owner signature to Stratix10.zip using the new keychain and the Owner FW Private .pem file.
Note: The Stratix10.zip file is available in the <install_dir>/quartus/common/devinfo/programmer/firmware/ directory. This file includes the SDM firmware.
Programming the Co-Signed Firmware eFuses in the Intel^® Stratix^® 10 device using the signed firmware (Signed FW signed_Stratix10.zip) and owner.fuse as inputs.

Note: Refer to Using eFuses for more information about programming the Co-Signed Firmware virtual or physical eFuses.

3.3.1.1. Prerequisites for Co-Signing Device Firmware

Before completing the steps to co-sign device firmware, you must generate an owner root key and program the owner root public key hash eFuse in the eFuses on your Intel^® Stratix^® 10 device.

To generate the owner root key follow the instructions in Step 1: Creating the Root Key or by using your own custom hardware security module.

Then program the owner root public key hash into eFuses. By default, the quartus_pgm command programs the root public key hash into virtual (volatile) eFuses. You can use the optional --non_volatile_key argument to specify physical eFuses on the Intel^® Stratix^® 10 device. Here are both versions of the quartus_pgm command:

//For physical (non_volatile) eFuses on the 
               Intel^® 
               Stratix^® 10 device
quartus_pgm -c 1 -m jtag -o "p;root_public.qky" --non_volatile_key

//For virtual (volatile) eFuses
quartus_pgm -c 1 -m jtag -o "p;root_public.qky"

Alternatively, you can use the Intel^® Quartus^® Prime Programmer to program the owner root key as described in Step 5a: Programming the Owner Public Root Public Key.

3.3.1.2. Generating the Owner Firmware Signing Key

You use the Intel^® Quartus^® Prime Signing Tool operation=append_key to append a firmware signing key to the owner root public key. The permission is set to 1 for firmware.

The first two steps generate required inputs to the operation=append_key command shown in Step 3.

Run the following command to generate a private key you use to sign the firmware.

quartus_sign --family=stratix10 --operation=make_private_pem \ 
 --curve=prime256v1 or <secp384r1> owner_fw_private.pem

Run the following command to generate the corresponding firmware public key from owner_fw_private.pem.
```
quartus_sign --family=stratix10 --operation=make_public_pem \ 
owner_fw_private.pem owner_fw_public.pem
```

Run the following command to append the owner_fw_public.pem to the owner root keychain

quartus_sign --family=stratix10 --operation=append_key \ 
--previous_pem=owner_root_private.pem --previous_qky=owner_root_public.qky \
 --permission=0x1 --cancel=1 owner_fw_public.pem owner_fw_key.qky

3.3.1.3. Co-Signing the Firmware

You use the Intel^® Quartus^® Prime Signing Tool operation=sign to sign the firmware with your private firmware key.

Run the following command to co-sign the firmware file. The firmware file is Stratix10.zip. The Intel^® Quartus^® Prime Software writes this file to the <install_dir>/ quartus/common/devinfo/programmer/firmware/ directory.

quartus_sign --family=stratix10 --operation=sign --qky=owner_fw_key.qky \ 
--pem=owner_fw_private.pem Stratix10.zip signed_Stratix10.zip

Refer to Programming eFuses for instructions on programming eFuses.

3.3.1.4. Powering On In JTAG Mode After Implementing Co-Signed Firmware

After you program the co-signed firmware eFuse, the Intel^® Stratix^® 10 device requires all configuration bitstreams to include co-signed firmware on every subsequent power-on. The existing helper image containing the SDM firmware is now out-of-date because it does not specify co-signed firmware. You must regenerate a new signed_helper_image.rbf file that specifies co-signed firmware.

The example commands specify the helper_device 1SX280LH2. If you are using a different Intel^® Stratix^® 10 device, provide the appropriate ordering code for that device up to the speed grade designation. Helper images are necessary for flash and fuse programming using the Intel^® Quartus^® Prime Programmer. The helper image programs the SDM firmware.

To find the list of helper devices, in the Intel^® Quartus^® Prime Programmer, select Add Device.
In the Device family list, select Intel^® Stratix^® 10 . In the Device name list, identify the find the part number that matches your device.

Figure 10. User the Programmer to Determine the helper_device Argument

Generate a signed helper image for eFuse programming.

quartus_pfg --helper_image -o helper_device=1SX280LH2 -o subtype=FUSE \ 
 -o fw_source=signed_Stratix10.zip signed_helper_image.rbf

Configure your Intel^® Stratix^® 10 device with the signed_helper_image.rbf file you just created.
```
quartus_pgm -c 1 -m jtag -o “p;signed_helper_image.rbf” 
```

3.4. Signing Command Detailed Description

The signing command, quartus_sign, supports the following functions:

Generates the private and public PEM files
Generates the signature chain starting with the root public key
Appends additional public keys to the signature chain
Signs a bitstream, firmware, or debug certificate
Calculates the root public key hash from the signature chain file .qky file

The quartus_sign command always specifies the FPGA device family and operation. Here is the general format of the command:

quartus_sign --family=stratix10 --operation=<type of operation> [additional arguments]

The following table summarizes all the quartus_sign operations.

Table 6. Signing Command Argument Summary
Argument	Options	Description
`operation`	`make_private_pem`	Generates a private key in .pem format such as root_private.pem.
	`make_public_pem`	Generates a public key in .pem format from the private .pem such as root_public.pem.
	`make_root`	Creates a new Intel^® Quartus^® Prime keychain .qky file with a given public key .pem in the root entry such as root_public.qky.
	`append_key`	Signs, appends, and sets the permissions and cancellation ID of an additional public key to an existing signature chain in the Intel^® Quartus^® Prime keychain `.qky` format.
	`sign`	Signs the bitstream with the .pem private key and key chain.
	`fuse_info`	Calculates the root public key hash from the .qky file.

The following topics provide details on each operation. The operations are listed in the order that you normally run them to create a signature chain, sign the bitstream, and calculate the root public key hash.

3.4.1. Generate Private PEM Key

The first step in generating the signature chain is creating the private PEM.

Command	quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> <output private PEM file> or: quartus_sign --family=stratix10 --operation=make_private_pem --curve=<prime256v1 or secp384r1> --no_passphrase <output private PEM file>
Input file	None
Output file	Private PEM file
Arguments	This command includes 1 required argument and 1 optional argument: `curve`: Selects the Elliptic Curve Digital Signature Algorithm (ECDSA) 256 or 384. Intel recommends using `secp384r1` if possible because `prime256v1` may be vulnerable to attacks within the next 20 years. `no_passphrase`: By default the `make_private_pem` command encrypts the private key. You can add the optional `--no_passphrase` argument to create a plain text key. Intel recommends following industry best practices to use a strong, random passphrase on all private key files.

3.4.2. Generate Public PEM Key

The second step in generating the signature chain is generating the public PEM file from the private PEM file.

Command	quartus_sign --family=stratix10 --operation=make_public_pem <input private PEM file> <output public PEM file>
Input file	`input private PEM file`: This is the file that the `make_private_pem` generates.
Output file	`output public PEM file`: `make_public_pem` generates this file.
Arguments	This command has no additional arguments.

3.4.3. Generate Root Signature Chain

The third step in generating the signature chain makes the root public key by converting the public key PEM file to the Intel^® Quartus^® Prime key format.

Command	quartus_sign --family=stratix10 --operation=make_root <input root public PEM file> <output root public qky file>
Input file	`input public PEM file`: This is the file that the `make_public_pem` generates.
Output file	`output root public qky file`: `make_root` generates this file.
Arguments	This command has no additional arguments.

3.4.4. Append Key to Signature Chain

The append command implements the following functions:

Uses the private part of the last-appended public key to sign the new public key
Appends the specified design signing key to the root public Intel^® Quartus^® Prime keychain
Assigns specified permissions and cancellation ID to the appended public key

Command	quartus_sign --family=stratix10 --operation=append_key --previous_pem==<private PEM for the public key of last entry in input QKY> --previous_qky=<input QKY> --permission=<permission value to authenticate> --cancel=<cancel ID> <public PEM for new entry> <output QKY>
Input files	The `append_key` command has 3 input files: `previous_pem`: The private PEM file that is input to the `make_public_pem` operation. This private PEM is from the previous entry in the input signature chain. `previous_qky`: Intel^® Quartus^® Prime .qky format keychain to which the the `quartus_sign` command appends the new public key.
Output file	The `append_key` outputs 1 file: `output_key`: This is the new signature chain with one additional entry.
Arguments	This command includes 2 arguments: `permission`: Sets the signing key permission value. These bits are positional. Each bit grants permission to sign a particular type of data. To allow a key to sign more than one type of data, you can add the permissions for the data types. For example, a permission value of 6 can sign all data types that permissions 2 and 4 can sign. The following values are valid: 1: To sign firmware 2: To sign FPGA I/O, core sections, and PR sections 4: To sign HPS I/O and the FSBL 8: To sign an HPS debug certificate `cancel`: Specifies the cancellation ID to cancel this signature. The valid range is 0-31. The special value of -1 is for keys that are uncancellable.

3.4.5. Sign the Bitstream, Firmware, or Debug Certificate

The sign operation takes an unsigned image.rbf, firmware.zip, debug.cert as input. The sign operation generates a signed output file, either signed_image.rbf, signed_firmware.zip, or signed_debug.cert.

For .rbf generation, you convert the .sof to an .rbf using either the Intel^® Quartus^® Prime File > Programming File Generator dialog box or the quartus_pfg command-line command.

Command	quartus_sign --family=stratix10 --operation=sign --qky=<qky file> --pem=<private PEM for the public key of last entry in the input QKY> <unsigned rbf, unsigned firmware zip file, unsigned debug certificate> <signed rbf, firmware zip file, or signed debug certificate>
Input file	The sign operation supports the following 3 input file types: `unsigned rbf file`: This is the .rbf that you generate from the .sof `unsigned firmware zip file`: quartus/common/devinfo/programmer/firmware/Stratix10.zip. This file contains the SDM firmware. `unsigned debug certificate file`: This is the unsigned debug certificate you create from the programmed device by running the following command: `quartus_pgm -c 1 -m jtag -o “ei;hps_unsigned.cert;<device>"`
Output file	`signed rbf file`, `signed firmware zip file`, or `signed certificate file`: This file is the output of the `sign` operation.
Arguments	This command has 2 additional arguments: `qky`: This is the .qky file generated by the previous `append_key` or `make_root` operation. `pem`: This is the private PEM for the previous public key of the input QKY.

Refer to Step 4: Signing the Bitstream for the steps to sign the bitstream using the Programing File Generator tool.

3.4.6. Calculate Root Public Key Hash from QKY

The fuse_info operation returns the hash of the root public key.

Command	quartus_sign --family=stratix10 --operation=fuse_info <input QKY> <fuse output text>
Input file	`input QKY`: This is the root public key.
Output file	`fuse output text`: Manufacturing uses this text file to program the specified eFuses of the Intel^® Stratix^® 10 device.
Arguments	This command has no additional arguments.

3.4.7. Signing Tool (with Source Code)

Intel provides a reference implementation of the Intel^® Stratix^® 10 bitstream signing tool with Intel^® Quartus^® Prime Pro Edition software, including source code. You may use this implementation to sign bitstreams, extend to integrate with a Hardware Security Module (HSM) of your device, or use it as a reference for your bitstream signing tool.

The reference implementation file is stratix10_sign.py and is available in the <install_dir>/quartus/common/devinfo/programmer/python directory.

4. Encryption and Decryption

A single AES root key under owner control encrypts the dynamic blocks of the Intel^® Stratix^® 10 configuration bitstream.

Encryption Process

You can store the owner AES Root key in virtual eFuses, physical eFuses, BBRAM, or quad SPI flash memory as a PUF-wrapped key. To prevent overuse of the AES root key, the root key encrypts a chain of intermediate keys. The root key encrypts the first intermediate key, which encrypts the second intermediate key, and so on. The last intermediate key encrypts the section keys.

Encryption supports up to 20 intermediate keys. By default, the encryption function uses three intermediate keys. These keys mitigate side channel attack risk by limiting the exposure of the final key to encrypt a given section of the bitstream.

Intel recommends that you limit the amount of data encrypted with the same key using AES update mode. You enable AES update mode by setting the Assignments > Device > Device and Pin Options > Security > Encryption Update Ratio parameter to 31:1. When enabled, the Intel^® Quartus^® Prime Pro Edition Software inserts keys to limit the amount of data encrypted by a given key to the specified ratio. For example, the 31:1 ratio inserts a new key every 31 * 32 bytes. Different ratios may become available in a future release.

Figure 11. Security Tab: AES Encryption Key Update Ratio and Enable Scrambling

Figure 12. AES Update Mode

Decryption Process

The section key decrypts the keys block which contains up to 128 keys. Each key is 256 bits and decrypts subsequent encrypted data or another keys block.

Figure 13. Bitstream Decryption

The initialization vector (IV) is unencrypted data that is an input to the decryption function.

Understanding Partially Encrypted Configuration Bitstreams

Configuration bitstream encryption is a two-step process. In the first step, the Intel^® Quartus^® Prime Software writes a partially encrypted bitstream to your working directory. In the second step, the bitstream encryption is finalized. The steps separation ensures the bitstream generation process does not need access to your AES root key.

A partially encrypted configuration bitstream has no intermediate keys, and the section keys are in plaintext. The encryption finalization step converts a partially-encrypted bitstream to a fully-encrypted bitstream by generating intermediate keys using the AES root key and encrypting the section keys using the last intermediate key.

Enable Scrambling

The Enable Scrambling parameter helps to limit any potential side-channel exposure of decrypted configuration data during the configuration process. Enabling this option places a command in the configuration bitstream that the SDM processes at configuration time. The Enable Scrambling parameter does not affect the encryption or decryption process.

4.1. Using the Encryption Feature

Encrypting the owner image includes the following three steps:

Step 1: Preparing the owner image and AES key files
Step 2: Generating the programming files
Step 3: Programming the AES key and configuring the encrypted owner image

The following flow diagram shows the processes required for each step.

Figure 14. Design Flow for Owner Image Encryption in Intel^® Stratix^® 10 Devices

4.1.1. Step 2a: Generating Programming Files Using the Programming File Generator

You can use the Programming File Generator to encrypt and sign the owner image.

The Programming File Generator supports the following signed and encrypted output file types:

Raw Binary File (.rbf)
JTAG Indirect Configuration File (.jic)
Programmer Object File (.pof)
Raw Programming Data File (.rpd)

On the Intel^® Quartus^® Prime File menu select Programming File Generator.
On the Output Files tab, specify the output file type for your configuration scheme.

Figure 15. Output File Specification
On the Input Files tab, click Add Bitstream and browse to your .sof.
To specify encryption and authentication options select the .sof and click Properties.
1. Turn Enable signing tool on.
2. For Private key file select your signing key private .pem file.
3. Turn Finalize encryption on.
4. For Encryption key file, select your AES .qek file.
  
  Figure 16. Input (.sof) File Properties for Authentication and Encryption
To generate the signed and encrypted bitstream, on the Input Files tab, click Generate.
The password dialog box prompts you to input your passphrase for the .qek. The programming file generator generates top.rbf if the passphrase is correct.

4.1.2. Step 2b: Generating Programming Files Using the Command Line Interface

For JTAG or Avalon^® -ST configuration schemes, you can use the quartus_pfg script to generate the signed and encrypted output file.

In your output files directory, run the following command:

quartus_pfg -c encryption_enabled.sof top.rbf -o finalize_encryption=ON \ 
-o qek_file=aes.qek -o signing=ON -o pem_file=design0_sign_private.pem

The password dialog box prompts you to input your passphrase for the aes.qek. The programming file generator generates top.rbf if the passphrase is correct.

4.1.3. Step 2c: Generating Partially Encrypted Programming File Using the Command Line Interface

You may generate a partially encrypted programming file in order to finalize encryption and sign the image at a later time. You use the command line to generate the partially encrypted file in the raw binary file (.rbf) format. After finalizing encryption and signing, you can covert the generated output file to any appropriate format.

You use the quartus_pfg command line interface to generate the partially encrypted programming file.

In your output files directory, run the following command:

quartus_pfg -c -o finalize_encryption_later=ON \
-o sign_later=ON top.sof top.rbf

The generated output file is in .rbf format.

Use command in Encrypt the Bitstream to finalize encryption. After you finalize the encryption, you must sign the programming file using instructions in Step 4b: Signing the Bitstream Using the quartus_sign Command section.

4.1.4. Step 3a: Specifying Keys and Configuring the Encrypted Image Using the Intel Quartus Prime Programmer

You should already have specified a storage location for your .qek on the Security page of the Assignments > Device > Device and Pin Options. In the current release, you can select Battery Backup RAM (BBRAM), eFuses, or Quad SPI Intrinsic ID PUF-wrapped. After you make this selection, the Intel^® Quartus^® Prime Pro Edition Software identifies the .sof file as encryption enabled and records your settings for the Encryption key select and Encryption update ratio.

Note: If you intend to program your AES root key into physical eFuses, you must first follow the procedure in section Storing the AES Key in Physical eFuses.

Figure 17. Specify Storage Location for Encryption Key

Bring up the Intel^® Quartus^® Prime Programmer.
Right click the Intel^® Stratix^® 10 device and select Add QKY/QEK/FUSE File file. Navigate to your .qky file and select it.

Figure 18. Adding .qky, .qek or .fuse files
Enable the Program/Configure option for the .qky file. Disable the Program/Configure for any other files that may be selected. Click Start to program the authentication key into your Intel^® Stratix^® 10 device.

Figure 19. Program/Configure A Key File
Right click the Intel^® Stratix^® 10 device and select Add QKY/QEK/FUSE File. Navigate to your .qek file and select it.
Enable the Program/Configure option for the .qek file. Disable the Program/Configure for any other files that may be selected. Click Start. The Passphrase dialog box appears. Enter your passphrase. The encryption key programs into the BBRAM, virtual eFuses or physical eFuses on the Intel^® Stratix^® 10 device.

With the keys programmed, you can load the signed and encrypted .rbf bitstream image.

Option	Description
Using the Intel^® Quartus^® Prime Programmer:	Enable the Program/Configure option for the .rbf file. Disable the Program/Configure for any other files that may be selected. Click Start.
Using a Intel^® MAX^® 10 device or other external host:	Instruct the configuration hardware to configure the Intel^® Stratix^® 10 device from the flash memory.

If you previously programmed the authentication key into physical eFuses, it is important to remove this directive until you intend to do additional physical eFuse programming. Select Tools > Options > Programmer to restore the Enable device security using a volatile security key setting. Having volatile security selected ensures that you do not program physical eFuses unintentionally.

4.1.5. Step 3b: Programming the AES Key and Configuring the Encrypted Image Using the Command Line

You use the Intel^® Quartus^® Prime Programmer to program the owner AES key into the device. Then, configure the device using the encrypted bitstream.

You should already have specified a storage location for your .qek as explained in Step 3a: Using the Intel^® Quartus^® Prime Programmer to Specify Keys and Configure the Device. You can also specify this parameter using the --key_storage argument to the quartus_pgm command.

Note: If you intend to program your AES root key into physical eFuses, you must first follow the procedure in next section Storing the AES Root Key in Physical eFuses.

You can program the key file using the quartus_pgm command:

CAUTION:
Incorrect programming of security eFuses can permanently prevent the device from configuring. Intel strongly recommends before programming any security eFuse that you test using the virtual eFuses to ensure that the values being programmed are correct.
```
// For BBRAM
quartus_pgm -c 1 -m jtag -o "pi;aes.qek" --key_storage="BBRAM"

// For virtual eFuses
 quartus_pgm -c 1 -m jtag -o "pi;aes.qek" --key_storage="Virtual eFuses"

// For physical eFuses
 quartus_pgm -c 1 -m jtag -o "pi;aes.qek" --key_storage="Real eFuses"
```
The command arguments specify the following information:
- -c: cable number
- -m: mode
- -o: operation. The argument to operation is enclosed in quotes. The letters specify the following operations:
  - p: program
  - i: load a helper image containing SDM firmware
    Note: This option is required only on the first programming command. If you are using a co-signed helper image, you may program that image prior to programming the .qek encryption key.
  - ;: the argument following the ; specifies the programming file
- --key_storage: specifies the location for the encryption key. The following values are available: BBRAM, Virtual eFuses, or Real eFuses.
  Note: The current release only supports PUF storage in quad SPI flash memory as part of a .jic file. The following command programs flash memory over the JTAG interface:
```
quartus_pgm -c <cable_name> -m jtag -o “p;cfg-bitstream.jic”
```
Here are some additional commonly used arguments to the quartus_pgm command:
- b: blank check
- v: verify
- e: examine
Now program the signed encrypted bitstream using the following commands:
```
quartus_pgm -c 1 -m jtag -o "p;encrypted.rbf"
```

4.1.6. Storing the AES Key in Physical eFuses

Beginning in version 19.3, the Intel^® Quartus^® Prime Software supports storing the AES root key in physical eFuses. To help protect the AES root key from extraction via physical examination of the fuses, the SDM firmware wraps the AES root key and stores the wrapped value in eFuses. You must cancel Intel firmware IDs 0-4 at a minimum prior to programming your AES root key in physical eFuses. However, Intel recommends using the latest version of the Intel^® Quartus^® Prime Programmer to program the root key hash, which automatically cancels Intel firmware IDs.

After programming the appropriate Intel firmware IDs, you must power cycle your system. To program the AES root key into physical eFuses, use the Programmer to send the .qek file to the Intel^® Stratix^® 10 device.

quartus_pgm -c <cable_index> -m JTAG -o "pi;aes.qek" --key_storage "<storage_location>"

The command arguments specify the following information:

-c <cable_index>: specifies the device index of to program on the JTAG chain
-m JTAG: specifies JTAG as the programming mode
-o: operation. The argument to operation is enclosed in quotes. The letters specify the following operations:
- p: program
- i: load a helper image if the device not already configured. This is an optional parameter.
- aes.qek: specifies the .qek file path
--key_storage: specifies the on-chip storage location for the AES key. The following values are available: BBRAM, Virtual eFuses, or Real eFuses. This option is specific to the .qek files.

4.1.7. Storing the AES Key in BBRAM using the JTAG Mailbox

You can use the JTAG Mailbox VOLATILE_AES_WRITE and VOLATILE_AES_ERASE commands to write the AES Key to BBRAM and erase the AES key from BBRAM.

For more information about using these commands, refer to the How can I write or erase the Intel^® Stratix^® 10 AES BBRAM encryption key using the Mailbox Client Intel^® FPGA IP interface and System Console?

4.2. Using a PUF-Wrapped AES Key

Intel^® Stratix^® 10 devices utilize Intrinsic ID technology to implement an SRAM Physically Unclonable Function (PUF) that can be used as a secure and flexible option for AES key storage. A PUF uses unique silicon variations inherent in each Intel^® Stratix^® 10 device as a fingerprint that can be used to derive a secret key, called the PUF root key. The PUF root key wraps the AES root key. QSPI flash stores this wrapped key.

The PUF root key is undiscoverable outside of an Intel^® Stratix^® 10 device. The process to create the PUF root key, called enrollment, generates a helper data file that is subsequently used in the reconstruction of the root key at each power on. The reconstruction process is called activation. The SDM automatically activates the PUF whenever you power cycle your system if helper data is stored in the QSPI flash device. On its own, you cannot use the helper data to regenerate the PUF root key or unwrap the AES key. To regenerate the PUF root key, both PUF and the helper data are required.

Implementing a PUF-wrapped AES Key includes the following steps:

Enrolling the Intrinsic ID PUF via JTAG.
Wrapping the AES key.
Generating flash programming files.
Programming the helper data into quad SPI flash memory.
Query the Intrinsic ID PUF activation status.

The use of Intrinsic ID technology requires a separate license agreement with Intrinsic ID. Intel^® Quartus^® Prime Pro Edition software restricts PUF operations, including enrollment and key wrapping, without the appropriate license.

4.2.1. Step 1: Enrolling the Intrinsic ID PUF via JTAG

You perform PUF enrollment to derive the PUF root key and to generate the PUF helper data (.puf) file. You must follow several restrictions intended to help prevent the characterization of the PUF through repeated enrollment attempts. Prior to performing PUF enrollment, you must program the owner root key hash into physical eFuses.

The SDM refuses PUF enrollment commands until the owner root key is programmed into physical eFuses. To enroll the PUF, you must use the JTAG interface and the Intel^® Quartus^® Prime Programmer, which automatically loads the provision firmware. The provision firmware must be the first firmware loaded after a power cycle, and you must issue the PUF enrollment command before any other command. The provision firmware supports other commands after PUF enrollment, including PUF wrapping and programming quad SPI, however, you must power cycle the device in order to load a configuration bitstream.

If you believe that the helper data in flash memory is corrupt, you can recreate new helper data by running the enrollment again. New helper data is different from any other helper data. New helper data cannot unwrap a wrapped AES root key that was wrapped with different helper data. It is possible to wrap many AES root keys with one PUF enrollment. PUF helper data files and wrapped key files are unique for each device. Wrapped key files are unique for each PUF enrollment. You must keep your .puf and .wkey files in sync with each other and with each of your devices.

Figure 20. Intrinsic ID PUF Enrollment

Use the Intel^® Quartus^® Prime Programmer to trigger PUF enrollment and generate the .puf. The Programmer automatically loads a provision firmware helper image when both the i operation and a .puf file argument are specified.

quartus_pgm -c 1 -m jtag -o “ei;wrapper.puf;1SX280LH2”

If you are using co-signed firmware, you must create a provision helper image and program that helper image prior to enrolling the PUF. Follow a similar procedure in Powering On In JTAG Mode After Implementing Co-Signed Firmware.

quartus_pfg --helper_image -o helper_device=1SX280LH2 -o subtype=PROVISION\
-o fw_source=signed_Stratix10.zip signed_provision_helper_image.rbf
quartus_pgm -c 1 -m jtag -o “p;signed_provision_helper_image.rbf”
quartus_pgm -c 1 -m jtag -o "e;wrapper.puf"

4.2.2. Step 2: Wrapping the AES Key

You generate the IID PUF wrapped AES root key (.wkey) file by sending a signed certificate to the SDM.

You can use the Intel^® Quartus^® Prime Programmer to automatically generate, sign, and send the certificate to wrap your AES root key, or you may use the Intel^® Quartus^® Prime Programming File Generator to generate an unsigned certificate. You sign the unsigned certificate using your own tools or the Quartus signing tool. You then use the Programmer to send the signed certificate and wrap your AES root key. The signed certificate may be used to program all devices that can validate the signature chain.

Figure 21. Wrapping the AES Key Using the Intel^® Quartus^® Prime Programmer

You may generate the IID PUF wrapped AES root key (.wkey) with the Programmer using the following arguments:
- The .qky file containing a signature chain with AES root key certificate permission
- The private .pem file for the last key in the signature chain
- The .qek file holding the AES root key
- The 16-byte initialization vector (iv)
```
quartus_pgm -c 1 -m jtag --qky_file=aes0_sign_chain.qky --pem_file=aes0_sign_private.pem \
--qek_file=aes.qek --iv=1234567890ABCDEF1234567890ABCDEF -o "ei;aes.wkey;1SX280LH2"
```
You may generate an unsigned IID PUF wrapping AES root key certificate with the Programming File Generator using the following arguments:
- The correct certificate type
- The .qek file holding the AES root key
- The initialization vector (iv)
```
quartus_pfg --ccert -o ccert_type=IID_PUF_WRAPPED_AES_KEY \
-o qek_file=aes.qek --iv=1234567890ABCDEF1234567890ABCDEF unsigned_aes.ccert
```

You sign the unsigned certificate with your own signing tools or the quartus_sign tool using the following command:

quartus_sign --family=stratix10 --operation=sign --qky=aes0_sign_chain.qky \
--pem=aes0_sign_private.pem unsigned_aes.ccert signed_aes.ccert

You then use the Programmer to send the signed AES certificate and return the wrapped key (.wkey) file:
```
quarts_pgm -c 1 -m jtag --ccert_file=signed_aes.ccert -o "ei;aes.wkey;1SX280LH2"
```
Note: The i operation is not necessary if you previously loaded the provision firmware helper image, for example, to enroll the PUF.

4.2.3. Step 3a: Generating Flash Programming File: Specifying Output Files

Complete the following steps to specify the output files to program to quad SPI flash memory:

On the File menu, click Programming File Generator. On the Output Files tab make the following selections:

For Device Family select Stratix 10.
For Configuration mode select Active Serial x4.
For Output directory browse to your output file directory. This example uses output_files
For Name, specify a name for the programming file to be generated. This example uses output_file.
Under Description select the programming files to generate. This example generates the JTAG Indirect configuration File (.jic) for device configuration and the Raw Binary File of Programming Helper Image (.rbf) for device helper image. This example also selects the optional Memory Map File (.map) and Raw Programming Data File (.rpd). The raw programming data file is necessary only if you plan to use a third-party programmer in the future.

Figure 22. Programming File Generator - Output Files Tab - Select JTAG Indirect Configuration

4.2.4. Step 3b: Generating Flash Programming File: Specifying Input Files

Use the Programming File Generator to specify the additional PUF-related input files to your flash image.

The following example demonstrates a single-image flash layout, using the Quartus tools to encrypt and sign the bitstream.

You must specify the Quad SPI Intrinsic ID PUF-wrapped option for the Encryption key storage select parameter in the Assignments > Device > Device and Pin Options > Security menu prior to generating your .sof file.

Figure 23. Program Flash Memory with PUF Helper Data and Application Image

To specify your configuration bitstream, on the Input Files tab, click Add Bitstream and browse to your .sof.
To specify your PUF helper data file, click Add Raw Data. Change the Files of type drop-down menu to Quartus Physical Unclonable Function File (*.puf). Browse to your .puf file.
To specify the your wrapped AES key file, click Add Raw Data. Change the Files of type drop-down menu to Quartus Wrapped Key File (*.wkey). Browse to your .wkey file.

Figure 24. Specify Input Files for Configuration, Authentication, and Encryption
To add your private .pem file, select your .sof file and then click Properties.
1. Turn On Enable signing tool.
2. For Private key file select your .pem file.
3. Turn On Finalize encryption.
4. For Encryption key file select your .qek file.

4.2.5. Step 3c: Generating Flash Programming File: Specifying the Configuration Device

Use the Programming File Generator to specify your configuration device and generate the files you specified on the Output Files tab.

On the Configuration Device tab click Add Device and select your flash device from the list of available flash devices.
Select the configuration device you have just added and click Add Partition.
In the Edit Partition dialog box for the Input file and select your .sof from the dropdown list. You can retain the defaults or edit the other parameters in the Edit Partition dialog box.

Figure 25. Specifying your .sof Configuration Bitstream Partition
When you add the .puf and .wkey as input files, the Programming File Generator automatically creates a PUF partition in your Configuration Device. To store the .puf and .wkey in the PUF partition, select the PUF partition and click Edit. In the Edit Partition dialog box, select your .puf and .wkey files from the drop-down lists. If you remove the PUF partition, you must remove and re-add the configuration device for the Programming File Generator to create another PUF partition.

Figure 26. Add the .puf and .wkey files to the PUF Partition
For the Flash Loader parameter select the Intel^® Stratix^® 10 device family and device name that matches your Intel^® Stratix^® 10 OPN.
Click Generate to generate the output files that you specified on the Output Files tab.
The Programming File Generator reads your .qek file and prompts you for your passphrase if you generated your AES key with a passphrase. Type your passphrase in response to the Enter QEK passphrase prompt. Click the Enter key.

Note: As you type your passphrase, you do not see any indication that you are typing characters.
Click OK when the Programming File Generator reports successful generation.

4.2.6. Step 4a: Programming the PUF-Wrapped Key to Quad SPI Flash

Use the Programmer to write your .jic to quad SPI flash memory.

On the Intel^® Quartus^® Prime Tools menu select Programmer.
In the Programmer, click Hardware Setup and then select a connected Intel^® FPGA Download Cable.
Click Add File and browse to your .jic file.

Figure 27. Program .jic
Unselect the box associated with the Helper image.
Select Program/Configure for the .jic output file.
Turn on Start button to program your quad SPI flash memory.
Power cycle your board. The design programmed to the quad SPI flash memory device subsequently loads into the target FPGA.

4.2.7. Step 4b: Accessing PUF Files in a PUF Partition

You must generate and program an entire flash programming image to add a PUF partition to the quad SPI flash.

When a PUF partition already exists in the flash, it is possible to use the Intel^® Quartus^® Prime Programmer to directly access the PUF helper data and wrapped key files. For example, if activation is unsuccessful, it is possible to re-enroll the PUF, re-wrap the AES key, and subsequently only program the PUF files without having to overwrite the entire flash.

The Intel^® Quartus^® Prime Programmer supports the following operation argument for PUF files in a pre-existing PUF partition:

p: program
v: verify
r: erase
b: blank check

You must follow the same restrictions for PUF enrollment, even if a PUF partition exists.

Use the i operation argument to load the provision firmware helper image for the first operation. For example, the following command sequence will re-enroll the PUF, re-wrap the AES root key, erase the old PUF helper data and wrapped key, then program and verify the new PUF helper data and AES root key.

quartus_pgm -c 1 -m jtag -o "ei;new.puf;1SX280LH2"
quartus_pgm -c 1 -m jtag --ccert_file=signed_aes.ccert -o "e;new.wkey;1SX280LH2"
quartus_pgm -c 1 -m jtag -o "r,old.puf"
quartus_pgm -c 1 -m jtag -o "r,old.wkey"
quartus_pgm -c 1 -m jtag -o "p,new.puf"
quartus_pgm -c 1 -m jtag -o "p,new.wkey"
quartus_pgm -c 1 -m jtag -o "v,new.puf"
quartus_pgm -c 1 -m jtag -o "v,new.wkey"

4.2.8. Step 5: Querying Intrinsic ID PUF Activation Status

After you enroll the Intrinsic ID PUF, wrap an AES key, generate the flash programming files, and update the quad SPI flash, you power cycle your device to trigger PUF activation and configuration from the encrypted bitstream. The SDM reports the PUF activation status along with the configuration status. If PUF activation fails, the SDM instead reports the PUF error status. Use the quartus_pgm command to query the configuration status.

Use the following command to query the activation status:

quartus_pgm -c 1 -m jtag --status --status_type=”CONFIG”

Here is sample output from a successful activation:

Response of CONFIG_STATUS
        Device is running in user mode
        00006000  RESPONSE_CODE=OK, LENGTH=6
        00000000  STATE=IDLE
        00000000  Version
        C000000F  MSEL=JTAG, nSTATUS=1, nCONFIG=1
        80000002  CONF_DONE=0, INIT_DONE=1, CVP_DONE=0, SEU_ERROR=0, PROVISION_FW=1
        00000000  Error location
        00000000  Error details 
Response of PUF_STATUS
        00001000 RESPONSE_CODE=OK, LENGTH=1
        00000400 STATUS=PUF_ACTIVATION_SUCCESS, RELIABILITY_DIAGNOSTIC_SCORE=4

4.2.9. Enabling and Disabling the More Security Options

The Assignments > Device > Device and Pin Options > Security > More options dialog box provides additional security options. Several of these parameters address the location of the encryption key.

When you turn on any of these options, the Intel^® Quartus^® Prime Software sets a flag in the .sof that the SDM reads before configuring the Intel^® Stratix^® 10 device. These options replicate most of the functionality that you can control using eFuses. However, programming physical eFuses makes these options permanent. Setting these options in the More Security Options dialog box allows you to turn them off and on by recompiling your design.

Complete the following steps specify these additional security settings:

On the Assignments > Device > Device and Pin Options > Security menu, select More options.
In the More Security Options dialog box, turn on the options you want to disable.

Figure 28. Specifying Security eFuse Settings

4.2.10. Additional Information About Using the PUF

4.2.10.1. Location of the PUF in Flash Memory

The location of the PUF file is different for designs that support RSU and designs that do not support the RSU feature.

Table 7. Flash Sub-Partitions Layout without RSU Support
Flash Offset	Size (in bytes)	Contents	Description
0 K	256 K	Configuration Management Firmware	Firmware that runs on SDM.
256 K	256 K	Configuration Management Firmware
512 K	256 K	Configuration Management Firmware
768 K	256 K	Configuration Management Firmware
1M	32 K	PUF data copy 0	Data structure for storing PUF helper data and PUF-wrapped AES root key copy 0
1M+32 K	32 K	PUF data copy 1	Data structure for storing PUF helper data and PUF-wrapped AES root key copy 1

Table 8. Flash Sub-Partitions Layout with RSU Support
Flash Offset	Size (in bytes)	Contents	Description
0 K	256 K	Decision firmware	Firmware to identify and load the highest priority image.
256 K	256 K	Decision firmware
512 K	256 K	Decision firmware
768 K	256 K	Decision firmware
1 M	8 K + 24K Padding	Decision firmware data	Reserved for Decision firmware use.
1 M + 32 K	Variable	Factory image	A simple image that you create as a backup if all other application images fail to load. This image includes the CMF that runs on the SDM.
Next	32 K	PUF data copy 0	Data structure for storing PUF helper data and PUF-wrapped AES root key copy 0
Next +32 K	32 K	PUF data copy 1	Data structure for storing PUF helper data and PUF-wrapped AES root key copy 1
Next + 256 K	4 K	Sub-partition table copy 0	Data structure to facilitate the management of the flash storage.
Next +32 K	4 K	Sub-partition table copy 1
Next +32 K	4 K	CMF pointer block copy 0	A list of pointers to application images in order of priority. When you add an image, that image becomes the highest.
Next +32 K		CMF pointer block copy 1	A second copy of the list of pointers to application images.
Variable	Variable	Application image 1	Your first application image.
Variable	Variable	Application image 1	Your second application image.

4.3. Black Key Provisioning

AES encryption helps protect confidential information or sensitive data in a configuration bitstream. When you enable AES encryption you must protect the AES key during programming (also called provisioning) the AES key to the device. Typically, AES key provisioning occurs at a trusted facility at increased cost.

Black key provisioning creates a direct secure channel between the black key provisioning service and the Intel^® Stratix^® 10 device. The black key provisioning service executes on a trusted system that is in a secure location and requires a secure network connection back to the manufacturing facility. The secure channel ensures that the black key provisioning service can provision the AES root key and other confidential information without the exposure to an intermediate party.

Intel strongly recommends the use of black key provisioning with Intel^® Stratix^® 10 FPGAs that have a -BK OPN suffix. For more information about devices with a -BK suffix and setting up black key provisioning service, please contact your Intel sales representative or Intel support.

4.3.1. Enabling Black Key Provisioning

The black key provisioning service primarily controls the black key provisioning. The Intel^® Quartus^® Prime Programmer assists in establishing a mutually-authenticated secure connection between the Intel^® Stratix^® 10 device and the black key provisioning service. The secure connection is established via https and requires several certificates identified using a text file. The bkp_tls_ca_cert certificate authenticates your black key provisioning service instance to your black key provisioning programmer instance. The bkp_tls_* certificates authenticate your black key provisioning programmer instance to your black key provisioning service instance.

You create a text file containing the necessary information for the Intel^® Quartus^® Prime Programmer to connect to the black key provisioning service. To initiate black key provisioning, use the Programmer command line interface to specify the black key provisioning options text file. The black key provisioning then proceeds automatically.

You can enable the black key provisioning using the quartus_pgm command:

quartus_pgm -c <cable> -m <programming_mode> --device <device_index> --bkp_options=bkp_options.txt

The command arguments specify the following information:

-c: cable number
-m: specifies the programming mode such as JTAG
--device: specifies a device index on the JTAG chain. Default value is 1.
--bkp_options: specifies a text file containing black key provisioning options.

4.3.2. Black Key Provisioning Options

The black key provisioning options is a text file passed to the Programmer through the quartus_pgm command. The file contains required information to trigger black key provisioning.

Example of bkp_options.txt file.

bkp_cfg_id = 1
bkp_ip = 192.167.1.1
bkp_port = 10034
bkp_tls_ca_cert = root.cert
bkp_tls_prog_cert = prog.cert
bkp_tls_prog_key = prog_key.perm
bkp_tls_prog_key_pass = 1234
bkp_proxy_address = https://192.167.5.5:5000
bkp_proxy_user = proxy_user
bkp_proxy_password = proxy_password

Table 9. Black Key Provisioning OptionsThis table displays the options required to trigger black key provisioning.
Option Name	Type	Description
`bkp_ip`	Required	Specifies the server IP address running the black key provisioning service.
`bkp_port`	Required	Specifies black key provisioning service port required to connect to the server.
`bkp_cfg_id`	Required	Identifies the black key provisioning configuration flow ID. Black key provisioning service creates the black key provisioning configuration flows including an AES root key, desired eFuse settings, and other black key provisioning authorization options. The number assigned during the black key provisioning service setup identifies the black key provisioning configuration flows. Note: Multiple devices may refer to the same black key provisioning service configuration flow.
`bkp_tls_ca_cert`	Required	The root TLS certificate used to identify the black key provisioning services to the Intel^® Quartus^® Prime Programmer (Programmer). A trusted Certificate Authority for the black key provisioning service instance issues this certificate. If you run the Programmer on a computer with Microsoft^® Windows^® operating system (Windows), you must install this certificate in the Windows certificate store.
`bkp_tls_prog_cert`	Required	A certificate created for the instance of the black key provisioning Programmer (BKP Programmer). This is the https client certificate used to identify this BKP programmer instance to the black key provisioning service. You must install and authorize this certificate in the black key provisioning service prior to initiating a black key provisioning session. If you run the Programmer on Windows, this option is not available. In this case, the `bkp_tls_prog_key` already includes this certificate.
`bkp_tls_prog_key`	Required	The private key corresponding to the BKP Programmer certificate. The key validates the identity of the BKP Programmer instance to black key provisioning service. If you run the Programmer on Windows, the .pfx file combines the `bkp_tls_prog_cert` certificate and the private key. The `bkp_tlx_prog_key` option passes the .pfx file in the `bkp_options.txt` file.
`bkp_tls_prog_key_pass`	Optional	The password for the `bkp_tls_prog_key` private key. Not required in the black key provisioning configuration options (`bkp_options.txt`) text file.
`bkp_proxy_address`	Optional	Specifies the proxy server URL address.
`bkp_proxy_user`	Optional	Specifies the proxy server user name.
`bkp_proxy_password`	Optional	Specifies the proxy authentication password.

4.4. Partial Reconfiguration Bitstream Encryption

Partial reconfiguration (PR) is an Intel FPGA feature that allows you to dynamically reconfigure a portion of the FPGA design, while the remaining FPGA design continues to function.

Starting with Intel^® Quartus^® Prime Pro Edition software version 20.4, you can enable bitstream encryption on some Intel^® Stratix^® 10 FPGA designs that use partial reconfiguration.

Partial reconfiguration designs utilizing the Hierarchical Partial Reconfiguration (HPR) or Static Update Partial Reconfiguration (SUPR) do not support the bitstream encryption. You must use the same encryption key to encrypt the static region and all personas. If your design contains multiple PR regions, you must encrypt all personas. To enable partial reconfiguration bitstream encryption, follow the same procedure in all design revisions.

4.4.1. Enabling Partial Reconfiguration Bitstream Encryption

You enable partial reconfiguration bitstream encryption by selecting Assignments > Device > Device and Pin Options > Security menu. Select the desired encryption key storage location.

Figure 29. Security Tab: Enabling Partial Reconfiguration Bitstream Encryption

After you compile your base design and revisions, the software generates a .sof file and one or more .pmsf files, representing the personas. You create encrypted and signed programming files from .sof and .pmsf files in a similar fashion to designs with no partial reconfiguration enabled.

4.4.2. Generating Encrypted Partial Reconfiguration Persona Programming Files Using the Command Line Interface

Use the following command to convert all compiled persona .pmsf files to encrypted and signed programming files:

quartus_pfg -c encryption_enabled_persona1.pmsf encrypted_signed_persona1.rbf \
-o finalize_encryption=ON -o qek_file=aes.qek -o signing=ON \
-o pem_file=design0_sign_private.pem

4.4.3. Generating Partially Encrypted Partial Reconfiguration Persona Programming Files Using the Command Line Interface

You may generate a partially encrypted programming file in order to finalize the encryption and sign the programming file at a later time.

Use the following command to convert the compiled persona .pmsf file to a partially encrypted .rbf file:

quartus_pfg -c -o finalize_encryption_later=ON \
-o sign_later=ON encryption_enabled_persona1.pmsf persona1.rbf

Use command in Encrypt the Bitstream to finalize encryption. Then, you must sign the programming file using instructions in Step 4b: Signing the Bitstream Using the quartus_sign Command.

4.5. Encryption Command Detailed Description

The encryption command supports the following functions:

Making an AES key
Encrypting the configuration bitstream

Table 10. Signing Command Argument Summary
Argument	Options	Description
`operation`	`make_aes_key`	Generates an .qek file. Takes 6 optional arguments.
	`encrypt`	Completes the encryption process. When you enable encryption, the Bitstream Assembler always generates a partially-encrypted owner configuration bitstream (.rbf) from the .sof input file.

4.5.1. Make AES Key

You can use the six optional arguments to the quartus_encrypt command to customize encryption.

Command	quartus_encrypt --family=stratix10 --operation=make_aes_key <output .qek>
Input file	None
Output file	.qek
Arguments	This command includes the following 6 optionals arguments: `ik_count`: Specifies the number of intermediate keys to encrypt the owner configuration bitstream. The default value is 3. `max_key_use`: Specifies the maximum number of keys to use to encrypt the owner configuration bitstream. The default value is 128. The following restriction applies to the total number of encryption keys: log₂(max_key_use) * (ik_count + 1) < 64 `passphrase`: Specifies an optional file path that contains a passphrase to protect the .qek. If you do not specify this argument, the `quartus_encrypt` command prompts you to enter the `passphrase`. `base_key`: Specifies a binary file as the `base_key` to generate a root key if you do not specify an `aes_key` or key derivation key. If you do not specify a `base_key`, `quartus_encrypt` uses random data. `aes_key`: Specifies an AES key in hexadecimal words. If you do not specify an `aes_key`, the `quartus_encrypt` command derives the `aes_key` from the `base_key`.

4.5.2. Encrypt the Bitstream

You enable encryption on the Security page of the Assignments > Device > Device and Pin Options > Security tab. When you enable encryption, the Bitstream Assembler always generates a partially-encrypted owner configuration bitstream. A partially encrypted configuration bitstream has no intermediate keys. The section key is in plaintext. The encryption finalization step creates intermediate keys and replaces the plaintext section key with an encrypted version. The quartus_encrypt command completes the encryption process.

Command	quartus_encrypt --family=stratix10 --operation=encrypt --Key=<output .qek> \ <partially-encrypted .rbf> <fully encrypted .rbf>
Input file	Partially encrypted .rbf file.
Output file	Fully encrypted .rbf file.
Arguments	This command includes the following 2 required arguments: `key`: Specifies a .qek file. `passphrase`: Specifies an optional file path that a contains passphrase to protect the .qek. If you do not specify this argument, the `quartus_encrypt` command prompts you to enter the `passphrase`.

4.6. Encryption Tool (with Source Code)

Intel provides a reference implementation of the Intel^® Stratix^® 10 bitstream encryption tool with Intel^® Quartus^® Prime Pro Edition software, including source code. You may use this implementation to encrypt bitstreams, extend to integrate with a Hardware Security Module (HSM) of your choice, or use it as a reference for your bitstream encryption tool.

The reference implementation file is stratix10_encrypt.py and is available in the <install_dir>/quartus/common/devinfo/programmer/python directory.

5. Using eFuses

Intel^® Stratix^® 10 devices use eFuses to permanently store device and security information. Owner eFuse fields are quadruple-redundant. The Intel^® Quartus^® Prime Programmer programs eFuses using a JTAG interface. eFuse programming is an irreversible process in which electrical current passes through a small chip feature until the feature is destroyed.

Accessing the Virtual eFuses

The SDM maintains a virtual eFuse cache in volatile RAM. The virtual eFuse cache stores values that represent the current state of the physical eFuses, and any writes to virtual eFuses.

The quartus_pgm command writes eFuse values to the virtual eFuse cache unless the non_volatile_key argument is specified.

You can use the Programmer to write values to the fuse cache in SDM RAM. These values persist until you remove power from the device, or reload the fuse cache using the mailbox. Some virtual eFuses, such as co-signed firmware and JTAG disable, do not become active unless firmware is reloaded. You reload firmware by programming a helper image with a different firmware such as the provision firmware, or by using a different version of the Programmer. Because programming incorrect values into real eFuses renders the device unusable, Intel recommends that you test eFuse programming using virtual eFuses before programming the first Intel^® Stratix^® 10 device with real eFuses. Intel^® Stratix^® 10 devices restrict programming of physical eFuses immediately after programming of virtual eFuses. If you programmed virtual eFuses, you must power cycle a device prior to programming physical eFuses.

Important: Virtual eFuses are intended only for use in development or test environments. Do not rely on virtual eFuses to provide security or keys protection in a production environment.

The following table describes all available owner eFuses.

Table 11. Owner Programmable eFuses
eFuse Name	Legal Values	Description
Intel^® FPGA public key hash	384-bit hex	Read-only.
Intel^® FPGA public key cancellation	32-bit hex	32 Intel cancellation IDs are available. Each bit corresponds to the cancellation ID.
Co-signed firmware	1-bit boolean	When you program this fuse, both you and Intel must sign the device firmware. Intel signs the device firmware with the root public key during the manufacturing process.
Device not secure	1-bit boolean	If you receive a device and this fuse is programmed do not use the device and contact Intel.
Owner encryption key program done	1-bit boolean	The Programmer programs the owner AES key into eFuses.
Owner encryption key program start	1-bit boolean	The Programmer programs the owner AES key into eFuses.
Owner key cancellation	32-bit hex	0-31. The Intel^® Stratix^® 10 device has 4 redundant cancellation bits of with each fuse. The Programmer programs all 4 copies when you cancel the corresponding fuse.
Owner root public key hash	384-bit hex	Stores the hash value of the owner root public key.
Owner public key size	[0, 256, 384]	Specifies owner public key size. Intel recommends using 384-bit keys if possible.
JTAG disable	1-bit boolean	When set, disables JTAG command and configuration. Setting this eFuse eliminates JTAG as mode of attack.
Force SDM clock to Internal Oscillator	1-bit boolean	When set, disables an external clock source for the SDM for bitstream configuration. Forcing the SDM to use an internal oscillator helps to limit potential interruptions or attacks by modifying an external clock during configuration.
Force encryption key update	1-bit boolean	When set, all encrypted bitstreams must specify the Encryption Update Ratio on the Intel^® Quartus^® Prime Assignments > Device and Pin Options > Security menu.
Disable virtual eFuses	1-bit boolean	When set, disables the eFuse virtual programming capability.
Lock security eFuses	1-bit boolean	Programming this fuse prevents the future programming of any owner-accessible security policy fuses, not including key cancellation ID fuses.
Disable HPS debug	1-bit boolean	When set, permanently disables debugging using JTAG to access the HPS.
Disable encryption key in eFuses	1-bit boolean	When set, the device does not use an AES key stored in eFuses.
Disable encryption key in BBRAM	1-bit boolean	When set, the device does not use AES key stored in BBRAM.
Disable PUF-wrapped encryption key	1-bit boolean	When set, the device does not use a PUF-wrapped AES key.
Disable Intrinsic ID PUF enrollment	1-bit boolean	When set, Intrinsic ID PUF re-enrollment fails. Disabling re-enrollment prevents further usage of the PUF in this device if the helper data is corrupted for any reason.

Simulating the Public Key Hash Virtual eFuses

Because eFuses are non-volatile, Intel recommends validating eFuse programming before programming physical eFuses on the Intel^® Stratix^® 10 device.

This example provides the steps to validate the public key hash. First, you program the public key hash value into in virtual eFuses. Then, you compare that value to the value that the Examine function stores in hash_fuse.txt:

Turn on Enable device security using a volatile security key in the Intel^® Quartus^® Prime Programmer. When you select this option the Intel^® Quartus^® Prime Pro Edition stores the eFuse values in firmware registers.
In the Intel^® Quartus^® Prime Programmer click Add File and browse to your signed bitstream.
In the Intel^® Quartus^® Prime Programmer turn on the Program/Configure and Examine options.
Click Start.
After programming completes, the Programmer displays the hash value of the signature key stored in firmware. You can now compare that value to the value you generate by creating a hash_fuse.txt file using the quartus_sign command with the operation set to fuse_info.

5.1. Fuse Programming Input Files

The Intel^® Quartus^® Prime Programmer supports the following three input file types for fuse programming. Intel^® Quartus^® Prime key file (.qky), the Intel^® Quartus^® Prime encryption key (.qek), and the .fuse file.

The files provide the following information to the Intel^® Quartus^® Prime Programmer:

.qky: Provides the owner public root key for authentication and the second-level key for firmware authentication. Use this file for the following functions:
- To program and verify the public root key fuses
- To sign the owner configuration bitstream
- To sign the device firmware
- To sign the HPS debug certificate
.qek: Provides the AES key for encryption. Use this file for the following functions:
- To program the AES key fuses
- To encrypt the owner configuration bitstream
.fuse: Specifies all owner fuses. Also includes the public root key which is read-only. Use this file for the following functions:
- To program and verify security fuses
- To program owner-defined fuses

5.2. Understanding Fuse File Format

The .fuse file contains a list of fuse name-value pairs. The value specifies whether the fuse has been programmed (blown) and its cancellation ID.

The following example shows the format of the .fuse file.

# Comment
<fuse name> = <value>
<fuse name> = <value>
<fuse name> = <value>

You can use the Intel^® Quartus^® Prime Programmer Examine option to read all currently programmed fuses in the Intel^® Stratix^® 10 device and store this information in a .fuse file. In general, a fuse with a value of 0x0 is not programmed. A fuse with the value of 0xF is programmed.

5.3. Programming eFuses

You can program eFuses to enable or disable device security features, improving the security of your design. Before programming eFuses you must check the current state of eFuse programming for your device. This procedure ensures that you add the new eFuse commands to the existing eFuse programming commands, if any.

Generate the current device fuse status file, programming_file.fuse.

quartus_pgm -c 1 -m jtag -o “ei;programming_file.fuse;1SX280LH2”

Edit programming_file.fuse to add the required eFuses. There are four copies of eFuses. Programming changes all 4 copies from 0 to 1. Add the following command to programming_file.fuse.
```
<fuse_name> = "0xF"
```

Program the eFuses:

//For physical (non-volatile) eFuses
quartus_pgm -c 1 -m jtag -o "pi;programming_file.fuse" --non_volatile_key

//For virtual (volatile) eFuses
quartus_pgm -c 1 -m jtag -o "pi;programming_file.fuse"

5.4. Key Cancellation eFuses

Intel^® Stratix^® 10 devices maintain two sets of key cancellation fuses; one for owner key cancellation IDs and one for Intel key cancellation IDs. You are responsible for managing the owner key cancellation IDs with your product life cycle.

Intel may cancel an Intel ID as needed with new versions of firmware. For information on the current Intel cancellation ID, refer to Canceling Intel Firmware ID. Intel cancellation ID fuses corresponding to a given firmware are programmed automatically when the owner root key hash is programmed. You are responsible for updating the device firmware and Intel key cancellation IDs. Intel recommends updating device programming files to use the latest firmware and programming the canceled IDs into eFuses.

To update the key cancellation fields, you use the Intel^® Quartus^® Prime Programmer to examine the fuse information, modify the fuse settings, and use the Programmer to program the new fuse settings.

Follow these steps to cancel eFuses that specify SDM firmware versions that are no longer valid.

Extract the existing fuse information by running the following command-line command:

quartus_pgm -c 1 -m jtag -o "ie;my_fuse.fuse;1SX280LH2"

This command generates a my_fuse.fuse text file.

Sample contents of my_fuse.fuse:

# Co-signed firmware                   = "0xF"
# Device not secure                    = "0x0"
# Intel key cancellation               = ""
# Owner fuses                          = "0x00000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000"
# Owner key cancellation               = ""
# Owner public key hash                = "0x000000000000000000000000000000000CE520B15B082E67ACEBCB8545CE239FDBB8CDE6083F6DF9D3BF542932EA5039"
# Owner public key size                = "0xF"
# QSPI start up delay                  = "0x0"
# SDMIO0 is I2C                        = "0x0"

Using a text editor, update my_fuse.fuse to specify the keys to cancel. Change:
```
#Intel key cancellation               = ""
```
to:
```
Intel key cancellation               = "0,1,2,3,4"
```
Note: Be sure to remove the initial #.

Run the following command to program the cancellation ID eFuses:

//For physical (non-volatile) eFuses
quartus_pgm -c 1 -m jtag -o "p;my_fuse.fuse" --non_volatile_key

//For virtual (volatile) eFuses
quartus_pgm -c 1 -m jtag -o "p;my_fuse.fuse"

5.5. Security Option eFuses

Security option eFuses permanently restrict certain features of Intel^® Stratix^® 10 FPGAs. Some security eFuses do not take effect immediately. The individual fuses description indicates when you need to power cycle or reconfigure the device.

The table below specifies special considerations for enabling security option eFuses.

Table 12. Security Option eFuses
Security Option eFuse	eFuse Consideration
Co-signed firmware	Firmware evaluates the owner co-signature over firmware on the next firmware load, or by the SDM boot ROM on subsequent power cycles. Existing configuration files, including RSU boot images, that were not built with co-signed firmware will fail to authenticate.
JTAG disable	Takes effect immediately. This option precludes further use of the provisioning software. If you wish to use both the JTAG disable and the Lock security eFuses security option eFuses, you must program both fuses in the same operation.
Force SDM clock to Internal Oscillator	Takes effect on subsequent reconfiguration.
Force encryption key update	Takes effect on subsequent reconfiguration.
Disable virtual eFuses	Takes effect immediately.
Lock security eFuses	For Intel^® Quartus^® Prime Pro Edition software version 20.3 and earlier, contact Intel Support prior to enabling this fuse. For Intel^® Quartus^® Prime Pro Edition software version 20.4, programming this fuse takes effect immediately. The eFuse is validated on subsequent power cycles. If you wish to use both the JTAG disable and the Lock security eFuses security option eFuses, you must program both fuses in the same operation.
Disable HPS debug	Takes effect immediately.
Disable encryption key in eFuses	Takes effect on subsequent reconfiguration.
Disable encryption key in BBRAM	Takes effect on subsequent reconfiguration.
Disable PUF-wrapped encryption key	Takes effect on subsequent reconfiguration.
Disable Intrinsic ID PUF enrollment	Takes effect immediately.

5.6. Converting Key, Encryption, and Fuse Files to the Jam Staple File Formats

You can use the quartus_pfg command-line command to convert .qky, .qek, and .fuse files to Jam* STAPL Format File (.jam) and Jam Byte Code File (.jbc). You can use these files to program Intel FPGAs using the Jam STAPL Player and the Jam STAPL Byte-Code Player, respectively.

A single .jam or .jbc contains several functions including a firmware helper image and program, blank check, and verification of key and fuse programming.

CAUTION:

When you convert the AES .qek file to .jam format, the .jam file contains the AES key in plaintext but obfuscated form. Consequently, you must protect the .jam file when storing the AES key. You can do this by provisioning the AES key in a secure environment.

quartus_pfg Conversion Commands

Here are examples of quartus_pfg conversion commands:

quartus_pfg -c -o helper_device=1SX280LH2 root.qky RootKey.jam 
quartus_pfg -c -o helper_device=1SX280LH2 root.qky RootKey.jbc
quartus_pfg -c -o helper_device=1SX280LH2 nd.qek nd_qek.jam 
quartus_pfg -c -o helper_device=1SX280LH2 nd.qek nd_qek.jbc
quartus_pfg -c -o helper_device=1SX280LH2 cancel_id.fuse nd_fuse.jam 
quartus_pfg -c -o helper_device=1SX280LH2 cancel_id.fuse nd_fuse.jbc

For more information about the using the Jam STAPL Player for device programming refer to AN 425: Using the Command-Line Jam STAPL Solution for Device Programming.

Using the .jam Files to Program Root Key and AES Encryption Key

Run the following commands to program the owner root public key and AES encryption key:

// To load the helper bitstream into the FPGA.
// The helper bitstream include SDM firmware
quartus_jli -c 1 -a CONFIGURE RootKey.jam

// To program the owner root public key into virtual eFuses
quartus_jli -c 1 -a PUBKEY_PROGRAM RootKey.jam

//To program the owner root public key into physical eFuses
quartus_jli -c 1 -a PUBKEY_PROGRAM -e DO_UNI_ACT_DO_EFUSES_FLAG RootKey.jam

// To program the AES Encryption key into BBRAM
quartus_jli -c 1 -a AESKEY_PROGRAM -e DO_UNI_ACT_DO_BBRAM_FLAG EncKey.jam

6. Additional Security Features

6.1. JTAG Disable

The Disable JTAG on the Assignments > Device > Device and Pin Options > Security > More Options page disables JTAG communication with the SDM. When you set this option, the device does not respond to JTAG commands or configure via JTAG.

This setting does not affect mandatory JTAG instructions such as boundary-scan and reading the ID code. You can reinforce this option by programming the Disable JTAG eFuse.

CAUTION:

Programming the Disable JTAG eFuse permanently disables communication between the SDM and JTAG.

6.2. Using an HPS Debug Certificate

For Intel^® Stratix^® 10 SX devices, you can require an HPS debug certificate before permitting access to the JTAG interface for HPS debugging. An HPS debug certificate is a one-time certificate that is valid until you power down the SDM. A firmware reload may also invalidate the HPS debug certificate. Restarting the HPS does not invalidate the HPS debug certificate.

Signing a configuration bitstream with the HPS debug access port (DAP) available without a debug certificate enables that configuration bitstream to load unauthenticated software to the HPS. In response, the Intel^® Quartus^® Prime Pro Edition Software generates critical warnings. Intel recommends careful consideration before using this option. Intel strongly recommends restricting such a bitstream from release and canceling the signing key ID after this configuration bitstream is no longer needed.

Note: You can debug the HPS without a certificate by turning on the Allow HPS debug without certificate on the Assignments > Device > Device and Pin Options > Configuration menu.

Using an HPS debug certificate includes the following steps:

Requesting the certificate from a configured device.
Signing the certificate using a keychain with HPS debug permissions.
Programming the signed certificate back into the device.

You can create an HPS debug certificate when the following conditions are true:

You have selected either HPS or SDM pins to access the HPS.
Figure 30. Specify Either HPS or SDM Pins for the HPS DAP
You have not disabled the HPS DAP.
You have programmed the FPGA with an owner root key. Refer to Step 5: Programming the Owner Public Root Key for Authenticationfor more information.
You have programmed the device with a signed bitstream with the HPS and FSBL permission set to true. (permission=4 for HPS and FSBL)
You have not permanently disabled JTAG on the device by programming the JTAG disable eFuse. For more information about the available eFuses refer to the Owner Programmable eFuses table in the Using eFuses topic.
You have not permanently disabled HPS debugging on the device by programming the HPS debug disable eFuse. For more information about the available eFuses refer to the Owner Programmable eFuses table in the Using eFuses topic.
You have not programmed the FPGA with a design that disables HPS debug. HPS debug certificates do not override the setting to disable HPS debug for a given bitstream.

6.3. Enabling HPS JTAG Debugging

Use this procedure to enable HPS JTAG debugging after configuring the Intel^® Stratix^® 10 SX device with a signed bitstream.

You should already have created a first-level signature chain by completing the instructions in the following topics:

Step 2: Creating the Design Signing Key.
Step 3: Appending the Design Signature Key to the Signature Chain. Be sure to specify permission=8 for the HPS debug certificate.

Completing these commands results in <debug_cert_sign_chain.qky> and <design0_sign_private.pem> files that are inputs the quartus_sign command the creates the signed HPS debug certificate.

To create the HPS debug certificate, you must provide a <device> argument to the quartus_pgm command. Use the Intel^® Quartus^® Prime Programmer Device name list to determine the proper <device> argument by completing the following steps:
1. Find the list of Intel^® Stratix^® 10 devices, in the Intel^® Quartus^® Prime Programmer, by select Add Device.
2. In the Device family list, select Intel^® Stratix^® 10 . In the Device name list, find the part number that matches your device.
  
  Figure 31. Using the Programmer to Determine the helper_device Argument
Generate an unsigned secure HPS debug certificate from the programmed device. The <device> argument is the Device name you identified in the previous step.
```
quartus_pgm -c 1 -m jtag -o “ei;unsigned_hps_debug.cert;<device>”
```

Sign the HPS debug certificate using the quartus_sign command:

quartus_sign --family=stratix10 --operation=sign \ 
--qky=debug_cert_sign_chain.qky --pem=design0_sign_private.pem \ 
unsigned_hps_debug.cert signed_hps_debug.cert

Send the signed HPS debug certificate to the device to enable HPS debugging.
```
quartus_pgm -c 1 -m jtag -o “p;signed_hps_debug.cert"
```

6.4. Using Design Security Features with Remote System Update

Remote System Update (RSU) is an Intel^® Stratix^® 10 FPGAs feature that assists in updating configuration files in a robust way. RSU is compatible with design security features such as authentication, firmware, co-signing, and bitstream encryption as RSU does not depend on the design contents of configuration bitstreams.

In order to use design security features with RSU images, you follow the instructions in Section 5.5 Generating Remote System Update Image Files Using the Programming File Generator of the Intel^® Stratix^® 10 Configuration User Guide to generate RSU images with .sof file inputs. For every .sof file specified on the Input Files tab, you click the Properties... button and specify the appropriate settings and keys for the signing and encryption tools. The programming file generator tool automatically signs and encrypts factory and application images while creating the RSU programming files.

Future release of Intel^® Quartus^® Prime Pro Edition software plans to support the RSU file generation using already encrypted .rbf files or signed .rbf files.

7. Intel Stratix 10 Device Security User Guide Archives

Intel^® Quartus^® Prime Version	User Guide
20.3	Intel^® Stratix^® 10 Device Security User Guide Archive
20.1	Intel^® Stratix^® 10 Device Security User Guide Archive
19.3	Intel^® Stratix^® 10 Device Security User Guide Archive
19.1	Intel^® Stratix^® 10 Device Security User Guide Archive

8. Document Revision History for Intel Stratix 10 Device Security User Guide

Document Version	Intel^® Quartus^® Prime Version	Changes
2021.02.17	20.4	Made the following changes: Revised Encryption section in the Intel^® Stratix^® 10 Device Security Overview topic. Added text stating that devices with advanced security enabled can only load a secured firmware. Removed Partial Reconfiguration Bitstream Encryption (PRBE) topic from the Planned Security Features section. Intel^® Quartus^® Prime software version 20.4 supports PRBE feature. Updated key permission content in the Signature Block section. Added permission bit used to sign black key provisioning. Added firmware ID=8 along with its firmware release in the Intel Firmware IDs table. Restructured content in Powering On In JTAG Mode After Implementing Co-Signed Firmware and Programing eFuses sections. Revised Step 1: Enrolling the Intrinsic ID PUF via JTAG. Revised PUF enrollment text to emphasize that the Intel^® Quartus^® Prime Pro Edition Programmer automatically loads the provision firmware. Added note suggesting to toggle the `nCONFIG` signal in order to perform a successful reconfiguration. Updated text to emphasize that Intel^® Quartus^® Prime Programmer restricts PUF operations without the appropriate license. Revised Black Key Provisioning section. Added recommendation to use -BK OPN suffix for devices using black key provisioning features. Updated Partial Reconfiguration Bitstream Encryption topic. Added new sections: Enabling Partial Reconfiguration Bitstream Encryption Generating Encrypted Partial Reconfiguration Persona Programming Files Using the Command Line Interface Generating Partially Encrypted Partial Reconfiguration Partial Reconfiguration Persona Programming Files Using the Command Line Interface Revised Using eFuses topic. Clarified restriction of programming physical eFuses after virtual eFuses. Added new topics: Signing Tool (with Source Code) Encryption Tool (with Source Code) Security Option eFuses Using Design Security Features with Remote System Update Corrected minor errors and typos.
2020.10.13	20.3	Made the following changes: Revised Important Notice to Customers Regarding Features Added in Intel^® Quartus^® Prime Pro Edition Software Version 20.3 notice. The IID PUF-based AES key storage feature is a production feature. The anti-tamper features were removed in this release. Added limitation for Intel^® Stratix^® 10 GX 10M devices in the Intel^® Stratix^® 10 Device Security Overview: Encryption section. The Intel^® Stratix^® 10 GX 10 devices don't support the advanced security features. Updated the Owner Security Keys and Storage Options section: Revised virtual eFuses, physical eFuses, and BBRAM typical applications in the Comparison of AES Key Storage Options table. Revised Black Key Provisioning description in the Owner AES Key section. Removed Owner AES Key Programming section. The content is already available in the Encryption and Decryption chapter. Updated the Planned Security Features section: Added the Anti-Tampering topic. Added the Partial Reconfiguration Bitstream Encryption topic. Removed the Black Key Provisioning topic. Updated the Signature Chain Content table: Added bit 6: AES root key certificate in the Public Key Entry description. Revised Header Block Entry description. Updated the Canceling Intel Firmware ID section: Added firmware ID=7 along with its firmware release in the Intel Firmware IDs table. Revised and added steps to prevent using older firmware versions once you upgraded to a new firmware version. Corrected argument value for signing firmware in the Append Key to Signature Chain section. The value to sign firmware is 1, not 0. Added assignment to specify the owner cancellation ID in the Step 4a: Signing the Bitstream Using the Programming File Generator section. Revised note in the Using the Co-Signed Feature section. The text points to the Using eFuses section for information on programming the co-signed eFuses. Revised the Prerequisites for Co-Signing Device Firmware section: Rename argument from `--key_storage` to `--non_volatile_key`. Updated the `quartus_pgm` commands. Updated the instruction links. Added new topic: Step 2c: Generating Partially Encrypted Programming File Using the Command Line Interface. Added Quad SPI Intrinsic ID PUF-wrapped option in the Step 3a: Specifying Keys and Configuring the Encrypted Image Using the Intel^® Quartus^® Prime Programmer. Updated description of `-i` option and added a note in the Step 3b: Programming the AES Key and Configuring the Encrypted Image Using the Command Line section. The note states that you can program the co-signed helper image prior to programming the .qek encryption key. Removed Anti-Tamper Monitoring and Mitigation section and all related anti-tamper content. Removed (Beta) label from all IID PUF-based AES key storage content. In this release, IID PUF is a production feature. Revised all PUF-related content. Added support for black key provisioning and new sections describing enabling black key provisioning, including the `bkp_options` description. Revised Using eFuses and Key Cancellation eFuses topics. Added statement to emphasize the usage of virtual eFuses. The virtual eFuses are meant for testing purposed only. They don't guarantee security in the production environment. Revised the Using an HPS Debug Certificate topic. Revised text to emphasize the debug certificate usage in order to ensure the bitstream security: Intel strongly recommends restricting such a bitstream from release and canceling the signing key ID after this configuration bitstream is no longer needed. Revised the required conditions to create HPS debug certificate. Updated JTAG related condition to emphasize that the JTAG disable fuse disables JTAG. Added new condition to emphasize that the HPS debug disable fuse permanently disables the HPS debugging. Updated Enabling HPS JTAG Debugging topic. Corrected the statement on the `permission` usage. You should specify `permission=8` for the HPS debug certificate. Renamed a key file from `<design0_sign_chain.qky>` to `<debug_cert_sign_chain.qky>`. Updated .puf file description in the File Types for Security appendix. Added new `quartus_pgm` command arguments in the quartus_pgm Command Operation Argument appendix: `-o p;file.ccert` `-o pvbi;file.puf` `-o pvbi;file.wkey` `-o ei;file.ccert;device_name` `-o ei;file.puf;device_name` `-o ei;file.wkey;device_name` Corrected minor errors and spelling mistakes.
2020.04.13	20.1	Made the following changes: Added topic: Important Notice to Customers Regarding Features Added in Intel^® Quartus^® Prime Pro Edition Software Version 20.1. It states that the IID PUF-based AES key storage and Anti-Tamper features are a beta release in Intel^® Quartus^® Prime Pro Edition software version 20.1. Added support for a PUF-wrapped AES key. Refer to Using a PUF-Wrapped AES Key (Beta) for more information. This feature is a beta release in Intel^® Quartus^® Prime Pro Edition software version 20.1. Added support for monitors that can trigger an anti-tamper response when the temperature, voltage, or external clock frequency exceeds the values you specify. Refer to Anti-Tamper Monitoring and Mitigation (Beta) for more information. This feature is a beta release in Intel^® Quartus^® Prime Pro Edition software version 20.1. Added the Comparison of AES Key Storage Options table that describes the features of each the 4 possible storage locations. Added firmware ID=6 along with its firmware release in the Intel Firmware IDs table. Reorganized user guide. Added support for a `quartus_pfg` command that checks the integrity of a signed configuration bitstream. Refer to Verifying a Configuration Bitstream Signature for more information. Added an appendix covering acronyms and definitions of security terminology. Added an appendix describing file types that implement security features. Added an appendix showing help for the operation (-o) argument to the `quartus_pgm` command. Updated Security Category figures to show the new Permitted owner cancellation id and Anti-Tamper tab. Removed statement that the JTAG disable eFuse eliminates boundary scan. In the Intel^® Quartus^® Prime Release 20.1 release, disabling JTAG does not disable boundary scan. Corrected minor errors and spelling mistakes.
2020.01.15	19.3	Corrected the `pem_file` argument in 7.1.3. Step 2b: Generating Programming Files Using the Command Line. The correct command uses `pem_file=design0_sign_private.pem`: quartus_pfg -c encryption_enabled.sof top.rbf \ -o finalize_encryption=ON -o qek_file=aes.qek \ -o signing=ON -o pem_file=design0_sign_private.pem
2020.01.06	19.3	Made the following changes: Corrected the `quartus_encrypt` command in the Step 1: Preparing the Owner Image and AES Key Filetopic. The `ik_count` and `max_key_use` arguments must be preceded by `--`. Added command showing how to convert an .rbf to .jam format in the Step 4: Signing the Bitstream topic. Added the following note to the Converting Key, Encryption, and Fuse Files to Jam Staple File Formats topic: CAUTION: When you convert the AES .qek file to .jam format, the .jam file contains the AES key in plaintext but obfuscated form. Consequently, you must protect the .jam file when storing the AES key. You can protect the .jam file by provisioning the AES key in a secure environment. Added a link to the How can I write or erase the Intel^® Stratix^® 10 AES BBRAM encryption key using the Mailbox Client Intel^® FPGA IP interface and System Console? article in Storing the AES Key in BBRAM using the JTAG Mailbox.
2019.10.30	19.3	Added the following new security features: Added support for physical (non-volatile) eFuses. Changed the way you specify virtual (volatile) or physical (non-volatile) eFuses. The `--non_volatile_key` parameter is now an argument to the `quartus_pgm` command. Consequently, you no longer need to recompile to change the eFuse storage location. Increased the number of public keys entries supported from 2 to 3. Added support for a signed secure HPS debug certificate to prevent unauthorized remote or physical access to the HPS. Decreased the encryption update ratio from 127:1 to 31:1. Revised description the Using the Authentication Feature example. The example now specifies permission 6 to allow the key to sign both the Core (permission=2) and HPS (permission=4) sections of the configuration bitstream. You must create separate key chains to limit the permissions to either Core or HPS. Added support for 10 additional eFuses described in the Owner Programmable eFuses table. Added examples of advanced security features. Added descriptions of side-channel mitigation features. Added the following topics: Step 4a: Protecting the AES Key when Storing the AES in eFuses Step 4b: Protecting the AES Key when Storing the AES Key in BBRAM Encryption Command Detailed Description Make AES Key Encrypt the Bitstream Programming eFuses Canceling eFuses Added examples of .jam commands under the Using the .jam Files to Program Root Key and AES Encryption Key heading. Corrected AES Update Mode figure. The number of data bits in a data block is 256, not 128. Corrected the cancellation ID Numbers in Figure 5: Three-Key Signature Chain. The cancellation IDs are 0 and 1. Removed recommendation to use separate signing keys for core and HPS in Intel^® Stratix^® 10 SX devices. Changed Using the Authentication Feature example to set permissions to 6 which can sign both the core and HPS. Revised Anti-Tampering topic. Revised theUsing eFuses topic. Corrected minor errors and typos.
2019.05.30	19.1	Made the following corrections: Corrected the Signing Command Argument Summary table. The references to .key format should say .qky format.
2019.05.10	19.1	Made the following corrections: Removed spaces before the fuse programming file name in the `quartus_pgm` commands in Step 3b: Programming the AES Key and Configuring the Encrypted Image Using the Command Line. Changed file name argument to `-o "p;my_fuse.fuse"` in Step 4 of Canceling Non-Volatile eFuses.
2019.05.07	19.1	Initial release.

A. Appendices

A.1. Acronyms and Glossary

Table 13. Abbreviations and Acronyms
Term	Meaning	Description
AC	Activation Code	Consists of 2 Helper (firmware) data. Each copy is 32 KB for a total of 64 KB. The SDM retrieves the PUF AES key from this data.
CMF	Configuration Management Firmware	Firmware for the Secure Device Manager (SDM). The SDM manages device configuration. The CMF implements many functions including the functions listed here: FPGA configuration Voltage regulator configuration Temperature measurement HPS software load HPS Reset Remote System Update (RSU) Read, erase, and program flash memory Device security, including authentication and encryption
CA	Certificate Authority	A organization that validates entities such as configuration bitstreams and binds them to cryptographic keys.
Decision CMF	Decision Configuration Management Firmware	Firmware to identify and load the highest priority image.
Device Owner	—	The device owner asserts control over a device by programming the root public key into eFuses. When a device has an owner the device only loads configuration bitstreams that the owner has signed.
MAC	Message Authentication Code	A short piece of added information to help guarantee the integrity and authenticity of a larger piece of information. For example, the SDM uses a MAC to verify PUF helper data during PUF activation.
PR	Partial Reconfiguration
Provision Firmware	—	Provision firmware contains code that runs during provisioning. For example provision firmware includes code to program authentication fuses or enroll the PUF.
PUF	Physically Unclonable Function	A physically-defined digital fingerprint that serves as a unique identifier for a semiconductor device such as a microprocessor. This digital fingerprint is based on unique physical variations which occur naturally during semiconductor manufacturing.
PUF helper data	.puf	A binary file that contains PUF helper data. The SDM uses the PUF helper data to activate the PUF prior to configuration. A 32 kilobyte block in Quad SPI memory stores the PUF helper data.
UID	Unique ID	An identifier that is guaranteed to be unique.
Wrapped key file	.wkey	A binary file that contains the PUF-wrapped encryption key.

A.2. File Types for Security

The Programming File Generator, Intel^® Quartus^® Prime Programmer, and quartus_pgm command use these file types to generate and program a secure configuration bitstream. Refer to the Secondary Programming Files (Programming File Generator) in the Intel^® Quartus^® Prime Pro Edition User Guide: Programmer for definitions of other configuration bitstream file types such as .rbf and .jic that are do not implement security-related functions.

Table 14. File Types for Security
File Extension	Description
.fuse	Contains device eFuse data.
.pem	Privacy enhanced mail certification. Stores the public or private key for authentication.
.puf	Physically unclonable function (.puf) file. A binary file that contains PUF helper data.
.qek	Intel^® Quartus^® Prime encryption key. A password-protected file that stores the AES key that encrypts and decrypts the configuration bitstream.
.qky	Intel^® Quartus^® Prime key file. Stores the signing key chain for configuration bitstream authentication.
.wkey	Wrapped AES key file. A binary file that contains the PUF-wrapped encryption key.

A.3. quartus_pgm Command Operation Argument

Here is the Intel^® Quartus^® Prime help for the operation (-o) argument to the quartus_pgm command.

Quartus_pgm --help=operation

JTAG Config/Program        
		                    -o p;file.sof
                            -o pvb;file.pof
                            -o pvbi;file.jic
                            -o p;file.rbf
                            -o pvbi;file.qky
                            -o pbi;file.qek
                            -o pvbi;file.fuse
                            -o p;file.cert
                            -o p;file.ccert
                            -o pvbi;file.puf
                            -o pvgi;file.wkey

JTAG Examine                -o e;file.pof;device_name
                            -o ei;file.jic;device_name
                            -o ei;file.fuse;device_name
                            -o ei;file.cert;device_name
                            -o ei;file.ccert;device_name
                            -o ei;file.puf;device_name
                            -o ei;file.wkey;device_name

Skip Device (JTAG Bypass)   -o s;device_name

Passive Serial Program      -o file.sof

Active Serial Program       -o pl;file.pof

Passive Serial Chain        -o file1.sof -o file2.sof -o file3.sof

JTAG Chain                  -o p;file1.pof -o s;file2.pof
                            -o v;file1.pof@1 -o p;file2.pof@2

CDF                         quartus_pgm -c byteblastermv[lpt1] file.cdf