拒绝应用程序被越狱，App Attest可防护（附源码）

当越狱在 iOS 设备第一次流行起来时，iOS 开发人员会尝试各种方法来保护自己的应用程序，以让应用免受盗版等不确定因素的困扰。有许多方法可以做到这一点，包括检查 Cydia 是否存在、检测应用程序是否可读取自身沙箱之外的文件、在检测到调试器时让应用程序崩溃等等。

然而，事实证明这些防御措施并不是那么有效。如果攻击者可以直接访问物理设备，那么这些措施就不再有效。对于高手来说，他们可以让设备看上去并没有越狱以有效地绕过这些措施，过去可以，现在也可以。同时对于一些越狱用户来说，他们可能并不是想要干坏事，而仅仅是想要一些酷炫的功能，比如说可定制的主屏幕。

随着近来越狱可能再度流行，Apple 给出了一套自己的解决方案。在 iOS 14 中，新的 App Attest API 为应用提供了一种对服务器请求进行签名的方法，以尝试向服务器证明这些请求来自应用程序的合法版本。

需要了解的是，App Attest 不会告诉服务器“这个设备是越狱的么？”，因为这种方案被一次次证明是不可行的。相反，其目标是保护服务器请求，以让攻击者更难创建非法的应用版本来解锁高级功能或植入作弊功能。再次强调的是：由于攻击者可以物理访问设备，因此在这种情况下，没有任何办法可以完全保护你的应用。

由于无法信任应用可以自我保护，因此 App Attest 要求在应用的后端采取必要的工作来实施这个安全策略。由于这是 Swift 相关的内容，所以这里不介绍后端应该如何处理，只是会顺带提及。

生成一对密钥以签署请求

App Attest 依赖于使用非对称公钥/密钥对来工作。最终目的是让应用程序使用密钥对服务器请求进行签名，然后将数据发送到后端，在后端用公钥来确认请求的合法性。如果攻击者拦截了请求，他并没有办法更改内容，这样就不会影响后端的验证。

要生成密钥对，可以导入 DeviceCheck 框架，并调用 DCAppAttestService 单例对象的 generateKey 方法：

import DeviceCheck let service = DCAppAttestService.shared service.generateKey { （keyIdentifier， error） in guard error == nil else { return } }

App Attest 生成的密钥对会安全地存储在设备的 Security Enclave 中。由于无法直接访问，所以这个方法返回的是一个 keyIdentifier 属性，在需要时可以用来找到对应的密钥。我们需要存储它，以便后续用来验证应用程序的请求。

值得一提的是，并非所有类型的设备都支持App Attest，如果查看了 Apple 的文档，会发现我们需要先检查是否支持，并要求服务器做降级处理以应用例外的情况：

if service.isSupported { 。.. }

但是不要这么做！就像之前所说的，攻击者可以可以轻松地伪装成设备不支持这一操作。Apple 也没有相应的应对措施，这个检查的原因更多的是因为有些 Macbook 没有支持它的芯片。根据 Guilherme Rambo 的调查，大部分 iOS 设备都支持这一功能，所以对应 iOS 应用来说，不需要这个兼容性检测。

将公钥发送到后端

为了对请求进行签名，需要为后端提供一种校验签名的方法。我们需要为后端提供上述生成的公钥的访问权限，来完成校验。但是我们不能简单地创建一个请求来发送公钥，因为攻击者很容易拦截请求并发送自己的公钥，这样他们可以完全控制应用发送到后端的内容。

这个问题的解决方法是让 Apple 来证明我们发送的密钥是来自应用的合法版本。可以调用 attestKey 方法来完成，该方法接收密钥的标识符作为参数：

