Why we tried this

The biggest difference between the Crypto Stack and the Com Stack is the lack of an external source of truth like a DBC. When configuring CAN Stack, CanId, DLC, and signal positions can be cross-checked against the DBC; tools catch mismatches automatically. Crypto Stack has no such input — the Csm → CryIf → CryptoDriver reference chain is filled in and aligned entirely by hand.

For this test I picked a harder scenario:

• RSA-2048 verification on the same ECU (legacy Bootloader compatibility)
• ECDSA-P256 verification (new security requirement)
• Ed25519 on top

Three asymmetric algorithms on one ECU. I wanted to see how painful manual configuration really is, and whether AI can keep that complexity under control.

For engineers who are not deeply familiar with asymmetric cryptography, just understanding the differences takes time — let alone configuring them.

How much manual configuration takes

First, the three-layer relationship. Csm is the application-facing entry: each CsmJob maps to one operation (e.g. SignatureVerify). A Job references a Primitive configuration (algorithm family, hash algorithm family) and a CsmKey. CryIf is the routing layer in the middle: CryIfChannel maps Csm calls to a concrete Crypto Driver Object; CryIfKey maps the abstract CsmKey reference to the real KeyElement in the driver. CryptoDriver does the actual work — KeyElement size and format, and which algorithms each Primitive supports, are all defined here.

Each of the three algorithms must be wired through all three layers:

Algorithm	Csm layer	CryIf layer	CryptoDriver layer
RSA-2048 verify	JobId, AlgorithmFamily=RSA, AlgorithmFamilySecondary=SHA256, KeyId ref	ChannelId, KeyRef mapping	KeyElementSize=2048bit, PaddingType=PKCS1v1.5 or PSS
ECDSA-P256 verify	JobId, AlgorithmFamily=ECC, curve params, SHA256	ChannelId, KeyRef mapping	KeyElementSize=256bit, curve id
Ed25519 verify	JobId, AlgorithmFamily=EDDSA, built-in SHA512 (no separate hash config)	ChannelId, KeyRef mapping	KeyElementSize=256bit, curve fixed to Edwards25519

Stack all three algorithms and you easily exceed a hundred fields across the three layers. The real pain is not the field count — these fields have implicit cross-module constraints; toolchain validation only checks whether individual fields are legal, not whether cross-module references make sense.

How AutoC configures it

Prepare EB

Configure the S32K3 Crypto Driver in EB (HSE supports asymmetric algorithms).

Prepare ETAS

Select ETAS CryIf and Csm.

Prepare AutoC

• Put the EB project under the EB directory and adjust settings via /settings

• Also configure ETAS External modules so EB Crypto and ETAS Crypto are linked automatically

Input description

Requirement:

This ECU's Bootloader must support RSA-2048-PKCS1v1.5 verification (legacy firmware signing tool) and ECDSA-P256-SHA256 verification (new firmware signing tool). Add Ed25519 verification for the application layer to validate OTA packages.

AI parsed this into 3 tasks:

AI configuration run (about 9 minutes):

Use /log to export every node AutoC touched:

Check results

1. EB

2. ETAS

EB generates code; ETAS reports errors

Keep letting AutoC fix it:

After downloading generated code, if it does not run or verification fails, you can still ask AutoC to review the configuration.

Wrapping up

AutoC does not use a general-purpose model to emit ARXML text directly. It separates "AI judgment" from "writing configuration": the model only decides intent (which Job, which algorithm, how Keys and Channels reference each other); actual parameter writes go through toolchain APIs, with field validity enforced by the tools.

Three algorithms on one ECU means a lot of manual work to align Csm → CryIf → CryptoDriver references, and the toolchains will not check cross-module constraints for you. Crypto Stack has no DBC-style external authority — which is exactly the kind of scenario where AI can keep those implicit relationships under control.