Comment FIDO rend possible l’authentification sans mot de passe

Comment FIDO rend possible l’authentification sans mot de passe

Résoudre le problème des mots de passe dans le monde

FIDO est l’acronyme de Fast IDentity Online. C’est une alliance industrielle ouverte fondée en 2012 dans le but de résoudre le problème des mots de passe. La technologie qui sous-tend FIDO2 se base sur la cryptographie asymétrique. À ce propos, une clé privée et une clé publique génèrent chacune une paire de clés. La clé publique du destinataire peut s’échanger à tout moment avec des partenaires de communication pour crypter des messages. Pour décrypter le message, la clé privée du destinataire est nécessaire ; le destinataire doit la conserver en sécurité, car des tiers pourraient décrypter le message s’ils l’interceptaient.

Chaque authentificateur disponible pour FIDO2 possède un certificat X.509, également appelé certificat d’attestation, stocké lors de la fabrication du dispositif. La clé privée est gravée dans le dispositif et ne peut pas être exportée ou interférée d’une autre manière. En outre, le dispositif est attesté cryptographiquement. Par exemple, des attaquants tentent d’intercepter une demande d’enregistrement et de la remplacer par la leur. Or ils ne peuvent pas échanger la clé publique générée avec une autre clé. Car la signature d’attestation ne correspond pas.

Ceci est la première partie d’un article de blog en deux parties expliquant les détails de FIDO2. La première partie couvre :

• les bases de l’authentification sans mot de passe,
• les composants de FIDO2
• le déroulement de l’enregistrement et de l’authentification en détail.

La deuxième et dernière partie se concentre sur la planification, la mise en œuvre et l’audit d’une implémentation FIDO2 dans Azure AD.

Composants de la FIDO2

Principe

WebAuthn et le protocole CTAP2 (Client to Authenticator Protocol 2) sont deux composants importants de l’architecture FIDO2 (figure 2) :

• WebAuthn est une API JavaScript basée sur un navigateur Web et indépendante de la plate-forme, dans le standard Web du W3C. L’API permet aux utilisateurs de s’authentifier auprès de services Internet sans mot de passe. Pour cela elle utilise une cryptographie asymétrique basée sur une méthode de clé publique.

CTAP2 contrôle la communication entre le client et l’authentificateur. Par exemple, le client peut être un ordinateur disposant d’un navigateur Web et l’authentificateur peut être un appareil mobile. L’hôte CTAP2 fait partie du client, qui communique avec l’authentificateur via l’API CTAP CBOR.

La figure 1 montre que le protocole CTAP2 peut communiquer avec des applications qui ont mis en œuvre CTAP2. Ainsi, l’ouverture de session sans mot de passe ne se limite pas aux services Internet. Mais elle peut servir de diverses manières, par exemple pour se connecter à des appareils Windows 10 autonomes ou reliés à un domaine.

Les composants

Il existe plusieurs autres composants importants de FIDO2, illustrés dans la figure 2, que nous devons comprendre :

• L’authentificateur de plate-forme et l’authentificateur d’itinérance agissent en tant qu’entité sécurisée intégrée au dispositif final de l’utilisateur ou attachée à celui-ci.
• Le service de métadonnées FIDO (MDS) aide à prouver l’authenticité de l’authentificateur en récupérant régulièrement les chaînes de certificats de l’authentificateur. Les fabricants génèrent et stockent de manière aléatoire un Authenticator Attestation Globally Unique ID (AAGUID), qui identifie le modèle d’Authenticator.
• Le client WebAuthn met en œuvre l’API WebAuthn et se compose d’un système d’exploitation et d’un navigateur Web. Il sert d’interface entre l’authentificateur et la partie utilisatrice afin que l’authentification s’effectue à l’aide de l’API WebAuthn.
• La partie dépendante se compose du serveur web et du serveur FIDO. En tant que construction globale, elle fournit un accès à une ressource sécurisée. Il accepte les demandes du serveur ou de l’application web pour enregistrer et authentifier les utilisateurs. Aucun protocole spécifique n’est oligatoire pour la communication entre le serveur ou l’application web et le Relying Party. Mais ils sont souvent mis en œuvre comme une API REST. TLS sécurise toutes les communications, sinon l’API WebAuthn ne permettra aucune communication.
• La certification d’une partie utilisatrice et d’un authentificateur peut être accordée par l’Alliance FIDO. Cela permet de valider la conformité et l’interopérabilité du produit. Pour chaque produit, il existe différentes exigences de sécurité, qui sont étiquetées de niveau 1 à niveau 3+. Il est à noter que tous les authentificateurs doivent répondre au moins au niveau 1 des exigences de sécurité pour obtenir la certification FIDO.

