Ligne directrice du gouvernement du Canada (GC) sur l’authentification multifactorielle (AMF) : Recommandations techniques relatives aux authentifiants utilisés pour l’AMF dans le domaine opérationnel du GC

2.3.1 Résistance à l’hameçonnage (usurpation d’identité du vérificateur)

Il existe de nombreuses définitions du terme « hameçonnage ». Certaines définitions sont très étroites et se concentrent sur des types d’attaques particuliers, tandis que d’autres sont plus vagues. En général, l’hameçonnage est une tentative par un auteur de menaces de tromper un utilisateur pour qu’il révèle des renseignements sensibles comme des mots de passe ou des numéros de compte bancaire ou pour qu’il fasse quelque chose qu’il ne devrait pas faire, comme cliquer sur un lien malveillant qui télécharge un maliciel sur son dispositif.

Dans le contexte de l’authentification, la résistance à l’hameçonnage se définit comme la capacité du protocole d’authentification de détecter les secrets d’authentification et les résultats valides de l’authentifiant et d’empêcher leur divulgation à une fausse PC, indépendamment du niveau de vigilance de l’utilisateur^{Note de bas de page 18}. Plus particulièrement, les authentifiants résistants à l’hameçonnage offrent une protection robuste contre un type d’attaque d’interception connu sous le nom d’usurpation d’identité du vérificateur. Ce type d’attaque consiste à attirer l’utilisateur vers un faux site Web placé entre l’utilisateur et le vérificateur ou la PC légitime^{Note de bas de page 19}. L’auteur de menaces se fait passer pour le site Web du vérificateur légitime auprès de l’utilisateur, et pour l’utilisateur auprès du vérificateur légitime, afin d’obtenir un accès non autorisé au compte de l’utilisateur ou aux ressources auxquelles l’utilisateur tente d’accéder. La protection contre l’usurpation d’identité du vérificateur est assurée par la liaison du canal ou la liaison du nom du vérificateur.

Veuillez noter que les authentifiants résistants à l’hameçonnage utilisent le chiffrement asymétrique pour résister à l’usurpation d’identité du vérificateur. Les authentifiants qui exigent que l’utilisateur saisisse manuellement les données d’authentification, comme les mots de passe, les authentifiants HB avec saisie de numéro ou les authentifiants MPU, ne résistent pas à l’usurpation d’identité du vérificateur, puisque les données d’authentification ne sont pas liées à la session qui est en cours d’authentification.

Au niveau AAL3/LoA 4, au moins un des authentifiants doit être résistant à l’hameçonnage. Il est également fortement recommandé qu’au moins un des authentifiants AAL2/LoA 3 soit résistant à l’hameçonnage. Cependant, certains authentifiants et certaines combinaisons d’authentifiants autorisés au niveau AAL2/LoA 3 ne sont pas intrinsèquement résistants à l’hameçonnage. Il faut alors mettre en œuvre des mesures de sécurité compensatoires dans le cadre du processus d’authentification afin d’atténuer le risque de réussite des attaques par hameçonnage^{Note de bas de page 20}. Par exemple, s’assurer que l’utilisateur s’authentifie à partir d’un appareil géré par le GC^{Note de bas de page 21}, vérifier que l’appareil est configuré correctement et détecter les géolocalisations anormales peut contribuer à compenser l’absence d’authentifiants résistants à l’hameçonnage. De plus, la sensibilisation et la formation des utilisateurs constituent d’importantes mesures d’atténuation qui peuvent contribuer à empêcher l’hameçonnage. Veuillez noter que ces exemples ne constituent pas une liste exhaustive. Comme le contexte des menaces évolue, les mesures de sécurité compensatoires doivent elles aussi évoluer, et les ministères doivent donc procéder à une surveillance continue et aux ajustements nécessaires.

Les directives relatives aux authentifiants résistants à l’hameçonnage se résument comme suit :

• AAL1/LoA 2 : aucune précision
• AAL2/LoA 3 : recommandé, sinon des mesures de sécurité supplémentaires doivent être mises en œuvre, comme indiqué ci-dessus
• AAL3/LoA 4 : obligatoire

Autres sources de renseignements sur la résistance à l’hameçonnage [en anglais seulement] :

• Cybersecurity and Infrastructure Security Agency: Implementing Phishing-Resistant MFA
• Office of Management and Budget M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles^{Note de bas de page 22}

2.3.2 Protection des clés cryptographiques

Les authentifiants cryptographiques peuvent utiliser le chiffrement symétrique ou asymétrique et être mis en œuvre de façon logicielle ou matérielle. Dans tous les cas, les clés secrètes (chiffrement symétrique) et les clés privées (chiffrement asymétrique) utilisées durant le processus d’authentification de l’utilisateur doivent être protégées contre toute utilisation, divulgation ou modification non autorisée.

La manière dont les authentifiants cryptographiques protègent les clés cryptographiques dépend de leur type (p. ex., logiciel ou matériel) ainsi que du niveau AAL/LoA où ils sont utilisés. Ces authentifiants peuvent être mis en œuvre de plusieurs façons, notamment au moyen d’un module de plateforme sécurisée (TPM)^{Note de bas de page 23}, d’un élément sécurisé (SE)^{Note de bas de page 24} ou d’un environnement d’exécution de confiance (EEC)^{Note de bas de page 25}.

