Windows Hello

Cet article décrit la technologie Windows Hello fournie dans le cadre de Windows et explique comment les développeurs peuvent implémenter cette technologie pour protéger leurs applications Windows et leurs services principaux. Il met en évidence des fonctionnalités spécifiques de ces technologies qui aident à atténuer les menaces qui proviennent de l’utilisation des informations d’identification conventionnelles et fournit des conseils sur la conception et le déploiement de ces technologies dans le cadre d’un déploiement de client Windows.

Pour obtenir une procédure pas à pas sur la création d’une application WinUI à l’aide de Windows Hello et du service d’authentification de stockage, consultez les articles relatifs à l’application de connexion Windows Hello et au service de connexion Windows Hello.

Introduction

Une hypothèse fondamentale sur la sécurité des informations est qu’un système peut identifier qui l’utilise. L’identification d’un utilisateur permet au système de décider si l’utilisateur est identifié de manière appropriée (un processus appelé authentification), puis de déterminer ce qu’un utilisateur correctement authentifié doit être en mesure de faire (autorisation). La grande majorité des systèmes informatiques déployés dans le monde dépendent des informations d’identification de l’utilisateur pour prendre des décisions d’authentification et d’autorisation, ce qui signifie que ces systèmes dépendent de mots de passe réutilisables créés par l’utilisateur comme base pour leur sécurité. La maxima fréquemment citée que l’authentification peut impliquer « quelque chose que vous connaissez, quelque chose que vous avez ou quelque chose que vous êtes » met en évidence le problème : un mot de passe réutilisable est un facteur d’authentification tout seul, de sorte que toute personne qui sait que le mot de passe peut emprunter l’identité de l’utilisateur qui le possède.

Problèmes liés aux informations d’identification classiques

Depuis le milieu des années 1960, lorsque Fernando Corbató et son équipe au Massachusetts Institute of Technology ont défendu l’introduction du mot de passe, les utilisateurs et les administrateurs ont dû gérer l’utilisation de mots de passe pour l’authentification et l’autorisation des utilisateurs. Au fil du temps, l’état de l’art pour le stockage de mot de passe et l’utilisation a avancé un peu (avec le hachage sécurisé et le sel, par exemple), mais nous sommes toujours confrontés à deux problèmes. Les mots de passe sont faciles à cloner et ils sont faciles à voler. En outre, les erreurs d’implémentation peuvent les rendre non sécurisées, et les utilisateurs ont du mal à équilibrer la commodité et la sécurité.

Vol d'informations d'identification

Le plus gros risque pour les mots de passe est simple : un attaquant peut les voler facilement. Chaque endroit où un mot de passe est entré, traité ou stocké est vulnérable. Par exemple, un attaquant peut voler une collection de mots de passe ou de hachages à partir d’un serveur d’authentification en effectuant des écoutes sur le trafic réseau vers un serveur d’applications, en implantant des programmes malveillants dans une application ou sur un appareil, en journalisant les séquences de touches d’utilisateur sur un appareil ou en regardant les caractères qu’un utilisateur tape. Il s’agit simplement des méthodes d’attaque les plus courantes.

Un autre risque lié est celui de la relecture des informations d’identification, dans laquelle un attaquant capture des informations d’identification valides par écoute électronique sur un réseau non sécurisé, puis le relecture ultérieurement pour emprunter l’identité d’un utilisateur valide. La plupart des protocoles d’authentification (y compris Kerberos et OAuth) protègent contre les attaques par relecture en incluant un horodatage dans le processus d’échange d’informations d’identification, mais cette tactique protège uniquement le jeton que le système d’authentification émet, et non le mot de passe fourni par l’utilisateur pour obtenir le ticket en premier lieu.

Réutilisation d’informations d’identification

L’approche courante de l’utilisation d’une adresse e-mail, car le nom d’utilisateur complique le problème. Un attaquant qui récupère correctement une paire nom d’utilisateur-mot de passe à partir d’un système compromis peut ensuite essayer cette même paire sur d’autres systèmes. Cette tactique fonctionne étonnamment souvent pour permettre aux attaquants de se lancer à partir d’un système compromis dans d’autres systèmes. L’utilisation d’adresses e-mail en tant que noms d’utilisateur entraîne des problèmes supplémentaires que nous explorerons plus loin dans ce guide.

Résolution des problèmes d’informations d’identification

