บทเรียน 4.1 — Secure boot และ chain of trust

เป้าหมาย

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

1. อธิบายบทบาทของคอร์ CM33_S ในการบูตแบบปลอดภัยของแม่แบบเฟิร์มแวร์
2. วาดห่วงโซ่ความเชื่อใจตั้งแต่ ROM จนถึงแอปพลิเคชัน และระบุว่าลายเซ็นถูกตรวจที่ขั้นใด
3. อธิบายความต่างระหว่าง secure boot กับการเข้ารหัสเฟิร์มแวร์

ก่อนเริ่ม

• เรียนมาก่อน: บทเรียน 3.2, ลายเซ็น บทเรียน 1.2
• ซอฟต์แวร์: แม่แบบของ SDK ที่ ef72c1b build ได้แล้ว

บทนี้จะไม่ให้ทำ provision secure_boot=true หรือโอนความเป็นเจ้าของด้วยกุญแจ OEM — งานนี้เปลี่ยนอุปกรณ์ระดับชิป ต้องทำตาม AN237849 โดยคนที่ตัดสินใจแล้วและดูแลกุญแจ OEM ได้

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

proj_cm33_s/main.c ยาวไม่ถึงห้าสิบบรรทัด — หัวไฟล์ "CM33 Secure boot - TrustZone setup and jump to CM33_NS" มีแค่ cybsp_init(), เปิด interrupt, อ่าน stack pointer/reset handler จากตาราง vector ของ CM33_NS แล้วกระโดดไปที่นั่น

ทายก่อน ก่อนกระโดด CM33_S ตรวจลายเซ็นของเฟิร์มแวร์ CM33_NS หรือไม่ ถ้าไม่ตรวจ ใครตรวจอะไร

แนวคิด (1) — บทบาทของ CM33_S

PSoC™ Edge E84 มีสามคอร์ (proj_cm33_s, proj_cm33_ns, proj_cm55) — Extended Boot เปิด CM33 secure จากตำแหน่งคงที่ → CM33 secure เปิด CM33 non-secure → CM33 non-secure เปิด CM55

CM33_S คือ image แรกของผู้ใช้ที่ Extended Boot เห็น และเป็นข้อต่อเดียวที่ Extended Boot ตรวจลายเซ็นได้

สวิตช์ SECURE_BOOT ใน common.mk

• SECURE_BOOT=0 (ค่าเริ่มต้น) — image CM33_S ได้แค่หัว MCUboot ไม่ได้ลงนาม
• SECURE_BOOT=1 — CM33_S ถูกลงนามด้วยกุญแจ OEM root of trust

ค่าอื่นนอกจาก 0/1 (เช่น true, yes) ทำให้ build หยุดด้วย error — ค่าที่พิมพ์ผิดต้องไม่กลายเป็น build ที่ไม่ได้ลงนามแบบเงียบ ๆ

แนวคิด (2) — ห่วงโซ่ความเชื่อใจของบอร์ดนี้

 Boot ROM (Infineon) → Extended Boot (Infineon)
    │  ตรวจลายเซ็นของ image CM33_S ด้วยกุญแจ OEM
    │  ✔ เมื่อ provision secure_boot=true และ build SECURE_BOOT=1
    │  ✘ ในสภาพเริ่มต้นของแม่แบบ (SECURE_BOOT=0)
    ▼
 CM33_S   cybsp_init() แล้วกระโดดไป reset handler ของ CM33_NS
    │  ✘ ไม่ตรวจลายเซ็นของ CM33_NS
    ▼
 CM33_NS  FreeRTOS, PSA+OPTIGA driver, WiFi, MQTT แล้ว Cy_SysEnableCM55()
    │  ✘ ไม่ตรวจลายเซ็นของ CM55
    ▼
 CM55     จอ, Edge AI (โมเดลตรวจผ่าน hook ที่ยังเป็น weak function คืน "ตรวจไม่ได้")

ข้อสรุปที่ต้องเขียนลง threat model ต่อให้เปิด secure boot ครบ ห่วงโซ่ในแม่แบบนี้ก็ขาดหลัง CM33_S — ใครเขียน flash ของ CM33_NS หรือ CM55 ได้ จะรันโค้ดของตัวเองได้โดยไม่มีใครตรวจ

แนวคิด (3) — secure boot ≠ การเข้ารหัสเฟิร์มแวร์

แม่แบบนี้ไม่มีขั้นเข้ารหัส image — เปิด secure boot แล้วใครอ่าน flash ได้ก็ยังอ่านโค้ดได้

