【译】在您的应用中安全使用Android的篡改检测 （Using Android's tamper detection securely in your app）

原文地址： 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服务是开源的，因此您可以重用部分代码或对其进行研究。