Crypto basics for embedded systems

Companion videos

Watch on YouTube (opens in a new tab)

TESAIoT Security Essentials Thai Embedded Systems Association (TESA)

Videos by Thai Embedded Systems Association (TESA) · The whole series in the playlist AIoT Foundation

Module 1 · Threat modelling and crypto fundamentals · Module overview · Course home

The STRIDE table in the last lesson was full of the words TLS, certificate and signature. This lesson pulls those tools apart one at a time: which property each one gives you, which it cannot give you, and why a private key belongs in a chip, not in a file.

Objectives

By the end of this lesson you will:

Pick the right cryptographic primitive for a goal — confidentiality, integrity or authentication — correctly in at least 4 of 5 cases
Read an X.509 certificate and identify its subject, issuer, validity period and public key
Explain why a private key belongs in a secure element rather than in general-purpose flash

Before you start

Already covered: Lesson 1.1: Threat modelling an IoT device. Keep your threat model table open beside you.
Tools: a computer with openssl on its terminal (already present on Linux and macOS; on Windows use Git Bash or WSL) and internet access.
Board: not needed for this lesson. Every experiment runs on the computer, but the data you read is the real data the board uses.

See it work first

Open a terminal and ask for the certificate from the same broker the board connects to.

openssl s_client -connect mqtt.tesaiot.dev:8884 -servername mqtt.tesaiot.dev -showcerts </dev/null

The result has two certificates. As this lesson is written (26 Sep 2026), the first has subject CN = mqtt.tesaiot.dev, issued by CN = TESAIoT Intermediate CA. The second is TESAIoT Intermediate CA itself, issued by TESAIoT Root CA. The dates you see may differ, because the server’s certificate is renewed periodically.

Guess first: which certificate does the board’s firmware already have embedded — the server’s, the intermediate’s, or the root’s? Write your answer down in your learning log, then find out in lab step 3.

Concepts

1. Three goals, four families of tool

When choosing a tool, first ask which property you need: confidentiality (others cannot read it), integrity (you can tell if it was changed), or authentication (you can tell who created this data). Then pick from the table.

Tool	Uses what key	Gives you	Cannot give you	On our node
A hash, e.g. SHA-256	No key	A fixed-size fingerprint of the data; change one bit and the whole result changes	No way to know who created it — anyone can recompute it	The pinned CA’s fingerprint in the firmware
A MAC, e.g. HMAC-SHA256	One secret key shared by both sides	Integrity, and knowing it came from someone who holds the key	Cannot be proved to a third party, because either side could have created it	The OPTIGA™ Trust M can compute an HMAC (`optiga_crypt_hmac`)
A digital signature, e.g. ECDSA P-256	A key pair — sign with the private key, verify with the public key	Integrity, authentication, and proof that holds up to a third party	Does not hide the data	The CertificateVerify signature in mTLS, the Protected Update manifest
Symmetric encryption, e.g. AES	The same secret key for encrypting and decrypting	Confidentiality, and speed	Needs a way to agree on the key first	Data inside a TLS record
Asymmetric key agreement, e.g. ECDHE	A temporary key pair on each side	A shared secret key without ever sending a key over the wire	Does not verify who the other side is — needs a signature alongside it	The `ECDHE` part of the ciphersuite name

A real example of the pitfall here is in the SDK’s 02_model_signature_hook.c. The function that verifies an AI model’s signature fully checks the CRC of the file’s trailer, but still returns “could not verify” (-10), not “passed” (+1). The comment in the file explains why: returning pass because the CRC matches would turn a signature into a checksum, because anyone can recompute a CRC and overwrite it. A cryptographic hash like SHA-256 has exactly the same problem if no key is involved.

2. X.509 certificates and the chain of trust

An X.509 certificate (RFC 5280) is a document in which the issuer signs a statement that “this public key belongs to this subject, during this period.” There are four fields you need to be able to read.

subject — the certificate’s owner, e.g. CN = mqtt.tesaiot.dev
issuer — whoever signed this certificate, e.g. CN = TESAIoT Intermediate CA
validity — the period from notBefore to notAfter
subjectPublicKeyInfo — the subject’s algorithm and public key

