當攻擊者是客戶端時：防禦中間人攻擊

想像一下，你開發了一款安全的行動應用程式。你的連線經過加密，基礎設施也得到了加固，你的團隊晚上都能睡個好覺。然後，一位安全研究人員帶著一部已root的安卓手機、一個免費代理工具以及你所有API流量的明文資料出現了。

這就是中間人攻擊（MitM）問題，它尤其棘手，因為攻擊者並不總是潛伏在咖啡店的 Wi-Fi 網路中。

對於行動應用程式而言，您通常需要關注中間人攻擊 (MitM)，但也需要注意客戶端中間人攻擊 (MitClient)。在客戶端中間人攻擊中，攻擊者可以控制終端設備並嘗試攔截與伺服器的通訊。有時，攻擊者甚至會坐在電腦前，蓄意逆向工程您的應用程式與處理伺服器的通訊方式。沒有任何單一的安全控制措施能夠完全阻止此類攻擊。真正有效的方法是針對不同的應用場景，採用多層防禦：憑證綁定、白盒端對端加密和白盒雙向 TLS 都是不錯的選擇。以下將分別介紹每種防禦措施的功能、重要性、以及缺點。

證書別針：你的第一道防線

當你的應用程式連接到伺服器時，它通常會信任任何由認可的憑證授權單位 (CA) 所頒發的憑證。證書綁定打破了這個規則。相反，你的應用程式會被硬編碼為只信任預先配置的特定憑證。如果在握手過程中出現其他證書，連線將被拒絕，就此結束。憑證綁定功能強大，但也會帶來一些維運上的難題，需要事先規劃。 證書輪換現在是你們的問題了。 如果您的固定憑證過期，而您沒有先推送應用程式更新，則合法使用者將被鎖定。

如果攻擊者能夠控制行動應用程序，他們可以利用已root的裝置和Frida等動態分析工具繞過憑證PIN碼驗證。證書PIN碼在滿足合規性要求或作為抵禦中間人攻擊的額外安全層方面具有意義，但還有更強的方法來應對中間人攻擊。當攻擊者直接控制某個終端設備時，這一點尤其重要。

用於端對端加密的白盒密碼學：在無法信任裝置的情況下保護金鑰

標準加密的假設是，即使有人攔截了你的網路流量，也無法讀取其內容，因為金鑰是保密的。但在攻擊者可以控制加密一端的已root裝置上，這種假設就不成立了。攻擊者可以轉儲記憶體、攔截你的加密庫調用，並在加密前後提取金鑰。白盒加密透過將金鑰和演算法整合到一個高度混淆的單一實作中來解決這個問題。密鑰永遠不會以獨立值的形式存在於記憶體中。

除了 TLS 層之外，使用白盒實現的 AES 或類似演算法對行動裝置和伺服器之間的通訊進行加密，可以有效防止中間人攻擊獲取資料。雖然額外的加密會降低效能，但這種方法能顯著提升安全性。

相互 TLS：確保只有您的應用程式才能與您的伺服器通訊

在標準的 TLS 連線中，只有伺服器驗證自身身份，你的應用程式會檢查伺服器憑證並決定是否信任它。雙向 TLS (mTLS) 則相反，雙方都需要進行身份驗證。你的應用程式在握手過程中提供客戶端證書，而伺服器會斷開與任何無法證明其持有正確證書的客戶端的通訊。

實際上，這意味著即使攻擊者設法繞過了證書綁定，如果沒有有效的客戶端證書，他們仍然無法存取您的處理伺服器。攻擊者需要使用合法的客戶端，或從應用程式中提取私鑰。大規模的證書管理非常困難。為數百萬用戶頒發、輪換和吊銷客戶端憑證需要強大的公鑰基礎設施 (PKI)。這並非易事，但並非可以實現。在已取得 root 權限的裝置上，仍然存在攻擊者提取用戶端憑證和私鑰以冒充合法應用程式實例的風險。使用具有靈活金鑰長度的簽章產生演算法（例如 RSA SigGen）或橢圓曲線離散對數演算法（例如 ECDSA）的白盒實作可以顯著改善這種情況，這些演算法可以將私鑰嵌入到程式碼中，使其難以提取。

單獨使用或全部一起使用

這些控制措施可以單獨使用，也可以組合使用。憑證綁定可以阻止代理攔截，但在已root的裝置上可以被繞過，並且在憑證輪替時會出現操作問題。白盒端對端加密（White-box E2EE）即使在受到主動監控的情況下也能保護有效載荷的機密性，但會影響效能。 mTLS確保只有合法的應用程式實例才能連接，但私鑰必須使用硬體或白盒實作進行保護，並且憑證必須進行大規模管理。

Digital.ai 現在可以提供憑證綁定功能，並且擁有經 FIPS 認證的 E2EE 和 mTLS 白盒實作。對於許多用例來說，單獨使用 E2EE 可能就足夠了，或者也可以將所有方法分層結合使用，以最大限度地提高安全性。