先用一句話抓住這篇
從工廠閘道器申請連線開始，循序理解 Secure Boot、Measured Boot 與 Remote Attestation 如何分工，並看懂 TPM/PCR 證據能證明什麼、不能證明什麼。
先把這篇當成一張閱讀地圖：上方摘要說明問題，圖片先建立直覺，下面文字再補上真正的技術取捨。
如果第一次讀覺得名詞很多，可以先記住比喻與結論；第二次再回頭看名詞，會順很多。
工廠的遠端閘道器想連上管理中心，申請執行一項維護工作。中心認得它的裝置身分，卻看不到它剛才如何開機：載入的是核准韌體，還是某個遭替換的版本？「我是那台設備」與「我現在處於可信狀態」是兩個不同主張。
中心需要檢查量測值、可信來源與 freshness，再按服務政策決定權限。Secure Boot 在本機限制哪些程式可以執行；Measured Boot 留下啟動時的量測，供後續證據評估。一次通過評估，不代表設備沒有漏洞，也不保證之後狀態不再改變。PCR 與 signed quote 是本課採用的一種常見實作，不必先懂 TPM 才能跟著走。
1. 設備說自己安全，遠端該相信嗎？
想像你是管理中心的老師傅。工廠閘道器傳來請求：「我是 GW-00123，請讓我執行維護工作。」中心查到序號和帳號都正確，但它沒有親眼看到設備開機，也不能光憑一句自我介紹就知道裡面執行的是哪套韌體。
先把這件事拆成三個問題。要保護的是什麼？這裡是管理中心的維護權限，以及設備接觸到的控制功能。誰在做決定？是遠端管理中心。它看不到設備開機過程，因此必須問：設備能不能提供一份可信的紀錄，讓中心判斷這次連線時載入了哪些元件？
這就是威脅模型的起點：先列出資產、可能的攻擊者、攻擊路徑，以及系統最後必須做出的決策。攻擊者可能試著替換韌體；設備也可能只是更新後版本不同，或遇到設定錯誤。結果不一樣，不代表原因一定是惡意攻擊，但管理中心不能只憑設備自述就把高權限交出去。[1]
因此要分開問「這是誰」和「它現在是什麼狀態」。裝置身分有助於辨認連線來源；啟動證據則要描述特定一次開機中、特定涵蓋範圍內量到的內容。遠端證明就是讓這些證據能被遠端檢查，再交由服務依政策決定權限。
先停一下想想：如果你管理這個服務，會要求設備提供哪一種可檢查的證據？
2. 身分相同，開機狀態也會相同嗎？
把問題想得更具體：同一台設備今天安裝了核准版本，明天可能完成合法更新；也可能有某個元件被換掉。它的序號仍然是 GW-00123，網路憑證也可能仍有效。身分沒有改變，但啟動狀態已經不同。
可以把裝置憑證想成一張可驗證的識別證：它能協助確認對方持有某個受信任的金鑰，卻不會自動告訴你這台設備剛載入哪一版韌體。若設備的憑證沒變、啟動內容卻變了，光看識別證就看不出差異。
啟動測量補的是另一種資訊：在某次開機流程中，平台實際量到哪些程式或設定。這些資料有明確範圍，不會描述設備的一切，也不是憑證本身。管理中心要把身分和狀態證據放在一起看，才能分別回答「哪台設備來了」與「它這次帶著什麼狀態來」。[1]
3. Secure Boot 已經檢查了，遠端為何還要證據？
Secure Boot 的工作重點，是在受保護的啟動流程中，依本機信任資料與政策檢查下一階段程式；不符合規則的項目可以被拒絕，不讓它取得執行權。這是設備內部的執行管制，能降低未授權程式在開機早期搶先執行的風險。
可以沿著開機順序想像：較早執行、受保護的階段檢查下一階段；檢查符合平台政策，才交出控制權。這個決定發生在設備本機，作用範圍也取決於產品實際設定了哪些信任資料與啟動元件。Secure Boot 的價值在於執行管制，不是替遠端服務代做授權。
管理中心若只收到「開機完成」或「Secure Boot 已啟用」，仍要查這句話從哪裡來、涵蓋哪些元件，以及是不是這次連線的新回應。設備自己說「我有檢查」，和遠端驗證者拿到可檢查的證據，是兩回事。前者是狀態宣稱；後者還要有可信的證據來源與驗證流程。[1][2]
所以 Secure Boot 和 Measured Boot 可以分工合作：前者依本機政策決定是否執行；後者把選定的啟動事件留下來，供後續驗證者判讀。遠端服務需要的是後一條證據路徑，才不必把「設備說已檢查」直接當成答案。
4. Measured Boot 記錄的是什麼？
Measured Boot 的核心直覺是留下啟動過程的測量紀錄。系統可以針對納入測量範圍的韌體、Boot Manager、作業系統載入器或設定資料計算摘要，並依序記錄事件。這讓後續的檢查者有機會回頭判斷啟動時發生了什麼。
這裡的「測量」通常不是把整個韌體檔案複製到報告裡，而是對指定內容計算摘要，並記下一筆事件。事件紀錄可以帶有事件類型、摘要，以及協助辨認來源的資訊。比方說，管理端看到一筆韌體事件和一個摘要，之後可以拿它跟可信參考資料比較；摘要本身不會自動說明這個版本是否獲准。
在分階段啟動的設計中，前一階段可在交出控制權前量測下一階段。Boot ROM 可能量測韌體，韌體再量測 Boot Manager，後續階段也可能依平台設計延續這條流程。哪些程式會量、事件怎麼命名、是否涵蓋設定資料，都要看硬體平台、韌體與設定；不能把某一款 PC 的事件清單當成所有設備的標準答案。[2][3]
要特別分清楚：量到某個元件，只能說流程留下了它的測量紀錄，不能直接推論它安全；記錄事件本身也不會阻止程式執行。要阻擋未授權程式，得靠 Secure Boot 這類執行政策。Measured Boot 提供的是可供後續檢查的材料。
5. 為什麼紀錄的順序也重要？
可以把事件紀錄想成一份逐項蓋章的旅程簿：先量韌體，再量 Boot Manager，接著量作業系統載入器。每次新測量都會依特定規則加入先前的累積值。常見 TPM PCR 擴展模型可以簡化寫成「新值 = Hash（舊值 || 新測量）」；這裡的重點不是背公式，而是知道順序會影響最後結果。[2]
PCR 可以先想成晶片內一個固定大小的累積欄位。事件發生時，平台把新測量值和目前 PCR 值一起做雜湊，再把結果寫回；PCR 的值受 TPM 規定的重設與 extend 規則控制，一般軟體不能直接指定成任意內容。這種 extend 操作會把前面的累積狀態帶進下一步。
因此，先量 A 再量 B，和先量 B 再量 A，通常會留下不同的最終值。它不像購物清單，只記得「有 A、有 B」；事件次序也是啟動故事的一部分。驗證者會用事件紀錄按順序重算，再確認結果能否對上受保護暫存器回報的值。[2]
不過，雜湊鏈只涵蓋真的送進 PCR 的事件。如果某個元件從未被量測，它不會因為前後其他階段都留下紀錄，就自動被納入。換句話說，驗證結果的範圍，從設計時選擇量哪些元件就已經決定了一大部分。
6. 如果事件紀錄能被改，還有什麼用？
只把事件清單存在一般儲存區，確實不能假設它永遠無法被修改。常見做法是同時保留可讀的 event log，並把測量結果依序延伸到受保護的 TPM Platform Configuration Register（PCR）。驗證者收到事件清單與 TPM 簽署的 quote 後，可重算事件應導出的 PCR 值，再與 quote 內被簽署的值比較。[2][3]
兩份資料各有工作。Event log 是可讀的逐筆明細，說明哪些事件曾被量測；quote 則由 TPM 對指定 PCR 的當前值簽章，讓驗證者能確認這些值是用對應的 TPM Attestation Key（AK）產生。單看 log，攻擊者可能改內容；單看 PCR，驗證者又只看到累積結果，不知道每一步是哪個事件造成的。
驗證者拿到兩者後，按 log 中的順序重新執行 extend 計算，再把算出的結果和 quote 簽署的 PCR 值比對。若有人刪掉、調換或修改已記錄的事件，重算結果就可能對不上。RFC 9683 以 TPM 網路設備描述了這種作法；不同平台的事件格式與 PCR 配置仍可能不同。[2][3]
這一步能檢查的是「明細和 TPM 簽出的累積值是否一致」，不是「內容是否良善」。如果惡意程式本來就在被量測流程允許的位置，兩份資料仍可能彼此吻合。之後還要檢查簽章金鑰是否屬於可信設備、量測範圍是否足夠，以及這些值是否符合政策。
7. 如何避免拿舊的好證據冒充現在？
假設閘道器上個月曾通過檢查，攻擊者把當時的回應錄下來。若管理中心今天只問「請給我你的證據」，而設備送來一份可重用的舊資料，中心可能無法分辨這是現在的狀態，還是過去某個時間點的狀態。
做法可以分成幾步。管理中心先產生一個新的、難以預測的隨機挑戰值，也就是 nonce，傳給閘道器；閘道器再把這個 nonce 和要回報的 PCR 值放進 quote，由 TPM 的 AK 簽署。管理中心檢查簽章與 nonce：若 nonce 不是這次送出的值，就不能把這份回應當成對本次請求的回答。[1][2]
這能讓上個月錄下來的 quote 無法原封不動重播，因為裡面沒有今天的新 nonce。不過，新鮮 nonce 只說明簽署回應時綁定了這次挑戰；它不會自己保證 PCR 裡每個值都是剛剛才量到。若開機量測早已存在儲存區，直到連網後才拿 nonce 簽署，驗證者還要依系統設計確認這些舊測量是否仍代表目前狀態。[1]
nonce 是常見的新鮮度作法，但不是唯一作法；RFC 9334 也描述時間戳與 epoch ID 等模型。選哪一種，要看設備有沒有可信時鐘、連線流程及雙方保存狀態的方式。重點是讓驗證者判斷「這次拿到的證據，和我這次要求的狀態之間，有沒有可信的時間關係」。[1]
8. 誰提供證據，誰決定放行？
遠端證明可以先用三個角色來理解。裝置上的 attester（證明者）整理並提供關於自身狀態的 claims 與證據；verifier（驗證者）檢查證據是否可信、是否新鮮，以及是否符合既定參考值與政策；relying party（依賴方，也就是要提供服務的一方）再依驗證結果決定開放哪些服務或操作。[1]
放回閘道器的情境，attester 是負責產生設備狀態證據的那一端；它可能包含收集啟動事件的韌體或軟體，也可能搭配 TPM 保護 PCR 與簽署 quote。TPM 不一定自己知道「剛剛執行的是哪個檔案」；通常還需要平台中的其他元件把測量送進去。[1][2]
verifier 接著檢查證據本身：例如簽章能不能用可信的 AK 驗證、nonce 是否吻合、event log 能否重算出 quote 中的 PCR 值，以及測量是否符合參考值與評估政策。它輸出的是一份評估結果，不是直接替設備開門。
最後由 relying party，也就是握有維護服務的管理中心，依自己的政策決定要不要放行、放行多久、開放哪些操作。這三種角色是在描述責任，不一定是三台機器；小型系統可以整合在一個服務，大型系統也可以拆開部署。重要的是授權決策由誰負責，要清清楚楚。[1]
9. 驗證者拿什麼來比較？
設備送來的摘要本身只是一組數值。驗證者需要可信參考資料，才能判斷這個值對應的是哪個已核准元件或版本；還要套用政策，決定哪些版本、設定、裝置身分和執行環境符合目前需求。新鮮度也要一併檢查，否則正確的舊資料可能被誤當成現在的狀態。[1]
例如，某個韌體版本更新後，檔案內容改變，摘要通常也會改變。驗證者要能查到這個新值是否由可信來源提供、適用於哪個設備型號與版本，以及它目前是否獲准使用。不能只因為設備回報一個新摘要，就把它自動加入「安全清單」。
參考值是拿來比對的資料；政策則定義比對規則與可接受結果。規則不一定只有「摘要完全相等」一種，也可能依版本集合、允許範圍，或幾項 claim 之間的關係來判斷。不同設備、不同維護工作也可以有不同門檻。[1]
所以參考資料需要安全的核准、更新與撤回流程。資料太舊，合法更新可能一直被誤報；資料若讓未授權者任意修改，攻擊者就可能把自己的版本登記成可接受狀態。判讀證據的 verifier 必須信任的不只是設備回報，也包括提供參考值的人與政策制定者。[1]
10. 證據不相符，接下來該怎麼做？
若測量結果和目前參考值不相符，服務可以先暫緩高風險操作，再保留事件紀錄與診斷資訊，確認近期是否有核准更新、設定變更或環境差異。若是未預期的變更，就依事件處理流程隔離設備、進一步調查或引導回復到可信狀態。
管理中心可以依風險分級處理。若只是申請低權限的狀態查詢，或許可以限制功能後繼續連線；若要下控制命令、取得敏感資料，就可以先暫停這項操作，保留 event log、quote 與更新紀錄，再由維護流程確認原因。這些是服務政策的選擇，不是 PCR 自己會替管理者做的決定。
不相符是一個警訊，不是攻擊成立的證明。合法韌體剛更新、設備設定與參考環境不一致，都可能造成結果不同；但如果所有未知值都自動放行，攻擊者也可能利用這條捷徑。較穩妥的做法，是把「符合」、「已知但過期」、「未知」和「驗證失敗」分開處理，並預先安排調查、隔離與可信復原路徑。[1]
11. 通過遠端證明，代表設備沒有漏洞嗎？
驗證成功最精確的解讀是：在這一次檢查中，驗證者收到的特定證據符合它採用的規則。它不代表整台設備沒有漏洞，不代表每一個未測量的元件都可信，也不代表檢查結束後設備狀態沒有改變。證據能支持的結論，受測量範圍、證據可信度、參考資料與檢查時間所限制。[1]
這個界線可以從三個缺口看出來。第一，沒有量到的元件不在這份證據裡。第二，即使量測值和可信參考吻合，也只說明所採用的元件或設定符合規則，不代表程式沒有尚未發現的漏洞。第三，quote 對應的是某個測量狀態；設備在回報之後仍可能改變，服務不能把一次檢查當作永久通行證。[1][2]
因此 Remote Attestation 提供的是有範圍、有時間點的證據評估，最後是否信任、授予什麼權限，仍是 relying party 的風險決策。設備若要長期提供服務，還需要韌體更新、漏洞修補、執行期監控和網路隔離等措施，補上開機證據看不到的部分。
12. 回到最初的連線申請
現在，工廠閘道器重新申請連線。管理中心收到這次的新鮮證據，檢查簽署回應與啟動測量，並確認它符合目前維護政策。若結果符合，服務仍不必一次開放所有權限；只授予完成這項工作的必要存取，能限制設備帳號或後續軟體出問題時的影響範圍。
把流程按順序走一次：閘道器先用身分憑證證明自己是哪個設備；管理中心送出本次挑戰；設備把簽署 quote 與 event log 回傳；verifier 驗證簽章、nonce、log 與 PCR，再用可信參考值和政策評估狀態；最後管理中心才依結果開放維護服務。每一關回答的問題不同，不能跳過中間步驟，只看設備宣稱「已安全開機」。[1][2]
符合政策，也不代表要開放整台設備的所有權限。這次申請只是維護工作，就授予完成該工作所需的範圍與時間；如果驗證只得到部分證據，政策也可以只開放較低風險的功能。這樣即使帳號或後續軟體出問題，能造成的影響也比較受限。
三個機制各自回答不同問題：Secure Boot 在本機管制涵蓋範圍內的啟動程式能否執行；Measured Boot 留下選定的啟動測量；Remote Attestation 讓遠端 verifier 評估證據，再由服務決定權限。這是一條由啟動量測、遠端判讀到服務授權組成的流程，沒有任何一個元件能單獨替整台設備背書。[1][2]
最後留一題：如果核准的韌體更新改變了測量值，誰要確認更新確實獲准、何時更新參考資料，又如何避免舊版本趁更新流程回滾？這些作業流程，往往決定遠端證明能否在真實設備群中持續可信。
參考資料
- RFC 9334: Remote ATtestation procedureS (RATS) Architecture，定義 attester、verifier、relying party 與證據評估架構。
- RFC 9683: Remote Integrity Verification of Network Devices Containing Trusted Platform Modules，以 TPM 為基礎的網路設備完整性驗證案例。
- Trusted Computing Group, PC Client Platform Firmware Profile Specification，PC Client 平台韌體測量與事件紀錄相關規格。
重播 event log，和 quote 中的 PCR 一樣嗎？
逐步計算 PCR=SHA256(old PCR || SHA256(event))。先重排 log，查看與 quote 不符；再改 OS 而保持 log 一致，觀察 reference 拒絕。最後重放舊 nonce：簽章仍可能有效，freshness 卻失敗。
真正計算 SHA-256 與 ECDSA 簽署／驗證自編 quote，PCR 從 32 個零 byte 開始。沒有 TPM、TPM Quote 編碼或真實事件格式；trusted key 與 reference 政策由你指定。新 nonce 綁定回應，不保證量測剛發生，也不凍結之後的 runtime 狀態。
學習指南
晶片裡的信任，是怎麼建立的？
查看課程大綱 → · 進度只計入已發布課程
先備知識
- 理解 Secure Boot 與數位簽章會更容易銜接
我學會了什麼
- 區分開機管制與測量紀錄
- 說明如何一起檢查 Event Log 與受保護的測量值
- 把遠端證明結論限制在實際檢查的證據與政策