The broker’s chain is: the server’s certificate ← TESAIoT Intermediate CA ← TESAIoT Root CA. The device can trust the server’s certificate because it can walk the signatures back up until it reaches a certificate it already trusts in its firmware — that certificate is called the trust anchor.

The device side also has two sets of its own certificates, as recorded in chapter C4 of the SDK docs and in mqtt_mtls_setup.c.

The factory certificate in slot 0xE0E0 has subject CN=InfineonIoTNode, identical on every chip, issued by Infineon OPTIGA(TM) Trust M CA 300. The only fields that differ per chip are the serial number and the public key, so this certificate proves “this is a genuine Trust M,” but not which device it is.
TESAIoT’s own certificate in slot 0xE0E1, obtained after enrolment, has the device_id as its subject, issued by TESAIoT MCU CA.

There is something you need to know about validity: in the mbedTLS configuration for CM33_NS at this commit (mbedtls_user_config.h), the option MBEDTLS_HAVE_TIME_DATE is disabled, which, as the same file’s comment explains, is the part that checks a certificate’s validity period. CRL parsing (MBEDTLS_X509_CRL_PARSE_C) is disabled too. With this configuration, the device does not reject a certificate for being expired or revoked. Write this down in the “remaining risk” section of your threat model.

3. Why a private key belongs in a chip

A private key in a file or in flash can be read out in several ways: whoever holds the firmware image, whoever can plug into the debug port, or whoever can desolder the flash chip and read it, walks away with the key too. Once they have it, they are your device in every respect — they can make as many copies as they like. This is why ETSI EN 303 645 provision 5.4-1 requires security parameters to be stored securely, and cites a secure element as one example.

The OPTIGA™ Trust M changes the question from “where is the key” to “who can tell the chip to use the key.”

The key is generated inside the chip and there is no command to read it out. In Infineon’s example dump (trust_m3_json.txt, MIT), slot 0xE0F0’s metadata has only Change = never and Execute = always — no read permission at all.
A program sends the key’s slot name (its OID) together with a digest, and gets a signature back, as in the example in the next section.
The chip’s hardware is certified to Common Criteria EAL6+ (high), as Infineon states, so it resists physical attack far better than ordinary flash.

And it is just as important to be complete about what the chip does not protect against.

If the firmware on the MCU is compromised, the attacker can ask the chip to sign anything, for as long as they control the board. The chip prevents the key from being stolen or cloned, not misused while the board itself is compromised.
The I2C wire between the MCU and the chip is not encrypted in the SDK’s default configuration (OPTIGA_COMMS_DEFAULT_PROTECTION_LEVEL is OPTIGA_COMMS_NO_PROTECTION in optiga_lib_config_mtb.h). The key itself never travels on the wire, but the digest and the signature do. Infineon offers a Shielded Connection feature for cases where you need to guard against tapping this wire.

Worked example

Here is a signature made with a key inside the chip, taken from Infineon’s example (example_optiga_crypt_ecdsa_sign.c @ release-v5.3.0, lines 80–93, © 2021-2024 Infineon Technologies AG, MIT). The board’s SDK uses this version of the host library, per the proj_cm55/deps/optiga-trust-m.mtb file.

/* SPDX-FileCopyrightText: 2021-2024 Infineon Technologies AG
 * SPDX-License-Identifier: MIT */
        /**
         * 2. Sign the digest using Private key from Key Store ID E0F0
         */
        optiga_lib_status = OPTIGA_LIB_BUSY;
        return_status = optiga_crypt_ecdsa_sign(
            me,
            digest,
            sizeof(digest),
            OPTIGA_KEY_ID_E0F0,
            signature,
            &signature_length
        );

        WAIT_AND_CHECK_STATUS(return_status, optiga_lib_status);

Reading it piece by piece:

digest is the 32-byte SHA-256 of the data — the signature is over the digest, not over the raw data
OPTIGA_KEY_ID_E0F0 is the key’s slot name, not the key itself — at no point does the key appear in the MCU’s RAM
signature is the result that comes out — it is public data; anyone can verify it with the public key
This call is asynchronous: it returns immediately, and the real result arrives through a callback that sets optiga_lib_status, with WAIT_AND_CHECK_STATUS waiting for that value to stop being OPTIGA_LIB_BUSY. We will come back to this in lesson 2.2, on why you must hold the chip’s access gate for the whole wait.

In the board’s firmware, the same job lives in trustm_ecdsa_sign(), which TLS calls when building CertificateVerify (lesson 3.1).

Practice

Pick one tool per scenario, and say which property it provides. This is the rubric for objective 1 — you need at least 4 of 5 correct.

The platform sends the device a new certificate, and the device must be sure it really came from the platform, not from someone else. ____
You need to keep the CA’s “fingerprint” in a document, so someone else can compare it against the certificate the server sends. ____
A temperature reading crossing a coffee shop’s WiFi must not be readable by the person at the next table. ____
Two sensors from the same company already share a secret key, and need to know a message was not altered in transit. ____
A device and a server need to end up with a shared AES key, without ever sending that key across the network. ____

Solution

A digital signature gives integrity and authentication — this is the basis of Protected Update in lesson 4.2
A hash (SHA-256) — a fingerprint needs no key, because the trust comes from the channel through which you obtained this value (a document you already trust)
Symmetric encryption, e.g. AES inside TLS, gives confidentiality
A MAC (HMAC) — once you already share a key, a MAC is faster than a signature, but it cannot be proved to a third party
Key agreement (ECDHE) — gives a shared key without sending it, but needs a signature alongside it, otherwise you might agree a key with an attacker in the middle

Check your understanding

The questions below are part of the full set in quiz.yaml, which the automated grader uses.

Why does the signature-verification function in 02_model_signature_hook.c not return “passed,” even when the file trailer’s CRC is correct? (objective 1)
- a) Because CRC is too slow
- b) Because anyone can recompute a CRC — it tells you the data was not corrupted in transit, but not who wrote it
- c) Because CRC needs a secret key
- d) Because CRC only works on already-encrypted data
Solution

b. Verifying who created something needs a key. Without a key-based check, returning “passed” is lying about having verified it.
The factory certificate in slot 0xE0E0 has subject CN=InfineonIoTNode on every chip. Which conclusion is correct? (objective 2)
- a) This certificate can tell you which device it is
- b) This certificate is definitely forged
- c) This certificate proves it is a genuine Trust M, but you need the serial number or public key to tell devices apart
- d) This certificate has no public key
Solution

c. The only fields that differ per chip are the serial number and the public key. To bind a permission to a specific device, bind it to those two values, not to the subject.
Which of these describes something the OPTIGA™ Trust M does not protect against? (objective 3)
- a) Reading out the private key to copy it
- b) A key being used to sign something by firmware that has already been compromised, while the attacker still controls the board
- c) Desoldering the flash chip to read the key
- d) Recovering the key from a firmware image file
Solution

b. The chip does whatever the connected MCU tells it to. It prevents the key from being stolen, but it has no way to know whether the MCU itself has been compromised.
In the mbedTLS configuration for CM33_NS at commit ef72c1b, will the device reject an expired server certificate? (objective 2)
- a) It always rejects it
- b) No, not for date reasons, because MBEDTLS_HAVE_TIME_DATE is disabled
- c) Only rejects it if there is a CRL
- d) It depends on the broker
Solution

b. This configuration disables checking a certificate’s validity period, and disables CRL parsing too. It must be recorded as a remaining risk.

Lab

Read a real certificate, make a real signature. Write down every result in your learning log.

1. Capture the chain. Save the certificates the broker sends into a file.

openssl s_client -connect mqtt.tesaiot.dev:8884 -servername mqtt.tesaiot.dev -showcerts </dev/null 2>/dev/null \
  | awk '/BEGIN CERT/,/END CERT/' > chain.pem
csplit -s -z -f cert chain.pem '/-----BEGIN CERTIFICATE-----/' '{*}'

