บทเรียน 4.2 — Protected Update

เป้าหมาย

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

1. อธิบายขั้นตอนของ Protected Update ตั้งแต่คำขอจนถึงการตรวจ manifest
2. อธิบายหน้าที่ของตัวนับกันย้อนรุ่น และผลของ manifest lock
3. ระบุการเปลี่ยนแปลงบนชิปที่รีแฟลชแล้วก็กู้คืนไม่ได้ ตามที่ตัวอย่างของ SDK เตือนไว้

ก่อนเริ่ม

• เรียนมาก่อน: บทเรียน 4.1 และตาราง metadata ใน บทเรียน 2.1
• Protected Update ในบทนี้คือการอัปเดต object ในชิป (ใบรับรอง กุญแจ metadata) ไม่ใช่การอัปเดตเฟิร์มแวร์ของ MCU

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

[PU-Ingest] STEP 4: Executing OPTIGA Trust M Protected Update
[PU-Ingest] [4.1] Manifest verification OK (Trust Anchor signature valid)
[PU-Ingest] PROTECTED UPDATE COMPLETED SUCCESSFULLY!

ทายก่อน ถ้า host ถูกเจาะ ผู้โจมตีพิมพ์บรรทัดไหนในนี้ปลอมได้บ้าง และอะไรคือหลักฐานที่เขา ปลอมไม่ได้

แนวคิด (1) — จากคำขอถึงการตรวจ manifest ในชิป

OPTIGA™ Trust M ไม่รับใบรับรองที่เขียนเป็นไบต์ธรรมดาลงช่องที่ถูกป้องกัน — ต้องมี manifest ที่ลงนามด้วยกุญแจที่ชิปเชื่ออยู่แล้ว (trust anchor) กับ fragment ที่บรรจุข้อมูลจริง

1. subscribe device/<id>/commands/#  (ก่อนขอเสมอ)
2. tesaiot_publish_protected_update("E0E1","E0E8",ver,with_csr)
   → ตรวจในเครื่องก่อน (ช่องถูกล็อกกับ anchor อื่นอยู่ไหม)
3. เขียนใบของผู้ลงนามลง 0xE0E8 ตั้งชนิดเป็น trust anchor
4. optiga_util_protected_update_start(manifest)
   ▶ ชิปตรวจลายเซ็นของ manifest กับ 0xE0E8   ◀ จุดที่ host ปลอมไม่ได้
5. ส่ง fragment ชิปเขียนช่องเป้าหมาย

คำตอบคำทาย ทุกบรรทัด printf host ที่ถูกเจาะพิมพ์อะไรก็ได้ — เหตุการณ์ที่ปลอมไม่ได้คือ ชิปตรวจลายเซ็นสำเร็จ หลักฐานจริงคืออ่าน metadata กลับมา ไม่ใช่เชื่อ log

แนวคิด (2) — ตัวนับกันย้อนรุ่น และ manifest lock

ตัวนับ version (tag C1) ชิปจำ version ของแต่ละ object และปฏิเสธ manifest ที่ version ไม่มากกว่าเดิม — ขึ้นได้อย่างเดียว กันการเอา manifest เก่าที่ถูกลงนามมาเล่นซ้ำ

manifest lock (tag D0) apply สำเร็จ → Change เป็น 21 E0 E8 → ช่องนั้นรับเฉพาะ manifest ที่ลงนามโดย anchor นั้น — กลับทางได้ตราบที่ LcsO ยังต่ำกว่า op

รหัสผิดพลาดตัวเดียวแปลได้หลายอย่าง 0x800F เกิดได้ทั้งจาก: ช่องถูกล็อกกับ anchor อื่น, version เก่า, หรือช่อง trust anchor ว่าง (กรณีที่พบบ่อยที่สุด) — อย่าเพิ่งสรุปว่าลายเซ็นผิด

กันเล่นซ้ำด้วย correlation id bundle ที่มาถึงตอนไม่มีคำขอค้าง ต้องทิ้ง

แนวคิด (3) — สิ่งที่รีแฟลชแล้วกู้คืนไม่ได้

ยังไม่ได้ทำงานจริง c_ota_client มีฟิลด์ file_hash/signature ใน job document แต่ ota_verify_firmware() ยังเป็น TODO ที่คืน OTA_OK เสมอ — ห้ามนำไปใช้กับอุปกรณ์จริงโดยไม่เติมการตรวจ

