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

เป้าหมาย

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

1. เลือกเครื่องมือเข้ารหัสที่เหมาะกับเป้าหมาย (ความลับ ความถูกต้อง หรือการยืนยันตัวตน) ได้ถูกต้องอย่างน้อย 4 ใน 5 กรณี
2. อ่านใบรับรอง X.509 แล้วระบุ subject, issuer, อายุ และ public key ได้
3. อธิบายว่าทำไมกุญแจลับควรอยู่ในชิปความปลอดภัยแทนหน่วยความจำแฟลชทั่วไป

ก่อนเริ่ม

• เรียนมาก่อน: บทเรียน 1.1 — เปิดตาราง threat model ของคุณไว้ข้าง ๆ
• เครื่องมือ: คอมพิวเตอร์ที่มี openssl
• บอร์ด: ไม่ต้องใช้ในบทนี้ — ทุกการทดลองทำบนคอมพิวเตอร์

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

openssl s_client -connect mqtt.tesaiot.dev:8884 -servername mqtt.tesaiot.dev -showcerts </dev/null

ผลที่ได้มีใบรับรองสองใบ ใบแรก CN = mqtt.tesaiot.dev ออกโดย CN = TESAIoT Intermediate CA ใบที่สองคือ TESAIoT Intermediate CA เอง ออกโดย TESAIoT Root CA

ทายก่อน เฟิร์มแวร์ของบอร์ดมีใบรับรองใบไหนฝังอยู่ในตัวแล้ว — ใบของเซิร์ฟเวอร์ ใบ intermediate หรือใบ root

แนวคิด (1) — สามเป้าหมาย สี่ครอบครัวเครื่องมือ

02_model_signature_hook.c ของ SDK ตรวจ CRC ได้ครบแต่ยังคืน "ตรวจไม่ได้" (-10) ไม่ใช่ "ผ่าน" — hash/CRC ไม่มีกุญแจ ใครก็คำนวณใหม่ทับได้

แนวคิด (2) — ใบรับรอง X.509 และห่วงโซ่ความเชื่อใจ

สี่ฟิลด์ที่ต้องอ่านเป็น subject · issuer · validity (notBefore–notAfter) · subjectPublicKeyInfo

ห่วงโซ่ของ broker: ใบเซิร์ฟเวอร์ ← TESAIoT Intermediate CA ← TESAIoT Root CA — อุปกรณ์เชื่อใบเซิร์ฟเวอร์เพราะเดินลายเซ็นย้อนไปจนเจอใบที่เชื่ออยู่แล้ว (trust anchor)

ใบจากโรงงาน ช่อง 0xE0E0 subject CN=InfineonIoTNode เหมือนกันทุกชิป — พิสูจน์ว่าเป็น Trust M ของแท้ แต่ไม่บอกว่าเป็นเครื่องไหน (serial/public key ต่างกันต่อชิป)

ยังไม่ตรวจ ค่าตั้ง mbedTLS ของ CM33_NS ที่ commit นี้ปิด MBEDTLS_HAVE_TIME_DATE และ MBEDTLS_X509_CRL_PARSE_C — อุปกรณ์ไม่ปฏิเสธใบเพราะหมดอายุหรือถูกเพิกถอน

แนวคิด (3) — ทำไมกุญแจลับควรอยู่ในชิป

กุญแจลับในไฟล์หรือ flash อ่านออกได้หลายทาง — ใครถือ image, เสียบพอร์ต debug, หรือถอดชิป flash ก็ได้กุญแจไปด้วย แล้วทำสำเนาไปกี่เครื่องก็ได้

OPTIGA™ Trust M เปลี่ยนคำถามจาก "กุญแจอยู่ที่ไหน" เป็น "ใครสั่งให้ชิปใช้กุญแจได้"

• กุญแจสร้างในชิป ไม่มีคำสั่งอ่านออก (metadata: Change=never, ไม่มีสิทธิ์อ่าน)
• โปรแกรมส่ง ชื่อช่อง (OID) กับ digest เข้าไป แล้วได้ลายเซ็นกลับมา
• ฮาร์ดแวร์ผ่าน Common Criteria EAL6+ (high)

ชิปไม่ได้กัน การใช้กุญแจลงนามโดยเฟิร์มแวร์ที่ถูกยึดไปแล้ว (ขณะยังคุมบอร์ดอยู่) และสาย I2C ไม่ได้เข้ารหัสในค่าตั้งเริ่มต้น (OPTIGA_COMMS_NO_PROTECTION)

