บทเรียน 1.1 — Threat model ของอุปกรณ์ IoT

เป้าหมาย

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

1. ระบุทรัพย์สินที่ต้องปกป้องของอุปกรณ์ IoT หนึ่งชิ้นได้อย่างน้อยสี่รายการ
2. จัดภัยคุกคามตามหมวด STRIDE และจับคู่แต่ละภัยกับมาตรการป้องกันที่ตรวจได้
3. เทียบ threat model ของตัวเองกับข้อกำหนดพื้นฐานของ ETSI EN 303 645 และระบุข้อที่ยังขาด

ก่อนเริ่ม

• รู้: ภาษา C ระดับอ่านโค้ดคนอื่นออก และหลักการ publish/subscribe ของ MQTT
• อุปกรณ์: บทนี้เป็นงานคิดบนกระดาษเป็นหลัก บอร์ดยังไม่ต้องเสียบ
• แม่แบบ: resources/threat-model-template.md — งานชิ้นนี้จะกลับมาอีกครั้งในบทเรียน 5.3

อุปกรณ์ตัวอย่างของหลักสูตร คือเฟิร์มแวร์แม่แบบ bento-firmware-template-mtb-only บน TESAIoT Dev Kit ที่เชื่อม MQTTS ไปยัง mqtt.tesaiot.dev — server-TLS (พอร์ต 8884) หรือ mTLS (พอร์ต 8883)

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

[MQTT] Waiting for WiFi...
[MQTT-Config] Mode=%d, Broker=%s:%u, Client=%s, User=%s, PassLen=%u
[MQTT] Connecting to '%s:%u' as '%s'...
[MQTT] Connected to broker

สังเกตบรรทัด [MQTT-Config] — มันพิมพ์ชื่อผู้ใช้ แต่พิมพ์รหัสผ่านเป็นแค่ ความยาว (PassLen) เพราะ console ไม่ใช่วิทยุ และมักเป็นจอที่คนอื่นมองเห็นด้วย

แปลว่าคนเขียนเฟิร์มแวร์ได้ทำ threat model ไปแล้วอย่างน้อยหนึ่งข้อ — นับสาย UART เป็นช่องทางรั่วไหล ก่อนอ่านต่อ เขียนห้าอย่างที่ผู้โจมตีอยากได้จากบอร์ดนี้

แนวคิด (1) — ทรัพย์สินและผู้โจมตี

ผู้โจมตีสี่แบบ ผู้โจมตีทางเครือข่าย · คนที่ถือบอร์ดได้ (USB/I2C) · อุปกรณ์อื่นที่ถูกเจาะแล้ว · คนในที่เข้าถึง broker

แนวคิด (2) — ขอบเขตความเชื่อใจ

            [เซนเซอร์บนบอร์ด]
                   │ I2C
 [CM55: จอและสัมผัส] ──IPC── [CM33_NS: WiFi, MQTT] ──I2C── [OPTIGA Trust M]
                                    │
 ═══════ ขอบเขต: อากาศ ═════════════╪═══════════════════════════════
                                    │ WiFi
                             [access point] ── internet ── [broker] ── [Platform]
 ═══════ ขอบเขต: คนที่ถือบอร์ด ═══════════════════════════════════
   พอร์ต USB/KitProg (debug, flash) · สาย I2C ที่วัดได้บนบอร์ด

ทุกจุดที่ข้ามเส้นคือจุดที่ต้องถามว่า "อีกฝั่งเป็นใคร และเรารู้ได้อย่างไร"

แนวคิด (3) — STRIDE: หกคำถามที่ถามทุกขอบเขต

หมวดหนึ่งอาจว่างได้ แต่ต้องว่างเพราะคิดแล้ว ไม่ใช่เพราะลืมถาม

แนวคิด (4) — มาตรการที่ตรวจได้ และเส้นฐาน ETSI

