探索管理式设备认证

♪ ♪ Bob: 大家好 我是 Bob Whiteman iOS 设备管理高级工程师 我很高兴与大家分享企业和教育环境中 设备管理的一个重要的安全新功能 我们首先回顾一下设备安全现状 用户需要访问组织资源 如网站 应用服务器和数据库 还有一些攻击者也想访问这些资源 保护资源的经典模型是 边界安全模型 您在内网周围划出安全边界 设置防火墙或 VPN 以允许合法客户端访问并拒绝威胁 但这种模式并没有跟上 人们与现代组织的互动方式 云服务提供商将资源置于边界之外 威胁可以从外围开始

威胁可以通过冒用合法客户端 来渗透防线

更现代的安全模型不信任网络边界 相反 每个资源执行自己的信任评估 这是零信任架构的核心原则

您可以将信任评估视为一个函数 输入是关于客户端的状态信息 输出是授予或拒绝访问的决定 正确的信任评估至关重要 误报会妨碍用户活动 或者更糟糕的是 误报允许攻击者访问您的资源 这意味着 掌握准确的状态信息也很重要 我们来研究一下状态的常见组成部分 您使用有关客户端及其请求的 所有可用信息 提出请求的人 他们使用的设备 他们的位置等等 信任评估可能在访问 不同资源的状态中使用不同的细节 访问低安全性的资源 可能只需要用户的身份 但访问关键的基础设施 可能需要评估所有状态项 由组织决定哪些细节是相关的

状态的一个核心元素是用户的身份 这表明谁在提出请求

Apple 设备提供了几种 支持验证用户身份的技术 比如 Extensible Single Sign On 功能 包括内置的 Kerberos 扩展 以方便对 App 网站和 帐户进行用户身份验证 新的 Enrollment Single Sign On feature 能让 App 在用户注册过程中 及之后便于认证 但本期讲座不是关于用户身份 而是关于设备身份的 此状态元素指示哪个设备 正在发出请求

设备在每次 MDM 通信中 报告的 UDID 是您的 MDM 服务器知道它 正在管理哪个设备的主要方式 DeviceInformation 查询 还提供设备的 MDM 服务器属性 包括序列号 除 MDM 服务器外 受管理设备经常与组织内的 其他系统通信 因此 MDM 服务器经常使用 客户端证书配置设备 此证书向其他系统声明设备的身份 这些识别设备的方法对我们很有帮助 但它们等于相信 这款设备就是它自称的那个样子 随着形势的变化 设备比以往任何时候都更加分散 我们的安全需求也在不断变化 为了解决该问题 我很高兴分享一个 用于认证设备身份的 强大新方法 Managed Device Attestation 有了 Managed Device Attestation 设备将在发出请求时 提供关于自身的有力证据 它改进了状态信息 因此 建立在这个基础上的 信任评估更准确 简言之 Managed Device Attestation 是指合法设备 能够可靠地访问资源并阻止攻击者 这个发布为 iOS 16 iPadOS 16 和 tvOS 16 带来了 Managed Device Attestation 本期讲座中 我们将首先概述新的认证功能 解释使用认证的好处 然后深入到实现细节 首先 什么是认证 认证是对事实的声明 如果您信任提出请求的实体 您就接受了这是真实的事实 在软件中 认证是经过加密签名的事实 通常是 X.509 证书 如果您信任签名者 那么您就会接受事实是真实的 对于 Managed Device Attestation 事实是设备的身份和其他属性 签名者是 Apple 接受这些设备事实的准确性 需要信任 Apple 但是 不需要信任 Apple 编写的每一行代码 只需信任 Secure Enclave 和 Apple 的认证服务器 这些服务器可以访问 Apple 的 生产记录和操作系统目录 如果您将数据保存在 Apple 设备上 就是在毫无保留地信任这些设备 以下是我们如何将认证的力量 带到被管理的设备上 Managed Device Attestation 提供了两种使用认证证书的方法 我们增强了 DeviceInformation MDM 命令 使 MDM 服务器可以 使用认证的好处 我们还增加了对 AutomaticCertificate Management Environment 协议的支持 这是通过添加 ACME 配置文件 有效载荷实现的 它使认证的好处在整个组织的 基础设施中都可用

