Keys tied to users -- during registration, an authenticator generated a new ECDSA key locally, and offloads it to the PC, to be sent to the server. The public c

Keys tied to users -- during registration, an authenticator generated a new ECDSA key locally, and offloads it to the PC, to be sent to the server. The public component is exported in plaintext and is the verifier data. The private component is sealed by symmetric encryption using a key held only on your device. Part of the sealing includes the canonical representation of the domain, protocol and port for the site in question. Origin binding -- When you visit a site you used before, the site sends you the encrypted blob offloaded private key. Your token verifies it and decrypts it, and signs a challenge using the key and sends that back to the server as a response, to be verified using the stored public key. Part of this unsealing process ties it to the domain, protocol and port of the origin site making the request, so if a phishing site acts as a relay, your token won't generate a valid response, since the phishing site origin differs and the offloaded private key won't decrypt. If you look at the threat model here, if your token and its implantations of crypto are secure, you really need to get rogue software onto the client device, which can send arbitrary requests over USB to your security token device, and trick the user into proceeding. At that point it's "game over" as you have code execution on the endpoint and there's other ways to achieve your goals from there.