使用 App Attest 保护你的 App

你好 我的名字是Manthan 我是信任与安全团队的一名工程师 今天 我将介绍App Attest 如何帮助保护你的App和用户 你构建并分发了你的App 以便其正常运行 在Apple平台上的安全环境中 欺诈者总在寻找 利用你App的方法 超出其预期功能的漏洞 这可能包括攻击场景 即你App的被篡改副本 向你的服务器发送看似合法的请求 以获取敏感数据 想象一下 你构建了 一个测验监考App 供学生参加测验并提交答案 欺诈者可能会逆向工程你的App 创建修改版本 向服务器提交虚假测验答案 App Attest可帮助你的服务器 拒绝此类请求 来自被修改的客户端 或者在你的App中注入 你未发布的内容 通过直接修改 被篡改的源代码副本 或相关资源包 并重新签名你的App 并在设备上运行 修改后的副本 想象一下 你有一款屠龙游戏 欺诈者在游戏中注入了 可增强能力的作弊菜单 这使他们能够向你的服务器 提交虚假分数 并使用被篡改的游戏App 在排行榜上名列前茅 App Attest旨在应对 此类威胁场景 我将从App Attest 防护的内容开始介绍 然后介绍集成步骤 和最佳实践 我将指出一些常见陷阱 并以欺诈指标作为结尾 这是检测可疑认证活动 的强大工具 先来看App Attest如何 帮助保护你的App App Attest可帮助确保你的App 运行在正版Apple硬件上 它通过颁发一个认证来实现 该认证提供加密证明 证明你的App在用户设备上 合法运行 然后可由你的服务器验证 确保你的App运行在 安全的Apple设备上 其次 它帮助你了解 你的App是否被修改 在用户设备上 App Attest提供 依赖方的相关信息 启动类别以及与你App 关联的Bundle版本 所有这些都有助于你 判断App是否被修改 你的App通过 依赖方标识符被唯一识别 这是你的Team Identifier的组合 来自 Apple开发者预置描述文件 以及App的Bundle标识符 想象一下 欺诈者修改了你的App 并使用与你的Team Identifier 不匹配的预置描述文件重新签名 App Attest会在用户设备上 显示你App的身份信息 帮助你发现 未经授权的修改 iOS 27的新功能 它会突出显示用户设备上 你App的启动验证类别 你可能通过App Store 分发了你的App 但观察到App Attest显示 TestFlight启动验证类别 它还会识别你发布的App版本 的Bundle版本 如果欺诈者使用更新的Bundle版本 重新签名你的App 而你并不知情 App Attest将使其透明化 最后 你可以使用App Attest 保护从App到服务器的载荷 App Attest可以生成断言 使用之前颁发认证的加密属性 然后你的服务器可以验证 App载荷中的断言 确保载荷在传输过程中 未被篡改 基于以上指导 下面介绍App Attest的工作原理 以及如何采用它 我将介绍App Attest 的每个核心部分 首先确定App Attest 的可用范围 App Attest支持 所有Apple平台 包括macOS 27及更高版本 此前不支持macOS 虽然App Attest在所有 主要Apple操作系统上可用 但在这些平台上 并非所有App类型均可使用 通过isSupported API 控制App Attest的使用 来自App Attest框架 例如 App Attest可用于 Action和SSO App扩展 但不适用于其他类型的App扩展 你也可以将isSupported的响应 用作欺诈信号 将其纳入你的风险评估中 如果你在受支持的平台上 分发了你的App 但观察到某特定用户 不支持响应的激增 这可能表明存在篡改 你应该决定是否 允许用户继续使用 当App Attest不支持时 你App的相关功能 接下来是App Attest 工作流程的第一步 即生成Key ID 你的App首先调用App Attest 生成一个Key ID App Attest代表App创建 一个绑定Secure Enclave的密钥对 私钥存储在Secure Enclave中 App Attest将公钥的哈希值 返回给你的App 然后你的App将Key ID 存储在Keychain中 处理App Attest密钥时 应注意一些最佳实践 对于基于账户的App 每个用户生成1个密钥 或为用户设备上整个App 生成1个密钥 不要在用户群体中共享密钥 使用Keychain存储 App生成的Key ID Key ID在App安装期间 一直有效 它们在App更新后依然有效 但如果用户重新安装App 或恢复设备 包括从iCloud备份恢复 密钥将失效 密钥是按设备的 不会在用户设备间同步 以上是App Attest密钥生成的介绍 这些是认证和断言的基础 你的App已经生成了Key ID 现在可以请求App Attest 证明该密钥 你的App从Keychain获取Key ID 你的App请求服务器 对Key ID执行认证 你的服务器通过向App 发放质询来响应 以包含在认证中 你的App调用认证API 来自App Attest框架 提供Key ID和服务器质询 App Attest获取 Key ID对应的密钥对 以及设备中的一些认证数据 此认证数据 来源于Secure Enclave 其中包含设备启动时 硬件属性的快照 它无法被修改 它向Apple服务 发起服务器请求 用以验证设备数据 并返回一个认证 App Attest将认证对象 返回给你的App 你的App将认证 发送至你的服务器 你的服务器应验证该认证 我们接下来将介绍这一步 保存它并将其与 你App的用户关联 有一些最佳实践需要注意 在收集和处理认证时 重要的是由你的服务器 控制认证的发起 这有助于确保 你的App保持在安全的 每秒请求数上限内 认证可能失败 你的App应在稍后重试 实现指数退避策略 以避免触及全局速率限制 不应在你的App中 硬编码重试逻辑 以减少对Apple认证服务器 的不可控请求激增 你的App应在用户流程之外 收集认证 尝试在后台任务中 执行认证操作 最后 认证应始终由服务器验证 而非App 如果你的App被入侵 将无法信任其进行认证验证 我现在将介绍认证本身 即App Attest认证API 返回的对象 认证结构分为三个部分 格式 认证声明 以及认证器数据 格式是标识Apple匿名认证 的固定字符串 其次是认证声明 其中嵌入了 加密证书链和收据 证书链 证明被认证的密钥 是在正版Apple硬件上生成的 请遵循开发者文档 验证证书链 其中包含nonce和Key ID 以及嵌入在叶证书中 的依赖方标识符 在macOS 27及更高版本中 还有一个密钥访问控制属性 称为ACL Blob OID 也包含在叶证书中 这代表与App Attest密钥 相关联的安全条件 这些条件由Secure Enclave强制执行 即在设备上 收集认证时 密钥访问控制属性 适用于所有平台 但在macOS上尤为重要 在macOS上 App Attest 为每个生成的密钥配置 要求完整安全模式和 System Integrity Protection的策略 完整安全模式确保最高安全级别 并验证 用户设备上 操作系统的完整性 System Integrity Protection 可防止执行未经授权的代码 并保护系统路径 这两项在Mac设备上 默认均已启用 通过验证 密钥访问控制属性 你可以确认 在用户设备上执行的安全条件 认证声明还包含一张收据 其格式与App Store收据类似 你应遵循 开发者文档来解析此内容 你应验证依赖方ID 被认证密钥和服务器质询 这些均包含在收据中 你的服务器应存储此收据 以便与欺诈指标对接 最后是认证器数据 用于标识你的App 和认证的相关信息 请遵循开发者文档来解包 认证器数据并验证其内容 在iOS 27及更高版本中 认证器数据末尾附加了 一种新结构 称为扩展 其格式遵循 Web身份验证标准 针对认证器模型 我将花些时间介绍扩展 以及服务器如何处理 认证器数据的这一部分 扩展描述了你的App 的额外安全属性 这些属性在认证过程中 从设备上收集 新增了两个扩展标识符 启动验证类别和Bundle版本 启动验证类别 帮助你了解你的App 是否在意外环境中执行 Bundle版本帮助你确认 你App的某个版本 你所分发的版本 正在用户设备上运行 你应监控这些属性 检查意外值 并将其纳入对用户 的整体风险评估 以上就是认证的内容 它对检测篡改迹象 尤为有用 例如 你有一个集成了 App Attest的macOS App 设想一个欺诈者禁用了 System Integrity Protection的场景 他们随后修改你的App 并用不同的预置描述文件重新签名 并修改系统路径中的 App Attest框架 你的服务器收到的认证 将突出显示已禁用的 System Integrity Protection状态 通过密钥访问控制属性体现 它还可能包含 已修改的Team Identifier 启动验证类别或Bundle版本 你的服务器可以拒绝 与App修改版本的通信 并将此纳入对该用户 的风险评估 你的服务器已验证认证 并存储了公钥 你的App可以使用该已认证密钥 通过断言保护 持续的通信 你的App准备与服务器 通信一些数据 你的服务器提供质询 以包含在App的载荷中 你的App获取Key ID 并调用App Attest框架 中的断言API 提供Key ID 和服务器质询 App Attest将编码的断言对象 返回给你的App 然后你的App将断言对象 嵌入其载荷中 并将载荷传输至你的服务器 你的服务器验证断言 并接受或拒绝载荷内容 随着你的App生成断言 你应牢记 一些重要注意事项 按需生成断言 断言在设备本地生成 且不会往返于Apple服务器 可在App生命周期中 需要时生成 以嵌入服务器载荷中 断言会影响CPU性能 生成断言涉及 执行加密操作 注意不要频繁生成断言 或在App生命周期内 生成过多断言 你的服务器应验证 断言中嵌入的计数器属性 并确保其严格递增 服务器应跟踪 与用户关联的断言的计数器 这提供了 防重放攻击的保护 每次你的App嵌入断言时 断言对象中的计数器值 应该增加 如果你观察到 计数器值保持不变或递减 这可能表明 存在被篡改的App副本 该副本不知晓 服务器记录的计数器值 现在 我将简要介绍 如何解析断言对象 断言是包含两个部分的结构 签名和认证器数据 请遵循开发者文档 使用认证器数据验证签名 服务器质询以及 认证对象中的公钥 与认证类似 断言对象中的认证器数据 标识断言时你的App 的相关信息 在iOS 27及更高版本中 认证器数据末尾 附加了一种新结构 称为扩展 应以与扩展相同的方式处理 认证对象的 认证器数据中的扩展 以上就是断言 也涵盖了 App Attest的核心部分 断言对确保服务器请求 尤为有用 来自有效App副本的服务器请求 接下来 介绍一些 值得注意的常见陷阱 你的服务器应谨慎处理 来自你App的 可疑活动场景 考虑为现有用户 处理新认证的情况 不要直接拒绝新密钥 因为合法场景例如 App重新安装或设备恢复 可能导致密钥轮换 这也意味着 不要立即使该用户 之前认证的密钥失效 结合欺诈指标 你的服务器的认证映射 对于用户可用作 欺诈或滥用信号 如果你的服务器 拒绝认证或断言 你的App应优雅地处理此情况 对该用户降级 与App Attest相关的功能 在加强监控的情况下 给予用户有限访问权限 避免未经全面风险评估 直接封锁用户 我来阐明我所说的 对用户进行风险评估的含义 这取决于你的业务 以及你所分发的App类型 以及App中潜在欺诈的影响 如果你基于App Attest 怀疑某用户存在欺诈行为 请遵循你的业务准则 来停用或暂停用户 请记住 未经适当评估 封锁用户可能会损害信任 并可能影响合法用户 始终遵循明确的 风险评估流程 你现在已有 全面深入的了解 了解App Attest的核心流程 以及如何与其最佳交互 App Attest最后要介绍 的部分是欺诈指标 这是检测可疑认证活动的工具 被入侵的设备仍可通过认证 并充当代理 代表被修改的App实例 生成有效认证 运行在其他设备上的实例 这些修改后的App可以向你的服务器 发送被篡改的请求 欺诈指标 提供唯一已认证密钥 的近似计数 与你的App关联 在过去30天内某设备上的计数 你可以将其用作 对用户风险评估配置文件的一部分 通过判断该用户 是否与认证相关联 来自可能被入侵的设备 欺诈指标通过你的服务器 进行访问 与App Attest数据服务器之间 你的服务器从与用户关联的 认证中检索收据 然后向App Attest数据服务器 发送POST请求 使用检索到的收据 数据服务器随后将 一张收据返回给你的服务器 其中包含欺诈指标 你应将其用于后续的收据获取 收据的结构类似于 App Store收据 它包含三个部分 签名 证书链以及收据载荷 签名对收据载荷进行签名 证书链根植于 Apple认证机构 收据载荷包含相关信息 关于与指标关联 的已认证密钥 以及欺诈指标本身 请遵循开发者文档 验证此收据载荷 的不同部分 风险指标字段 定义欺诈指标计数 收据也必须刷新 not before字段概述了 可以刷新收据的最早时间 到期时间字段 描述收据的到期时间 之后收据将无法再刷新 使用欺诈指标时 请考虑以下事项 任何涉及 App Attest密钥轮换的用户操作 都会影响欺诈指标 例如 重新安装App 或恢复设备 可能会强制在你的App中 重新生成密钥并重新认证 这些操作都会影响欺诈指标 避免使用欺诈指标 直接封锁用户访问App 将欺诈指标视为 欺诈活动调查信号 你应监控其值 以建立基准 并将峰值识别为 可疑活动的指标 现在你已具备使用App Attest 保护App工作流程所需的一切 保护用户安全 并确保你的App安全 要继续你的学习之旅 首先使用最新SDK 重新构建你的App 以便访问 App Attest API的最新功能 找出你App中 可以从认证安全性中 受益的区域 例如身份验证流程 或付费内容的敏感载荷 可以通过断言来加强 配置你的服务器验证认证 存储收据并跟踪断言计数器 将欺诈指标纳入 你的风险评估流水线 App Attest为你提供了 验证App完整性的工具 保护App与服务器之间的通信 并检测欺诈迹象 这一切都有Apple硬件 安全性的支撑 现在去为你的用户 实施这些保护措施吧 感谢观看