L’ITSP.30.031 v3 (voir le tableau 6) et la NIST SP 800-63B (voir les sections 5.1.6.1 à 5.1.9.1) fournissent des conseils sur la protection des clés cryptographiques. Les exigences propres à chaque AAL/LoA incluent ce qui suit :

• AAL1/LoA 2 : Les clés cryptographiques peuvent être conservées sur un disque ou un autre support électronique à condition qu’elles soient robustement protégées contre toute divulgation non autorisée au moyen de contrôles limitant l’accès à la clé aux seuls composants logiciels du dispositif nécessitant l’accès^{Note de bas de page 26}.
• AAL2/LoA 3 : Les clés de signature privée appropriées pour TPM, ES ou EEC doivent être générées sur le TPM, l’ES ou l’EEC et ne doivent pas être exportées^{Note de bas de page 27}. Toutes les opérations de chiffrement du processus d’authentification de l’utilisateur doivent être effectuées à l’intérieur des limites du TPM, de l’ES ou de l’EEC. À ce niveau, il faut également suivre les directives ci-dessous.
  • Les TPM logiciels comme définis par le Trusted Computing Group (voir l’annexe C) ne doivent pas être utilisés et, s’ils sont pris en charge par la plateforme informatique ou l’appareil mobile, ils doivent être désactivés.
  • Les authentifiants cryptographiques logiciels MF qui conservent les clés cryptographiques sur un disque ou un autre support électronique ne sont pas autorisés à partir du niveau AAL2/LoA 3.
  • Il est recommandé que les authentifiants logiciels MPU 1F ou MF utilisés au niveau AAL2/LoA 3 ou supérieur soient exécutés sur un dispositif matériel comme un appareil mobile géré par le GC (téléphone intelligent), physiquement séparé de la plateforme informatique générale.
• AAL3/LoA 4 : Du matériel dédié distinct, comme un TPM discret (voir l’annexe C) ou un ES intégré, est nécessaire. Les clés cryptographiques doivent être générées et conservées de manière sécurisée sur le matériel dédié et ne doivent pas être exportables. Toutes les opérations cryptographiques du processus d’authentification de l’utilisateur doivent être effectuées à l’intérieur des limites du matériel dédié. À ce niveau, il faut également suivre les directives ci-dessous.
  • Des authentifiants matériels indépendants de la plateforme et dédiés à la fonction d’authentification sont nécessaires (p. ex., authentifiant itinérant FIDO2 ou carte à puce basée sur l’ICP)^{Note de bas de page 28}
  • Le facteur d’activation utilisé pour déverrouiller ou activer un authentifiant cryptographique matériel MF, comme une carte à puce basée sur l’ICP, doit être communiqué de manière sécurisée, soit par un chemin de confiance (ne passe pas par le système d’exploitation de la plateforme informatique), soit par la saisie directe du facteur d’activation sur la carte à puce ou le lecteur de cartes (p. ex., lecteur d’empreintes digitales sur la carte ou le lecteur de cartes).

En outre, pour les authentifiants MF, chaque opération d’authentification nécessite la saisie du facteur d’activation connexe pour déverrouiller ou activer l’authentifiant. La soumission du facteur d’activation doit être une opération distincte du déverrouillage du dispositif hôte (p. ex., plateforme informatique ou téléphone intelligent), même si le facteur d’activation utilisé pour déverrouiller le dispositif hôte peut être utilisé dans l’opération d’authentification^{Note de bas de page 29}.

Les exigences de validation des modules cryptographiques sont décrites dans la section 2.3.3 ci-dessous.

2.3.3 Validation des modules cryptographiques

Comme l’indiquent l’ITSP.30.031 v3 et la NIST SP 800-63B, les modules cryptographiques doivent être validés pour répondre aux exigences de la norme FIPS (Federal Information Processing Standard) 140^{Note de bas de page 30} :

• Les authentifiants cryptographiques utilisés au niveau AAL2/LoA 3 doivent être validés au niveau 1 de la FIPS 140 ou à un niveau supérieur.
• Les authentifiants cryptographiques matériels 1F utilisés conjointement avec un autre authentifiant AAL3/LoA4 doivent être validés au niveau 1 de la FIPS 140 ou à un niveau supérieur dans l’ensemble, avec au minimum une sécurité physique de niveau 3.
• Les authentifiants MF AAL3/LoA 4 doivent être des modules cryptographiques matériels validés au niveau 2 de la FIPS 140 ou à un niveau supérieur, avec au minimum une sécurité physique de niveau 3.

Nota : Il n’y a pas de stipulation au niveau AAL1/LoA 2 pour les authentifiants. Voir la section 4.1.2 de la NIST SP 800-63B pour connaître les exigences relatives aux vérificateurs.

Les authentifiants cryptographiques doivent fonctionner seulement en mode FIPS. Seuls les algorithmes cryptographiques recommandés dans l’ITSP.40.111 doivent être utilisés, et tous les protocoles de sécurité pertinents doivent être configurés comme recommandé dans l’ITSP.40.062.

2.3.4 Résistance à l’interception (attaque de l’intercepteur)

L’interception^{Note de bas de page 31} est une attaque par laquelle l’auteur de menaces s’immisce entre deux parties communicantes afin d’intercepter ou de modifier les données qui circulent entre elles. Dans le contexte de l’authentification, l’auteur de menaces s’immisce entre l’utilisateur et le fournisseur de justificatifs d’identité (FJI) au moment de l’inscription, ou entre l’utilisateur et le vérificateur au moment de la liaison de l’authentifiant^{Note de bas de page 32}.

