wordpress订单推送微信seo全称是什么意思
乐鑫特权隔离机制 系列文章 #4
目录
安全启动 (Secure boot)
受保护应用程序的安全启动 (Secure boot for protected app )
用户应用程序的安全启动 (Secure boot for user app)
基于证书的验证方案 (Certificate-based verification scheme)
- 必要条件
- 验证过程
在上一篇文章中，我们演示了如何在乐鑫特权隔离框架中，独立地更新用户应用程序。简单来说，通过将受保护的应用和用户应用程序相互隔离，即可轻松实现对其中任意程序的独立更新。在这个框架下，为单个受保护的应用程序提供多个用户应用程序也成为可能，类似于应用程序的“应用程序商店”。然而，随着这些应用程序功能的日益丰富，提高其安全性的需求也随之增加。
本文中，我们将介绍“用户应用程序的安全启动机制”，该机制确保只有受信任和授权的用户应用程序，才能在设备上执行。
安全启动 (Secure boot)
安全启动流程可以确保仅有授权和受信任代码才能在设备上执行，常见的实现方法是通过构建“信任链”，即通过从一个受信任且无法更改的实体开始（例如硬件中的一次性可编程存储器），一步步构建完全值得信任的完整信任链。
使用乐鑫特权隔离框架的项目具有两类相互独立的应用程序二进制文件：受保护应用程序 (protected_app) 和用户应用程序 (user_app) ，可以独立完成更新。
乐鑫特权隔离框架可以为这两类应用程序提供安全启动流程，通过基于信任根的信任链，验证受保护应用和用户应用程序文件。
受保护应用程序的安全启动 (Secure boot for protected app )
受保护应用程序的安全启动遵循 ESP-IDF 中传统应用安全启动方案。
传统安全启动过程概述如下：
1. 芯片上电/复位时，ROM 引导加载程序开始执行。注意，这里的 ROM引导加载程序已经烧录在芯片中，无法改变，因此是可信的，将作为信任链的信任根。
2. ROM 引导加载程序在 flash 中查找有效的二级引导加载程序，如果找到，则使用 eFuse 中烧录的公钥哈希值，验证文件附加 RSA-3072 公钥。
3. 公钥验证完成后，继续使用经过验证的公钥验证整个二级引导加载程序文件的数字签名。如果数字签名验证成功，ROM 引导加载程序将二级引导加载程序加载到内存中，并开始执行。
4. 一旦二级引导加载程序开始执行，它就被视为受信任的实体。然后，二级引导加载程序将初始化系统，并尝试以类似的方式使用 eFuse 验证和加载受保护的应用程序。
更多详情，您可以查看 ESP-IDF 编程指南中的安全启动章节。
用户应用程序的安全启动 (Secure boot for user app)
如前所述，受保护应用程序和用户应用程序都可以独立开发，因此这两类应用程序的所有权可以属于不同单位，也就是说它们可能都需要单独的签名密钥。为了验证受保护应用程序，我们会在 eFuse 中烧录受保护应用程序公钥的哈希值，但出于节省 eFuse 内存的目的，并没有同样地烧录用户应用程序公钥的哈希值。
对此，我们特别为用户应用程序的安全启动设计了基于证书的验证机制。
基于证书的验证方案 (Certificate-based verification scheme)
在此方案中，受保护应用程序被视为受信任的应用程序，因此可以在受保护应用程序的固件中烧录一些信息，用于后续验证用户应用程序的真实性。
-
必要条件
采用该方案的受保护应用程序和用户应用程序必须满足一些条件。
受保护应用程序：
1. 受保护应用程序的所有者必须维护两组单独的 RSA-3072 私钥。一组用于对受保护的应用程序的固件进行签名，另一个用于创建 CA 证书。
2. 必须提供某种途径，允许用户应用程序开发人员获取签名证书。
3. 必须在其固件中嵌入 CA 证书。
用户应用程序：
1. 用户应用程序的所有者需要生成 RSA-3072 私钥，用于对用户应用固件进行签名，还用于生成证书签名请求(CSR)。
2. 必须将此 CSR 发送到受保护的应用程序 CA，并获取已签名的用户应用证书 (UAC)。
3. 必须使用 RSA-3072 私钥对固件签名。签名和用户应用证书必须随附在应用程序文件的末尾。
-
验证过程
该方案的验证流程如下：
1. 芯片复位时，ROM 引导加载程序将验证二级引导加载程序，然后验证受保护应用程序的RSA-3072 公钥，具体方式为：对比 eFuse 中烧录的 RSA 公钥哈希值与受保护应用程序文件末尾处附加的公钥哈希值。
2. 公钥验证完成后，继续使用经过验证的公钥验证受保护应用程序的 RSA-PSS 签名。如果验证成功，则可以将受保护的应用程序视为受信任的应用程序并允许启动。
3. 受保护应用程序启动后，会在 flash 中搜索有效的用户应用程序，如果找到，则将使用嵌入在受保护应用程序中的 CA 证书，来验证附加至用户应用程序文件末尾的用户应用证书 (UAC)。UAC 由受保护应用程序的 CA 私钥签名，因此可以通过 CA 证书中的 CA 公钥进行验证。
4. UAC 中包括相应用户应用程序签名密钥的公钥，一旦 UAC 通过受保护应用程序的验证，UAC 内部的公钥也可以被视为受信任。此后，受保护的应用程序使用此公钥，验证用户应用程序的 RSA-PSS 签名。
更多详情，您可以查看乐鑫特权隔离文档中的安全启动章节。
如有任何问题或反馈，欢迎随时在 GitHub 仓库中提交 issue。您可点此 乐鑫特权隔离机制 系列文章 查看往期，敬请期待后续的更多内容。