SDK สำหรับ TESAIoT Dev Kit
คู่มืออ้างอิง API และ Tutorial (ModusToolbox)
Loading...
Searching...
No Matches
TESAIoT HSM (libbento_hsm.a)

Topics

 chip gate และ manager
 การจับ touch ไว้
 การลงทะเบียนและการ publish ของ Protected Update
 state และ correlation
 การทดสอบแบบแยกส่วน
 หมายเหตุการใช้งาน

Detailed Description

archive (ไฟล์ไลบรารีแบบสแตติก .a) ตัวนี้ export ฟังก์ชันออกมา 18 ตัวพอดี (dist/tesaiot_hsm/api.txt) ทั้งหมดประกาศไว้ใน tesaiot_hsm_api.h ที่เขียนด้วยมือ ซึ่งเป็นที่อยู่ของการประกาศที่แก้ไขได้ และถูกตรวจเทียบกับ api.txt ทุกครั้งที่รันการทำแพ็กเกจ ฟังก์ชันเหล่านี้ถูกนิยามไว้ในไฟล์ 3 ไฟล์ที่อยู่ใน archive (tesaiot_optiga_manager.c, tesaiot_optiga_trust_m.c, tesaiot_protected_update_isolated.cdist/tesaiot_hsm/PROVENANCE.txt) ซึ่งไม่มีไฟล์ใดส่งมอบมาเป็นซอร์ส ส่วนฟังก์ชันอีกราว 52 ตัวที่ header tesaiot_optiga*.h รุ่นเก่าประกาศไว้คือกลไกของการลงทะเบียน (enrolment) และ Protected Update ฟังก์ชันเหล่านั้นถูกเปลี่ยนชื่อภายใน archive ด้วยเจตนาให้ผู้ใช้ไลบรารีเข้าถึงไม่ได้

variant ที่ใช้ได้
mtb-mpy และ mtb-only

ไม่ต่างกันระหว่าง variant: variants/mtb-only.mk:14 — "OPTIGA CSR and Protected Update. libbento_hsm.a needs zero MPY symbols."

symbol 6 ตัวที่ถูกใช้แบบ weak — ข้อกำหนดการตรวจ NULL

dist/tesaiot_hsm/overridable.txt ว่างเปล่า: ไม่มีอะไรใน archive นี้ที่เขียนทับ (override) ได้แบบ weak — ไม่มี symbol ใดที่นี่เป็น hook ให้ผู้ใช้ไลบรารีมาเขียนเอง แต่หกใน 18 ตัวนั้นถูกใช้ในฐานะ weak symbolโดยผู้เรียกที่มีอยู่จริงในของที่ส่งมอบ เพราะจะเชื่อม (link) เข้ามาเฉพาะเมื่อ ENABLE_OPTIGA_CLM=1 เท่านั้น (ค่าเริ่มต้นคือ 1) ผู้เรียกที่ต้องคอมไพล์โดยปิด CLM จะประกาศ symbol เหล่านี้เป็น __attribute__((weak)) และตรวจ NULL ของพอยน์เตอร์ฟังก์ชันก่อนเรียกทุกครั้ง:

ฟังก์ชัน จุดที่ถูกใช้แบบ weak ในของที่ส่งมอบจริง
publish_csr() proj_cm33_ns/ipc_hsm_handler.c:1691-1693 (การประกาศ), :2174 (การตรวจ)
tesaiot_publish_protected_update() ipc_hsm_handler.c:2192
trustm_reset_state() ipc_hsm_handler.c:1966-1968
trustm_current_correlation_id() ipc_hsm_handler.c:1792-1794 — ตรวจ NULL สองจุด คือตัวพอยน์เตอร์ แล้วจึงเป็น string ที่คืนกลับมา
trustm_requested_target_oid() tesaiot_pu_ingest.c:139-144 ถอยไปใช้ 0xE0E1
trustm_requested_anchor_oid() tesaiot_pu_ingest.c:133-137 ถอยไปใช้ 0xE0E8
extern int publish_csr(uint8_t *csr, size_t csr_length, uint16_t target_oid,
uint16_t trust_anchor_oid, uint32_t payload_version)
__attribute__((weak));

อีก 12 ตัวเป็น strong ทุกที่ และไม่ต้องมีตัวกัน (guard) แบบนี้

กฎ 3 ข้อที่ย้อนกลับมาในทุกหัวข้อ

  1. optiga_chip_enter() ไม่ใช่การตรวจสอบว่า init แล้วหรือยัง ฟังก์ชันนี้คืนค่า true โดยเจตนาเมื่อ manager ไม่เคยถูก initialise (tesaiot_optiga_manager.c:157-169) ส่วน optiga_manager_lock() คืนค่า false ในสถานะนั้น และเป็นการทดสอบ "manager ขึ้นแล้วหรือยัง" ที่ถูกต้อง การเข้าใจสลับกันคือสาเหตุที่มีบันทึกไว้ของข้อบกพร่องประเภทเข้าถึงโดยไม่ผ่าน gate (ด่านกั้น) หลายรายการ
  2. touch hold เป็นแบบนับจำนวน และห้ามส่ง IPC_CMD_TOUCH_RESUME ดิบ ๆ เอง secure element (ชิปนิรภัยแยกส่วน) กับตัวควบคุมการสัมผัส (touch) ของ CM55 ใช้บัส I2C เส้นเดียวกัน การจับไว้ทุกครั้งซ้อนกันได้ (s_touch_holds) และการจับไว้ทุกครั้งต้องมีการปล่อยหนึ่งครั้งพอดีในทุกเส้นทางออก การส่งคำสั่ง resume ดิบ ๆ แทนการเรียก optiga_manager_touch_release() ทำให้ CM55 ตั้ง touch_disabled = false โดยไม่มีเงื่อนไข ซึ่งไปยกเลิกการจับไว้ของ task อื่น — OPTIGA_COMMS_ERROR (0x0102) (ipc_hsm_handler.c:1393-1405)
  3. correlation id (รหัสจับคู่คำขอกับคำตอบ) คือการป้องกันการเล่นซ้ำ (replay) แพลตฟอร์มเก็บ bundle ของ Protected Update ล่าสุดไว้ และส่งมาให้ทุกครั้งที่เชื่อมต่อ รอบการทำงานถูกตั้งให้พร้อมรับโดย publish_csr() หรือ tesaiot_publish_protected_update() และถูกปลดโดย trustm_reset_state() เท่านั้น ขณะที่ trustm_current_correlation_id() เป็น NULL ต้องทิ้ง bundle ที่เข้ามา พบ 3 ครั้งเมื่อ 2026-08-07 ก่อนที่จะมีการตรวจนี้ แต่ละครั้งคือการทำรอบก่อนหน้าซ้ำอย่างเงียบ ๆ