WebAuthn pubKeyCredParams & credentialPublicKey : CBOR & COSE

1. Introduction : pubKeyCredParams & credentialPublicKey

2. Qu'est-ce que la cryptographie à clé publique ?

    2.1 Comment fonctionne la cryptographie à clé publique ?

    2.2 Types courants d'algorithmes de cryptographie à clé publique

    2.3 Adoption croissante de la cryptographie publique basée sur l'ECC

3. WebAuthn : comment la cryptographie à clé publique est-elle utilisée dans les Passkeys ?

4. Comment choisir les bons paramètres pour pubKeyCredParams ?

    4.1 Quels algorithmes COSE sont pertinents pour WebAuthn ?

    4.2 Définir le tableau pubKeyCredParams dans pubKeyCredParams

5. Comment extraire la clé publique de l'attestationObject ?

    5.1 Vue d'ensemble : qu'est-ce que l'attestationObject ?

      5.2 Qu'est-ce que la Concise Binary Object Representation (CBOR) ?

      5.3 Qu'est-ce que le format de clé COSE ?

      5.4 Décodage et analyse de l'attestationObject

6. Recommandation

7. Conclusion

Dans le domaine de la sécurité numérique, les Passkeys sont le nouveau standard de l'authentification sans mot de passe. Au cœur des Passkeys se trouve la cryptographie à clé publique, utilisée au sein du protocole WebAuthn sur lequel ils reposent. Comprendre comment la cryptographie à clé publique est utilisée dans WebAuthn, notamment pour la création, l'extraction, la gestion et le stockage des Passkeys, est essentiel lors de la conception ou de l'utilisation de l'authentification par Passkeys. La clé publique est stockée sur le serveur de la Relying Party (RP), qui est le backend du site web souhaitant authentifier un utilisateur via des Passkeys. La clé privée, quant à elle, est stockée de manière sécurisée dans un module de sécurité matériel (HSM) qui varie selon le système d'exploitation : Secure Enclave (iOS), TEE (Android) ou un TPM (Windows).

Dans cet article de blog, nous allons rapidement passer en revue les bases de la cryptographie à clé publique utilisée dans les Passkeys. À la fin de cet article, nous aurons répondu aux questions suivantes :

• Quels algorithmes de chiffrement sont pris en charge par WebAuthn
• Comment fonctionnent les pubKeyCredParams lors de la création d'une paire de clés ?
• Comment fonctionne credentialPublicKey pour extraire les clés publiques créées ?

Pour comprendre le fonctionnement de la cryptographie à clé publique au sein de WebAuthn, nous allons d'abord examiner son principe général et les types d'algorithmes les plus courants.

La cryptographie à clé publique, également connue sous le nom de cryptographie asymétrique, s'oppose à la cryptographie symétrique où la même clé est utilisée pour le chiffrement et le déchiffrement. La cryptographie asymétrique utilise deux clés distinctes : une clé publique, qui peut être partagée ouvertement, et une clé privée, qui est gardée secrète par son propriétaire.

Source : https://en.wikipedia.org/wiki/Public-key_cryptography

Cette méthode permet non seulement de chiffrer des données pour en garantir la confidentialité, mais aussi de signer des messages. La signature vérifie l'identité de l'expéditeur et garantit que le message n'a pas été altéré, confirmant ainsi son authenticité et son intégrité.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Voici un aperçu de quelques types d'algorithmes courants utilisés en cryptographie à clé publique :

Le fondement mathématique de la cryptographie sur les courbes elliptiques (ECC), qui inclut ECDSA et EdDSA, repose sur les propriétés des courbes elliptiques que nous n'aborderons pas dans cet article. Mais il est évident, d'après le tableau ci-dessus, que certains avantages favorisent leur adoption. Nous allons passer en revue les plus importants dans la section suivante.

Become part of our Passkeys Community for updates & support.

Join

