使用 App Attest 和 DeviceCheck 减少欺诈

使用 App Attest 和 DeviceCheck 减少欺诈

了解如何使用 Apple 强大的反欺诈工具 App Attest 和 DeviceCheck 来保护您的 app 和内容。深入探究如何将其与您的 app 集成来部署 App Attest，从而阻止您的 app 和内容在未经授权的情况下遭到修改。此外，我们还将展示如何使用 DeviceCheck 来确保您能够区分客户，辨别哪些已在您的 app 中收到优惠内容，而哪些是通过非法手段取得优惠内容。

资源
相关视频

WWDC21
- 保护您的帐户、促销和内容
下载

♪ ♪ 大家好欢迎收看本期视频 “使用App Attest 和DeviceCheck减少欺诈” 我是严学瑞在App Store信任与安全团队工作很高兴可以和大家讨论使用App Attest 和DeviceCheck 保护你的应用程序在Apple公司我们一直致力于确保App Store 对用户和开发者而言是安全可靠的在本期视频中我们将讨论工程细节内容如想了解相关业务和概念详情可参考视频“保护你的账户推广活动和内容” 来自2021年的WWDC会议
在iOS 11中我们引入了DeviceCheck框架 DeviceCheck框架有助于减少对促销优惠的欺诈行为假设你的应用程序新增了某项功能为了推广该功能你提供一项免费只可使用一次的促销优惠也许会有人多次领取该优惠通过一遍又一遍地重装应用程序以获得免费的优惠很有可能你想限制优惠的领取如每个设备只可领取一次而不是允许应用程序被重复地安装导致优惠的再次领取
现在 DeviceCheck 可以帮助你检测一个设备是否已经领取过促销优惠或者一个设备是否存在欺诈行为
它允许你在Apple服务器上持续存储单个设备的两个二进制位信息和一个时间戳
这两个二进制位对你的应用程序有何意义由你来定
其状态由Apple负责维护可供你进行更新和查询
同一个开发者的所有应用程序共享这两个二进制位因此需牢记这两个二进制位的定义以便其适用于你的所有应用程序
它们的状态会维持不变不论是应用程序重装不同用户登录同一设备甚至是“抹掉所有内容和设置” 考虑使用时间戳重置这两个二进制位在做选择的时间节点基于你的促销和业务策略
想了解更多关于DeviceCheck的内容可参考视频 “隐私和你的应用程序” 来自2017年WWDC大会以及DeviceCheck框架文档
以上介绍的是DeviceCheck 接下来我将介绍App Attest 它同样在DeviceCheck框架之中
当你的服务器接收到一个请求时可能会很难判断该请求确实来自你的应用程序
App Attest允许你的应用程序附加一个基于硬件的断言作为访问请求的一部分你的服务器可使用断言核实访问请求是否来自正版应用和正品Apple设备设想一下你设计了一款很棒的应用程序旨在鼓励用户通过旅行发现收藏品结果却发现被篡改的应用程序允许收集所有藏品连家门都不需要出
或者想象下在多玩家竞技比赛中当玩家看到其他对手通过作弊手段获得了无限加成从而在排行榜上快速蹿升他们的那种沮丧之情
或者再想象下你在一个周六醒来满心欢喜地发现服务器端有大量的访问请求然而经过调查你发现这些访问请求根本不是来自你的应用程序
App Attest可以协助你识别应用程序的正版和篡改版本进而保护应用程序的用户体验和你的业务
App Attest提供三个关键性能有助于保护你和你的用户
App Attest允许你的服务器核实一个请求是否来自应用程序的合法版本通过满足三个条件：请求来自正品Apple设备运行你的正版应用软件且有效负载未遭篡改
让我们详细介绍App Attest 提供的这三个性能 App Attest的核心在于一个安全密钥对以及一项由Apple签名的认证证明密钥对来自正品Apple设备使用App Attest API 通过Secure Enclave模块存储和访问私有密钥
应用程序可以使用密钥对服务器请求进行签名服务器可以通过核实签名验证请求是否来自正品Apple设备
对于在Apple设备上运行的应用程序它必须经过签名任何人如果篡改你的应用程序必须使用他们的身份重新签名这就不可避免地修改了应用程序的身份
认证中包含应用程序身份的哈希版本
通过比较你的应用程序身份和认证中的身份就可以判定一个访问请求是否来自篡改应用程序版本
由于你已经知道请求来自正品设备和正版应用程序让我们来讨论下请求有效负载
在向你的服务器发送一个有效负载之前可以通过使用经验证的密钥利用App Attest 对有效负载的摘要进行签名这会生成一个有效负载的断言
你的应用程序会将有效负载和相应的断言传输至你的服务器通过验证有效负载的断言你可以确认有效负载没有在传输中被篡改
以上就是三大关键性能现在让我们来稍微谈谈隐私的话题
在Apple 我们高度重视隐私问题我们坚信隐私是一个健康应用生态系统的基石 App Attest的每个要素都将隐私问题考虑其中
认证的设计可用于验证正品设备同时防止被追踪认证是匿名的且不包含硬件标识
应用程序的每次安装 App Attest密钥都是唯一的这意味着一个App Attest密钥无法继续存在于应用程序的重装也无法备份以及无法在跨设备中同步你在设计应用程序时请记住这一点
既然你现在已经了解App Attest的价值所在让我们更深入地讨论如何将其引入你的应用程序中将App Attest引入你的应用程序包含三个基本部分创建App Attest密钥证明和验证这个密钥生成和验证断言让我们以创建App Attest密钥作为讨论的开始所有App Attest的调用都受到isSupported函数的检验支持App Attest的设备需要包含Secure Enclave 但也有一些情况比如应用程序扩展函数isSupported的返回值仍然为false 你的应用程序必须合理地处理这些情况
应该将故障作为一种风险信号而不是直接拦截访问首先将一个访问归类为不可信然后根据你的风险评估逻辑评估是否允许该客户端使用敏感功能
另一种方法是监测那些访问你的服务器时声称不支持App Attest 的设备突增如果支持App Attest的设备比例骤减这也许预示着篡改版本应用正试图绕开检查在一个App Attest密钥顺利生成的情况下让我们接着验证这个密钥为防范中间人攻击和重放攻击我们需要来个单次的服务器请求让你的服务器将请求传至应用程序
将认证与用户的账户身份或其它参数相连散列这些参数和该请求以创建clientDataHash 使用上一步骤的clientDataHash参数以及密钥标识我们就可以开始调用attestKey API
attestKey将使用私有密钥为设备创建一个硬件认证请求然后将请求发送至Apple 进行验证一旦通过验证 Apple将一个匿名的认证对象返回至你的应用程序将认证和相关的自定义有效负载发送至你的服务器进行验证好的既然你的应用程序已经发送认证至你的服务器让我们试着对其进行验证
该认证遵循网络身份验证标准其包含三部分内容：一系列由Apple签字的证书认证数据结构和风险指标回执
让我们关注你需要验证的重要部分
证书部分包含叶证书和中间证书 App Attest根证书可以在Apple的私有公钥基础设施库中获得通过验证整个证书链可以确定一个设备是否为正品Apple设备
当你调用attestKey时一个一次性使用的哈希值也被称为一个随机数即从clientDataHash 和其它数据中被创建该随机数包含在叶证书之中
为防范篡改你在服务器中重现该随机数并进行匹配验证
认证器数据模块包含若干项内容如一份应用程序身份的哈希版本这用于验证服务器的访问来自你的应用程序
密钥认证还包含一份回执你可以存储并在日后用于向Apple请求一份风险指标数据我将在视频中介绍更多关于这部分的内容
如果一切都验证成功 App Attest密钥是对的存储密钥和客户数据以备验证后续请求之用
不是所有验证失败都源于认证无效合理地处理其它相关情况比如isSupported函数返回值为false 因为访问量增加时被节流或者普通网络故障这样你就可以将验证失败作为你的整体风险评估的信号
想了解更多关于实现验证的详细内容请参考相关文档调用attest-Key API 会生成你的应用程序和App Attest服务之间的网络访问每个应用程序每次只发生一次然而如果应用程序的用户基数大大量用户的应用程序可能会共同向App Attest发送很多请求为了管理好资源避免被限流需要确保你已经解决了安装量的问题举个例子如果你有一百万日活跃用户你可能需要一两天来提升效能如果你有十亿日活跃用户这很棒你可能需要不止一个月
由于有了认证密钥你可以调用generateAssertion API 来保护你的应用程序和服务器之间的敏感通信
断言流比断言更简单因为这里已不再涉及Apple服务器
所有断言使用的密钥产生于设备端并在你的服务器上进行验证
首先从服务器发起一个独特的请求然后生成有效负载的摘要和调用generateAssertion generateAssertion 将使用有效负载摘要一个随机数并使用App Attest 密钥对其进行签名
随后你的应用程序可以将有效负载和断言发送至你的服务器最后你的服务器会验证该有效负载
断言有效负载由这样的高级结构组成签名和认证器数据
为了验证签名在你的服务器上反向操作重现随机数然后使用公钥验证签名
如果签名有效你就可以确信有效负载没有被篡改
认证器数据部分包含应用程序身份哈希值
验证该列表可以确认断言来自你的正版应用程序
认证器数据也包含一个不断增长的计数器为防范重放攻击可在你的服务器上保存计数器的值并指定这个值随着每个后续请求而增加
有了密钥你现在可以按需不断重复该过程由于生成断言不需要访问Apple服务器它是个加密操作会带来一定的时延当你在应用程序中加入App Attest时在设计时需要将这一点考虑在内
断言非常适合重要但频率不高的访问这些访问可以应对额外的延迟和必要的计算
对于高频实时的网络指令断言可能不太适用
值得祝贺的是你现在已经完成了App Attest的实施单是完成这一点你就可以开始将接收到的服务器访问分类为正版或篡改版本并将这个重要的欺诈信号运用于你的业务逻辑但问题没这么简单攻击者可能会试图绕开App Attest 通过使用一个设备创建很多个App Attest密钥然后使用那个设备充当许多篡改版本应用程序与你的服务器之间的通信媒介为检测这样的行为我们提供一项服务名为App Attest风险度量服务它规定一个设备能为你的应用程序创建的大致密钥数量重新调用attestKey将返回认证和一份风险指标回执你的服务器可以将该回执发送至风险度量服务然后兑换一份新的回执这份新的回执将包含风险指标
定期地你可以兑换最新的回执以获得应用程序及对应设备最新的指标
这是回执结构的高级视图它是个加密消息的语法标准容器详情可参考DeviceCheck 框架文档里的 “评估欺诈风险”内容
轻App 是iOS中令人兴奋的功能我们在iOS 15中为轻App 增加了对App Attest的支持为支持轻量版应用无缝升级至完整版应用在App Attest环境中轻量版和完整版应用程序拥有相同的应用程序身份在你的服务器端验证应用程序身份时请务必记住这一点
当轻App被手动删除或者服务终止时他们的密钥将会失效正如完整版应用程序未被安装一样
好的关于轻App就介绍这么多现在要记住成功运用App Attest 的关键要素在服务器端验证而非设备端应用程序也许会被篡改进而使验证码失效
将一次性的服务器请求加入到你的断言流中以阻止网络重放攻击
处理失效场景比如isSupported函数返回值为false 访问量增加时被节流或者普通网络故障将故障作为风险评估的信号
App Attest and DeviceCheck 提供的信息可供你应用于整体欺诈评估使用DeviceCheck减少促销优惠的欺诈行为
利用App Attest检测应用程序的篡改版本保护你的内容和用户体验感谢收看我期待看到你的应用程序得到App Attest 和DeviceCheck的保护再见

let appAttestService = DCAppAttestService.shared

if appAttestService.isSupported {
    appAttestService.generateKey { keyId, error in
        guard error == nil else { /* Handle the error. */ }
        // Cache keyId for subsequent operations.
    }
} else {
   // Handle fallback as untrusted device
}

9:34 - Generate key attestation

appAttestService.attestKey(keyId, clientDataHash: clientDataHash) { attestationObject, error in
    guard error == nil else { /* Handle error. */ }

    // Send the attestation object to your server for verification.
}

13:14 - Generate assertion

appAttestService.generateAssertion(keyId, clientDataHash: clientDataHash) { assertionObject, error in
    guard error == nil else { /* Handle error. */ }
    
    // Send assertion object with your data to your server for verification
}

正在查找特定内容？在上方输入一个主题，就能直接跳转到相应的精彩内容。

提交你查询的内容时出现错误。请检查互联网连接，然后再试一次。

资源

相关视频

WWDC21