让你的应用远离越狱:iOS 14 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 的目的是使此过程足够困难,以使只有一个非常熟练和专业的攻击者才能找到闯你您的应用程序的途径-而这种牛人很少。



https://mp.weixin.qq.com/s/BWCoHujNNXy7iiduz1154w

iOS APP 图标版本化

在我们的项目开发过程中,需要频繁打包给测试人员去测试,有时候我们都不知道测试机上安装的版本是否是最新的,这样会造成很多不必要的麻烦和成本。因此我们需要将buildNumber以水印的方式打在APPIcon上,可以很直观的知道当前是哪一个版本。

发布于:8天以前  |  20次阅读  |  详细内容 »

如何实现一个HTTP请求库——axios源码阅读与分析

在前端开发过程中,我们经常会遇到需要发送异步请求的情况。而使用一个功能齐全,接口完善的HTTP请求库,能够在很大程度上减少我们的开发成本,提高我们的开发效率。

发布于:9天以前  |  23次阅读  |  详细内容 »

老司机 iOS 周报 #144 | 2021-01-14

发布于:12天以前  |  44次阅读  |  详细内容 »

快手,快影 iOS App反调试

发布于:19天以前  |  65次阅读  |  详细内容 »

优酷iOS插件化页面架构方法

随着业务不停地迭代,优酷 APP 用于分发视频资源的 UI 控件越写越多,也越来越复杂,并且同时相似相近的代码也非常多。

发布于:2月以前  |  180次阅读  |  详细内容 »

iOS中的内嵌汇编

写一篇在iOS上使用汇编的文章的想法在脑袋里面停留了很久了,但是迟迟没有动手。虽然早前在做启动耗时优化的工作中,也做过通过拦截objc_msgSend并插入汇编指令来统计方法调用耗时的工作,但也只仅此而已。刚好最近的时间项目在做安全加固,需要写更多的汇编来提高安全性(文章内汇编使用指令集为ARM64),也就有了本文

发布于:2月以前  |  182次阅读  |  详细内容 »

77.9K 的 Axios 项目有哪些值得借鉴的地方

Axios 是一个基于 Promise 的 HTTP 客户端,同时支持浏览器和 Node.js 环境。它是一个优秀的 HTTP 客户端,被广泛地应用在大量的 Web 项目中。

发布于:2月以前  |  166次阅读  |  详细内容 »

不会吧,这也行?iOS后台锁屏监听摇一摇

一般情况下,出于省电、权限、合理性等因素考虑,给人的感觉是很多奇怪的需求安卓可以实现,但是iOS就无法实现!今天要介绍的需求也有这种感觉,就是“当 APP 处于后台或锁屏状态时,依旧可以监听到摇一摇,进而触发某些功能,比如:语音播报”。

发布于:3月以前  |  306次阅读  |  详细内容 »

iOS 稳定性:App 被终止的原因

本次 session 主要内容如下: 介绍了后台应用终止的常见原因,并提供了一些优化建议 介绍了 MetricsKit 提供的在代码中获取诊断和性能数据的方法 介绍了 Xcode Metrics Ogranizer 提供的关于线上用户性能数据的可视化报告

发布于:3月以前  |  421次阅读  |  详细内容 »

优酷iOS插件化页面架构方法

随着业务不停地迭代,优酷 APP 用于分发视频资源的 UI 控件越写越多,也越来越复杂,并且同时相似相近的代码也非常多。

发布于:3月以前  |  318次阅读  |  详细内容 »

Vue中Axios的封装和API接口的管理

在vue项目中,和后台交互获取数据这块,我们通常使用的是axios库,它是基于promise的http库,可运行在浏览器端和node.js中。他有很多优秀的特性,例如拦截请求和响应、取消请求、转换json、客户端防御XSRF等。所以我们的尤大大也是果断放弃了对其官方库vue-resource的维护,直接推荐我们使用axios库。如果还对axios不了解的,可以移步axios文档。

发布于:3月以前  |  292次阅读  |  详细内容 »