service.attestKey（keyIdentifier， clientDataHash： hash） { attestation， error in guard error == nil else { return } let attestationString = attestation？.base64EncodedString（） // Send the attestation to the server. It now has access to the public key！ // If it fails， throw the identifier away and start over. }

这个方法会访问远程 Apple 服务器，并返回一个 “attestation” 对象，这个对象不仅包含了公钥，而且还包含有关应用程序的大量信息，以表明这是经过 Apple 认证的合法的公钥。客户端收到这个对象后，必须将其完整发送到后端，后端需要执行多步验证，以确认未被篡改。如果验证了 “attestation” 对象是合法的，后端便可以从中安全地提取应用的公钥。

目前尚不清楚 Apple 是否尝试在此过程中检查用户的设备是否越狱。文档并没有提到这种情况，不过他们也指出 App Attest 不能确切地设备是否越狱，这至少说明他们尝试过。可以肯定地说，并没有办法指出设备是否越狱，而且 attest 这个词只表示请求未被拦截或篡改。

attestation 请求的附加 clientDataHash 参数与校验的过程本身无关，但对安全性却至关重要。实际上，这个请求的很容易做重放攻击，攻击者可以拦截验证请求并窃取从 Apple 发送的 “attestation” 对象，以便后续可以在应用程序的非法版本中 “重放” 相同的验证请求来欺骗服务器。

解决这个问题的方法是简单粗暴地不允许验证请求被随意地执行。客户端可以提供一个一次性使用令牌（或会话ID），服务器希望该令牌与请求一起使用以确保其有效性。如果两次使用相同的令牌，则请求将失败。这就是 clientDataHash 的目的：通过向验证请求提供令牌的哈希版本，Apple 会将其嵌入到最终对象中，并为您的服务器提供一种提取它的方式。有了这个，对于攻击者来说，仅通过拦截请求就很难创建您应用程序的非法版本。

let challenge = getSessionId（）.data（using： .utf8）！ let hash = Data（SHA256.hash（data： challenge）） service.attestKey（keyIdentifier， clientDataHash： hash） { 。.. }

如前所述，Apple 并不建议你重用密钥，而应该对设备中的每个用户帐户执行整个过程。

由于这个请求依赖于远程 Apple 服务器，因此可能会失败。如果错误是服务器不可用，Apple 表示你可以重试，但是如果其他原因，则应丢弃密钥标识符并重新开始这一流程。例如，当用户重新安装您的应用程序时，可能会发生这种情况：你生成的密钥在正常的应用程序更新中仍然有效，但是在重新安装应用程序，设备迁移或从备份还原设备后仍然会发生错误。对于这些情况，您的应用需要能够重新执行密钥生成过程。

从服务器方面来说，还值得一提的是，“attestation” 对象还包含一张回执，你的服务器可以使用该回执来向 Apple 请求欺诈评估指标。这使你可以检查生成的密钥的数量以及与它们关联的设备，以检测可能的欺诈情况。苹果公司特别提到了攻击的可能性，即用户可能使用一个设备向越狱设备提供有效的断言，这种欺诈评估可以通过定位具有异常高数量的断言请求的用户来检测到。

加密请求

在验证了密钥的有效性之后，后端将可以访问公钥。从现在开始，每次处理敏感内容时，都可以安全地对请求进行签名。用于此目的的 generateAssertion 方法的工作原理与密钥的验证非常相似，只是这次需要要验证请求本身：

let challenge = getSessionId（）.data（using： .utf8）！ let requestJSON = “{ ‘requestedPremiumLevel’： 300， ‘sessionId’： ‘\（challenge）’ }”.data（using： .utf8）！ let hash = Data（SHA256.hash（data： challenge）） service.generateAssertion（keyIdentifier， clientDataHash： hash） { assertion， error in guard error == nil else { return } let assertionString = assertion？.base64EncodedString（） // Send the signed assertion to your server. // The server will validate it， grab your request and process it. }

与之前一样，后端必须支持使用一次性令牌来防止重放攻击。这次，由于请求本身就是我们的 clientDataHash，因此我们将令牌添加到 JSON 中。对于给定键可以进行的断言数量没有限制。但是，尽管如此，通常仍应保留它们，以在应用程序发出请求保护敏感信息，例如下载内容。

在这种情况下，额外保护来源于请求被散列并且只能使用一次。由于整个请求都是由私钥签名的，因此攻击者无法简单地拦截请求并利用它们来制作自己的请求。他们必须弄清楚你请求的参数来自何处，并手动尝试对其进行签名，这比简单附加代理要更多的技术。如开头所述，要破解这种保护并不是没有可能，只是需要更加努力。

测试及实施

App Attest 服务记录了你无法重置的标记。为防止这种情况，非生产环境中的应用程序将使用沙盒版本。如果你想在生产环境中进行测试，则应将 com.apple.developer.devicecheck.appattest-environment 授权添加到你的应用中，并将其值设置为 production。

如果你的用户群很大，Apple 建议你逐步启用此功能，因为对 attestKey 的请求受网速限制。

结论

通过在客户端和后端中实现此功能，攻击者更难创建应用程序的非法版本。但是，请注意这并不意味着不可能！如前所述，你无法确定用户是否拥有越狱设备，也无法确定阻止其攻击你的应用的方法。与大多数安全措施一样，App Attest 的目的是使此过程足够困难，以使只有一个非常熟练和专业的攻击者才能找到闯你您的应用程序的途径-而这种牛人很少。