安德魯的部落格

[設計案例] “授權碼” 如何實作? #3 (補) - 金鑰的保護

2016/03/19 設計案例: “授權碼” 如何實作? .NET C# 專欄 技術隨筆
前一篇 #3 介紹了如何利用 "數位簽章" 簡單又可靠的做好 "授權碼" 的驗證，主要都在說明程式架構的實作，沒有對實際運作的情況做太多補充，這篇就來補足這些遺漏的部分。運用這些公開的加密演算法，既安全又可靠，不過這些東西大家都拿的到啊，因此安全與否，完全取決於你的金鑰是否有妥善的被管理。   [設計案例] "授權碼" 如何實作? 2016/02 (本篇系列文章) #1. 需求與問題 #2. 授權碼序列化 #3. 數位簽章 #3. (補) - 金鑰的保護   我就針對 "授權碼" 的產生及驗證，畫一張簡單的關係圖，然後再來說明:

實際的運作架構，原廠 (我) 應該在內部，有我自己的授權碼產生器，可以產生出我需要的組態，發放給我的客戶使用。有幾個重點是維運時必須注意的:
  1. PRIVATE KEY 妥善保管: 產生正確的授權碼，需要有我自己的 PRIVATE KEY。只要有外人能拿到我的 PRIVATE KEY，技術上來說，他就能用我的身分產生任意組態的授權碼。因此我必須好好保管好我自己的 PRIVATE KEY。
  2. 發放 PUBLIC KEY: 讓所有客戶能驗證授權碼，這將會需要把我的 PUBLIC KEY 發放給所有的客戶。客戶端只要拿到我的 PUBLIC KEY，就能驗證授權碼是否可被信賴。
  經過上一篇的討論，各位可能已經覺得這樣安全無慮了，我假設性的提出一個狀況，看看這情境發生時是否對安全會造成威脅? 假設我有個很熟悉系統的合作對象，因為她要代替我維護客戶的系統，因此知道一切技術細節，但是由於上述原因，她無法取得我自己的 PRIVATE KEY。如果她想要自己偷偷賺一筆授權費，她只要這樣做:
  1. 自己產生一組 PRIVATE KEY (當然這組金鑰一定跟我的不一樣...)
  2. 用這組 PRIVATE KEY 產生假的授權碼 (當然這組授權碼，在 SERVER 上會被驗證出問題)
  3. 用這組自己產生的金鑰，把 PUBLIC KEY 替換掉，發給客戶使用..
關鍵在第三點，如果你無法確保客戶拿到的是正確的 PUBLIC KEY，那麼一切的努力就都白費了不是嗎? 意圖不軌的合作廠商，根本不需要去偷到我的 PRIVATE KEY，她只要把我給客戶的 PUBLIC KEY 掉包就夠了...。莫非定律就是: 設想再週到的系統，往往會在你最意想不到的地方被攻破.. 難怪 StarWars 每一次的死星，都會被反抗軍用莫名其妙的方式炸掉 XD  

預先在系統內埋好你的 PUBLIC KEY:

這問題怎麼解? 如果你能保證你的環境都是能掌控的，那麼你可以把你的 PUBLIC KEY 內建在系統內，就沒有被替換的風險了。最常見的例子就是 Game Console, 電視遊樂器對於原版片的保護機制了。遊戲主機如何能分辨原版光碟? 靠的就是一模一樣的數位簽章機制。遊戲主機內部的 OS，早就內建原廠的 PUBLIC KEY，而且這些 KEY 早已被 OS 及硬體妥善的保護起來 (參考: TPM, Trusted Platform Module)，即使沒有連上 internet, 你放入盜版片仍然會被檢測出來，就是這個原理。遊戲主機只要在載入任何遊戲之前，是先確認數位簽章是否正確即可。那些改機的人，都是運用各種平台本身的 BUG，想辦法繞過或是停用這個檢查機制，才能讓你的遊戲主機能執行沒有正確簽章過的程式或遊戲。  

透過 CA 發行 PUBLIC KEY:

但是... 如果我只是個小型的軟體開發商，沒本錢像 Microsoft / XBox, Sony / PS, 任天堂 / Wii 這樣搭建整個完整的體系，那怎麼辦? 這時，如果你的 KEY 是由公正的第三者來發放及提供其他人來調閱你的 PUBLIC KEY，這也是從另一個角度解決問題。這公正的第三者，也就是常聽到的 CA (certificate authority)，詳細的介紹可以參考 wiki (CA) 的說明。架構上就類似 DNS 一樣，你想要有自己的 domain name, 你就必須去跟營運商註冊。同時全世界的使用者想連到你的網站，就要去 DNS 查詢。除非駭客能控制全世界的 DNS，否則他是無法透過非正式管道把你的網址搶過來占為己有的。 同樣的，憑證也有類似的架構。發給你的憑證，裡面就包含了你的 PUBLIC / PRIVATE KEY, 除此之外也還包含了你的基本資訊，如註冊名稱，公司，等等... PRIVATE KEY 仍然一樣只有你自己手上才有，但是其他客戶要驗證時，會到 CA 調出你的 PUBLIC KEY 來驗證。改進過的架構如下:

雖然這樣更安全可靠了，不過把 CA 納進來之後，系統的建置就更複雜了。採用公正的第三方 CA，通常憑證都是需要費用的 (年費)。你自己架設 CA 的話，要確保所有會用到的客戶都在你管轄範圍內，否則也是沒用。另外 CA 的建制也是個大工程，系統要正常運作，這也是個額外的管理及營運成本。  

透過其他手段，強制客戶必須連回原廠驗證

如果你不想用 CA 的這條路，也沒有本錢去做到像 Game Console 這整套完整的架構，那麼還是有些折衷的方案可以考慮。基本上你只要想辦法綁一些關鍵的資訊，一定要由原廠直接提供，藉這些手段，逼出沒有被設定正確的 PUBLIC KEY 的客戶:
  1. 直接由原廠提供力行升級的更新包。若沒有正確的 PUBLIC KEY 則無法升級。
  2. 定期強迫系統需要連回原廠的網站檢測
  3. 透過實體的手段 (例如維護合約等等) 來發行 KEY
其實大公司也有類似的問題，只要有心，仔細想想，你會發現到處都是案例!! 我舉個例子: 安裝過 Windows 的人都知道，裝完要線上啟用，你的 Windows 右下角才不會有討厭的字樣一直提醒你這是盜版 XD。這個啟用的動作，就是一定要上網進行的。對於大量授權版或是企業版，你不用一台一台去啟用，Windows 會自動連上 KMS 去驗證。那些校園免啟動版，都會要求你的 PC / NB 每隔一段時間，一定要連回學校的網路。企業如果有架設自己的 KMS，則 PC 就不需要連回 internet 跟 microsoft 驗證。但是那台 KMS 則還是要定期跟 Microsoft 回報。 因此，回到主題，這也是為何我前面的文章都先暫時跳過 KEY STORE 這部分的原因。扯到 KEY 的管理，就有太多技術手段以外的故事可以講了，實在是防不勝防，有時你還是得考慮用正規的做法比較可靠。若營運的支出許可，去申請個公司用的憑證，花一點費用，用 CA 發的憑證來做這些動作是最安全可靠的。你的系統多安全，不是取決於你的程式碼，而是你的 KEY 如何管理。各位可以自行評估合適的方案。 數位簽章的部分就先補充到這裡。這系列文章還沒結束喔，後面還有 API 等其他的應用~



Facebook Pages

Edit Post (Pull Request)

Post Directory