เส้นทางอัปเดตผ่าน BLE NUS ต้องยืนยัน Y/N บนจอ แต่คอมไพล์เฉพาะเมื่อ ENABLE_PAGE_BENTO_BUDDY=1 และ ในแม่แบบที่ส่งมอบ ไลบรารีนี้ยังไม่ได้ถูก link เข้าภาพเฟิร์มแวร์

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

#define EXAMPLE_PU_TARGET   "E0E1"   /* hex string, not 0xE0E1 */
#define EXAMPLE_PU_ANCHOR   "E0E8"
/* platform takes max(chip counter, its record, this) + 1 */
#define EXAMPLE_PU_VERSION  (1U)

int rc = tesaiot_publish_protected_update(EXAMPLE_PU_TARGET, EXAMPLE_PU_ANCHOR,
                                          (uint32_t)EXAMPLE_PU_VERSION, false);

ตัวอย่างนี้ ปิดไว้เป็นค่าเริ่มต้น ต้อง build ด้วย DEFINES+=EXAMPLE_HSM_REQUEST_PU=1 — ไม่งั้นพิมพ์แค่แผนของคำขอแล้วข้ามไป (ความตั้งใจ: OID เป้าหมายควรถูกอ่านสองรอบก่อนกด)

เทียบกับบทเรียน 1.2: นี่คือกรณีเดียวกับ hook ตรวจโมเดล AI — ฟังก์ชันที่ชื่อ "verify" ต้องไม่คืนผ่านถ้ายังไม่ได้ตรวจจริง

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

ฝึกเติม ทำนายผล: ช่อง 0xE0E1 ถูกล็อกกับ 0xE0E9 แต่คำขอระบุ anchor E0E8 → (ข) ถูกปฏิเสธในเครื่องก่อนส่งคำขอ · bundle ถูกต้องมาถึงหลังรีบูตตอนไม่มีคำขอค้าง → (ง) เฟิร์มแวร์ทิ้ง bundle

แล็บหลัก (ไม่ส่งจริง) build ตัวอย่าง 06 โดยไม่เปิดสวิตช์ — จดแผนของคำขอที่พิมพ์ วาดแผนภาพลำดับทำเครื่องหมายจุดที่ host ปลอมได้/ชิปตรวจลายเซ็น/ตัวนับเปลี่ยน

แล็บเสริม (ต้องได้รับอนุญาตจากผู้สอน) Protected Update จริง — อ่าน metadata ก่อน/หลัง ถ้า C0 เปลี่ยน หยุดและรายงานทันที

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

1. ในเส้นทาง Protected Update ขั้นไหนที่ host ที่ถูกเจาะปลอมไม่ได้

   • ก) การพิมพ์บรรทัด "PROTECTED UPDATE COMPLETED SUCCESSFULLY!" · ข) การที่ชิปตรวจลายเซ็นของ manifest กับ trust anchor ของตัวเองสำเร็จ แล้วเขียนช่องเป้าหมาย · ค) การส่ง ACK ขึ้นแพลตฟอร์ม · ง) การ subscribe commands/#

2. ตัวนับ version (tag C1) ป้องกันอะไร

   • ก) ป้องกันไม่ให้ manifest ที่ลงนามถูกต้องแต่เป็นรุ่นเก่า ถูกนำมาใช้ซ้ำ · ข) ป้องกันการอ่านใบรับรอง · ค) ป้องกันการเชื่อมต่อ WiFi ซ้ำ · ง) ป้องกันการเขียน tag C0

3. ตามตัวอย่าง 06 การเปลี่ยนแปลงใดบนชิปที่ไม่มี reflash การลบ หรือการตัดไฟใดพากลับได้

   • ก) การเขียนใบรับรองลง 0xE0E1 · ข) การเลื่อน LcsO (metadata tag C0) · ค) การเชื่อมต่อ MQTT · ง) การอ่าน metadata

ไปต่อ

Protected Update ต้องมีใบรับรองของอุปกรณ์อยู่ก่อน หรือส่ง CSR ไปพร้อมคำขอ โมดูลสุดท้ายจะดูการลงทะเบียนด้วย CSR ตั้งแต่สร้างกุญแจในชิปจนได้ใบรับรองกลับมา

บทเรียนถัดไป: บทเรียน 5.1: ลงทะเบียนด้วย CSR