对于 DeviceInformation 认证 MDM 服务器发出 DeviceInformationquery 并指定一些新密钥 Apple 服务器将获取认证 并将它返回给 MDM 服务器 然后 MDM 服务器评估认证

但注意 DeviceInformation 认证 向 MDM 服务器声明 “A device exists with these properties” 但不能认证 MDMserver 当前正在与之通信的设备 是同一个设备 为此 您需要 ACME 有效载荷认证

ACME 有效载荷认证 为设备的身份提供了 最强有力的认证 当您安装包含 ACME 有效载荷的配置文件时 设备会从组织 ACME 服务器 请求证书 这与安装 SCEP 有效载荷非常相似 设备向 ACME 服务器提供认证 基于对设备身份的有力认证 ACME 服务器颁发组织的 其他服务器信任的新客户端证书 这两个新功能使用认证证书 来证明几件事 该设备是正品 Apple 硬件 该设备是特定装置 该设备具有某种属性 并且私钥已绑定到设备 它向不同的服务器证明 它们正在 与同一设备通信 这些证书对您有什么好处 认证主要是一种安全功能 所以我将描述一些威胁 以及认证如何降低威胁

首先 一款被泄露的设备 会谎报其属性 所以 Apple 会认证其属性 即使操作系统受到威胁 这也不会影响认证的可靠性 只需要 Secure Enclave 完好无损 或者受损设备提供了过时的属性认证 而这些属性已经发生了变化 证明文件中的临时文件可确保 事实是最新的 ACME 有效载荷认证 可以减轻其他威胁 受损设备 在与 MDM 服务器通信时 发送不同的设备标识符 因此 Apple 验证设备标识符的方式 与设备用于验证 TLS 连接的客户端身份相关联 这可以向 MDM 服务器和 其他组织服务器 证明它们与哪个设备通信

