[参考译文] CC2340R5：关于 CC2340R5 BLE 模块的安全固件架构的讨论

您好！

我认为、答案很大程度上取决于您对客户的信任程度。 如果您仍然可以相当信任您的客户、并且您不担心他们被恶意使用、我可以认为拥有单独的制造商和客户代码的一种方式是将两者都编译为库、并拥有一个与库链接的通用应用程序。

我们的想法是、客户和制造商都将处理单独的项目、这些项目将以库作为目标进行构建。 它们将公开的唯一函数是“void customer_entrypoint ()“和“void manufacturer_entrypoint ()“。 然后、双方都知道的源代码的一个常见应用程序会为客户启动一个将此函数用作入口点的线程、以及将另一个线程与另一个入口点一起启动的线程。

这种解决方案的优点如下：
-客户和制造商之间不共享代码源,但普通应用程序除外,它只做最少的创建 2 个线程
-调试符号可以从库中去除,以减少逆向工程的可能性
-客户和制造商螺纹是独立的  
-通过 OAD 进行固件更新仍然可以工作,因为它将作为常规应用程序构建

然而,我看到的缺点如下:
-必须由制造商和客户做一些工作,以商定角色的划分,因为两者都可以访问 BLE 栈和整个闪存。 例如、如果制造商线程和客户线程都尝试开始广播、第一个将起作用、第二个将返回错误。
-由于两个线程都可以访问相同的闪存,客户和制造商需要就非易失性存储的划分达成一致。 例如、客户可能有权访问 0x70000 至 0x75000、而制造商可能有权访问 0x75000 至 0x80000（实际值无关紧要）。 但 CC2340R5 中的任何内容都不会阻止客户读取和访问制造商的 NVS。 因此、敏感信息不能以未加密方式存储在 NVS 中
-两个图像只能使用一个 CCFG

但是、我仍然希望坚持这样的想法：有了此解决方案、即使没有调试符号或您的任何源代码、动机非常强的攻击者/客户仍然可以更改您提供给他们的库的代码、并尝试对其进行逆向工程。 如果您对客户没有信任、甚至不应该看到代码/IP 的编译版本、我看到的唯一解决方案是使用提供的 2 个库构建应用程序的第三方行为者、然后将它们加密为 MCUBoot 加密映像。 那么除了受信任的第三方之外,任何人都看不到编译的代码。 请注意、目前使用 SimpleLink SDK 的 CC2340R5 尚不支持 MCUBoot 加密映像。