2. Read the four fields of each certificate (cert00, cert01), and fill in a table of subject, issuer, notBefore, notAfter and key algorithm.
Terminal window
```
openssl x509 -in cert00 -noout -subject -issuer -dates
openssl x509 -in cert00 -noout -text | grep -A1 'Public Key Algorithm'
```
3. Compare against the firmware’s trust anchor. Compute the SHA-256 fingerprint of the intermediate certificate, and compare it against the value e3ff5011703755b697227a17945837b7b43616a060d14b37995b62c24e0d7e98 that the SDK records in tesaiot_config_defaults.h as the value of the CA pinned in tesaiot_root_ca.h.
Terminal window
```
openssl x509 -in cert01 -noout -fingerprint -sha256
```
Do they match? And was your guess in “See it work first” correct?

4. Hash vs. MAC. Change one character in a message and see how much the result changes. Then try an HMAC with a test key.

printf 'temp=25.0' | openssl dgst -sha256
printf 'temp=25.1' | openssl dgst -sha256
printf 'temp=25.0' | openssl dgst -sha256 -hmac lab-key-not-a-secret

5. Signature. Generate a P-256 key pair on your computer, sign, verify, then change the message and verify again.

printf 'temp=25.0' > msg.txt
openssl ecparam -name prime256v1 -genkey -noout -out lab_key.pem
openssl ec -in lab_key.pem -pubout -out lab_pub.pem
openssl dgst -sha256 -sign lab_key.pem -out msg.sig msg.txt
openssl dgst -sha256 -verify lab_pub.pem -signature msg.sig msg.txt
printf 'temp=99.9' > msg.txt
openssl dgst -sha256 -verify lab_pub.pem -signature msg.sig msg.txt

The first check must say Verified OK; the second must say Verification failure.

6. Ask yourself. The file lab_key.pem sits on your disk. Anyone who can copy this file could sign anything in your place. Write two or three sentences on how the OPTIGA™ Trust M changes this on the board, and what risk still remains. Then delete the test key file.

Going further

We have seen how the chip lets a key stay put without ever coming out. The next lesson opens up the real chip on the TESAIoT Dev Kit — what objects live inside it, what the metadata tells you, and which commands change the chip in ways that cannot be undone.

Next lesson: Lesson 2.1: What the secure element does for us

Reflect

In past work, have you ever used a hash or a CRC where you actually needed authentication?
If your device does not know the current date, how would you handle an expired certificate?
Who in your organisation can access the firmware image file, and if the key lives inside it, how many people could effectively “become your device”?

References

Review questions

Answer on your own first, then open the answer.

Why does the signature hook in 02_model_signature_hook.c not return "verified" even when the trailer CRC is correct? (Objective 1)
1. เพราะ CRC ช้าเกินไป
2. เพราะใครก็คำนวณ CRC ใหม่ได้ มันบอกว่าข้อมูลไม่เสียระหว่างทาง แต่ไม่บอกว่าใครเขียน
3. เพราะ CRC ต้องใช้กุญแจลับ
4. เพราะ CRC ใช้ได้กับข้อมูลที่เข้ารหัสแล้วเท่านั้น
Show answer

Answer: B. เพราะใครก็คำนวณ CRC ใหม่ได้ มันบอกว่าข้อมูลไม่เสียระหว่างทาง แต่ไม่บอกว่าใครเขียน

การยืนยันว่าใครเป็นผู้สร้างต้องอาศัยกุญแจ ถ้าไม่มีการตรวจด้วยกุญแจ การคืน "ผ่าน" คือการอ้างว่าตรวจแล้วทั้งที่ยังไม่ได้ตรวจ
A device and a server must share an AES key without sending the key over the network. Which primitive fits? (Objective 1)
1. hash SHA-256
2. HMAC
3. การตกลงกุญแจแบบ ECDHE ที่มีลายเซ็นกำกับ
4. CRC32
Show answer

Answer: C. การตกลงกุญแจแบบ ECDHE ที่มีลายเซ็นกำกับ