ตัวอย่างสมบูรณ์ — ลงนามด้วยกุญแจในชิป

จาก example_optiga_crypt_ecdsa_sign.c (Infineon, MIT) — SDK ของบอร์ดใช้ host library รุ่นนี้

/* 2. Sign the digest using Private key from Key Store ID E0F0 */
optiga_lib_status = OPTIGA_LIB_BUSY;
return_status = optiga_crypt_ecdsa_sign(
    me, digest, sizeof(digest),
    OPTIGA_KEY_ID_E0F0, signature, &signature_length
);
WAIT_AND_CHECK_STATUS(return_status, optiga_lib_status);

• digest = SHA-256 ของข้อมูล 32 ไบต์ — ลงนามบน digest ไม่ใช่ข้อมูลดิบ
• OPTIGA_KEY_ID_E0F0 คือ ชื่อช่อง ไม่ใช่ตัวกุญแจ — กุญแจไม่โผล่ใน RAM ของ MCU เลย
• คำสั่งเป็น asynchronous — คืนค่าทันที ผลจริงมาทาง callback

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

ฝึกเติม เลือกเครื่องมือให้ถูกสถานการณ์ (ต้องถูก ≥4/5)

1. แพลตฟอร์มส่งใบรับรองใหม่ ต้องแน่ใจว่ามาจากแพลตฟอร์มจริง → ลายเซ็นดิจิทัล
2. เก็บ "ลายนิ้วมือ" ของ CA ไว้เทียบ → hash
3. อุณหภูมิผ่าน WiFi ร้านกาแฟต้องไม่ให้คนข้างโต๊ะอ่าน → การเข้ารหัสสมมาตร

แล็บ เก็บห่วงโซ่ใบรับรองจาก broker, อ่านสี่ฟิลด์ของแต่ละใบ, เทียบ fingerprint กับค่าที่ SDK บันทึกไว้, ลองแก้ข้อความหนึ่งตัวอักษรดู hash เปลี่ยนแค่ไหน, สร้างคู่กุญแจ P-256 ลงนามและตรวจบนคอมพิวเตอร์ (ครั้งแรก Verified OK, แก้ข้อความแล้ว Verification failure) แล้วลบไฟล์กุญแจทดลองทิ้ง

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

1. ทำไมฟังก์ชันตรวจลายเซ็นใน 02_model_signature_hook.c จึงไม่คืน "ผ่าน" แม้ CRC จะถูกต้อง

   • ก) เพราะ CRC ช้าเกินไป · ข) เพราะใครก็คำนวณ CRC ใหม่ได้ มันไม่บอกว่าใครเขียน · ค) เพราะ CRC ต้องใช้กุญแจลับ · ง) เพราะ CRC ใช้ได้กับข้อมูลเข้ารหัสแล้วเท่านั้น

2. ใบรับรองจากโรงงานในช่อง 0xE0E0 มี subject CN=InfineonIoTNode ทุกชิป ข้อสรุปใดถูก

   • ก) ใบนี้บอกได้ว่าเป็นอุปกรณ์เครื่องไหน · ข) ใบนี้ปลอมแน่นอน · ค) ใบนี้พิสูจน์ว่าเป็น Trust M ของแท้ แต่ต้องใช้ serial หรือกุญแจสาธารณะถ้าจะแยกเครื่อง · ง) ใบนี้ไม่มีกุญแจสาธารณะ

3. ในค่าตั้ง mbedTLS ของ CM33_NS ที่ commit ef72c1b อุปกรณ์จะปฏิเสธใบรับรองของเซิร์ฟเวอร์ที่หมดอายุหรือไม่

   • ก) ปฏิเสธเสมอ · ข) ไม่ปฏิเสธด้วยเหตุผลเรื่องวันที่ เพราะ MBEDTLS_HAVE_TIME_DATE ถูกปิด · ค) ปฏิเสธเฉพาะเมื่อมี CRL · ง) ขึ้นกับ broker

ไปต่อ

เราเห็นแล้วว่าชิปทำให้กุญแจไม่ต้องออกมาข้างนอก บทต่อไปจะเปิดดูข้างในชิปจริงบน TESAIoT Dev Kit ว่ามี object อะไร metadata บอกอะไร และคำสั่งไหนเปลี่ยนชิปแบบย้อนกลับไม่ได้

บทเรียนถัดไป: บทเรียน 2.1: ชิปความปลอดภัยทำอะไรให้เรา