Versal Authentication Support - 2024.2 English

Bootgen User Guide (UG1283)

Document ID
UG1283
Release Date
2024-11-13
Version
2024.2 English

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

Note: Unlike Zynq devices and Zynq UltraScale+ MPSoC, for Versal adaptive SoCs, the authentication certificate is placed prior to the partition. The ECDSA P521 curve is not supported for authentication of the bootloader partition (PLM) because the BootROM only supports RSA-4096 or ECDSA-P384 authentication. P521 can, however, be used 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." A snippet of the usage is shown below.

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. You can enable the use of authenticated partition digests that are stored in the optional Image Header Table. The partition digests are SHA digests that are used to validate the integrity of the partition data at boot.

When reading the Meta Header, PLM authenticates and copies the table of partition digests to be used during partition loading. Authentication can be skipped for any partition with a digest entry in the table. In this case, the partition data is passed through the SHA engine, and the resulting digest is compared 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 for storing in eFUSE for PPK to be trusted. This step is required only for authentication with eFUSE mode, and can be skipped for AHWRoT. The value from efuseppksha.txt can be programmed to eFUSE for authentication with the eFUSE for AHWRoT.

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