aliro-project/docs/vendor-bugs/2026-06-12-st-xcube-aliro-processAUTH1ResponsePayload.md

ST X-CUBE-ALIRO: ACWG_processAUTH1ResponsePayload errors against spec-compliant card

Status: open Reporter: Dangerous Things (ops@dangerousthings.com) Date filed: 2026-06-12 Severity: blocking — prevents Aliro Expedited phase from completing against any third-party Java Card applet

Summary

ACWG_processAUTH1ResponsePayload (shipped precompiled in Aliro.a / ACWG_Security.a) returns ACWG_Error_Crypto_EncryptDecrypt on every iteration when processing AUTH1 responses from our open-source Java Card Aliro applet, despite the applet emitting bytes that an independent CSA Aliro v1.0 reference reader decrypts cleanly. Because the failing routine is closed-source, we cannot localize where ST's interpretation diverges from ours. We are asking for source access, a concrete statement of which §8.3.1 interpretation ST uses, or confirmation that ours is correct plus a vendor patch.

Reproducer

• Reader hardware: NUCLEO-U545RE-Q + X-NUCLEO-NFC10A1 (ST25R200), STM32U535/U545 target.
• Reader firmware: X-CUBE-ALIRO middleware + RFAL T=CL (X-CUBE-ALIRO version <TBD>).
• Card: NXP J3R452 (also reproduces on J3R180) running our open-source Aliro applet, implementing CSA Aliro v1.0 §8.3.1.4 (Kdh via X9.63 KDF / BSI TR-03111 §4.3.3 single-step KDF with SHA-256), §8.3.1.5–.13 (HKDF salt expansion), §8.3.1.6 (AES-256-GCM AUTH1 response encryption: 12-byte IV, 16-byte tag), §8.3.1.13 (salt_volatile layout).
• Expected: Expedited Standard AUTH1 completes; reader extracts credential_PubK and UD signature.
• Observed: every AUTH1 response into ACWG_processAUTH1ResponsePayload returns ACWG_Error_Crypto_EncryptDecrypt. UART trace shows the retval at the call boundary; no internal context exposed.

Evidence

• UART trace: ACWG_processAUTH1ResponsePayload -> ACWG_Error_Crypto_EncryptDecrypt, repeatable across power cycles and across both J3R180 and J3R452.
• Card output: AUTH1 response APDU captured; structurally a single AES-256-GCM blob per §8.3.1.6.
• Independent decrypt: the same captured bytes fed into our PC/SC reader (aliro-bench-test, full Aliro spec implementation in Python) decrypt cleanly. Plaintext TLV:
  • signaling_bitmap = 0x0005
  • 0x5A credential_PubK = 65 B (uncompressed P-256, 04 || X || Y)
  • 0x9E UD signature = 64 B (raw ECDSA r || s over P-256)
• PC/SC path completes Expedited Standard end-to-end against the same card, same applet, same personalization. The card therefore emits well-formed §8.3.1 output by at least one reasonable reading of the spec.

What we ruled out

Three crypto fixes ("the trifecta") landed on the applet 2026-06-11; none changed Nucleo behavior:

1. salt_volatile structure — verified byte-for-byte against §8.3.1.13. Same bytes accepted by PC/SC.
2. Kdh derivation — corrected from HKDF to X9.63 KDF per §8.3.1.4. The corrected Kdh is what now decrypts cleanly under PC/SC.
3. AUTH1 cmd_params byte — confirmed the parameter byte the card hashes into its transcript matches what the Nucleo transmits on-air (RFAL frame capture).

All three were necessary for PC/SC; none were sufficient for the Nucleo library.

What we can't rule out

The vendor library's interpretation of §8.3.1.4 / §8.3.1.6 / §8.3.1.13 or the surrounding transcript construction may differ from ours in a way the spec text permits but does not require — e.g. AAD composition, IV layout, or transcript hash boundaries. Without source or symbols for Aliro.a / ACWG_Security.a we cannot identify which step raises ACWG_Error_Crypto_EncryptDecrypt. Reverse-engineering the archive is months of work for a vendor support question.

Request

Any of the following resolves the block:

1. Source access to Aliro.a / ACWG_Security.a — at minimum ACWG_processAUTH1ResponsePayload and its crypto helpers — under whatever NDA ST requires.
2. Concrete spec interpretation the vendor library uses for §8.3.1.4 / §8.3.1.6 / §8.3.1.13 in byte terms (key schedule, AAD, IV, tag).
3. Confirmation that our interpretation (matching the PC/SC reference) is correct, plus a vendor patch.
4. Partner-program acceptance if a beta firmware fix is already in flight.

We can provide the personalized card, the captured AUTH1 request/response APDU pair, and the PC/SC reader's decrypted plaintext for ST to validate against an independent reference.

ST contact for this report: <TBD> (currently filed via X-CUBE-ALIRO support channel; please advise correct routing).