9879668472
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>