Dangerous Things
782074f6ae
Three components, all bench-validated to varying depths: - applet/: CSA Aliro v1.0 Java Card applet for J3R180. AUTH0 + AUTH1 expedited-standard flow end-to-end green via PC/SC bench reader (aliro-bench-test). Userland AES-256-GCM and HMAC-SHA-256 layered on top of J3R180's primitives because the card lacks both natively. P-256 curve params seeded explicitly per J3R180's quirk. - harness/: Python orchestrator (aliro-trustgen, aliro-personalize, aliro-bench-test) for trust-bundle generation, card personalization via PersonalizationApplet, and PC/SC AUTH0+AUTH1 transactions. 126 pytest cases passing. - reader/STM32CubeExpansion_ALIRO_V1_0_0/: ST X-CUBE-ALIRO V1.0.0 with our NFC10A1 port (NUCLEO-U545RE-Q + X-NUCLEO-NFC10A1, ST25R200 shared with NFC09A1). nfc10-only/ project, NFC10A1 BSP shim, ALIRO_TRUST_OVERRIDE include into vendor's provisioning.c, and an ALIRO_APDU_TRACE wrapper around demoTransceiveBlocking. Boots, detects the J3R180, completes SELECT + AUTH0; AUTH1 currently fails with RFAL ERR_PROTO (0xB) — under investigation, see docs/plans/2026-04-20-nucleo-nfc10a1-port.md and bench-notes/. Excluded: x-cube-aliro.zip vendor archive, harness/.venv, build dirs, generated aliro_trust.h (contains private reader scalar), all PEMs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
62 lines
2.1 KiB
Python
62 lines
2.1 KiB
Python
"""Aliro-flavored mdoc DeviceResponse for the step-up phase.
|
|
|
|
Per Aliro §8.4.2, the User Device returns an ISO 18013-5 DeviceResponse
|
|
with two changes: readerAuth / documentErrors / errors / deviceSigned MUST
|
|
NOT be present, and map keys are replaced by the integer aliases in
|
|
Table 8-22 (still encoded as text strings).
|
|
|
|
For v1 (no Access Data Elements; Access Document carries only the
|
|
credential long-term public key inside IssuerAuth), the DeviceResponse
|
|
is effectively static once the AD is generated:
|
|
|
|
{
|
|
"1": "1.0", # version
|
|
"2": [ # documents
|
|
{
|
|
"1": { # issuerSigned
|
|
"1": {}, # nameSpaces (empty — no ADEs)
|
|
"2": <AD> # IssuerAuth — raw COSE_Sign1 bytes
|
|
},
|
|
"5": "aliro-a" # docType
|
|
}
|
|
],
|
|
"3": 0 # status (0 = OK)
|
|
}
|
|
|
|
The Access Document is already a serialized COSE_Sign1, which is itself
|
|
valid CBOR (a 4-element array). Splicing its bytes into the DeviceResponse
|
|
at the IssuerAuth position yields valid CBOR — no decode/re-encode needed.
|
|
"""
|
|
|
|
import cbor2
|
|
|
|
|
|
def build_device_response(access_document_bytes: bytes) -> bytes:
|
|
"""Returns a deterministic-CBOR DeviceResponse wrapping the given
|
|
Access Document as IssuerAuth.
|
|
|
|
``access_document_bytes`` must be the serialized COSE_Sign1 produced
|
|
by :func:`build_access_document` — it is embedded verbatim.
|
|
"""
|
|
# cbor2.dumps with canonical=True produces deterministic CBOR. The AD is
|
|
# loaded first so it lives in the structure as real Python objects that
|
|
# cbor2 re-encodes — this gives us canonical ordering guarantees even if
|
|
# the source AD was encoded differently.
|
|
ad = cbor2.loads(access_document_bytes)
|
|
return cbor2.dumps(
|
|
{
|
|
"1": "1.0",
|
|
"2": [
|
|
{
|
|
"1": {
|
|
"1": {},
|
|
"2": ad,
|
|
},
|
|
"5": "aliro-a",
|
|
}
|
|
],
|
|
"3": 0,
|
|
},
|
|
canonical=True,
|
|
)
|