Threat model ของอุปกรณ์ IoT

หลักสูตร: Secure IoT กับ OPTIGA™ Trust M · Threat model และพื้นฐานวิทยาการเข้ารหัส
ระดับ: L3 ทำได้เอง
เวลาโดยประมาณ: 70 นาที (แนวคิด 20 · ฝึก 20 · แล็บ 25 · เช็กความเข้าใจ 5)
อุปกรณ์: Dev Kit
ทักษะที่ฝึก: พื้นฐานความปลอดภัยระบบฝังตัว ถึง L3
การแก้ปัญหาและการคิดเชิงวิพากษ์ ถึง L2
ควรเรียนก่อน: ไม่มี
สถานะ: ทดลองใช้ (alpha)

วิดีโอประกอบ

ดูบน YouTube (เปิดในแท็บใหม่)

TESAIoT Security Essentials สมาคมสมองกลฝังตัวไทย (TESA)

วิดีโอโดย สมาคมสมองกลฝังตัวไทย (TESA) · ดูทั้งชุดใน playlist AIoT Foundation

โมดูล 1 · Threat model และพื้นฐานวิทยาการเข้ารหัส · ภาพรวมโมดูล · หน้าหลักสูตร

ก่อนแตะชิปความปลอดภัยสักคำสั่ง เราจะนั่งคิดแบบผู้โจมตีกับอุปกรณ์หนึ่งชิ้นให้จบก่อน บทเรียนนี้ใช้โหนดเซนเซอร์บน TESAIoT Dev Kit ที่ส่งข้อมูลขึ้น TESAIoT Platform ผ่าน MQTTS เป็นตัวอย่างตลอดทั้งหลักสูตร

เป้าหมาย

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

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

ก่อนเริ่ม

รู้มาก่อน: ภาษา C ระดับอ่านโค้ดคนอื่นออก และหลักการ publish/subscribe ของ MQTT ถ้ายังไม่เคยส่งข้อมูลขึ้นแพลตฟอร์มเลย อ่าน บทเรียน 5.1 ของหลักสูตร TESAIoT Firmware Stack ก่อนก็ได้
อุปกรณ์: บทนี้เป็นงานคิดบนกระดาษเป็นหลัก บอร์ดยังไม่ต้องเสียบ แต่ถ้ามี TESAIoT Dev Kit อยู่ในมือ การหยิบขึ้นมาดูพอร์ตและสายจะช่วยให้นึกออกว่าผู้โจมตีเข้าถึงอะไรได้บ้าง
แม่แบบ: ดาวน์โหลด resources/threat-model-template.md ไว้กรอกในแล็บ งานชิ้นนี้จะกลับมาอีกครั้งในบทเรียนปลายทาง 5.3

อุปกรณ์ตัวอย่างของหลักสูตร คือเฟิร์มแวร์แม่แบบ bento-firmware-template-mtb-only ใน TESAIoT PSE84 Dev Kit SDK (commit ef72c1b) ที่ทำงานบน TESAIoT Dev Kit มันอ่านค่าเซนเซอร์บนบอร์ด ต่อ WiFi ด้วยข้อมูลรับรองจากที่เก็บในบอร์ด แล้วเชื่อม MQTTS ไปที่ mqtt.tesaiot.dev ส่งข้อมูลขึ้นหัวข้อ device/<device_id>/telemetry และ subscribe คำสั่งที่ device/<device_id>/commands/# การเชื่อมต่อมีสองโหมดหลัก คือ server-TLS (อุปกรณ์ยืนยันตัวด้วยชื่อผู้ใช้และรหัสผ่าน ที่พอร์ต 8884) และ mTLS (อุปกรณ์ยืนยันตัวด้วยกุญแจใน OPTIGA™ Trust M ที่พอร์ต 8883) ข้อเท็จจริงเหล่านี้มาจากบท C3 ของเอกสาร SDK

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

นี่คือบรรทัดที่เฟิร์มแวร์พิมพ์ออก UART ตอนเชื่อมต่อแพลตฟอร์ม (ข้อความตามซอร์สในบท C3 ค่าจริงแทนที่ %s %u)

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

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

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

แนวคิด

