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

前一篇 #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 等其他的應用~




Search

    Post Directory

    Facebook Pages