f94e416c99
Three independent spec-misreads found via Path X investigation against
the X-CUBE-ALIRO vendor library, all causing
ACWG_Error_Crypto_EncryptDecrypt on the vendor's processAUTH1ResponsePayload.
Each was symmetric between this applet and our PC/SC reader, so
aliro-bench-test passed against our own host-side reader but failed
against any spec-compliant third-party reader. Path X also surfaced
an X-CUBE-ALIRO-specific compat shim (bitmap + EXCHANGE stub) which is
documented to be retired by the Step-Up Milestone 1 work.
1. salt_volatile dropped x(credential_long_term_pub) at the end.
§8.3.1.13 salt_volatile ends at the 0xA5 proprietary information TLV;
the credential key belongs in `info` (and even there it's the
EPHEMERAL one, which buildInfo already does correctly).
2. Kdh now uses X9.63 KDF per §8.3.1.4 instead of HKDF.
The §8.3.1.4 closing note ("actual key derivation is performed using
§8.3.1.5") refers to subsequent session-key derivation from Kdh
(§8.3.1.13 -> §8.3.1.5 HKDF), NOT a substitution for Kdh itself.
For 32-byte output X9.63 KDF reduces to:
Kdh = SHA-256(ZAB || 0x00000001 || transaction_identifier)
Added a native SHA-256 instance to AliroCrypto for this one-shot.
3. salt_volatile flag uses AUTH1's command_parameters, not AUTH0's.
§8.3.1.13 says "command_parameters || authentication_policy from the
command data field". When §8.3.1.13 runs (after AUTH1), the active
request is AUTH1; authentication_policy only exists in AUTH0 so it's
still pulled from saved AUTH0 state, but command_parameters is the
AUTH1 value (typically 0x01 = "request credential_PubK in response").
4. signaling_bitmap kept at 0x0005 when AD provisioned + INS_EXCHANGE
stub on AliroApplet returns 9000 with empty payload. Empirically the
X-CUBE-ALIRO vendor library errors on bitmap=0x0000 even though the
spec allows it (separate vendor quirk worth filing); EXCHANGE stub
exists because the firmware unconditionally sends 0xC9 post-AUTH1
for the Reader Status sub-event report. Both shims are documented to
be retired in Step-Up Milestone 1 -- StepUpApplet will handle 0xC9
on its own AID (ACCE5502) per §10.2.1 after the spec-mandated
step-up AID SELECT.
PC/SC bench-test still passes: AUTH1=9000, ~3.2 s, bitmap=0x0005.
Nucleo X-CUBE-ALIRO firmware now reports retval=ACWG_OK on
processAUTH1ResponsePayload (confirmed against j3r452 UID
04565E4A0B2190 in /tmp/nucleo-three-fixes.log). The remaining
"DOOR OPERATION FAILED" on Nucleo is downstream Step-Up not being
implemented yet -- StepUpApplet is still the scaffold and returns
6D00/6E00 to ENVELOPE / EXCHANGE. That's Milestone 1 work.
80/80 Java tests + 126/126 Python tests pass.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
76 lines
2.9 KiB
Python
76 lines
2.9 KiB
Python
"""Reader-side mirror of AliroApplet.buildSaltVolatile / deriveSessionKeys.
|
|
|
|
Keep this BYTE-IDENTICAL to the applet implementation in
|
|
applet/src/main/java/com/dangerousthings/aliro/AliroApplet.java
|
|
(buildSaltVolatile). Drift here = decryption fails on real card.
|
|
"""
|
|
|
|
from io import BytesIO
|
|
|
|
from aliro_harness.reader.crypto import hkdf_sha256
|
|
|
|
SALT_VOLATILE_TAG = b"Volatile****"
|
|
INTERFACE_BYTE_NFC = 0x5E
|
|
PROPRIETARY_A5_TLV = bytes.fromhex("A50880020000" "5C020100")
|
|
PROTOCOL_VERSION_1_0 = bytes([0x01, 0x00])
|
|
|
|
# Offsets into the 160B derived_keys_volatile (§8.3.1.13).
|
|
OFF_EXPEDITED_SK_READER = 0
|
|
OFF_EXPEDITED_SK_DEVICE = 32
|
|
OFF_STEP_UP_SK = 64
|
|
|
|
|
|
def build_salt_volatile(
|
|
*,
|
|
reader_long_term_pub_x: bytes,
|
|
reader_group_id: bytes,
|
|
reader_group_sub_id: bytes,
|
|
reader_ephem_pub_x: bytes,
|
|
transaction_id: bytes,
|
|
command_parameters: int,
|
|
authentication_policy: int,
|
|
) -> bytes:
|
|
"""Per spec §8.3.1.13. Mirrors AliroApplet.buildSaltVolatile.
|
|
|
|
Spec §8.3.1.13 salt_volatile ends at the 0xA5 proprietary TLV. We
|
|
previously appended x(credential_long_term_pub_key) here; that was a
|
|
misread of the spec (the credential pubkey belongs in `info`, and even
|
|
there it's the *ephemeral* pubkey, not the long-term one). The misread
|
|
was symmetric between this reader and the applet, so AUTH1 succeeded
|
|
against our own card but failed against ST's X-CUBE-ALIRO with
|
|
ACWG_Error_Crypto_EncryptDecrypt. Fixed 2026-06-11.
|
|
"""
|
|
if not (0 <= command_parameters <= 0xFF and 0 <= authentication_policy <= 0xFF):
|
|
raise ValueError(
|
|
"command_parameters and authentication_policy must each fit in one byte"
|
|
)
|
|
out = BytesIO()
|
|
out.write(reader_long_term_pub_x) # 32
|
|
out.write(SALT_VOLATILE_TAG) # 12
|
|
out.write(reader_group_id) # 16
|
|
out.write(reader_group_sub_id) # 16
|
|
out.write(bytes([INTERFACE_BYTE_NFC])) # 1
|
|
out.write(bytes([0x5C, 0x02])) # 2
|
|
out.write(PROTOCOL_VERSION_1_0) # 2
|
|
out.write(reader_ephem_pub_x) # 32
|
|
out.write(transaction_id) # 16
|
|
out.write(bytes([command_parameters, authentication_policy])) # 2
|
|
out.write(PROPRIETARY_A5_TLV) # 10
|
|
salt = out.getvalue()
|
|
if len(salt) != 141:
|
|
raise ValueError(
|
|
f"salt_volatile must be 141 bytes (caller passed wrong-length x-coord or ID); "
|
|
f"got {len(salt)}. Each 32B field must be exactly 32B; each 16B field must be 16B."
|
|
)
|
|
return salt
|
|
|
|
|
|
def derive_expedited_session_keys(
|
|
kdh: bytes,
|
|
salt_volatile: bytes,
|
|
info_credential_ephem_pub_x: bytes,
|
|
) -> bytes:
|
|
"""§8.3.1.13: derived_keys_volatile (160B). info = x(credential_ephem_pub) +
|
|
AUTH0 vendor extensions (none in v1)."""
|
|
return hkdf_sha256(kdh, salt_volatile, info_credential_ephem_pub_x, 160)
|