先用一句話抓住這篇
從門外的鑰匙、HUK 與 Key Storage 出發，一路走到可信開機、安全儲存、內外部信任與完整 HRoT；用十二張漫畫看懂硬體信任根真正負責什麼。
先把這篇當成一張閱讀地圖：上方摘要說明問題，圖片先建立直覺，下面文字再補上真正的技術取捨。
如果第一次讀覺得名詞很多，可以先記住比喻與結論；第二次再回頭看名詞，會順很多。
一棟房子可以裝上厚門、警報器和攝影機，但如果鑰匙就掛在信箱旁，攻擊者根本不必破解那些設備。晶片安全也有同樣的問題：演算法再強、軟體再複雜，只要最底層的祕密、第一段程式或存取規則能被繞過，上面的防線就會失去意義。
這一課從「鑰匙放在門外」的例子出發，先看狹義的信任核心：根祕密、HUK 與 Key Storage；再把視野拉大到可信程式、安全執行、安全儲存、密碼學服務、生命週期與內外部信任。這裡的「狹義／廣義」只是教學鏡頭，不是業界唯一、正式的產品分級。
1. 房子很堅固，鑰匙卻在門外
先不要急著背 HRoT。想像屋主買了最好的門鎖、警報器和攝影機，卻把備用鑰匙留在信箱上。小偷不需要研究門鎖結構，也不用切斷警報器；拿到那把鑰匙，就能沿著「合法開門」的路徑進去。
這就是 weakest link 的意思。安全不是把功能一個個打勾後相加，而是看攻擊者能不能找到更短的繞路。晶片裡的根金鑰若可讀出、第一段啟動碼若可替換，或任何 App 都能呼叫敏感操作，AES、SHA、簽章驗證等功能即使各自正確，整體仍可能不可信。
Root of Trust 的工作，是替某一項安全服務提供最早、最難被繞過的信任依據。不同系統可能為機密性、完整性、量測、更新、裝置身分或復原安排不同的根，而且不一定每一項都各有一個獨立方塊。GlobalPlatform 的 RoT 定義同樣強調，RoT 是受信任、用來提供特定安全功能的元件或功能集合。[1]
所以工程師該先問：「哪一個資產或判斷一旦失守，後面所有檢查都會被騙過？」先把這題答清楚，再盤點手上有哪些 HRoT IP，才知道信任根應該守在哪裡。
2. 設計可以公開，信任起點不能被拿走
Kerckhoffs 原則提醒我們：系統的演算法、架構與流程就算被知道，安全性仍應主要依靠妥善保護的金鑰，而不是賭攻擊者沒看過設計。把 RTL、韌體流程或演算法藏起來，可以增加分析成本，卻不該是唯一一道牆。
在裝置裡，HUK（Hardware Unique Key）常用來稱呼每顆裝置特有、可支撐多種服務的根祕密。它可能直接存於 OTP／eFuse，也可能由 PUF 回應配合修復資料重建，或在受控產線中注入。名稱與實作會因架構而異；共同目標是讓這份根材料不必以一般軟體可讀的明文形式四處搬動。DICE 裡的 UDS（Unique Device Secret）則有更窄的任務：它要和第一段可變程式碼的量測組合成第一個 CDI，不該被當成一般工作金鑰隨意取用。
「根」也不等於「權力天生最大」。真正的影響力來自系統把哪些服務、金鑰與決策建立在它上面。若 HUK 只用來導出儲存金鑰，它支撐的是那條儲存信任；若又被拿來建立裝置身分、更新驗證與 attestation，失守範圍自然更大。
理想介面通常不提供 read_huk()。呼叫者只能請受控邊界替它導出、解封或完成一項允許的運算，最後拿到結果，拿不到根祕密。這樣即使上層軟體被入侵，攻擊者也不會立刻取得能離線複製的根材料。
工程師延伸：HUK 與 UDS 是架構角色，不是同一種固定電路
產品可以把最早期的祕密材料保留在 OTP／eFuse，也可以由 PUF 配合修復資料重建；接著再從根材料導出或封裝下層工作金鑰。看到相同縮寫時，仍要檢查威脅模型、reset 行為、測試權限、helper data、用途標籤與匯出路徑，不能只靠名稱判定兩個設計等價。
3. Key Storage 不是把金鑰塞進盒子
保險箱若只防止別人看見鑰匙，卻讓任何人都能隔著玻璃按下「開門」，問題仍然沒有解決。Key Storage 的第一層是 confidentiality：金鑰不可由一般軟體直接匯出；第二層則是 authorization：系統要知道誰在請求、想做什麼，以及現在是否允許。
因此介面會同時考慮 caller identity、asset owner 與 access policy。App A 建立的金鑰，不應自然地被 App B 取得；測試模式可用的操作，也不一定能帶進正式量產狀態。PSA 的 Secure Storage 架構便把不同 client 的資料隔離，並透過服務介面控制存取，而不是把所有資料當成同一個檔案櫃。[5]
第三個問題是「允許哪一種操作」。某把 key 可能只准解封特定儲存資料，不准匯出；韌體驗證只能使用指定 public key，簽署能力則留在受控的 private key 端；根材料也可能只准進入 KDF，不能直接當工作金鑰。把用途寫進 policy，可以減少一個介面被濫用後的傷害範圍。
時間也得放進來看。裝置從製造、測試、正式使用到退役，權限會改變；Debug 可能被鎖住，暫時性祕密可能被 zeroize，更新也要經授權狀態機。金鑰是否安全，不能只拍一張「靜止在保險箱裡」的照片，還要看完整生命週期。
4. 根祕密為什麼不該親自做每一份工作？
把 HUK 直接交給每個服務，就像把大樓總鑰匙複製給清潔、收件、機房和租戶。任何一份副本外流，都可能打開整棟樓。更穩健的做法，是讓根祕密留在可信邊界裡，再用 KDF（Key Derivation Function）導出不同用途的工作金鑰。
KDF 會把 root secret、label 與 context 一起帶進計算。Label 可以表達「storage」「device identity」或「service A」；context 則可綁定裝置、版本、演算法或其他環境資料。用途或情境改變，導出的 key 也應跟著不同。
根祕密因此不必頻繁接觸更多介面。某個工作金鑰失守，也不會自動揭露其他用途的金鑰；這限制了單一子金鑰外洩的範圍。共同根祕密若被取得，攻擊者仍可能重算它能衍生的其他金鑰，不能把分層當成根失陷後的保護。
還要注意：從同一根祕密導出多把 key，不代表它們可以隨意互換。真正的 domain separation 要由明確編碼、固定 label、正確 KDF 與存取政策共同完成；不要只在字串前面隨便加一個名稱，就宣稱用途已隔離。
5. HRoT 到底要保護哪些東西？
第一類資產最直觀：HUK、私鑰與 shared key 都有機密性需求。攻擊者若讀到它們，可以在裝置外複製身分、解開資料，或模仿原裝置完成敏感操作。這些內容通常要 non-exportable，並限制只能在受保護服務中使用。
第二類資料可能本來就公開，例如 CA public key、韌體驗證公鑰、certificate 或預期 digest。它們不一定需要保密，卻必須防止被替換。攻擊者若能把「可信公鑰」換成自己的公鑰，後面的簽章驗證照樣會算出 PASS，只是信錯了人。
第三類是會變動的安全狀態：允許的韌體版本、rollback counter、更新狀態、失敗次數或撤銷資訊。它們需要受控更新、完整性和 freshness。只驗證內容沒有被亂改，卻容許換回一份舊而有效的快照，仍可能讓已修補漏洞復活。
Lifecycle 與 debug policy 也屬於受保護範圍。不同資料需要不同的保護方式：祕密資產要防止未授權讀取；信任材料與狀態要防止未授權替換；需要更新的東西則要能在授權、可驗證的流程裡更新，不是永遠鎖死。
6. 同一顆晶片裡，為什麼還要驗證彼此？
Internal trust 先問資料：內容完整嗎？來源真的是預期元件嗎？一個 digest 可以幫忙比對資料是否變動，但 digest 本身若也能被替換，就無法證明來源。要做來源驗證，還需要受保護的基準值、MAC、簽章或其他能連回信任根的機制。
接著問 caller。現代 SoC 裡可能同時有 normal world、secure world、多個 privilege level、DMA master 與外部裝置。共用匯流排或記憶體不代表共用權限；HRoT 需要透過硬體身分、隔離、記憶體保護和受控 API，辨認誰正在請求。
第三個問題是 operation。即使 caller 合法，也不表示任何動作都合理。某個服務可使用 storage key 解封自己的資料，不代表它能要求匯出 key；維修工具能讀診斷資訊，也不代表能關閉 secure boot。
Lifecycle 這一題也不能漏。製造與測試階段需要的權限，若一路留到 field operation，就可能成為後門；退役時又要處理資料清除與憑證撤銷。內部信任要同時滿足 right data、right caller、right operation 與 right lifecycle，單說「Alice 是對的人」還不夠。
7. 開機後，誰是第一個可信的程式？
電源打開後，處理器會從 reset vector 取得第一個執行位置。若這段起始程式能被未授權替換，它可以假裝完成所有檢查，再把惡意韌體交給後面執行。因此常見做法，是讓第一段可信碼落在不可變硬體、mask ROM 或經嚴格保護的 Boot ROM。
這個起點不必做完整作業系統的工作。它只要足以初始化必要資源、讀取受保護的驗證材料、檢查下一階段，並在失敗時走向安全處理。程式碼、資料、parser 與 key interface 越多，越難審查，也越容易出現漏洞。
驗證通過後，第一階段把信任延伸給第二階段；第二階段再驗證第三階段。這就是 Chain of Trust。NIST SP 800-193 把平台韌體韌性整理成保護、偵測與復原三個目標：可信啟動要能拒絕錯誤映像，也得處理更新與復原。[2]
Chain of Trust 要求每一層在交棒前，用已建立的信任材料與 policy 判斷下一層。若中間任何一次驗證被跳過、驗證 key 可被替換，或 rollback policy 失效，鏈條就會在那一節斷掉。
8. Secure Storage 只要加密就夠了嗎？
Confidentiality 回答「別人能不能看見內容」。對祕密金鑰、token 或私人資料很重要，但它只處理一個維度。把密文某一段換掉、把整份密文換成別人的，或把昨天的合法密文搬回來，都不一定靠「看不見」就能阻止。
Integrity 與 authenticity 回答資料是否被改，以及是否由預期來源建立。Isolation 則確保 Alice 寫入的物件不會被 Bob 或 Eve 當成自己的取回；這需要 owner identity、命名空間與存取控制配合，不是只替每個檔案套一層 AES。
Freshness 專門處理舊快照。假設系統已撤銷某項舊權限，攻擊者若能把儲存區整體換回撤銷前的合法狀態，內容與驗證碼可能都完全正確，安全政策卻倒退了。單把版本號一起放進同一份 MAC 保護的檔案沒有用，因為攻擊者會連檔案與版本一起還原。判斷 freshness 的計數器或 replay state 必須放在單調遞增、或至少不會跟著同一儲存媒體一起回復的位置。
PSA Secure Storage 與 TF-M 的 protected storage 設計都把 key derivation、client isolation、integrity 與儲存後端邊界納入考量。真正的 secure storage 是一套端到端服務，不是「有加密」三個字。[5][6]
工程師延伸：只有完整性，仍然擋不住回滾
有效的 MAC 能證明資料與某把 key、某段訊息相符，卻不能單獨證明它是目前最新、仍被允許的狀態。防回滾需要受保護的版本狀態、單調計數器、hash chain，或其他能辨認舊版合法快照的設計；而且這份判斷依據不能只和資料放在同一個可被整體還原的區域。
9. HRoT 能不能保證整條網路都安全？
對外通訊時，我們會問三個不同問題：對方真的是 Bob 嗎？傳輸內容會不會被旁觀者看見？訊息途中有沒有被改？Authentication、encryption 與 integrity 分別回答不同部分，不能只看到一把鎖就當成三題全解。
HRoT 可以保存裝置私鑰、受信任 CA key、certificate 或 attestation 所需材料，也能在受控邊界內完成簽署、驗證或金鑰操作。它讓裝置端不必把根材料交給一般軟體，並為協定提供一個比較可信的起點。
但 HRoT 不是整條網路。Peer identity、憑證路徑、握手 transcript、演算法協商、重放防護、錯誤處理與 session 狀態，都屬於協定和系統整合。硬體裡有一顆安全元件，不會自動讓錯誤的 TLS 設定或自製協定變正確。
外部通訊的安全涉及身分驗證、加密、完整性與簽章。其中，signature 可以提供來源與完整性證據，但「法律上的不可否認性」還牽涉身分驗證、私鑰控制、稽核與制度，不是看到簽章就自動成立。
10. 從根祕密，怎麼搭成完整的 HRoT？
用「狹義鏡頭」看，HRoT 像是一個守住 HUK 的小核心：不可變狀態、根祕密、Key Storage 和幾個受控操作。這個畫面適合建立第一層直覺，卻不足以描述多數實際產品需要面對的啟動、儲存、更新與隔離問題。
把鏡頭拉大，系統還需要可信程式、安全執行環境、存取控制、生命週期、密碼學服務、安全儲存與失敗處理。有些設計會加入 anti-tamper sensor 或反應機制，有些則以封裝、debug policy、memory protection 和 side-channel 對策建立邊界。這不是固定同心圓，也沒有一套所有產品都必須長得一樣的清單。
PUF 與 TRNG 特別容易混淆。PUF 利用製程差異產生裝置特有、可重現但帶雜訊的回應，常需 helper data 與 fuzzy extractor 才能協助建立穩定祕密；TRNG 則從物理不確定性取得每次都要新鮮的隨機性。前者偏向「同一顆裝置再次建立特有材料」，後者偏向「現在產生新的不可預測值」。
Crypto engine 也不是擺進去就算完成。AES、SHA、KDF 的實作、key path、DMA、錯誤回報、零化與 caller policy 必須落在同一個可說明的 security boundary 裡。PSA 將 Root of Trust、受隔離服務與平台安全生命週期串起來，正是這種從元件走向系統的思路。[3][4]
工程師延伸：PUF 與 TRNG 的驗證問題不同
PUF 評估會關注同一裝置能否重現、不同裝置是否分離、環境變化、helper data 洩漏與重建失敗率；TRNG 評估則關注物理雜訊源、conditioning、健康測試、失效反應與新輸出的不可預測性。兩者都可能用到類比雜訊，卻不能因為放在同一個安全方塊裡，就沿用彼此的安全宣稱。
11. PUF、HUK、TEE、TPM、SE，為什麼不能混成同一個名詞？
PUF 是 physical primitive：它提供裝置特有的物理回應，可協助建立根祕密。HUK 是 secret asset：它描述留在受保護邊界內的裝置根材料。Key Store 是 protected service：它保存或封裝工作 key，並居中管理誰能用、能做什麼。三者可能合作，卻不是同義詞。
Boot ROM 是 trusted code 的常見起點；TEE 是 isolated execution environment，讓敏感程式和資料與一般環境分開。GlobalPlatform 的 TEE 架構談的是執行環境、client API 與 trusted application 等邊界；一個 TEE 可以使用硬體信任根，但「有 TEE」不自動等於所有根材料與啟動鏈都安全。[7]
SE（Secure Element）與 TPM（Trusted Platform Module）是安全元件或子系統類別，各自有產品定位與介面傳統；它們可能提供金鑰管理、安全運算、量測、密封或 attestation。DICE 則從專用的 UDS 與第一段可變程式碼量測算出 CDI，再往下組成分層身分；TCG 的 DICE 文件把這項硬體需求和裝置身分連在一起。[8]
Chain of Trust 描述信任如何由一階延伸到下一階，HRoT 則是硬體錨定、能提供一組可信服務的子系統。不同 SoC 可能把能力放在同一個 block，也可能分散在 ROM、security island、memory controller 與獨立安全元件。責任地圖的箭頭代表可能的支援關係，不是固定接線圖。
工程師延伸：狹義與廣義 HRoT 只是教學鏡頭
標準與供應商對 Root of Trust、Secure Element、TEE、TPM、security island 與 measured boot service 的切分方式不盡相同。本課從根祕密與 Key Storage 逐步走到較完整的可信子系統，是為了幫助理解責任邊界，不是在定義業界通用的 Basic／Standard HRoT 產品等級。
12. 少一塊時，信任會從哪裡漏出去？
第一個案例：HUK 完全讀不到，但任何 App 都能要求它替自己完成任意操作。Key confidentiality 守住了，access control 卻失敗。攻擊者不必偷走 key，只要把受保護服務當成遠端控制器使用。
第二個案例：Crypto Engine 算法正確、速度也快，key 卻會沿著一般 bus 或 debug 介面匯出。缺少的是 key boundary。安全運算的範圍必須包含 key 進入、使用、暫存與清除的完整路徑。
第三個案例：Storage 能驗證每份資料的 MAC，卻接受過去的合法快照。完整性仍在，freshness 卻失守。第四個案例：TEE 內部隔離很好，但啟動時的第一段程式可被替換；這時缺少可信的 immutable anchor，後面的驗證都可能只是惡意程式演給我們看。
真正的檢查方式，是沿著 Root Secret → Trusted Code → Secure Services → Chain of Trust 逐段追問：資產在哪裡產生？誰能使用？哪段程式做判斷？狀態如何更新？失敗後往哪裡走？功能 checklist 容易漏掉抄近路的攻擊者；完整信任路徑才看得出繞道。
五點帶走
- 先找出失守後會讓其他防線失效的信任錨點，再談它採用哪一種 HRoT 名稱或產品形式。
- HUK 是裝置根祕密資產；DICE 的 UDS 有專用的 CDI 衍生路徑。Key Storage 還要控制 caller、operation 與 lifecycle，不能只防止讀出。
- 公鑰、certificate、digest 不一定要保密，卻要防止未授權替換；安全儲存還要處理隔離與 freshness。
- Boot ROM、可信啟動、TEE、密碼學、PUF、TRNG、SE、TPM 與 DICE 各負責不同層次，可能組合，但不是同義詞。
- 最後要用攻擊路徑驗證整條信任鏈；有一顆安全元件，不代表整個裝置或網路自動安全。
下一單元再談 Digital Signature：如何用受保護的私鑰留下可驗證的數學證據，以及驗證者究竟相信了什麼。
References
- GlobalPlatform, Root of Trust Definitions and Requirements v1.1.1：RoT 的角色、功能與需求定義。
- NIST SP 800-193, Platform Firmware Resiliency Guidelines：平台韌體的保護、偵測與復原原則。
- PSA Certified, What Is a Root of Trust?：PSA Root of Trust 與裝置安全基礎的概念介紹。
- Arm PSA Crypto API, Sample System Architecture：受隔離 crypto service、client 與 key lifetime 的架構示例。
- Arm PSA Secure Storage API, Architecture：client isolation、storage service 與後端邊界。
- Trusted Firmware-M, Protected Storage Key Management：protected storage 的 key derivation 與生命週期設計。
- GlobalPlatform, TEE System Architecture：TEE、Rich Execution Environment 與 trusted application 的系統邊界。
- Trusted Computing Group, Hardware Requirements for a Device Identifier Composition Engine：DICE 的硬體需求與分層裝置身分基礎。
用途分離與使用權，要分別檢查
先比較同一用途重算與改用途的輸出。再改裝置情境，預測 key 會不會相同。最後取消 caller 授權，或選擇匯出根祕密，查看政策拒絕哪一項。
HKDF-SHA-256 真正運算，root 是公開的固定教學位元組 00…1f，不能保護資料。label/context 用 JSON 陣列明確編碼。政策判斷由指定條件模擬；頁面顯示衍生值供比較，沒有真正 HUK、硬體隔離、DICE CDI 或 read_huk 防護。
學習指南
晶片裡的信任，是怎麼建立的？
查看課程大綱 → · 進度只計入已發布課程
先備知識
- 不要求硬體安全背景，從日常的鑰匙與門鎖開始
我學會了什麼
- 先找出可能繞過後續防線的最弱點，再說明 Root of Trust 應在哪裡錨定保護
- 區分根祕密、Key Storage policy 與衍生工作金鑰
- 沿著資料、caller、operation 與 lifecycle 檢查內部信任
- 說明 Boot ROM、Secure Storage 與 Chain of Trust 如何協作
- 區分 PUF、TRNG、TEE、SE、TPM、DICE 與 HRoT 的責任