La cryptographie sur les courbes elliptiques a été largement adoptée pour les appareils mobiles, car ils bénéficient de tailles de clé plus petites, ce qui présente les avantages suivants :

• Besoins de stockage réduits : Les clés plus petites de l'ECC nécessitent moins d'espace de stockage que les méthodes cryptographiques traditionnelles comme RSA. C'est particulièrement avantageux pour les appareils disposant de ressources mémoire limitées, ce qui permet une utilisation plus efficace de l'espace. Le tableau suivant montre une approximation des niveaux de sécurité comparables et des tailles réelles des clés utilisées. Le niveau de sécurité est mesuré en bits et correspond généralement à un chiffrement par clé symétrique de cette taille :

Le terme niveau de sécurité dans ce contexte fait référence à la robustesse du système cryptographique, plus précisément au niveau de difficulté pour un attaquant de déjouer les mesures de sécurité. Il est généralement mesuré en bits et représente la quantité de travail (le nombre d'opérations) qui serait nécessaire pour casser le chiffrement ou falsifier une signature. Avec l'augmentation du niveau de sécurité, les avantages en termes de taille deviennent évidents, atteignant des rapports de taille de clé allant jusqu'à 1:30.

• Performances améliorées : Les clés plus petites permettent des opérations cryptographiques plus rapides, ce qui est crucial pour les appareils à faible puissance de traitement. Il en résulte des activités de chiffrement et de déchiffrement plus rapides, ce qui améliore les performances globales et la réactivité des applications mobiles. Selon le type de benchmarks, les gains de vitesse d'exécution varient de 10 à 40 fois. Voici un exemple de données de benchmark qu'AWS a mené lors de l'implémentation d'ECDSA pour Cloudfront en 2018 :

• Meilleure efficacité énergétique : Grâce à un traitement plus efficace avec des clés plus petites, les opérations ECC peuvent consommer moins d'énergie. Cette économie d'énergie est vitale pour les appareils mobiles, où la préservation de l'autonomie de la batterie est un défi constant.

Ces facteurs rendent l'ECC particulièrement adaptée aux environnements mobiles, où l'optimisation du stockage, de la vitesse de traitement et de la consommation d'énergie est essentielle. Par conséquent, l'ECC est de plus en plus privilégiée dans l'informatique mobile pour sa capacité à fournir une sécurité robuste sans compromettre les performances de l'appareil. Néanmoins, il existe encore aujourd'hui de nombreuses anciennes versions de protocoles répandus comme TLS (utilisé pour HTTPS, FTPS ou SMTPS), SSH ou IPsec qui prennent toujours en charge RSA, mais qui ont commencé à proposer des variantes basées sur l'ECC aux clients qui les supportent.

Le standard WebAuthn n'est pas un standard de chiffrement, mais plutôt un protocole de sécurité qui fournit une authentification forte basée sur la clé publique pour les applications web. Il permet aux utilisateurs de se connecter en utilisant la biométrie, des appareils mobiles ou des clés de sécurité matérielles (par exemple, les YubiKeys) au lieu de mots de passe. Par conséquent, WebAuthn est intentionnellement agnostique quant à la cryptographie à clé publique sous-jacente réellement utilisée. Voyons comment cela est réalisé.

Le protocole de sécurité WebAuthn facilite l'authentification cryptographiquement sécurisée entre l'Utilisateur et la Relying Party. En termes techniques, cela signifie que la Relying Party (un site web qui souhaite utiliser les Passkeys avec ses utilisateurs) doit échanger des clés via le navigateur avec l'utilisateur et son Authenticator, qui stocke ensuite la clé privée dans le module de sécurité matériel (HSM) spécifique.

Pour l'inscription / l'enregistrement des Passkeys, il y a trois étapes importantes :

• (1) La Relying Party signale les algorithmes de chiffrement pris en charge : La Relying Party signale les algorithmes de chiffrement supportés via PublicKeyCredentialCreationOptions.pubKeyCredParams avec les autres PublicKeyCredentialCreationOptions.
• (2) L'Authenticator de l'utilisateur crée la paire de clés : L'Authenticator vérifie la liste pubKeyCredParams pour trouver les algorithmes de chiffrement qu'il prend en charge et crée une paire de clés ainsi qu'un Credential ID unique. Il stocke la clé privée dans le HSM, puis renvoie la clé publique et l'algorithme de chiffrement utilisé au navigateur. Ensuite, le navigateur envoie une requête POST au backend de la Relying Party avec l'attestationObject dans la section « authData ». S'il n'y a aucune correspondance entre les algorithmes de chiffrement pris en charge, la cérémonie de création échouera.
• (3) La Relying Party extrait la clé publique et la stocke : La Relying Party reçoit l'attestationObject du navigateur. Elle analyse la section authData.credentialPublicKey et en extrait la clé publique. En plus de la clé publique, des informations sur l'algorithme de chiffrement utilisé et le Credential ID sont également renvoyées à la Relying Party.

Pour les connexions / authentifications ultérieures avec des Passkeys, les étapes suivantes sont nécessaires (détails simplifiés) :

• (1) La Relying Party présente un challenge : La Relying Party génère un challenge aléatoire et le fournit à l'Authenticator pour signature.
• (2) L'Authenticator de l'utilisateur signe le challenge : L'Authenticator signe le challenge avec la clé qui correspond à la demande d'authentification et le renvoie avec le Credential ID à la Relying Party.
• (3) La Relying Party valide la signature : La Relying Party reçoit les informations et recherche la clé publique associée au Credential ID utilisé. Elle valide ensuite cryptographiquement la signature en utilisant l'algorithme de chiffrement/signature convenu lors de l'enregistrement des Passkeys.

En examinant les deux cas, nous pouvons voir que c'est uniquement lors de l'inscription / l'enregistrement des Passkeys que les informations sur la clé publique et l'algorithme de chiffrement sont transportées entre les acteurs.

Pour les événements de connexion / authentification ultérieurs avec des Passkeys, seuls le challenge et la signature font partie des données transmises.

Le standard WebAuthn utilise les ID d'algorithme COSE de l'IANA pour identifier les algorithmes de chiffrement utilisés. Les ID d'algorithme COSE sont utilisés à la fois pour signaler les algorithmes pris en charge dans pubKeyCredParams et pour transmettre le type de paire de clés réellement créé dans credentialPublicKey. Nous nous concentrerons sur leur implémentation dans les deux prochaines sections.

La liste des algorithmes COSE de l'IANA comprend plus de 75 algorithmes qui pourraient théoriquement être utilisés avec le standard WebAuthn. La plupart des algorithmes avec un ID négatif sont à clé publique asymétrique et la plupart des positifs sont symétriques, mais il s'agit plutôt d'une convention car il y a des exceptions.

Comme nous l'avons souligné précédemment, l'algorithme de chiffrement doit être pris en charge par l'Authenticator et le backend de la Relying Party pour pouvoir être utilisé dans la cérémonie WebAuthn. Comme la plupart des Relying Parties utilisent des bibliothèques WebAuthn existantes qui ont accès à un large éventail d'algorithmes de chiffrement, il est plus important de regarder quels algorithmes sont pris en charge par quels Authenticators :

(*) = Petite partie des clés de sécurité (par ex. Yubikeys 5+, Solokey ou Nitrokey)\ Extrait du tableau IANA : Voir la liste complète ici

Comme vous pouvez le voir dans ce tableau, pour prendre en charge tous les Authenticators importants, RS256 et ES256 sont suffisants. Certains membres de la communauté recommandent d'intégrer également EdDSA pour améliorer encore la sécurité. D'un autre côté, les Credential IDs qui doivent également être stockés semblent être significativement plus longs pour les clés EdDSA. À ce jour, la version de travail de l'éditeur du W3C sur le futur standard WebAuthn de niveau 3 suggère les trois algorithmes.

La configuration des algorithmes de chiffrement pris en charge pour la création de Passkeys se fait via les PublicKeyCredentialCreationOptions :

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

L'exemple montre comment les algorithmes sont spécifiés dans : pubKeyCredParams par alg pour l'ID et en ajoutant public-key comme type d'algorithme. Aux lignes 29/30, les PublicKeyCredentialCreationOptions sont transmises à l'Authenticator via l'API WebAuthn du navigateur. La suppression de la prise en charge de ES256 ou RS256 produira des erreurs et est fortement déconseillée.

Comme exemple fonctionnel, nous allons exécuter les PublicKeyCredentialCreationOptions suivantes sur un Mac dans le Passkeys Debugger.

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

La réponse produite par l'Authenticator est envoyée à la Relying Party (en tant qu'attestation) et ressemble à ceci :

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

