ข้ามไปยังเนื้อหา
TESA Open Knowledge

งานปลายทาง: อุปกรณ์ที่ปลอดภัยหนึ่งชิ้น

โมดูล 5 · การลงทะเบียนอุปกรณ์อย่างปลอดภัย · ภาพรวมโมดูล · หน้าหลักสูตร

งานชิ้นสุดท้ายไม่ได้วัดว่าอุปกรณ์ “ดูเหมือนทำงาน” แต่วัดว่าคุณ พิสูจน์ ได้ไหมว่ามันทำงานตามที่อ้าง คุณจะส่งอุปกรณ์หนึ่งเครื่องที่ลงทะเบียนแล้ว เชื่อม mTLS ด้วยกุญแจในชิป ส่งข้อมูลขึ้นแพลตฟอร์ม และ threat model ที่อัปเดตตามความจริง

เป้าหมาย

หัวข้อที่มีชื่อว่า “เป้าหมาย”

เมื่อจบบทเรียนนี้ คุณจะ:

  1. ส่งอุปกรณ์ที่ลงทะเบียนแล้ว เชื่อมต่อด้วย mTLS และส่งข้อมูลขึ้นแพลตฟอร์มได้ พร้อม log เป็นหลักฐาน
  2. ปรับ threat model จากโมดูลแรกให้สะท้อนมาตรการที่ทำจริง และระบุความเสี่ยงที่ยังเหลือ

ก่อนเริ่ม

หัวข้อที่มีชื่อว่า “ก่อนเริ่ม”
  • เรียนมาก่อน: ทุกบทเรียนในหลักสูตรนี้ โดยเฉพาะแล็บของ 3.1, 3.2 และ 5.1
  • ไฟล์ที่ต้องมี: threat model ของคุณจาก บทเรียน 1.1 และแม่แบบรายงาน resources/evidence-checklist.md
  • อุปกรณ์: TESAIoT Dev Kit ที่ลงทะเบียนบน TESAIoT Platform แล้ว มีไฟล์ตั้งค่าที่เชื่อมต่อได้ และแม่แบบของ SDK ที่ apply patch ครบ (บทเรียน 3.1)
  • การอนุมัติ: การลงทะเบียนจริงสร้างกุญแจใหม่ในชิป และ Protected Update ทำให้ตัวนับ version ขึ้นถาวร ทั้งสองอย่างต้องได้รับอนุญาตจากผู้สอนก่อน งานนี้ ไม่มีขั้นใดเขียน metadata tag C0 ถ้าค่า C0 ของช่องใดเปลี่ยนไประหว่างงาน ให้หยุดและรายงานทันที

ดูของจริงก่อน

หัวข้อที่มีชื่อว่า “ดูของจริงก่อน”

ตลอดหลักสูตรเราเจอกรณีเดียวกันซ้ำหลายครั้ง บรรทัดที่ดูเหมือนสำเร็จ ไม่ได้แปลว่าสำเร็จ

  • [PSA-Sign] Using Key OID ... พิมพ์ ก่อน การลงนาม (บทเรียน 3.1)
  • tesaiot_mqtt_publish() คืน true แปลว่า เข้าคิว ไม่ใช่ถึง broker (บทเรียน 3.2)
  • tesaiot_publish_protected_update() คืน 0 แปลว่า ขอแล้ว ไม่ใช่เสร็จแล้ว (บทเรียน 4.2)
  • ฟังก์ชัน ota_verify_firmware() คืน OTA_OK โดยไม่ได้ตรวจอะไรเลย (บทเรียน 4.2)

ถามตัวเองก่อนเริ่ม: สำหรับแต่ละข้อข้างบน หลักฐานที่ ถูก คืออะไร และได้มาจากฝั่งไหน

แนวคิด

หัวข้อที่มีชื่อว่า “แนวคิด”

หลักฐานในงานนี้มีสี่ชนิด เรียงจากอ่อนไปแข็ง

  1. ข้อความที่อุปกรณ์พิมพ์ ใช้ได้เมื่อรู้ว่าบรรทัดนั้นพิมพ์ตอนไหน และมีบรรทัด error ที่ต้อง ไม่ ปรากฏประกอบ
  2. สถานะที่อ่านกลับจากชิป เช่น metadata ของ 0xE0E1 ก่อนและหลัง ชิปตอบตามความจริงไม่ว่า host จะพิมพ์อะไร
  3. หลักฐานจากฝั่งผู้รับ เช่นข้อมูลที่ไปถึงผู้ subscribe หรือสิ่งที่แพลตฟอร์มบันทึก
  4. การทดสอบด้านลบ กรณีที่ ควรล้ม และล้มจริง เช่นพอร์ต mTLS ปฏิเสธ client ที่ไม่มีใบรับรอง มาตรการที่ไม่เคยถูกทดสอบให้ล้ม ยังไม่ได้พิสูจน์อะไร