1. ทรัพย์สิน ผู้โจมตี และขอบเขตความเชื่อใจ

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

ทรัพย์สิน คือสิ่งที่ถ้าเสียความลับ (confidentiality) เสียความถูกต้อง (integrity) หรือใช้งานไม่ได้ (availability) แล้วมีคนเดือดร้อน ของโหนดเซนเซอร์เรามีอย่างน้อยเท่านี้

ทรัพย์สิน	อยู่ที่ไหนบนโหนดนี้	สมบัติที่ต้องรักษา
กุญแจลับของตัวตนอุปกรณ์	ใน OPTIGA™ Trust M ช่อง `0xE0F0` (กุญแจจากโรงงาน) และ `0xE0F1` (กุญแจของ TESAIoT)	ความลับ และต้องไม่มีใครเอาไปใช้แทนเราได้
ใบรับรองและ `device_id`	ช่อง `0xE0E1` ในชิป และไฟล์ตั้งค่า `/.tesaiot_config`	ความถูกต้อง
trust anchor ที่ใช้ตรวจเซิร์ฟเวอร์	`tesaiot_root_ca.h` ที่คอมไพล์ติดเฟิร์มแวร์	ความถูกต้อง ถ้าถูกเปลี่ยน อุปกรณ์จะเชื่อเซิร์ฟเวอร์ปลอม
รหัส WiFi และรหัสผ่าน MQTT (โหมด server-TLS)	ที่เก็บข้อมูลรับรองบน LittleFS และ `tesaiot_config_store`	ความลับ
เฟิร์มแวร์ของทั้งสามคอร์	หน่วยความจำ flash	ความถูกต้อง
telemetry	ระหว่างทางไป broker	ความถูกต้อง และความลับถ้างานต้องการ
คำสั่งจากแพลตฟอร์ม	หัวข้อ `device/<device_id>/commands/#`	ความถูกต้อง และต้องรู้ว่ามาจากใคร
การทำงานต่อเนื่อง	ทั้งระบบ	ความพร้อมใช้งาน
สถานะวงจรชีวิตของชิป (LcsO)	metadata tag `C0` ของ object ในชิป	ความถูกต้อง เปลี่ยนได้ทางเดียว ย้อนไม่ได้

ผู้โจมตี ที่เราคิดถึงมีสี่แบบ แต่ละแบบเข้าถึงคนละขอบเขต

ผู้โจมตีทางเครือข่าย อยู่ใน WiFi เดียวกันหรือบนเส้นทางอินเทอร์เน็ต ตั้ง access point ปลอมได้ ดักและแก้แพ็กเก็ตได้
คนที่ถือบอร์ดได้ เสียบ USB เข้าพอร์ต debug อ่าน flash หรือดักสาย I2C บนบอร์ดได้
อุปกรณ์อื่นบนแพลตฟอร์มเดียวกันที่ถูกเจาะแล้ว และพยายามทำตัวเป็นอุปกรณ์ของเรา
คนในที่เข้าถึง broker หรือแพลตฟอร์ม

ขอบเขตความเชื่อใจ (trust boundary) คือเส้นที่ข้อมูลข้ามจากฝั่งที่เราควบคุมไปฝั่งที่เราไม่ควบคุม ทุกจุดที่ข้ามเส้นคือจุดที่ต้องถามว่า “อีกฝั่งเป็นใคร และเรารู้ได้อย่างไร”

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

2. STRIDE: หกคำถามที่ถามทุกขอบเขต

STRIDE เป็นตัวช่วยจำหกหมวดของภัย แต่ละหมวดจับคู่กับสมบัติที่ถูกละเมิด ตามตารางของ OWASP Threat Modeling Process

หมวด	ผู้โจมตีทำอะไร	สมบัติที่ต้องมี
Spoofing	ปลอมตัวเป็นคนอื่นหรือเครื่องอื่น	การยืนยันตัวตน (authentication)
Tampering	แก้ข้อมูลที่เก็บไว้หรือกำลังเดินทาง	ความถูกต้อง (integrity)
Repudiation	ทำแล้วปฏิเสธว่าไม่ได้ทำ เพราะระบบตามรอยไม่ได้	การปฏิเสธความรับผิดไม่ได้ (non-repudiation)
Information disclosure	อ่านข้อมูลที่ไม่มีสิทธิ์อ่าน	ความลับ (confidentiality)
Denial of service	ทำให้ใช้งานไม่ได้	ความพร้อมใช้งาน (availability)
Elevation of privilege	ได้สิทธิ์มากกว่าที่ควรได้	การอนุญาต (authorization)

