[参考译文] CC3220SF：引导过程、安全引导和加密。

您好 Harish、

Uniflash 将在 CC32xx 上运行一系列命令、以在外部串行闪存上构建和解压缩器件文件系统。 作为此过程的一部分、将编译文件表、并刷写通过 Uniflash 提供的文件、例如应用程序二进制文件、服务包以及其他文件(如 certs)。 标记为安全的文件将由 CC32xx 加密、并计算和签名文件的散列。 每个文件签名都将存储在文件表中、以便 CC32xx 可以根据需要确定文件完整性和真实性。

附加到应用二进制文件的20字节散列是 CC32xxSF 变体所特有的一个特殊步骤、在这里、程序代码从外部闪存复制到内部闪存。 引导加载程序对内部闪存内容进行散列并将其与该20字节散列进行比较、以确保其内容与外部闪存上的带符号二进制文件匹配。

安全启动会在每次启动时检查二进制文件的完整性。 因此、如果外部闪存内容已损坏或故意修改、文件签名将不再与闪存上的内容匹配。 引导加载程序将无法引导器件映像并返回安全警告错误。 如果累积的安全错误过多、器件将锁定自身、从而无法执行蛮力攻击。

通过 Uniflash 传输的每个文件的加密实际上是通过每个文件的唯一 AES 密钥来处理的。 当每个加密文件加载到存储器中时、CC32xx AES 硬件加密模块会动态解密这些文件。 唯一的 AES 密钥由器件在文件创建时生成、并存储在文件表中。 文件表本身也像任何其他加密文件一样进行加密和身份验证、不同之处在于加密密钥源自每个 CC32xx 器件特有的唯一256位硬件机密。 因此、每个文件表将使用每个器件的一组唯一密钥进行加密和身份验证、从而防止您只需将串行闪存的完整内容传输到另一个 CC32xx 进行解密的攻击。

如果您需要更多有关 CC32xx 安全启动实现的说明、或对器件的安全驱动工具有其他疑问、请告诉我。

此致、

Michael

 您好、Michael、  

感谢您的快速响应。 我在提到这些文件后感到困惑。 我请您回答我在下面提到的问题、这样可能会消除我的困惑。  我要求您逐点回答标有绿色的问题  

Uniflash 将在 CC32xx 上运行一系列命令、以在外部串行闪存上构建和解压缩器件文件系统。 作为此过程的一部分、将编译文件表、  并刷写通过 Uniflash 提供的文件、例如应用程序二进制文件、服务包以及其他文件(如 certs)。 标记为安全的文件将由 CC32xx 加密、并计算和签名文件的散列。 每个文件签名都将存储在文件表中、以便 CC32xx 可以根据需要确定文件完整性和真实性。

从上面的陈述中我了解到有一个与每个闪存相关联的文件表、它还包含用于解密的签名和相关密钥。 我的理解是否正确？

首先对文件进行加密、然后计算哈希值、结果哈希值是有符号的？ 我的理解是正确的。

附加到应用二进制文件的20字节散列是 CC32xxSF 变体所特有的一个特殊步骤、在这里、程序代码从外部闪存复制到内部闪存。 引导加载程序对内部闪存内容进行散列并将其与该20字节散列进行比较、以确保其内容与外部闪存上的带符号二进制文件匹配。

好的、我知道在将二进制文件从外部闪存复制到内部闪存以检查完整性时、会使用附加到二进制文件的20个字节。 但在此之前、为了检测外部闪存中的任何变化、使用了 SHA-1哈希、该哈希存储在"/sys/mcuflashimghash.bin "中。 我的理解是否正确？ 请参阅以下文档中的图21-13。

http://www.ti.com/lit/ug/swru465/swru465.pdf

安全启动会在每次启动时检查二进制文件的完整性。 因此、如果外部闪存内容已损坏或故意修改、文件签名将不再与闪存上的内容匹配。 引导加载程序将无法引导器件映像并返回安全警告错误。 如果累积的安全错误过多、器件将锁定自身、从而无法执行蛮力攻击。

从这一点我可以理解、当通过比较 SHA-1哈希检测到外部闪存二进制文件发生变化时、将检查二进制文件的签名。 我的理解是否正确？ 每次启动时都不会验证签名。

签名是在加密之后还是在加密之前计算的？

Uniflash 在刷写签名时验证签名、还是在使用 Uniflash 工具刷写映像时验证引导加载程序。

通过 Uniflash 传输的每个文件的加密 实际上是通过每个文件的唯一 AES 密钥来处理的。 当每个加密文件加载到存储器中时、CC32xx AES 硬件加密模块会动态解密这些文件。 唯一的 AES 密钥由器件在文件创建时生成、并存储在文件表中。 文件表本身也像任何其他加密文件一样进行加密和身份验证、不同之处在于加密密钥源自每个 CC32xx 器件特有的唯一256位硬件机密。 因此、每个文件表将使用每个器件的一组唯一密钥进行加密和身份验证、从而防止您只需将串行闪存的完整内容传输到另一个 CC32xx 进行解密的攻击。

我了解在 Uniflash 的文件属性中何时选择了“安全”选项文件会被加密，以及当我们选择选项“供应商”并提供文件令牌时会发生什么情况？ 。 此文件令牌是加密/解密密钥吗？ 并且在文件表中添加了相同的内容？

 引导加载程序将从文件表中读取解密密钥并对二进制文件进行解密？

