Versal Authenticated JTAG HSM Flow - 2025.2 English - UG1283

Purpose

The Authenticated JTAG (AuthJTAG) HSM flow for Versal devices allows enabling secure, time‑bounded JTAG access using signed policy data, without exposing private keys outside a Hardware Security Module (HSM). Bootgen splits the process into:

1. Stage 0: Generate hash artifacts (no private keys)
2. Stage 1: Offline/HSM signing (AuthJTAG hash)
3. Stage 2: Assemble signed AuthJTAG enablement binary

Components

• PPK (Primary Public Key): Long‑term anchor
• SPK (Secondary Public Key): Operational key (its hash is signed by PSK)
• AuthJTAG Policy Block: Contains revoke_id, device_dna, jtag_timeout
• Signatures:
  • SPK signature
  • AuthJTAG policy signature
• Algorithm (example): ECDSA (P‑384) → SHA384 hash files (.sha384 / .sha384.sig)
  • RSA variant uses SHA3 (.sha3 / .sha3.sig)
  • Use: -authenticatedjtag ecdsa or -authenticatedjtag rsa

Stage 0 – Hash Generation

Command:

bootgen -arch versal -image test_stage0.bif -generate_hashes 
-authenticatedjtag ecdsa -log trace

BIF (test_stage0.bif):

all:
{
  ppkfile = files/keys/primary0.pub
  authjtag_config {
    revoke_id    = 0x23
    device_dna   = 112233445566778899AABBCCDDEEFF11
    jtag_timeout = 0x11223344
  }
}

Outputs (ECDSA example):

• authJtag.sha384 (AuthJTAG policy hash)

  (Plus any standard image hash artifacts if combined with a boot image build.)

Key Points:

• No private keys required.
• device_dna: 128‑bit hex (for example, must match target silicon length/format).
• jtag_timeout: Policy field interpreted by device (units device‑specific).
• revoke_id: Supports revocation/iteration of JTAG enablement tokens.

Stage 1 – HSM / Offline Signing

Actions inside secure environment:

• Sign authJtag.sha384 with PSK (or same operational key, per policy) → authJtag.sha384.sig
• openssl rsautl -raw -sign -inkey PSK.pem -in authjtag.sha384 > authjtag.sha384.sig

Deliverables returned for Stage 2:

• authJtag.sha384.sig

Validation Checklist:

• Signature sizes match algorithm (ECDSA P‑384 → 96 bytes DER or fixed raw if tool expects raw; Bootgen expects its defined format).
  Note: DER is a standardized binary format to serialize cryptographic data. a standard way of describing complex data objects like digital certificates, keys, and signatures
• Filenames unchanged.

Stage 2 – Generating Auth JTAG PDI binary

Produces authenticated JTAG binary.

Command:

bootgen -arch versal -image test_stage2.bif \
-authenticatedjtag ecdsa authJtag-ecdsa-new.bin -log trace

BIF (test_stage2.bif):

all:
{
  ppkfile = files/keys/primary0.pub
  authjtag_config {
    revoke_id      = 0x23
    device_dna     = 112233445566778899AABBCCDDEEFF11
    jtag_timeout   = 0x11223344
    authjtag_sign  = authJtag.sha384.sig
  }
}

What Bootgen does:

• Loads PPK
• Inserts AuthJTAG signature (authJtag.sha384.sig)
• Generates final enablement artifact: authJtag-ecdsa-new.bin

File Naming Summary

hash_ext:

• ECDSA: sha384
• RSA: sha384

BIF Attribute Reference (authjtag_config)

Common Errors

Security / Operational Notes

• Keep PSK inside HSM; only public PPK in build chain.
• Use trace logs (-log trace) for audit of parameter inclusion.
• Validate generated binary on secured test hardware before deployment.

Minimal Workflow Recap (ECDSA)

1. Stage 0: bootgen -arch versal -image test_stage0.bif -generate_hashes -authenticatedjtag ecdsa
2. Stage 2: bootgen -arch versal -image test_stage2.bif -authenticatedjtag ecdsa authJtag-ecdsa-new.bin
3. Distribute authJtag-ecdsa-new.bin to provisioning flow

Best Practices

• Archive Stage 0 artifacts + used PPK for provenance.
• Enforce signature integrity check (size + hash) pre-Stage 2.
• Maintain revocation ledger tied to revoke_id values.
• Automate mismatch detection (device_dna length, algorithm drift).

Optional RSA Variant Differences

• Use: -authenticatedjtag rsa
• Hash files: authJtag.sha384
• Signatures: authJtag.sha384.sig
• Keep consistent algorithm