作者 / 软件工程师 Max Bires
自 Android 8.0 以来,认证成为一项必备功能。随着各个版本的更迭,认证越来越成为各种功能和服务的信任核心,例如 SafetyNet、身份凭据 (Identity Credential)、数字车钥匙 (Digital Car Key) 以及各种第三方库。因此,现在我们需要重新审视认证基础架构,加强信任链的安全性,并在出现已知漏洞时提高设备信任的可恢复性。
自 Android 12.0 起,我们将提供一个选项,可将工厂内私钥配置替换为工厂内公钥提取加上带短期证书的 OTA (over-the-air) 证书配置。此方案将在 Android 13.0 中强制实施。我们将其称为远程密钥配置 (Remote Key Provisioning)。
哪些群体会受到此方法的影响?
原始设备制造商 (OEM) / 原始设计制造商 (ODM)
设备制造商将不再直接向工厂中的设备提供认证私钥,从而解除了必须在工厂中管理认证密钥的负担。
潜在的依赖方
我们将在下文中进一步说明认证中证书链的格式、算法和长度将发生的变化。如果依赖方在设置其证书验证代码时,要求该代码必须与旧证书链结构有极高的匹配度,则需要更新此代码。
为什么要改变?
我们改变向设备提供认证证书的方式有两大动机因素: 允许设备在受到攻击后恢复,以及收紧认证供应链。在如今的认证方案中,如果发现某个设备型号受到的攻击会对认证的信任信号产生影响,或者如果密钥经某种机制泄露,则必须撤消该密钥。由于依赖认证密钥信号的服务越来越多,这一举措可能会对设备受到影响的消费者产生巨大的冲击。
如果设备已经在运行被攻破的软件,这项措施可以使我们停止对该设备进行密钥配置,并消除密钥意外泄露的可能性。这将大大减少用户服务中断的可能性。
如何运作?
每台设备都会生成一个唯一的静态密钥对,该密钥对的公共部分由 OEM 在其工厂中提取。随后,这些公钥将被上传到 Google 服务器,用作之后产生的配置的信任基础。私钥则永远不会离开生成它的安全环境。
当设备启用并连接到互联网时,它会为其已生成的密钥生成证书签名请求,并使用与工厂内收集的公钥对应的私钥对其进行签名。后端服务器将验证请求的真实性,然后签署公钥,返回证书链。然后,密钥库会存储这些证书链,并在请求认证时随时分配给应用。
此流程将在证书到期或当前密钥供应用尽时定期执行。该方案支持隐私保护,每个应用将接收到不同的认证密钥,并且密钥本身会定期轮换。此外,Google 后端服务器也进行了分段处理,因此验证设备公钥的服务器看不到附加的认证密钥。这意味着 Google 无法将认证密钥关联回请求它们的特定设备。
从技术角度来看,发生了哪些变化?
终端用户不会注意到任何变化。使用认证的开发者则需要注意以下变化:
-
证书链结构
- 鉴于新版在线配置基础架构的性质,链长度比以前更长,并且可能会发生变化。
-
信任根
- 信任根最终将从目前的 RSA 密钥更新为 ECDSA 密钥。
-
弃用 RSA 认证
- KeyMint 生成和认证的所有密钥都将使用 ECDSA 密钥和对应的证书链进行签名。而在以前,非对称密钥由各自对应的算法进行签名。
-
短期证书和认证密钥
- 为设备配置的证书在到期和轮换之前通常拥有最多两个月的有效期。
欢迎您 点击这里 向我们提交反馈,或分享您喜欢的内容、发现的问题。您的反馈对我们非常重要,感谢您的支持!
版权声明
禁止一切形式的转载-禁止商用-禁止衍生 申请授权