Principes de conception de protocoles sécurisés

La conception de protocoles sécurisés suppose un adversaire qui contrôle entièrement le réseau. Le modèle de Dolev-Yao (1983) précise que l'adversaire peut intercepter, lire, retarder, rejouer, supprimer et modifier tout message en transit. Il peut générer des messages indiscernables de ceux des parties légitimes. Il peut composer de nouveaux messages à partir de composants de messages connus. Il ne peut pas casser les primitives cryptographiques (déchiffrer sans la clé ni contrefaire des signatures). Point crucial, l'adversaire est limité sur le plan du calcul : il fonctionne en temps polynomial, mais contrôle tous les canaux de communication. La sécurité d'un protocole consiste à atteindre des objectifs d'authentification et de confidentialité même face à cet adversaire puissant, en s'appuyant uniquement sur la difficulté calculatoire des primitives sous-jacentes.

Abadi et Needham (1994) ont condensé les enseignements pratiques de la conception de protocoles en un ensemble de principes. (1) Chaque message doit exprimer clairement sa signification : son interprétation doit être autonome et ne pas dépendre du contexte. (2) Les conditions permettant à une entité d'agir doivent être énoncées explicitement dans le protocole. (3) Si l'identité d'une entité est importante, elle doit être indiquée explicitement dans le message. (4) Il faut préciser pourquoi le chiffrement est utilisé : le chiffrement assure la confidentialité et la signature assure l'authentification ; il ne faut pas utiliser le chiffrement à la place de la signature. (5) Un message doit être chiffré au niveau du protocole où sa confidentialité est nécessaire. Ces principes ont empêché de nombreuses failles de type NS.

Les attaques par rejeu comptent parmi les vulnérabilités de protocole les plus courantes. Les mécanismes de fraîcheur garantissent qu'un message reçu a été généré récemment et n'est pas rejoué depuis une ancienne session. Deux approches sont possibles : (1) les valeurs à usage unique (nombre utilisé ONCE), selon un défi-réponse dans lequel le récepteur envoie une valeur aléatoire et attend qu'elle soit reprise dans la réponse. La réponse doit contenir la valeur à usage unique chiffrée ou signée, ce qui empêche un ancien enregistrement de satisfaire le défi. (2) Les horodatages : les deux parties incluent l'heure actuelle et tout message dont l'horodatage est obsolète est rejeté. Les horodatages exigent des horloges synchronisées (Kerberos autorise un décalage de cinq minutes). Les valeurs à usage unique sont préférables lorsque la synchronisation des horloges est indisponible ; les horodatages simplifient la vérification sans état.

Utiliser la même clé cryptographique pour plusieurs usages crée des interactions dangereuses. Si une clé K est utilisée à la fois pour le chiffrement et l'authentification, un adversaire peut soumettre des textes chiffrés forgés au mécanisme d'authentification afin d'en extraire des informations. TLS 1.3 évite rigoureusement ce problème avec HKDF-Expand-Label et des étiquettes distinctes pour chaque clé dérivée : «‫c hs traffic » (poignée de main du client), «‫s hs traffic » (poignée de main du serveur) et «‫c ap traffic » (application du client). Même si la clé de poignée de main est compromise, les clés applicatives dérivées d'une autre branche HKDF restent sécurisées. Les conceptions de protocoles doivent examiner chaque clé afin de détecter les risques liés à des usages multiples et dériver des clés distinctes pour des usages distincts.

Les identifiants d’authentification doivent être liés à la session précise dans laquelle ils sont utilisés. Sans cette liaison, un identifiant obtenu dans une session peut être rejoué dans une autre. Techniques : (1) inclure les identifiants de session dans les données signées ou authentifiées par un MAC. (2) inclure la transcription DH dans la signature (approche STS). (3) utiliser la clé de session dérivée par HKDF pour calculer un MAC sur l’identité (approche SIGMA). Message de fin de TLS 1.3 : MAC(server_finished_key, transcript_hash) — le MAC couvre la transcription complète, de sorte que rejouer un message de fin provenant d’une autre session échoue. Cette liaison empêche les attaques intersessions découvertes dans les premières variantes de Kerberos et de NS.

Les protocoles ne devraient divulguer que le minimum d’informations nécessaire à leur fonction. Ne révélez les identités qu’aux personnes qui en ont besoin. N’incluez pas les numéros de série des certificats ni les identifiants permettant de relier des sessions à des identités, sauf si cela est nécessaire. TLS 1.3 chiffre le certificat du serveur (contrairement à TLS 1.2, où il est en clair), réduisant les informations dont dispose un espion passif. ESNI (indication de nom de serveur chiffrée, désormais ECH — ClientHello chiffré) chiffre l’indication du nom du serveur afin de dissimuler le serveur auquel le client se connecte. La divulgation minimale d’informations est également un principe de conception des jetons : les revendications des JWT doivent contenir uniquement ce qui est nécessaire à l’autorisation, et non des enregistrements d’identité complets.

