Spartan UltraScale+ HSM Flow Support with Example - 2025.2 English - UG1283

Stage 0 – Generate Hash Files

Generates:

• hashblock hash files (BH hash, PLM hash, pmc cdo hash)
  Note: For SU10P, SU25P, SU35P it is the Hashblock hash. For >SU45P, it is the Hashblock itself.
• SPK hash

Command:

./bootgen -arch spartanup -image test_stage0.bif -generate_hashes -log trace

Example (SHAKE256 variant):

new_bif:
{
    id_code = 0x04E88093
    extended_id_code = 0x01
    id = 0x2
    boot_config { smap_width = 32 }
    ppkfile = ../files/keys/primary.lms.pub
    spkfile = ../files/keys/secondary.lms.pub
    image {
        name = pmc_subsys
        id = 0x1c000001
        partition {
            id = 0x01
            type = bootloader
            authentication = lms-shake256
            file = ../files/plm.elf
        }
        partition {
            id = 0x09
            type = pmcdata, load = 0xf2000000
            file = ../files/pmc_data.cdo
        }
    }

Resulting key files (SHAKE256):

• plm.0.shake256 (this file contain either hashblock or hash of hashblock based on the device family)
  Note: plm.0.shake256 (hashblock) (this file contain either hashblock or hash of hashblock based on the device family)

• spk.shake256.sig (hash to be signed → becomes spk.shake256.sig after signing)

• bootheader.shake256

(If using lms-sha256 the extensions are .sha256 instead.)

Stage 1 – HSM / Offline Signing

Performed entirely inside the secure environment.

Sign:

• SPK hash file → produces spk.<ext>.sig
• Hashblock hash or Hashblock → produces <partition>.N.<ext>.sig (N = partition index)

Example (single authenticated partition, SHAKE256):

Input to HSM:
  spk.shake256.sig    (hash blob)
  plm.0.shake256      (Hashblock hash or Hashblock)
HSM outputs:
  spk.shake256.sig        (now a signature)
  plm.0.shake256.sig      (Hashblock hash or Hashblock signature)

Ensure:

• PSK signs SPK hash
• SSK signs hashblock hash/ hashblock hash
• File naming preserved exactly
• Binary (raw) signature format returned

Stage 2 – Final Image Assembly

Recombines original inputs + returned signatures.

Command:

./bootgen -arch spartanup -image test_stage2.bif -w -o boot_new.bin -log trace

Example (corrected for SHAKE256):

new_bif:
{
    id_code = 0x04E88093
    extended_id_code = 0x01
    id = 0x2
    boot_config { smap_width = 32 }
    ppkfile = ../files/hss_keys/primary.lms.pub
    spkfile = ../files/hss_keys/secondary.lms.pub
    image {
        name = pmc_subsys
        id = 0x1c000001
        partition {
            id = 0x01
            type = bootloader
            authentication = lms-shake256
            presign = plm.0.shake256.sig
            spksignature = spk.shake256.sig
            file = ../files/plm.elf
        }
        partition {
            id = 0x09
            type = pmcdata, load = 0xf2000000
            file = ../files/pmc_data.cdo
        }
    }
}

(If you instead choose lms-sha256, change authentication plus all .shake256 to .sha256 and presign = plm.0.sha256.sig, spksignature = spk.sha256.sig.)

Output: boot_new.bin (fully authenticated boot image)

Bootgen validates:

• Signature lengths/format
• Algorithm consistency
• Presence of required presign + spksignature

Common Issues

1. presign file not found:
   • Cause: Wrong extension or missing index (.0.)
2. spksignature mismatch:
   • Cause: SPK public key in Stage 2 differs from Stage 0
3. Mixed algorithm/extension:
   • lms-shake256 must use .shake256, lms-sha256 must use .sha256

Best Practices

• Keep Stage 0 in build pipeline; isolate Stage 1 (HSM) with audit logging
• Verify returned signatures (size sanity) before Stage 2
• Enforce consistent key sets between Stage 0 and Stage 2
• Automate detection of extension/key mismatches (pre-flight script)

Notes on LMS/HSS

• Single-level LMS (LMS Only) vs hierarchical HSS (multi-level) affects private key handling, not external file naming.
• Hash/signature generation interfaces remain identical for the flow.