[参考译文] CC3220S：需要自定义 OTA 库、以便使用附加的 NBIOT 模块进行 OTA

感谢 Kobi 的答复。

现在我可以肯定的是、要重新制作 OTA 库以使用 NBIOT、需要付出一定的努力、我们必须找到另一种方法来实现它。

我们正在考虑对映像进行加密并在器件上下载、然后必须在刷写之前对其进行解密(AES)。   

您能给我提供一些资源吗？这些资源可以帮助我使用文件系统命令来刷写新映像。

我已经查看 了 http://www.ti.com/lit/an/swra509b/swra509b.pdf 和 http://www.ti.com/lit/ug/swru469g/swru469g.pdf 以及技术参考手册、但是  

对器件末尾的解密部分有一点不确定 考虑到我使用 Uniflash 对映像进行加密(在常规设置下使用加密密钥)、是否可以将文件系统命令与加密实用程序结合使用？

如果我错过了一些基本的东西、请原谅我。

此致

Ravija

为什么需要对映像进行加密？ 我想您将使用安全通道(TLS)从服务器获取它。

《CC32XX NWP 编程人员指南》中介绍了 FS 命令。

BR、

Kobi

是 Kobi、

您说得对、我们使用 https 连接获得了命令、因此底层传输是安全的。

您是否建议通过 https 连接进行简单的二进制下载即可满足固件下载案例的要求？

感谢您分享编程人员指南的链接。 我们将使用它来帮助对下载的二进制文件进行编程。

此致

Ravija

你好

我一直在尝试更新/sys/mcuimg.bin 文件。 我有一些关于这方面的问题：

1) 1)我用于打开文件的标志为：

SL_FS_CREATE| SL_FS_OVERWRITE| SL_FS_CREATE_NOSIGNATURE |SL_FS_WRITE_MUST_COMMIT|SL_FS_CREATE_FAILSAFE|SL_FS_CREATE_SECURE | SL_FS_CREATE_COMMEND_WRITE|(SL_FS_CREATE_MAX_SIZE (265800))

Q 1.1是这样、还是我错过了其他东西。

Q 1.2、是否还需要 更新/sys/mcuimg.bin 以及 /sys/servicepack.ucf 文件。 (如果我们始终使用相同的服务包)

Q 1.3我不使用任何令牌、应该使用 SL_FS_TOKEN_MASTER 还是创建供应商令牌(使用 Uniflash？)。 确认相同、但我已经读取了某个位置、如果使用 public_write 打开文件、则在写入期间不需要提供该令牌。  

2)打开文件进行写入后、我尝试将虚拟 bin 文件(从 CCS 编译后生成)复制到使用 FS_open 命令创建的"/sys/mcu_img.bin "文件。

我成功复制了文件内容、但在用关闭文件时  

状态= sl_FsClose (new_wify_ota_file_handle、NULL、0)；

我收到 错误  sl_error_fs_wrong_certificate_file_name、因此我添加了默认证书文件 dummy-root-ca-cert

status = sl_FsClose (new_wify_ota_file_handle、"dummy-root-ca-cert "、NULL、0)；

但随后我开始获取错误  SL_ERROR_FS_ILLEGAL_signature

我已尝试从 ota.cmd 文件的同一工程的 OTA tar 文件中为/sys/mcu_img.bin 添加基本64签名(作为初始尝试)、并得到以下错误：

SL_ERROR_FS_ERROR_signature_or_Certificic_name_length

当然、我尝试将证书文件的名称更改为 dummy-trusted-ca-cert、然后使用 相同的错误将 dummy-trusted-cert

Q 2.1是要从调试文件夹(所创建工程的.bin 文件)中获取的/sys/mcu_img.bin 文件、或者必须从 Uniflash 中导出、如下所示(https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/729334)。 这是正确的文件：

"sp_file_name"："sp_3.13.0.3_2.0.0.0_2.2.0.6.bin"、
"sm_mcu_name"："mcuimg.bin"、

Q 2.2哪个证书文件应用于"/sys/mc_img.bin 文件的 FS_CLOSE 函数。 是 dummy-root-ca-cert 还是 trusted-root-ca-cert

Q 2.3在生产环境中，应如何创建证书文件。  

代码的相关部分如下所示：