OTA

我们正在使用 AWS OTA 代理、下载 OTA 时会发生什么情况？ 是否会在签名验证后替换文件、然后重新启动？  

如果您可以解释 OTA 过程如何执行此安全引导、将会有所帮助  

谢谢、

Harish

您好 Harish、

我的在线回答：

从上面的陈述中我了解到有一个与每个闪存相关联的文件表、它还包含用于解密的签名和相关密钥。 我的理解是否正确？

是的

首先对文件进行加密、然后计算哈希值、结果哈希值是有符号的？ 我的理解是正确的。

该文件经过散列和签名、然后进行加密。

好的、我知道在将二进制文件从外部闪存复制到内部闪存以检查完整性时、会使用附加到二进制文件的20个字节。 但在此之前、为了检测外部闪存中的任何变化、使用了 SHA-1哈希、该哈希存储在"/sys/mcuflashimghash.bin "中。 我的理解是否正确？ 请参阅以下文档中的图21-13。

http://www.ti.com/lit/ug/swru465/swru465.pdf

没错

从这一点我可以理解、当通过比较 SHA-1哈希检测到外部闪存二进制文件发生变化时、将检查二进制文件的签名。 我的理解是否正确？ 每次启动时都不会验证签名。

每次引导时都会检查签名。 引导加载程序将在每次引导时检查内部闪存的内容、以确保其与记录的散列相匹配。 串行闪存上保存的散列本身是加密和签名的、因此每次启动时都会对照此签名检查内部闪存。

签名是在加密之后还是在加密之前计算的？

由于内部闪存的内容未加密、因此在加密之前计算 SHA-1哈希值。

Uniflash 在 刷写签名时验证签名、还是在使用 Uniflash 工具刷写映像时验证引导加载程序。

 引导加载程序执行所有文件加密和签名。 Uniflash 只会发送 UART 引导加载程序命令和文件数据、以便引导加载程序使用。 如果要为文件提供不正确的文件签名、引导加载程序将返回 Uniflash 要显示的文件写入错误。

我了解在 Uniflash 的文件属性中何时选择了“安全”选项 文件会被加密，以及当我们选择选项“供应商”并提供文件令牌时会发生什么情况？ 。 此文件令牌是加密/解密密钥吗？ 并且在文件表中添加了相同的内容？

文件令牌不是文件的加密密钥。 它是一个访问密钥、允许您控制读/写/删除文件访问。 将此设置为"Vendor"可让您提供已知的令牌，以便您的应用程序可以使用 sl_FS*()文件系统 API 访问您的文件。 如果不设置该标志、则只有 NWP 可以访问这些文件。

 引导加载程序将从文件表中读取解密密钥并对二进制文件进行解密？

是的、引导加载程序和 NWP 内核通常能够使用文件系统上作为"安全"存储的所有文件的解密密钥访问文件表。

OTA

我们正在使用 AWS OTA 代理、下载 OTA 时会发生什么情况？ 是否会在签名验证后替换文件、然后重新启动？  

我不熟悉 AWS OTA 方法、但实际上、假设 OTA 正常工作、它将下载 mcuflashimg.bin 文件、使用新下载的副本覆盖旧文件、应该会发生什么情况。 然后、在下一次引导时、引导加载程序将看到 mcuflashimg.bin 已更改、相应地更新散列、并将新的 mcuflashimg 内容下载到内部闪存。 从应用程序代码的角度来看、除了下载和覆盖 mcuflashimg 之外、无需执行任何操作。 引导加载程序将处理其余部分。

此致、

Michael

您好、Michael、

感谢您的回答和快速响应。 非常感谢、我的大部分问题都得到了解答。 我还有其他一些问题、您能回答以下问题。

问题1：

 每次引导时都会检查签名。 引导加载程序将在每次引导时检查内部闪存的内容、以确保其与记录的散列相匹配。 串行闪存上保存的散列本身是加密和签名的、因此每次启动时都会对照此签名检查内部闪存。

从上面的语句中可以看出、您所指的哈希 是在图像从串行闪存传输到片上闪存时自动计算出的 SHa -1哈希。 同样的散列也用于检查串行闪存二进制文件中的任何更改。 从外部串行闪存计算 SHA -1散列时、是否包含20字节散列(附加到二进制文件)？

如果是、那么片上闪存上的映像不包含20字节散列？ 那么哈希·马赫将如何发生呢？

问题2：

 根据我的理解、引导加载 程序将检查串行闪存上是否有新映像、这是使用 SHA-1哈希检测到的、该哈希存储在"/sys/mcuflashimghash.bin "中。串行闪存内容的任何更改都将不匹配。 这表示尝试了新映像或篡改。 如果尝试篡改、片上闪存将被整体擦除。 如果检测到新映像、则会将映像复制到片上闪存

现在的问题是引导加载程序如何区分篡改尝试和新代码、它在复制到片上闪存之前是否验证签名？ 复制到片上闪存后、它将验证20个字节的散列、但在复制之前执行任何检查？ 复制20个字节不匹配后、内部闪存二进制文件已被过度写入。

如果20字节哈希也被篡改以匹配该怎么办？

问题3：

OTA 期间如何传递加密和签名？ 如果我替换使用 Uniflash 刷写的安全二进制文件、然后调用引导加载程序、引导加载程序将如何进行加密并更新文件表？

谢谢、

Harish