M2E.1: parse the EXCHANGE plaintext as Aliro §8.3.3.5 / Table 8-19 [sub_event_id, payload_len, payload], reject SW_WRONG_LENGTH on truncation or length mismatch and SW_DATA_INVALID on unknown sub_event_id (M2 only supports 0x01 = ReaderStatusRequest). M2E.2: emit a Reader Status sub-event RESPONSE (Table 8-20) plaintext [0x01, 0x00, 0x00] in place in the APDU buffer, GCM-encrypted under StepUpSKDevice + deviceIv(stepup_device_counter) per §8.3.1.6. Ciphertext+ tag = 19 B, single APDU, no chaining. Harness verify_step_up_m2 + the test mock now ship the spec request shape, decrypt the 19 B EXCHANGE response under deviceCounter=1, and decrypt the subsequent ENVELOPE response under deviceCounter=2 (EXCHANGE consumed 1). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Aliro test harness
PC-side tools for the Aliro Java Card applet project.
Layout
src/aliro_harness/
├── issuer/ Test CA: keypairs, X.509 certs, signed Access Documents
├── personalize/ pyscard-based loader driving the PersonalizationApplet
├── reader_log/ pyserial VCP capture, tag parser, trace differ
└── trustgen/ CLI emitting reader/aliro_trust.h from CA + reader keys
tests/ pytest suite (unit + end-to-end)
Setup
python3 -m venv .venv
source .venv/bin/activate
pip install -e '.[dev]'
pytest
Not for production
All keys generated or accepted by this harness are TEST-ONLY. Do not reuse in a production Aliro deployment.