Dans la section suivante, nous verrons comment les clés publiques et l'algorithme de chiffrement utilisé peuvent être extraits de la réponse.

Tout d'abord, nous devons examiner comment l'attestationObject est réellement construit, car comme nous le voyons ci-dessus, il n'est pas transporté en JSON vers la Relying Party.

L'attestationObject joue un rôle important dans le processus d'enregistrement WebAuthn, servant de conteneur pour la déclaration d'attestation fournie par l'Authenticator. Cet objet fournit de nombreuses informations nécessaires à la Relying Party (RP) pour vérifier l'origine et l'intégrité des nouvelles informations d'identification à clé publique.

À la base, l'attestationObject est une structure complexe. Il est principalement encodé au format CBOR (Concise Binary Object Representation), qui est ensuite encodé en Base64URL. Il encapsule les données de l'Authenticator ainsi qu'une déclaration d'attestation qui vérifie l'authenticité des informations. Comme les Passkeys sont créés avec une attestation « none » et ne contiennent donc pas de déclaration d'attestation, nous n'aborderons pas ce sujet dans cet article. Note : nous avons écrit principalement CBOR car il y a aussi des préfixes CBOR non standard impliqués en raison des longueurs variables nécessaires pour les extensions optionnelles. Nous n'approfondirons pas ce sujet, une discussion sur les complexités peut être trouvée ici.

