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

เป้าหมาย

งานชิ้นสุดท้ายไม่ได้วัดว่าอุปกรณ์ "ดูเหมือนทำงาน" แต่วัดว่าคุณ พิสูจน์ ได้ไหมว่ามันทำงานตามที่อ้าง

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

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

ก่อนเริ่ม

• เรียนมาก่อน: ทุกบทเรียนในหลักสูตรนี้ โดยเฉพาะแล็บของ 3.1, 3.2 และ 5.1
• ไฟล์ที่ต้องมี: threat model จาก บทเรียน 1.1 และ resources/evidence-checklist.md
• การอนุมัติ การลงทะเบียนจริงสร้างกุญแจใหม่ในชิป และ Protected Update ทำให้ตัวนับ version ขึ้นถาวร — ทั้งสองต้องได้รับอนุญาตจากผู้สอนก่อน งานนี้ ไม่มีขั้นใดเขียน metadata tag 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) — หลักฐานสี่ชนิด เรียงจากอ่อนไปแข็ง

1. ข้อความที่อุปกรณ์พิมพ์    ใช้ได้เมื่อรู้ว่าพิมพ์ตอนไหน และไม่มีบรรทัด error ประกอบ
2. สถานะที่อ่านกลับจากชิป    เช่น metadata ก่อน/หลัง ชิปตอบตามจริงเสมอ
3. หลักฐานจากฝั่งผู้รับ      เช่นข้อมูลที่ subscriber ได้รับ
4. การทดสอบด้านลบ           กรณีที่ควรล้ม และล้มจริง

มาตรการที่ไม่เคยถูกทดสอบให้ล้ม ยังไม่ได้พิสูจน์อะไร

หลักฐานต้อง ไม่รั่ว — ห้ามแนบรหัสผ่าน MQTT, รหัส WiFi, หรือไฟล์ใน bundle ลงรายงาน ถ้าจะเผยแพร่ ให้แทน device_id/UID ด้วยค่าที่ปิดบางส่วน

แนวคิด (2) — ความเสี่ยงที่ยังเหลือของแม่แบบ (commit ef72c1b)

threat model ที่อัปเดตแล้วต้องบอกตรง ๆ ว่าอะไรยังไม่ได้ป้องกัน

ตัวอย่างสมบูรณ์ — หนึ่งแถวของตารางหลักฐาน

หลักฐานบวกมีสามบรรทัด เพราะบรรทัดเดียวไม่พอ (3.1) หลักฐานลบพิสูจน์ว่าพอร์ตนั้นต้องการใบรับรองจริง ไม่ใช่ปล่อยทุกคนเข้า

ฝึกเติม / แล็บ

ฝึกเติม จัดชนิดหลักฐาน: mosquitto_sub ได้รับ payload → 3 (ผู้รับ) · read_metadata ก่อน/หลัง PU → 2 (ชิป) · tesaiot_mqtt_publish() คืน true → ไม่ใช่หลักฐาน · พอร์ต 8884 ไม่ใส่ CA ได้ Verify return code: 20 → 4 (ด้านลบ)

แล็บ (~55 นาที) สถานะเริ่มต้น (อ่าน C0/D0) → ลงทะเบียน (ผู้สอนอนุญาต) → เปลี่ยนเป็น mTLS เก็บ log เต็ม → publish+พิสูจน์ว่าถึง → การทดสอบด้านลบ ≥2 ข้อ → Protected Update (ถ้าอนุญาต) → สถานะสุดท้าย (C0 ต้องเท่าข้อ 1) → อัปเดต threat model → ตรวจการรั่วก่อนส่ง

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

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

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

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

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

3. ทำไมต้องมีการทดสอบด้านลบในรายงาน

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

ไปต่อ

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

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