Your security key trusts the computer it’s plugged into. That’s the problem.
FIDO2 is the best answer the industry has to phishing. Private keys never leave the authenticator, and every signature is bound to the website that asked for it. That is why hospitals, banks and governments are moving to passkeys and security keys.
But a 2022 formal analysis presented at ESORICS, "A Formal Analysis of the FIDO2 Protocols" by Guan, Li, Ye and Zhao, found a weak spot that is easy to miss. The cryptography is not the problem. The problem is the computer in the middle.
How the Client PIN works
Many security keys have no screen and no keypad. To prove that the right person is holding the key, the user types a PIN on the computer. The computer then passes it to the authenticator over USB, NFC or Bluetooth.
To protect the PIN on the way, the two sides first agree on a shared key using Elliptic-curve Diffie–Hellman (ECDH). The catch is that this exchange is unauthenticated: neither side can confirm who is on the other end.
What the researchers found
The authors modelled FIDO2 in the ProVerif verifier across 32 scenarios and more than 78,000 test cases. Their conclusion is blunt: the Client PIN mechanism "has flaws".
The PIN can be intercepted. An attacker sitting between the computer and the authenticator can swap in its own keys on both sides. It then decrypts the current PIN, any new PIN and the PinToken that unlocks the authenticator for the session.
A malicious client can bind the wrong key. In an "authenticator rebinding" attack, malware on the user's computer relays the registration to an attacker's key of the same model. The website accepts it, and the victim's account now trusts the attacker's device.
A touch can approve someone else's login. In a "parallel session" attack, malware forwards an attacker's login request to the victim's authenticator. The user touches the key thinking it is their own sign-in, and the signature goes to the attacker's session.
Counters and transaction text leak. The signature counter and transaction text travel in the clear, so a malicious client can learn how often the user signs in and what they are approving.
None of these attacks extracts a private key. They all work by exploiting what the authenticator cannot see and the user cannot check.
The root cause: input and output on the wrong device
Every one of these attacks relies on the same assumption: the host computer is trusted. It collects the secret (the PIN) and it tells the user what they are approving. If the host is compromised, or the channel to the key is, both input and output are in the attacker's hands.
The researchers recommend protocol fixes: authenticate the authenticator and client to each other, authenticate the client to the relying party, and encrypt the counter and transaction data. Those are sound, and they will take years to reach the installed base.
There is a more direct design answer, and it is in our view the one that matters most for high-assurance environments. Move input and output onto the authenticator itself.
Secure input. When the user is verified on the authenticator, with a fingerprint sensor on the device, there is no PIN to type on a keyboard, send over a cable or intercept with a keylogger. The secret never touches the host.
Secure output. When the authenticator has its own display, it can show what is being approved before the user consents. A rebinding or parallel session attack depends on the user not knowing which request they are confirming. A trusted screen removes that blind spot.
Why this matters in hospitals
Clinical workstations are shared, busy and hard to lock down. They run legacy software, accept USB devices and are used by dozens of people a shift. That is precisely the kind of host the FIDO2 Client PIN assumes it can trust.
An authenticator that verifies the clinician on the device and shows what it is signing does not have to trust the workstation. That is the principle behind the Crayonic Badge, which pairs an on-device biometric sensor with an e-ink display, so identity is checked and confirmed on the wearer's own hardware.
Questions to ask about any authenticator
Where is the user verified: on the device, or on the computer?
Can the user see what they are approving, on hardware the attacker does not control?
If the workstation were compromised tomorrow, what could the attacker do with the key plugged into it?
Does the vendor's threat model say what it assumes about the host?
FIDO2 removed passwords from the server. The next step is removing trust in the computer between the user and their key.
