บทเรียน 3.1 — TLS และ mTLS

เป้าหมาย

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

1. วาดขั้นตอน handshake ของ TLS 1.3 และระบุขั้นที่เซิร์ฟเวอร์และอุปกรณ์พิสูจน์ตัวตน
2. อธิบายว่าเมื่อใช้ชิปความปลอดภัย การลงลายเซ็นระหว่าง handshake เกิดขึ้นในชิปโดยกุญแจลับไม่ออกมา
3. วินิจฉัยสาเหตุของการเชื่อมต่อ TLS ล้มเหลวที่พบบ่อยอย่างน้อยสามแบบ

ก่อนเริ่ม

• เรียนมาก่อน: บทเรียน 2.2 และไฟล์ cert01 ที่ตรวจ fingerprint แล้ว (แล็บ 1.2)
• เครื่องมือ: openssl — แล็บหลักทำบนคอมพิวเตอร์ ส่วนบนบอร์ดเป็นแล็บเสริม

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

[mTLS] Setting up OPTIGA Trust M (cert=0xE0E0, key=0xE0F0)
[mTLS] Certificate read: %u bytes PEM
[MQTT] Connecting to '%s:8883' as '%s'...
[PSA-Sign] Using Key OID 0xE0F0 for TLS CertificateVerify (slot=%lu)
[MQTT] Connected to broker

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

แนวคิด (1) — handshake ของ TLS 1.3

 อุปกรณ์ (client)                                 broker (server)
 ClientHello + key_share            ──────▶
                                    ◀──────  ServerHello + key_share
                                             {Certificate} {CertificateVerify}
                                             {CertificateRequest} ← เฉพาะเมื่อขอ mTLS
                                    ◀──────  {Finished}
 {Certificate}        ← mTLS: ใบของอุปกรณ์
 {CertificateVerify}  ← mTLS: อุปกรณ์ลงนามบน transcript (ในชิป)
 {Finished}                         ──────▶

ข้อเท็จจริงที่ต้องแยก broker คุย TLS 1.3 ได้ แต่ค่าตั้ง mbedTLS ของ CM33_NS ที่ commit ef72c1b เปิดเฉพาะ TLS 1.2 — ใน 1.2 ใบรับรองทั้งสองฝั่งเดินแบบไม่เข้ารหัส (ต่างจาก 1.3)

แนวคิด (2) — ลายเซ็นเกิดในชิป กุญแจไม่ออกมา

mqtt_mtls_setup_optiga() เตรียมของก่อน handshake:

1. ถือ touch-hold + optiga_manager_init() ก่อนงาน TLS ใด ๆ
2. เลือกตัวตน: ถ้า optiga_verify_cert_key_pair(0xE0E1,0xE0F1) ผ่าน ใช้คู่ TESAIoT
   ไม่งั้นใช้คู่จากโรงงาน 0xE0E0/0xE0F0
3. อ่านใบรับรองเป็น PEM ส่งให้ TLS stack
4. สร้าง key handle แบบ opaque (PSA_KEY_LOCATION_OPTIGA) — ไม่ได้สร้างกุญแจใหม่ แค่ "ชื่อ"

ตอนสร้าง CertificateVerify mbedTLS → PSA → optiga_psa_sign() → trustm_ecdsa_sign() (ถือประตู+hold ตลอด) — ไม่มีจุดไหนที่ไบต์ของกุญแจลับออกจากชิป

คำตอบคำทาย [PSA-Sign] Using Key OID ... พิมพ์ก่อนการลงนาม สัญญาณว่าสำเร็จคือบรรทัดนี้ +ไม่มีบรรทัด ERROR + [MQTT] Connected to broker

แนวคิด (3) — mTLS พิสูจน์อะไร และไม่พิสูจน์อะไร

ถ้าใช้คู่จากโรงงาน ใบ CN=InfineonIoTNode เหมือนกันทุกชิป → handshake พิสูจน์ได้แค่ว่าเป็น Trust M ของแท้ ไม่มีอะไรผูกตัวตน (device_id) กับใบที่แสดง — ตัวควบคุมจริงอยู่ฝั่ง broker (ACL ผูกกับ fingerprint ของกุญแจสาธารณะ ไม่ใช่ subject)

TLS/mTLS ไม่ได้ป้องกัน

