[参考译文] TMS320F28P650DH：F28P65 CMAC 符合 RFC4493 标准吗？

不、我们讨论的是 RFC4493、 请参阅本文“RFC4493 - AES-CMAC 算法“、我们会测试示例“c：/ti/c2000/C2000Ware_6_00_00_00/driverlib/f28p65x/examples/c28x/aes/aes_ex7_cmac_auth.c “、TI 的 CMAC 引擎的结果与 mbedtls 和 openssl 不同、而这两个库确实完全符合  RFC4493。

我查看了这篇文章“RFC4492：用于传输层安全 (TLS) 的椭圆曲线加密 (ECC) 密码套件“、发现 RFC4492 与 CMAC 无关。

尊敬的 Xuliang：

我们将再次验证这一点、然后返回给您、

是的、您添加了一些额外的函数来生成子密钥、因此结果与 RFC4493 规范兼容。 但是、我要测试安全启动的 CMAC 结果、它不等于 mbedtls 和 openssl 的结果、因为 F28P65x 技术参考手册指出“ CMAC 计算需要用户定义的 128 位
在 CPU 用户 OTP 区域 1 标头 OTP CMACKEY 位字段中编程的密钥。 此外、用户必须这样做
根据 16KB 闪存存储器范围计算黄金 CMAC 标签、并将标签与一起存储
闪存中硬编码地址处的用户代码。 “我使用 openssl 计算 16KB 的可执行二进制文件、结果与 CCS 十六进制实用程序计算结果不同。
CMAC 密钥为：
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

示例为“boot_ex1_cpu1_secure_flash_cpu1.c"</s>“

请阐明、安全启动 CMAC 是否具有生成子密钥的能力。 否则、很难满足安全启动要求。

尊敬的 Ira：

感谢您的答复！ 您能帮我们看看安全启动 (ROM) 是否也有相同的问题吗？

此致、

挂起

您好、Hang、请允许我们在内部进行检查、然后返回给您。

请告知我们进度、10 天过去了。

这话什么意思？ 如果是、安全启动是否正确？

我可以确认 ROM 包含用于生成子密钥并使用子密钥计算 CMAC 的代码。

非常感谢、谢谢。

我们如何修复此错误？ 由于安全启动在当今至关重要、因此如果安全启动不符合标准 (RFC4493)、我们如何说服终端客户我们的产品满足要求、例如 IECC62443。

您好、安全启动中不存在此错误、我们已在内部进行了验证。  

您能告诉我您尝试执行了哪些步骤来实现安全启动吗

您好：Nilabh、

我认为 Xuliang 的 问题不是 与运行安全启动有关、而是无法让终端客户相信安全启动符合 IEC62443。

是否可以检查 IEC62442 是否需要安全启动、且符合 RFC4493 的规定？ 或者任何安全启动可以正常工作？

此致、

挂起。

您好：Nilabh、

感谢您提供的信息、这有助于我们解决问题！

同时、 Ira Thete 是否可以在下一个产品中添加对 ROM 的更改？

问题在于、客户会假设我们遵循 RFC 4493（如我们所说的“cmac"）“）、并将尝试使用 3-P CMAC 工具生成签名、但发现它不起作用。

现在、他们只能使用 TI 工具来完成这项工作。

此致、

挂起

与此同时、 Ira Thete 是否可以在下一个产品中将更改添加到 ROM？

挂起、

这已存在于 ROM 代码中。

它仅在应用程序代码中丢失。

我测试 CCS Hex 实用程序、它计算出 CMAC 结果、但结果与 OpenSSL 或 mbedtls 结果不兼容、此外、CCS 结果与中的方法不兼容  C2000Ware_6_00_00_00/driverlib/f28p65x/examples/c28x/AES/AES_EX7_cmac_auth.c

需要指出的是、如果 F28P65x 器件的安全启动符合标准或最佳实践（ECDSA 或 CMAC RFC 4493 等） 、则会更方便和更有说服力。
同时、正如文档所说、身份验证算法是 CMAC、因此它应该与其定义兼容。

正如您提到的“ ROM 代码中已经存在这种文件“、您能提供一个说明文件来告诉我们如何使用示例 “boot_ex1_cpu1_secure_flash_cpu1.c"吗“吗？目前、有关这方面的文档很少见、这非常令人困惑。

尊敬的 Xuliang：

