Skip to content
TESA Open Knowledge

Capstone: one secure device

Module 5 · Secure device provisioning · Module overview · Course home

This final piece of work does not measure whether the device “looks like it works” — it measures whether you can prove it works as claimed. You will deliver one device that is enrolled, connects over mTLS with a key inside the chip, publishes to the platform, and comes with a threat model updated to match reality.

Objectives

Section titled “Objectives”

By the end of this lesson you will:

  1. Deliver an enrolled device that connects over mTLS and publishes to the platform, with logs as evidence
  2. Update the threat model from the first module to reflect the mitigations you actually implemented, and list the risks that remain

Before you start

Section titled “Before you start”
  • Already covered: every lesson in this course, especially the labs of 3.1, 3.2 and 5.1
  • Files you need: your threat model from lesson 1.1, and the report template resources/evidence-checklist.md
  • Device: a TESAIoT Dev Kit already registered on the TESAIoT Platform, with a config file that can connect, and the SDK’s template with every patch applied (lesson 3.1)
  • Approval: real enrolment creates a new key inside the chip, and a Protected Update permanently advances the version counter. Both need the instructor’s permission first. No step in this task writes metadata tag C0. If any slot’s C0 value changes during this work, stop and report it immediately.

See it work first

Section titled “See it work first”

Throughout this course we have met the same pattern again and again: a line that looks like success does not mean success.

  • [PSA-Sign] Using Key OID ... is printed before the signature happens (lesson 3.1)
  • tesaiot_mqtt_publish() returning true means queued, not delivered to the broker (lesson 3.2)
  • tesaiot_publish_protected_update() returning 0 means requested, not done (lesson 4.2)
  • The function ota_verify_firmware() returns OTA_OK without checking anything at all (lesson 4.2)

Ask yourself before you start: for each item above, what would count as correct evidence, and which side would it come from?

Concepts

Section titled “Concepts”

This task’s evidence comes in four kinds, from weakest to strongest.

  1. A message the device prints. Useful once you know exactly when that line is printed, and only alongside confirming that an accompanying error line does not appear.
  2. State read back from the chip, such as 0xE0E1’s metadata before and after. The chip answers truthfully no matter what the host prints.
  3. Evidence from the receiving side, such as data that reaches a subscriber, or what the platform itself records.
  4. A negative test — a case that should fail, and really does. For example, the mTLS port refusing a client with no certificate. A mitigation that has never been tested to fail has proven nothing.

And evidence must never leak. Never attach an MQTT password, a WiFi password, or a bundle file to your report. The firmware’s logs are already designed to print only a password’s length (PassLen, passphrase=N byte(s)). If your report will be shared, replace the device_id and the chip’s UID with partially masked values.

Your updated threat model must state plainly what is still unprotected. This course has already found at least this many remaining risks in the template at commit ef72c1b.

Remaining risk From lesson
The chip prevents a key from being stolen, but not from being used to sign by firmware that has already been compromised 1.2
The device does not check a certificate’s expiry or revocation (MBEDTLS_HAVE_TIME_DATE and CRL are disabled) 1.2
The I2C wire between the MCU and the chip is not encrypted by default 1.2
TLS 1.2 sends the device’s certificate unencrypted during the handshake 3.1
If using the factory certificate, identity is bound to the device only by the broker’s ACL 3.1
The config file on LittleFS, which carries the WiFi password, is never stated to be encrypted 3.2
The template’s secure boot chain covers only CM33_S, and only once provisioned 4.1
The example OTA client still does not verify a firmware image’s hash or signature 4.2

Worked example

Section titled “Worked example”

Here is a sample of how one row of the evidence table could be filled in, for the claim “connects with mTLS using an enrolled identity.” Values in angle brackets are your board’s real values.

Claim Positive evidence Negative evidence Kind
The device connects to the broker with mTLS, and the chip is the one signing with TESAIoT’s key UART: [mTLS] device pair verified — using TESAIoT identity, [PSA-Sign] Using Key OID 0xE0F1 ..., [MQTT] Connected to broker, all within the same connection No [PSA-Sign] ERROR: trustm_ecdsa_sign status=... line · from a computer, openssl s_client on port 8883 with no client certificate gets refused with an alert 1 and 4

Notice the positive evidence has three lines, because one line is not enough (lesson 3.1), and the negative evidence proves the port really requires a genuine certificate, rather than letting everyone in. Other rows in the resources/evidence-checklist.md template follow the same pattern.