และหลักฐานต้อง ไม่รั่ว ห้ามแนบรหัสผ่าน MQTT รหัส WiFi หรือไฟล์ใน bundle ลงรายงาน log ของเฟิร์มแวร์ถูกออกแบบให้พิมพ์แค่ความยาวของรหัสอยู่แล้ว (PassLen, passphrase=N byte(s)) ถ้ารายงานจะเผยแพร่ ให้แทน device_id และ UID ของชิปด้วยค่าที่ปิดบางส่วน

threat model ที่อัปเดตแล้วต้องบอกตรง ๆ ว่าอะไรยังไม่ได้ป้องกัน หลักสูตรนี้เจอความเสี่ยงที่ยังเหลือของแม่แบบที่ commit ef72c1b อย่างน้อยเท่านี้

ความเสี่ยงที่ยังเหลือ มาจากบทเรียน
ชิปกันการขโมยกุญแจ แต่กันเฟิร์มแวร์ที่ถูกยึดไม่ให้สั่งลงนามไม่ได้ 1.2
อุปกรณ์ไม่ตรวจวันหมดอายุและการเพิกถอนของใบรับรอง (MBEDTLS_HAVE_TIME_DATE และ CRL ปิดอยู่) 1.2
สาย I2C ระหว่าง MCU กับชิปไม่ได้เข้ารหัสในค่าตั้งเริ่มต้น 1.2
TLS 1.2 ส่งใบรับรองของอุปกรณ์แบบไม่เข้ารหัสใน handshake 3.1
ถ้าใช้ใบจากโรงงาน ตัวตนผูกกับอุปกรณ์ได้ด้วย ACL ฝั่ง broker เท่านั้น 3.1
ไฟล์ตั้งค่าบน LittleFS ที่มีรหัส WiFi ไม่ได้ระบุว่าเข้ารหัส 3.2
ห่วงโซ่ secure boot ในแม่แบบครอบแค่ CM33_S และเปิดเฉพาะเมื่อ provision แล้ว 4.1
OTA client ตัวอย่างยังไม่ตรวจ hash และลายเซ็นของเฟิร์มแวร์ 4.2

ตัวอย่างสมบูรณ์

หัวข้อที่มีชื่อว่า “ตัวอย่างสมบูรณ์”

นี่คือตัวอย่างการกรอกตารางหลักฐานหนึ่งแถว สำหรับข้อ “เชื่อม mTLS ด้วยตัวตนที่ลงทะเบียนแล้ว” ค่าในวงเล็บแหลมคือของจริงจากบอร์ดคุณ

ข้ออ้าง หลักฐานบวก หลักฐานลบ ชนิด
อุปกรณ์เชื่อม broker ด้วย mTLS และชิปเป็นผู้ลงนามด้วยกุญแจของ TESAIoT UART: [mTLS] device pair verified — using TESAIoT identity, [PSA-Sign] Using Key OID 0xE0F1 ..., [MQTT] Connected to broker ภายในการเชื่อมต่อเดียวกัน ไม่มีบรรทัด [PSA-Sign] ERROR: trustm_ecdsa_sign status=... · จากคอมพิวเตอร์ openssl s_client ที่พอร์ต 8883 โดยไม่มีใบของ client ถูกปฏิเสธด้วย alert 1 และ 4

สังเกตว่าหลักฐานบวกมีสามบรรทัด เพราะบรรทัดเดียวไม่พอ (บทเรียน 3.1) และหลักฐานลบพิสูจน์ว่าพอร์ตนั้นต้องการใบรับรองจริง ไม่ใช่ปล่อยทุกคนเข้า แถวอื่นในแม่แบบ resources/evidence-checklist.md ใช้รูปแบบเดียวกัน

ฝึกเติม

หัวข้อที่มีชื่อว่า “ฝึกเติม”

จัดแต่ละข้อว่าเป็นหลักฐานชนิดไหน (1 ข้อความจากอุปกรณ์ · 2 สถานะจากชิป · 3 ฝั่งผู้รับ · 4 การทดสอบด้านลบ) หรือ ไม่ใช่หลักฐาน

  1. mosquitto_sub ที่ subscribe ไว้ก่อน ได้รับ payload ที่อุปกรณ์ publish ____
  2. optiga.read_metadata(0xE0E1) ก่อนและหลัง Protected Update ได้ D0 เปลี่ยนเป็นค่าที่ระบุ anchor และ C0 เท่าเดิม ____
  3. tesaiot_mqtt_publish() คืน true ____
  4. การต่อพอร์ต 8884 โดยไม่ใส่ CA ได้ Verify return code: 20 ____
  5. ภาพถ่ายหน้าจอที่ขึ้น “The device can prove it holds the key this certificate names” ____
