Asymmetric Keys with STM32 and ECDSA

STM32 Tutorial: asymmetric cryptography for embedded systems, with a focus on public/private key pairsdigital signatures, and ECDSA on STM32C5.

Abstract

This article introduces asymmetric cryptography for embedded systems, with a focus on public/private key pairsdigital signatures, and ECDSA on STM32. It explains the basic principles behind asymmetric keys, how message digests are signed and verified, and how these concepts are demonstrated using the STM32 Cryptographic Library example stcryptolib_sign_verify_ecc_ecdsa. The goal is to provide a simple and practical overview for secure embedded applications.

1. Introduction

Asymmetric cryptography uses two different but mathematically linked keys:

  • public key, which can be shared
  • private key, which must remain secret

This model is especially useful when you want to:

  • verify identity
  • sign messages
  • protect trust during communication
  • support secure boot and firmware authenticity

Unlike symmetric cryptography, asymmetric cryptography does not rely on a single shared secret. Instead, it uses a key pair to separate what can be shared openly from what must be kept confidential.

In embedded systems, asymmetric cryptography is often used for authentication and trust establishment, while symmetric algorithms are used for high-speed data encryption.

2. Crypto basics - asymmetric key ciphers

Asymmetric cryptography is based on the use of a public key and a private key.

Main principle

  • The public key is distributed to others.
  • The private key stays with the owner.
  • What is done with one key can only be validated or reversed by the other.

Two common uses

  1. Digital signatures

A private key is used to sign data, and the public key is used to verify that signature.

This provides:

  • authenticity: proof of origin
  • integrity: proof that the data was not modified
  1. Encryption for confidentiality

A public key can be used to encrypt data so that only the private key can decrypt it.

However, in practice, embedded security systems more commonly use asymmetric cryptography for signatures and authentication, because asymmetric encryption is computationally expensive.

Why asymmetric keys matter in embedded systems

Asymmetric cryptography is useful for:

  • secure boot
  • firmware signing
  • device identity
  • certificate-based trust
  • secure provisioning

2.1. Message digest and digital signatures

For asymmetric signing, the data is usually not signed directly. Instead, a message digest is created first.

What is a digest?

A digest is the output of a hash function applied to a message.

It has these properties:

  • fixed length
  • fast to compute
  • sensitive to any message change

Why sign the digest instead of the full message?

Signing the digest is:

  • more efficient
  • faster
  • well suited for embedded devices

2.2. ECDSA workflow

ECDSA stands for Elliptic Curve Digital Signature Algorithm.

A typical flow is:

  1. Compute the digest of the message
  2. Use the private key to generate a signature
  3. Send the message together with the signature
  4. Use the public key to verify the signature
  5. If verification succeeds, the message is authentic and unchanged

Key point

A digital signature does not hide the message.
It proves that the message was signed by the owner of the private key and that it was not altered.

2.3. ECDSA and public key verification

ECDSA is a widely used asymmetric signature algorithm based on elliptic curves.

Why ECDSA is attractive

  • strong security with relatively small keys
  • efficient compared with many older asymmetric algorithms
  • well suited for constrained embedded devices

What happens during signing

The private key is used together with the message digest and a random value to produce the signature.

What happens during verification

The public key is used to check whether:

  • the signature is valid
  • the digest matches the original message
  • the data has not been modified

Important note

ECDSA relies on strong randomness during signature generation. If the random value is weak or reused, security can be compromised. This makes a reliable RNG essential.

3. Hands ON with STM32C5

The example used here is:

  • Example: stcryptolib_sign_verify_ecc_ecdsa
  • Example version: 2.0.3
  • Target: STM32C5 series

This example shows how to use the STM32 Cryptographic Library to sign and verify a message with ECDSA.

To download the example, go to> STM32 Package Creator , as this is a new way from ST to generate custom examples for STM32CubeMX2 and HAL2.

From there, select the STM32C5:

And confirm the HAL driver version as well as the STCryptoLib:

Proceed with the software package configuration:

Select the package format:

And download the package example:

Locate the example ../STM32C5_Crypto/examples/middleware/stcryptolib/sign_verify_ecc_ecdsa

4. Hands-On: Deep dive explanation

The library configuration and the operation are performed in a single API call.

It includes two execution paths:

  1. Known random
    • sign a known message digest using a known random
    • compare the generated signature with a known expected signature
    • verify the known message digest with the known signature
  2. True random
    • sign the known message digest using a true random

verify the signature generated from the true random

4.1. Detailed scenario

Initialization phase

At program start, mx_system_init() is called. It initializes:

  • peripherals
  • nonvolatile memory, such as flash or external memory
  • MPU regions, if applicable
  • system clock
  • SysTick

Step 1: Initialize cryptographic services

  • initialize the STM32 Cryptographic library
  • initialize the RNG instance

Step 2: Perform ECDSA signing and verification

  • compute and verify the digest of the message
  • compute and verify the signature with a known random
  • compute and verify the signature with a true random

Step 3: Deinitialize services

  • deinitialize the STM32 Cryptographic library
  • deinitialize the RNG instance

Expected successful result

If all operations succeed:

  • the status LED remains turned on
  • the global variable ExecStatus is set to EXEC_STATUS_OK

If USE_TRACE is enabled, the following log messages can be observed:

Conclusion

Asymmetric cryptography plays a central role in secure embedded systems. Unlike symmetric cryptography, it uses a public/private key pair to separate trust and secrecy.

In this article, we covered:

  • the basics of asymmetric key cryptography
  • the role of digests and digital signatures
  • how ECDSA supports authenticity and integrity
  • how the STM32 Cryptographic Library demonstrates signing and verification in practice

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top