Comme l’indiquent l’ITSP.30.031 v3 et la NIST SP 800-63B, la communication entre l’utilisateur et le vérificateur doit se faire par un canal protégé authentifié (TLS, etc.) pour assurer la confidentialité des données d’authentification et la résistance aux interceptions au niveau AAL1/LoA 2 et aux niveaux supérieurs. Cependant, le niveau de résistance à l’interception peut varier (voir à la description ci‑dessous).

Un protocole est considéré comme ayant une faible résistance aux attaques d’interception lorsqu’il dispose d’un mécanisme qui permet à l’utilisateur de savoir s’il interagit avec un vérificateur ou une PC légitime, mais qui fait tout de même courir le risque à l’utilisateur non vigilant de révéler ses données d’authentification à une partie non autorisée, qui les utiliserait ensuite pour usurper l’identité de l’utilisateur auprès du vérificateur ou de la PC légitime. Par exemple, l’envoi d’un mot de passe par TLS authentifié par un serveur a une faible résistance aux interceptions. Le navigateur Web permet à l’utilisateur de vérifier l’identité du vérificateur ou de la PC, mais si l’utilisateur n’est pas suffisamment vigilant, le mot de passe peut quand même être révélé à une personne non autorisée. Un protocole est dit fortement résistant aux tentatives d’interception s’il ne dépend pas de la vigilance de l’utilisateur pour empêcher la divulgation des données d’authentification à une partie non autorisée qui usurpe l’identité du vérificateur ou de la PC. Un exemple de ce type de protocole est le TLS authentifié par le client, dans lequel le navigateur et le serveur Web s’authentifient mutuellement à l’aide de l’ICP. Les protocoles d’authentification qui peuvent détecter l’usurpation d’identité du vérificateur, comme mentionné dans la section 2.3.1, sont très résistants aux tentatives d’interception.

Conseils particuliers en matière de résistance aux interceptions :

• AAL1/LoA 2 : une faible résistance est requise au minimum
• AAL2/LoA 3 : une faible résistance est requise au minimum; veuillez noter qu’au moins un authentifiant résistant à l’hameçonnage est recommandé, comme indiqué à la section 2.3.1
• AAL3/LoA 4 : une forte résistance est requise et au moins un authentifiant résistant à l’hameçonnage est requis, comme indiqué à la section 2.3.1

2.3.5 Résistance à la réinsertion

On considère qu’un processus d’authentification résiste aux attaques par réinsertion s’il est pratiquement impossible de réussir une authentification en enregistrant puis en réinsérant le message d’une authentification antérieure. Les protocoles qui font appel aux nonces ou aux défis pour prouver la « récence » de la transaction résistent aux attaques par réinsertion. Les authentifiants MPU, les authentifiants cryptographiques et les secrets matriciels sont des exemples d’authentifiants résistants à la réinsertion. Les secrets mémorisés ne sont pas considérés comme résistants à la réinsertion parce que les données d’authentification (le secret lui‑même) sont fournies à chaque authentification^{Note de bas de page 33}.

Les conseils relatifs à la résistance à la réinsertion fournis dans l’ITSP.30.031 v3 et la NIST SP 800-63B sont adoptés (à l’exception des conseils modifiés pour le niveau AAL1/LoA 2) comme suit :

• AAL1/LoA 2 : recommandé^{Note de bas de page 34}
• AAL2/LoA 3 : obligatoire
• AAL3/LoA 4 : obligatoire

2.3.6 Intention d’authentification

Les plus récentes directives de la NIST SP 800-63B-4 (deuxième version publique) décrivent l’intention d’authentification comme suit :

Un processus d’authentification est intentionnel s’il exige du requérant qu’il réponde explicitement à chaque demande d’authentification ou de réauthentification. Le but de l’intention d’authentification est de rendre plus difficile l’utilisation d’authentifiants (p. ex., des authentifiants cryptographiques MF) à l’insu du requérant, par exemple par un maliciel au point terminal. L’authentifiant lui-même doit établir l’intention d’authentification, bien que les authentifiants cryptographiques MF puissent établir l’intention en réintroduisant le facteur d’activation de l’authentifiant.

L’intention d’authentification peut être établie de plusieurs façons. Les processus d’authentification qui requièrent l’intervention du requérant peuvent être utilisés pour prouver l’intention (p. ex., un requérant qui saisit les données produites par un authentifiant MPU). Les authentifiants cryptographiques qui exigent une action de l’utilisateur pour chaque opération d’authentification ou de réauthentification peuvent également être utilisés pour établir l’intention (p. ex., appuyer sur un bouton ou réinsérer l’authentifiant).

La présentation de caractéristiques biométriques n’établit pas toujours l’intention d’authentification. Par exemple, l’utilisation de la caméra frontale d’un téléphone portable pour capturer des données biométriques faciales ne constitue pas une intention, puisqu’on peut raisonnablement s’attendre à ce que la caméra capture une image du visage lorsque l’appareil est utilisé à d’autres fins que l’authentification. Dans ces scénarios, un mécanisme explicite (p. ex., appuyer sur un bouton logiciel ou physique) doit être fourni pour établir l’intention d’authentification.

Les directives du NIST en matière d’intention d’authentification sont adoptées comme suit :