或者攻击者从合法设备中提取私钥 并使用它来发出请求 欺骗合法设备 Apple 证实 私钥受 Secure Enclave 保护 该软件对私钥的 导出或导入具有特别强的保护 最后 攻击者劫持证书请求 以获取证书颁发机构 为不同的设备颁发证书 Apple 通过将请求设备与 证书请求绑定的方式 来验证该设备的身份 因此 证书颁发机构只向合法设备 颁发证书 证书为您提供安全方面的好处 从而减轻多种威胁 那么您如何在您的环境中使用呢 让我们详细了解 如何实现 Managed Device Attestation 首先 对 DeviceInformation 命令 进行了增强 MDM 服务器可以向 受管设备发出此命令 该请求包括服务器想知道的属性列表 我们添加了一个新属性 DevicePropertiesCertification 将其添加到 Queries 数组 意味着 MDM 服务器 正在请求认证 为确保认证是新鲜的 MDM 服务器可以使用 DeviceAttestationNonce 密钥 与 Queries 密钥出现在 请求中的同一级别 该密钥是可选的 它的值是一个数据对象 最大大小为 32 字节 这是一个请求认证的示例 查询数组包含 DevicePropertiesCertification 密钥 并且有一个32 字节的临时文件 取证成功时 响应包含一个 DevicePropertiesCertificate 密钥 它的值是一个数据对象数组 数组中的每个元素 是证书链中的一个证书 这是一个示例响应 叶证书首先出现在数组中 它包含自定义 OID 中的设备属性 前两个 OID 是设备标识属性 序列号和 UDID 如果 MDM 注册是 User Enrollment 则它们会从证书中省略 其余 OID 是匿名的 可用于所有注册类型 sepOS 版本是指在 Secure Enclave 上运行的 操作系统的版本 临时文件 OID 中存在正确的值 证明证书生成了 当 MDM 服务器收到认证时 必须按照以下顺序仔细地验证 它验证证书链是否植根于预期的 Apple 证书颁发机构 Apple 证书颁发机构 可以从 Apple Private PKI Repository 中获得 它验证叶证书中的临时文件 是否与 DeviceInformation 请求中的临时文件匹配 如果已指定的话 然后它解析出剩余的 OID 并评估它们的值 生成新的认证需要使用设备 和 Apple 服务器上的 大量资源 所以对于请求新认证证书的频率 存在速率限制 目前每七天请求一个新认证 通过指定新的临时文件 来请求新的认证 省略一个临时文件表明 新鲜度不是问题 因此 设备可以返回其最新的认证 如果指定了随机数 并匹配缓存的认证 则返回缓存的认证 当 MDM 服务器在认证中 验证临时文件时 它应该检测到不匹配的临时文件 并确定这是否是由于缓存而导致的 但不要仅仅因为这是利率上限 就要求每七天更新一次认证 这样做只会延迟您的 MDM 服务器发现更改的速度 在设备属性上 更不用说浪费资源了 相反 监视其他 DeviceInformation 属性中的相关更改 比如操作系统版本 当其中一项发生更改时 就请求新的认证 这可确保在更改后尽快更新认证 而不是等待速率限制到期 为了防止设备被泄露 并谎报这些其他属性 您可以偶尔随机要求提供新的认证 以保持设备诚实 请求认证可能会失败 这种情况时 设备仍会响应 但省略了一些信息 可能响应中省略了 DevicePropertiesCertification 字段 或是一个预期的 OID 抑或是它的值被省略了 失败的原因有很多 设备在到达 Apple 认证服务器时 遇到网络问题 没有服务器 100% 的时间都在运行 因此 Apple 的认证服务器 可能存在问题 或者设备硬件或软件可能受到损害 或者甚至不是真正的 Apple 硬件 在最后三种情况下 Apple 的认证服务器 拒绝为它们无法验证的属性 发布认证 认证失败的原因有很多 从无害的网络故障到主动攻击 不幸的是 MDM 服务器没有可靠的方法 知道确切的原因 这是因为关于故障的唯一信息来源 是设备本身 它可能是一个在撒谎的受损设备 那么 MDM 服务器应该 如何解释故障呢 认证失败时 不要总是假设最坏的情况 如果您有一个零信任架构 那么您可能会采用以下方式处理它 该组织计算设备的信任分数 失败或意外失效的认证 会降低该分数 信任评分降低会触发不同的操作 比如拒绝服务访问 将设备标记为人工调查 或通过清除设备 吊销其证书来进行补救 这可以确保 对失败的认证做出适当的响应 让我们继续实施 ACME 有效载荷认证 安装 ACME 有效载荷 涉及几个步骤 我将描述该过程中的不同参与者 然后是每个步骤 我们从 iPhone iPad 或 Apple TV 开始

在大多数情况下 这是由 MDM 服务器管理 有一个 ACME 服务器 这执行了 ACME协议 RFC 8555 因此它可以从组织证书颁发机构 颁发客户端证书 并且有 Apple 的认证服务器 发布认证

第一步是 让 MDM 服务器安装配置文件 包含 ACME 有效载荷 有效载荷指定设备 将生成的密钥属性 设备将请求的证书属性 以及如何从 ACME 服务器请求证书 要开始安装配置文件 设备生成请求的密钥类型 为了使用证书 密钥必须是硬件绑定的 虽然 ACME 有效载荷支持 RSA 和各种大小的密钥 但为了获得硬件绑定密钥 必须使用 ECSECPrimeRandom 您的最佳选择是 ECSECPrimeRandom 384 位密钥 因为这是最高安全性的硬件绑定密钥 创建密钥后 设备将与 ACME 服务器进行初始联系

