
-
开始使用量子安全加密技术
了解如何通过抵御量子计算这一新兴威胁来保护 App 的敏感用户数据,并了解如何保护用户隐私。我们将探索不同类型的量子攻击、它们对现有加密协议的影响,以及如何使用量子安全加密技术来抵御这些攻击。你将了解如何使用量子安全 TLS 来保护网络数据,以及如何使用 CryptoKit 的量子安全 API 来保护应用程序数据。
章节
资源
-
搜索此视频…
大家好 我是 Cathie 来自 Cryptography Engineering 团队 本视频将介绍如何通过 量子安全加密技术未雨绸缪
你开发的应用程序 在用户生活中占据着重要位置 你的 App 也许能够访问 用户的个人敏感数据 而且已经采用了加密技术 来保护这些数据
但随着量子计算的崛起 现有加密技术的安全性正面临威胁 量子攻击可破解 或削弱许多广泛使用的算法 你需要通过转向量子安全加密技术 来提前规避这一风险 首先 我将详细分析加密技术 面临的各类量子攻击 受影响的协议 以及如何使用量子安全 加密技术来抵御这些攻击 接着 我将探讨如何通过 量子安全 TLS 加密技术 保护网络数据免受量子攻击威胁 最后 我将介绍如何利用 CryptoKit 中的新型量子安全 API 来保护自定协议
首先 我们来看看加密技术 面临的量子攻击
假设某款 App 可以访问 健康状况、位置和照片等 个人敏感数据 并利用加密技术来保护这些数据 例如 当它将数据上传至服务器 进行备份或跨设备同步时 正是通过 TLS 协议来确保数据安全 在这些场景及许多其他工作流程中 加密技术都是 用户数据安全的核心保障
然而 当前的加密技术正面临 量子攻击的严重威胁 这既包括用于保障 数据机密性的加密算法 也涉及确保数据真实性的签名机制 业界专家普遍认为 具备足够算力的 量子计算机即将问世 而且 在量子计算机尚未问世的今天 某些量子攻击手段就已构成切实威胁
例如 攻击者目前可以采用 “先窃密 后解密”的攻击模式 收集加密数据 我们来看看这类攻击的运作方式
回到上一个例子 这款 App 中包含健康状况、位置和 照片等敏感的用户数据 需要将这些数据传输至服务器 它会通过 TLS 协议 对数据进行加密并传输 这时 攻击者可以 截获并存储这些加密数据 虽然当前无法解密 但攻击者只需静候 未来量子计算机技术成熟 便可破解此前囤积的密文 最终获取敏感用户数据
这种“先窃密 后解密”的攻击模式 主要针对攻击者能够截获的加密数据 尤其是传输中的数据 典型场景包括向服务器 发送数据的 App、跨设备同步数据 以及任何通过网络 传输加密数据的系统 这种攻击破坏了数据的机密性 因为攻击者解密后 即可读取网络传输内容 攻击者当下就可能 正在窃取网络通信数据 因此我们必须立即采取措施 防范这类攻击 与被动型的“先窃密 后解密” 攻击不同 下面我将介绍一种主动攻击的例子 在这种场景下 持有量子计算机的攻击者 需要直接介入协议交互过程
假设某个 App 使用 与用户绑定的签名密钥 通过生成签名 向服务器验证用户身份
攻击者截获网络流量中的签名后 利用高性能量子计算机 破解加密算法 窃取签名密钥 随后攻击者使用盗取的密钥伪造签名 发送至服务器 成功冒充用户身份 由于服务器无法辨别真伪 接受了攻击者的签名 攻击者便能以用户身份执行任意操作
这种针对签名机制的主动攻击 会破坏身份真实性 攻击者既可伪造认证凭据 又能以受害者名义执行操作 这种威胁主要影响两类 App 一是执行用户身份验证的 App 例如 WebAuthn 标准和 多因素认证系统 二是进行数据真实性验证的 App 如资产签名类 App 虽然当前尚不存在 能够执行这类攻击的 高性能量子计算机 但相关技术发展已现端倪 这将成为未来的威胁
量子攻击对广泛应用的加密技术 构成切实威胁 为抢占防御先机 密码学界 正全力研发并标准化 抗量子攻击的新算法 即量子安全密码体系 这类算法目前已具备部署条件 不仅能在如今广泛使用的 非量子经典计算机上运行 更能同时抵御经典计算机 与量子计算机的攻击 我将详细展开说明 但请记住 即便加密技术原理复杂 应对方案却很简单
加密技术可分为公钥密码 与对称密钥密码两大类别
量子攻击对二者的影响程度不同 因此需要采用差异化的防御策略 我们先从涉及公钥加密和数字签名的 公钥密码体系开始解析 经典公钥密码技术基于数学难题 比如 RSA 和椭圆曲线离散对数 这些问题对于经典计算机来说 计算强度过大 难以解决
然而 量子计算机却能以指数级速度 破解这些难题 导致现有算法失效 因此 必须用量子安全算法来替代 由于这类算法需耗费大量算力 经典计算机和量子计算机都无法解决
对于量子安全加密 推荐采用后量子混合公钥加密 简称“后量子 HPKE”
而对于量子安全签名 则应选用后量子混合签名方案 这两种均属于后量子混合架构 背后的设计理念是 将新型的后量子算法 与现有经典算法相结合 要破解这种混合架构 须同时攻破后量子算法和经典算法 因此 混合架构 能提供最佳的安全保障 这也正是 Apple 推荐的 量子安全加密方案 对称密钥加密体系包括对称加密 与消息认证码技术 这些算法同样基于经典计算机 难以解决的数学难题 但量子计算机对这些算法的影响 与对经典公钥算法的影响大不相同 量子计算机只能对这些问题的安全性 实现小幅、固定系数的削弱 因此它们仅会弱化 对称密钥加密的强度 于是 经典安全的对称密钥算法 只需将密钥长度加倍 即可抵御量子计算攻击
将原本 128 位密钥的加密算法 升级为 256 位 比如从 AES-128 迁移到 AES-256 回到我之前讨论的量子攻击 迁移至量子安全加密的最优先事项 是防范“先窃密 后解密”攻击 这是因为当前在网络中 传输的加密数据 可能正在被窃取 要抵御这种威胁 必须尽快将传输中数据的加密方案 升级为量子安全加密 尤其是涉及敏感用户数据的协议
事实上 防范这类攻击至关重要 Apple 已在 iMessage 信息中 率先采取防范措施
iMessage 信息为网络传输中的 敏感用户对话提供了数据保护 为抢占量子防御先机 Apple 在 iOS 17.4 中推出了 iMessage PQ3 协议 这标志着大规模量子安全通信技术 已达到行业顶尖水平 这个协议对 iMessage 信息的 加密体系进行了彻底重构 通过量子安全混合加密技术 为会话的初始密钥建立 及持续密钥更新提供保护 请参阅 Apple 安全博客 详细了解 iMessage PQ3 的 设计理念与研发动机 iMessage PQ3 是大规模量子安全 通信领域的一次重大飞跃 但这仅是保护网络数据安全的 冰山一角 绝大多数网络数据 包括所有 HTTPS 流量 仍依赖 TLS 协议进行保护 接下来 我将探讨如何 通过升级至量子安全 TLS 来防御量子攻击
TLS 1.3 已推出 量子安全加密升级方案 专门防范“先窃密 后解密”攻击 这一升级通过量子安全的 密钥交换机制实现 并已获得美国国家标准与技术研究院 和互联网工程任务组的 标准化支持 多家主流服务提供商 均已开始部署 量子安全 TLS 加密技术 你只需简单配置 即可启用这一防护能力
从 iOS 26 开始 对于推荐采用的联网 API Apple 操作系统将默认启用 量子安全 TLS 加密 推荐的 API 包括 URLSession 和 Network.framework 需要注意的是 与传统 TLS 类似 这种保护仅适用于客户端 与 TLS 终止服务器之间的通信
你应当逐步弃用传统联网 API 如 Secure Transport 因为这些接口 将无法支持量子安全 TLS 对于自定网络协议栈 升级过程可能更具挑战性 这正是一个迁移至 URLSession 或基于 Network.framework 重构网络协议栈的绝佳时机
要让量子安全 TLS 加密 在设备与服务器之间生效 服务器端也需同步启用这一功能 大多数开发者使用的是 内容托管或网站托管服务提供商 这些服务商大都 已支持量子安全 TLS 加密 部分已默认开启 其余仅需简单更改配置即可启用 如果是自行部署服务器 则需要额外进行一些配置工作 因为你需要显式升级 TLS 库和相关配置 请参阅这里列出的文档 进一步了解具体操作 为量子安全 TLS 加密做好网络准备
你可能正在使用某些系统服务 这些服务会对设备与 Apple 服务器 之间的通信数据进行加密处理 Apple 正以身作则率先推进 因此在 iOS 26 中 这些系统服务将在客户端启用 量子安全 TLS 加密 并在服务器端逐步推广部署 CloudKit 将 App 的数据 储存在 iCloud 中 并实现跨设备和网页同步
“Apple 推送通知”确保 App 向用户及时推送相关内容
iCloud 专用代理 保护 App 中的 DNS 查询 及未加密的 HTTP 流量 这些系统服务均已开始支持 量子安全 TLS 加密
同时 Safari 浏览器、天气、地图等 需要处理敏感数据的 Apple 内置 App 也正在推进量子安全 TLS 加密技术的落地 现在 你的 App 也应同步升级
对于大多数开发者来说 在 TLS 中使用量子安全加密 足以防御“先窃密 后解密”攻击 但 TLS 并不是 保护传输中数据的唯一方法 如果你采用了自定加密协议 即直接调用加密 API 来保护数据 那么你需要迁移 以改用量子安全加密 API
为此 你首先需要清点 当前加密技术的使用情况 识别协议中涉及 量子计算威胁的加密环节 例如传输中的加密数据和数字签名 随后制定迁移计划 将这些协议升级为量子安全加密方案 借助 CryptoKit 提供的 新型量子安全 API 完成这些升级
CryptoKit 是 Apple 全平台 通用的 Swift 加密框架 提供各类加密算法的 API 接口 在 iOS 26 中 CryptoKit 新增了量子安全 API 这些 API 不仅性能优异、易于使用 而且安全可靠 它们通过强制在安全隔区 执行硬件级隔离运算 有效抵御时序攻击和旁路攻击 此外 这些 API 的核心实现 经过形式化验证 确保功能完全符合标准化规范 从而提供可靠的 正确性保证
下面我以“Climbing”App 为例 演示如何使用 CryptoKit 新的 API 这款 App 使用自定加密协议 来保护传输中的数据
它需要处理用户的健康数据、 地理位置轨迹以及 登山途中拍摄的照片 你想要实施端到端加密 将这些数据 安全地同步到用户的其他设备上 这些信息非常敏感 必须确保服务器和攻击者都无法获取 为此 你创建了一个自定协议 将数据加密后发送至用户的其他设备 并通过服务器中转这些加密数据
在这个场景中 仅具备量子安全 TLS 是不够的 因为 TLS 仅能保护客户端 与 TLS 终端服务器之间的通信 而本例中的用户数据 绝不能向服务器透露
任何像这款“Climbing”App 一样 需要加密传输数据的 App 都必须采用量子安全加密机制 从而防范“先窃密 后解密”攻击
从 iOS 26 开始 CryptoKit 新增了量子安全加密 API 这种 API 基于后量子混合公钥加密 简称“后量子 HPKE” 这正是你的“Climbing”App 迁移升级的理想选择 可有效保护用户敏感数据 免受量子攻击 接下来我将通过示例代码 演示如何使用这个新 API
发送方和接收方 都定义了 X-Wing 的 后量子 HPKE 加密套件 在示例代码演示后 我会详细讲解 X-Wing 的技术细节 在接收端 你需要生成一个 X-Wing 密钥对 如果你的 App 已经在使用 CryptoKit 的传统 HPKE 加密 那么迁移到后量子 HPKE 只需更换加密套件和密钥类型即可 因此 真正涉及量子安全 HPKE API 的部分 只有开头的这几行代码
接收方需要共享自己的公钥
然后使用接收方公钥创建发送方实例
并利用发送方封装的密钥创建接收方
发送方通过数据加密处理来生成密文 这些数据包括 健康指标、地理位置轨迹或 照片等敏感用户数据 以及经过认证的元数据 发送方随后会将密文传输至接收方
接收方需使用相同的认证元数据 来解密密文
现在 用户的登山旅行数据已通过 具备量子安全性的端到端加密机制 从发送设备传输至接收设备
正如我在示例代码中演示的那样 你应该采用后量子 HPKE 来实现量子安全加密 这将通过 X-Wing 密钥封装机制 (KEM) 来建立 HPKE 共享密钥
后量子 HPKE 与 X-Wing 均属于后量子混合架构 这意味着它们融合了 后量子算法与传统算法 从而同时获得双重安全保障
ML-KEM 是 X-Wing KEM 及其他后量子 KEM 的 后量子构建块 尽管 ML-KEM 的加密数据体积开销 大于传统加密方案 但它的性能表现 与传统方案相当甚至更优 CryptoKit 采用的 ML-KEM 实现 经过形式化验证 它的功能等效性 已严格符合 FIPS 203 标准规范 它还支持安全隔区 这意味着你可以为 ML-KEM 运算 强制执行硬件级隔离保护
我们探讨了如何通过 CryptoKit 提供的高层 API 即后量子 HPKE 来实现数据加密 若你需要实现自定加密协议 例如为特定协议规范提供支持 CryptoKit 同样提供 底层量子安全 API
后量子 HPKE 采用 X-Wing 作为密钥封装方案 而 X-Wing 又将 ML-KEM 用作后量子构建块 目前 CryptoKit 支持 所有这些加密 API 同理 在量子安全签名领域 ML-DSA 充当了后量子构建块的角色 CryptoKit 现已同步支持 ML-DSA 签名 API 与 ML-KEM 一样 ML-DSA 实现也支持安全隔区
开发者可直接在应用程序代码层 基于 ML-DSA API 构建后量子混合签名方案
所有 CryptoKit API 均在 客户端设备本地运行 当协议要求客户端与服务器 实现密码学互操作性时 最便捷的解决方案之一 是在服务器端采用 Swift Crypto Swift Crypto 是一个 Swift 库 它为服务器提供了 与 CryptoKit 兼容的 API 接口 可确保无缝的跨端开发体验 它还保障了服务器端兼容性 能够兼容 iOS 26 中 CryptoKit 支持的所有量子安全 API 请注意 由于这些量子安全 API 均基于标准化协议实现 你可以在服务器端 选用任何符合标准的密码学库 借助 CryptoKit 和 Swift Crypto 全新的量子安全 API 你现在有了将 App 迁移至 量子安全加密体系的全套工具 能够有效防范量子攻击 要探索更多使用新 API 的具体示例 请查阅视频资源中的示例代码
现在你已经掌握了保护 App 数据 免受量子攻击的方法 首要任务是确保网络数据 通过 TLS 协议进行量子安全加密 这一步非常简单 尤其是在使用推荐的联网 API 时 这些 API 默认已启用 量子安全加密功能
更新服务器配置 在服务端同步启用量子安全加密
在自定加密协议场景中 使用 CryptoKit 新的量子安全 API 正如“Climbing”App 示例所示 可采用后量子 HPKE 进行数据加密
量子攻击并非遥不可及 它们已是当下切实存在的威胁 我们应当未雨绸缪 全面转向量子安全加密技术 就像登山者常说的那样:直接冲吧
-
-
15:00 - HPKE code sample
let ciphersuite = HPKE.Ciphersuite.XWingMLKEM768X25519_SHA256_AES_GCM_256 // Recipient let privateKey = try XWingMLKEM768X25519.PrivateKey.generate() let publicKey = privateKey.publicKey // Sender var sender = try HPKE.Sender(recipientKey: publicKey, ciphersuite: ciphersuite, info: info) let encapsulatedKey = sender.encapsulatedKey // Recipient var recipient = try HPKE.Recipient(privateKey: privateKey, ciphersuite: ciphersuite, info: info, encapsulatedKey: encapsulatedKey) // Sender encrypts data let ciphertext = try sender.seal(userData, authenticating: metadata) // Recipient decrypts message let decryptedData = try recipient.open(ciphertext, authenticating: metadata) #expect(userData == decryptedData)
-
-
- 0:00 - 简介
量子计算的兴起对当前的加密算法构成了重大威胁,量子攻击很容易破解这些算法,危及存储在应用程序中的敏感用户数据。你需要转向量子安全加密技术,提前规避这一风险。 了解如何使用 TLS 中的量子安全加密来保护网络数据,以及如何使用 CryptoKit 中新的量子安全 API 保护自定协议。
- 1:18 - 量子攻击
加密技术是保护各种工作流程中用户数据的基础,它利用 TLS 来保护安全。但是,这种保护措施正面临量子攻击的威胁。 量子计算机带来了两大威胁:“先窃密,后解密”攻击模式和主动量子攻击。在前者这类攻击中,攻击者可以先拦截加密数据并存储下来,稍后再使用量子计算解密,破坏数据的机密性。这种被动攻击会影响加密数据,尤其是传输中的数据,例如 App 发送到服务器的数据或跨设备同步的数据。 在主动量子攻击中,攻击者使用量子计算机破解加密签名,从而冒充用户并伪造身份验证,只是这种攻击目前尚不可行。这些攻击会对执行用户和数据身份验证的 App 造成威胁。专家们一致认为,足够强大的量子计算机很快就会问世,因此需要立即采取行动来防范这些威胁。
- 4:49 - 量子安全加密技术
量子攻击对当前的加密系统造成了重大风险,因此密码学界开发了量子安全算法,现已可供采用。 量子计算机可以完全破解经典的公钥加密技术,如 RSA 和椭圆曲线离散对数。你需要用后量子混合架构替换这些算法,这种架构结合了新的后量子算法与当前的经典算法。 量子计算机削弱了对称密钥加密体系,包括对称密钥加密和消息认证码。将密钥长度加倍即可使这些算法能够抵御量子攻击。 当前的第一要务,是对传输中的数据改用量子安全加密,以抵御“先窃密,后解密”攻击。Apple 已经迈出了这一步,在 iOS 17.4 中实施了 iMessage PQ3,为 iMessage 信息对话提供了量子安全混合加密。
- 8:56 - 保护网络数据
iMessage PQ3 标志着量子安全通信方面的重大进步,但要对网络数据提供更广泛的保护,则必须要升级到量子安全 TLS。TLS 1.3 使用具有量子安全性的密钥交换机制。主要服务提供商均已采用这一升级,并且从 iOS 26 开始,这一升级将默认启用,用于推荐的网络 API —“URLSession”和“Network.framework”。这些量子安全网络 API 可防范“先窃密,后解密”攻击。 你应当弃用传统网络 API,并在客户端和服务器端启用量子安全 TLS。
- 12:08 - 保护自定协议
若要保护数据免受未来的量子攻击,就要改用量子安全加密。对于自定加密协议,你需要明确当前的使用情况、规划更新,然后使用 CryptoKit 实施这些更改,CryptoKit 是一种 Swift 框架,适用于所有 Apple 平台。 在 iOS 26 中,CryptoKit 提供了一种新的高层量子安全加密 API,这种 API 性能出色且易于使用。这个 API 基于后量子混合公钥加密 (HPKE),并且已经过形式化验证,因此能确保正确性。安全隔区可确保执行硬件级隔离,以增强对时序攻击和旁路攻击的防御。 CryptoKit 还提供底层量子安全 API。对于密钥封装,后量子 HPKE 使用 XWing,它使用 ML-KEM 作为后量子构建块。对于量子安全签名,ML-DSA 是后量子构建块。这两种实施方式都支持安全隔区。 那些要对传输中的数据进行加密的 App,例如会处理健康数据或地理位置数据等敏感用户信息的 App,需要使用后量子 HPKE 来建立具有量子安全性的端到端加密。有些协议要求客户端和服务器之间具有密码学互操作性,而借助 Swift Crypto 可以轻松开发这类功能。Swift Crypto 库为服务器提供了与 CryptoKit 兼容的 API 接口,并确保可以兼容 iOS 26 中 CryptoKit 支持的所有量子安全 API。