• AAL1/LoA 2 : non obligatoire
• AAL2/LoA 3 : recommandé
• AAL3/LoA 4 : obligatoire

Veuillez noter que si un authentifiant cryptographique matériel 1F est utilisé conjointement avec un mot de passe robuste au niveau AAL3/LoA 4, il faut établir l’intention d’authentification en exigeant une saisie physique de la part de l’utilisateur (p. ex., appuyer sur un bouton) afin que l’authentifiant fonctionne. Le fait d’appuyer sur le bouton pour confirmer la présence physique ne constitue pas un facteur d’authentification supplémentaire.

2.3.7 Considérations propres à FIDO

Un aperçu des spécifications propres à la FIDO Alliance et de la recommandation WebAuthn du W3C, y compris certains détails techniques pertinents pour la présente sous-section, figure à l’annexe B. Le lecteur devrait se familiariser avec la terminologie et les concepts décrits dans l’annexe B avant de poursuivre la lecture de la présente sous-section.

2.3.8 Résumé des directives de mise en œuvre

Le tableau 2.4 présente un résumé des recommandations formulées dans les sous‑sections précédentes. Veuillez noter qu’il s’agit d’un résumé abrégé; la section correspondante doit être consultée pour plus de détails. Notez également qu’il n’y a aucune précision concernant les authentifiants LoA 1 puisqu’ils ne sont pas autorisés.

2.4.1 Liaison des authentifiants

Il est essentiel de lier les authentifiants à une identité particulière pour garantir que le bon utilisateur accède aux bonnes ressources (p. ex., comptes, applications, services et information). La liaison d’un utilisateur à un ou à plusieurs authentifiants se fait au cours de la procédure d’inscription de l’utilisateur, mais on peut aussi le faire ultérieurement en utilisant les authentifiants déjà émis pour lier de nouveaux authentifiants.

La section 6.1 de la NIST SP 800-63B contient des directives relatives à la liaison des authentifiants. La section 6.1.2.1 de la NIST SP 800-63B traite de l’utilisation d’authentifiants à un niveau d’assurance donné pour lier d’autres authentifiants à un LoA identique ou inférieur. La section 6.1.2.2 de la NIST SP 800-63B traite de la possibilité d’utiliser un authentifiant 1F pour ajouter un autre type d’authentifiant 2F, ce qui peut faire passer le niveau d’assurance de AAL1/LoA 2 à AAL2/LoA 3 (selon les authentifiants). Par exemple, un utilisateur peut s’authentifier auprès d’un service Web à l’aide d’un ID utilisateur et d’un mot de passe préalablement enregistrés, puis inscrire un authentifiant de type quelque chose que vous possédez (p. ex., un authentifiant FIDO) qui sera désormais utilisé comme deuxième facteur^{Note de bas de page 38}.

L’utilisation d’un ID utilisateur et d’un mot de passe existants pour lier un authentifiant 2F supplémentaire ne garantit pas que le compte de l’utilisateur n’a pas déjà été compromis. L’utilisateur qui tente d’inscrire un authentifiant supplémentaire peut très bien être un imposteur. Bien que le NIST recommande qu’une notification de l’événement soit envoyée à l’utilisateur par une méthode HB (p. ex., compte de courrier électronique inscrit), cette mesure ne suffit pas nécessairement à détecter la compromission d’un compte. Il faut donc prendre des mesures supplémentaires pour s’assurer que l’utilisateur est bien celui qu’il prétend être. Cela est possible si le deuxième facteur est déjà lié à l’utilisateur (p. ex., un téléphone intelligent géré par le GC et remis à l’utilisateur doit être utilisé comme deuxième facteur). Si le deuxième authentifiant n’a pas été préalablement lié à l’utilisateur, d’autres méthodes doivent être employées. Par exemple, il est possible d’utiliser la vérification d’un code d’accès unique envoyé ou fourni au bon utilisateur par un moyen fiable HB pour augmenter le niveau de confiance selon lequel l’utilisateur qui réalise l’inscription est bien celui qu’il prétend être. Le mécanisme HB doit être limité dans le temps (p. ex., expiration dans les 10 jours ouvrables).

2.4.2 Récupération des authentifiants

Des mécanismes appropriés de récupération des authentifiants doivent être mis en place pour rétablir l’accès de l’utilisateur en cas de perte, de vol ou de détérioration d’un authentifiant existant. Les méthodes de récupération varient en fonction du type d’authentifiant, mais dans tous les cas, elles doivent être au moins aussi robustes et sûres que la ou les méthodes utilisées pour établir la liaison d’origine avec l’authentifiant. La section 6.1.2.3 de la NIST SP 800-63B fournit des directives supplémentaires concernant la récupération des authentifiants. Les utilisateurs doivent également être informés de leurs responsabilités, notamment en ce qui concerne le signalement immédiat des authentifiants perdus ou volés (voir la section 6.2 de la NIST SP 800-63B pour de plus amples renseignements).

Veuillez noter que d’autres considérations relatives à la gestion du cycle de vie des authentifiants doivent également être prises en compte, notamment le renouvellement (section 6.1.4 de la NIST SP 800-63B), la suspension (section 6.2 de la NIST SP 800-63B), l’expiration (section 6.3 de la NIST SP 800-63B) et la révocation (section 6.4 de la NIST SP 800-63B).