Inscription

Définition

L’inscription signifie que la partie utilisatrice crée un compte utilisateur. Un utilisateur appelle le service via un client WebAuthn, transfère les données d’un Authenticator. Et il dépose une clé publique auprès de la Relying Party. Plus tard, l’utilisateur pourra s’authentifier auprès du service en utilisant le même Authenticator. La figure 3 décrit le processus d’enregistrement.

Les étapes

Les étapes à suivre sont les suivantes :

1. Un utilisateur navigue vers un service prenant en charge WebAuthn (par exemple outlook.com) dans le navigateur web et fait une demande d’authentification.
2. La partie utilisatrice renvoie une réponse au client WebAuthn. Cela consiste en des paramètres que le client WebAuthn doit remplir pour s’enregistrer. Par exemple, la partie utilisatrice peut spécifier quel authentifiant est à utiliser. L’authentification locale peut consister en la saisie d’un code PIN, de caractéristiques biométriques telles que l’empreinte digitale, ou d’une confirmation par un lecteur NFC.
3. Le client WebAuthn reçoit les paramètres de la partie utilisatrice et vérifie les authentificateurs disponibles connectés au client WebAuthn. La particularité de cette procédure est que l’identifiant de la partie utilisatrice se base sur le nom de domaine. Le nom de domaine (Origine) doit être crypté par TLS et n’est accessible que via https://. L’identifiant de la partie utilisatrice n’est valable que s’il correspond à l’origine de la partie utilisatrice. En supposant que l’URL de connexion d’un service Internet est https://login.example.com, les ID des parties utilisatrices suivantes sont valides : login.example.com (par défaut) et example.com. Mais pas m.login.example.com et pas seulement .com.
4. L’authentificateur vérifie si le Relying Party passe une interaction utilisateur avant que l’enregistrement s’effectue. Lors de l’enregistrement auprès d’un service Internet, cela génère une nouvelle paire de clés asymétriques. Cette dernière n’est pas partagée entre les services Internet. Cette paire de clés s’appelle paire de clés d’identification ou simplement paire de clés (Figure 4).

Vérification

La clé privée de l’authentificateur signe la clé publique nouvellement créée avec les informations de la partie utilisatrice. Elle est renvoyée à la partie utilisatrice et stockée dans celle-ci pour une authentification ultérieure. Enfin, un compteur de signature doit être exécuté par l’authentificateur pour incrémenter une valeur positive après chaque enregistrement. Puis le compteur l’envoie à la partie utilisatrice. Ce compteur sert à identifier et rejeter un authentificateur cloné.

5. La nouvelle clé publique générée et signée à l’étape précédente et les autres attestations nécessaires sont renvoyées au client WebAuthn. Il est important de noter que l’authentificateur doit effectuer une certaine forme d’attestation avant la livraison pour vérifier l’authenticité. En général, l’attestation comprend :
   • une clé publique d’authentification signée numériquement par la clé privée d’attestation et un défi,
   • ainsi qu’un certificat ou des données similaires qui peuvent confirmer les informations de provenance de la clé publique par la partie utilisatrice. Cet élément emballé s’appelle objet d’attestation.