• ข้อมูลที่พักอยู่บนอุปกรณ์หรือแพลตฟอร์ม (ปกป้องแค่ระหว่างทาง)
• ปลายทางที่ถูกเจาะแล้ว · ACL ที่ตั้งผิด
• ใบที่หมดอายุ/ถูกเพิกถอน (ในค่าตั้งนี้)
• การเชื่อมต่อที่ตั้ง CY_AWS_ROOTCA_VERIFY_NONE (เช่นบางเส้นทาง HTTPS) — เข้ารหัสแต่กันดักกลางทางแบบ active ไม่ได้

แนวคิด (4) — อ่านอาการเมื่อการเชื่อมต่อล้ม

ตัวอย่างสมบูรณ์ — mTLS บนคอมพิวเตอร์ (device-mtls)

/* Resolve credential files */
char ca[512], crt[512], key[512];
join_path(crt, sizeof(crt), certs_dir, FILE_CLIENT_CERT);
join_path(key, sizeof(key), certs_dir, FILE_CLIENT_KEY);
if (!(file_exists(crt) && file_exists(key))) {
  fprintf(stderr, "mTLS requires client_cert.pem and client_key.pem in %s\n", certs_dir);
  return 1;
}

บนคอมพิวเตอร์ กุญแจลับคือ ไฟล์ client_key.pem ที่อ่านเข้า RAM — ใครคัดลอกไฟล์ได้ก็เป็นอุปกรณ์นี้ได้ บนบอร์ด ตำแหน่งเดียวกันคือ cy_tls_set_optiga_key_id() ที่ส่งแค่ ชื่อ ของกุญแจ — bundle จากการลงทะเบียนด้วย CSR ไม่มีกุญแจลับใน ZIP

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

ฝึกเติม เรียงข้อความ handshake ของ TLS 1.3 แบบ mTLS แล้วกำกับ S=เซิร์ฟเวอร์พิสูจน์ตัว D=อุปกรณ์พิสูจน์ตัว: ClientHello → ServerHello → EncryptedExtensions → CertificateRequest → Certificate(S) → CertificateVerify(S) → Finished(S) → Certificate(D) → CertificateVerify(D) → Finished(D)

แล็บ openssl s_client ที่พอร์ต 8884 ดู state ทีละข้อความ เทียบกับแผนภาพ · บังคับ -tls1_2 ดูว่าบรรทัดไหนหายไป/เพิ่มมา · ต่อพอร์ต 8883 โดยไม่มีใบ client ดู alert · ตัด -CAfile ออกดู Verify return code

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

1. ใน mTLS อุปกรณ์พิสูจน์ว่าถือกุญแจลับของใบรับรองจริงด้วยข้อความใด

   • ก) ClientHello · ข) Certificate · ค) CertificateVerify · ง) EncryptedExtensions

2. psa_generate_key() ใน mqtt_mtls_setup_optiga() ทำอะไร

   • ก) สร้างคู่กุญแจใหม่ในชิปทุกครั้งที่เชื่อมต่อ · ข) คัดลอกกุญแจลับจากชิปมาไว้ใน RAM · ค) ลงทะเบียน handle แบบ opaque ที่ driver แปลงเป็น OID ของกุญแจในชิป ไม่ได้สร้างอะไรในชิป · ง) สร้างกุญแจ AES สำหรับ TLS record

3. ทำไมใน TLS 1.2 ผู้ที่ดักแพ็กเก็ตได้จึงอาจรู้ว่าเป็นอุปกรณ์เครื่องไหน แม้ข้อมูล MQTT จะถูกเข้ารหัส

   • ก) เพราะรหัสผ่านถูกส่งแบบไม่เข้ารหัส · ข) เพราะใบรับรองของทั้งสองฝั่งใน handshake ของ TLS 1.2 เดินแบบไม่เข้ารหัส · ค) เพราะ TLS 1.2 ไม่มีการเข้ารหัสเลย · ง) เพราะ MQTT CONNECT อยู่นอก TLS

ไปต่อ

ตอนนี้เรารู้ว่าช่องทางปลอดภัยอย่างไร บทต่อไปจะตามเส้นทางของข้อมูลทั้งเส้น ตั้งแต่ไฟล์ตั้งค่าบนบอร์ดจนถึง broker

บทเรียนถัดไป: บทเรียน 3.2: MQTTs ขึ้น TESAIoT Platform