Versal Authentication Support - Versal Authentication Support - 2026.1 English - UG1283

Bootgen User Guide (UG1283)

Document ID
UG1283
Release Date
2026-06-23
Version
2026.1 English

Bootgen supports RSA-4096 and ECDSA P384 and P521 curves for Versal adaptive SoC authentication. The system uses NIST SHA-3 to calculate the hash on all partitions and headers. The system places the signature calculated on the hash in the PDI.

Note: Versal adaptive SoCs place the authentication certificate before the partition, unlike Zynq devices and Zynq UltraScale+ MPSoC. The bootloader partition (PLM) cannot use the ECDSA P521 curve for authentication because the BootROM supports only RSA-4096 or ECDSA-P384. However, you can use P521 to authenticate any other partition.

Meta Header Authentication

For a Versal adaptive SoC, Bootgen authenticates the meta header based on the parameters under the bif attribute "metaheader." The following snippet shows the usage.

metaheader
{
	authentication = rsa,
	pskfile = psk.pem,
	sskfile = ssk.pem
}

Authentication Optimization

Starting in v2024.1, for a Versal adaptive SoC, you can opt for authentication time reduction.

If you are using the same SPK (with the same authentication algorithm and key strength) for the Meta Header and partitions loaded by the PLM, it is possible to avoid the SPK and partition data signature validations. Enable the use of authenticated partition digests stored in the optional Image Header Table. At boot, the system uses SHA partition digests to validate the integrity of the partition data.

When reading the Meta Header, PLM authenticates and copies the table of partition digests to be used during partition loading. You can skip authentication for any partition with a digest entry in the table. In this case, the system passes the partition data through the SHA engine. It then compares the resulting digest against the authenticated digest value stored for that partition in the Image Header Table.

For enabling authentication optimization refer to enable_auth_opt.

PPK Hash for eFUSE

Bootgen generates the PPK hash and stores it in eFUSE so the PPK is trusted. You need this step only for authentication with eFUSE mode. Program the value from efuseppksha.txt into the eFUSE for AHWRoT authentication.

BIF File Example

The following is a sample BIF file, generate_hash_ppk.bif.

generate_hash_ppk:
{
    pskfile = primary0.pem
    sskfile = secondary0.pem
    image
    {
        name = pmc_ss, id = 0x1c000001
        { type=bootloader, authentication=rsa, file=plm.elf}
        { type=pmcdata, load=0xf2000000, file=pmc_cdo.bin}
    }
}

Command

The command to generate PPK hash for eFUSE programming is:

bootgen –image generate_hash_ppk.bif –arch versal –w –o test.bin –efuseppkbits efuseppksha.txt

Cumulative Secure Boot Operations for Versal Adaptive SoC

Table 1. Cumulative Secure Boot Operations
Boot Type Operations Hardware Crypto Engines
Authentication Decryption Integrity (Checksum Verification)
Non-secure boot No No No None
Asymmetric Hardware Root-of-Trust (A-HWRoT) Yes (Required) No No RSA/ECDSA along with SHA3
Symmetric Hardware Root-of-Trust (S-HWRoT) (Forces decryption of PDI with eFUSE black key) No Yes (Required PLM and Meta Header should be encrypted with eFUSE KEK) No AES-GCM
A-HWRoT + S-HWRoT Yes (Required) Yes (Required) No RSA/ECDSA along with SHA3 and AES-GCM
Authentication + Decryption of PDI Yes Yes (Key source can be either from BBRAM or eFUSE) No RSA/ECDSA along with SHA3 and AES-GCM
Decryption (Uses user-selected key. The key source can be of any type such as BBRAM/BHDR or even eFUSE) No Yes No AES-GCM
Checksum Verification No No Yes SHA3