La résolution des problèmes que posent les mots de passe est difficile. Le renforcement des stratégies de mot de passe seul ne le fera pas ; les utilisateurs peuvent simplement recycler, partager ou écrire des mots de passe. Bien que l’éducation des utilisateurs soit essentielle pour la sécurité de l’authentification, l’éducation seule n’élimine pas le problème non plus.

Windows Hello remplace les mots de passe par une authentification à deux facteurs forte (2FA) en vérifiant les informations d’identification existantes et en créant des informations d’identification spécifiques à l’appareil qu’un mouvement utilisateur biométrique ou basé sur un code confidentiel protège.

Qu’est-ce que Windows Hello ?

Windows Hello est le nom que Microsoft a donné au nouveau système de connexion biométrique intégré à Windows. Parce qu’il est intégré directement dans le système d’exploitation, Windows Hello permet l’identification par reconnaissance faciale ou empreinte digitale pour déverrouiller les appareils des utilisateurs. L’authentification se produit lorsque l’utilisateur fournit son identificateur biométrique unique pour accéder aux informations d’identification spécifiques à l’appareil, ce qui signifie qu’un attaquant qui vole l’appareil ne peut pas se connecter à celui-ci, sauf si cet attaquant a le code confidentiel. Le magasin de certificats sécurisé de Windows protège les données biométriques sur l’appareil. En utilisant Windows Hello pour déverrouiller un appareil, l’utilisateur autorisé accède à toutes ses expériences, applications, données, sites web et services Windows.

L’authentificateur Windows Hello est appelé Hello. Un Hello est unique à la combinaison d’un appareil individuel et d’un utilisateur spécifique. Il n’est pas itinérant sur les appareils, n’est pas partagé avec un serveur ou une application appelante et ne peut pas être facilement extrait d’un appareil. Si plusieurs utilisateurs partagent un appareil, chaque utilisateur doit configurer son propre compte. Chaque compte obtient un Hello unique pour cet appareil. Vous pouvez considérer un Hello comme un jeton que vous pouvez utiliser pour déverrouiller (ou libérer) des informations d’identification stockées. Hello lui-même ne vous authentifie pas auprès d’une application ou d’un service, mais il libère les informations d’identification qui peuvent. En d’autres termes, Hello n’est pas une information d’identification utilisateur, mais il s’agit d’un deuxième facteur pour le processus d’authentification.

Authentification Windows Hello

Windows Hello offre un moyen robuste pour qu’un appareil reconnaisse un utilisateur individuel, ce qui répond à la première partie du chemin entre un utilisateur et un service ou un élément de données demandé. Après que l’appareil ait reconnu l’utilisateur, il doit encore authentifier l’utilisateur avant de déterminer s’il doit accorder l’accès à une ressource demandée. Windows Hello fournit une 2FA forte entièrement intégrée à Windows et remplace les mots de passe réutilisables par la combinaison d’un appareil spécifique et d’un mouvement biométrique ou d’un code confidentiel.

Windows Hello n’est pas seulement un remplacement pour les systèmes 2FA traditionnels, cependant. Il est conceptuellement similaire aux cartes à puce : l’authentification est effectuée à l’aide de primitives de chiffrement au lieu de comparaisons de chaînes, et le matériel de clé de l’utilisateur est sécurisé à l’intérieur du matériel résistant aux falsifications. Windows Hello ne nécessite pas les composants d’infrastructure supplémentaires requis pour le déploiement de cartes à puce. En particulier, vous n’avez pas besoin d’une infrastructure à clé publique (PKI) pour gérer les certificats, si vous n’en avez pas actuellement. Windows Hello combine les principaux avantages des cartes à puce : la flexibilité de déploiement pour les cartes à puce virtuelles et la sécurité robuste pour les cartes à puce physiques, et cela sans aucun de leurs inconvénients.

Fonctionnement de Windows Hello

Lorsque l’utilisateur configure Windows Hello sur son ordinateur, il génère une nouvelle paire de clés publique-privée sur l’appareil. Le module de plateforme sécurisée (TPM) génère et protège cette clé privée. Si l’appareil n’a pas de puce TPM, la clé privée est chiffrée et protégée par les logiciels. En outre, les appareils compatibles TPM génèrent un bloc de données qui peut être utilisé pour attester qu’une clé est liée au module TPM. Ces informations d’attestation peuvent être utilisées dans votre solution pour décider si l’utilisateur reçoit un niveau d’autorisation différent, par exemple.

