Content 

1. Starting with the FPGA configuration

2. A two-stage pure software boot process

3. Measured boot performance

4. Adapting security and performance

5. From a protected boot to lifecycle security

Secure boot on an FPGA-based system does not end when the device has loaded its configuration bitstream. The processor, bootloader, application firmware, and later updates also have to be protected before execution.

We implemented and measured a multi-stage secure boot architecture on an Efinix Titanium Ti375 SoC FPGA with the hardened high performance Sapphire RISC-V SoC consisting of quad cores that run up to 1 GHz. The design combines the Ti375's native bitstream security with two KiviCore bootloader stages, extending the chain of trust to software stored in external flash.

1. Starting with the FPGA configuration

The Ti375 provides native security mechanisms for the first configuration stage. Its configuration bitstream can be encrypted with AES-GCM-256 and authenticated using RSA-4096. The AES key and a hash of the RSA public key are stored in FPGA eFuses. During configuration, the device decrypts the bitstream and validates its signature before entering user mode. If verification fails, configuration stops. JTAG access can also be permanently restricted through eFuses.

In our architecture, the authenticated FPGA configuration initializes the on-chip RAM containing KiviBoot-NanoBL. This creates the transition from the Ti375 hardware trust anchor to the software boot chain: only the expected FPGA design and first-stage bootloader can become active. For production systems, bitstream authentication is essential; encryption additionally protects the confidentiality of the FPGA design.

2. A two-stage pure software boot process

A single feature-rich bootloader would increase the amount of code that has to be trusted from the beginning. We therefore divide the process into a minimal first stage and a more flexible second stage.

• KiviBoot-NanoBL, the minimal first stage: KiviBoot-NanoBL runs from on-chip RAM and deliberately contains only the functionality required to start the next trusted component. It loads KiviSecureBL from external flash, decrypts it, and verifies it before execution. Keeping this stage small reduces its attack surface and makes security review easier.
• KiviBoot-SecureBL, verification and system functions: After successful verification, KiviBoot-SecureBL runs from external DDR4 RAM. It loads the user application from flash into DDR4 RAM, decrypts the image, verifies its hash, and validates its digital signature. Control is transferred to the application only after all checks have passed. As the more flexible stage, it can also implement platform-specific policies for firmware updates, image metadata, product or hardware identifiers, version checks, recovery, and anti-rollback protection.

The resulting chain of trust is:

Ti375 eFuses -> authenticated and encrypted bitstream -> KiviBoot-NanoBL -> KiviBoot- SecureBL -> user application

3. Measured boot performance

We measured the implementation on the Efinix Titanium Ti375 C529 Development Kit in its default manufacturer configuration. To make the result reproducible and comparable, KiviSecureBL loaded a 256 KiB user application from external flash into DDR4 RAM.

The complete software boot process up to execution of the user application took approximately 811 ms. Around 482 ms, or 59% of the total time, was spent transferring data from flash. Excluding the measured flash transfer time, approximately 329 ms remained for security processing and other bootloader operations. The load time for the application image of around 423 ms corresponds to the minimum time required to load the application without Secure Boot anyway.

This distinction matters because flash performance is highly system-dependent. Faster devices, higher SPI clock rates, and more efficient transfer modes can significantly reduce startup time without changing the secure boot architecture. The 811 ms result therefore characterizes this specific Ti375 development-kit configuration rather than a fixed limit of the solution.

4. Adapting security and performance

The same boot concept can be adapted to different system requirements. Cryptographic operations can run entirely in software on Sapphire RISC-V CPUs, an external secure element can protect keys and provide selected functions, SHA and AES operations can be accelerated with crypto IP cores in the FPGA fabric, or SPI Flash configuration can be changed to speed-up loading software. Hardware acceleration becomes particularly relevant for larger images or systems with tight startup-time requirements.

The appropriate architecture depends on the threat model, available FPGA resources, acceptable boot time, key-protection requirements, update path, and whether the target runs bare metal, an RTOS, or Linux. Native bitstream protection and software verification should be assessed together. Securing only the application leaves the FPGA configuration exposed, while protecting only the bitstream leaves subsequently loaded software outside the chain of trust.

5. From a protected boot to lifecycle security

Secure boot is only one part of product security. The same trust model should continue through manufacturing, key provisioning, field updates, rollback prevention, and recovery. Signing keys need to remain outside the device, development and production credentials should be separated, and failed verification must lead to a defined safe state. These decisions are platform- and product-specific and should be made before the update mechanism is implemented.