iMessage 密钥验证

原文 ↗ Hacker News 讨论 ↗

Apple 新推出的 iMessage Contact Key Verification 功能通过让用户相互验证彼此的加密密钥来扩展端到端加密，目标是检测 iMessage 基础设施上的高级中间人攻击。评论者将其与 Signal、WhatsApp、Matrix 和 Telegram 中的类似机制进行比较，讨论究竟有多少人会真正做密钥核验，以及即使只有少量验证，是否也足以对高端攻击者形成威慑。许多争论集中在 Apple 的设计取舍上——将该功能绑定到 iCloud Keychain 和较新的 OS 版本，排除旧设备，并引发关于可用性、隐私以及非技术用户进行密钥验证的可行性等问题。

与 Beeper 的关系和发布时间

  • 几位评论者想知道这是否是对 Beeper Mini 的回应。
  • 另一些人指出，它在 Beeper 最近的 iMessage 活动之前很久就已公布并处于测试阶段。
  • 线程中的共识是：这个功能在概念上与 Beeper 正交，并不是对它的反应。

威胁模型和目标

  • 该功能被视为对“高级威胁”的防护，尤其是针对 iMessage 服务器的 MITM 攻击和密钥替换。
  • 一些人强调它对国家级对手的价值，因为一旦暴露就会烧掉昂贵的 0-day 和工具。
  • 另一些人则认为，如果只有极少数人验证密钥，攻击者可能会接受被发现的风险。
  • 关于加入这类功能是否意味着 Apple 已知存在成功攻击，存在分歧；几位评论者表示，安全加固并不能证明系统已被攻破。

验证 UX 和采用情况

  • 有人将其与 Matrix、Signal 和 WhatsApp 的验证机制进行比较；概念上类似。
  • 也有人担心手动验证（代码、密钥比对）对大多数用户来说摩擦太大，这来自对其他通讯工具的使用经验。
  • Apple 的实时验证使用 8 位数字代码；离线验证使用一长串密钥字符串。有人认为类似 emoji 的方案更易用。
  • 许多人预计未来几年采用率会很低，尤其是在非技术用户中。

实现与安全架构

  • 据称，已验证的密钥数据存放在一个端到端加密的 CloudKit 容器中，只是在 Contacts 中被引用。
  • 据报道，iOS 联系人 API 无法读写该字段；第三方应用不应篡改它。
  • 底层机制使用透明日志，思路上类似 WhatsApp 的密钥透明。
  • 需要 iCloud Keychain；评论者指出它本身也是端到端加密的。

平台要求与 iCloud 绑定

  • 要求所有登录同一 Apple ID 并使用 iMessage 的设备运行较新的 OS 版本；旧设备会阻止激活，除非退出登录。
  • 这让保留旧款 Mac/iPad 或在工作/个人设备之间共享账户的用户感到困扰。
  • 有些人认为把该功能绑定到 iCloud/iCloud Keychain 对于希望严格隔离或不进行云同步的人来说设计不佳，即使消息同步到 iCloud 是可选的。

信任模型与社会/法律影响

  • 讨论中出现了“信任网络”的想法（由联系人为其他人背书），但也有人指出这会造成严重的隐私泄露（例如暴露关系）。
  • 也有人争论，即使是有限的验证（“群体保护”）是否能实质上阻止大规模监视，以及情报机构在现实世界中面临多大的问责。