作者 / 软件工程师 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 密钥和对应的证书链进行签名。而在以前，非对称密钥由各自对应的算法进行签名。
-
短期证书和认证密钥
- 为设备配置的证书在到期和轮换之前通常拥有最多两个月的有效期。
欢迎您 点击这里 向我们提交反馈，或分享您喜欢的内容、发现的问题。您的反馈对我们非常重要，感谢您的支持！
版权声明
禁止一切形式的转载-禁止商用-禁止衍生 申请授权