const unsigned char g_example_bin_file_Name[]="my_bin.bin"；
const unsigned char g_new_wio_file_Name[]="/sys/mcuimg.bin；
uint8_t signature_base64[]="iwn9fqUt8AjWSwhG5RPMXjIbBl04w05zxOCT0K/OkY6p4G0Ibk4Uo+p4gSUVwwkU1+7dKCub/XlBOZ6UCC0UV8UCCW0Z4 UV1UCCUV0Z4 UVd1无 J4无 J4无 J4无 J4无 J4无 J4无 J4无 J4无 J4无 J4无1无 J4无1无1无1无2无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无2无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无1无2无1无1无1无1无1无1无1无1无1无1无1

 ----------------------

int32_t copy_function ()
｛

/*要读取/写入配置文件的文件句柄*/
slfsFileInfo_t * Example_bin_file_ota_file_info、* new_wify_ota_file_info；
uint8_t data_copy[1024]=｛0｝；
uint16_t len = 1024、偏移= 0；
uint16_t pEndLength = 0；
uint32_t token = 0；
int32_t status = 0、example_bin_file_ota_file_handle = 0、new_wi_ota_file_handle = 0；

// uint32_t FsOpenFlags = sl_FS_CREASE_SECURE；
// FsOpenFlags |= sl_FS_OVERWRITE；
// FsOpenFlags |= SL_FS_CREATE_NOSIGNATURE；
// FsOpenFlags |= sl_FS_CREASE_FAILSAFE；
//
example_bin_file_ota_file_info = malloc (sizeof (slfsFileInfo_t))；
new_wify_ota_file_info = malloc (sizeof (slfsFileInfo_t))；

Example_bin_file_ota_file_info->Len = 0；
new_wify_ota_file_info->Len = 0；

状态= sl_FsGetInfo ((unsigned char*) g_example_bin_file_Name、no_token_used、example_bin_file_ota_file_info)；
// if (status !=0)/*0 =成功*/
//｛
// free (example_bin_file_ota_file_info)；
//免费(new_wify_ota_file_info)；
//返回状态；
//｝
pEndLength =(example_bin_file_ota_file_info->Len)；

状态= sl_FsGetInfo (g_new_wify_file_Name、no_token_used、new_wify_ota_file_info)；
// if (status !=0)/*0 =成功*/
//｛
// free (example_bin_file_ota_file_info)；
//免费(new_wify_ota_file_info)；
//返回状态；
//｝
example_bin_file_ota_file_handle = sl_FsOpen (g_example_bin_file_Name、sl_FS_read、(unsigned long *)&token)；
new_wify_ota_file_handle = sl_FsOpen (g_new_wify_file_Name、sl_fs_create| sl_fs_create_nosigature| sl_fs_create_nose_commit|sl_fs_create_token|sl_fs_create_secure | sl_fs_fs_fs_create_ture| sl_fs_fs_sw_create_en_ten_ds_dome_en_tage_s|s|s_fwrite_s_de|s&s_dome_s&s&sl (sl

// FsOpenFlags |= SL_FS_CREATE_NOSIGNATURE；

while (offset < pEndLength)//@TODO 检查 if =为必需项
｛
status = sl_FsRead (example_bin_file_ota_file_handle、offset、data_copy、len)；

状态= sl_FsWrite (new_wify_ota_file_handle、offset、data_copy、len)；//重复使用全局缓冲区获取值
如果(状态< 0)/*Status 将保留写入的字节数*/

｛
状态= sl_FsClose (example_bin_file_ota_file_handle、NULL、NULL、0)；
状态= sl_FsClose (new_wify_ota_file_handle、NULL、0)；
FREE (example_bin_file_ota_file_info)；
免费(new_wify_ota_file_info)；
UART_PRINT ("复制功能状态%d\r\n"、状态)；
退货状态；
｝
offset+=len；
｝
UART_PRINT ("复制函数：超出 while \r\n 的时间")；

状态= sl_FsClose (example_bin_file_ota_file_handle、NULL、NULL、0)；
status = sl_FsClose (new_wify_ota_file_handle、"dummy-trusted-ca-cert "、(const unsigned char *) signature_base64、sizeof (signature_base64))；

FREE (example_bin_file_ota_file_info)；
免费(new_wify_ota_file_info)；
退货状态；
｝

此致

Ravija

您好 Kobi、

感谢您的快速回复。  

我已经按照您和上面给出的线程(也在该线程内)中所述的步骤执行了操作、但我无法通过-10289错误。

1) 1)我将 timer_led 示例 bin 文件导入到 uniflash 中、并检查该文件是否由 dummy-root-ca-cert-key 签名。