2.4.3 Réauthentification

La réauthentification sert à déterminer si l’utilisateur précédemment authentifié est toujours présent dans une session donnée, soit parce qu’il est inactif, soit après un certain laps de temps. Les lignes directrices des Digital Identity Guidelines du NIST (voir les sections 4.1.3, 4.2.3, 4.3.3 et 7.2 de la NIST SP 800-63B) décrivent les exigences en matière de réauthentification à chaque AAL. Ces exigences sont adoptées avec les précisions supplémentaires suivantes^{Note de bas de page 39} :

• AAL1/LoA 2 : La réauthentification est requise au moins tous les 30 jours, que l’utilisateur soit actif ou non; les PC sont libres de déterminer leurs propres exigences en matière de délai d’inactivité, s’il y a lieu.
• AAL2/LoA 3 : La réauthentification est requise au moins toutes les 12 heures, que l’utilisateur soit actif ou non; la réauthentification est également requise après 30 minutes d’inactivité de l’utilisateur (bien que l’utilisateur puisse être invité à confirmer qu’il est toujours présent avant que le délai d’inactivité ne soit écoulé^{Note de bas de page 40}); la réauthentification d’une session qui n’a pas encore atteint sa limite de temporisation peut se faire au moyen d’un secret mémorisé ou de données biométriques conjointement avec le secret de session encore valide.
• AAL3/LoA 4 : La réauthentification est requise au moins toutes les 12 heures, que l’utilisateur soit actif ou non; la réauthentification est également requise après 15 minutes d’inactivité (bien que l’utilisateur puisse être invité à confirmer qu’il est toujours présent avant que le délai d’inactivité ne soit écoulé^{Note de bas de page 41}); la réauthentification nécessite une AMF.

Si l’utilisateur ne se réauthentifie pas avec succès dans la minute qui suit la demande de réauthentification, la session est interrompue. Si la réauthentification est réussie, les limites de temporisation de la session et le délai d’inactivité de l’utilisateur sont réinitialisés.

Le NIST souligne (voir la NIST SP 800:63 Digital Identity Guidelines – Frequently Asked Questions) qu’il y a d’autres moyens de s’assurer que le dispositif n’est pas utilisé par une partie non autorisée, comme le verrouillage au niveau du système d’exploitation et l’authentification locale obligatoire pour que l’utilisateur puisse déverrouiller l’appareil. Il n’est pas toujours possible pour une PC de connaître l’état du dispositif de l’utilisateur et, dans ce cas, les limites de temporisation constituent une mesure de contrôle raisonnable. Si la PC sait que l’utilisateur utilise un système géré qui exige le verrouillage de l’écran selon les stratégies programmées, elle peut être en mesure d’assouplir les limites de temporisation du système en question. Une PC pourrait aussi gérer la plupart des interactions de l’utilisateur à un certain AAL et passer à un AAL supérieur pour les opérations de nature délicate. Dans un tel cas, la session à privilèges limités pourrait durer beaucoup plus longtemps que celle à privilèges plus élevés. L’adoption de mesures compensatoires comme celles-ci fait partie du processus d’évaluation des risques.

[Nota : Si la section 7.2.1 de la NIST SP 800-63B traite de l’exigence pour une PC de transmettre l’âge maximal d’authentification à un fournisseur d’identité ou de justificatifs (FID/FJI) dans un scénario fédéré, elle n’aborde pas la possibilité de forcer la réauthentification, qui est prise en charge par les protocoles de fédération SAML et OpenID Connect. Les PC peuvent utiliser ces derniers pour forcer la réauthentification quel que soit l’état de la session authentifiée entre l’utilisateur et le FID. Heureusement, l’ébauche de la version 4 des Digital Identity Guidelines du NIST a ajouté la notion d’authentification forcée à la section 5.6 de la SP-800-63C-4.]

2.4.4 Authentification renforcée

L’authentification renforcée, qu’il ne faut pas confondre avec la réauthentification décrite dans la sous-section précédente, est utilisée lorsqu’il est nécessaire d’élever le LoA d’une session donnée (p. ex., l’utilisateur est authentifié au LoA 2 et demande l’accès à une ressource qui nécessite une authentification LoA 3). Les PC doivent être en mesure d’inviter l’utilisateur à s’authentifier au LoA supérieur (ou de le rediriger vers un FID dans un environnement fédéré) afin de renforcer l’authentification en cas de besoin.

2.4.5 Authentification centralisée

Comme indiqué dans le document Considérations et stratégie d’authentification multifactorielle des services organisationnels de TI du GC, une solution organisationnelle centralisée d’authentification, qui peut prendre en charge plusieurs méthodes d’AMF fondées sur des normes ouvertes et acceptées par l’industrie, est un élément essentiel de la stratégie globale de gestion de l’identité, des justificatifs d’identité et de l’accès (GIJIA) du GC. L’authentification doit être centralisée dans toute la mesure du possible pour alléger le fardeau de la prise en charge de plusieurs mécanismes d’authentification des applications et des services individuels, prendre en charge l’identification unique et permettre la constitution d’une fédération. L’authentification centralisée facilite également le contrôle d’accès continu en fonction du risque, comme nous le verrons dans la sous-section suivante.

2.4.6 Contrôle d’accès en fonction du risque