该团队提到 ROM 代码中的实现是正确的。 您能否确认是否考虑了 C2000 架构的小字节序。 请注意、OpenSSL 期望的默认格式为大端字节序。 如果您能获得相同的 CMAC 标签计算、请告诉我们。

此致、

Ozino

请提供一个具有互操作性的示例、这意味着一个 CCS 示例和一个 OpenSSL 命令来生成相同的标签。

我考虑字节序、并使用以下命令：

echo “生成大端字节序二进制文件：“
$｛CG_TOOL_HEX｝-q -b -image -map PRIMARY_BOOT_SUMMARY_BE.map -o primary_boot_be.bin --订单 LS $｛PROJECT_LOC｝/primary_boot_roms_directive_file.txt $｛BuildArtifactFileBaseName｝.out
echo “生成小端字节序二进制文件：“
$｛CG_TOOL_HEX｝-q -b -image -map PRIMARY_BOOT_SUMMARY_LE.MAP -o primary_boot_le.bin --ORDER MS $｛PROJECT_LOC｝/primary_boot_roms_directive_file.txt $｛BuildArtifactFileBaseName｝.out
OpenSSL enc -AES-128-CBC -in primary_boot_be.bin -out primary_boot_be_enc.bin -K FFFFFFFFFFFFFFFFFFFFFFFFFFFF -iv 00000000000000000000000000000000
OpenSSL enc -AES-128-CBC -in primary_boot_le.bin -out primary_boot_le_enc.bin -K FFFFFFFFFFFFFFFFFFFFFFFFFFFF -iv 00000000000000000000000000000000
echo “生成大端字节序加密二进制文件：“
xxd -s –16 -l 16 -p -u primary_boot_be_enc.bin
echo “生成小端字节序加密二进制文件：“
xxd -s –16 -l 16 -p -u primary_boot_le_enc.bin
回波“大端字节序输入、tag：“
OpenSSL Mac — 密码 AES-128-CBC -macopt hexkey：FFFFFFFFFFFFFFFFFFFFFFFFFFFF - IN primary_boot_be.bin CMAC
回波“小端字节序输入、tag：“
OpenSSL Mac — 密码 AES-128-CBC -macopt hexkey：FFFFFFFFFFFFFFFFFFFFFFFFFFFF - IN primary_boot_le.bin CMAC


但是、以上结果都与 CCS 十六进制实用程序结果不兼容。

尊敬的 TI 专家：

我已经在 F28P65 上对 CMAC 实现方案进行了广泛的测试、但无法使用 OpenSSL 重现 TI 生成的 CMAC 标签（符合 RFC4493 标准）。 我已经超越了字节序等基本检查。

Core Logic Analysis
对于典型的安全启动场景：
受保护区域：`0x80000~0x823FF`
- CMAC 存储在:`0x823F4` 0x823FF~（16 字节 TAG + 8 字节填充）
-生成时：CMAC 区域包含零

我已验证的内容 ：
-方法 A（将 CMAC 区域视为零）→**与 TI**不匹配
-方法 C（不包括 CMAC 面积）→**与 TI**不匹配
-两个测试用小/大端字节序→仍然没有匹配

由于这两种逻辑一致的方法都失败了、因此 TI 工具链必须使用**与我从最终二进制文件中提取的内容不同的输入数据汇编**。

我的请求 ：
您能否清楚地说明：
1.安全启动 ROM/hex2000 工具使用哪种逻辑模型 (A、B 或 C)？

一个简单的 CCS 示例可以使用 OpenSSL 单行版本进行验证、这是最好的证明。

尊敬的 NIlabh&Ira：

您能帮助回答吗？

是否有任何更新？

您好 Hang、

数据是否进行了 128 位对齐？

ROM 需要对齐的映像来计算 CMAC。

谢谢

Ronak

尊敬的 Ronak：

我认为、我们遇到的问题是关于生成方法、尤其是关于 CMAC 面积的填充方式。

客户的 请求 ：

您能否清楚地说明：
1.安全启动 ROM/hex2000 工具使用哪种逻辑模型 (A、B 或 C)？

2.可使用 OpenSSL One-liner（或任何其他 3P 工具）验证的简单 CCS 示例是最好的证明。

当然、我们知道这一点。

您好：

我们正在内部验证它、但参考 TRM：

此致、
马特