反對白盒密碼學的三大最棘手論點——以及它們為何錯過要點

In 系列第一部分 我們探討了硬體安全止步之處：為什麼安卓的TLS協定堆疊完全繞過了StrongBox，為什麼硬體碎片化導致大多數用戶得不到保護，以及為何硬體安全無法抵禦協定層的二進位逆向工程。如果您還沒讀過那篇文章，那麼了解它的背景資訊對理解本文至關重要。 

這篇文章針對的是另一種類型的懷疑論者——他們並非認為硬體安全就足夠了，而是完全否定了白盒密碼學。以下是我們最常聽到的三種論點，它們值得我們直接回應。 

論點一：“WBC違反了柯克霍夫原則。它是騙人的。” 

學術界的批評是這樣的：克爾克霍夫原理指出，即使密碼系統的所有資訊（金鑰除外）都是公開的，它也應該是安全的。白盒密碼學透過隱藏實作細節來保護金鑰，這意味著它的安全性依賴於隱蔽性。但這並非真正的安全。在像WhibOx這樣的奪旗賽中，所有公開的白盒密碼學實現都在幾天內就被破解了。這是一種不科學的噱頭。 

這種批評誤解了世界浸信會實際所做的工作——並且因此，錯誤地運用了它所引用的原則。 

WBC 並不隱藏演算法。白盒形式的 AES 仍然是 AES——相同的輸入、相同的輸出、相同的數學運算。演算法完全公開，並且沒有改變。 WBC 所做的，是改變金鑰的儲存和使用方式，將其嵌入轉換後的實作中，從而顯著增加了提取金鑰的難度。演算法仍然是公開的，密鑰仍然是秘密的。這正是柯克霍夫原則所要求的。 

批評者將「實現方式加強」與「演算法保密」混為一談。這兩者並非同一概念。加強實現方式以保護金鑰是一種金鑰保護機制——這並非違反原則，而是對原則的實踐。 

現在想想如果沒有這種保護會發生什麼事。攻擊者已經控制了你的應用程式和設備。提取密鑰並非什麼複雜的攻擊——這只是一個入門級的練習。在二進位檔案中找到 ARM AES 指令，設定一個斷點，執行應用程式執行該操作，然後從暫存器讀取金鑰。只需幾分鐘，使用免費工具即可完成。此時，柯克霍夫原理就無濟於事了——金鑰已經遺失。 

WBC（全域金鑰保護）機制使得柯克霍夫原理在惡意環境下依然有效。當攻擊者掌握了你的二進位檔案和裝置時，WBC 機制能夠確保金鑰的秘密性。 

值得注意的是，同樣的斷點攻擊也適用於 OpenSSL──找到 AES 指令，設定斷點，讀取暫存器。沒有人會舉辦 CTF 比賽來破解 OpenSSL 或其他開源加密庫的金鑰提取功能，因為它們的設計初衷並非為了在惡劣的運行時環境中保護金鑰。 WBC 所遵循的標準，是任何權威加密函式庫都無法企及的。不同之處在於，WBC 正在積極嘗試解決這個問題。 

針對 WhibOx 的批評值得直接回應：沒錯，CTF 實作確實會被破解。但商業實現則屬於另一類。我們 RSA/AES 實作中已知的 DFA 漏洞已在 2019 年的 TFIT 大會上解決。目前尚未發現針對我們橢圓曲線實現的 DFA 攻擊。我們的產品持有 FIPS 140-3 認證（證書編號 4910），這是學術 CTF 參賽作品所不具備的獨立驗證。 

更重要的是，WBC並非孤軍奮戰。應用加固產品——包括混淆、動態插樁檢測、調試器檢測和鉤子檢測——能夠主動破壞攻擊者發動側通道攻擊所需的工具，而這些攻擊正是破解簡單實現的關鍵。試圖對加固後的應用運行Frida的攻擊者，面對的並非一個被混淆的演算法，而是能夠偵測並回應其工具的系統。這並非依靠混淆來保障安全，而是縱深防禦。 

論點 2：“代碼提取使 WBC 變得毫無價值。” 