Le contrôle d’accès en fonction du risque (ou simplement le contrôle d’accès adaptatif) est un modèle de contrôle d’accès dynamique qui utilise de multiples indicateurs de sécurité pour éclairer la prise de décisions entourant le contrôle d’accès, comme la force de la méthode d’authentification de l’utilisateur, le niveau d’assurance de la session établie entre le système et l’utilisateur, la géolocalisation de l’utilisateur et d’autres considérations^{Note de bas de page 42}.

Même s’il ne s’agit pas d’une représentation exhaustive, la Figure 2.3 aide à comprendre le concept d’un modèle de contrôle d’accès en fonction du risque. Comme l’illustre le schéma, l’authentification de l’utilisateur n’est que l’une des nombreuses considérations qui motivent les décisions en matière de contrôle d’accès. Par exemple, l’attestation du dispositif est un complément important de l’authentification de l’utilisateur, puisqu’il s’agit d’une façon fiable et sûre de vérifier l’identité et l’état du dispositif utilisé pour accéder aux ressources du GC.

Les décisions en matière de contrôle d’accès doivent être dynamiques et s’adapter aux changements de politique et à l’évaluation des menaces et des risques en temps réel, comme l’illustrent les données d’entrée politiques et télémétriques dans la Figure 2.3. Ce modèle constitue le fondement même d’un contrôle d’accès continu en fonction du risque en application des principes de la vérification systématique^{Note de bas de page 43}. Il permet également de mettre en place des mesures compensatoires de manière à compenser les faiblesses dans un domaine par d’autres domaines et d’éclairer le processus global de prise de décisions en matière de contrôle d’accès.

Figure 2.3 - version textuelle

Illustration conceptuelle d’un modèle de contrôle d’accès en fonction du risque.

Le centre de l’illustration est occupé par un encadré intitulé « Contrôle d’accès en fonction du risque ». Les diverses entrées du modèle se trouvent à gauche et en haut de l’encadré, alors que les résultats sont à sa droite.

De haut en bas, les entrées du côté gauche sont les suivantes :

• Authentification de l’utilisateur
• Rôle et attributs de l’utilisateur
• Authentification du dispositif
• Attestation du dispositif
• Ressource cible
• Date et heure
• Géolocalisation de l’utilisateur

De gauche à droite, les entrées en haut de l’encadré sont les suivantes :

• Renseignements sur les politiques
• Renseignements sur les menaces
• Renseignements sur les vulnérabilités
• Gestion de l’information et des événements de sécurité
• Visibilité et analyse
• Analyse du comportement de l’utilisateur et de l’entité

De haut en bas, les résultats à droite de l’encadré sont les suivants :

• Accorder le plein accès
• Accorder un accès restreint
• Refuser l’accès

2.4.7 Utilisation de la biométrie

Comme indiqué dans les Digital Identity Guidelines du NIST (voir la section 5.2.3 de la NIST SP 800-63B), « la biométrie DOIT être utilisée seulement dans le cadre d’une authentification multifactorielle avec un authentifiant physique (quelque chose que vous possédez). » [traduction] Par conséquent, la biométrie ne peut être utilisée comme second facteur qu’en combinaison avec quelque chose que l’utilisateur possède, comme un authentifiant cryptographique matériel MF doté d’un capteur intégré (p. ex., un lecteur d’empreintes digitales). Lorsque la biométrie est utilisée comme second facteur, certaines exigences s’appliquent concernant le taux de fausses correspondances et les technologies de détection des attaques de présentation (p. ex., détection du caractère vivant).

Il faut aussi noter que certaines technologies biométriques sont conçues dans un souci de commodité pour l’utilisateur plutôt que de sécurité et, par conséquent, peuvent ne pas convenir au niveau d’assurance requis. Il faut donc être prudent lors de l’utilisation de la biométrie comme facteur d’authentification. Voir la section 5.2.3 de la NIST SP 800-63B pour de plus amples renseignements.

2.4.8 Prenez vos authentifiants personnels (PAP)

Comme indiqué précédemment dans la section 2.2, tous les dispositifs utilisés pour accéder aux ressources internes du GC doivent être gérés par le GC. Cela inclut les appareils mobiles comme les téléphones intelligents. Il est cependant admis que certains ministères n’ont pas d’autre choix que de mettre en œuvre l’AMF sur des appareils personnels, en particulier pour les entrepreneurs. Bien que l’AMF ajoute une mesure de sécurité supplémentaire par rapport à une solution 1F basée seulement sur un ID utilisateur et un mot de passe, un appareil mobile non géré par le GC est plus susceptible d’être compromis qu’un appareil géré par le GC. Toutefois, la gestion des appareils mobiles, la gestion unifiée des points terminaux (UEM) ou la gestion des applications mobiles pourraient potentiellement être utilisées pour gérer les données et les applications ministérielles sur les appareils mobiles personnels, ce qui réduirait considérablement le risque par rapport aux appareils non gérés. Utilisé conjointement avec une plateforme informatique gérée par le GC, ce système pourrait éventuellement faire passer le niveau d’assurance de LoA 2 à LoA 3, pourvu que les mesures de sécurité et les pratiques exemplaires appropriées soient en place (p. ex., la séparation entre l’espace de travail et l’espace personnel est maintenue en permanence, les dispositifs débridés et compromis sont détectés, etc.). Voir Sécurité des appareils des utilisateurs finaux pour les modèles de déploiement Prenez vos appareils personnels (PAP) – ITSM.70.003 pour de plus amples renseignements.