La négociation de version constitue une surface d’attaque courante : un adversaire supprime ou modifie le ClientHello pour contraindre les deux parties à utiliser une version plus ancienne et moins sûre du protocole. Défenses : (1) négociation de version authentifiée — inclure la version négociée dans la transcription signée (le message de fin de TLS couvre le ClientHello, y compris la version). (2) marqueurs de rétrogradation — TLS 1.3 définit des octets magiques dans ServerHello.Random lors d’une rétrogradation vers TLS 1.2 pour permettre au client de la détecter. (3) prévention de l’intolérance aux versions — les serveurs doivent rejeter les ClientHellos malformés sans revenir silencieusement à une version antérieure. (4) SCSV — TLS_FALLBACK_SCSV signale au serveur que le client réessaie avec une version inférieure, ce qui permet au serveur de rejeter les replis illégitimes.

Les messages du protocole devraient faire l’objet d’un engagement dès le premier échange. La non-malléabilité signifie qu’un adversaire ne peut pas modifier un texte chiffré ou une signature et la faire valider dans un contexte différent. AEAD assure la non-malléabilité du texte chiffré : toute modification invalide la balise d’authentification. Au niveau du protocole, le hachage de la transcription garantit que l’échange du message de fin, à la fin d’une négociation, engage tous les messages envoyés. Cela empêche les attaques par copier-coller : l’insertion de messages provenant de deux sessions différentes ne peut produire une valeur de fin valide pour l’une ou l’autre session. Les schémas d’engagement (engagements par hachage) étendent ce principe aux flux de protocole nécessitant un engagement préalable avant la révélation.

Les protocoles complexes échouent souvent aux limites de la machine à états. Si une transition d’état est ambiguë — que se passe-t-il si le message 3 arrive avant le message 2 ? et si un type de message inattendu arrive ? — les implémentations peuvent diverger, créant des incohérences qu’un adversaire peut exploiter. Les spécifications de protocole doivent définir : la machine à états complète (tous les états et les transitions valides), le comportement face aux entrées inattendues (rejeter avec une erreur précise ou ignorer silencieusement), les délais d’attente et les limites de retransmission, ainsi que le nettoyage des sessions. SSL/TLS a historiquement souffert de divergences d’implémentation dans les machines à états ; CVE-2014-0160 (Heartbleed) était essentiellement une défaillance de machine à états : une requête de battement de cœur était traitée dans un état où la mémoire n’était pas correctement limitée.

Les protocoles cryptographiques sont rarement utilisés seuls. Un protocole AKE établit une clé de session, qui est ensuite utilisée par un protocole de la couche applicative. Si le protocole AKE et le protocole applicatif sont conçus indépendamment, sans tenir compte de la composabilité, leurs interactions peuvent compromettre la sécurité. Le cadre de la composabilité universelle (UC) (Canetti, 2001) fournit un modèle rigoureux pour la composition des protocoles : un protocole est sûr au sens UC s’il reste sûr lorsqu’il est composé arbitrairement avec d’autres protocoles sûrs au sens UC. TLS 1.3, Signal et Noise visent une sécurité composable. En pratique : utilisez la liaison de canal (exportez le hachage de la transcription) pour relier la session AKE à l’authentification applicative ultérieure et empêcher le transfert d’identifiants entre des sessions établies par le même protocole AKE.

Les concepteurs de protocoles commettent régulièrement les mêmes catégories d’erreurs. (1) Cryptographie faite maison : implémenter des chiffrements par blocs, des MAC ou une dérivation de clés personnalisés sans évaluation par des pairs. (2) Confiance implicite : supposer la source d’un message à partir du contexte réseau plutôt que d’une preuve cryptographique. (3) Sécurité facultative : rendre le chiffrement ou l’authentification configurable, ce qui conduit inévitablement à une rétrogradation. (4) Jetons à longue durée de vie sans révocation : émettre des JWT ou des clés de session ayant une longue durée de vie sans mécanisme de révocation. (5) Ignorer le canal d’erreur : ne pas authentifier les messages d’erreur permet à un adversaire d’injecter des erreurs pour influencer le comportement du protocole. (6) Utiliser le chiffrement pour l’authentification : chiffrer des données n’authentifie pas leur source sans MAC ou signature.

Selon les principes d’Abadi et Needham, pourquoi un message doit-il inclure explicitement l’identité de l’expéditeur lorsque celle-ci est importante ?

La conception de protocoles sécurisés applique des principes établis : modèle d’adversaire de Dolev-Yao (adversaire contrôlant le réseau), principes d’Abadi et Needham (identité explicite, messages autonomes), fraîcheur au moyen de valeurs à usage unique ou d’horodatages, séparation des clés via HKDF avec des étiquettes distinctes, liaison des identifiants d’authentification aux sessions, divulgation minimale d’informations, prévention des rétrogradations par authentification de la transcription, non-malléabilité grâce à AEAD et au hachage de la transcription, machines à états claires avec gestion définie des erreurs, et composabilité au moyen de preuves de sécurité selon le modèle UC. Les violations de ces principes sont à l’origine de presque toutes les vulnérabilités cryptographiques connues au niveau des protocoles.