เฉลย
  1. 3 ฝั่งผู้รับ
  2. 2 สถานะจากชิป ชิปตอบตามจริงเสมอ
  3. ไม่ใช่หลักฐาน ว่าข้อมูลถึง แปลแค่ว่าเข้าคิว
  4. 4 การทดสอบด้านลบ พิสูจน์ว่าการตรวจใบของเซิร์ฟเวอร์ต้องมี anchor ที่ถูก
  5. 1 ข้อความจากอุปกรณ์ ประโยคนี้มาจาก prov_say() หลังการตรวจคู่ใบกับกุญแจ มีน้ำหนักเมื่อแนบ log บน UART ของรอบเดียวกันด้วย

เช็กความเข้าใจ

หัวข้อที่มีชื่อว่า “เช็กความเข้าใจ”

คำถามข้างล่างเป็นส่วนหนึ่งของชุดเต็มใน quiz.yaml ซึ่งระบบตรวจอัตโนมัติใช้

  1. หลักฐานชุดใดพอจะอ้างว่า “ชิปลงนาม CertificateVerify สำเร็จด้วยกุญแจที่ลงทะเบียนแล้ว” (เป้าหมายข้อ 1)

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

    ข ตามเกณฑ์ของบท C4 ที่เราใช้ในบทเรียน 3.1

  2. ข้อใดควรอยู่ในช่อง “ความเสี่ยงที่ยังเหลือ” ของ threat model หลังทำงานนี้เสร็จ (เป้าหมายข้อ 2)

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

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

  3. ทำไมต้องมีการทดสอบด้านลบในรายงาน (เป้าหมายข้อ 2)

    • ก) เพื่อให้รายงานยาวขึ้น
    • ข) เพราะมาตรการที่ไม่เคยถูกทดสอบให้ล้ม อาจผ่านทุกครั้งไม่ว่ามันจะทำงานหรือไม่
    • ค) เพราะแพลตฟอร์มบังคับ
    • ง) เพราะการทดสอบด้านบวกผิดเสมอ
    เฉลย

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

แล็บ

หัวข้อที่มีชื่อว่า “แล็บ”

ส่งอุปกรณ์หนึ่งชิ้นพร้อมรายงานหลักฐาน ใช้เวลาราว 55 นาที กรอก resources/evidence-checklist.md ไปพร้อมกัน

  • 1. สถานะเริ่มต้น (mtb-mpy) อ่าน metadata ของ 0xE0E1 จดค่า tag C0 และ D0 ถ้า C0 ไม่ใช่ 01 หยุดและแจ้งผู้สอน บน mtb-only ให้บันทึกว่าข้ามขั้นนี้และเหตุผล
  • 2. ลงทะเบียน (ผู้สอนอนุญาตแล้ว) HSM Security → Enrol Certificate ในโหมดที่เชื่อมต่อได้อยู่ เก็บประโยคบนจอและบรรทัด UART ตามแล็บเสริมของบทเรียน 5.1 ผลตัดสินต้องเป็น “The device can prove it holds the key this certificate names”
  • 3. เปลี่ยนเป็น mTLS ตั้ง tls_mode=mtls แล้วเชื่อมต่อใหม่ เก็บ log ตั้งแต่ [MQTT] Waiting for WiFi... จนถึง [MQTT] Connected to broker แล้วตัดสินด้วยเกณฑ์สามข้อของบทเรียน 3.1
  • 4. ส่งข้อมูลและพิสูจน์ว่าถึง publish telemetry แล้วเก็บหลักฐานฝั่งผู้รับตามแล็บ 3.2 ข้อ 4 ระบุให้ชัดว่าหลักฐานมาจากไหน
  • 5. การทดสอบด้านลบอย่างน้อยสองข้อ เช่น พอร์ต 8883 ปฏิเสธ client ที่ไม่มีใบ (แล็บ 3.1 ข้อ 3) การตรวจเซิร์ฟเวอร์ล้มเมื่อไม่มี anchor (แล็บ 3.1 ข้อ 4) หรือ SECURE_BOOT=yes ถูกระบบ build ปฏิเสธ (แล็บ 4.1 ข้อ 2)
  • 6. Protected Update (ถ้าผู้สอนอนุญาต) ทำตามแล็บเสริมของบทเรียน 4.2 เก็บ metadata ก่อนและหลัง และผลของการเชื่อมต่อใหม่ที่ต้องเห็นบรรทัด Ignoring a Protected Update bundle nobody asked for ถ้ามี bundle ถูกส่งมา
  • 7. สถานะสุดท้าย อ่าน metadata ของ 0xE0E1 อีกครั้ง C0 ต้องเท่ากับข้อ 1
  • 8. อัปเดต threat model ของบทเรียน 1.1 ทุกแถว STRIDE ต้องมีสถานะ (ยังไม่ทำ / ทำแล้ว / ทดสอบผ่าน) ตาราง ETSI ต้องมีหลักฐานหรือเหตุผล และช่องความเสี่ยงที่เหลือต้องมีอย่างน้อยสามข้อจากตารางในหัวข้อแนวคิด พร้อมแผนหนึ่งบรรทัดต่อข้อ
  • 9. ตรวจการรั่ว ค้นรายงานและไฟล์แนบทั้งหมดว่าไม่มีรหัสผ่าน ไม่มีไฟล์จาก bundle และไม่มีกุญแจลับ ก่อนส่ง