Tiré de la spécification WebAuthn

Dans les données de l'Authenticator (authData), la clé publique nouvellement générée, ainsi que le Credential ID de l'utilisateur, sont stockés de manière sécurisée et peuvent être récupérés par la Relying Party. Comme les développeurs doivent aborder la tâche d'extraire la clé publique de l'attestationObject dans tout système basé sur WebAuthn, il est important de comprendre son architecture.

CBOR (Concise Binary Object Representation) est un format de données conçu pour encoder des données de manière compacte, efficace et extensible. Il est binaire, ce qui le rend plus petit et plus rapide à analyser que son modèle textuel, le JSON. L'exemple suivant illustre la différence entre JSON et CBOR (Texte vs. Binaire) :

Le gras est Name. L'italique est Corbado. (plus d'informations peuvent être trouvées sur https://cbor.io/)

Dans le contexte de WebAuthn, CBOR est utilisé pour plusieurs raisons :

• Lien avec FIDO2 / CTAP : Comme CBOR est utilisé dans les standards sous-jacents, l'analyse et le traitement des données sont simplifiés, car WebAuthn et CTAP utilisent tous deux le même schéma d'encodage compact.
• Compacité : L'encodage efficace de CBOR en fait un excellent choix pour le trafic web où la minimisation de la taille des données peut avoir un impact significatif sur les performances, en particulier sur les réseaux mobiles ou dans les environnements où la bande passante est limitée.
• Flexibilité : CBOR prend en charge une variété de types de données et de structures, y compris les tableaux, les maps, les chaînes de texte, les chaînes d'octets et les balises pour l'extensibilité. Cela le rend suffisamment polyvalent pour gérer les différents types de données et les structures complexes nécessaires aux opérations de WebAuthn.
• Extensibilité : Le format est conçu pour être extensible, ce qui signifie que de nouvelles fonctionnalités peuvent être ajoutées à WebAuthn sans rompre la compatibilité avec les implémentations existantes.

