相当于iOS的Android设备检查 [英] Android equivalent of ios devicecheck

问题描述

是否存在与android设备等效的android设备检查 https://developer.apple.com/documentation/devicecheck 或以任何方式验证这是您的未经医生查询的apk进行的api调用?

Is there an android equivalent of ios device check https://developer.apple.com/documentation/devicecheck or any way to verify that this is your undoctored apk making the api call?

推荐答案

问题的第一部分

是否存在与ios设备相同的android设备检查 https://developer.apple.com/documentation/devicecheck

正如已经指出的，Android等效系统是SafetyNet，但是尽管对Android安全生态系统进行了很好的改进，但根据

As already point out the android equivalent is SafetyNet, but despite being a very good improvement for the Android security ecosystem was not designed to be used as a stand-alone defence, as per Google own statement:

此API的目标是使您对运行您的应用程序的设备的完整性充满信心.然后，您可以使用标准的Android API获取其他信号.您应该将SafetyNet Attestation API用作反滥用系统的一部分，作为附加的深度防御信号，而不是作为应用程序的唯一反滥用信号.

The goal of this API is to provide you with confidence about the integrity of a device running your app. You can then obtain additional signals using the standard Android APIs. You should use the SafetyNet Attestation API as an additional in-depth defense signal as part of an anti-abuse system, not as the sole anti-abuse signal for your app.

开发人员在实施SafetyNet解决方案时也要牢记:

Also when a developer is implementing the SafetyNet solution it needs to bear in mind:

• 它是Google移动服务(GMS)的一部分，因此只能在具有此功能的设备上运行.在某些市场(例如远东)，很多设备都没有此功能.

• It is part of Google Mobile Services (GMS) so only runs on devices that have this. In some markets, such as the far east, there are a significant number of devices that do not have this available.

使用标准的免费API密钥只能进行数量有限的证明调用，因此要大规模使用(大概)付费级别.

There are a limited number of attestation calls that can be made with a standard free API key, so to use at scale a (presumably) paid level would be required.

它主要用于检查特定Android设备正在运行的OS映像是否被认为是安全和兼容的.因此，可以认为它是相当高级的根检查，它能够检查指示已根设备的文件系统更改.

It is primarily designed to check if the OS image that a particular Android device is running is considered to be secure and compatible or not. As such it can be considered to be quite advanced root check that is able to check for file system changes indicative of rooted devices.

由于SafetyNet对OS映像的哈希值进行了全面分析，因此实际上可能会非常缓慢(有时需要几秒钟).这意味着它不能连续进行，并且在使用时需要格外小心，以向用户隐藏此延迟，但不会为攻击者提供利用的机会.

Since the SafetyNet is doing a full analysis of the hashes of the OS image it can actually be quite slow (sometimes a few seconds). This means that it cannot be doing continuously and some care is needed in its use to hide this latency from the user, but without creating an opening for an attacker to exploit.

SafetyNet并没有专门分析正在运行的应用程序的内存映射以检测检测框架(这取决于它们只能在有根设备上运行)，例如XPosed和Frida.

SafetyNet does not specifically analyse the memory map of running apps to detect instrumentation frameworks (it relies on the fact that they can only run on rooted devices), like XPosed and Frida.

SafetyNet确实通过apkDigestSha256功能提供了正在运行的应用程序的证明.但是，只有在报告了完整完整性的情况下，才可以依靠它.这意味着，如果该应用程序在任何种类的异常或有根设备上运行，则其完整性是未知的.一些用户仅出于自定义目的而对设备进行植根，并且如果移动应用中有很大比例的设备，则SafetyNet将排除他们使用该应用的能力.在这种情况下，我们想专门了解正在运行的应用程序的完整性，而不是整个系统. SafetyNet无法做到这一点，但是移动应用程序证明服务可以.

SafetyNet does provide an attestation of the running app via the apkDigestSha256 feature. However, this can only be relied upon if full integrity is reported. This means that the integrity of the app is unknown if it is running on any kind of unusual or rooted devices. Some users root their devices only for customizations purposes and if the mobile app has a significant percentage of them then SafetyNet will exclude them from being able to use the app. In this scenarios we want to know specifically about the integrity of the running app rather then the system as a whole. SafetyNet is not able to do that, but a mobile app attestation service can.

为了以无法欺骗的方式执行证明检查，则应用程序无法进行自己的检查(显然，此代码可能会被其自身篡改).因此，需要实现服务器端以可靠地使用该功能.

In order to perform the attestation check in a way that cannot be spoofed then app cannot do its own check (as obviously this code could be tampered with itself). Thus there is a need to implement a server side to use the feature reliably.

问题的第二部分

或以任何方式验证这是您进行API调用的非医生apk?

or any way to verify that this is your undoctored apk making the api call?

此处的方法是将SafetyNet与移动应用证明服务一起使用.如果您的移动应用程序中需要用户身份验证和身份验证，则也应使用OAUTH2.最后但并非最不重要的一点是，如

The way here is to use SafetyNet alongside a Mobile App Attestation service. OAUTH2 should also be used if user authentication and authentication is necessary in your mobile app. Last but not least important is the use of certificate pinning to secure the communication channel between the API server and the Mobile App, as covered in this series of articles about Mobile API Techniques.

移动应用证明服务的定义

移动应用程序证明服务的作用是通过在应用程序中集成的SDK和在云中运行的服务，在运行时确保您的应用程序未被篡改或未在有根设备中运行.

The role of a Mobile App Attestation service is to guarantee at run-time that your App was not tampered or is not running in a rooted device by using an SDK integrated in your App and a service running in the cloud.

在成功证明App完整性后，JWT令牌被发行并签名，并且秘密地​​知道您的App的API服务器和云中的Mobile App Attestation服务.

On successful attestation of the App Integrity a JWT token is issued and signed with a secret that only the API server of your App and the Mobile App Attestation service in the cloud are aware.

在App证明失败的情况下，将使用API​​服务器不知道的秘密对JWT进行签名.

In the case of failure on the App Attestation the JWT is signed with a secret that the API server does not know.

现在，应用程序必须与每个API一起发送，并在请求的标头中调用JWT令牌.这将使API服务器仅在可以验证JWT令牌中的签名时才处理请求，而在验证失败时拒绝请求.

Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature in the JWT token and refuse them when it fails the verification.

一旦App不知道Mobile App Attestation服务使用的机密，就无法在运行时对其进行反向工程，即使该App被篡改，在根设备上运行或通过连接进行通信是中间攻击中一个人的目标.这是与SafetyNet解决方案相关的这种服务的亮点.

Once the secret used by the Mobile App Attestation service is not known by the App, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack. This is where this type of service shines in relation to the SafetyNet solution.

作为一个旁注，如果您的应用程序直接与第三方服务进行通信，那么我建议您将这一职责委派给API服务器，这样可以避免 仅在您服务后，代表您未经授权使用您的第三方服务 现在，来自移动应用的真实请求通过了完整性挑战.

As a side note if your App talks directly with third parts services, then I suggest that you delegate that responsibility to the API server, that will prevent unauthorized use of your third part services in your behalf, once it only serves now authentic requests from the Mobile App's that passed the Integrity challenges.

移动应用程序证明服务已经作为SAAS解决方案存在于 Approov (I在这里工作)，它为包括iOS在内的多个平台提供了SDK.集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌.对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求.

The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.

这篇关于相当于iOS的Android设备检查的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！