Pour activer Windows Hello sur un appareil, l’utilisateur doit disposer de son compte d’ID Microsoft Entra ou de son compte Microsoft connecté dans les paramètres Windows.

Comment les clés sont protégées

Chaque fois que le matériel clé est généré, il doit être protégé contre les attaques. La façon la plus robuste de le faire consiste à utiliser du matériel spécialisé. Il existe un long historique d’utilisation de modules de sécurité matériels (HSM) pour générer, stocker et traiter des clés pour les applications critiques de sécurité. Les cartes à puce sont un type spécial de HSM, comme les appareils conformes à la norme TPM du groupe informatique approuvé. Dans la mesure du possible, l’implémentation de Windows Hello tire parti du matériel TPM intégré pour générer, stocker et traiter des clés. Toutefois, Windows Hello et Windows Hello for Work ne nécessitent pas de module de plateforme sécurisée intégré.

Chaque fois que cela est possible, Microsoft recommande l’utilisation du matériel TPM. Le module TPM protège contre diverses attaques connues et potentielles, y compris les attaques par force brute de code confidentiel. Le module de plateforme sécurisée fournit également une couche de protection supplémentaire après un verrouillage de compte. Lorsque le module de plateforme sécurisée a verrouillé le matériel de clé, l’utilisateur doit réinitialiser le code confidentiel. La réinitialisation du code confidentiel signifie que toutes les clés et certificats chiffrés avec l’ancien matériel de clé seront supprimés.

Authentification

Lorsqu’un utilisateur souhaite accéder au matériel de clé protégée, le processus d’authentification commence par l’utilisateur entrant un code confidentiel ou un mouvement biométrique pour déverrouiller l’appareil, un processus parfois appelé « libération de la clé ».

Une application ne peut jamais utiliser les clés d’une autre application, ni quelqu’un ne peut jamais utiliser les clés d’un autre utilisateur. Ces clés sont utilisées pour signer des demandes envoyées au fournisseur d’identité ou au fournisseur d’identité, cherchant à accéder aux ressources spécifiées. Les applications peuvent utiliser des API spécifiques pour demander des opérations nécessitant des éléments clés pour des actions particulières. L’accès via ces API nécessite une validation explicite par le biais d’un mouvement utilisateur et le matériel clé n’est pas exposé à l’application demandée. Au lieu de cela, l’application demande une action spécifique, comme la signature d’un élément de données, et la couche Windows Hello gère le travail réel et retourne les résultats.

Préparation à l’implémentation de Windows Hello

Maintenant que nous avons une compréhension de base du fonctionnement de Windows Hello, examinons comment les implémenter dans nos propres applications.

Il existe différents scénarios que nous pouvons implémenter à l’aide de Windows Hello. Par exemple, il vous suffit de vous connecter à votre application sur un appareil. L’autre scénario courant consisterait à s’authentifier auprès d’un service. Au lieu d’utiliser un nom d’ouverture de session et un mot de passe, vous utiliserez Windows Hello. Dans les sections suivantes, nous allons aborder l’implémentation de deux scénarios différents, notamment la façon de s’authentifier auprès de vos services avec Windows Hello, et comment effectuer une conversion d’un système de nom d’utilisateur/mot de passe existant en système Windows Hello.

Implémentation de Windows Hello

Dans cette section, nous commençons par un scénario greenfield sans système d’authentification existant, et nous expliquons comment implémenter Windows Hello.

La section suivante explique comment migrer à partir d’un système de nom d’utilisateur/mot de passe existant. Toutefois, même si cette section vous intéresse davantage, vous pouvez examiner celle-ci pour obtenir une compréhension de base du processus et du code requis.

Inscription de nouveaux utilisateurs

Nous commençons par un tout nouveau service qui utilisera Windows Hello et un nouvel utilisateur hypothétique prêt à s’inscrire sur un nouvel appareil.

La première étape consiste à vérifier que l’utilisateur est en mesure d’utiliser Windows Hello. L’application vérifie les paramètres utilisateur et les fonctionnalités de l’ordinateur pour vous assurer qu’elle peut créer des clés d’ID utilisateur. Si l’application détermine que l’utilisateur n’a pas encore activé Windows Hello, il invite l’utilisateur à le configurer avant d’utiliser l’application.

Pour activer Windows Hello, l’utilisateur doit simplement configurer un code confidentiel dans les paramètres Windows, sauf si l’utilisateur l’a configuré pendant l’expérience OOBE (Out of Box Experience).