L'utilisation de CBOR est particulièrement adaptée à l'encodage des clés publiques et de l'attestationObject car il doit gérer les différents formats et longueurs que nous avons évoqués précédemment. Par exemple, une clé RSA aurait des attributs et des tailles différents par rapport à une clé ECDSA. Au sein de l'attestationObject, les clés publiques sont stockées au format COSE Key, qui est basé sur CBOR.

Une structure COSE Key est construite sur un objet map CBOR. Elle définit une manière structurée de représenter les clés, englobant divers types de clés et leurs paramètres correspondants, tels que le module et l'exposant RSA, ou les coordonnées de la clé publique sur courbe elliptique. Ce format standardisé permet de sérialiser et désérialiser les clés de manière cohérente, quel que soit leur algorithme cryptographique sous-jacent, en plus de l'ID de l'algorithme de chiffrement que nous avons abordé précédemment.

En tirant parti de CBOR et du format COSE Key, WebAuthn peut faciliter une large gamme d'opérations cryptographiques tout en garantissant que la charge utile reste aussi petite que possible, et reste adaptable aux futures mises à jour de la technologie cryptographique. Ce choix s'aligne sur les objectifs de WebAuthn de fournir un protocole sécurisé, efficace et évolutif pour l'authentification web.

Lorsqu'il s'agit de décoder l'attestationObject dans WebAuthn, les développeurs sont confrontés à une décision importante : développer une solution personnalisée ou utiliser une bibliothèque établie. La complexité et la nature critique de ce processus ne peuvent être surestimées. L'implémentation manuelle du décodage Base64URL et CBOR, bien que techniquement réalisable, introduit le risque d'erreurs subtiles qui peuvent compromettre l'intégrité du processus d'authentification.

Pour garantir la vérification cryptographique de la signature, ainsi que l'exactitude de toutes les autres étapes de validation, il est fortement conseillé d'utiliser une bibliothèque WebAuthn bien testée et largement adoptée. De telles bibliothèques sont conçues avec une expertise en chiffrement pour gérer les détails du décodage et de la validation de l'attestationObject, notamment :

• Analyser correctement le format CBOR pour extraire la déclaration d'attestation et les données de l'Authenticator.
• Interpréter le format COSE Key pour récupérer la clé publique.
• Effectuer des vérifications cryptographiques pour valider la signature conformément au standard WebAuthn.

En s'appuyant sur une bibliothèque réputée, les développeurs économisent non seulement du temps et des ressources, mais gagnent aussi en tranquillité d'esprit. La clé publique, une fois extraite et vérifiée par ces outils fiables, peut ensuite être stockée en toute sécurité dans la base de données, prête à être utilisée pour des sessions d'authentification sécurisées. Cette approche garantit le respect des spécifications du protocole et maintient le niveau de sécurité attendu dans les implémentations WebAuthn. Par souci de simplicité, nous utiliserons le SimpleWebauthn Debugger qui renvoie une version entièrement décodée avec les champs CBOR convertis en JSON éclaté :

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

La bibliothèque SimpleWebAuthn est utilisée pour décoder l'attestationObject complet. Comme nous pouvons le voir, toutes les informations sont maintenant lisibles. Toutes les informations cryptographiques font partie de credentialPublicKey, qui fait partie de la section authData. La bibliothèque a éclaté cela dans la déclaration parsedCredentialPublicKey. Dans la spécification, il y a plusieurs exemples de ce à quoi ressemble le format COSE Key.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

