fix(ctap1): emit Le on U2F APDUs to support case 4#200
Open
AlfioEmanueleFresta wants to merge 2 commits into
Open
fix(ctap1): emit Le on U2F APDUs to support case 4#200AlfioEmanueleFresta wants to merge 2 commits into
AlfioEmanueleFresta wants to merge 2 commits into
Conversation
U2F REGISTER and AUTHENTICATE are Case 4 APDUs per FIDO U2F Raw Message Formats v1.2 sections 3 and 4. The encoder previously stopped after the Lc + data field, silently dropping the response_max_length that callers were setting. Strict authenticators reject these as Case 3 (no response expected) requests. Append a 2-byte big-endian Le when response_max_length is Some, with values >= 65536 encoded as the 0x0000 wildcard.
The From<&ApduRequest> for Command impl was calling Command::new_with_payload, which produced a Case 3 APDU and dropped the response_max_length field. U2F REGISTER and AUTHENTICATE require a Case 4 APDU per FIDO U2F NFC section 3.1. Switch to new_with_payload_le so Le is included when the request asks for a response. For the typical short-form request (le=256), apdu-core encodes Le as a single 0x00 byte.
f209a82 to
a3e58c2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
U2F REGISTER and AUTHENTICATE produce a response payload, so per FIDO U2F Raw Message Formats v1.2 section 3.1 the request APDU must include
Le(omittingLeis reserved for instructions not expected to yield response bytes). libwebauthn was settingresponse_max_lengthon theApduRequestbut both encoders silently dropped it:ApduRequest::raw_longstopped after theLc + datafield. Withresponse_max_length = Some(0x100)the byte stream came out as a Case 3 extended APDU (noLe).From<&ApduRequest> for CommandusedCommand::new_with_payload, which does not carryLeat all.Strict authenticators reject Case 3 register/authenticate. The in-tree virtual
fido-authenticatoris lenient about it, so CI never caught the gap.Changes
ApduRequest::raw_longnow appends a 2-byte big-endianLewhenresponse_max_lengthisSome(_), matching the extended-length encodingLe1 Le2from FIDO U2F Raw Message Formats v1.2 section 3.1.3. Values>= 65536collapse to0x0000(the spec's wildcard forNe = 65536). This is the path used by HID, BLE, and caBLE, all of which mandate extended-length encoding (FIDO U2F HID v1.2 section 2.4; FIDO U2F BT v1.2 sections 5.1 and 5.2).From<&ApduRequest> for Commandswitches toCommand::new_with_payload_le, soresponse_max_lengthis propagated throughapdu-core. Withlonger_payloadsdisabled (the default in this crate),apdu-corewritesLeas a single byte; for the typical request withresponse_max_length = 256this yieldsLe = 0x00, which is short-form Case 4 and valid under FIDO U2F NFC v1.2 section 3 ("either short or extended length APDU encoding is allowed").raw_longand the NFC encoder, including the wildcardLe = 0x0000.Spec references