Reference Implementation for CTAP 2.2 Hybrid Tunnel Service

[Isaiah Inuwa]

Hello all,

I'm working on a platform authenticator for Linux and I'm diving into the hybrid transport flow. I see that there is a literate Go implementation for the client in the spec draft, but I don't see anything for the tunnel server.

I've gotten as far as implementing the QR initiation and decrypting/parsing the BLE advert from the mobile device, but it'd be a little bit easier to develop the WebSockets part against a local server rather than trying to test against Google's live production server.

If not, I'll keep going and see if I can keep going against the cable.ua5v.com instance and hope I don't hit any IP blocks!

Thanks,

Isaiah Inuwa

[Adam Langley]

There isn't any published reference server that I'm aware of, I'm afraid.

Cheers

AGL

[Isaiah Inuwa]

Thanks, Adam.

I've been working through the spec to make sure I understand it. I have a few questions/feedback.

# Authenticator Confirmation

There doesn't seem to be a step in the hybrid QR flow for the user to confirm to the client that the intended authenticator sent the BLE advert. Without this, it seems that an attacker could scan the QR code before them, allowing the attacker to register the attacker's credentials on the user's account, or to authenticate the user to the attacker's account, both of which have some security issues.

I would have guessed that there would be some sort of confirmation on the client to prevent this attack, such as the authenticator displaying the last byte of the connection nonce as 2 hex digit for the user to type into the client platform before they establish a tunnel.

Without this in place, I think the burden lies on users to keep QR codes private (by not using them in public places). Is this something that FIDO intends to address, or should we expect RPs (and the other passkey marketing materials) to communicate to users that QR code flows should not be initiated in public places?

# ecdh Package

I'm not sure if the final spec release will remain a Go program. With the ecdh package released in Go 1.20, are the corresponding functions drop-in replacements for the ecdsa references in the spec? I think so, but just wanted to confirm.

I'm sorry if this is the wrong place to ask; these seem like deployment questions. I'm not a FIDO or W3C member, so I can't ask in the working group.

Thank you,

II

[Adam Langley]

On Mon, Jan 15, 2024 at 1:35 PM Isaiah Inuwa <isaiah...@gmail.com> wrote:

Thanks, Adam.

I've been working through the spec to make sure I understand it. I have a few questions/feedback.

# Authenticator Confirmation

There doesn't seem to be a step in the hybrid QR flow for the user to confirm to the client that the intended authenticator sent the BLE advert. Without this, it seems that an attacker could scan the QR code before them, allowing the attacker to register the attacker's credentials on the user's account, or to authenticate the user to the attacker's account, both of which have some security issues.

I would have guessed that there would be some sort of confirmation on the client to prevent this attack, such as the authenticator displaying the last byte of the connection nonce as 2 hex digit for the user to type into the client platform before they establish a tunnel.

Without this in place, I think the burden lies on users to keep QR codes private (by not using them in public places). Is this something that FIDO intends to address, or should we expect RPs (and the other passkey marketing materials) to communicate to users that QR code flows should not be initiated in public places?

Yes, it's possible for an attacker, who can observe a victim's screen, to try and race the user to completing the QR-based hybrid protocol. It requires physical proximity and line of sight to the screen, so it's tough to pull off. It would have been possible to defend against in ways like the one you suggest, but our data suggests that hybrid is already at the limits of user inconvenience. We have, instead, focused on state-assisted transactions, and prelinking phones when both are signed into the same account, to both remove user friction and avoid this issue.

# ecdh Package

I'm not sure if the final spec release will remain a Go program. With the ecdh package released in Go 1.20, are the corresponding functions drop-in replacements for the ecdsa references in the spec? I think so, but just wanted to confirm.

Quite possibly! Given Go's compatibility guarantees I believe that the existing code will continue working and I'm afraid that updating it is unlikely to end up a high-enough priority to actually happen.

Cheers

AGL

--

Adam Langley a...@imperialviolet.org http://www.imperialviolet.org