[参考译文] CC3135：主机 MCU 和 Wifi 芯片之间的安全 SPI 接口

您好、Olivier、

我认为对于 CC3135器件来说、这不是一个简单的方法。 我认为最好的方法是在用户应用中使用 CC3235、并实施自己的加密。

1月

大家好、Jan、

感谢您的快速回答。

同时、是否有 支持外部接口加密的 TI Wifi 芯片参考？

CC3135和 CC3235硬件/软件是否兼容？

就 CC3235系列而言、CC3235S 和 CC3235SF 有两种选择。

根据数据表、它们都具有256KB 的 SRAM (数据+代码)、但 只有 CC3235SF 具有用于用户应用代码的片上闪存。  

在实施外部 SPI 接口加密时，哪一种最适合我们的需要？

谢谢。

Olivier

您好、Olivier、

器件的选择取决于您的应用需求。 CC3135在 WiFi 芯片和主机 MCU 之间没有加密功能。 但是、如果主处理器在 Linux WiLink 8上运行、器件可能是不错的选择。 由于 WiFi 请求程序在处理器内部的驱动程序上运行、因此您的加密问题不适用。

我认为 CC3235S 和 CC3235SF 都适合您的应用。 但是、如果您将来想使用 TLS 1.3、我会推荐 CC3235SF。 您需要将套接字代码和 WiFi 控制代码从 MCU 移动到 CC3235。 您将针对主 MCU 和 CC3235之间的 SPI 通信加密实施自己的流加密。

有一个问题。 是否需要使用 WPA2-企业安全版(802.1x)？

1月

大家好、Jan、

我们不需要使用  WPA2企业安全性。  我们的主处理器是运行 Azure RTOS 的 ARM cortex-M33内核。

是否有针对 CC3235的 SPI 加密接口或任何相关内容的代码示例？

而且、将现有的 CC3135 芯片移植到 CC3235是否顺利？

谢谢。

Olivier

您好、Olivier、

我不知道此类显示 CC3235 SPI IN 接口加密的示例。 对于通过 SPI 接口进行通信加密、可更好地拟合流加密、但根据您设计用于通信的协议、可使用分组加密、如 AES。 CC3235具有用于 AES 和 DES (3DES)的硬件加速器。 唯一的问题是如何在 MCU 和 CC3235上存储对称密钥。 从安全角度来看、最好在加密之前进行密钥交换、如 Diffie–Hellman。

将 SL_ API 代码从 M33移植到 CC3235不会太重要。 您可能需要：

1. 将您的 sl_ API 代码从 M33移动到 CC3235
2. 为 M33应用程序和 CC3235应用程序之间的数据交换设计您自己的协议。 在我看来、将更好地用于通信 UART、而不是 SPI (线路问题较少)
3. 在您的物理通信(SPI 或 UART)之上设计加密。 可能您不需要加密整个物理通信、而只需要敏感数据。

我假设您使用的是来自 CC3135 (CC3235)的 TCP/IP 堆栈、而不是来自 M33 (例如 NETX Duo)的 TCP/IP 堆栈。

1月

大家好、Jan、

感谢您的回答。

实际上、我们在使用 NETX DUO 的 TCP/IP 堆栈作为我们正在开发的应用程序、以满足其他目的的需要。

我们只能通过 WIFI 驱动程序使用 SimpleLink SDK 的有限部分。

这意味着 TCP/IP 堆栈将保留在 M33 MCU 中、而且加密可能会基于此。

此外、我们希望 SPI 不要降低接口的速度。

此致、

Olivier

您好、Sabeeh：

感谢您的回答。

我看到 CC3301目前还没有投产。 这是否与将于今年年底开始的生产阶段兼容？

另外、我看到同一系列的 CC3300看起来非常相同、但不处理 BLE。 我认为这最适合我们的情况 、因为我们在该芯片上不需要 BLE 支持、但可能是您没有提到 CC3300的原因。

我们目前的 CC3135与 SimpleLink SDK 兼容、如果我们使用的新基准也兼容、将会更容易。 我在 SimpleLink SDK 的兼容性列表中没有看到 CC330X。 是因为它还没有投产还是不兼容?  

最后一点、您能否确认我们当前使用的 CC3135不能具有自定义固件(与  CC3235不同)？

此致、

Olivier

尊敬的 Thomas：

让我们在直接消息中讨论这一点。