วิธีใช้คือเดินทีละขอบเขตในแผนภาพ แล้วถามหกคำถามนี้ที่ขอบเขตนั้น ได้ภัยมาแล้วจึงเลือกมาตรการ หมวดหนึ่งอาจว่างก็ได้ แต่ต้องว่างเพราะคิดแล้ว ไม่ใช่เพราะลืมถาม

3. มาตรการที่ตรวจได้ และเส้นฐาน ETSI EN 303 645

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

เมื่อได้ threat model แล้ว ให้เทียบกับเส้นฐานของอุตสาหกรรม ETSI EN 303 645 V3.1.3 (2024-09) ข้อ 5 ของมาตรฐานมีสิบสามหมวด ตั้งแต่ 5.1 ห้ามใช้รหัสผ่านเริ่มต้นแบบเดียวกันทุกเครื่อง จนถึง 5.13 ตรวจสอบข้อมูลที่รับเข้า แต่ละข้อย่อยมีสถานะ M (ต้องทำ) หรือ R (ควรทำ) ตามตาราง B.1 ของมาตรฐาน ข้อที่เกี่ยวกับโหนดเซนเซอร์ของเราโดยตรงคือ

ข้อ	สถานะ	ใจความ (ถอดความ)
5.1-2A	R	ไม่ควรใช้รหัสผ่านยืนยันตัวตนระหว่างเครื่องกับเครื่อง
5.3-10	M	ถ้ารับอัปเดตทางเครือข่าย ต้องตรวจความแท้และความถูกต้องของอัปเดตทุกครั้ง
5.4-1	M	ค่าความปลอดภัยที่เก็บถาวรต้องเก็บอย่างปลอดภัย (มาตรฐานยกตัวอย่าง secure element)
5.4-3	M	ห้ามฝังค่าความปลอดภัยสำคัญไว้ในซอร์สโค้ด
5.5-1	M	สื่อสารด้วยวิทยาการเข้ารหัสตามแนวปฏิบัติที่ดี
5.6-4A	M	พอร์ต debug ต้องปิด หรือป้องกันด้วยการยืนยันตัวตน
5.7-1	R	ควรตรวจซอฟต์แวร์ของตัวเองด้วยกลไก secure boot
5.13-1B	M	ข้อมูลที่เข้ามาทางเครือข่ายต้องถูกตรวจก่อนใช้

ข้อไหนที่ threat model ของเราไม่มีมาตรการรองรับ คือ ช่องว่าง ที่ต้องเขียนไว้ตรง ๆ พร้อมเหตุผลหรือแผน

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

นี่คือ threat model หนึ่งหน้าของโหนดเซนเซอร์ในสภาพ วันนี้ คือโหมด server-TLS และ build ปกติของแม่แบบ แต่ละแถวบอกว่าจะตรวจอย่างไร และบทเรียนไหนในหลักสูตรที่ลงลึกเรื่องนั้น

ขอบเขต: TESAIoT Dev Kit หนึ่งเครื่อง เฟิร์มแวร์แม่แบบ mtb-only ที่ ef72c1b เชื่อม mqtt.tesaiot.dev ไม่รวมระบบหลังบ้านของแพลตฟอร์ม