Cette sortie présente tous les éléments cryptographiques du credentialPublicKey soigneusement analysés sous une forme lisible par l'homme. Cette instance particulière révèle une clé EC2 pour l'algorithme ES256, comme l'indiquent le paramètre de l'algorithme et la présence des coordonnées x et y.

En revanche, la sortie d'un système Windows 10 ressemble à ce qui suit :

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

Ici, l'ID de l'algorithme est -257, correspondant à RS256, et nous pouvons discerner que les attributs caractérisant cette clé publique divergent de manière significative de ceux d'une clé ECDSA. Le format COSE Key permet de spécifier des attributs uniques par type :

De plus, le module RSA est considérablement plus long que les coordonnées de la courbe elliptique utilisées dans la clé ES256, ce qui souligne notre discussion précédente sur les différences de taille de clé et les exigences inhérentes des différents algorithmes cryptographiques.

Après avoir passé en revue les bases de la cryptographie à clé publique et compris comment elle est intégrée dans le standard WebAuthn / FIDO2, nous avons deux recommandations majeures pour les Relying Parties :

• Sélectionner les bons algorithmes de chiffrement : Dans l'implémentation de WebAuthn, il est important d'utiliser les bons algorithmes pour une compatibilité maximale. Sur la base des recommandations actuelles, une combinaison de RS256, ES256 et EdDSA est conseillée. RS256 et ES256 se distinguent par leur large prise en charge, et l'inclusion d'EdDSA peut améliorer la sécurité lorsque c'est possible.
• Utiliser des bibliothèques WebAuthn éprouvées pour extraire la clé publique : Une fois que vous avez choisi les algorithmes, l'étape suivante consiste à intégrer une bibliothèque WebAuthn bien testée. Une telle bibliothèque peut gérer avec compétence les complexités de l'analyse de * attestationObject*. Une fois que la bibliothèque a extrait les clés publiques et les données associées, elles peuvent être stockées en toute sécurité dans la base de données. Le format utilisé par la bibliothèque garantit généralement que la clé est stockée d'une manière qui peut être lue et utilisée avec précision pour de futures authentifications.

Il est crucial de ne pas réinventer la roue : tirez parti des connaissances collectives intégrées dans les bibliothèques établies. Une implémentation personnalisée risque d'introduire des erreurs et des failles de sécurité qui pourraient compromettre l'efficacité de l'authentification et la sécurité globale du système.

Dans cet article de blog, nous avons exploré les bases de la cryptographie à clé publique pour répondre aux trois questions initiales :

1. Algorithmes de chiffrement pris en charge dans WebAuthn : WebAuthn est conçu pour être flexible et prend en charge une large gamme d'algorithmes de chiffrement, notamment RSA (RS256), ECDSA (ES256) et EdDSA. Cette adaptabilité lui permet de s'intégrer de manière transparente avec divers Authenticators et plateformes, garantissant une large compatibilité.
2. Fonctionnalité de pubKeyCredParams dans la création de paires de clés : Les pubKeyCredParams jouent un rôle important dans la phase d'enregistrement du processus WebAuthn en spécifiant les algorithmes cryptographiques que la Relying Party prend en charge. Cela garantit que les paires de clés créées sont compatibles à la fois avec l'Authenticator de l'utilisateur et les exigences de la Relying Party.
3. Fonctionnalité de credentialPublicKey et extraction des clés publiques : Le credentialPublicKey est utilisé pour extraire les clés publiques de l'attestationObject fourni par les Authenticators.

De plus, nous avons souligné l'indépendance du protocole WebAuthn vis-à-vis des algorithmes de chiffrement spécifiques, ce qui améliore considérablement sa flexibilité et sa pérennité face aux nouvelles méthodes cryptographiques. Nous espérons que cet article aidera également d'autres développeurs à déboguer et à comprendre les concepts et les problèmes liés à la cryptographie à clé publique dans WebAuthn.