Dans tous les cas, il est préférable d’utiliser les méthodes d’authentification les plus robustes possibles. Par exemple, l’utilisation de messages texte (SMS) est fortement déconseillée. Il vaut mieux utiliser des mécanismes plus sécuritaires comme la notification poussée avec saisie de numéro ou une application MPU. L’utilisation d’authentifiants résistants à l’hameçonnage, comme les clés d’accès FIDO2 liées à un appareil et conservées sur l’appareil mobile de l’utilisateur ou une clé de sécurité FIDO2 appartenant à l’utilisateur (l’une ou l’autre pouvant être utilisée pour s’authentifier avec WebAuthn sur une plateforme informatique gérée par le GC), peut également être une option. Si cette méthode est adoptée, il faut aussi utiliser l’attestation pour vérifier que l’authentifiant répond aux exigences minimales à remplir pour accéder à la ressource cible. Il convient également de noter que l’utilisation d’un dispositif personnel en tant qu’authentifiant ne doit pas créer involontairement la possibilité d’accéder aux ressources internes du GC à l’aide de ce dispositif. Plus particulièrement, les authentifiants « Prenez vos authentifiants personnels » (PAP) devraient être utilisés en combinaison avec une plateforme informatique gérée par le GC.

Les cas d’utilisation et la nécessité d’avoir des mesures d’atténuation des risques supplémentaires devraient être pris en compte avant l’adoption d’une méthode PAP. Les considérations relatives à la protection de la vie privée doivent également être évaluées.

B-3.1 Clés d’accès (synchronisées et liées à un appareil)

La signification du terme clé d’accès a évolué au cours des dernières années. Certains fournisseurs ont introduit ce terme comme synonyme pour décrire des justificatifs multidispositifs que l’on peut sauvegarder et copier dans plus d’un appareil. En fait, le terme clé d’accès s’applique tant aux justificatifs multidispositifs que monodispositifs (voir la page Web FIDO Alliance: Passkeys). Autrement dit, « clé d’accès » est un terme générique qui désigne des justificatifs détectables FIDO, qu’ils soient multidispositifs (copiables) ou monodispositifs (non copiables). La documentation la plus récente utilise les termes clé d’accès synchronisée et clé d’accès liée à un appareil (par exemple, voir le document FIDO Deploying Passkeys in the Enterprise: Introduction).

La synchronisation des clés d’accès est une approche qui permet de sauvegarder et de synchroniser (copier) les clés privées utilisées pour authentifier l’utilisateur de plusieurs appareils, ce qui élimine (ou réduit) la nécessité d’enregistrer plusieurs justificatifs auprès d’un même service Web en ligne. Les clés d’accès synchronisées prennent également en charge la synchronisation transparente des justificatifs avec de nouveaux appareils. Cela améliore l’expérience de récupération de l’authentifiant (voir la section Récupération ci‑dessous) et permet une authentification transparente des utilisateurs qui utilisent plusieurs appareils pour accéder aux mêmes services Web en ligne. Cependant, il y a des compromis à faire entre l’aspect pratique des clés d’accès synchronisées et les problèmes de sécurité qu’elles pourraient créer.

Le National Institute of Standards and Technology (NIST) des États-Unis a récemment publié de nouvelles directives provisoires sur les authentifiants synchronisés (ou clés d’accès synchronisées). Ces directives provisoires font état des exigences en matière de sécurité à respecter pour que ces authentifiants puissent servir avec le niveau d’assurance (LoA) 3 ou le niveau d’assurance d’authentification (AAL) 2. Cela pourrait bien changer la donne en améliorant l’expérience utilisateur sans sacrifier la sécurité. Il faut cependant savoir que certains produits ne prennent en charge que les clés d’accès liées à un appareil afin de satisfaire à des exigences d’assurance plus strictes (par exemple, la mise en œuvre de la norme FIDO2 de la série 5 de Yubikey).

Les livres blancs de FIDO Alliance, intitulés FIDO Authentication for Moderate Assurance Use Cases et High Assurance Enterprise FIDO Authentication, apportent des précisions sur les différences entre clé d’accès synchronisée et clé d’accès liée à un appareil en termes d’avantages et d’inconvénients.

B-3.2 Modalité de stockage des justificatifs

Il semble que des renseignements contradictoires (ou trompeurs) soient publiés en ligne au sujet de l’endroit où sont stockées les clés privées servant à authentifier les utilisateurs. Par exemple, le site Web de FIDO Alliance lui-même (voir la page FIDO Authentication) précise textuellement que les justificatifs de connexion FIDO2 chiffrés sont uniques dans chaque site Web, ne quittent jamais l’appareil de l’utilisateur et ne sont jamais stockés sur un serveur. Toutefois, il ressort clairement de la lecture des spécifications de FIDO2 (qui, par définition, font autorité) que les clés de signature privées servant à l’authentification peuvent être stockées sur l’appareil ou sur le serveur (sous forme chiffrée). En particulier, voir les sections 6.2, Authenticator Taxonomy et 6.2.2, Credential Storage Modality de la norme WebAuthn, ainsi que les définitions connexes des justificatifs détectables côté client et côté service^{Note de bas de page 61}. Bien que l’U2F ne soit pas nécessairement considéré comme faisant partie de FIDO2, consultez également la section 7 de l’aperçu de l’authentification de second facteur (U2F) et la section 4.3 de la norme en matière de formats de messages bruts U2F de FIDO Alliance (par exemple, « les jetons U2F peuvent encapsuler la clé privée générée et l’identifiant de l’application à laquelle la clé est destinée, et présenter le tout comme le pseudonyme de la clé »).

