先用一句話抓住這篇
從研究 SoC 的資料外洩案例，逐步理解 DEK、KEK、HUK、使用授權、輪替、撤銷、復原與密碼抹除。12 張漫畫搭配完整講義、工程延伸與 26 項可重跑的教學測試。
先把這篇當成一張閱讀地圖：上方摘要說明問題，圖片先建立直覺，下面文字再補上真正的技術取捨。
如果第一次讀覺得名詞很多，可以先記住比喻與結論；第二次再回頭看名詞，會順很多。
Key Management / Key Hierarchy · MY Academy 漫畫小教室
從一台研究設備開始
實驗剛做完，MY 要把結果留在設備裡，明天再比較不同測試條件下的變化。這批資料還沒發表，不能讓任何裝進設備的程式都讀得到。
沿用上一堂 PUF 小教室的做法，資料先加密，再存進 SoC 的儲存區；保護資料的金鑰則由晶片內隔離的安全服務管理。這裡的「服務」可以先理解成一段專門處理金鑰和密碼運算的程式。其他程式需要解密時，向它提出請求，不直接拿走金鑰。
設備上有兩個用途不同的程式。分析程式需要讀取實驗數據，才能畫曲線、比較結果；診斷工具只需要知道設備是否正常，例如溫度或儲存空間。研究資料不是診斷工作所需的內容，因此 MY 不打算開放它讀取。
這是為課程設計的虛構情境。圖中的曲線與操作紀錄都是教學示意，沒有使用真實研究資料，也不是某款產品的漏洞報告。
01｜匯出被拒絕，為什麼資料還是出去了？
如果你正在帶這個設計，接下來會先查哪裡？懷疑金鑰被偷走很合理。假如對方同時拿到資料密文和對應的金鑰，就可能在別處解開資料。不過，先別把這個猜測當成調查結論。MY 請機器人查看安全服務的紀錄，發現兩筆值得一起看的狀態：一筆匯出金鑰的請求遭到拒絕，另一筆解密請求卻成功了。
先把這兩個動作拆開。「匯出金鑰」要取得的是金鑰本身的內容；「提出解密請求」則可以是請安全服務在內部使用金鑰，再把運算結果交回來。後一種設計不必把金鑰交給呼叫者，也能完成解密。PSA Crypto API 就分別定義了匯出與解密的使用權限，兩者並不是同一個開關。[1]
回到這台設備，即使研究檔一直以密文保存，分析程式仍然需要某種方式取得可以使用的資料。否則資料雖然存下來了，明天也無法分析。設計者因此提供了解密服務。原本方便合法程式工作的入口，如果接受了不該接受的請求，就可能成為明文離開保護範圍的路徑。這是我們接下來要查的假設，還不能只憑一個「成功」狀態就斷定所有細節。
也要留意，單次匯出遭拒，只能說明那次請求沒有被允許。真實事故調查還得確認紀錄可信、請求對得上、沒有其他金鑰副本或洩漏途徑。為了把這堂課的問題看清楚，我們先設定：攻擊者沒有拿到金鑰位元，也沒有進入隔離的安全服務；它能控制診斷工具，讀普通儲存區，並向服務提出請求。
這個設定還有一個重要條件：診斷工具和分析程式是受隔離的不同程式，底層身分機制仍可信。如果診斷外掛直接住在分析程式裡、共用它的身分，後面的判斷就會不同。本課最後會回來處理這個情況。
現在再看一次開場的問題。MY 真正想保護的是研究資料，不只是讓金鑰留在晶片裡。即使金鑰沒有被取走，只要不該讀資料的程式取得了明文，原本的保護目的就沒有達成。
下一步，先沿著診斷工具送出的那筆請求往內看：它指定了什麼資料？服務怎麼知道請求是誰送來的？又在哪裡決定要不要替它解密？
02｜是誰替診斷工具解密？
MY 先把診斷工具送出的內容列出來：它指定了計畫 A 的資料物件，要求執行解密。這種請求不一定包含金鑰本身。程式可以使用一個識別碼，讓服務找出應該操作的金鑰。把識別碼想成管理櫃上的編號就好；知道第幾格放什麼，並不能決定你有沒有權利打開它。
接著往服務內看。它找到了資料、找到了金鑰，也成功完成解密，卻漏掉了「這個呼叫者是否可以讀取計畫 A」的判斷。於是金鑰仍在服務裡，明文卻被交給診斷工具。開場的兩筆紀錄可以同時成立，並沒有要求密碼演算法先被破解。
這裡要區分兩層政策。一層是某把金鑰能不能做解密、簽章或匯出；另一層是眼前的呼叫者能不能對這個物件要求這項操作。即使 DEK 被設定為允許解密，也不代表所有程式都可以請它解任何檔案。PSA 定義金鑰使用旗標；TF-M 的服務設計還處理呼叫者身分與金鑰擁有者資訊，兩者不能混成同一項檢查。[1][2]
此例把問題鎖定在漏查物件權限，並假設請求傳遞及身分來源可信。實際設計還要確認識別碼不能被替換成另一個物件、服務不能被誘導使用錯誤金鑰，以及回傳結果沒有送到別人的緩衝區。先找清楚服務替誰做了哪件事，才知道要修哪個位置。
03｜哪把鑰匙保護研究資料？
在修正入口之前，MY 把研究檔案的保護方式畫出來。直接拿來加密研究資料的金鑰叫 DEK，也就是 Data Encryption Key。這堂課選擇由安全服務用密碼學用途的亂數產生器建立 DEK。資料加密後，普通儲存區可以保存密文，但不應把未受保護的 DEK 一起放在旁邊，讓同一個讀取動作把兩者都拿走。
因此再用一把 KEK，Key Encryption Key，保護 DEK。把金鑰作為被保護的輸入，經過適當的金鑰包裝操作，輸出一份可以保存的包裝資料。這個包裝除了要隱藏 DEK，也要能發現不應被接受的竄改。NIST 的 key-wrapping 文件把這類操作與一般資料用途的加密分別討論。[7]
分析程式要讀資料時，安全服務先用 KEK 解開包裝，取得 DEK，再用 DEK 解密資料。這些金鑰位元可以一直留在服務邊界內；程式收到的是它被允許取得的結果。圖上把先後順序拆開，是為了指出角色分工，並不表示實作一定得把中間 DEK 複製到一般處理器可讀的記憶體。
同一個系統也可以採不同的建立方式，例如從根金鑰衍生資料金鑰，或使用安全硬體提供的金鑰插槽。本課選用「隨機 DEK 加包裝」的組合，好讓稍後的輪替與復原容易看清楚；不能反過來把這個例子當成所有 SoC 唯一的設計。資料加密仍須選好模式並管理 nonce、認證標記與物件中繼資料，畫一個鎖頭不代表這些工作都已完成。
04｜計畫 B 也用同一把鑰匙？
研究設備開始處理第二個計畫。沿用原本的 DEK 最省管理工作，但若那把金鑰外洩，對方拿到兩個計畫的密文就可能一起讀。MY 決定替計畫 B 建立另一把 DEK。這會多出一份金鑰紀錄與包裝，也換來較清楚的暴露範圍：只有 DEK-A 被取得，不等於 DEK-B 已經跟著洩漏。
接著是保護這些 DEK 的 KEK 要從哪裡來。沿用上一堂的概念，HUK 是裝置根金鑰的一種角色，來源可以是 PUF 支援的設計，也可以採其他安全建立與保存方式。本例讓 HUK 經過 KDF，也就是金鑰衍生函數，配合明確的儲存用途資訊，產生儲存用 KEK。根金鑰不直接拿來處理每份研究檔案。
用途資訊需要穩定、無歧義的編碼。儲存與其他服務不能意外送入完全相同的資訊。HKDF 的 info 欄位可以綁定應用與情境。[5] 服務仍須檢查誰能要求衍生哪個用途；如果任何程式都能索取任意用途的祕密，取不同名字沒有建立權限隔離。
這裡也沒有「分層後任何外洩都互不影響」的保證。DEK 分開，主要限制單一 DEK 暴露的範圍；共同 KEK 或 HUK 若失陷，影響可能沿著它能解包裝或衍生的路徑擴大。通訊金鑰則另看協定。TLS 1.3 的 traffic keys 來自握手祕密及其推導流程，不能為了把圖畫得整齊，就把所有 session keys 都掛在 HUK 下。[6]
05｜誰可以用哪把金鑰？
現在回來修入口。MY 讓分析程式與診斷工具各送出同一個「讀取 A」請求。單看資料物件與操作名稱，兩筆請求可以完全一樣。服務還需要知道發出請求的是哪個主體，而且這個身分不能只取自請求裡一句「我是分析程式」。否則診斷工具換個字串就能冒用。
本例假設作業系統和隔離機制仍可信，能把不同程式的請求綁到可靠身分。服務再將這個身分與物件 A、所需金鑰、允許的操作、目前狀態一起比對。透過檢查的請求才進入解密；不通過的請求在回傳明文之前就被拒絕。TF-M 的呼叫者及 key-owner 設計可以作為具體閱讀例子，真正的隔離保證仍由平台與系統整合決定。[2]
政策也必須約束物件與金鑰的對應。如果應用可以任意指定「拿 A 的權限配 B 的金鑰」，只查到帳號合法仍可能做錯事。實作通常需要讓服務擁有這項綁定，並驗證請求參數、輸出位置與中繼資料。加密旗標本身不會替應用補上這些判斷。
修補後，分析程式仍能讀 A；診斷工具讀 A 被拒絕，查設備狀態則照常成功。這組結果支持「原本未授權的讀取路徑受到限制」。它沒有證明合法分析程式永遠不會被控制，也沒有證明安全服務沒有其他漏洞。把這個結論說準，後面驗收才不會把一個成功測試擴大成整台設備的安全保證。
06｜定期換 KEK，要重加密所有資料嗎？
MY 收到定期輪替包裝金鑰的維護需求。設備裡已存了許多研究檔，如果每換一把 KEK 都重寫所有資料，時間與寫入成本可能很高。不過，先看圖上的作用對象：KEK 包裝的是 DEK，研究資料本身是由 DEK 加密的。只要 DEK 沒換，資料密文不一定需要改動。
在可信服務內，用 KEK-v1 解開既有包裝，再把同一把 DEK 交給 KEK-v2 重新包裝，便得到新版包裝資料。這個動作叫 rewrap。它讓包裝層換用新的金鑰，而沒有假裝資料金鑰也跟著變成另一把。保留分層關係，維護人員才容易判斷哪些檔案必須搬動。[3]
切換不能只做一個覆寫動作就結束。先建立新包裝，確認能解開且能讀取對應資料，再切換有效版本；舊包裝依保存與安全政策處置。若途中斷電，系統要知道目前到哪一步，避免只剩一份打不開的資料。要不要短暫保留雙版本，以及何時清除舊版本，須在可用性和暴露風險之間作明確選擇。
這個流程不能直接套用到「舊 KEK 已被偷」的事件。對方若也取得它能解開的舊包裝，相關 DEK 就可能受到影響。刪除本機舊包裝不會把對方手上的副本一起刪掉。正常輪替處理的是持續維護，事故復原還得評估祕密到底暴露到哪一層。
07｜DEK 外洩，只換外層夠嗎？
這次調查發現，計畫 A 的 DEK 確實已被取得。研究團隊提出一個看似省事的做法：趕快換 KEK，把 DEK 重包裝就好。然而攻擊者已經有 DEK，不需要再走解包裝路徑。對方拿著原有 DEK 與原有密文，依然可以解密；新包裝對這組副本沒有作用。
MY 必須先處理造成入侵或洩漏的路徑，再在可信環境建立新的 DEK。如果入侵者仍控制新金鑰會出現的位置，換再多次也可能繼續外洩。受影響的舊 DEK 不再用來加密新資料；現存仍需要保密的資料，則按風險與保存需求安排重新加密、驗證和版本切換。[3]
遷移過程需要把舊資料解開，因此舊金鑰可能仍須在受控條件下暫時用於復原或讀取。這不等於允許它繼續保護新資料，也不能忽略內容可能遭竄改的風險。維護紀錄要分清楚「為遷移讀舊資料」與「繼續使用舊鑰加密」，不能只用一個啟用／停用字樣概括所有階段。
新 DEK 可以保護後續資料，也可以保護完成遷移後的新副本，但無法收回對方早已帶走的明文。若舊密文與舊 DEK 仍在對方手上，它們也不會因本機切換成功而失效。事件回報因此要分開寫：已阻斷的路徑、已換新的範圍，以及必須承認已失去保密性的資料。
08｜合作人員離開，該撤銷什麼？
合作研究結束後，MY 要取消合作帳號的讀取權。若先前對方只能透過服務讀取，而且沒有取得金鑰副本，那麼服務拒絕這個身分的新請求，就是停止後續線上存取的重要一步。沒有必要僅因一個帳號退出，就不加判斷地把整台設備的所有金鑰換掉。
但若對方曾持有共享 DEK 或能自行解包裝的祕密，停用帳號無法限制它在別處處理已有副本。此時要另外評估金鑰共用範圍與後續換鑰。撤銷身分解決誰可以再進來；停用版本決定服務接受哪把金鑰；更換祕密則更新密碼保護所依賴的材料。這些工作可能同時發生，目的卻不同。[3]
還有一個容易漏掉的問題：攻擊者把政策檔還原成「合作仍有效」時留下的舊副本，怎麼辦？那份檔案可能有正確的認證標記，因為它過去確實合法。但驗證內容未被竄改，不等於驗證它仍是現在應使用的版本。需要防止這類回復時，版本狀態就不能和可被一起還原的政策檔放在同一個可回復範圍。
可採的方式取決於平台，例如由可信元件維護狀態，或向權威服務確認目前政策。這堂課只要求讀者看出問題，不把某種計數器畫成通用解法。至於合作期間已被合法下載的資料，也不會因撤銷成功而消失；資料使用與保存條件還需要另外管理。
09｜晶片壞了，資料救得回來嗎？
研究設備故障，原 SoC 無法再工作。MY 還保留完整的資料密文與本機 DEK 包裝，以為把它們搬到新設備就能繼續分析。可是本機包裝綁在原設備的 KEK，而新設備有不同的根金鑰。若沒有其他可用的路徑，備份雖然一個位元都沒少，仍可能無法解開。
這不是加密失敗，而是原本「只有這台設備可以解」的設計在故障時繼續發揮作用。真正該問的是，研究資料是否允許在失去原晶片後復原。如果答案是需要，就必須在資料建立時準備合適的復原材料及流程，不能等晶片壞掉才要求它生出另一把鑰匙。[3]
本例可以替同一把 DEK 建立第二份受保護的包裝，由獨立的復原 KEK 保護。故障後，經核准的復原服務在受控環境解開這份包裝，再為新設備建立它能使用的包裝。這条路不要求把 HUK 匯出，但確實新增了一個值得保護的入口；復原金鑰的保管、核准者、執行環境與稽核都成為信任範圍的一部分。
當然，不是每種資料都必須可復原，也不是每種金鑰都適合備份。MY 要把可用性需求先寫清楚：可以接受設備遺失時資料一併失去，還是必須保留受控的替代路徑？兩個選擇都需要承擔後果。若允許復原，就不能同時宣稱任何情況下都只有原晶片有能力解密。
10｜刪了金鑰，就能安心報廢？
幾年後，這台研究設備要報廢。MY 執行刪除金鑰，服務回覆成功，機器人卻拿出當年留下的復原包裝。它提醒了一個具體問題：目前刪掉的是一個可查詢的編號、一份本機金鑰，還是所有能夠重建解密能力的材料？這三種結果不能混用同一份完成證明。
如果任務只是讓報廢設備不再洩漏資料，研究團隊可能仍需要保留正式備份。這時驗收聚焦在交出去的設備及其殘留內容，不必假裝研究資料從此在所有地方都消失。若任務是清除整份研究資料，保存於別處的密文、金鑰、復原包裝和明文副本就都需要納入範圍判斷。
密碼抹除利用適當加密與金鑰清除，讓目標密文的解密在指定條件下不可行。它依賴金鑰副本與實作的處置，不能只看一般 API 是否找不到某個 ID。NIST SP 800-88 Rev. 2 特別討論金鑰備份、託管與清除條件；外部副本必須依相應政策管理。[4]
還要找出重建路徑。例如 DEK 可以由仍存在的根金鑰與公開標籤重新衍生，單純刪除當前 DEK 物件可能不夠；如果已留下明文快取，刪除金鑰也不會改變那份快取。對本課的隨機 DEK 設計，則要盤點本機與復原包裝、能打開它們的金鑰以及曾經產生的副本。最後留下的紀錄應說明範圍、操作、驗證與限制，而不只是一個綠色勾號。
11｜怎麼確認原本那條路被堵住？
MY 把第一天那筆「診斷工具讀 A」的請求拿回來，放進修補前與修補後的服務模型。前者得到明文，後者在授權檢查被拒絕。接著用合法分析身分讀同一個物件，仍然成功。這樣同時確認錯誤路徑受到限制，以及必要工作沒有一起被破壞。
匯出測試也要保留，但它不再是唯一指標。本例的匯出在修補前就被拒絕，因此「匯出失敗」無法分辨漏洞有沒有修好。能分辨兩者的是診斷工具能否透過另一項操作拿到不該取得的資料。測試項目應針對要證明的主張設計，不要選一個本來就會通過的操作當作結案依據。
還要換幾個條件。讓診斷工具自報成分析程式，看看服務是否忽略這個不可信聲明；讓僅能讀 A 的身分改讀 B，確認物件邊界；再測已撤銷的身分、被改過的物件標籤與舊版政策。失敗時要能從紀錄知道是授權、完整性或版本檢查在哪裡作出判斷，但不要把金鑰或研究明文寫進一般日誌。
隨教材附的模型只在一般程式環境演示這些關係，並用合成資料做加密與包裝。它不是真正的 TEE、PUF 或防竄改硬體，也不能證明實體攻擊、側通道或正式平台隔離已被驗收。模型可以幫讀者看懂因果；正式產品仍須把同一組問題帶回實際硬體、軟體與部署條件逐項驗證。
12｜如果被攻陷的是合法分析程式？
最初的診斷工具沒有讀 A 的權限，所以補好可信身分與物件檢查，就能限制那條路徑。現在改成分析程式本身被攻擊者控制。它發出的請求可能使用正確身分、正確物件和原本允許的操作，服務因此照常回傳明文。權限表並沒有失效；問題是原本受信任的使用者端不再值得同樣信任。
如果工作真的需要把完整明文交給分析程式，系統就必須承認這個程式以及能讀取它記憶體的元件屬於重要信任範圍。若工作只需要某個計算結果，可以考慮把敏感運算留在適合的可信邊界內，對外提供範圍較窄的操作。這會增加服務實作與驗證成本，也可能限制應用彈性，不能只畫一個安全區就當作免費解答。
縮小輸出也需要檢查實際資訊量。只回平均值或統計結果，不代表沒有洩漏；反覆查詢、任意挑選資料子集合，仍可能讓對方推算出不該知道的內容。因此物件、操作、查詢條件與輸出政策要一起設計。金鑰留在晶片內，對降低金鑰直接暴露仍有價值，但不能替代這些資料使用限制。
回頭看這台設備，已經可以逐項回答：DEK 處理研究資料，KEK 保護 DEK，HUK 可支援指定用途的根；服務決定誰能對哪份資料做什麼；輪替、撤銷、救援與退役管理的是不同時刻的需求。開場外洩的原因，是服務替沒有讀取權的診斷工具解密。修補後這條路受到限制；換成合法程式遭控制，就需要重新檢查信任與輸出的範圍。
延伸問題留給讀者：Secure Boot 驗證程式後，如果它在執行中遭控制，啟動時的驗證能替代哪些執行期保護，又有哪些不能替代？先用這堂課的方式畫出資產、請求與信任邊界，再決定需要增加什麼機制。
可執行教學示範：實際測試結果
以下是合成資料教學模型的實際結果，不是晶片安全認證。身分發行、隔離與可信版本狀態由測試程式假設；沒有執行真實惡意程式，也沒有接觸正式資料。
26/26 PASS · 2026-10-05 · 依原講義 26 個案例重建並重新執行下載版；這是新一輪結果，非恢復舊紀錄。
展開全部測試
P01修補前也拒絕匯出 — PASSP02缺物件授權時，診斷工具取得明文 — PASSP03修補後，診斷讀取遭拒 — PASSP04合法分析仍可讀取 — PASSP05診斷狀態查詢仍可使用 — PASSP06自報分析身分不會提升權限 — PASSP07偽造 session 物件被拒絕 — PASSP08僅能讀 A 的身分不能讀 B — PASSP09撤銷後拒絕新請求 — PASSP10修補後仍拒絕金鑰匯出 — PASSP11DEK-A 不能解開 B 的密文 — PASSP12不同用途產生不同衍生金鑰 — PASSP13正常 rewrap 保留同一 DEK 與資料密文 — PASSP14修改受驗證的包裝中繼資料會使驗證失敗 — PASSP15修改資料物件標籤會使驗證失敗 — PASSP16竄改密文不能取得已驗證的結果 — PASSP17已外洩 DEK 仍能解開舊副本 — PASSP18舊 DEK 不能解開新 DEK 的密文 — PASSP19持有父金鑰可重算新版標籤的金鑰 — PASSP20新晶片根金鑰無法自然開啟原機包裝 — PASSP21預先建立的復原路徑可遷移到新設備 — PASSP22刪本機引用不消除保留的復原路徑 — PASSP23舊政策可驗證，但可信版本狀態仍拒絕它 — PASSP24合法程式失陷仍可使用既有權利 — PASSP25可讀 A 也不能指定 B 的金鑰 — PASSP26換 KEK 不會使外洩舊 KEK 與舊包裝失效 — PASS
執行方式：node proof.mjs
工程師延伸
一、呼叫者身分究竟可信到哪一層？
本課讓診斷工具和分析程式處於不同隔離主體，並把底層身分傳遞視為可信。若平台只區分安全世界與一般世界，卻把所有一般世界程式視為同一個 caller，就無法直接實現圖中的應用級權限。需要檢查平台如何建立主體、如何傳遞身分，以及能否防止較低信任元件偽造。
TF-M 的 Crypto service 會把呼叫者與 key owner 納入設計，但平台是否能可靠區分非安全端客戶端，仍是系統整合議題。[2] 同一程序中的外掛、被控制的核心、DMA 能接觸的緩衝區，都可能改變原假設。若 API 使用能力權杖，也須討論權杖能否被偽造、轉交、撤銷和限制範圍，不能把本課「一般 ID 不是授權」誤讀成所有 handle 設計都一樣。
二、金鑰建立與中繼資料，不能只保護 key bytes
建立方式可以是安全產生、受控注入或衍生。每種選擇都需要交代來源信任、祕密出現的位置，以及失陷時哪些金鑰一起受影響。KDF 的用途與版本編碼要避免歧義；僅改公開 label 不提供父金鑰失陷後的前向保密，因為持有父金鑰者可能重算相同輸出。[5]
包裝與資料加密也要保護相關中繼資料。若使用 AEAD，物件 ID、用途、版本等可以納入經認證但不必隱藏的資料；哪一些欄位被綁定必須明確。nonce 必須符合所選演算法的要求，不能因金鑰留在硬體裡就忽略。驗證失敗的中間明文不得交給呼叫者。教學模型用 AES-GCM 示範這種綁定，不把它冒稱為 AES-KW 或 AES-KWP 實作。[8]
三、輪替與撤銷：中斷後怎麼復原？
建立新包裝、驗證、切換、清理可以視為不同狀態，並為每一步規定斷電後的重試行為。切換前需要知道新資料與包裝是否一致；清理前要確認沒有必要讀取仍依賴舊版本。保留舊版有可用性價值，也延長相關暴露窗口，不應無限期保留而沒有政策。
資料或政策的認證成功只表示驗證所承諾的完整性條件，不代表版本最新。需要防回復時，可信版本狀態不能和被還原的儲存快照一起倒退。另一方面，父金鑰失陷時，改版本名稱或把同一 DEK 包在新 KEK 裡，不能消除舊副本的解密能力。必須依實際可衍生、可解包裝及已複製的範圍評估替換工作。[3]
四、把復原清單反過來，就是退役時的檢查起點
復原設計記錄了資料能被救回的途徑：哪些包裝、哪個保管者、哪個設備或服務能重新取得 DEK。當任務變成清除全資料，這份清單就能幫忙找出不應遺留的路徑。清除本機與清除所有副本的範圍要分開，不然維運團隊保留備份、退役團隊又宣稱完全不可恢復，兩份報告會互相矛盾。
JavaScript 或一般作業系統上的教學程式無法證明所有記憶體副本都已歸零；垃圾回收、複製、swap、除錯及備份都是限制。模型因此只展示「存在某條復原路徑時，仍可能解密」的反例，不把刪除一個物件當作完成密碼抹除。正式處理依平台能力、保存政策與驗證程序執行。[4]
五題理解檢查
1．匯出被拒、解密成功，先查哪裡？
先追查誰提出解密請求、針對哪份物件、服務是否授權以及明文送到哪裡。不能只憑結果判定加密被破解，也不能從一次匯出拒絕推論所有金鑰洩漏途徑都不存在。
2．正常 KEK 輪替與 DEK 已外洩，為何不能都只 rewrap？
正常輪替可以更換保護 DEK 的包裝，不改動同一 DEK 加密的資料。DEK 已外洩時，持有它的人不需要開新包裝就能解舊密文；須處理受影響 DEK 與仍需保護的資料，也不能追回已外流副本。
3．只有密文備份，原晶片壞了能自然復原嗎？
不能假設可以。還需要可用的解密金鑰或預先設計的受控復原路徑。新晶片的根金鑰不同，不會自動解開原晶片專用包裝；事後也不能憑空補出已失去的祕密。
4．刪掉本機金鑰編號，是否完成全資料清除？
尚不能如此宣告。要確認目標範圍與金鑰副本、包裝、復原、重衍生及明文路徑。若只退役本機，受控備份可能仍應保留；若要清除整份研究資料，就不能忽略那些副本。
5．分析程式被控制，正確身分檢查一定會拒絕嗎？
未必。它可能仍使用原本獲准的身分與操作。必須重新評估這個程式能接觸的物件與明文、是否要內移計算，以及輸出可能洩漏什麼。ACL 不會自動判讀合法請求背後的惡意。
名詞與閱讀路徑
| 名詞 | 在本例負責的工作 |
|---|---|
| DEK | 資料加密金鑰，直接保護研究資料。 |
| KEK | 金鑰加密金鑰，保護 DEK 的包裝。 |
| HUK | 硬體唯一金鑰，裝置根金鑰角色；本例用於指定用途衍生。 |
| KDF | 金鑰衍生函數，從輸入祕密與上下文產生指定用途的金鑰材料。 |
| Rewrap | 更換金鑰包裝，內部被包裝的 DEK 可以保持相同。 |
| 授權 | 決定指定身分可對哪些物件執行哪些操作。 |
| 密碼抹除 | 在適當加密與金鑰清除條件下，使目標密文的解密不可行。 |
先修可回看 PUF 的資料金鑰／HUK 分工；通訊金鑰另接 TLS 小教室。下一個設計問題是：裝置啟動後，怎麼持續限制已獲准程式的能力？
#HardwareSecurity #KeyManagement #KeyHierarchy #HUK #PUF #SecureStorage
參考來源
以下為概念與機制來源；故事、角色對話及教學模型為本課自編。查閱日期：2026-09-09。
- NIST SP 800-57 Part 1 Rev. 5，Recommendation for Key Management，§5.5、§8.2、§8.3 與附錄 B。
- RFC 5869，HKDF，§2–3。
- RFC 8446，TLS 1.3，§7.1–7.3。
換 KEK 包裝，能救回已外洩的 DEK 嗎？
追蹤同一 DEK 的兩份 AES-GCM 包裝，再核對資料密文雜湊完全沒變。改成診斷 caller 或 project-B，觀察「key 可解密」為何仍不能授權物件。最後看已持有 DEK 者仍能解舊密文。
加密、兩次包裝／解包與舊 DEK 解密都由 Web Crypto 真實執行，使用新隨機 nonce。根材料公開且固定，DEK 僅為教材；頁面內部有 raw DEK，不能證明 non-exportable 硬體或記憶體歸零。caller、物件、usage 與撤銷是獨立政策模型；拒絕不代表能識別已獲准程式的惡意。
學習指南
晶片裡的信任，是怎麼建立的？
查看課程大綱 → · 進度只計入已發布課程
先備知識
- PUF 與基本資料加密
我學會了什麼
- 區分金鑰匯出與授權使用
- 說明 DEK、KEK 與 HUK 分工
- 規劃金鑰輪替、撤銷、復原與抹除