因此、我使用/sys/mcu_img.bin 旁边的下载按钮从 uniflash 导出了该文件(我还尝试通过制作 OTA tar 进行导出)、但该文件与原始二进制文件类似。 (这些是否应该有所不同？)

接下来、我使用 openssl 使用命令"dgst -hex -c -shA1 -keyform der -signed dummy-root-ca-cert-key -out timerled_trusted.hex.sign timerled.bin"生成此文件的签名。

我以适当的十六进制格式将此签名复制到另一个代码中、在该代码中、我尝试将 timerled.bin 作为用户文件导入、然后将其复制到 /sys/mcuimg.bin 中

在这里、我还会得到10289误差

2)第二、我注意到在将任何映像导入到 Uniflash 时、弹出窗口显示 Uniflash 使用"dummy-trusted-cert "、因此我也尝试了上述步骤、这次使用"dummy-trusted-cert 密钥"和"dummy-trusted-certification"在关闭文件时对 timerled.bin 进行签名。

3) 3)我还通过在工具下从 Uniflash 生成密钥来尝试上述两种方法。

我真的被困在这里。 您能不能指导我做什么错了。

此外、从 Uniflash 下载的 MCU 映像(用于 timerled)与项目的调试文件夹中的映像完全相同。 不应该是这样吗？

此致

Ravija

你好

我仍在为此而挣扎。

指针、可能会出错。

此外、再次提出以下问题：

我从 Projects 调试文件夹中获取的 bin 文件、我在作为 mcuimg 浏览后从 Uniflash 下载的 bin 文件、以及我从使用在 Uniflash 上创建 OTA 创建的投影的 tar 文件中获取的文件都是相同的。 根据上述帖子中的主题、情况不应如此。

请尽快提供建议。

此致

Ravija

您好 Kobi、

再次感谢您的回复。

遗憾的是、我仍然无法通过此错误 sl_error_fs_wrong_signature_security_alert (-10289)

是的，您说得对，我在导入映像后生成了 OTA tar 文件(我希望使用自定义 OTA 进行刷写)。 这次我使用了它要求创建安全性的 dumme-ota-vender-certificate。 两个二进制文件仍然完全匹配。 我尝试将项目设置为 DEV 和生产模式。 (某些设备无法正常工作！)

接下来、我从该 tar 中浏览文件  

C：\Users\v\Desktop\OTA tar check\21_04_202020\20200421142119_CC3220S_export_binary\2\csys\mcuimg.bin

 使用"dummy-root-ca-cert-key"生成此文件的 SHA1签名、并在我的代码中使用此签名。

status = sl_FsClose (new_wify_ota_file_handle、"dummy-root-ca-cert "、signature、256)；

我还重新验证了用于访问此 SYS/mcuimg.bin 以进行写入的标志是否正确(根据从 OTA 库和技术参考手册中扣除的内容)

new_wif_ota_file_handle = sl_FsOpen (g_new_wify_file_Name、sl_fs_create| sl_fs_overwrite| sl_fs_write_mUST_commit|sl_fs_create_failure|sl_fs_create_secure | sl_fs_create_public_write|(sl_fs_create_max_max_token)(s&256)、长度为1024)*(256)

自定义 OTA 工程的 Uniflash 文件

我已经尝试使用从 Uniflash 生成的签名->工具部分以及 OTA 文件夹文件、但仍然不幸运[此签名不同于使用 openssl 的通用签名]

这种情况变得非常令人担忧。 您能指出我是否仍犯了任何错误？

此致、

Ravija

P.S. 生成的 bin 文件和 Signature

e2e.ti.com/.../Bin_5F00_file_5F00_and_5F00_OTA_5F00_bin_5F00_file.zip

为 OTA 文件夹中的文件打开 SSL 签名(SHA 1)(使用 dummy-root-ca-cert-key 文件)[格式化]