หมวด	ภัยบนโหนดนี้	มาตรการ	ตรวจอย่างไร (ผลที่ต้องเห็น)	ลงลึกที่
S	ผู้โจมตีตั้ง access point ปลอม แล้วทำตัวเป็น broker	ตรวจใบรับรองเซิร์ฟเวอร์กับ CA ที่ปักไว้ใน `tesaiot_root_ca.h`	ชี้ `broker=` ไปเซิร์ฟเวอร์ทดสอบที่ใช้ใบ self-signed ต้องล้มเหลวก่อน MQTT CONNECT	บทเรียน 3.1
S	อุปกรณ์อื่นที่ได้รหัสผ่าน MQTT ของเราไป ทำตัวเป็นเรา	เปลี่ยนเป็น mTLS ที่กุญแจอยู่ในชิป และให้ ACL ของ broker ผูกหัวข้อ `device/{id}/#` กับใบรับรอง	ถอดชิปออกจากบัสแล้วต่อใหม่ ต้องไม่มีกุญแจสำรองใน flash ให้ใช้ (บท C4 Step 3)	บทเรียน 3.1, 3.2
T	เฟิร์มแวร์ถูกเปลี่ยนเป็นตัวที่ไม่ได้ลงนาม	secure boot ของ Extended Boot ตรวจลายเซ็นของ CM33_S	build ด้วยกุญแจอื่นแล้ว flash บอร์ดที่ provision `secure_boot=true` แล้ว ต้องไม่บูต	บทเรียน 4.1
T	ใบรับรองในช่อง `0xE0E1` ถูกเขียนทับ	Protected Update ล็อกช่องให้รับเฉพาะ manifest ที่ลงนามโดย anchor	อ่าน metadata tag `D0` ต้องได้ `21 E0 E8` และการเขียนธรรมดาต้องถูกปฏิเสธ	บทเรียน 4.2
R	มีคนปฏิเสธว่าไม่ได้ขอใบรับรองหรืออัปเดต	ทุกคำขอมี correlation id ที่หาได้ทั้งใน log ของอุปกรณ์และของแพลตฟอร์ม	สุ่มคำขอหนึ่งรายการ ต้องตามรอยได้ครบทั้งสองฝั่ง	บทเรียน 5.1
I	รหัส WiFi หลุดจาก repo หรือจากหน้าจอ console	เก็บในที่เก็บข้อมูลรับรอง ไม่ใช่ `#define` และไม่พิมพ์ passphrase	ค้นทั้ง repo ไม่เจอ SSID หรือรหัส และ log ขึ้น `passphrase=N byte(s), not shown`	บทเรียน 3.2
I	กุญแจลับถูกอ่านออกจาก flash	กุญแจอยู่ใน OPTIGA™ Trust M ซึ่ง metadata ไม่ให้สิทธิ์อ่าน	ค้นใน image ที่ build ไม่เจอกุญแจลับ	บทเรียน 2.1
D	touch กับชิปใช้ I2C พร้อมกันจนธุรกรรมค้าง	touch-hold ครอบทั้งธุรกรรม	เชื่อมต่อซ้ำ 20 รอบ ต้องไม่มี `0x0102` ใน log	บทเรียน 2.2
D	broker ตัด session ที่ 90 วินาที เพราะไม่มี PINGREQ	task ที่วน MQTT loop ต้องยังมีชีวิต (stack พอ)	ปล่อยอุปกรณ์เงียบเกิน 90 วินาที แล้ว publish ยังผ่าน	บทเรียน 3.2
E	คำขอจากเครือข่ายเรียกคำสั่งที่มีความเสี่ยงสูง	trust policy ของ SDK อนุญาตระดับ HTTPS แค่ความเสี่ยง 0 กับ 1	เรียกคำสั่งความเสี่ยงระดับ 2 ผ่าน HTTPS ต้องได้ `refused` (07_trust_policy.c)	—

ช่องว่างเมื่อเทียบกับ ETSI EN 303 645 ในสภาพวันนี้

5.1-2A (R) โหมด server-TLS ยืนยันตัวอุปกรณ์ด้วยรหัสผ่าน ทางแก้คือ mTLS ในโมดูล 3
5.3-10 (M) ตัวอย่าง c_ota_client บน Developer Hub มีฟิลด์ file_hash และ signature ใน job document แต่ฟังก์ชันตรวจยังเป็น TODO ที่คืนผ่านเสมอ (บทเรียน 4.2)
5.7-1 (R) build ปกติใช้ SECURE_BOOT=0 image ของ CM33_S จึงไม่ได้ลงนาม (บทเรียน 4.1)
5.6-4A (M) แม่แบบไม่ได้จัดการเรื่องปิดพอร์ต debug ผลิตภัณฑ์จริงต้องวางแผนเอง
5.2-1 (M) ต้องมีนโยบายรับแจ้งช่องโหว่ที่เผยแพร่ต่อสาธารณะ ข้อนี้เป็นงานขององค์กร เฟิร์มแวร์ช่วยไม่ได้

