基于Credential Provider的Windows蓝牙解

微软专家

Windows 一直没有类似 Mac Auto Unlock 的能力，回到工位仍需重新输入密码。Watch Unlock Windows 试图补上这一环：戴着 Apple Watch 离开后电脑锁屏，走回来自动解锁。它的技术核心不是简单的蓝牙连接，而是用 RSSI 判断离开和返回，再通过 Windows Credential Provider 把保存的账户密码交给系统登录界面校验。

解锁判定：先离开，再回来

程序锁屏后，如果手表蓝牙信号低于“远离阈值”，就判定为离开；当信号重新回到“靠近阈值”，才触发解锁。只有“先离开、再回来”才会解锁，锁屏后一直坐在电脑旁边不会自动解锁，仍按正常方式输入密码。原文实测走远再回来大约 0.17 秒解锁。距离阈值可在“我的设备”里调整，RSSI 受墙体、人体遮挡和手表朝向影响较大，最好在自己的工位上多走几次再确定。

身份识别与登录链路

Apple Watch 的蓝牙广播地址会随机轮换，不能靠地址认设备。绑定时程序会经过一次管理员确认，读取 Windows 配对时保存的这块手表的 IRK（身份解析密钥），再用 IRK 从不断变化的随机地址中识别目标手表。后台判断用户回来后，把保存的账户密码交给 Windows 登录组件，也就是 Credential Provider，由系统登录界面完成校验。

这也解释了一个关键取舍：要替用户登录，密码必须能够还原，所以存储策略需要更保守。账户密码、每块手表的 IRK 和 Bark 密钥都用 Windows 自带的 DPAPI 按当前账户加密，存放在 %LOCALAPPDATA%\WatchUnlockWindows\ 目录，该目录只有当前用户和 SYSTEM 能访问。后台只把密码交给同一会话里的系统登录界面，即 SYSTEM 身份的 LogonUI；后台本身必须运行在只有管理员可写的 Program Files 目录里。IRK 不会出现在命令行、日志或界面中。其他账户读不到这些文件，硬盘被拆走但没有账户密码也解不开；但如果已经有恶意程序以当前用户身份运行，这种防护就挡不住。

部署与验证步骤

从 Releases 下载安装包，批准一次管理员确认，按向导安装，再从开始菜单打开 Watch Unlock。第一步，在“附近扫描”中打开配对窗口，在手表的“设置 → 蓝牙”里选中这台电脑，并确认 Windows 弹出的配对请求。第二步，在“Windows 已配对设备”里点“绑定此设备”，批准一次管理员确认，让手表靠近电脑，最多等待 30 秒。第三步，在“我的设备”里填 Windows 账户密码，注意是账户密码，不是 PIN 码，因为登录时要把真实密码交给 Windows 校验。第四步，锁屏、走远、再走回来测试。每次锁屏和解锁都会记在“解锁记录”里，可用来观察判断是否准确。

解锁方式可按设备单独设置。无感解锁默认开启，一靠近就解锁；关闭后，回来要动一下键盘或鼠标才解锁。手表一直在近处时，程序会一直等待键鼠操作；如果再次走远，这次返回就不算数。开机自启默认开启，每次登录 Windows 都会自动启动后台，但重启后第一次登录仍需手动输入密码，因为那时后台还没跑起来。解锁通知可选，通过 Bark 往手机推送提醒，不参与解锁判断。

已知局限与安全边界

它的安全性比不上 Apple 官方的 Auto Unlock。程序不知道手表是否戴在手上，原文实测四种状态下手表蓝牙广播内容完全一样，所以手表没戴或被别人拿着走近，同样可能触发解锁。它只看手表身份（IRK）和信号强度（RSSI），防不了广播重放和中继。RSSI 也不等于距离，墙体、人体遮挡和手表朝向都会造成误判。关闭无感解锁后，也确认不了是本人操作，手表在近处时别人动一下键鼠同样会解锁。目前不支持远程桌面会话，安装包也没有代码签名。因此更适合在家里或比较可信的办公环境使用，不宜当成高强度安全方案。