0xa7、0x16、0xa8、0x86、0x4d、0x73、0xec、0x3f、0x32、0xc9、0xbb、0x54、0xb、0x15、0xfc、0x75、0x2e、0x9、0x7、0xbb、0x7、0xbb、0x7、0xb、0xb、0x54、0xb、0x4、0xb、0xb、0x4、0x4、0xb、0xb、0x4、0x4、0xb、0x4、0xb、0xb、0x4、0xb、0xb、0x4、0xb、0x4、0xb、0xb、0x4、0xb、0x4、0xb、0xb、0x4、0xb、0x4、0xb、0x4、0xb、0x4、0xb、0x4、0xb、0xb、0x4、0xb、0x4、0xb、0xb、0xb、0x4、0xb、0x4、0x4、0xb、0xb、0xb、0x4、0xb、0x4、0x4、0xb

您好 Kobi、

我急切地等待你就此作出答复。

请查看上一帖子中的程序和标志。

再次感谢你们的帮助和自发的回答：)

此致

Ravija

尊敬的 Ravija：

同样 、看起来您正在做一些不需要的额外工作、并会破坏签名检查。

如果使用 Uniflash 创建 OTA 映像并使用 OtaArchive 进行验证、则无需编写任何特定代码即可处理 MCU 映像。

此外、了解用于对 MCU 映像进行签名的密钥与用于对整个 OTA tar 进行签名的密钥之间的区别非常重要。

对于 MCU 映像(确保使用"Select MCU Image"导入 MCU 映像)-在开发模式下、您将需要其中一个 Playground 虚拟密钥、例如文件系统中存储的带有 dummy-root-ca-cert 的 dummy-root-cccccert 密钥 (密钥和证书都需要设置为 MCU 映像属性屏幕的一部分)  

对于 OTA 映像-用于对整个 OTA 映像进行签名的特殊 ECC 密钥(出于测试目的、请使用"dummy_ota_vendor_key.der"、其中要求"dummy_ota_vendor_cert.der" 将位于文件系统中)。

当您使用 OtaArchive 代码时、两个证书都将自动使用。 首先、"dummy_ota_vendor_key.der"将用于验证 ota.cmd 签名。 然后、对于"ota.cmd"中定义的每个安全文件、关闭文件时将进行签名验证(MCU 映像是这些安全文件之一)。

请启用 OtaArchive 日志消息并提供它、以便我可以帮助调试确切的问题。

BR、

Kobi

您好 Kobi、

感谢您澄清证书相关信息。 它现在使它更加清晰。

根据我最初的问题、如果网络连接不良、我将使用 NBIOT 模块执行固件 OTA。 因此、我们尝试仅对 mcuimg.bin 进行 OTA、这可以通过安全网络使用来自 NBIOT 模块的 HttpGet 命令轻松完成。

这就是我们不使用 OTA 存档功能的原因、我们已根据您提供的信息和 https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/729334等相关线程切换到使用文件 OTA (使用我们的自定义固件)

无论我尝试什么、在导出 frpm Uniflash 后、似乎都不会向映像的二进制文件中添加签名/头文件

添加 OTA 存档功能是我们目前正在研究的一个选项、但我们仍停留在"mcuimg"文件 OTA 中。

即使是 OTA tar 映像也与原始二进制文件完全相同、这也让人怀疑文件 OTA 在此模块中不受支持、或者必须是从 Uniflash 获取标头附加二进制文件的另一种方法。

请清除此项吗？

此致

Ravija  

我不明白。 您是否仍在使用 Uniflash 创建 TAR 文件？

无论您在做什么、都需要提供原始 MCU 映像的签名(而不是将其附加到 摘要中)。

您好 Kobi、

我正在使用 Uniflash 创建 TAR 文件、并且正在进行捆绑 OTA。

我使用 Wifi 或 NBIOT 下载捆绑包、然后按照建议使用 Ot归 档库取消归档。

为此、我将使用 dumme-ota-vender-certificate 在创建时对 tar 进行签名、并已加载教程中给出的所有证书。 签名验证由 Ot归 档库本身处理。  

我之前也在使用 OTA 库、当我发布原始问题时、我不确定如何编辑 OTA 库、以便在出现网络问题时使用 NBIOT 而不是 WiFi 下载 WiFi tar 文件。 当我卡在文件 OTA 中时、我返回到库、进行了一些更改、并最终能够使用库本身进行 OTA

此致

Ravija  

那么、您是否发现了问题？

"并且正在进行捆绑 OTA 本身"是什么意思？ 由 uniflash 创建的 TAR 应处理该捆绑包。

如果您仍然遇到问题、请启用 OtaArchive 日志、以便我可以帮助进行调试。

BR、

Kobi