Practice

Section titled “Practice”

Classify each item by evidence kind (1 a device message · 2 chip state · 3 the receiving side · 4 a negative test), or mark it not evidence.

  1. mosquitto_sub, already subscribed beforehand, receives the payload the device published ____
  2. optiga.read_metadata(0xE0E1) before and after a Protected Update shows D0 changed to the value naming the anchor, and C0 unchanged ____
  3. tesaiot_mqtt_publish() returns true ____
  4. Connecting to port 8884 without a CA gets Verify return code: 20 ____
  5. A screenshot showing “The device can prove it holds the key this certificate names” ____
Solution
  1. 3, the receiving side
  2. 2, chip state — the chip always answers truthfully
  3. Not evidence that the data arrived — it only means it was queued
  4. 4, a negative test — it proves that verifying the server’s certificate requires the correct anchor
  5. 1, a device message. This sentence comes from prov_say() after checking that the certificate matches the key. It carries more weight if paired with the UART log from the same run.

Check your understanding

Section titled “Check your understanding”

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

  1. Which set of evidence is enough to claim “the chip successfully signed CertificateVerify with the enrolled key”? (objective 1)

    • a) The line [PSA-Sign] Using Key OID 0xE0F1 alone
    • b) The device pair verified line, the Using Key OID 0xE0F1 line, no ERROR line from trustm_ecdsa_sign, and [MQTT] Connected to broker, all in the same connection
    • c) The screen shows connected
    • d) tesaiot_mqtt_connect() returns true
    Solution

    b. Per the criteria from chapter C4 that we used in lesson 3.1.

  2. Which of these belongs in the “remaining risk” section of the threat model after finishing this task? (objective 2)

    • a) None, because mTLS is already in use
    • b) The secure boot chain covers only CM33_S, and the device does not check a certificate’s expiry
    • c) The private key lives in flash
    • d) The MQTT password is printed on the console
    Solution

    b. Items c and d are not true of a device that follows this course. Item a is threat modelling with your eyes closed — mTLS does not fix every provision.

  3. Why must a report include negative tests? (objective 2)

    • a) To make the report longer
    • b) Because a mitigation that has never been tested to fail might pass every time whether it works or not
    • c) Because the platform requires it
    • d) Because positive tests are always wrong
    Solution

    b. This is the same principle as “a verifiable mitigation” from lesson 1.1 — a test must be able to go red.

Lab

Section titled “Lab”

Deliver one device with an evidence report. This takes about 55 minutes; fill in resources/evidence-checklist.md as you go.

  • 1. Starting state. (mtb-mpy) Read 0xE0E1’s metadata, and record tags C0 and D0. If C0 is not 01, stop and tell your instructor. On mtb-only, record that you skipped this step and why.
  • 2. Enrol. (once the instructor has approved) HSM Security → Enrol Certificate, in whichever mode currently connects. Keep the on-screen sentences and the UART lines, per lesson 5.1’s optional lab. The verdict must be “The device can prove it holds the key this certificate names.”
  • 3. Switch to mTLS. Set tls_mode=mtls and reconnect. Keep the log from [MQTT] Waiting for WiFi... through to [MQTT] Connected to broker, then judge it against lesson 3.1’s three criteria.
  • 4. Publish, and prove it arrived. Publish telemetry, then collect evidence from the receiving side, per lab 3.2 step 4. State clearly where the evidence came from.
  • 5. At least two negative tests. For example: port 8883 refusing a client with no certificate (lab 3.1 step 3), server verification failing with no anchor (lab 3.1 step 4), or SECURE_BOOT=yes being refused by the build system (lab 4.1 step 2).
  • 6. Protected Update (if your instructor allows it). Follow lesson 4.2’s optional lab, keep the metadata before and after, and the result of reconnecting, which must show the line Ignoring a Protected Update bundle nobody asked for if any bundle gets sent.
  • 7. Final state. Read 0xE0E1’s metadata once more; C0 must equal step 1’s value.
  • 8. Update the threat model from lesson 1.1. Every STRIDE row needs a status (not done / done / tested and passed). The ETSI table needs evidence or a reason for each row. The remaining-risk section must have at least three items from the Concepts table, each with one line of plan.
  • 9. Check for leaks. Search your whole report and every attachment for passwords, bundle files, or a private key, before submitting.

