Embedded Security explained: Digital signatures

By KiviCore

August 26, 2026

Embedded devices rely on software and data that may change throughout their lifetime: firmware images, updates, FPGA configurations or device settings. Before trusting this data, the system may need to answer two important questions: Has the data been modified and was it signed by a trusted source?

Digital signatures provide a cryptographic mechanism to verify both.

1. What are digital signatures?

A cryptographic hash can detect whether data has changed, but it cannot prove who authorized it. An attacker replacing a firmware image could simply calculate a new hash as well. Digital signatures combine integrity and authenticity. They allow an embedded system to verify that data has not been modified after signing and that it was signed by the holder of the expected private key.

Typical embedded applications include:

• Secure boot: Verify firmware before execution.
• Firmware updates: Accept only authorized update images.
• FPGA configuration: Authenticate bitstreams before loading them.
• Configuration data: Reject unauthorized configurations.
• Commands and messages: Verify received data before acting on it.

In many of these applications, the embedded device does not need to generate signatures itself. It only needs to verify them.

2. How does it work?

Digital signatures use asymmetric cryptography with a private and public key. On the signing side, a cryptographic hash first creates a fixed-size digest representing the firmware, configuration or other data. The signature algorithm then uses the private key to generate a digital signature for this digest. The private signing key must remain secret. If it is compromised, an attacker could create signatures that the device may accept as authentic.

The data and its signature can then be transferred to the embedded device. For verification, the device calculates the hash again and uses the corresponding public key to verify the signature. If the data has been modified after signing, or the signature does not match, verification fails.

This results in a simple basic flow:

• Data → Hash → Sign with private key → Digital signature
• Data + Signature → Verify with public key → Valid / Invalid

The public key itself does not need to be secret. What matters is that the device uses the correct and trusted public key and that an attacker cannot replace it. In a simple embedded system, the public key or a hash of it can be securely provisioned as a trust anchor. More complex systems may use digital certificates and a Public Key Infrastructure (PKI) to establish and manage trust across devices and keys. Digital signatures therefore do not inherently require a complete PKI. The appropriate trust model depends on the system architecture.

Digital signatures should also not be confused with encryption. A signed firmware image can still be readable:

• Encryption → confidentiality
• Digital signature → authenticity + integrity

Both mechanisms can be combined when confidentiality, authenticity and integrity are required.

Digital signature schemes combine cryptographic primitives such as hashing with an asymmetric signature algorithm. Established schemes include RSA and ECDSA, while ML-DSA provides a standardized post-quantum alternative. These algorithms differ not only in their security properties, but also in computational effort, memory requirements, and key and signature sizes.

 3. Embedded implementation considerations

Implementing digital signatures in an embedded system involves more than selecting an algorithm. Key considerations include: 

Signing or verification only?

Secure boot and firmware update mechanisms often require only signature verification. Signing can remain in a separate trusted environment, keeping the private signing key off the device.

Where is the trust anchor stored?

The public key or its hash must be protected against unauthorized replacement, for example using OTP/eFuses, protected storage or a hardware Root of Trust.

When does verification take place?

Secure boot may require verification very early in the boot process, before an OS is available and while memory and processing resources are still limited.

What are the resource and performance constraints?

Available CPU performance, RAM, flash bandwidth, hardware crypto accelerator availability and acceptable verification or boot time can constrain the implementation.

Software, hardware acceleration or dedicated hardware?

Occasional verification on a capable processor may be handled in software. Limited CPU resources, strict timing requirements or frequent verification can make hardware acceleration or a dedicated hardware implementation attractive.

Which signature algorithm fits the system?

RSA, ECDSA and post-quantum schemes such as ML-DSA have different computational, memory, key-size and signature-size characteristics that need to fit the target platform.

Does the system need crypto agility?

Long-lived embedded devices may benefit from an architecture that allows algorithms to be replaced or extended as security requirements and cryptographic standards evolve.

There is no single best implementation for every embedded system. The right approach depends on the device architecture, threat model, performance requirements and the role of signature verification within the system's chain of trust.