สังเกตว่าข้อ 5 ไม่ใช่เรื่องโค้ดเลย threat model ที่ดีต้องกล้าเขียนว่าส่วนไหนอยู่นอกขอบเขตของเฟิร์มแวร์

ฝึกเติม

ตารางข้างล่างมีภัยห้าข้อบนโหนดเดียวกัน ให้เติมหมวด STRIDE และเขียนการทดสอบที่ทำให้ผลเป็นแดงได้ ข้อแรกทำให้ดูแล้ว

ภัย	หมวด	การทดสอบที่ตรวจได้
ผู้โจมตีใน WiFi เดียวกันอ่าน payload ของ telemetry	I	ดักแพ็กเก็ตด้วย Wireshark ระหว่าง publish ต้องเห็นเฉพาะ TLS record ไม่เห็นข้อความ JSON
มีคนส่งข้อความ `commands/...` ปลอมมาสั่งอุปกรณ์	____	____
มีคน publish ถี่ ๆ จนคิวของ publisher เต็ม ข้อมูลของเราหาย	____	____
ผู้ใช้ที่มีสิทธิ์อ่านอย่างเดียวบนแพลตฟอร์ม สั่งเขียนเฟิร์มแวร์ได้	____	____
อุปกรณ์ส่งข้อมูลผิดไปแล้วบอกว่าไม่ได้ส่ง	____	____

เฉลย

คำสั่งปลอม: S (และ T) ทดสอบโดยใช้บัญชีของอุปกรณ์อื่น publish เข้า device/<device_id ของเรา>/commands/... แล้ว broker ต้องปฏิเสธ ถ้าผ่าน แปลว่า ACL ไม่ได้ผูกหัวข้อกับตัวตน
คิวเต็ม: D บท C3 บอกว่า tesaiot_mqtt_publish() ใส่คิวแบบรอศูนย์วินาที คิวเต็มแล้วข้อความทิ้งเงียบ ทดสอบโดย publish รัว ๆ แล้วนับว่าที่ปลายทางได้ครบไหม ถ้าไม่ครบต้องมีตัวนับหรือค่าที่คืนมาบอก
สิทธิ์อ่านแต่เขียนได้: E ทดสอบด้วยบัญชีสิทธิ์อ่านอย่างเดียว เรียกคำสั่งเขียนแล้วต้องถูกปฏิเสธ
ส่งแล้วปฏิเสธ: R ทดสอบว่าข้อความหนึ่งรายการตามกลับไปหาตัวตนที่ยืนยันแล้วของผู้ส่งได้ไหม ถ้าใช้รหัสผ่านร่วมกันหลายเครื่อง ข้อนี้จะตกทันที

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

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

ข้อใดเป็น ทรัพย์สิน ที่ต้องรักษาความถูกต้องเป็นหลัก ไม่ใช่ความลับ (เป้าหมายข้อ 1)
- ก) รหัส WiFi ในที่เก็บข้อมูลรับรอง
- ข) trust anchor ใน tesaiot_root_ca.h
- ค) กุญแจลับในช่อง 0xE0F1
- ง) รหัสผ่าน MQTT ในโหมด server-TLS
เฉลย

ข ใบรับรองของ CA เป็นข้อมูลสาธารณะ ใครอ่านก็ได้ แต่ถ้ามีคนเปลี่ยนมันได้ อุปกรณ์จะเชื่อเซิร์ฟเวอร์ปลอมทันที ส่วนอีกสามข้อต้องรักษาความลับ
“อุปกรณ์ใช้ TLS 1.2” เป็นมาตรการที่ตรวจได้หรือไม่ (เป้าหมายข้อ 2)
- ก) ได้ เพราะ TLS 1.2 เป็นมาตรฐาน
- ข) ไม่ได้ ต้องเขียนเป็นการทดสอบที่ผลเป็นแดงได้ เช่น ใบรับรองปลอมต้องทำให้การเชื่อมต่อล้ม
- ค) ได้ ถ้า log ขึ้น Connected to broker
- ง) ไม่ได้ เพราะ TLS ไม่เกี่ยวกับ STRIDE
เฉลย

