原文地址： https://koz.io/using-safetynet-securely-in-your-android-app/

在上一篇博文中，我從技術角度描述了Google Play的SafetyNet服務的結構，深入研究了細節并對其進行了檢查。

回顧：Google Play的SafetyNet服務允許您的應用獲取有關所運行設備的“ CTS兼容性”狀態的信息。您可以將CTS兼容性視為生根檢測，設備篡改檢測和活動MitM檢測的組合。

許多應用程序使用商業“保護套件”來執行其中的某些任務，或者推出自己的解決方案-這通常很容易被破壞。

Google Play的SafetyNet服務可以免費為您的應用提供類似的信息-盡管檢查是基本的，但比推出自己的解決方案更難繞過。我相信，如果您確實想進行篡改檢測，但又不想投資專門的產品或咨詢服務，那么使用此API值得一試。

但是，對于不具備安全意識的開發人員而言，“正確”使用SafetyNet API并非直截了當。

不安全地使用SafetyNet

例如，此示例應用程序?（源）和此應用程序以僅客戶端方式實現API。這些應用程序獲取證明結果，并使用和字段getBoolean()上的方法在本地檢查簽名和CTS兼容性字段。ctsProfileMatchisValidSignature

這種方法的問題在于，已經在設備上具有root用戶訪問權限的攻擊者可以掛鉤該getBoolean()方法并使其始終返回true-誘使您的應用程序相信該設備確實與CTS兼容，而真正的SafetyNet響應卻說這是不。如果您在本地檢查JWS AttestationResult對象的簽名，則會存在相同的問題。

完全可以執行這種掛鉤的Xposed模塊已經發布-可以輕松進行旁路。

或者，攻擊者可以重新打包您的應用程序并剝離所有這些檢查，從而獲得相同的結果。

避免客戶端檢查

這幾乎不是新的最佳實踐建議：避免客戶端檢查對您有好處。

我和Cigital的資深顧問Georgi Boiko創建了SafetyNet Playground，這是一個示例性的開源Android應用程序，旨在解決這些“瑣碎的繞過”問題。它使用SafetyNet API的方式與Android Pay相同。

設計該應用程序是為了在服務器端進行檢查。這樣的想法是，除非SafetyNet服務響應您的設備與CTS兼容，否則服務器將不會返回任何有用的數據。

有了這樣的解決方案，攻擊者就可以不再瑣碎地鉤住應用程序中的內容。他需要投入時間和精力來趕上趕超過程，并了解不斷變化的SafetyNet服務，試圖掛鉤從設備收集到的所有內容，并弄清楚什么將構成每張支票的“可接受”狀態。

當然，攻擊者在剝離了Attestation API之后仍然可以重新打包應用程序。取決于攻擊者的聰明程度，它也可能會被擊敗，因為JWS對象包括發出請求的程序包的簽名……攻擊者將不得不偽造該簽名，以便Google Services認為另一個應用程序發出了請求。

這篇博客文章詳細介紹了SafetyNet Playground的設計。Android應用程序和Web服務是開源的，因此您可以重用部分代碼或對其進行研究。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的【译】在您的应用中安全使用Android的篡改检测 （Using Android's tamper detection securely in your app）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。