Content

Digital signatures are foundational for authenticating firmware, software updates, FPGA configurations, configuration data and other security-relevant objects in embedded systems. But the architectural choice is rarely straightforward.

At implementation level, there are two fundamental approaches. The cryptographic computation can be executed in software by a processor, or it can be offloaded to dedicated cryptographic hardware. The right choice depends on more than raw execution time. CPU load, available FPGA resources, memory requirements, data movement and required latency all influence the system-level result.

This article compares both approaches and then looks at a second decision that arises when hardware is selected: Should the implementation be optimized primarily for FPGA area or for cryptographic performance?

1. What do we mean by software and hardware cryptography?

Discussions on hardware cryptography often focus on system-level components like HSMs or TPMs. While these are critical, our focus here is the implementation level. For example, an FPGA-based system might combine secure key storage, a processor, cryptographic IP cores and secure-boot logic to form a larger security subsystem. The cryptographic IP core is one component of that architecture rather than an HSM or TPM by itself.

In this article we compare if the cryptographic computations required for digital signature verification shall be executed in software by the processor or offloaded to dedicated cryptographic hardware. We distinguish two primary approaches:

• In a software implementation, cryptographic algorithms are executed as software instructions by a general-purpose or embedded processor. A cryptographic library provides functions such as hashing, encryption or digital signature verification, while the processor performs the underlying computations.
• In hardware cryptography, dedicated digital logic performs or accelerates cryptographic operations. This can range from individual hardware accelerators for functions such as hashing or polynomial arithmetic to complete cryptographic algorithms implemented in RTL. The processor may still configure the hardware, provide input data and process the result, but the cryptographic computation itself is partly or fully offloaded to dedicated logic.

2. Signature verification is part of a larger trust workflow

It is important to distinguish between the cryptographic operation and the overall security workflow. Mathematically, verification reduces to:

Data + Signature + Trusted Public Key → Cryptographic Verification → Valid/Invalid

In an embedded system, the complete "trust workflow" also involves:

• Manifest parsing and data structuring,
• Policy checks (versions, certificate chains, blacklists),
• The final decision (Accept/Reject).

A common misconception is that an RTL implementation of signature verification requires moving the entire workflow into hardware. This is not the case. Even if the computationally intensive cryptographic core is executed in RTL, the logic for policy decisions, key management, and manifest parsing can remain in software. In this article, we primarily compare where the cryptographic function is implemented, not where the complete security workflow resides.

3. Software-based signature verification

The most straightforward implementation is to execute the cryptographic algorithm on the processor using a software library.

The processor handles the surrounding workflow and also performs hashing and signature verification. The verification result is then combined with policy checks to make the final accept/reject decision.

Conceptually: Firmware / Data → Parsing / Policy → Crypto Library → Accept / Reject

3.1 When does software make sense?

Software-based verification can be a good fit when:

• signatures are verified relatively infrequently,
• verification latency is acceptable,
• sufficient CPU and memory resources are available,
• flexibility is important,
• or cryptographic algorithms may need to change during the product lifetime.

Software also fits naturally into existing development workflows. Mature cryptographic libraries can be integrated without adding dedicated FPGA logic. Consider a device that verifies a firmware image once during startup. If a software implementation completes verification within the required boot time and the processor is otherwise idle during that phase, adding dedicated hardware purely for performance may provide little system-level benefit.

Software also offers a high degree of crypto agility. Algorithms and implementations can often be changed through software updates without redesigning the underlying hardware.

3.2 Where are the limitations?

Cryptographic processing consumes CPU cycles and memory and competes with other software workloads. Depending on the system, this can affect CPU utilization, working memory, verification latency, system responsiveness, and predictability of execution time.

This becomes especially critical with Post-Quantum Cryptography (PQC). Algorithms such as ML-DSA require significant working memory for polynomial arithmetic and intermediate buffers. On resource-constrained embedded CPUs, the RAM requirements of a PQC software implementation can conflict with existing application needs, making software-only approaches significantly less viable than for traditional elliptic-curve schemes.

The required software components also become part of the security boundary. Depending on the architecture, that may include the cryptographic library, bootloader, and other code involved in parsing and making the final trust decision. This does not make software verification inherently insecure. It means the software environment must be considered as part of the overall security architecture.

4. Hardware-based signature verification

The alternative is to offload cryptographic processing to dedicated FPGA or ASIC logic.

In this architecture, software can still control the overall workflow. The CPU may parse the signed object, perform policy checks, select the public key and start the verification operation. The dedicated hardware core performs the cryptographic processing and returns the verification result.

The defining difference is therefore how the cryptographic computation is implemented and which system resource performs it:

• In a software implementation, the processor executes the cryptographic algorithm.
• In a hardware implementation, dedicated logic performs or accelerates the cryptographic processing.
  
  

  ---

