您的硬體安全措施運作正常，這不是問題所在。

我們經常聽到類似的反對意見：“我們已經在使用 Android StrongBox，我們有 ECDH 密鑰交換，我們的密鑰從未離開過硬件，為什麼還需要在此基礎上進行白盒加密呢？” 

這是一個合理的問題。 StrongBox、TEE支援的金鑰庫和ECDH都是非常強大的技術。忽視它們是不誠實的，而且毫無益處。所以，與其否定它們，不如讓我們來看看它們究竟保護了什麼，以及它們的漏洞在哪裡。

金庫類比——以及它為何不完整 

硬體安全在某一方面非常出色：保管鑰匙 safe 在保險庫內部，StrongBox 產生金鑰、儲存金鑰並執行加密操作，而無需暴露原始金鑰材料。這才是真正的安全保障，至關重要。 

但大多數安全架構師都不會問這個問題： 金庫是否阻礙了最重要的操作？ 

對於使用 HttpsURLConnection、OkHttp 或類似作業系統管理的 API 建立標準伺服器連線的 Android 應用程式來說，答案基本上是否定的。 Android 的 TLS 協定堆疊運作在 BoringSSL 和 Conscrypt 這兩個軟體庫之上，它們完全透過軟體處理 ECDH 金鑰交換，無需經過 StrongBox 或 TEE Keystore。 TLS 會話金鑰以原始位元組的形式存在於記憶體中，與裝置的硬體配置無關。 

這並非安卓設計的缺陷，而是大多數應用程式安全討論中忽略的架構現實。你的數據保險庫非常出色。但對TLS而言，資料保險庫並不在系統架構之內。 

當二進位檔案成為攻擊面 

暫且不談TLS。設想一下，如果一個應用程式使用硬體金鑰進行加密操作——這些金鑰經過正確配置，源自ECDH，並安全地儲存在StrongBox中——這確實是一個強大的方案。 

現在想想攻擊者會如何利用你的應用程式。他們不會嘗試從 StrongBox 中提取金鑰——這很難。他們會下載你的應用，運行反彙編程序，然後讀取你的程式碼。 

他們找到的是握手邏輯：你的應用程式用於與伺服器通訊的協定、身份驗證流程以及 API 結構。有了這些訊息，他們就不需要你的金鑰了。他們建構了一個修改後的應用，可以從頭開始完成一個看似合法的握手過程。 StrongBox on 該設備現在持有伺服器信任的密鑰。 

更高價值的攻擊並非讀取單個用戶的解密數據，而是對你的協議有足夠深入的了解，從而偽造經過身份驗證的 API 請求——而且可能大規模偽造，甚至可能冒充任意用戶。硬體安全對此束手無策，因為這種攻擊根本不會觸及硬體本身。 

這就是白盒密碼學和應用程式加固的差距所在：保護協定邏輯本身，而不僅僅是金鑰。 

碎片化問題（趁它還存在的時候） 

即使拋開 BoringSSL 的實際情況不談，Android 硬體安全覆蓋率也存在問題。根據 DroidCCT 的研究（一項經過同行評審的 Android 裝置安全分析），StrongBox 僅在 8.7% 的高階裝置上可用，7.2% 的中階裝置可用，而低階裝置僅佔 0.2%。您的大多數用戶都沒有安裝它。 

iOS 的情況則有所不同：所有目前的 iOS 裝置都配備了安全隔離區 (Secure Enclave)，提供強大的硬體級保護。碎片化問題主要針對 Android 系統。 

值得注意的是，這種論點並非無懈可擊。硬體的可用性會隨著時間推移而提高，一些安全指南已經建議在硬體普及之前，將白盒加密作為TEE的臨時補充。二元逆向工程、認證和廠商獨立性方面的優勢依然存在；而碎片化才是當下最引人注目的論點。對於某些組織——尤其是那些受監管或供應鏈限制的組織——而言，降低對任何單一硬體供應商安全實現的依賴本身就是一個設計目標。 

「應用層認證」的真正意義 

還有一個值得注意的差距：你的伺服器完成了握手，但它不知道自己在和誰通信。 

它無法區分在真實設備上運行的合法應用程式、在已root設備上運行的重新打包版本的應用程序，以及通過逆向工程您的協議並模仿您的握手而完全合成的客戶端。 

Google Play 完整性 API 有幫助。如果使用正確的 nonce 和 requestHash 綁定，達到 MEETS_STRONG_INTEGRITY 等級可以顯著減少繞過攻擊的漏洞。但無論完整性等級如何，乾淨的代理設備重播攻擊仍然存在風險。 

白盒加密提供應用層認證：它透過加密證明，證明請求源自於執行受保護協定邏輯的未修改應用，而無需依賴作業系統或硬體信任訊號。它是第二個正交訊號——並非Play Integrity的替代品，而是彌補Play Integrity的不足。 

更高級的版本——也是我們認為行業發展的方向——是持續的行為認證：該客戶端自上次請求以來是否觸發了任何篡改檢測？能夠根據客戶端運行時安全狀態調整回應的伺服器，比在會話建立時做出非此即彼的信任/不信任決策的伺服器，具有更高的彈性。 

完整畫面 

硬體安全是金庫。白盒加密和應用程式加固是裝甲運輸車——保護所有必須離開金庫並參與現實世界的資料。 

對於大多數 Android TLS 操作而言，安全性庫並不在安全路徑中。即使它在安全路徑中，也無法保護協定層、二進位檔案層或認證層。這些並非放棄硬體安全的理由，而是將其視為完整防禦體系中的一層，而非最終解決方案的理由。 

以上四點是我們內部工程、安全和客戶成功團隊進行壓力測試的論點。這其中還有更多內容——包括如何將其應用於特定平台和合規框架（Digital.ai Key & Data Protection 持有 FIPS 140-3 憑證 #4910），並符合監理產業要求。 

如果您正在評估應用程式保護，並希望全面了解其在您環境中的適用情況，我們非常歡迎您與我們交流。 立即請求演示