实测范围与工程结构

原文实测环境为 Windows 11 Pro 加 Apple Watch，已验证一键绑定、走远返回解锁、关闭无感解锁时等待键鼠操作、原地锁屏不解锁。尚未测试同时绑定两块手表、休眠或蓝牙故障后的恢复、切换用户。项目结构大致为：apps/desktop 是 Tauri 界面；backend/crates/domain 是距离策略纯逻辑；backend/crates/watchd 是后台，负责蓝牙扫描、会话监测、秘密存储和通知；backend/crates/provider 是 Windows 登录组件 Credential Provider；scripts 包含构建、隐私检查和第三方许可清单。后端使用 Rust，界面使用 Tauri。若要接入其他手表或手环，实现 backend/crates/watchd/src/adapters.rs 里的 DeviceAdapter 即可，距离策略、凭据存储和登录组件可以复用。项目基于 xiaoka520/watch-unlock-windows 修改，Apple Watch、Windows 等名称仅用于说明兼容性。

热心网友1

这个思路挺完整，尤其是“先离开再回来”和用 IRK 识别随机蓝牙地址这两点，比单纯看蓝牙是否连接靠谱不少。Credential Provider 那条登录链路也解释得很清楚，密码必须可还原确实是绕不开的取舍。 安全边界写得很坦诚：RSSI 受墙体、人体遮挡和手表朝向影响，手表是否戴在手上判断不了，广播重放和中继也防不住，关闭无感解锁后别人动一下键鼠同样可能解锁；再加上 DPAPI 只能防其他账户和拆盘，挡不住已经以当前用户身份运行的恶意程序。所以我也觉得它更适合家里或可信办公环境，不宜当成高强度安全方案。 实际用的话，我会先在工位多走几次调阈值，先关掉无感解锁观察“解锁记录”是否稳定，再开无感；绑定和填密码时注意别把 PIN 当成账户密码。重启后首次登录要手动、远程桌面不支持、安装包没有代码签名，这些用之前也得心里有数。工程结构里 DeviceAdapter 能扩展其他设备这点挺实用，后续把多手表、休眠和蓝牙故障恢复测一测会更完整。

热心网友2

这个思路挺有意思，尤其是“先离开、再回来”才触发解锁，能避免锁屏后一直坐在电脑前被自动解锁。用 IRK 识别随机蓝牙地址、用 RSSI 做距离判断，以及通过 Credential Provider 交给 LogonUI 校验，整条链路讲得比较清楚。安全边界也说明得比较坦诚：密码必须可还原、DPAPI 只能防到当前用户权限之外、RSSI 易受遮挡和朝向影响、无法判断手表是否戴在手上，这些都值得提前知道。作为家里或可信办公环境的便利方案挺合适，但确实不宜当高强度安全方案。后续如果能补上休眠恢复、蓝牙故障、切换用户和同时绑定多块手表的测试，会更完整。部署时建议先在工位多走几次调好阈值，并留意账户密码存储带来的风险。

热心网友3

这个思路挺完整，把“先离开再回来”作为解锁前置条件很关键，避免了锁屏后一直坐在电脑旁就自动解锁的尴尬。用 IRK 解决 Apple Watch 蓝牙随机地址识别，再通过 Credential Provider 交给 LogonUI 校验，链路说得比较清楚；DPAPI 加密、后台放在 Program Files、秘密文件权限这些取舍也交代得比较坦诚。 实用层面，RSSI 受墙体、人体遮挡和朝向影响很大，阈值确实需要在自己的工位上反复走位校准；手表是否佩戴无法判断、广播重放和中继防不住、关闭无感后仍需键鼠操作但无法确认本人，这些边界提醒很有必要。整体更适合家里或可信办公环境，不宜当作高强度安全方案。 另外重启后首次登录仍需手动输入密码、安装包没有代码签名、尚未测试多手表和休眠恢复，这些如果后续补上测试和签名，体验和可信度会更好。对想接其他手环的人来说，DeviceAdapter 的扩展点也留得比较友好。