MikeFaith/aliro-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: AUTH1 crypto interop with stock X-CUBE-ALIRO + EXCHANGE compat stub

Browse Source 
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>
This commit is contained in:
michael
2026-06-11 10:18:42 -07:00
parent 06c00385a4
commit f94e416c99
10 changed files with 213 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
applet/src/main/java/com/dangerousthings/aliro/AliroCrypto.java
View File

@@ -2,6 +2,7 @@ package com.dangerousthings.aliro;
import javacard.security.ECPrivateKey;
import javacard.security.KeyAgreement;
import javacard.security.MessageDigest;
/**
* Low-level Aliro cryptographic primitives, factored out so they can be
@@ -30,6 +31,9 @@ final class AliroCrypto {
private KeyAgreement ecdhPlain;
private AliroHmac aliroHmac;
/** Native SHA-256 instance used by {@link #deriveKdh} (X9.63 KDF). */
private MessageDigest sha256;
/** Reusable scratch for one HMAC output (T(i)) and one counter byte. */
private byte[] hkdfPrevT;
@@ -59,6 +63,11 @@ final class AliroCrypto {
} catch (Throwable t) {
javacard.framework.ISOException.throwIt((short) 0x6FC7);
}
try {
sha256 = MessageDigest.getInstance(MessageDigest.ALG_SHA_256, false);
} catch (Throwable t) {
javacard.framework.ISOException.throwIt((short) 0x6FC2);
}
try {
hkdfPrevT = javacard.framework.JCSystem.makeTransientByteArray(
HASH_LEN, javacard.framework.JCSystem.CLEAR_ON_DESELECT);
@@ -183,26 +192,42 @@ final class AliroCrypto {
}
/**
* Derives Kdh per Aliro §8.3.1.4 (with the §8.3.1.5 HKDF substitution
* noted in the spec): {@code Kdh = HKDF(IKM=ECDH_x(priv, peerPub),
* salt=txnId, info=∅, L=32)}. Writes 32 bytes to {@code out[outOff..]}
* and returns 32.
* Derives Kdh per Aliro §8.3.1.4: <b>X9.63 KDF</b> from BSI TR-03111 with
* H=SHA-256, ZAB = ECDH shared-secret x-coord, SharedInfo =
* transaction_identifier, K = 256 bits. For 32-byte output X9.63 KDF
* reduces to a single SHA-256 invocation:
* <pre>
* Kdh = SHA-256(ZAB || 0x00000001 || transaction_identifier)
* </pre>
*
* <p><b>History:</b> we previously misread the §8.3.1.4 note ("actual key
* derivation is performed using §8.3.1.5") as authorizing HKDF
* substitution for Kdh itself. The note is about the subsequent
* session-key derivation (§8.3.1.13 uses §8.3.1.5 HKDF), not Kdh. The
* misread was symmetric between this applet and our PC/SC reader, so
* AUTH1 succeeded against our own host-side reader but failed against
* ST's X-CUBE-ALIRO library (which follows §8.3.1.4 correctly) with
* {@code ACWG_Error_Crypto_EncryptDecrypt}. Fixed 2026-06-11.
*
* <p>Writes 32 bytes to {@code out[outOff..]} and returns 32.
*/
short deriveKdh(
ECPrivateKey priv,
byte[] peerPubUncomp, short peerPubOff,
byte[] txnId, short txnIdOff, short txnIdLen,
byte[] out, short outOff) {
// Stage ZAB || counter(0x00000001) at kdfWorkbuf[0..36).
computeEcdhSharedX(priv, peerPubUncomp, peerPubOff, kdfWorkbuf, (short) 0);
hkdfExtract(
txnId, txnIdOff, txnIdLen,
kdfWorkbuf, (short) 0, HASH_LEN,
kdfWorkbuf, HASH_LEN);
hkdfExpand(
kdfWorkbuf, HASH_LEN, HASH_LEN,
kdfWorkbuf, (short) 0, (short) 0,
HASH_LEN,
out, outOff);
kdfWorkbuf[32] = 0;
kdfWorkbuf[33] = 0;
kdfWorkbuf[34] = 0;
kdfWorkbuf[35] = 1;
// Kdh = SHA-256(ZAB || counter || txnId) -- one shot.
sha256.reset();
sha256.update(kdfWorkbuf, (short) 0, (short) 36);
sha256.doFinal(txnId, txnIdOff, txnIdLen, out, outOff);
// Wipe ZAB from working memory.
javacard.framework.Util.arrayFillNonAtomic(kdfWorkbuf, (short) 0, (short) 36, (byte) 0);
return HASH_LEN;
}