這項建議來自經驗豐富的安全架構師。他們的論點是：即使你無法從白盒實作中提取原始金鑰，也無需這樣做。只需將整個白盒二進位從應用程式複製出來，並在你自己的伺服器上運行即可。這樣你就擁有了一個預先包裝好的解密工具，而無需提取金鑰。 

這是一個真實存在的攻擊。對於沒有伺服器端驗證的簡單實現，它確實有效。 

對於正確部署的伺服器來說，它會在伺服器邊界失敗——原因如下。 

從外部提取的二進位檔案並非您的應用程式。它不具備您的應用程式在合法未修改的設備上運行時所具備的安全狀態。應用程式加固防護措施會產生行為遙測資料：此客戶端是否觸發了篡改偵測？執行環境是否乾淨？這是一個經過驗證的運轉時環境嗎？ 

運行在攻擊者伺服器上的被盜用的白盒模組無法通過這些檢查。它沒有應用感知遙測歷史記錄，也無法透過行為驗證。伺服器可以（也應該）根據客戶端的運行時安全狀態調整其回應。看起來像是盜用的二進位檔案的客戶端會受到相應的處理。 

除了行為驗證之外，每個裝置唯一的金鑰交換意味著基於某個裝置配置的白盒實作無法用於其他目標。提取的密鑰塊僅對提取它的特定伺服器互動有效，而不能作為通用解密工具。 

程式碼竊取是一種真實存在的攻擊途徑，需要相應的架構應對措施。因應措施是行為驗證和裝置間金鑰的唯一性，而不是假裝這種攻擊不存在。 

論點 3：“硬體安全性使軟體保護過時。” 

這種論點來自於平台把關人和硬體供應商：隨著 StrongBox、TEE 支援的金鑰庫和安全隔離區的成熟，基於軟體的加密保護已成為過時的方法。應用程式應該依賴硬體隔離原語。軟體混淆是多餘的。 

我們在第一部分中討論了這一論點的技術基礎，但在這裡有必要直截了當地說：前提是錯誤的，而且是可以證明的。 

Android 的 TLS 協定堆疊（即所有透過 HttpsURLConnection 或 OkHttp 建立標準 HTTPS 連線的應用所使用的路徑）完全透過 BoringSSL 和 Conscrypt 在軟體層級處理 ECDH 金鑰交換。它不使用 StrongBox，也不使用 TEE 金鑰庫。 TLS 會話金鑰以原始位元組的形式存在於每個 Android 裝置的記憶體中，與硬體安全功能無關。 

這並非理論上的缺陷。 BoringSSL 原始碼、Conscrypt 維護者的討論以及同行評審的研究中都有相關記載。硬體安全性在保護特定硬體支援操作中的靜態金鑰方面表現出色。但對於大多數 Android 應用程式中最常見的加密操作而言，它卻無能為力。 

除了 TLS 安全漏洞之外，硬體安全並不能保護你的二進位檔案免受逆向工程攻擊。它無法阻止攻擊者理解你的協定並偽造已認證的請求。它無法提供應用層認證。它也無法解決運行時行為被竄改的問題。 

硬體安全是金庫。白盒加密和應用加固是裝甲運輸——保護所有必須離開金庫並參與現實世界的資料。金庫和裝甲運輸相輔相成。認為一個好的金庫會使裝甲運輸過時的觀點，是對二者功能的誤解。 

誠實總結 

白盒密碼技術並非堅不可摧。沒有哪家正規廠商聲稱它是。它所宣稱的是成本不對稱：透過提高成功攻擊所需的成本和複雜程度，迫使大多數攻擊者轉向更容易的目標；同時確保那些真正成功的攻擊需要投入與國家支持或高度定向行動相關的資源，而不是像Frida這樣的腳本小子就能搞定的。 

學術界對WBC的批評僅適用於簡單的獨立實作方式。但對於架構完善、結合了WBC、應用程式加固、行為認證和設備級金鑰唯一性等功能的部署方案而言，這些批評並不適用。 

以上三點是我們與工程、安全、客戶成功團隊共同進行壓力測試的成果。如果您正在評估應用程式保護方案，並希望了解這些方案如何應用於您的特定環境和威脅模型，我們非常樂意與您溝通。 立即請求演示