Bien qu’il soit admis que certains produits ne prennent en charge que des justificatifs détectables ou des solutions particulières, comme l’authentification sans mot de passe, les déclarations générales comme « la clé privée ne quitte jamais l’appareil » ne sont pas tout à fait exactes lorsqu’elles ont trait aux spécifications de FIDO Alliance et à la norme WebAuthn recommandée par le W3C. Il s’agit également d’une appellation erronée en ce qui concerne les clés d’accès synchronisées (voir ci-dessous pour en savoir plus).

Le principal avantage du stockage des clés privées sur le serveur est de diminuer la quantité de mémoire que doit posséder l’appareil, ce qui réduit le coût de l’authentifiant et permet théoriquement de prendre en charge un nombre illimité de paires de clés. Toutefois, la protection des clés privées stockées sur le serveur peut poser problème et dépend de la mise en œuvre adéquate d’un algorithme de chiffrement approuvé et des longueurs de clé connexes. Par exemple, Yubico utilise l’algorithme AES-256 en mode CCM (pour l’authentification de second facteur U2F, voir la page Web Key Generation). En outre, le nombre de clés d’accès pouvant être stockées sur les clés de sécurité FIDO2 ne cesse d’augmenter. Ainsi, une clé Yubikey 5 FIDO2 qui acceptait 25 clés d’accès liées à un appareil peut maintenant en accepter 100. De plus, Google a récemment lancé de nouvelles clés de sécurité Titan qui peuvent stocker plus de 250 clés d’accès (voir l’article intitulé The latest Titan Security Key is in the Google Store).

À noter également que la tendance actuelle de l’industrie semble s’orienter vers les clés d’accès qui sont, par définition, des justificatifs détectables et qui ne peuvent donc pas être stockées sur le serveur (voir le tableau B2 pour plus de contexte). Néanmoins, la modalité de stockage des justificatifs côté serveur ne doit pas être complètement écartée, puisqu’il existe des produits qui la mettent en œuvre.

B-3.3 Récupération

Comme avec toute autre méthode d’authentification, il doit y avoir un moyen de récupérer les authentifiants conformes à la norme FIDO lorsque l’authentifiant principal est égaré, volé ou endommagé. Selon FIDO Alliance (voir le document en ligne intitulé Recommended Account Recovery Practices for FIDO Relying Parties), il est recommandé que chaque utilisateur dispose d’au moins deux authentifiants conformes à la spécification FIDO, dont un authentifiant de secours au cas où il arriverait quelque chose à l’authentifiant principal. Toutefois, cette approche ne convient pas nécessairement au gouvernement du Canada, puisqu’elle entraîne une augmentation des coûts (en raison de la nécessité pour chaque utilisateur d’avoir plusieurs authentifiants), crée une expérience utilisateur négative et oblige les utilisateurs à stocker en toute sécurité leur(s) authentifiant(s) de secours. Par conséquent, d’autres méthodes de récupération doivent être explorées (par exemple, la mise en œuvre d’une approche d’authentification centralisée qui permettrait de prendre en charge d’autres approches appropriées). Les clés d’accès synchronisées (dont il a été question plus haut) ou les processus hybrides d’assurance élevée peuvent également constituer des solutions de rechange.

B-3.4 Attestation d’entreprise

Au départ, les spécifications de FIDO Alliance ont été conçues pour un marché de consommation de masse, à savoir les utilisateurs accédant à des services dans l’Internet. Bien que cela reste un objectif majeur, des ajouts récents à la norme WebAuthn recommandée et à la spécification CTAP introduisent la notion d’« attestation d’entreprise (AE) » afin de rendre les authentifiants FIDO plus adaptés au domaine de l’entreprise. Cependant, la manière dont l’AE fonctionne réellement dans la pratique nécessite une étude plus approfondie.

À l’heure où nous écrivons ces lignes, les clés synchronisées ne permettent pas l’attestation^{Note de bas de page 62}. En effet, la spécification CTAP 2.1 actuelle et la norme WebAuthn de niveau 2 recommandée ne prennent en charge l’attestation que pendant la procédure d’enregistrement. Il n’existe donc aucun moyen de faire valoir une nouvelle déclaration d’attestation au moment de l’authentification à partir d’un autre appareil avec une clé d’accès synchronisée. Toutefois, la prise en charge de cette nouvelle capacité devrait être ajoutée à la spécification CTAP 2.2 et à la norme WebAuthn de niveau 3 recommandée. Il reste à voir ce que cela signifiera dans la pratique et quel sera le niveau de soutien fourni par la communauté des fournisseurs.

Notez également que l’AE a été introduite dans le cadre de FIDO2 et qu’elle n’est pas prise en charge par l’authentification U2F.

Voir les pages Web FIDO TechNotes: The Truth About Attestation et FIDO Attestation White Paper pour en savoir plus sur l’attestation. La page Web Enterprise Attestation apporte des précisions sur l’AE, et plusieurs livres blancs relatifs aux déploiements d’entreprise sont disponibles dans le document en ligne intitulé Learn how FIDO authentication fits into your enterprise environment.