U2F is een challenge-response-protocol uitgebreid met bescherming tegen phishing en Man-In-The-Middle-aanvallen, toepassingsspecifieke sleutels, detectie van apparaatklonen en apparaatattestatie. Er zijn twee processen: registratie en authenticatie.a
We beginnen met een eenvoudig challenge-response authenticatieproces, gebaseerd op openbare-sleutelcryptografie. Het U2F-apparaat heeft een privésleutel (kpriv) en de RP (Relying Party) krijgt de bijbehorende openbare sleutel (kpub). Het sleutelpaar wordt gegenereerd in de sabotagebestendige uitvoeringsomgeving van het apparaat, waar kpriv niet uit kan worden gehaald.
Het concept is dat de client samenstelt wat het weet over de huidige HTTP-verbinding (URI en TLS-kanaal-ID). Deze informatie wordt vervolgens ondertekend door het U2F-apparaat en naar de RP (Relying Party) gestuurd, die verifieert dat de informatie correct is.
Toevoegingen aan het authenticatieproces:
Application-specific keys voorkomen dat vertrouwende partijen apparaten kunnen volgen tussen verschillende gebruikersaccounts. Dit betekent dat Example.com niet kan weten of User1 en User2 dezelfde sleutel delen. Het U2F-apparaat genereert een nieuw sleutelpaar en sleutelhandvat voor elke registratie. Het handvat wordt opgeslagen door de RP en terug gestuurd naar het apparaat bij authenticatie. Op deze manier weet het apparaat met welke sleutel te authenticeren (bijvoorbeeld de sleutel van User1 of User2).
Toevoegingen aan het authenticatieproces:
Zoals al vermeld, zijn Yubico’s U2F-apparaten sabotagebestendig en kan kpriv niet extern worden gelezen (tenminste niet onopgemerkt). Om toch kloon detectie te bieden aan U2F-apparaten zonder sabotagebestendige beveiligingselementen (bijvoorbeeld software-implementaties), voegen we een authenticatieteller toe. Het concept is eenvoudig: Het apparaat verhoogt de teller bij het authenticeren, en de RP controleert of de teller hoger is dan de vorige keer.
Toevoegingen aan het authenticatieproces:
Attestatie geeft vertrouwende partijen de mogelijkheid om token eigenschappen te verifiëren, zoals het tokenmodel. Dit wordt geïmplementeerd via een attestatiecertificaat, ondertekend door de apparaatleverancier, dat het apparaat naar de RP stuurt bij registratie. Attestatie heeft geen invloed op de authenticatieprocedure.
Toevoegingen aan het registratieproces:
Een U2F-apparaat moet voor elke service waarmee het zich registreert, een nieuw ECC-sleutelpaar genereren. Bij authenticatie moet het apparaat de eerder gegenereerde sleutel voor die service gebruiken. Dit is triviaal, maar wordt complexer naarmate we meer eisen toevoegen.
We only need a key-value store on the device without any additional requirements.
example.org => [Key for example.org]acme.com => [Key for acme.com]
We want to allow devices to store multiple keys per service. For example, a user might have more than one GMail accounts. To solve this, we associate each key with a key handle instead of with a service. During registration, the device sends a key handle which is kept by the service. When authenticating, the service sends the key handle back to the device.
KeyHandle[0x21AE9B] => [Key 1 for example.org]KeyHandle[0xFBD308] => [Key 2 for example.org]KeyHandle[0x18C77B] => [Key 1 for acme.com]
The above implementation would work for a U2F device with lots of (tamper-resistant) storage. Unfortunately, this would make devices more expensive. However, since U2F does not specify how to store keys, we are free to come up with another solution — so we did:
Key generation scheme used by Yubico U2F devices
U2F + FIDO2
USB-A NFC