前一篇 #3 介紹了如何利用 "數位簽章" 簡單又可靠的做好 "授權碼" 的驗證，主要都在說明程式架構的實作，沒有對實際運作的情況做太多補充，這篇就來補足這些遺漏的部分。運用這些公開的加密演算法，既安全又可靠，不過這些東西大家都拿的到啊，因此安全與否，完全取決於你的金鑰是否有妥善的被管理。
[設計案例] "授權碼" 如何實作? 2016/02 (本篇系列文章)
#1. 需求與問題
#2. 授權碼序列化
#3. 數位簽章
#3. (補) - 金鑰的保護
我就針對 "授權碼" 的產生及驗證，畫一張簡單的關係圖，然後再來說明:
- PRIVATE KEY 妥善保管: 產生正確的授權碼，需要有我自己的 PRIVATE KEY。只要有外人能拿到我的 PRIVATE KEY，技術上來說，他就能用我的身分產生任意組態的授權碼。因此我必須好好保管好我自己的 PRIVATE KEY。
- 發放 PUBLIC KEY: 讓所有客戶能驗證授權碼，這將會需要把我的 PUBLIC KEY 發放給所有的客戶。客戶端只要拿到我的 PUBLIC KEY，就能驗證授權碼是否可被信賴。
- 自己產生一組 PRIVATE KEY (當然這組金鑰一定跟我的不一樣...)
- 用這組 PRIVATE KEY 產生假的授權碼 (當然這組授權碼，在 SERVER 上會被驗證出問題)
- 用這組自己產生的金鑰，把 PUBLIC KEY 替換掉，發給客戶使用..
預先在系統內埋好你的 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 的這條路，也沒有本錢去做到像 Game Console 這整套完整的架構，那麼還是有些折衷的方案可以考慮。基本上你只要想辦法綁一些關鍵的資訊，一定要由原廠直接提供，藉這些手段，逼出沒有被設定正確的 PUBLIC KEY 的客戶:- 直接由原廠提供力行升級的更新包。若沒有正確的 PUBLIC KEY 則無法升級。
- 定期強迫系統需要連回原廠的網站檢測
- 透過實體的手段 (例如維護合約等等) 來發行 KEY
