Files
aliro-project/reader/STM32CubeExpansion_ALIRO_V1_0_0/Middlewares/ST
michael 06c00385a4 build(reader): WTX cap bump 20→255 + AUTH1 wrap instrumentation
rfal_isoDep.h: vendor RFAL_ISODEP_MAX_WTX_RETRYS is 20 by default. With
slow userland AES-GCM on the J3R-family (J3R180/J3R452), AUTH1 takes
~3.2 s of card processing -- comfortably more than the negotiated FWT,
so the card sends S(WTX) blocks to keep the link alive. At the card's
FWI of 4, the spec-default 20 cap trips before AUTH1 finishes and RFAL
aborts the transceive with ERR_PROTO 0xB. Bumping to the existing
RFAL_ISODEP_MAX_WTX_RETRYS_ULTD (=255) accepts up to 255 sequential
WTX requests, well within ISO 14443-4 limits. The card itself is fully
spec-compliant on the WTX side -- the 20-cap is ST's conservative
middleware choice. Revert to (20U) when we ship native AES-GCM hardware.

aliro_apdu_wrap.c: extends the existing AUTH1 payload wrap to log the
return value from ACWG_processAUTH1ResponsePayload (vendor library's
internal status). Was instrumental in finding the three crypto bugs we
fixed in the follow-up commit -- the vendor printed retval=ACWG_Error_*
which let us localize the spec divergences without source access to
Aliro.a or ACWG_Security.a. Two stale __real_/__wrap_ stubs for
ACWG_computeKDHandVolatileKeys and ACWG_derivePersistentKeys were
removed -- they had no matching --wrap flag in CMakeLists.txt and were
silently dead.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-11 10:15:34 -07:00
..