近期隨著金融聯盟鏈平台逐步成形，黃金代幣的鑄造、交易、交付流程正式把「保管機構」與「參加機構」推上密碼作業的第一線。無論是負責發動交易的參加機構，還是掌管黃金鑄造／銷毀／強制轉帳的保管機構，都必須回答同一個問題：私鑰要放在哪裡、由誰簽、怎麼證明沒有人能繞過控管動用資產？
這篇文章整理我們在協助金融機構落地此類專案時，歸納出的 KMS（Key Management System）建置參考架構，重點放在「兩套金鑰體系」的分工、HSM 內的簽章流程，以及讓高權限操作不會變成單點風險的治理設計。
一、密碼作業橫跨兩套金鑰體系
參加機構介接聯盟鏈平台時，密碼相關工作其實同時發生在兩個完全不同的層次：
| 金鑰體系 | 用途 | 主要演算法 |
|---|---|---|
| 應用層電文金鑰 | 電文加解密、電文簽章，確保傳輸中的訊息機密性與不可否認性 | RSA 簽章、AES-256-GCM |
| 區塊鏈錢包金鑰 | 對鏈上交易物件或結構化資料進行簽章，代表機構對交易的最終授權 | secp256k1 ECDSA、keccak256 |
這兩套體系的風險等級與生命週期管理方式完全不同——電文金鑰保護的是「這則訊息是誰發的、內容有沒有被竄改」，錢包金鑰保護的則是「資產能不能被動用」。把兩者混在同一套金鑰管理邏輯裡處理，往往是後續稽核與擴充時最先出問題的地方，因此在架構設計之初就應該分開對待。
二、三層式保護架構：私鑰全程不出 HSM
典型的聯盟鏈介接架構可以拆成三層保護，每一層各自負責不同的安全目標：
- 第一層（通訊層）：HTTPS + 雙向憑證／API KEY，負責傳輸通道保護與端點識別。
- 第二層（應用層）：電文以全文加密（JWE）保護機密性，並對關鍵欄位簽章（JWS）確保完整性與來源可信。
- 第三層（區塊鏈層）：鏈上交易簽章／驗章，作為交易授權與不可否認的最終依據。
貫穿這三層的核心原則只有一句話：第二層的簽章私鑰與對稱基碼、第三層的錢包私鑰，都必須在 HSM 內產生、保存與運算，全生命週期不得以明文離開 HSM 的密碼邊界。應用系統永遠只透過 HSM 的標準介面（PKCS#11、KMIP 或原生 API）取得簽章結果或密文，本身完全不接觸私鑰明文。這不是口號，而是後續每一個技術決策的判斷基準——凡是會讓私鑰以任何形式（包含記憶體、日誌、備份檔）短暫暴露在 HSM 邊界之外的設計，都需要重新檢視。
三、應用層金鑰：對稱基碼分層與不可匯出的簽章金鑰
應用層電文的機密性與完整性，落地到 HSM 上有幾項具體要求：
- 簽章私鑰不可匯出：電文簽章用的 RSA 私鑰在 HSM 內產生、儲存為不可匯出金鑰，簽章運算也在 HSM 內完成，應用系統只拿得到簽章結果。
- 對稱基碼分層匯入與衍生：上游提供的主金鑰（Master Key）不會直接用來加密電文，而是透過「主金鑰 → 工作階段金鑰 → 一次性工作金鑰」的分層衍生，逐層縮小金鑰的使用範圍與曝險時間，且分層過程本身也在 HSM 內完成，不把主金鑰明文取出到應用層運算。
- 金鑰加密匯入：主金鑰若非由 HSM 自行產生而是外部交付，就必須以加密方式匯入，且從不以明文型態存在於 HSM 之外的任何地方——包含設定檔、日誌、資料庫。
- 安全亂數來源：一次性工作金鑰與初始向量，都由 HSM 內通過驗證的隨機數產生器產出，而非應用層自行呼叫語言內建的偽隨機函式。
- 金鑰識別與輪替：對外金鑰識別碼須對應本地金鑰代號，支撐日後輪替而不中斷服務。
真正的難點在於把這些要求串成一條「主金鑰匯入 → 分層衍生 → 電文加解密」的完整鏈路，且每一步都有稽核紀錄可查。我們的做法是把主金鑰匯入設計成一次性的「金鑰儀式」：主金鑰以雙分量方式由不同人員分別輸入，只有在 HSM 內部組合兩個分量後才還原出可用金鑰，任何單一人員都拿不到完整金鑰材料——這是金融業界對「無人能單獨掌控根金鑰」的標準回應方式。
四、區塊鏈錢包簽章：兩條流程、一個共同限制
聯盟鏈上的交易簽章通常分成兩條路徑，但兩者的密碼學核心是一致的。
交易物件簽章流程（一般轉帳、資金調整等）：
交易物件先經過 RLP 編碼成為未簽章交易，再以 keccak256 雜湊成 32 bytes 的交易摘要，最後才送進 HSM 用錢包私鑰執行 secp256k1 簽章，取得的簽章值再與未簽章交易組合成可上鏈的完整交易。
EIP-712 結構化資料簽章流程（進階授權、鏈下簽核等場景）：
結構化資料依 EIP-712 規則編碼後同樣以 keccak256 雜湊成 32 bytes 摘要，再送入 HSM 簽章。
兩條流程有一個共同且容易被忽略的限制：多數通過 FIPS 認證的商用 HSM，原生支援的雜湊演算法是 SHA-2／SHA-3 系列，並不內建以太坊系統慣用的 keccak256。因此實務上的標準作法是「外部雜湊、HSM 內簽 32-byte 摘要」——keccak256 在受控的應用層計算，HSM 只負責對已算好的摘要做 secp256k1 簽章，並搭配一致性校驗：送進 HSM 的摘要須重新驗算等於對原始交易物件（或 EIP-712 編碼）的 keccak256 值，避免應用層算錯卻沒人發現，實質簽出一筆「非使用者原意」的交易。簽章值也建議採用 low-s（canonical）規範，避免同一筆交易存在兩種合法但雜湊不同的簽章型式，造成延展性（malleability）風險。
五、金鑰治理：把「高權限操作」變成需要多人在場的事
錢包私鑰在 HSM 內產生、不可匯出，只解決了「私鑰不會被偷走」的問題，並沒有解決「誰有權限用這把私鑰做什麼事」的問題。尤其是保管機構角色會涉及黃金代幣的鑄造、銷毀、強制轉帳等高權限操作，一旦被單一帳號濫用，後果遠比一般轉帳嚴重，因此這類操作需要比日常簽章更嚴格的授權機制。
我們採用的模式是 Maker-Checker（雙人覆核）：敏感操作（建立錢包、執行簽章、確認金鑰儀式）由一人發起後不會立即執行，須由另一位具備對應權限、且不同於發起人的人員親自核准才送進 HSM 執行。核准要求核准人現場輸入自己的憑證完成身分驗證，而非靠共用審核佇列被動放行——讓「誰核准了什麼」在事後稽核時有明確且不可否認的紀錄，也讓誤操作在真正碰到 HSM 前有一次人工攔截的機會。
角色分離也應延伸到金鑰本身：簽署者、發送方、擁有者、被授權者若對應不同鏈上地址，就該以獨立金鑰與授權政策分開管理，不要讓同一把私鑰橫跨多種角色語意。
六、錢包配置：不是每個角色都要自建金鑰
實作上常見的誤解，是以為每種業務角色、每個地址欄位都要在 HSM 裡各開一把私鑰。真正需要「自建」（在 HSM 產生私鑰並向平台登記）的通常只有一類：機構自有的操作／簽署錢包——用於收款、出金與帳務調整簽署、進階授權等場景。平台端帶入交易電文的其他地址（保管庫、手續費收款、合約地址）多半是平台既有、直接引用即可。
配置上可依「業務別 × 冷熱分離」規劃：一般參加機構通常落在 1–2 類、2–4 把錢包；同時擔任保管機構則需額外配置角色分離的高權限錢包（鑄造、銷毀、管理員、暫停各一），並套用更嚴格的雙人覆核政策。另要留意：同一個 EVM 地址可同時持有多種代幣，不需為每種幣別各開一把錢包。
七、HSM 選型與驗收檢核清單
最後整理一份可以直接拿去對照 HSM 選型或驗收的檢核項目：
- 認證等級：至少 FIPS 140-3 Level 3，建議搭配 Common Criteria EAL4+。
- 非對稱演算法：支援 RSA-2048 以上（PKCS#1 v1.5 + SHA-256），以及 secp256k1 ECDSA，且能輸出可還原簽章恢復位元的簽章格式。
- 對稱演算法：AES-256-GCM、AES-256-ECB，以及金鑰包裝（key wrap）能力，用於支撐金鑰分層衍生。
- 雜湊相容策略：確認團隊已規劃「外部雜湊 + HSM 簽 32-byte 摘要」的相容方案，而不是誤以為 HSM 原生支援 keccak256。
- 亂數來源：具備通過驗證的隨機數產生器。
- 金鑰管理能力：金鑰可在 HSM 內產生且不可匯出、支援安全備援與多人分持、支援角色分權與操作稽核日誌。
- 介面相容性：提供 PKCS#11／KMIP 或原生 API，方便應用系統整合簽章與加解密呼叫。
- 高可用性：支援叢集或備援部署、金鑰跨節點同步、具備災備方案。
結語
黃金代幣參加機構與保管機構要面對的密碼作業，本質上是兩套風險等級不同的金鑰體系：電文金鑰靠分層衍生控制曝險範圍，錢包金鑰靠「私鑰不出邊界＋雙人覆核」控制動用風險。把這兩套邏輯梳理清楚、搭配具備 Maker-Checker 治理能力的 KMS，才能讓 HSM 的投資真正轉化為可稽核、可擴充的資產保護能力。
我們的 KMS 解決方案即依循上述架構落地——涵蓋 HSM 內錢包產生與簽章、對稱基碼雙分量匯入儀式、Maker-Checker 雙人覆核流程與完整操作稽核軌跡，協助金融機構把這些建置要求轉化為可維運、可驗收的系統能力。