4.1 Why use dedicated hardware?

Hardware can be attractive when verification creates significant CPU load, low latency is required, signatures are processed frequently or the processor should remain available for other application tasks while the cryptographic operation is running.

Dedicated hardware also allows the cryptographic datapath to be optimized specifically for the algorithm and target technology. For FPGA-based systems, this creates a design space between minimizing logic resources and maximizing cryptographic throughput or minimizing latency.

Hardware acceleration should nevertheless be evaluated at system level. A faster cryptographic engine does not automatically result in the same improvement in end-to-end verification time. Firmware still has to be read from memory or flash, data may have to cross a bus or DMA interface, and software may need to configure and synchronize with the hardware.

The relevant metric is therefore not only crypto-core latency, but the latency and resource usage of the complete verification path.

4.2 Hardware is not one architecture: area versus performance

Choosing hardware does not end the architecture decision. A hardware implementation can itself be optimized in different ways.

One design may minimize FPGA resources by sharing functions and combining dedicated hardware with processor-controlled operations. Another may implement substantially more of the cryptographic processing directly in RTL to achieve much higher performance.

• A resource-optimized architecture minimizes the amount of dedicated logic required for the cryptographic function. Hardware accelerators can offload computationally intensive operations. However when reducing the amount of logic used, data processing is not optimized for maximum parallel execution. That results in not achieving minimum latency, but cryptographic hardware offload is beneficial to free CPU from cryptographic functions to execute other tasks in software in parallel. This approach is attractive when FPGA area is limited and a signature verification does not justify a large dedicated cryptographic block.
• A performance-oriented architecture dedicates more logic to the cryptographic operation. The more logic is used to implement parallel or pipelined operations which results in much faster execution of cryptographic algorithms. This can substantially reduce the number of clock cycles required for operations such as key generation, signing or verification. The trade-off is a larger FPGA footprint in exchange for higher cryptographic throughput and lower latency.
  

4.3 Example: KiviPQC-DSA Tiny vs. Fast

KiviCore provides both architectural approaches for ML-DSA as hardware IP cores. KiviPQC-DSA Tiny and KiviPQC-DSA Fast are both hardware IP cores. Tiny uses a resource-oriented architecture to reduce FPGA resource requirements, while Fast implements the cryptographic algorithm as a larger RTL design for significantly higher processing performance.

In both cases, cryptographic processing can be offloaded so that the host CPU can remain available for other application tasks. The surrounding application, parsing and policy logic can still remain in software.

4.4 When does hardware acceleration make sense?

The decision should be based on system requirements rather than on the assumption that hardware is always preferable.

These are starting points rather than fixed rules. For example, a fast hardware core can still be limited by flash bandwidth or data transfers, while an optimized software implementation may be entirely sufficient for an operation that occurs only once during boot.

5. Do you actually need signing? The case for verification-only

Software versus hardware is not the only architectural choice. A second, independent question is whether the embedded device needs key generation and signing at all.

For secure boot, authenticated firmware updates or FPGA configuration authentication, signing can take place in a separate trusted development, manufacturing or release environment. The embedded device then only needs the trusted public key and signature-verification functionality.

A verification-only implementation can reduce implementation scope and avoids placing the private signing key on the embedded device.

Importantly, verification-only is not a third implementation architecture. Verification itself can be implemented in software or hardware.

6. What changes with post-quantum signatures?

The software-versus-hardware decision becomes particularly relevant when moving to post-quantum digital signatures.

ML-DSA uses different computational operations from RSA or ECDSA and introduces larger public keys and signatures. For embedded systems, the resulting requirements extend beyond CPU execution time. Working memory, storage, interfaces and data movement can all influence the architecture.

This is why PQC migration should not be treated simply as replacing one cryptographic library call with another.

For a detailed introduction to the algorithm, its three NIST parameter sets and their implications for embedded systems, see ML-DSA explained: Post-Quantum Digital Signatures for Embedded Systems.

7. Choosing the right architecture

The architecture decision can be reduced to three questions:

1. How should cryptographic verification be implemented?
   In software executed by the processor, or using dedicated cryptographic hardware?
2. If hardware is used, what should it optimize for?
   Minimum FPGA resources or maximum cryptographic performance?
3. Which cryptographic functions does the device actually need?
   Full key generation, signing and verification, or verification-only?

Separating these questions avoids a common source of confusion. A resource-optimized and a performance-optimized RTL IP core are both hardware solutions; they simply occupy different points in the area/performance design space.

For FPGA and SoC developers, the best implementation is therefore not necessarily the architecture with the fastest standalone cryptographic core. It is the architecture that meets the required security and verification latency while fitting the available CPU, memory, FPGA resources and complete system datapath.