The ENVELOPE handler now consumes the decrypted DeviceRequest through
DeviceRequestParser.validate (M2D.1), builds a canonical-CBOR
DeviceResponse around the cached Access Document via
DeviceResponseBuilder.build (M2D.2), and AES-256-GCM-encrypts the
result under StepUpSKDevice. For our standard 272 B AD the encrypted
output is 388 B (372 B body + 16 B GCM tag), so we ship the first
252 B inline with SW=61xx and let the reader pull the remaining 136 B
via GET RESPONSE (INS=0xC0). The chaining offset/remaining state is
held in a CLEAR_ON_DESELECT short pair; a fresh ENVELOPE resets both
slots, and GET RESPONSE outside an in-flight chain returns
SW_CONDITIONS_NOT_SATISFIED.
Tests:
- envelopeAfterStepUpSelectReturnsRealDeviceResponseViaChaining drives
AUTH0/AUTH1, sends a valid CBOR DeviceRequest under the StepUpSKReader
GCM, drains GET RESPONSE until SW=9000, and asserts the decrypted
plaintext matches the M2D.2 canonical-CBOR DeviceResponse byte-for-byte.
- envelopeWithMalformedDeviceRequestReturnsDataInvalid pins the
SW_DATA_INVALID propagation path.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
9879668472