WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Get ahead with quantum-secure cryptography

Get ahead with quantum-secure cryptography

系统服务隐私与安全
观看原视频

Highlight

量子计算机会让 RSA 与椭圆曲线公钥算法在指数时间内被破解，攻击者已经在做「先收集后解密」，iOS 26 在 URLSession 与 Network.framework 默认启用 TLS 量子安全密钥交换，CryptoKit 同时上线 Post-quantum HPKE、X-Wing、ML-KEM 与 ML-DSA。

核心内容

威胁不是科幻。攻击者今天就能截下一段加密流量存到硬盘里，等量子计算机问世再回头解密。这种「Harvest Now, Decrypt Later」攻击对所有跨网络传输的健康、定位、照片这类敏感数据有效，破坏的是机密性。另外一类是签名伪造：拿到量子算力后，攻击者可以从公开签名反推私钥，伪装成用户向服务器发起操作，这影响 WebAuthn、多因素登录、资产签名这类身份认证场景（03:18）。

Apple 的对策分两层。对称加密只受到常数级削弱，把 AES-128 升到 AES-256 就够了。公钥加密必须换算法：推荐使用「后量子混合」（post-quantum hybrid）构造——把后量子算法和经典算法叠在一起，攻击者必须同时打破两者才能成功（06:32）。落地路径上，iMessage 在 iOS 17.4 已切到 PQ3 协议；iOS 26 把量子安全 TLS 默认打开，CloudKit、APNs、iCloud Private Relay、Safari、Weather、Maps 都在跟进；CryptoKit 新增 Post-quantum HPKE、X-Wing、ML-KEM、ML-DSA 四套 API，由 Secure Enclave 兜底并经过形式化验证。

详细内容

session 的 demo 项目是一款攀岩 App，会把用户的健康数据、轨迹、照片端到端加密同步到自己的其他设备。TLS 不够用——TLS 只保护客户端到 TLS 终结点（也就是中转服务器）之间的链路，而这里要对服务器本身保密（14:14）。所以走的是自定义协议 + Post-quantum HPKE。

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)

关键点：

  • HPKE.Ciphersuite.XWingMLKEM768X25519_SHA256_AES_GCM_256：选用 X-Wing 混合 KEM（ML-KEM-768 + X25519），HKDF-SHA-256 派生密钥，AES-GCM-256 做对称加密；这是 iOS 26 给 HPKE 新增的后量子套件。
  • XWingMLKEM768X25519.PrivateKey.generate() 与 .publicKey：在接收方生成 X-Wing 密钥对，公钥发给发送方。从经典 HPKE 迁移过来，差别只有 ciphersuite 和 key type 这几行（15:16）。
  • HPKE.Sender(recipientKey:ciphersuite:info:)：发送方用收方公钥构造 sender，encapsulatedKey 是要随密文一起传给对端的封装密钥。
  • HPKE.Recipient(privateKey:ciphersuite:info:encapsulatedKey:)：接收方用自己的私钥和发送方传来的 encapsulatedKey 还原会话密钥。
  • sender.seal(_:authenticating:)：对用户数据加密，并把 metadata 作为 AAD 绑定到密文里防篡改。
  • recipient.open(_:authenticating:)：用同样的 metadata 校验并解密，得到原始数据。

更底层的能力同样开放：X-Wing KEM 单独可用，ML-KEM-768 作为后量子原语暴露，签名一侧提供 ML-DSA，可在应用层组装成 post-quantum 混合签名（17:53）。ML-KEM 与 ML-DSA 都支持 Secure Enclave，密钥操作可强制在硬件隔离环境中执行，核心实现对照 FIPS 203 做了形式化验证。服务端可用 Swift Crypto 拿到与 CryptoKit 一致的 API，或者换任何支持标准后量子算法的库（18:26）。

iOS 26 默认开启的范围限定在 URLSession 与 Network.framework；老的 Secure Transport 不会获得后量子升级，需要尽快迁离。自建服务器要自己升级 TLS 库和配置；用 CDN/托管商的，多数已经支持，开个开关即可（10:53）。

核心启发

  1. 盘点协议里的「数据在传输」环节：把 App 中所有走加密传输或签名的位置列出来，标记是 TLS 还是自定义 HPKE/签名。能交给 URLSession 的优先交出去，iOS 26 升级到 TLS 量子安全密钥交换是零成本收益。
  2. 把经典 HPKE 替换为 Post-quantum HPKE：如果已经用 CryptoKit 的 HPKE 做端到端加密（比如 IM、设备间同步、备份解密），改造点只有 ciphersuite 与 key type 两处。先在测试环境跑通 X-Wing 套件，再灰度服务端密钥分发。
  3. 签名链路评估 ML-DSA 落地：用户登录、设备凭证、资产签名这类长生命周期签名，未来一旦量子算力可用就会被回溯破解。趁早把私钥下沉到 Secure Enclave，并准备一条 post-quantum 混合签名（经典 + ML-DSA）的迁移路径。
  4. 服务端走 Swift Crypto 或标准库：iOS 26 的 CryptoKit 与 Swift Crypto API 完全对齐，Swift 后端可以直接共享代码；其他语言找符合 FIPS 203（ML-KEM）/ FIPS 204（ML-DSA）标准的实现即可，避免自实现。
  5. 告别 Secure Transport 与自有网络栈：Apple 已明确老 API 不会获得后量子升级。把残留的 Secure Transport 调用换成 URLSession，或把自有栈搭在 Network.framework 上，作为这次安全升级的副产品一并收尾。

关联 Session

评论

GitHub Issues · utterances