Les lignes de code suivantes montrent un moyen simple de vérifier si l’utilisateur est configuré pour Windows Hello.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
if (!keyCredentialAvailable)
{
    // User didn't set up PIN yet
    return;
}

L’étape suivante consiste à demander à l’utilisateur d’obtenir des informations pour s’inscrire auprès de votre service. Vous pouvez choisir de demander à l’utilisateur le prénom, le nom, l’adresse e-mail et un nom d’utilisateur unique. Vous pouvez utiliser l’adresse e-mail comme identificateur unique ; c’est à toi.

Dans ce scénario, nous utilisons l’adresse e-mail comme identificateur unique pour l’utilisateur. Une fois que l’utilisateur s’est inscrit, vous devez envisager d’envoyer un e-mail de validation pour vous assurer que l’adresse est valide. Cela vous donne un mécanisme de réinitialisation du compte si nécessaire.

Si l’utilisateur a configuré son code CONFIDENTIEL, l’application crée keyCredential de l’utilisateur. L’application obtient également les informations d’attestation de clé facultatives pour acquérir la preuve de chiffrement que la clé est générée sur le module TPM. La clé publique générée, et éventuellement l’attestation, est envoyée au serveur principal pour inscrire l’appareil utilisé. Chaque paire de clés générée sur chaque appareil sera unique.

Le code à créer keyCredential ressemble à ceci :

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

RequestCreateAsync est l’appel qui crée la clé publique et privée. Si l’appareil a la puce TPM appropriée, les API demandent à la puce TPM de créer la clé privée et publique et de stocker le résultat ; s’il n’existe aucune puce TPM disponible, le système d’exploitation crée la paire de clés dans le code. Il n’existe aucun moyen pour l’application d’accéder directement aux clés privées créées. Une partie de la création des paires de clés est également les informations d’attestation obtenues. (Consultez la section suivante pour plus d’informations sur l’attestation.)

Une fois la paire de clés et les informations d’attestation créées sur l’appareil, la clé publique, les informations d’attestation facultatives et l’identificateur unique (par exemple, l’adresse e-mail) doivent être envoyés au service d’inscription principal et stockés dans le back-end.

Pour permettre à l’utilisateur d’accéder à l’application sur plusieurs appareils, le service principal doit pouvoir stocker plusieurs clés pour le même utilisateur. Étant donné que chaque clé est unique pour chaque appareil, nous allons stocker toutes ces clés connectées au même utilisateur. Un identificateur d’appareil est utilisé pour optimiser la partie serveur lors de l’authentification des utilisateurs. Nous en parlons plus en détail dans la section suivante.

Un exemple de schéma de base de données pour stocker ces informations sur le serveur principal peut ressembler à ceci :

La logique d’inscription peut ressembler à ceci :

Les informations d’inscription que vous collectez peuvent bien sûr inclure beaucoup plus d’informations d’identification que celles que nous incluons dans ce scénario simple. Par exemple, si votre application accède à un service sécurisé tel qu’un service bancaire, vous devez demander une preuve d’identité et d’autres éléments dans le cadre du processus d’inscription. Une fois toutes les conditions remplies, la clé publique de cet utilisateur est stockée dans le back-end et utilisée pour valider la prochaine fois que l’utilisateur utilise le service.

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Credentials;

