[設計案例] 授權碼 如何實作? #3 (補) - 金鑰的保護
摘要提示
- 金鑰管理核心: 安全不在演算法而在金鑰，特別是私鑰與公鑰的妥善管理。
- 私鑰保護: 私鑰一旦外洩，攻擊者可偽造任何授權碼。
- 公鑰發放風險: 公鑰若被調包，客戶驗證將信任錯誤的簽章來源。
- 內建公鑰方案: 在受控環境把公鑰內建於系統並透過硬體/OS保護，降低替換風險。
- CA 第三方信任: 透過憑證授權單位發行與查詢公鑰，建立可驗證的信任鏈。
- CA 成本與複雜度: 使用公正 CA 需付費與建置整合，自己架 CA 也有治理成本。
- 強制連回驗證: 綁定更新、定檢與合約流程，迫使系統需與原廠或信任源對接。
- 實務類比: 遊戲主機與 Windows/KMS 的簽章與啟用機制是可借鏡的作法。
- 架構設計重點: 產碼端保護私鑰、驗證端取得正確公鑰，是整體安全關鍵。
- 策略選擇: 在成本、控制與風險間取捨，採用 CA 通常是最穩健的正規做法。
全文重點
本文延續前篇數位簽章的授權碼架構，補充實務中最關鍵卻常被忽略的環節：金鑰管理。數位簽章的安全性來自公開演算法加上正確的金鑰管理；演算法人人可得，真正決定安全的是私鑰與公鑰如何保護與發放。
在授權碼的運作中，原廠以私鑰簽出授權碼，客戶端以公鑰驗證。維運的首要重點是私鑰必須絕對保密；其次是公鑰要能正確、可信地到達客戶端。文中提出一個常被忽略的攻擊情境：合作方不需竊得原廠私鑰，只要自製一組金鑰，用其私鑰簽發假的授權碼，再把客戶端的公鑰替換為其自製公鑰，便能通過驗證，達到偽造授權的效果。此例凸顯「公鑰取得的真實性」是信任鏈的薄弱點。
對策有三類。其一，在受控平台將公鑰內建於系統並受 OS/硬體保護（如遊戲主機與 TPM 的做法），從源頭避免公鑰被替換。但此途徑仰賴可控制的硬體/軟體環境與安全啟動，對一般軟體商成本高、門檻大。其二，導入憑證授權單位（CA）做第三方信任。由 CA 簽發憑證，外界透過 CA 取得並驗證你的公鑰與識別資訊，形成可驗證的信任鏈與撤銷機制。此作法更安全、通用，但需支付年費並整合 PKI 流程；自建 CA 則需確保使用者皆在可控範圍且承擔治理成本。其三，若無法走上述完整路線，可以透過營運與流程綁定來「強迫連回信任源」：例如由原廠提供受簽章保護的更新包、定期連線回原廠檢測、以維護合約或實體流程發放關鍵代碼等。這些措施能在實務上揪出使用錯誤公鑰的環境，降低被調包的風險。文章以 Windows 啟用與企業 KMS 為例，示範「定期回源驗證」的有效性。
總結來說，授權碼系統的堅固程度不取決於程式碼巧妙與否，而在於金鑰管理品質與信任鏈設計。若預算允許，採用 CA 是最安全可靠的常規方案；若受限於成本或環境，則應在可控平台內建公鑰並加上回源驗證與營運綁定，疊加多層保障。設計者需依規模、風險、成本做務實取捨，並持續關注鍵結點：私鑰保護、公鑰配送的真實性與可驗證性，以及必要時的連線核驗策略。本文為數位簽章主題的補遺，後續將延伸到 API 等應用面向。
段落重點
數位簽章與金鑰管理的補充說明
本文補足前篇僅談架構未談實務的缺口：數位簽章雖安全，但關鍵在金鑰管理。原廠以私鑰生成授權碼，客戶端用公鑰驗證；因此私鑰必須嚴密保管，公鑰需可靠地發放到客戶端。只要私鑰外洩，攻擊者即可偽造授權碼；而即便私鑰安全，若公鑰被替換，驗證也會被誤導，整體安全瓦解。
安全風險情境：公鑰被調包的攻擊面
提出實際威脅情境：合作方自建金鑰對，用其私鑰簽假授權碼，再將客戶端公鑰替換為其自製公鑰，即可通過驗證而不需竊得原廠私鑰。此例指出系統常忽略的薄弱點在「公鑰的真偽與配送管道」，若無法保證客戶拿到的公鑰正確，所有簽章保護等同虛設。系統設計需同時守住私鑰與公鑰信任來源。
預先在系統內埋好你的 PUBLIC KEY
在可控環境中，可將公鑰內建於系統，並透過 OS/硬體機制（如 TPM、安全啟動）保護，避免被替換。遊戲主機即採此模式：在載入內容前先驗簽，未簽章或假簽章內容無法執行。此法依賴平台可控制且有防護機制，安全性高，但需硬體支持與生態建置；破解多藉由繞過安全啟動或利用平台漏洞，顯示實作需嚴謹。
透過 CA 發行 PUBLIC KEY
若無法完全控制客戶環境，可引入 CA 以第三方信任鏈發放與驗證公鑰。憑證除包含公私鑰對，還綁定主體識別，客戶端可向 CA 查驗公鑰與其有效性。此途徑讓攻擊者難以憑非正式管道「掉包」公鑰，並可利用撤銷與到期管理提升安全。不過採用公正 CA 需年費與整合成本；自建 CA 則要求用戶群在管轄範圍且需投入治理與運維。
透過其他手段，強制客戶必須連回原廠驗證
若不走 CA、也無法像主機平台般封閉，可採營運與流程性的折衷方案：由原廠提供受簽章保護的更新包，若公鑰錯誤則無法升級；要求系統定期回連原廠或受信伺服器做健康檢測；透過維護合約或線下流程發放關鍵碼，讓未對齊信任鏈者無法持續使用。Windows 啟用與企業 KMS 是可參考的體系：用戶端定期回源或回企業 KMS 以維持授權有效。
結語：選擇合適的信任策略與治理
作者強調跳過 Key Store 細節，是因為金鑰管理遠超程式層面，牽涉營運與治理。最穩健的方式通常是採用 CA；若成本或環境限制，則在可控平台內建公鑰並疊加回源驗證與營運綁定。實務上需在安全、成本與可行性間取捨，但不變原則是：系統安全性取決於金鑰如何被管理，而非演算法或程式碼本身。後續系列將續談 API 等應用。
資訊整理
知識架構圖
- 前置知識：
- 非對稱加密基礎：Public/Private Key 的角色與差異
- 數位簽章原理：簽章、驗證流程與不可否認性
- PKI 與憑證概念：CA、憑證內容與信任鏈
- 威脅模型基礎：攻擊面、內外部威脅、信任錨(Trust Anchor)
- 核心概念：
- 私鑰保護：授權碼生成的唯一信任根基，外洩即全盤皆輸
- 公鑰發放與完整性：驗證端的信任錨，若被替換則可偽造一切
- 公鑰替換攻擊場景：不需竊取私鑰，只要掉包公鑰即可繞過驗證
- 信任錨部署策略：內嵌公鑰、使用 CA、或在線驗證
- 維運與治理成本：安全 vs 可行性與成本的權衡（費用、流程、組織範圍）
- 技術依賴：
- 授權碼生成依賴私鑰簽章
- 授權碼驗證依賴正確公鑰與可靠的分發/查詢機制
- 內嵌公鑰方案依賴平台保護機制（如 TPM/OS 保護）
- CA 方案依賴 PKI 架構與第三方信任、憑證管理
- 在線驗證/回連方案依賴網路可達性與伺服器可用性
- 應用場景：
- 商業軟體授權碼生成與驗證
- 遊戲主機/封閉平台對原版內容的驗證（內嵌公鑰 + 平台信任）
- 企業/校園授權（類 KMS 模式的定期回連驗證）
- 軟體更新機制（簽章的更新包與驗證流程）
學習路徑建議
- 入門者路徑：
- 了解非對稱加密與數位簽章基本概念
- 練習產生金鑰對、用私鑰簽章與公鑰驗證
- 實作最小可行的授權碼生成器與驗證器（不含發佈機制）
- 進階者路徑：
- 研究公鑰分發風險與替換攻擊模型
- 評估與實作三種信任錨策略：內嵌公鑰、使用 CA、在線回連
- 學習金鑰保存技術（OS/TPM/HSM/KeyStore）與操作流程（輪替、備援）
- 實戰路徑：
- 在產品中部署授權碼簽章與驗證，並落地一種以上的信任錨策略
- 建立公鑰/憑證的發放與更新流程（含異常偵測與告警）
- 設計回連/更新包簽章流程，並在維運中監測合規與風險
關鍵要點清單
- 私鑰保護是核心信任根：授權碼可信度完全仰賴私鑰安全 (優先級: 高)
- 公鑰分發完整性：驗證正確性取決於客戶端是否拿到正確公鑰 (優先級: 高)
- 公鑰替換攻擊：無需竊取私鑰，只要掉包公鑰即可偽造授權碼 (優先級: 高)
- 內嵌公鑰作為信任錨：將公鑰固化在系統/裝置中，可降低被替換風險 (優先級: 中)
- 平台安全支援（TPM/OS 保護）：內嵌公鑰需倚賴平台保護與防繞過 (優先級: 中)
- 使用 CA/PKI 發放公鑰：由第三方建立信任鏈，降低掉包風險 (優先級: 高)
- CA 成本與治理：採用公有 CA 有費用與管理負擔，自建 CA 有範圍限制 (優先級: 中)
- 在線回連/強制驗證：透過定期連線或啟用流程逼出不正確公鑰配置 (優先級: 高)
- 簽章的更新包機制：更新包必須簽章與驗證以維持後續信任 (優先級: 中)
- 實體/合約管道發放：以維護合約或實體流程加強管控關鍵資訊 (優先級: 低)
- 合作夥伴風險管理：熟悉系統者可能成為攻擊源，流程需防內部威脅 (優先級: 中)
- Key store 延伸議題：金鑰存放、輪替、撤銷與審計屬長期治理課題 (優先級: 中)
- 信任邊界設計：在可控環境（封閉平台）與開放環境採不同策略 (優先級: 中)
- 可用性與安全平衡：回連與 CA 帶來營運依賴需有備援與降級策略 (優先級: 中)
- 監測與異常偵測：建立驗證失敗、回連異常、簽章錯誤的告警與處置 (優先級: 中)