6. Entre autres choses, le client WebAuthn renvoie l’objet d’attestation à la partie utilisatrice afin qu’elle puisse vérifier la réponse.
7. Le Relying Party stocke la clé publique et vérifie les données de l’objet d’attestation et les éventuelles extensions. La validation de l’authentificateur peut s’effectuer par la partie utilisatrice elle-même ou par le service de métadonnées FIDO. Le processus d’enregistrement terminé, l’utilisateur peut s’authentifier sans mot de passe avec l’authentificateur utilisé.

Authentification

Pour l’authentification, un utilisateur prouve son identité à la partie utilisatrice par l’intermédiaire d’un client WebAuthn utilisant un Authenticator. La figure 5 donne un aperçu du processus d’authentification :

1. Lorsqu’un utilisateur s’authentifie sur un service WebAuthn, le client à faire une demande d’authentification à une partie utilisatrice.
2. La partie utilisatrice reçoit la demande d’authentification et renvoie au client WebAuthn. Comme cela a déjà été fait lors de l’inscription, un nouveau défi est généré, entre autres. Il convient de renvoyer au client WebAuthn autant d’informations que possible, également appelées assertion d’authentification. Cela permet de limiter le choix des méthodes d’authentification pour l’utilisateur. Cela se ase sur les données présentes dans l’Authenticator.
3. Le client WebAuthn reçoit les options contenues dans l’étape 2 et commence la validation et l’appel de l’Authenticator. Puis, l’authentificateur reçoit les paramètres de l’ID de la partie utilisatrice.
4. L’authentificateur reçoit les données du client WebAuthn et vérifie si l’ID de la partie utilisatrice de l’enregistrement correspond. Puis il génère une signature d’assertion. Ensuite, la clé privée générée par l’authentificateur vérifie l’authenticité des données provenant de l’ID de la partie utilisatrice. Mais avant cela, il peut être nécessaire de procéder à une nouvelle authentification locale de l’authentificateur.
5. Entre autres choses, l’authentificateur renvoie les données signées de la signature d’assertion au client WebAuthn.
6. Le client WebAuthn envoie les données de l’authentificateur et la signature d’assertion à la partie utilisatrice.
7. Le Relying Party vérifie la disponibilité de la clé publique dans la base de données. Aussi, il vérifie la signature d’assertion avec la clé publique (clé publique d’identification) stockée lors de l’enregistrement.

Résumé et perspectives

La norme FIDO2 et le W3C ont réussi à augmenter la sécurité de l’authentification pour les services et applications Internet. La gestion automatisée des clés par l’authentificateur élimine le besoin d’une administration fastidieuse. Le protocole CTAP2 autorise les authentificateurs intégrés et externes, qui peuvent être adressés via les interfaces USB, NFC et BLE. Ainsi, le secret ne quitte jamais l’authentificateur.

Toutefois, la norme FIDO2 est en constante évolution :

• L’attestation d’entreprise (EA) permet de lier un authentifiant à un compte à l’aide d’un identifiant persistant. Ce que vous connaissez peut-être des cartes à puce. D’ailleurs, l’EA est conçue pour les environnements où une relation de confiance existe entre les appareils et la partie utilisatrice. Car la norme de confidentialité FIDO exige « qu’un appareil FIDO n’ait pas d’identifiant global visible sur les sites Web ».
• CTAP 2.1 permet la gestion des clés résidentes sur un authentificateur. Cela signifie que vous pouvez
  • gérer votre code PIN,
  • afficher les informations d’identification à découvrir,
  • ajouter ou supprimer des empreintes digitales et réinitialiser l’authentificateur via un navigateur, un panneau de configuration du système d’exploitation, une application ou un outil CLI. En outre, CTAP 2.1 permet de toujours demander une vérification de l’utilisateur sur l’authentificateur, même si la partie utilisatrice ne le demande pas.

Ainsi, la prochaine partie de cette série en deux parties portera sur la façon :

• de planifier,
• de configurer
• d’auditer l’authentification sans mot de passe dans Azure AD.