static async void RegisterUser(string AccountId)
{
    var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
    if (!keyCredentialAvailable)
    {
        // The user didn't set up a PIN yet
        return;
    }

    var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(AccountId, KeyCredentialCreationOption.ReplaceExisting);
    if (keyCreationResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = keyCreationResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var keyAttestationResult = await userKey.GetAttestationAsync();
        IBuffer keyAttestation = null;
        IBuffer certificateChain = null;
        bool keyAttestationIncluded = false;
        bool keyAttestationCanBeRetrievedLater = false;

        keyAttestationResult = await userKey.GetAttestationAsync();
        KeyCredentialAttestationStatus keyAttestationRetryType = 0;

        switch (keyAttestationResult.Status)
        {
            case KeyCredentialAttestationStatus.Success:
                keyAttestationIncluded = true;
                keyAttestation = keyAttestationResult.AttestationBuffer;
                certificateChain = keyAttestationResult.CertificateChainBuffer;
                break;
            case KeyCredentialAttestationStatus.TemporaryFailure:
                keyAttestationRetryType = KeyCredentialAttestationStatus.TemporaryFailure;
                keyAttestationCanBeRetrievedLater = true;
                break;
            case KeyCredentialAttestationStatus.NotSupported:
                keyAttestationRetryType = KeyCredentialAttestationStatus.NotSupported;
                keyAttestationCanBeRetrievedLater = true;
                break;
        }
    }
    else if (keyCreationResult.Status == KeyCredentialStatus.UserCanceled ||
        keyCreationResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {
        // Show error message to the user to get confirmation that user
        // does not want to enroll.
    }
}

Attestation

Lors de la création de la paire de clés, il existe également une option permettant de demander les informations d’attestation, générées par la puce TPM. Ces informations facultatives peuvent être envoyées au serveur dans le cadre du processus d’inscription. L’attestation de clé TPM est un protocole qui prouve par chiffrement qu’une clé est liée au TPM. Ce type d’attestation peut être utilisé pour garantir qu’une certaine opération de chiffrement s’est produite dans le module TPM d’un ordinateur particulier.

Lorsqu’il reçoit la clé RSA générée, l’instruction d’attestation et le certificat AIK, le serveur vérifie les conditions suivantes :

• La signature de certificat AIK est valide.
• Le certificat AIK se chaîne à une racine approuvée.
• Le certificat AIK et sa chaîne sont activés pour l’EKU OID « 2.23.133.8.3 » (le nom convivial est « Certificat de clé d’identité d’attestation »).
• Le certificat AIK est valide.
• Tous les certificats d’autorité de certification émis dans la chaîne sont valides et ne sont pas révoqués.
• L’instruction d’attestation est correctement formée.
• La signature sur l’objet blob KeyAttestation utilise une clé publique AIK.
• La clé publique incluse dans l’objet blob KeyAttestation correspond à la clé RSA publique envoyée par le client en même temps que l’instruction d’attestation.

Votre application peut affecter à l’utilisateur un niveau d’autorisation différent, en fonction de ces conditions. Par exemple, si l’une de ces vérifications échoue, il peut ne pas inscrire l’utilisateur ou limiter ce que l’utilisateur peut faire.

Connexion avec Windows Hello

Une fois que l’utilisateur est inscrit dans votre système, il peut utiliser l’application. Selon le scénario, vous pouvez demander aux utilisateurs de s’authentifier avant de commencer à utiliser l’application ou simplement de leur demander de s’authentifier une fois qu’ils commencent à utiliser vos services back-end.

Forcer l’utilisateur à se reconnecter

Pour certains scénarios, vous souhaiterez peut-être que l’utilisateur prouve qu’il est la personne actuellement connectée, avant d’accéder à l’application ou parfois avant d’effectuer une certaine action à l’intérieur de votre application. Par exemple, avant qu’une application bancaire envoie la commande de transfert d’argent au serveur, vous souhaitez vous assurer qu’il s’agit de l’utilisateur, plutôt que d’une personne qui a trouvé un appareil connecté, tentant d’effectuer une transaction. Vous pouvez forcer l’utilisateur à se reconnecter dans votre application à l’aide de la classe UserConsentVerifier . La ligne de code suivante force l’utilisateur à entrer ses informations d’identification.

La ligne de code suivante force l’utilisateur à entrer ses informations d’identification.

UserConsentVerificationResult consentResult = await UserConsentVerifier.RequestVerificationAsync("userMessage");
if (consentResult.Equals(UserConsentVerificationResult.Verified))
{
    // continue
}

Vous pouvez également utiliser le mécanisme de réponse aux défis du serveur, ce qui oblige un utilisateur à entrer son code confidentiel ou ses informations d’identification biométriques. Cela dépend du scénario que vous avez besoin d’implémenter en tant que développeur. Ce mécanisme est décrit dans la section suivante.

Authentification sur le serveur principal

Lorsque l’application tente d’accéder à un service back-end protégé, le service envoie un défi à l’application. L’application utilise la clé privée de l’utilisateur pour signer le défi et la renvoyer au serveur. Étant donné que le serveur a stocké la clé publique pour cet utilisateur, il utilise des API de chiffrement standard pour s’assurer que le message a été effectivement signé avec la clé privée correcte. Sur le client, la signature est effectuée par les API Windows Hello ; le développeur n’aura jamais accès à la clé privée d’un utilisateur.

En plus de vérifier les clés, le service peut également vérifier l’attestation de clé et déterminer s’il existe des limitations appelées sur la façon dont les clés sont stockées sur l’appareil. Par exemple, lorsque l’appareil utilise le module TPM pour protéger les clés, il est plus sécurisé que les appareils stockant les clés sans module de plateforme sécurisée. La logique back-end peut décider, par exemple, que l’utilisateur est autorisé à transférer un certain montant d’argent lorsqu’aucun module de plateforme sécurisée n’est utilisé pour réduire les risques.

L’attestation est disponible uniquement pour les appareils dotés d’une puce TPM version 2.0 ou ultérieure. Par conséquent, vous devez tenir compte du fait que ces informations peuvent ne pas être disponibles sur chaque appareil.

Le flux de travail client peut ressembler au graphique suivant :

Lorsque l’application appelle le service sur le serveur principal, le serveur envoie un défi. Le défi est signé avec le code suivant :

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

if (openKeyResult.Status == KeyCredentialStatus.Success)
{
    var userKey = openKeyResult.Credential;
    var publicKey = userKey.RetrievePublicKey();
    var signResult = await userKey.RequestSignAsync(message);

    if (signResult.Status == KeyCredentialStatus.Success)
    {
        return signResult.Result;
    }
    else if (signResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {

    }
}

La première ligne, KeyCredentialManager.OpenAsync, demande à Windows d’ouvrir le handle de clé. Si cela réussit, vous pouvez signer le message de défi avec la méthode KeyCredential.RequestSignAsync , ce qui entraîne la demande du code confidentiel ou de la biométrie de l’utilisateur par le biais de Windows Hello. À aucun moment, le développeur aura accès à la clé privée de l’utilisateur. Tout est sécurisé par le biais des API.

Les API demandent à Windows de signer le défi avec la clé privée. Le système demande ensuite à l’utilisateur d’un code CONFIDENTIEL ou d’une ouverture de session biométrique configurée. Lorsque les informations correctes sont entrées, le système peut demander à la puce TPM d’effectuer les fonctions de chiffrement et de signer le défi. (Ou utilisez la solution logicielle de secours, si aucun module de plateforme sécurisée n’est disponible). Le client doit renvoyer le défi signé au serveur.

Un flux de défi-réponse de base est illustré dans ce diagramme de séquence :

Ensuite, le serveur doit valider la signature. Lorsque vous demandez la clé publique et que vous l’envoyez au serveur pour une validation ultérieure, elle se trouve dans un objet blob publicKeyInfo codé en ASN.1. Si vous examinez l’exemple de code Windows Hello sur GitHub, vous verrez qu’il existe des classes d’assistance pour encapsuler les fonctions Crypt32 pour traduire l’objet blob encodé ASN.1 en objet blob CNG, qui est plus couramment utilisé. L’objet blob contient l’algorithme de clé publique, qui est RSA et la clé publique RSA.

Dans l’exemple, la raison pour laquelle nous convertissons l’objet blob encodé ASN.1 en objet blob CNG est de sorte qu’il puisse être utilisé avec CNG et l’API BCrypt. Si vous recherchez l’objet blob CNG, il vous pointe vers la structure BCRYPT_KEY_BLOB associée. Cette surface d’API peut être utilisée pour l’authentification et le chiffrement dans les applications Windows. ASN.1 est une norme documentée pour la communication de structures de données qui peuvent être sérialisées, et elle est couramment utilisée dans le chiffrement à clé publique et avec des certificats. C’est pourquoi les informations de clé publique sont retournées de cette façon. La clé publique est une clé RSA ; et c’est l’algorithme que Windows Hello utilise lorsqu’il signe des données.

Une fois que vous disposez de l’objet blob CNG, vous devez valider la demande signée par rapport à la clé publique de l’utilisateur. Étant donné que tout le monde utilise sa propre technologie système ou back-end, il n’existe aucun moyen générique d’implémenter cette logique. Nous utilisons SHA256 comme algorithme de hachage et Pkcs1 pour SignaturePadding. Vérifiez donc que c’est ce que vous utilisez lorsque vous validez la réponse signée du client. Là encore, reportez-vous à l’exemple pour obtenir un moyen de le faire sur votre serveur dans .NET 4.6, mais en général, il ressemblera à ceci :

using (RSACng pubKey = new RSACng(publicKey))
{
    retval = pubKey.VerifyData(originalChallenge, responseSignature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

Nous lisons la clé publique stockée, qui est une clé RSA. Nous validons le message de défi signé avec la clé publique et, si cela est extrait, nous autoriseons l’utilisateur. Si l’utilisateur est authentifié, l’application peut appeler les services principaux comme normale.

Le code complet peut ressembler à ce qui suit :

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Cryptography;
using Windows.Security.Cryptography.Core;
using Windows.Security.Credentials;

static async Task<IBuffer> GetAuthenticationMessageAsync(IBuffer message, String AccountId)
{
    var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

    if (openKeyResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = openKeyResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var signResult = await userKey.RequestSignAsync(message);
        if (signResult.Status == KeyCredentialStatus.Success)
        {
            return signResult.Result;
        }
        else if (signResult.Status == KeyCredentialStatus.UserCanceled)
        {
            // Launch app-specific flow to handle the scenario 
            return null;
        }
    }
    else if (openKeyResult.Status == KeyCredentialStatus.NotFound)
    {
        // PIN reset has occurred somewhere else and key is lost.
        // Repeat key registration
        return null;
    }
    else
    {
        // Show custom UI because unknown error has happened.
        return null;
    }
}

L’implémentation du mécanisme de réponse aux défis correct est en dehors de l’étendue de ce document, mais cette rubrique nécessite une attention particulière afin de créer un mécanisme sécurisé pour empêcher les attaques par relecture ou les attaques de l’intercepteur.

Inscription d’un autre appareil

Il est courant pour les utilisateurs d’avoir plusieurs appareils avec les mêmes applications installées aujourd’hui. Comment cela fonctionne-t-il lors de l’utilisation de Windows Hello avec plusieurs appareils ?

Lorsque vous utilisez Windows Hello, chaque appareil crée un ensemble de clés privées et publiques uniques. Cela signifie que si vous souhaitez qu’un utilisateur puisse utiliser plusieurs appareils, votre back-end doit être en mesure de stocker plusieurs clés publiques à partir de cet utilisateur. Reportez-vous au diagramme de base de données de la section Inscrire de nouveaux utilisateurs pour obtenir un exemple de structure de table.

L’inscription d’un autre appareil est presque identique à l’inscription d’un utilisateur pour la première fois. Vous devez toujours vous assurer que l’utilisateur qui s’inscrit pour ce nouvel appareil est vraiment l’utilisateur qu’il prétend être. Vous pouvez le faire avec n’importe quel mécanisme d’authentification à deux facteurs utilisé aujourd’hui. Il existe plusieurs façons d’y parvenir de manière sécurisée. Tout dépend de votre scénario.

Par exemple, si vous utilisez toujours le nom de connexion et le mot de passe, vous pouvez l’utiliser pour authentifier l’utilisateur et lui demander d’utiliser l’une de ses méthodes de vérification telles que SMS ou e-mail. Si vous n’avez pas de nom de connexion et de mot de passe, vous pouvez également utiliser l’un des appareils déjà inscrits et envoyer une notification à l’application sur cet appareil. L’application d’authentificateur MSA est un exemple de ceci. En bref, vous devez utiliser un mécanisme 2FA commun pour inscrire des appareils supplémentaires pour l’utilisateur.

Le code permettant d’inscrire le nouvel appareil est exactement le même que l’inscription de l’utilisateur pour la première fois (à partir de l’application).

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

Pour faciliter la reconnaissance des appareils inscrits par l’utilisateur, vous pouvez choisir d’envoyer le nom de l’appareil ou un autre identificateur dans le cadre de l’inscription. Cela est également utile, par exemple, si vous souhaitez implémenter un service sur votre back-end où les utilisateurs peuvent annuler l’inscription des appareils lorsqu’un appareil est perdu.

Utilisation de plusieurs comptes dans votre application

Outre la prise en charge de plusieurs appareils pour un seul compte, il est également courant de prendre en charge plusieurs comptes dans une seule application. Par exemple, vous vous connectez peut-être à plusieurs comptes Twitter à partir de votre application. Avec Windows Hello, vous pouvez créer plusieurs paires de clés et prendre en charge plusieurs comptes à l’intérieur de votre application.

Une façon de procéder consiste à conserver le nom d’utilisateur ou l’identificateur unique décrit dans la section précédente sur le stockage isolé. Par conséquent, chaque fois que vous créez un compte, vous stockez l’ID de compte dans un stockage isolé.

Dans l’interface utilisateur de l’application, vous autorisez l’utilisateur à choisir l’un des comptes créés précédemment ou à s’inscrire avec un nouveau compte. Le flux de création d’un compte est identique à celui décrit précédemment. Le choix d’un compte consiste à répertorier les comptes stockés à l’écran. Une fois que l’utilisateur sélectionne un compte, utilisez l’ID de compte pour vous connecter à l’utilisateur dans votre application :

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

Le reste du flux est identique à celui décrit précédemment. Pour être clair, tous ces comptes sont protégés par le même code confidentiel ou le même mouvement biométrique, car dans ce scénario, ils sont utilisés sur un seul appareil avec le même compte Windows.

Migration d’un système existant vers Windows Hello

Dans cette courte section, nous aborderons une application empaquetée existante et un système back-end qui utilise une base de données qui stocke le nom d’utilisateur et le mot de passe haché. Ces applications collectent les informations d’identification de l’utilisateur lorsque l’application démarre et les utilisent lorsque le système principal retourne le défi d’authentification.

Ici, nous allons décrire les éléments qui doivent être modifiés ou remplacés pour faire fonctionner Windows Hello.

Nous avons déjà décrit la plupart des techniques décrites dans les sections précédentes. L’ajout de Windows Hello à votre système existant implique l’ajout de deux flux différents dans la partie d’inscription et d’authentification de votre code.

Une approche consiste à laisser l’utilisateur choisir quand mettre à niveau. Une fois que l’utilisateur se connecte à l’application et que vous détectez que l’application et le système d’exploitation sont capables de prendre en charge Windows Hello, vous pouvez demander à l’utilisateur s’il souhaite mettre à niveau les informations d’identification pour utiliser ce système moderne et plus sécurisé. Vous pouvez utiliser le code suivant pour vérifier si l’utilisateur est capable d’utiliser Windows Hello.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

L’interface utilisateur peut ressembler à ceci :

Si l’utilisateur choisit de commencer à utiliser Windows Hello, vous créez le KeyCredential décrit précédemment. Le serveur d’inscription principal ajoute la clé publique et l’instruction d’attestation facultative à la base de données. Étant donné que l’utilisateur est déjà authentifié avec un nom d’utilisateur et un mot de passe, le serveur peut lier les nouvelles informations d’identification aux informations d’utilisateur actuelles dans la base de données. Le modèle de base de données peut être identique à l’exemple décrit précédemment.

Si l’application a pu créer les utilisateurs KeyCredential, elle stocke l’ID utilisateur dans un stockage isolé afin que l’utilisateur puisse choisir ce compte dans la liste une fois l’application redémarré. À partir de ce stade, le flux suit exactement les exemples décrits dans les sections précédentes.

La dernière étape de la migration vers un scénario Windows Hello complet désactive l’option nom d’ouverture de session et mot de passe dans l’application et supprime les mots de passe hachés stockés de votre base de données.

Résumé

Windows introduit un niveau de sécurité plus élevé qui est également simple à mettre en pratique. Windows Hello fournit un nouveau système de connexion biométrique qui reconnaît l’utilisateur et contrecarre activement les tentatives de contourner une identification correcte. Il peut ensuite fournir plusieurs couches de clés et de certificats qui ne peuvent jamais être révélés ou utilisés en dehors du module de plateforme approuvée. En outre, une couche de sécurité supplémentaire est disponible via l’utilisation facultative des clés d’identité d’attestation et des certificats.

En tant que développeur, vous pouvez utiliser ces conseils sur la conception et le déploiement de ces technologies pour ajouter facilement une authentification sécurisée à vos déploiements d’applications Windows empaquetées pour protéger les applications et les services principaux. Le code requis est minimal et facile à comprendre. Windows gère le gros travail.

Les options d’implémentation flexibles permettent à Windows Hello de remplacer ou de travailler en même temps que votre système d’authentification existant. L’expérience de déploiement est indolore et économique. Aucune infrastructure supplémentaire n’est nécessaire pour déployer la sécurité Windows. Avec Microsoft Hello intégré au système d’exploitation, Windows offre la solution la plus sécurisée aux problèmes d’authentification rencontrés par le développeur moderne.

Mission accomplie ! Vous venez de faire de l’Internet un endroit plus sûr !

Ressources supplémentaires

Articles et exemples de code

• Vue d’ensemble de Windows Hello
• Planifier un déploiement Windows Hello Entreprise
• Exemple de code Windows Hello UWP sur GitHub

Terminologie

Rubriques connexes

• Application de connexion Windows Hello
• Service de connexion Windows Hello