The M2 verdict run on J3R452 04555A4A0B2190 tripped SW=0x6FC4 on
AUTH0 (AliroCrypto.expandScratch makeTransientByteArray failure).
Summed CLEAR_ON_DESELECT allocations exceeded the ~3,120 B pool:
- PersonalizationApplet/CoseVerifier scratch: 768 B
- AliroApplet: 838 B (sessionState + scratch + derivedKeys + saltVolatile + kdh)
- StepUpApplet + StepUpSession: ~893 B (responseBuffer + scratchPlaintext + ...)
- AliroGcm + AliroCrypto (lazy, at first AUTH0): 720 B
Total ~3,220 B vs ~3,120 B cap.
CoseVerifier's 768 B was M2A.2's conservative sizing for up to 512 B COSE
payload. Aliro's IssuerAuth payload is ~188 B today. Tighten:
- MAX_PAYLOAD 512 -> 256 (still 36% headroom over actual)
- scratch 768 -> 384 (Sig_structure ~310 B + DER sig 72 B = ~382 B)
Saved 384 B, brings total to ~2,836 B. CAP rebuilt (100,990 B),
reinstalled + repersonalized + bench-test re-run -- GREEN.
Verdict log: docs/verdicts/2026-06-12-m2-pcsc-verdict.log
RESULT: OK -- applet round-trip on real hardware
0x5E signaling_bitmap: 0x0005
APDU latencies: select 23 ms, auth0 667 ms, auth1 3,258 ms
STEP-UP M2: OK -- EXCHANGE + ENVELOPE Access Document round-trip
Two plans land:
- 2026-06-07-step-up-implementation.md (v1): original 6-phase plan
written before the Path X session. Captured the four optimizations
(opt 1: reuse AliroGcm; opt 2: structural CBOR only; opt 3:
stream-encrypt during ENVELOPE emit; opt 4: cache IssuerAuth verify
at personalization) and the spec citations for each. Superseded by v2
but retained for the planning-history record.
- 2026-06-11-step-up-implementation-v2.md: revised after Path X
resolved the three crypto bugs. Splits into Milestone 1 (~400 LOC,
4-6 hours, gets DOOR OPERATION SUCCEEDED on stock X-CUBE-ALIRO with
decrypt-and-discard stubs) and Milestone 2 (~1500 LOC, 1-2 weeks,
real Access Document retrieval via mdoc DeviceResponse + CBOR + COSE).
The four optimizations are preserved into M2 where they matter; M1
ships without them since the demo doesn't need real document
payload yet.
Inline TODO comments mark the four optimization sites in source:
- CredentialStore.finalizeAccessDocument -- opt 4a (verify-flag in a
JCSystem.beginTransaction block) + opt 4b (Credential Issuer key
rotation assumption documented).
- StepUpApplet class javadoc -- all four optimizations laid out so the
implementer (subagent or human) lands them as they build the body.
(The AliroApplet INS_EXCHANGE comment that references the plans is
in the previous fix commit; it'll move/retire when M1 lands.)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three components, all bench-validated to varying depths:
- applet/: CSA Aliro v1.0 Java Card applet for J3R180. AUTH0 + AUTH1
expedited-standard flow end-to-end green via PC/SC bench reader
(aliro-bench-test). Userland AES-256-GCM and HMAC-SHA-256 layered
on top of J3R180's primitives because the card lacks both natively.
P-256 curve params seeded explicitly per J3R180's quirk.
- harness/: Python orchestrator (aliro-trustgen, aliro-personalize,
aliro-bench-test) for trust-bundle generation, card personalization
via PersonalizationApplet, and PC/SC AUTH0+AUTH1 transactions. 126
pytest cases passing.
- reader/STM32CubeExpansion_ALIRO_V1_0_0/: ST X-CUBE-ALIRO V1.0.0
with our NFC10A1 port (NUCLEO-U545RE-Q + X-NUCLEO-NFC10A1, ST25R200
shared with NFC09A1). nfc10-only/ project, NFC10A1 BSP shim,
ALIRO_TRUST_OVERRIDE include into vendor's provisioning.c, and an
ALIRO_APDU_TRACE wrapper around demoTransceiveBlocking. Boots,
detects the J3R180, completes SELECT + AUTH0; AUTH1 currently fails
with RFAL ERR_PROTO (0xB) — under investigation, see
docs/plans/2026-04-20-nucleo-nfc10a1-port.md and bench-notes/.
Excluded: x-cube-aliro.zip vendor archive, harness/.venv, build dirs,
generated aliro_trust.h (contains private reader scalar), all PEMs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
