手机资讯类网站模板,wordpress 二次元,做一个电子商城网站建设方案,长沙 网站设计 公司乐鑫特权隔离机制 系列文章 #4
目录
安全启动 (Secure boot)
受保护应用程序的安全启动 (Secure boot for protected app )
用户应用程序的安全启动 (Secure boot for user app)
基于证书的验证方案 (Certificate-based verification scheme)
必要条件验证过程…乐鑫特权隔离机制 系列文章 #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。您可点此 乐鑫特权隔离机制 系列文章 查看往期敬请期待后续的更多内容。