ข Connected to broker ขึ้นได้แม้การตรวจใบรับรองจะปิดอยู่ การทดสอบที่มีความหมายต้องลองกรณีที่ควรล้ม แล้วเห็นมันล้มจริง
โหมด server-TLS ยืนยันตัวอุปกรณ์ด้วยชื่อผู้ใช้และรหัสผ่าน ขัดกับข้อใดของ ETSI EN 303 645 (เป้าหมายข้อ 3)
- ก) 5.1-2A ไม่ควรใช้รหัสผ่านยืนยันตัวตนระหว่างเครื่องกับเครื่อง
- ข) 5.7-1 secure boot
- ค) 5.13-1B ตรวจข้อมูลที่รับเข้า
- ง) ไม่ขัดข้อใด
เฉลย

ก ข้อนี้มีสถานะ R (ควรทำ) จึงเป็นช่องว่างที่ต้องเขียนเหตุผลหรือแผนไว้ แผนของหลักสูตรนี้คือเปลี่ยนเป็น mTLS
คุณพบภัย “ผู้โจมตีส่งคำสั่งปลอมเข้าหัวข้อ commands” ควรจัดเป็นหมวดใดเป็นหลัก (เป้าหมายข้อ 2)
- ก) Denial of service
- ข) Spoofing
- ค) Information disclosure
- ง) Repudiation
เฉลย

ข ผู้โจมตีปลอมตัวเป็นแพลตฟอร์มหรือผู้มีสิทธิ์สั่ง มาตรการคือการยืนยันตัวตนและ ACL ที่ผูกหัวข้อกับตัวตน

แล็บ

Threat model หนึ่งหน้าของอุปกรณ์ของคุณ ใช้แม่แบบ resources/threat-model-template.md

เลือกอุปกรณ์หนึ่งชิ้น จะเป็นโหนดเซนเซอร์ของหลักสูตร หรือโปรเจกต์ของคุณเองบน TESAIoT Dev Kit ก็ได้ เขียนขอบเขตในหนึ่งย่อหน้า
วาดแผนภาพขอบเขตความเชื่อใจ อย่างน้อยต้องมีเส้นอากาศ (WiFi) และเส้นคนที่ถือบอร์ด
ระบุทรัพย์สินอย่างน้อยสี่รายการ บอกที่อยู่ และสมบัติที่ต้องรักษา (C, I หรือ A)
เดิน STRIDE ครบหกหมวด ได้ภัยอย่างน้อยหกข้อ ทุกข้อมีมาตรการและการทดสอบที่ผลเป็นแดงได้
เทียบกับตาราง ETSI ในหัวข้อแนวคิดข้อ 3 เขียนช่องว่างอย่างน้อยสองข้อ พร้อมสถานะ M หรือ R
แลกกับเพื่อนหนึ่งคน ให้เพื่อนหาภัยที่คุณพลาดหนึ่งข้อ แล้วเพิ่มลงตาราง

เก็บไฟล์นี้ไว้ บทเรียน 5.3 จะให้คุณกลับมาอัปเดตว่ามาตรการไหนทำจริงแล้ว และความเสี่ยงไหนยังเหลือ

ไปต่อ

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

บทเรียนถัดไป: บทเรียน 1.2: พื้นฐานวิทยาการเข้ารหัสสำหรับระบบฝังตัว

สะท้อนคิด

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

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

คำถามทบทวน

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

ข้อใดเป็นทรัพย์สินที่ต้องรักษาความถูกต้องเป็นหลัก ไม่ใช่ความลับ (เป้าหมายข้อ 1)
1. รหัส WiFi ในที่เก็บข้อมูลรับรอง
2. trust anchor ใน tesaiot_root_ca.h
3. กุญแจลับในช่อง 0xE0F1
4. รหัสผ่าน MQTT ในโหมด server-TLS
ดูเฉลย

คำตอบ: B. trust anchor ใน tesaiot_root_ca.h

