0e0a338b26
X-CUBE-ALIRO V1.0.0 (25-Feb-2026) + ST25 RFAL middleware V2.8.0 per the Release_Notes.html in the SDK we built against. ST routing set to the X-CUBE-ALIRO support form on st.com; replace with named FAE/partner contact if/when ST advises a different routing.
56 lines
4.7 KiB
Markdown
56 lines
4.7 KiB
Markdown
# 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 V1.0.0 (released 25-February-2026) + ST25 RFAL middleware V2.8.0 (T=CL).
|
||
- **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:** filing via the X-CUBE-ALIRO support form at https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-aliro.html. If routing-to-engineering needs a named FAE/partner contact, please advise — happy to re-send through whichever channel ST prefers.
|