起因

Crypto Stack 跟 Com Stack 最大的区别，是没有 DBC 这种外部权威数据源。配 CAN Stack 的时候，CanId、DLC、信号位置都能拿 DBC 文件反校验，配错了工具能自动挑出来。Crypto Stack 没有这个输入，Csm → CryIf → CryptoDriver 三层的引用关系全靠工程师手工填、手工对齐。

这次我想拿一个复杂点的场景练手：

• 同一个 ECU 里，RSA-2048 验签（兼容老 Bootloader）
• ECDSA-P256 验签（新安全需求）
• 再加个 Ed25519

三种非对称算法并存。想看看手工配置的复杂度到底有多大，AI 能不能把这个复杂度管住。

对非对称加密不太熟的工程师，光是搞清这几种算法的差别就要花不少时间，更别说怎么配了。

手工配置要配多少东西

先把三层模块的关系说清楚。Csm 是应用层看到的入口，每个 CsmJob 对应一个操作（比如 SignatureVerify），Job 里引用一个 Primitive 配置（算法族、Hash 算法族）和一个 CsmKey。CryIf 是中间的路由层，CryIfChannel 把 Csm 的调用映射到具体的 Crypto Driver Object，CryIfKey 把 CsmKey 的抽象引用映射到 Driver 层真实的 KeyElement。CryptoDriver 是真正干活的一层，KeyElement 的长度、格式，Primitive 支持的算法，都在这一层落地。

三种算法都要走一遍这三层：

算法	Csm 层要配	CryIf 层要配	CryptoDriver 层要配
RSA-2048 验签	JobId、AlgorithmFamily=RSA、AlgorithmFamilySecondary=SHA256、KeyId 引用	ChannelId、KeyRef 映射	KeyElementSize=2048bit、PaddingType=PKCS1v1.5 或 PSS
ECDSA-P256 验签	JobId、AlgorithmFamily=ECC、曲线参数、SHA256	ChannelId、KeyRef 映射	KeyElementSize=256bit、曲线标识
Ed25519 验签	JobId、AlgorithmFamily=EDDSA、Hash 内置 SHA512，不需要单独配	ChannelId、KeyRef 映射	KeyElementSize=256bit、曲线固定为 Edwards25519

三种算法叠起来，三层加起来轻松破百个字段。但真正麻烦的不是字段数量——这些字段之间有隐性约束，各工具的校验只管单个字段合不合法，不管跨模块合不合理。

AutoC 怎么自动配

准备 EB

EB 配置 S32K3 的 Crypto Driver（HSE 支持非对称算法）。

准备 ETAS

选择 ETAS 的 CryIf 和 Csm。

准备 AutoC

• EB 的工程放在 EB 目录下，通过 /settings 改一下配置

• 同时配置 ETAS 的 External modules，这样 EB 的 Crypto 会和 ETAS 的 Crypto 自动关联起来

输入描述

需求：

这个 ECU 的 Bootloader 需要同时支持 RSA-2048-PKCS1v1.5 验签（兼容旧固件签名工具）和 ECDSA-P256-SHA256 验签（新固件签名工具），另外给应用层加一个 Ed25519 验签用于 OTA 包校验。

AI 解析为 3 个 task：

AI 配置过程（耗时约 9 分钟）：

通过 /log 把所有 AI 操作的节点导出来：

检查结果

1. EB

2. ETAS

EB 能生成代码，ETAS 有报错

继续让 AutoC 修：

下载代码后跑不起来、算不对，仍然可以继续让 AutoC 帮你查配置。

最后

AutoC 不是拿通用模型直接生成 ARXML 文本。它把「AI 的判断」和「实际写入配置」拆开：模型只负责决定意图（该配哪个 Job、用哪种算法、Key 和 Channel 怎么引用），参数写入走工具链 API，字段合法性由工具校验兜底。

三种算法并存在同一个 ECU 里，手工对齐 Csm → CryIf → CryptoDriver 的引用关系工作量很大，而且各工具不会帮你检查跨模块约束。Crypto Stack 没有 DBC 那种外部权威数据源——这类场景正好适合用 AI 把隐性约束关系管住。