设备请求 DirectoryURL 它指定用于其余过程的 URL 与 ACME 服务器的通信 然后两个系统创建一个帐户 和一个订单 服务器提供 device-attest-01 验证类型 然后 ACME 服务器生成一个临时文件 并将其发送到令牌字段中的设备 ACME 协议最初用于 颁发服务器证书 但是在这里 我们使用的验证类型 是在 IETF 草案中引入的 该草案指定了 ACME 协议的扩展 认证和颁发客户端证书

认证是可选的 当有效载荷指定认证时 设备请求 Apple 提供认证 这几乎与 DeviceInformation 认证相同 它使用相同的 OID 并且为 User Enrollment 省略了设备标识的 OID 但有一些不同之处 临时文件在嵌入认证之前 使用 SHA-256 进行哈希处理 临时文件来自 ACME 服务器 而不是 MDM 服务器 认证叶证书匹配的私钥 是设备刚刚生成的那个 认证证书与私钥匹配 但是 该证书不能用于 除认证之外的任何目的 所以设备从 ACME 服务器 请求另一个证书 匹配私钥 这个证书对 TLS 有好处

设备提供证书签名请求 包含来自有效载荷的证书请求属性 它提供了认证链 它还提供来自 ACME 有效载荷的 ClientIdentifier 通常这就像一张票一样使用 这有利于签发单一证书 以防止重复请求 ACME 服务器在发出证书之前 必须按照此顺序仔细验证请求 它必须验证 ClientIdentifier 是否有效且未使用 认证证书必须链接到 正确的 Apple CA 认证叶证书中的 公钥必须与 CSR 匹配 临时文件必须匹配 ACME 服务器 之前发送的 SHA-256 哈希值 然后 ACME 服务器 可以评估剩余的 OID 请记住 认证可能会失败 在颁发证书时 ACME 服务器 应该仔细考虑失败 就像我们在 DeviceInformation 案例中审查认证失败一样 从这里开始 事情很快就结束了 ACME 服务器从组织 CA 颁发 客户端证书 并将其返回给设备

ACME 服务器是客户端证书 颁发的最终机构 它可以选择尊重或覆盖 CSR 中的属性 例如 SubjectAltName 设备将证书存储在密钥链中 这样就完成了 ACME 有效载荷的安装

让我们把这一切联系起来 服务器如何知道与它们通信的设备 就是声称的那个 设备使用同一个私钥的方式有多种 在获得 Apple 认证时 从 ACME 服务器获取客户端证书时 以及使用 TLS 与其他服务器通信时 因为密钥是硬件绑定的 我们知道所有这些操作 都是由同一个设备执行的 而且我们有一个 描述该设备的认证证书 结合这些 组织服务器现在 在授予访问权限时 对设备的身份有信心

就像证书和 SCEP 有效载荷一样 配置文件中的其他有效载荷 可以引用 ACME 有效载荷 以使用证书 将它用于 MDM Wi-Fi VPN Kerberos 和 Safari 浏览器 所有这些系统都得益于认证

一个设备可以有多达 10 个 ACME 有效载荷 同时使用安装的认证 请注意 硬件绑定的密钥不会被保留 当受管设备的备份恢复时 即使恢复到同一设备 如果您对 Managed Device Attestation 不做任何其他操作 那么可以对 MDM 客户端身份 使用 ACME 有效载荷 因此 MDM 服务器可以 确定它正在管理哪个设备 我们来总结一下 您可以使用 Managed Device Attestation 认证来修复多类威胁 利用 DeviceInformation 认证 来改进设备标识组件的状态 以获得更好的信任评估 而且 您现在可以在设备访问 组织资源时使用 ACME 认证 来认证其身份 我们期待开发者实施 Managed Device Attestation 我们将共同提高 开发者设备部署的安全性 谢谢 祝您的 WWDC 之旅一切顺利