1. What are digital signatures

2. How does it work?

3. Embedded implementation considerations

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: 

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.