ECDHE ให้กุญแจร่วมโดยไม่ส่งกุญแจ แต่ต้องมีลายเซ็นกำกับเพื่อรู้ว่าตกลงกับใคร นี่คือส่วน ECDHE ในชื่อ ciphersuite ของ TLS
The factory certificate in slot 0xE0E0 has subject CN=InfineonIoTNode on every chip. Which conclusion is right? (Objective 2)
1. ใบนี้บอกได้ว่าเป็นอุปกรณ์เครื่องไหน
2. ใบนี้ปลอมแน่นอน
3. ใบนี้พิสูจน์ว่าเป็น Trust M ของแท้ แต่ถ้าจะแยกเครื่องต้องใช้ serial หรือกุญแจสาธารณะ
4. ใบนี้ไม่มีกุญแจสาธารณะ
Show answer

Answer: C. ใบนี้พิสูจน์ว่าเป็น Trust M ของแท้ แต่ถ้าจะแยกเครื่องต้องใช้ serial หรือกุญแจสาธารณะ

ตามบท C4 ของเอกสาร SDK ฟิลด์ที่ต่างกันต่อชิปมีแค่ serial กับกุญแจสาธารณะ การผูกสิทธิ์กับเครื่องต้องผูกกับสองค่านี้ ไม่ใช่กับ subject
With the CM33_NS mbedTLS configuration at commit ef72c1b, does the device reject an expired server certificate? (Objective 2)
1. ปฏิเสธเสมอ
2. ไม่ปฏิเสธด้วยเหตุผลเรื่องวันที่ เพราะ MBEDTLS_HAVE_TIME_DATE ถูกปิด
3. ปฏิเสธเฉพาะเมื่อมี CRL
4. ขึ้นกับ broker
Show answer

Answer: B. ไม่ปฏิเสธด้วยเหตุผลเรื่องวันที่ เพราะ MBEDTLS_HAVE_TIME_DATE ถูกปิด

ค่าตั้งนี้ปิดการตรวจช่วงเวลาของใบ X.509 และปิดการ parse CRL จึงต้องบันทึกเป็นความเสี่ยงที่ยังเหลือใน threat model
Which of these does OPTIGA™ Trust M not protect against? (Objective 3)
1. การอ่านกุญแจลับออกมาทำสำเนา
2. การใช้กุญแจลงนามโดยเฟิร์มแวร์ที่ถูกยึดไปแล้ว ขณะที่ผู้โจมตียังคุมบอร์ดอยู่
3. การถอดชิป flash ไปอ่านกุญแจ
4. การค้นหากุญแจในไฟล์ image ของเฟิร์มแวร์
Show answer

Answer: B. การใช้กุญแจลงนามโดยเฟิร์มแวร์ที่ถูกยึดไปแล้ว ขณะที่ผู้โจมตียังคุมบอร์ดอยู่

ชิปทำตามคำสั่งของ MCU ที่ต่ออยู่ มันกันการขโมยและโคลนกุญแจ แต่ไม่รู้ว่า MCU ถูกยึดหรือไม่

Cite this lesson

If you teach from this lesson or reuse it in slides or documents, credit it with the text below. If you changed it, add (adapted) after the title.

"Crypto basics for embedded systems" from TESA Open Knowledge by the Thai Embedded Systems Association (TESA), https://github.com/tesaiot/tesa-qualification-program, licensed under CC BY-NC 4.0

Thai attribution: "พื้นฐานวิทยาการเข้ารหัสสำหรับระบบฝังตัว" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย (Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program สัญญาอนุญาต CC BY-NC 4.0

Lesson link: https://tesaiot.github.io/tesa-qualification-program/en/courses/secure-iot-optiga/m01-threats-and-crypto/l02-crypto-basics/

This lesson adapts the source below; keep its credit too.
https://github.com/tesaiot/tesaiot-pse84-devkit-sdk/tree/ef72c1b658178eee8c38b1e47d28b006f80a59b5 · SDK security examples and docs are linked at this commit; lesson pages quote short excerpts with attribution and copy no files.

Full guide: how to cite TESA

Content is licensed CC BY-NC 4.0. Reuse it non-commercially and credit the Thai Embedded Systems Association (TESA) every time. · How to cite TESA