เกณฑ์ผ่าน ทุกข้ออ้างในรายงานมีหลักฐานอย่างน้อยหนึ่งชนิดจากสี่ชนิด ข้อ 3 และ 4 มีหลักฐานครบ มีการทดสอบด้านลบอย่างน้อยสองข้อ และ threat model มีความเสี่ยงที่เหลือพร้อมแผน

ไปต่อ

หัวข้อที่มีชื่อว่า “ไปต่อ”

คุณผ่านหลักสูตร Secure IoT กับ OPTIGA™ Trust M แล้ว ทางที่ไปต่อได้

  • ปิดช่องว่างของแม่แบบในงานของคุณเอง เช่นเติมการตรวจใน OTA client (บทเรียน 4.2) หรือออกแบบให้ CM33_S ตรวจ image ถัดไป (บทเรียน 4.1)
  • อ่าน AN237849 Getting started with PSOC™ Edge security ก่อนวางแผน provision secure boot ให้ผลิตภัณฑ์จริง
  • ทบทวนเส้นทางเชื่อมต่อทั้งโมดูลใน TESAIoT Firmware Stack โมดูล 5 และลองตัวอย่างบน TESAIoT Developer Hub

กลับไปที่ หน้าหลักสูตร

สะท้อนคิด

หัวข้อที่มีชื่อว่า “สะท้อนคิด”
  • ข้ออ้างไหนในรายงานของคุณที่หาหลักฐานยากที่สุด และเพราะอะไร
  • ความเสี่ยงที่เหลือข้อไหนที่คุณจะรับไว้ได้ในผลิตภัณฑ์จริง และข้อไหนรับไม่ได้
  • ถ้าต้องอธิบายงานนี้ให้ผู้บริหารที่ไม่ใช่วิศวกรฟังในสองนาที คุณจะพูดว่าอะไร

แหล่งอ้างอิง

หัวข้อที่มีชื่อว่า “แหล่งอ้างอิง”

คำถามทบทวน

ลองตอบเองก่อน แล้วค่อยเปิดดูเฉลย

  1. หลักฐานชุดใดพอจะอ้างว่า "ชิปลงนาม CertificateVerify สำเร็จด้วยกุญแจที่ลงทะเบียนแล้ว" (เป้าหมายข้อ 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
    ดูเฉลย

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

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

  2. ข้อใดเป็นหลักฐานว่า telemetry ไปถึงจริง (เป้าหมายข้อ 1)

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

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

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

  3. ข้อใดควรอยู่ในช่องความเสี่ยงที่ยังเหลือของ threat model หลังทำงานนี้เสร็จ (เป้าหมายข้อ 2)

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

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

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

  4. ทำไมต้องมีการทดสอบด้านลบในรายงาน (เป้าหมายข้อ 2)

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

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

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

อ้างอิงบทเรียนนี้

ถ้านำบทเรียนนี้ไปสอน ทำสไลด์ หรือทำเอกสารต่อ ให้อ้างอิงด้วยข้อความนี้ ถ้าดัดแปลงเนื้อหา ให้เติม (ดัดแปลง)ต่อท้ายชื่อบทเรียน

"งานปลายทาง: อุปกรณ์ที่ปลอดภัยหนึ่งชิ้น" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย (Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program สัญญาอนุญาต CC BY-NC 4.0

ข้อความอ้างอิงภาษาอังกฤษ: "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

ลิงก์บทเรียน: https://tesaiot.github.io/tesa-qualification-program/courses/secure-iot-optiga/m05-provisioning/l03-capstone-secure-device/

บทเรียนนี้ดัดแปลงจากต้นฉบับด้านล่าง เมื่ออ้างอิงให้คงเครดิตต้นฉบับไว้ด้วย
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.

วิธีอ้างอิง TESA ฉบับเต็ม

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

เนื้อหาเผยแพร่ภายใต้ CC BY-NC 4.0 นำไปใช้ต่อในงานที่ไม่ใช่เพื่อการค้าได้ โปรดอ้างอิงสมาคมสมองกลฝังตัวไทย (TESA) ทุกครั้ง · วิธีอ้างอิง TESA