ใบรับรองของ CA เป็นข้อมูลสาธารณะ แต่ถ้ามีคนเปลี่ยนได้ อุปกรณ์จะเชื่อเซิร์ฟเวอร์ปลอม อีกสามข้อต้องรักษาความลับ
เลือกทุกข้อที่เป็นทรัพย์สินของโหนดเซนเซอร์ในบทเรียนนี้ (เป้าหมายข้อ 1)
1. กุญแจลับของตัวตนอุปกรณ์ในชิป OPTIGA™ Trust M
2. เฟิร์มแวร์ของทั้งสามคอร์
3. สถานะวงจรชีวิตของชิป (metadata tag C0)
4. สีของเคสบอร์ด
5. คำสั่งที่มาทางหัวข้อ device/<device_id>/commands/#
ดูเฉลย

คำตอบ: A. กุญแจลับของตัวตนอุปกรณ์ในชิป OPTIGA™ Trust M · B. เฟิร์มแวร์ของทั้งสามคอร์ · C. สถานะวงจรชีวิตของชิป (metadata tag C0) · E. คำสั่งที่มาทางหัวข้อ device/<device_id>/commands/#

ทรัพย์สินคือสิ่งที่ถ้าเสียความลับ ความถูกต้อง หรือความพร้อมใช้งานแล้วมีคนเดือดร้อน สีเคสไม่เข้าเกณฑ์นี้
"อุปกรณ์ใช้ TLS 1.2" เป็นมาตรการที่ตรวจได้หรือไม่ (เป้าหมายข้อ 2)
1. ได้ เพราะ TLS 1.2 เป็นมาตรฐาน
2. ไม่ได้ ต้องเขียนเป็นการทดสอบที่ผลเป็นแดงได้ เช่น ใบรับรองปลอมต้องทำให้การเชื่อมต่อล้ม
3. ได้ ถ้า log ขึ้น Connected to broker
4. ไม่ได้ เพราะ TLS ไม่เกี่ยวกับ STRIDE
ดูเฉลย

คำตอบ: B. ไม่ได้ ต้องเขียนเป็นการทดสอบที่ผลเป็นแดงได้ เช่น ใบรับรองปลอมต้องทำให้การเชื่อมต่อล้ม

Connected to broker ขึ้นได้แม้การตรวจใบรับรองจะปิดอยู่ การทดสอบที่มีความหมายต้องลองกรณีที่ควรล้มแล้วเห็นมันล้มจริง
ภัย "ผู้โจมตีส่งคำสั่งปลอมเข้าหัวข้อ commands" ควรจัดเป็นหมวด STRIDE ใดเป็นหลัก (เป้าหมายข้อ 2)
1. Denial of service
2. Spoofing
3. Information disclosure
4. Repudiation
ดูเฉลย

คำตอบ: B. Spoofing

ผู้โจมตีปลอมตัวเป็นผู้มีสิทธิ์สั่ง มาตรการคือการยืนยันตัวตนและ ACL ที่ผูกหัวข้อกับตัวตน
โหมด server-TLS ยืนยันตัวอุปกรณ์ด้วยชื่อผู้ใช้และรหัสผ่าน ขัดกับข้อใดของ ETSI EN 303 645 (เป้าหมายข้อ 3)
1. 5.1-2A ไม่ควรใช้รหัสผ่านยืนยันตัวตนระหว่างเครื่องกับเครื่อง
2. 5.7-1 secure boot
3. 5.13-1B ตรวจข้อมูลที่รับเข้า
4. ไม่ขัดข้อใด
ดูเฉลย

คำตอบ: A. 5.1-2A ไม่ควรใช้รหัสผ่านยืนยันตัวตนระหว่างเครื่องกับเครื่อง

ข้อ 5.1-2A มีสถานะ R (ควรทำ) จึงเป็นช่องว่างที่ต้องเขียนเหตุผลหรือแผนไว้ แผนของหลักสูตรนี้คือเปลี่ยนเป็น mTLS

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

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

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

ข้อความอ้างอิงภาษาอังกฤษ: "Threat modelling an IoT 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/m01-threats-and-crypto/l01-threat-modelling/

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

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