Pass criteria: every claim in the report carries at least one of the four evidence kinds; steps 3 and 4 each carry a complete set; at least two negative tests are present; and the threat model lists remaining risks, each with a plan.

Going further

Section titled “Going further”

You have completed the Secure IoT with OPTIGA™ Trust M course. Ways to go further:

Back to the course home

Reflect

Section titled “Reflect”
  • Which claim in your report was hardest to find evidence for, and why?
  • Which remaining risk would you accept in a real product, and which would you not?
  • If you had two minutes to explain this task to a non-engineer executive, what would you say?

References

Section titled “References”

Review questions

Answer on your own first, then open the answer.

  1. Which evidence is enough to claim "the chip signed CertificateVerify with the enrolled key"? (Objective 1)

    1. บรรทัด [PSA-Sign] Using Key OID 0xE0F1 อย่างเดียว
    2. บรรทัด device pair verified, บรรทัด Using Key OID 0xE0F1, ไม่มีบรรทัด ERROR ของ trustm_ecdsa_sign และ [MQTT] Connected to broker ในการเชื่อมต่อเดียวกัน
    3. หน้าจอขึ้นว่าเชื่อมต่อแล้ว
    4. tesaiot_mqtt_connect() คืน true
    Show answer

    Answer: B. บรรทัด device pair verified, บรรทัด Using Key OID 0xE0F1, ไม่มีบรรทัด ERROR ของ trustm_ecdsa_sign และ [MQTT] Connected to broker ในการเชื่อมต่อเดียวกัน

    ตามเกณฑ์ของบท C4 ที่ใช้ในบทเรียน 3.1 บรรทัด Using Key OID พิมพ์ก่อนการลงนาม จึงต้องมีบรรทัดอื่นประกอบ

  2. Which item is evidence that telemetry actually arrived? (Objective 1)

    1. tesaiot_mqtt_publish() คืน true
    2. ผู้ subscribe ที่เชื่อมต่อไว้ก่อน ได้รับ payload ที่อุปกรณ์ publish
    3. บรรทัด [Publisher] Published to บน UART
    4. ไฟ LED บนบอร์ดกะพริบ
    Show answer

    Answer: B. ผู้ subscribe ที่เชื่อมต่อไว้ก่อน ได้รับ payload ที่อุปกรณ์ publish

    true แปลแค่ว่าเข้าคิว และบท C3 บอกว่าบรรทัด [Publisher] Published to ถูกปิดไว้ หลักฐานต้องมาจากฝั่งผู้รับ

  3. Which item belongs in the remaining-risk section of the threat model after this capstone? (Objective 2)

    1. ไม่มี เพราะใช้ mTLS แล้ว
    2. ห่วงโซ่ secure boot ครอบแค่ CM33_S และอุปกรณ์ไม่ตรวจวันหมดอายุของใบรับรอง
    3. กุญแจลับอยู่ใน flash
    4. รหัสผ่าน MQTT ถูกพิมพ์บน console
    Show answer

    Answer: B. ห่วงโซ่ secure boot ครอบแค่ CM33_S และอุปกรณ์ไม่ตรวจวันหมดอายุของใบรับรอง

    ข้อ ค และ ง ไม่จริงในอุปกรณ์ที่ทำตามหลักสูตร ข้อ ก คือการทำ threat model แบบปิดตา

  4. Why must the report include negative tests? (Objective 2)

    1. เพื่อให้รายงานยาวขึ้น
    2. เพราะมาตรการที่ไม่เคยถูกทดสอบให้ล้ม อาจผ่านทุกครั้งไม่ว่ามันจะทำงานหรือไม่
    3. เพราะแพลตฟอร์มบังคับ
    4. เพราะการทดสอบด้านบวกผิดเสมอ
    Show answer

    Answer: B. เพราะมาตรการที่ไม่เคยถูกทดสอบให้ล้ม อาจผ่านทุกครั้งไม่ว่ามันจะทำงานหรือไม่

    หลักเดียวกับมาตรการที่ตรวจได้ในบทเรียน 1.1 การทดสอบต้องทำให้ผลเป็นแดงได้

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.

"Capstone: one secure device" 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/m05-provisioning/l03-capstone-secure-device/

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

TESA Open Knowledge · © 2026 สมาคมสมองกลฝังตัวไทย (TESA) · CC BY-NC 4.0

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