ยังไม่นับเป็นมาตรการกันย้อนรุ่น config แบบลงนามใส่ security-counter=1 (รูปแบบ MCUboot สำหรับกันย้อนรุ่น) แต่เอกสารที่หลักสูตรนี้ตรวจไม่ได้ยืนยันว่า Extended Boot บังคับใช้เลขนี้อย่างไร — บทเรียน 4.2 มีการกันย้อนรุ่นที่ยืนยันได้ในชิป OPTIGA™

ตัวอย่างสมบูรณ์ — ความต่างของสอง config

// Identical to boot_with_extended_boot.json except the CM33_S sign stage
// additionally carries "signing-key" + "security-counter", which turn the
// MCUboot metadata into a real OEM signature that Extended Boot verifies
// once the device is provisioned secure_boot=true.

อ่านแล้วตอบได้สามข้อ

1. ต่างจากแบบไม่ลงนามแค่สองฟิลด์: "signing-key" กับ "security-counter"
2. ลายเซ็นมีความหมายเมื่ออุปกรณ์ provision แล้วเท่านั้น — บอร์ดที่ยังไม่ provision secure_boot=true ไม่ได้ตรวจลายเซ็นนี้
3. ผู้เขียนออกแบบให้ "ล้มแบบมีเสียง" — ไม่ส่งกุญแจ = build error ไม่ใช่ image ไม่ได้ลงนามเงียบ ๆ

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

ฝึกเติม จัดข้อความว่าเป็นจริงกับ secure boot / การเข้ารหัส / ทั้งสอง / ไม่ใช่ทั้งสอง: กันบั๊ก buffer overflow ในโค้ดที่ลงนามถูกต้อง → ไม่ใช่ทั้งสอง (ลายเซ็นบอกแค่ว่ามาจากใคร) · กันการเปลี่ยนเฟิร์มแวร์ CM55 แม้เปิด SECURE_BOOT=1 แล้ว → ไม่ใช่ทั้งสอง (ลายเซ็นครอบแค่ CM33_S)

แล็บ diff สอง config ไฟล์ นับฟิลด์ที่ต่าง · สั่ง make build SECURE_BOOT=yes ดู error (ทำไม "ล้ม" จึงเป็นเรื่องดี) · วาดห่วงโซ่สองแบบ (บอร์ดตอนนี้ vs ผลิตภัณฑ์ที่เปิด secure boot ครบ) · อัปเดต threat model บทเรียน 1.1

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

1. ใน proj_cm33_s/main.c ของแม่แบบ CM33_S ทำอะไรก่อนเปิด CM33_NS

   • ก) ตรวจลายเซ็นของ CM33_NS ด้วย OPTIGA™ Trust M · ข) cybsp_init() แล้วอ่าน stack pointer และ reset handler จากตาราง vector แล้วกระโดดไป · ค) ถอดรหัส image ของ CM33_NS · ง) เชื่อมต่อ WiFi

2. build ด้วย SECURE_BOOT=1 แล้ว flash ลงบอร์ดที่ ยังไม่ provision secure_boot=true ผลคืออะไร

   • ก) บอร์ดไม่บูต · ข) Extended Boot ยังไม่ได้บังคับตรวจลายเซ็น การมีลายเซ็นจึงยังไม่ได้เพิ่มการป้องกัน · ค) ชิป OPTIGA ถูกล็อก · ง) LcsO เปลี่ยนเป็น operational

3. ข้อใดอธิบายความต่างของ secure boot กับการเข้ารหัสเฟิร์มแวร์ได้ถูก

   • ก) secure boot ซ่อนโค้ด การเข้ารหัสยืนยันว่าใครเขียน · ข) secure boot ยืนยันว่าโค้ดมาจากเจ้าของกุญแจและไม่ถูกแก้ การเข้ารหัสทำให้คนอื่นอ่านโค้ดไม่ได้ · ค) ทั้งสองอย่างเหมือนกัน · ง) secure boot ต้องใช้กุญแจลับบนอุปกรณ์

ไปต่อ

secure boot ตอบเรื่องเฟิร์มแวร์ตอนเปิดเครื่อง แต่ข้อมูลบางอย่างในชิป เช่นใบรับรองของอุปกรณ์ ต้องเปลี่ยนได้ตลอดอายุการใช้งาน บทต่อไปดูว่า OPTIGA™ Trust M รับการเปลี่ยนแปลงนั้นอย่างไรโดยไม่เชื่อ host

บทเรียนถัดไป: บทเรียน 4.2: Protected Update