refactor(applet): retire AliroApplet INS_EXCHANGE stub
The stub was added earlier this session as an X-CUBE-ALIRO compat shim back when we (incorrectly) believed the vendor firmware ignored the §10.2 step-up AID SELECT requirement and routed EXCHANGE directly to the Expedited AID (ACCE5501). Today's Path X work proved the vendor firmware actually DOES the §10.2 SELECT correctly once the upstream crypto interop is right. With M1B.1 / M1C.1 now landing the real EXCHANGE and ENVELOPE handlers on StepUpApplet (ACCE5502), the AliroApplet stub is strictly wrong: it would let stale expedited_device_counter state confuse the vendor library if the reader ever hit it. Spec-conformant readers route EXCHANGE to ACCE5502 after the step-up SELECT and never touch ACCE5501 with INS=0xC9. So AliroApplet returns SW_INS_NOT_SUPPORTED (0x6D00) for INS=0xC9 like any other unknown INS, and we ship one less compat shim. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -92,4 +92,19 @@ class AliroAppletTest {
|
||||
assertEquals(0x01, versions[0] & 0xFF, "expected first protocol version high byte 0x01");
|
||||
assertEquals(0x00, versions[1] & 0xFF, "expected first protocol version low byte 0x00");
|
||||
}
|
||||
|
||||
@Test
|
||||
void auth1ExchangeInsRejectedNowThatStepUpAppletOwnsIt() {
|
||||
// Once M1B.1 / M1C.1 land StepUpApplet (ACCE5502) as the proper owner
|
||||
// of INS_EXCHANGE (0xC9), AliroApplet must NOT also answer 0xC9 — a
|
||||
// spec-conformant reader routes EXCHANGE to ACCE5502 after the §10.2
|
||||
// step-up AID SELECT. AliroApplet receiving 0xC9 is a reader bug or
|
||||
// a stale flow, and must be rejected with SW_INS_NOT_SUPPORTED so it
|
||||
// can never accidentally interact with expedited session state.
|
||||
selectExpedited();
|
||||
CommandAPDU exchange = new CommandAPDU(0x80, 0xC9, 0x00, 0x00);
|
||||
ResponseAPDU resp = sim.transmitCommand(exchange);
|
||||
assertEquals(0x6D00, resp.getSW(),
|
||||
"AliroApplet must reject INS_EXCHANGE (0xC9) — StepUpApplet (ACCE5502) owns it now");
|
||||
}
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user