苹果迷苹果迷  2026-09-14 08:58 苹果家园 隐藏边栏 |   抢沙发  0 
文章评分 0 次,平均分 0.0
导语: 苹果在 macOS Tahoe 26.4 中悄悄改了登录钥匙串的存取方式:配 Secure Enclave 的 Mac 上,把 login.keychain-db 复制到另一台机器后,即使密码正确也无法解锁。发布说明只字未提,Time Machine 换机还原同样失效。

苹果在 macOS Tahoe 26.4 里悄悄改掉了登录钥匙串的存取方式:配备 Secure Enclave(安全隔区)的 Mac 上,把登录钥匙串文件复制到另一台 Mac 之后,即使密码完全正确,文件也拒绝解锁。改动没有写进发布说明,也没有在任何 WWDC 场次里出现过,受影响的是所有 Apple 芯片 Mac 以及部分带安全隔区的 Intel 机型。

变了什么:复制文件不再等于搬走密码

登录钥匙串一直是 macOS 里最常被「搬家」的对象。它是一个 SQLite 数据库文件,存放在用户主文件夹下的 ~/Library/Keychains/login.keychain-db,装着该账户保存的网站密码、应用凭据、证书与私钥。在 macOS 26.3 及更早版本里,把这一个文件复制到另一台 Mac、输入同一个账户密码,钥匙串就能直接打开——这套做法在 Mac 管理员和重度用户之间流传了十几年。

macOS 26.4 之后这条路被堵死。文件还是那个文件,密码还是那个密码,但解密的动作被要求必须先经过原机的 Secure Enclave。换一台机器,没有原机的安全隔区,整条解密链就断在第一步。表面上看是「同一份数据」,实际上锁已经换了。

Apple 官方 Keychain Access 钥匙串访问窗口界面截图
图片来源:Apple

机制:两把钥匙,一把被焊在 Secure Enclave 上

登录钥匙串的保护由两把钥匙分工完成:一把管元数据,用来快速检索条目的属性;另一把管真正的密文。Apple 的平台安全指南把这件事写得很直白——元数据密钥由 Secure Enclave 保护,但会缓存在应用处理器中以便快速查询钥匙串;而数据密钥始终需要完成一次经由 Secure Enclave 的往返。

「缓存」这半句是关键。它让日常读取不必每次都惊动安全隔区,所以普通用户完全感觉不到性能变化。但也正因为元数据密钥本身被绑定在那一颗 Secure Enclave 上,把文件搬到另一台机器时,新机器既拿不到这把密钥,也无法完成那次往返,解锁自然失败。反过来,在第二台机器上创建的密钥同样留在本地,也不会随文件走。

值得注意的是,这套双密钥体系并不是 26.4 才有的新东西。苹果文档里一直这么写,Tahoe 只是把「主钥匙串必须绑定安全隔区」这件事执行得更严格。

macOS 登录钥匙串跨机复制在 26.3 与 26.4 起的行为对比图
图表来源:本站根据 Apple 平台安全指南与 Der Flounder(Rich Trouton)技术分析整理制作

谁受影响,谁不受影响

受影响的范围比想象中大:所有 Apple 芯片 Mac,以及带 Secure Enclave 的部分 Intel 机型,覆盖数以千万计的设备。触发的条件是「把登录钥匙串文件复制或拖到另一台 Mac」这一类操作。Time Machine 备份还原到同一台机器不受影响,因为用的还是原机的安全隔区;但把备份还原到一台新 Mac,登录钥匙串同样无法使用。

不受影响的是非登录类钥匙串。用「钥匙串访问」自己新建的自定义钥匙串依旧可以跨机迁移,在 Tahoe 上新建的自定义钥匙串放到旧系统上也能打开。换句话说,苹果只锁了默认的那一个。

实测是怎么发现的:26.3 与 26.4 分界清晰

Der Flounder 的 Rich Trouton 最早把机制写清楚。他把一台 Apple 芯片 Mac 上的钥匙串复制进虚拟机,密码正确,文件依然拒绝解锁。Lapcat Software 的 Jeff Johnson 接着做了版本分界测试,借助 Guilherme Rambo 的 VirtualBuddy 复现:来自 26.3 及更早版本的钥匙串能在 Sequoia 等旧系统上解锁,来自 26.4 的则不能。

Johnson 的用词很重,把这称为「无声的破坏」。他的结论是:你无法、也不可能拥有一份可靠的登录钥匙串备份。他同时质疑苹果完全没有沟通——macOS 26.4 其实是今年 3 月发布的版本,发布说明里对这件事一字未提,直到有管理员在换机时撞上才发现。截至 9 月 11 日,苹果没有就此做出官方回应。

安全上是进步,代价是「可靠的备份」没了

从防护角度看,这次改动是加分的。即便攻击者拿到钥匙串文件,密钥也无法从 Secure Enclave 中导出,被盗的备份或云盘泄露都能被挡住。对合规要求严格、又必须本地自持凭据的团队来说,硬件绑定本身就是卖点。

但便利性的损失很实在。一台 Mac 突然损坏,可能连带丢掉里面所有本地保存的密码;批量换机或灾难恢复时,管理员会在最糟糕的时刻发现迁移脚本失效。也正因为如此,Hacker News 的讨论很快从「为什么会这样」转向「以后怎么办」——有人指向 iCloud 钥匙串作为苹果规划的方向,但很多企业出于合规原因必须关闭 iCloud,只能本地自持。

迁移前可以怎么做

  • 逐项导出:迁移前在「钥匙串访问」里选中条目导出,搬到新机后再导入,绕开整个文件级的绑定。
  • 改用自定义钥匙串:需要随身带的敏感条目放进自定义钥匙串,这类钥匙串不受本次限制。
  • 走 iCloud 钥匙串同步:跨设备同步本来就是它的设计目标,但要先确认合规上允许。
  • 关键凭据移出系统钥匙串:交给专业密码管理器保管,彻底不依赖设备绑定。

对普通用户来说,日常几乎感觉不到差别;真正需要重写习惯的是那批「手动搬用户文件夹」的人,以及负责批量迁移的企业管理员。苹果给了更强的锁,但把提前通知这一步省掉了。

延伸阅读

声明:本文来自投稿,不代表苹果家园立场,版权归原作者所有,欢迎分享本文,转载请保留出处!

发表评论

表情 格式 链接 私密 签到

友情链接

    扫一扫二维码分享