iOS 持续集成:更完备的 App Store Connect API

时隔两年 App Store Connect API 有了更新,WWDC 2018 推出了 App Store Connect API ,用于自动化一些 App Store Connect 后台操作。这次更新包含了 app 元数据相关的API,补上了原来缺失的重要一环, 使得几乎可以通过 App Store Connect API 完成 App Store Connect 上的所有操作。今后开发、证书配置、用户管理、测试、发布全流程都可以通过 API 完成。

发布于:3月以前  |  353次阅读  |  详细内容 »

iOS 性能优化:优化 App 启动速度

苹果是一家特别注重用户体验的公司,过去几年一直在优化 App 的启动时间,特别是去年的 WWDC 2019 keynote[1] 上提到,在过去一年苹果开发团队对启动时间提升了 200%

发布于:3月以前  |  327次阅读  |  详细内容 »

iOS圆角的离屏渲染,你真的弄明白了吗

发布于:3月以前  |  306次阅读  |  详细内容 »

iOS导航栏整体滑动解决方案(类似淘宝)

发布于:3月以前  |  359次阅读  |  详细内容 »

让你的应用远离越狱:iOS 14 App Attest 防护功能

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

发布于:3月以前  |  346次阅读  |  详细内容 »

探秘 iOS 14 的 WidgetKit

Widget Extension 提供了 small, medium, large 三个尺寸,不同尺寸可以展示不同的数据、不同的界面,开发者也可以锁定自己APP的 Widget 只有某类尺寸,相同的widget也能重复添加。作为添加在主屏幕上的控件,苹果用了 “At a glance” 来形容 widget ,所以 widget extension 是无法交互的,它能做的只有展示一些信息与点击两个作用,点击后就会引导至app,同时为了性能与耗电量的考虑,Widget extension 也不能展示视频和动态图像。

发布于:3月以前  |  383次阅读  |  详细内容 »

iOS 的自动构建流程

发布于:3月以前  |  410次阅读  |  详细内容 »

iOS14 Widget 万字指北,先人一步获得顶级流量

2020 年 6 月 22 日,苹果召开了第一次线上的开发者大会 - WWDC20。这次发布会上宣布了ARM架构Mac芯片(拳打Intel)、iOS 14 ATT(脚踢Facebook),可谓是一次载入史册(我是爸爸)的发布会了,当然还发布了被称为下一个顶级流量入口的Widget。踩着八月的尾巴,本次我们就来探究一下Widget。本文会从Widget初窥和Widget开发两个维度和章节来探究一下Widget, 其中初窥章节会带您简单的了解一下Widget,适合应用决策者阅读; 开发章节会带着您一步一步的完成设计开发Widget,适合程序员阅读。

发布于:3月以前  |  523次阅读  |  详细内容 »

iOS 性能优化 - Allocations分析内存分配

发布于:3月以前  |  375次阅读  |  详细内容 »

最多阅读

快速配置 Sign In with Apple 1年以前  |  3784次阅读
开篇 关于iOS越狱开发 1年以前  |  2565次阅读
APP适配iOS11 1年以前  |  2526次阅读
使用 GPUImage 实现一个简单相机 1年以前  |  2509次阅读
给数组NSMutableArray排序 1年以前  |  2487次阅读
在越狱的iPhone设置上使用lldb调试 1年以前  |  2440次阅读
App Store 审核指南[2017年最新版本] 1年以前  |  2336次阅读
UITableViewCell高亮效果实现 1年以前  |  2316次阅读
所有iPhone设备尺寸汇总 1年以前  |  2258次阅读
使用ssh访问越狱iPhone的两种方式 1年以前  |  2193次阅读
关于Xcode不能打印崩溃日志 1年以前  |  2117次阅读
使用ssh 访问越狱iPhone的两种方式 1年以前  |  2014次阅读
UIDevice的简单使用 1年以前  |  1805次阅读
为对象添加一个释放时触发的block 1年以前  |  1783次阅读
使用最高权限操作iPhone手机 1年以前  |  1749次阅读