问题的第一部分

是否存在与iOS设备检查https://developer.apple.com/documentation/devicecheck相当的Android版本
如前所述，Android的对等产品是SafetyNet，但尽管是Android安全生态系统的一个很好的改进，但其设计并非用作独立防御，如Google own statement所示：
此API的目的是让您对运行您的应用的设备的完整性充满信心。然后，您可以使用标准Android API获取其他信号。您应将SafetyNet认证API作为防滥用系统的一部分，作为额外的深度防御信号，而不是作为您的应用的唯一防滥用信号。
此外，当开发人员实施SafetyNet解决方案时，需要牢记：

• 它是谷歌移动的服务（GMS）的一部分，因此只在有此功能的设备上运行。在一些市场，如远东，有相当数量的设备没有此功能。
• 可以使用标准免费API密钥进行的证明调用数量有限，因此要大规模使用，可能需要付费级别。
• 它主要用于检查特定Android设备运行的操作系统映像是否安全和兼容。因此，它可以被视为非常高级的根检查，能够检查指示根设备的文件系统更改。
• 由于SafetyNet正在对操作系统映像的哈希值进行全面分析，它实际上可能非常慢（有时需要几秒钟）。这意味着它不能连续进行分析，在使用时需要注意向用户隐藏此延迟，但不能为攻击者提供漏洞。
• SafetyNet并不专门分析正在运行的应用程序的内存Map来检测工具框架（它依赖于它们只能在根设备上运行的事实），如XPosed和Frida。
• SafetyNet确实通过apkDigestSha256功能提供了对正在运行的应用程序的证明。这只能在报告完整性的情况下才能依赖。2这意味着如果应用程序运行在任何一种不寻常的或根设备上，它的完整性是未知的。一些用户仅出于自定义目的而设置其设备的root，如果移动的应用程序中有很大比例的用户，则SafetyNet会将其排除在能够使用应用程序。在这种情况下，我们希望具体了解正在运行的应用程序的完整性，而不是整个系统。SafetyNet无法做到这一点，但移动的应用程序认证服务可以。
• 为了以一种不能被欺骗的方式执行证明检查，则应用不能进行它自己的检查（因为很明显，该代码可能被篡改）。因此，需要实现服务器端以可靠地使用该特征。
  问题第二部分

或者有什么方法来验证这是你未经修改的apk在进行api调用吗？
这里的方法是将SafetyNet与移动的应用认证服务一起使用。如果在您的移动应用中需要用户身份验证和身份验证，还应使用OAUTH2。最后但并非最不重要的是使用证书绑定来保护API服务器和移动应用之间的通信通道，如有关移动API技术的文章中所述。

移动的应用证明服务的定义

移动的应用证明服务的作用是通过使用集成在应用中的SDK和在云中运行的服务，在运行时保证应用未被篡改或未在根设备中运行。
成功证明应用程序完整性后，将发布一个JWT令牌，并使用一个只有应用程序的API服务器和云中的移动的应用程序证明服务知道的秘密进行签名。
如果应用程序证明失败，则使用API服务器不知道的秘密对JWT进行签名。
现在，应用程序必须在每个API调用的请求标头中发送JWT标记。这将允许API服务器仅在可以验证JWT标记中的签名时才为请求提供服务，并在验证失败时拒绝请求。
一旦移动的应用程序认证服务使用的秘密不为应用程序所知，就不可能在运行时对其进行反向工程，即使应用程序被篡改，在根设备中运行或通过成为中间人攻击目标的连接进行通信。这就是此类服务相对于SafetyNet解决方案的亮点。
顺便提一下，如果您的应用程序直接与第三方服务进行通信，那么我建议您将该责任委托给API服务器，这样可以防止代表您未经授权使用第三方服务，只要它现在只为通过完整性挑战的移动的应用程序的真实请求提供服务。

移动的App Attestation服务已经作为一个SAAS解决方案存在于Approov（我在这里工作），它为几个平台提供SDK，包括iOS。集成还需要在API服务器代码中进行一个小的检查，以验证云服务发布的JWT令牌。对于API服务器来说，这项检查是必要的，以便能够决定服务哪些请求，拒绝哪些请求。

他们有SafetyNet --更全面一些：https://developer.android.com/training/safetynet/index.html
您需要了解的两个API是“证明”和“验证应用程序”：
证明API检查设备的完整性，而验证应用程序API检查是否安装了已知的可能有害的应用程序。为了增强安全保护，应在使用验证应用程序API之前使用证明API验证设备的完整性。
至于你问题的第二部分，无论你在你的应用程序中加入了什么，你都应该认为已经受到了损害，因为攻击者可以反编译你的应用程序。你最好把重点放在适当的服务器端安全性上，并限制你的API实际暴露的内容，适当的加密和令牌化（如果处理付款信息）、和足够的日志记录来跟踪对API的恶意调用。一旦您的规模足够大，足以吸引黑客的注意，您就有理由雇用专业的开发人员。

是的，有。为了确保您的后端只接收来自真正应用程序的合法API调用，您必须关注以下几个方面：

*支持的平台-有跨平台API保护解决方案，如Talsec AppiCrypt或特定于Android的解决方案，如华为专用的Safety Detect Kit或谷歌移动的服务SafetyNet。
*Android供应商详细信息：

| Android风格|可用解决方案|
| - -|- -|
|vanilla Android-自助服务亭、EMV POS终端、Lineage操作系统、医疗保健平板电脑|应用加密|
|谷歌移动的服务-三星、小米、OnePlus等|谷歌安全网、AppiCrypt|
|华为移动的服务-华为，荣誉|认证API、AppiCrypt|

*性能影响-例如，SafetyNet会带来一些由远程数据处理和评估引起的延迟。AppiCrypt提供稳定的〈10 ms的响应时间。
*第三方元素-如果您需要有保障的运营，使用第三方服务器（即Google SafetyNet，它不受您的控制）可能会给您的企业带来问题
*威胁详细信息级别-您是否需要精细的威胁分析并能够做出相应的React？SafetyNet结果是二进制的：安全或危险的设备。如果你需要更具体的，AppiCrypt有一个详细的启发式权重系统来进行威胁评估。

Android对此提供了一个本地解决方案-KeyPairGenerator

生成新密钥对（如果不存在）的示例-

KeyPairGenerator kpg = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore"); 
kpg.initialize(new KeyGenParameterSpec.Builder( 
        alias, // Key identifier 
        KeyProperties.PURPOSE_SIGN | KeyProperties.PURPOSE_VERIFY) 
    .setDigests(KeyProperties.DIGEST_SHA256, KeyProperties.DIGEST_SHA512) 
    .setAttestationChallenge(attestationChallenge) 
    .build()); 
KeyPair kp = kpg.generateKeyPair();

备注：

1.您必须指定非空的attestationChallenge to KeyPairGenerator.initialize方法来创建有效的证明对象，否则将获得假证书链。

1. attestationChallenge可以通过调用服务器的相应端点生成一次性质询来获取。