"เราใช้ TLS" ไม่ใช่มาตรการที่ตรวจได้ — มันเป็นแค่ชื่อเทคโนโลยี มาตรการที่ตรวจได้ต้องบอก การทดสอบที่ทำให้ผลออกมาเป็นแดงได้ เช่น "ชี้ broker ไปเซิร์ฟเวอร์ที่ใช้ใบ self-signed แล้วอุปกรณ์ต้องตัดการเชื่อมต่อก่อนส่ง MQTT CONNECT"

เทียบกับ ETSI EN 303 645 — ตัวอย่างข้อที่เกี่ยวกับโหนดเซนเซอร์โดยตรง

ตัวอย่างสมบูรณ์ — threat model หนึ่งหน้า (บางส่วน)

ขอบเขต TESAIoT Dev Kit หนึ่งเครื่อง เฟิร์มแวร์แม่แบบ mtb-only ที่ ef72c1b

ช่องว่างเมื่อเทียบ ETSI เช่น 5.1-2A (server-TLS ใช้รหัสผ่าน), 5.3-10 (c_ota_client มีฟิลด์ตรวจแต่ฟังก์ชันยังเป็น TODO ที่คืนผ่านเสมอ)

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

ฝึกเติม จัดภัยห้าข้อเข้าหมวด STRIDE พร้อมการทดสอบที่ตรวจได้ เช่น "มีคนส่งข้อความ commands/... ปลอมมาสั่งอุปกรณ์" (S/T), "publish ถี่จนคิวเต็ม ข้อมูลหาย" (D)

แล็บ threat model หนึ่งหน้าของอุปกรณ์ของคุณ

1. เลือกอุปกรณ์หนึ่งชิ้น เขียนขอบเขตในหนึ่งย่อหน้า
2. วาดแผนภาพขอบเขตความเชื่อใจ (อย่างน้อยเส้นอากาศและเส้นคนถือบอร์ด)
3. ระบุทรัพย์สินอย่างน้อยสี่รายการ พร้อมสมบัติที่ต้องรักษา (C, I, A)
4. เดิน STRIDE ครบหกหมวด ได้ภัยอย่างน้อยหกข้อ ทุกข้อมีการทดสอบที่ผลเป็นแดงได้
5. เทียบกับ ETSI เขียนช่องว่างอย่างน้อยสองข้อ

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

1. ข้อใดเป็น ทรัพย์สิน ที่ต้องรักษาความถูกต้องเป็นหลัก ไม่ใช่ความลับ

   • ก) รหัส WiFi ในที่เก็บข้อมูลรับรอง · ข) trust anchor ใน tesaiot_root_ca.h · ค) กุญแจลับในช่อง 0xE0F1 · ง) รหัสผ่าน MQTT ในโหมด server-TLS

2. "อุปกรณ์ใช้ TLS 1.2" เป็นมาตรการที่ตรวจได้หรือไม่

   • ก) ได้ เพราะ TLS 1.2 เป็นมาตรฐาน · ข) ไม่ได้ ต้องเขียนเป็นการทดสอบที่ผลเป็นแดงได้ · ค) ได้ ถ้า log ขึ้น Connected to broker · ง) ไม่ได้ เพราะ TLS ไม่เกี่ยวกับ STRIDE

3. คุณพบภัย "ผู้โจมตีส่งคำสั่งปลอมเข้าหัวข้อ commands" ควรจัดเป็นหมวดใดเป็นหลัก

   • ก) Denial of service · ข) Spoofing · ค) Information disclosure · ง) Repudiation

ไปต่อ

ในตารางตัวอย่าง มาตรการเกือบทุกข้อพึ่ง hash ลายเซ็น การเข้ารหัส หรือใบรับรอง บทต่อไป บทเรียน 1.2: พื้นฐานวิทยาการเข้ารหัสสำหรับระบบฝังตัว จะแยกเครื่องมือเหล่านี้ให้ชัด