Guide informel de Soatok sur les modèles de menace
(soatok.blog)- Un modèle de menace ne s’arrête pas à lister ce qu’il faut protéger et les attaquants : il devient utile pour les choix de conception lorsqu’il fait aussi apparaître les relations entre actifs, les hypothèses et les menaces volontairement exclues
- Un bon modèle considère les actifs non comme une liste, mais comme un graphe, et vérifie les risques et les présupposés en resserrant progressivement le périmètre autour des entrées, sorties et dépendances des composants
- Si une hypothèse tombe, les risques acceptés doivent eux aussi être réexaminés ; l’attaque Invisible Salamanders pose problème lorsque les fonctions de signalement d’abus dans l’E2EE entrent en conflit avec l’hypothèse des AEAD selon laquelle il existe « une seule clé valide par message »
- Le cas publickey.directory distingue hypothèses, actifs, acteurs et états de risque, sans être parfait ; le modèle de menace de Matrix v1.18 ressemble davantage à une liste de types d’attaques et omet le chiffrement ainsi que la gestion des clés
- La modélisation des menaces aide à prendre de meilleures décisions de conception en séparant les contraintes des choix techniques et les risques réels, comme dans l’authentification par passkey, la conception d’E2EE distribuée ou les débats sur la cryptographie post-quantique
Les questions auxquelles un modèle de menace doit répondre
- Un modèle de menace peut faire partie d’un processus formel de cybersécurité, mais il peut aussi être réalisé de manière informelle lors de la phase de conception et d’architecture d’un nouveau produit ou service
- Il doit au minimum répondre aux questions suivantes
- Que protège-t-on ?
- Qui, ou quoi, cherche à nuire à ce que l’on protège ?
- De quelles manières l’attaquant peut-il attaquer ?
- Que va-t-on faire pour bloquer ces attaques ?
- Ces quatre éléments suffisent à parler de modèle de menace, mais dans la pratique, des détails importants sont faciles à oublier
- Les questions supplémentaires nécessaires sont les suivantes
- Comment les actifs protégés sont-ils reliés entre eux ?
- Quelles hypothèses formule-t-on ?
- Quelles menaces choisit-on délibérément de ne pas traiter ?
- Comme il est impossible de couvrir toutes les attaques futures, il faut préciser les menaces exclues
- Si une hypothèse est fausse, le modèle devient incomplet, et la liste des risques déjà acceptés doit aussi être réexaminée
- Un modèle de menace ne doit pas être un instantané figé à un moment donné, mais un document vivant mis à jour lorsque c’est nécessaire
Les problèmes qui apparaissent lorsqu’une hypothèse tombe
- L’attaque Invisible Salamanders peut casser certaines conceptions de messagerie E2EE lorsque l’on y introduit une fonction de signalement d’abus
- Cette attaque interagit avec les hypothèses des schémas AEAD comme AES-GCM ou ChaCha20-Poly1305
- Ces schémas reposent sur l’hypothèse qu’il existe une seule clé valide pour un message donné
- Si l’on introduit plusieurs clés valides pour un même message, ou si l’on crée des confused deputies, on sort des garanties de sécurité de l’algorithme
- Énoncer clairement les hypothèses aide à identifier ses propres unknown unknowns
- Il n’est pas nécessaire d’être parfait, mais il faut être clair sur ce que l’on tient pour acquis
Procédure pour commencer la modélisation des menaces
- Pour pratiquer la modélisation des menaces de manière professionnelle, il est recommandé de lire le Threat Modeling Manifesto
- En pratique, on commence par noter rapidement les 7 éléments dans un format facile à copier-coller
- Ensuite, on dessine sur papier ou dans un outil numérique les composants du système à analyser
- Si un widget communique directement avec un autre, en dépend ou interagit avec lui, on indique cette relation
- La façon de représenter les relations doit simplement être celle qui est la plus utile à la personne qui travaille dessus
- On encadre ensuite tout le graphe, puis on resserre progressivement la boîte pour se concentrer sur chaque composant
- À chaque itération, on consigne les entrées et sorties du composant
- On répond autant que possible aux 7 questions
- Après être descendu aussi loin que le permet le niveau d’abstraction, on réfléchit aux hypothèses formulées sur les couches que l’on n’a pas explorées plus en profondeur
- Une base de données ne dépend probablement pas de la sécurité de X25519 de la même manière qu’un load balancer
- Les relations inappropriées, comme l’arrivée d’un flux RSS dans une base de données, doivent être consignées et, si possible, supprimées
Le cas publickey.directory
- Le travail visant à fournir de la transparence des clés au Fediverse est suivi sur publickey.directory
- Ce travail a commencé avec la spécification public-key-directory-specification, qui inclut un modèle de menace
- Ce modèle de menace est structuré en sections suivantes
- Hypothèses
- Actifs
- Acteurs et noms de rôles, y compris les attaquants et les personnes que l’on cherche à protéger
- Risques et états des risques
- Les états de risque se répartissent en quatre catégories
- Prevented by design : l’attaque ne fonctionne pas par conception
- Mitigated : si les hypothèses ne sont pas fausses, l’attaque ne devrait pas réussir
- Addressable : il existe une méthode d’atténuation, mais elle demande des efforts ou de l’attention, et l’opérateur doit en être conscient
- Open : le risque ne peut pas être atténué, ou ne le sera pas ; l’attaque réussit donc
- Ce modèle de menace n’est pas parfait non plus
- Il ne relie pas complètement les relations entre actifs et acteurs dans un graphe facile à lire par un humain
- La section sur les risques peut comporter des angles morts non pris en compte
- Certaines hypothèses importantes pour la sécurité du système peuvent avoir été oubliées
Contraste entre Matrix et Signal
- Le Security Threat Model de Matrix v1.18 liste des types d’attaques comme le déni de service, le spoofing, le spam ou l’espionnage
- Ce document présente les problèmes suivants
- Il ressemble davantage à une liste de types d’attaques
- Il ne contient pas de liste d’hypothèses
- Il ne contient pas de liste des actifs ni de relations entre eux
- La liste des attaques est incomplète
- Même si Matrix est présenté comme une messagerie E2EE, le modèle de menace ne traite ni du chiffrement ni de la gestion des clés
- Le modèle de menace de Matrix n’a pas beaucoup changé depuis la v1.1, alors qu’entre-temps il y a eu des divulgations de vulnérabilités et deux attaques cryptographiques supplémentaires de Lotte
- Matrix dispose néanmoins d’un modèle de menace
- Signal fournit des spécifications techniques, mais laisse à l’utilisateur le soin de reconstituer lui-même le modèle de menace
- Même un mauvais modèle de menace vaut mieux qu’une absence totale de modèle de menace
Comment un modèle de menace améliore la conception
- Dans la pratique de la sécurité, on cite souvent l’adage selon lequel le défenseur doit toujours avoir raison, tandis que l’attaquant n’a besoin de réussir qu’une seule fois
- Si le défenseur est suffisamment préparé, il peut choisir le terrain sur lequel l’attaquant devra évoluer
- La vraie defense-in-depth implique de comprendre suffisamment le modèle de menace pour pousser l’attaquant vers des impasses prévisibles
-
Prévenir le credential stuffing
- Le credential stuffing est une attaque simple et excessivement efficace dans le monde réel
- Sa cause est la réutilisation des mots de passe par les utilisateurs
- Comme il est difficile pour les utilisateurs de mémoriser plusieurs mots de passe uniques et sûrs, les gestionnaires de mots de passe ont longtemps constitué une atténuation correcte
- Aujourd’hui, les passkeys sont considérées comme un meilleur choix
- Les passkeys sont une manière plus conviviale d’utiliser la cryptographie asymétrique pour l’authentification
- Dans le meilleur des cas, elles utilisent des jetons de sécurité matériels comme SoloKeys ou YubiKeys
- Dans le cas moyen, elles sont fournies par le système d’exploitation ou par un gestionnaire de mots de passe
- Pour éviter des attaques simples similaires au credential stuffing, il faut la conception suivante
- Concevoir l’application pour exiger les passkeys
- Faire enregistrer plusieurs passkeys par l’utilisateur, ou au minimum en exiger une de secours
- Fournir un chemin break glass permettant à un administrateur d’ajouter une nouvelle passkey pour un utilisateur qui a perdu tous ses identifiants
- Journaliser cette opération d’administration d’une manière que l’administrateur ne peut pas censurer
- Si possible, ne pas prendre du tout en charge les mots de passe d’authentification
- Les mots de passe destinés à la dérivation de clés de chiffrement sont acceptables dans un contexte séparé
- Les passkeys rendent le phishing impossible, car lors de l’enregistrement, l’identifiant est lié cryptographiquement au nom de domaine
- Même si l’onboarding des passkeys a un coût, il peut réduire davantage la charge de support liée au credential stuffing et au phishing
- En supprimant l’attente irréaliste selon laquelle les humains devraient mémoriser des secrets à haute entropie sans les réutiliser, on élimine plusieurs classes d’attaques tout en améliorant l’utilisabilité
- La phrase d’Avi Douglen, « La sécurité qui sacrifie l’utilisabilité sacrifie la sécurité », est citée
E2EE distribuée et modèles de menace
- Deux propositions sont discutées pour l’E2EE des messages directs
- La spécification ActivityPub E2EE, destinée aux logiciels du Fediverse, par exemple les DM privés de Mastodon
- Des projets comme Germ Network, avec le même objectif pour ATProto, par exemple BlueSky
- Les deux projets ont envisagé à un moment donné d’utiliser MLS comme protocole de gestion des clés de conversation E2EE
- Dans les systèmes décentralisés, MLS présente deux contraintes importantes
- MLS spécifie un concept abstrait appelé Authentication Service
- L’ordre des messages est important pour la sécurité du ratcheting tree qui sous-tend les epochs de MLS
- Si ActivityPub adopte la transparence des clés pour la première contrainte, il doit préciser comment traiter plusieurs messages KeyUpdate concurrents sur plusieurs serveurs
- La situation d’ATProto et de BlueSky est plus délicate
- ATProto n’a pas d’instances comme le Fediverse
- Dans l’analyse de sécurité, il faut presque le traiter comme du P2P
- Il peut être nécessaire d’utiliser un protocole complexe garantissant l’ordre des messages dans un système distribué, par exemple une approche comme le Raft consensus algorithm
- Ou bien il faut passer outre MLS et choisir l’E2EE pairwise, en renonçant à l’abstraction de groupe
- Si l’objectif de sécurité est la confidentialité des messages entre utilisateurs et que l’on cherche à distribuer l’hébergement, la conception de type blockchain d’ATProto devient un obstacle à l’utilisation des protocoles standardisés et efficaces actuels d’accord de clés de groupe
- La modélisation des menaces permet de faire apparaître ces contraintes de conception dès les premiers schémas
Le rôle de la modélisation des menaces dans le débat sur la PQC
- À propos des constructions post-quantiques hybrides, une discussion est en cours sur la liste de diffusion du groupe de travail TLS de l’IETF autour d’une RFC établissant des code points ML-KEM non hybrides
- Les prémisses de la discussion sont les suivantes
- ML-KEM n’est pas une conception de la NSA
- Le soumissionnaire principal est Peter Schwabe, qui a travaillé avec Daniel J. Bernstein et la bibliothèque cryptographique NaCl, et réside en Allemagne
- Les autres soumissionnaires se trouvent eux aussi dans plusieurs régions d’Europe
- Comme l’explique l’article de Sophie Schmieg, la théorie de l’information exclut une backdoor dans ML-KEM
- ML-KEM a été choisi par le NIST au terme d’un effort de normalisation international, public et mené sur dix ans
- NIST, FIPS et la NSA exigent ML-KEM et ML-DSA non hybrides pour les systèmes classifiés
- Le draft IETF en question spécifie ML-KEM non hybride et l’indique avec Recommend=N
- La RFC sur les KEM hybrides devrait être marquée Recommend=Y, et les KEM hybrides seront préférés aux KEM non hybrides
- Les systèmes configurés pour toujours utiliser des KEM hybrides ne subissent aucune baisse de sécurité du fait de l’existence d’une RFC ML-KEM
- Google Chrome prend déjà en charge ML-KEM non hybride, et cela ne changera pas même si l’IETF ne publie pas de RFC
- L’effet pratique de cette RFC est de lever les contraintes procédurales d’organisations qui doivent se conformer à CNSA 2.0, FIPS 140-3 ou à des règles similaires, et qui ont besoin d’un numéro de RFC IETF stable plutôt que d’un Internet Draft
- Ce problème peut être particulièrement courant dans certains secteurs vendant à des clients gouvernementaux
-
Différence entre Hybrid PQ+ECDH et Pure PQ
- Le risque rencontré avec les KEM n’est pas de « casser le chiffrement après le Q-Day », mais Harvest Now, Decrypt Later
- Q-Day est employé comme abréviation pour désigner le moment où l’attaquant disposera d’un ordinateur quantique pertinent pour la cryptographie
- Si l’on décompose le risque, on obtient ceci
- L’ECDH pur, c’est-à-dire sans PQ, est cassé rétroactivement au Q-Day
- Le PQ pur n’est pas cassé au Q-Day, sous l’hypothèse que l’algorithme PQ n’est pas cassé avant
- Hybrid PQ+ECDH constitue une couverture contre l’effondrement de l’algorithme avant le Q-Day, mais n’apporte rien par rapport au Pure PQ après le Q-Day
- Défendre ECDH + ML-KEM revient à reconnaître qu’à long terme, ML-KEM est un algorithme sûr
- Les raisons de préférer l’hybride se résument à deux points
- Il est plus facile à accepter qu’un algorithme totalement inconnu, ce qui accélère l’adoption du PQ
- Il permet de se couvrir contre l’effondrement algorithmique de ML-KEM ou de l’ensemble de la cryptographie fondée sur les réseaux euclidiens
- Pour se couvrir d’une manière qui résiste aussi aux ordinateurs quantiques cryptographiquement pertinents, il faut du PQ+PQ hybride
- Si l’on met l’accent sur la diversité algorithmique, un hybride à trois voies ML-KEM + HQC + ECDH est plus proche d’un argument honnête
- ML-KEM est un KEM fondé sur les réseaux euclidiens et considéré comme résistant aux attaques quantiques
- HQC est un KEM fondé sur les codes et considéré comme résistant aux attaques quantiques
- ECDH est l’approche actuellement utilisée, mais elle est vulnérable aux attaques quantiques
- La modélisation des menaces peut servir, dans ce type de débat, à distinguer les oppositions idéologiques des risques techniques
Conclusion
- Internet propose de nombreux guides qui traitent formellement des modèles de menace et des méthodologies associées
- L’objectif ici est de disposer d’un smoke test permettant d’évaluer rapidement la qualité et l’efficacité d’un document de modèle de menace
- Un bon modèle de menace doit aller au-delà de ce qui est protégé, des attaquants, des modes d’attaque et des défenses, et faire aussi apparaître les relations entre actifs, les hypothèses et les risques acceptés
1 commentaires
Avis sur Lobste.rs
Le « manque de courtoisie » est un motif valable pour signaler un commentaire ; si l’on veut rendre l’Internet technique meilleur, il faudrait peut-être arrêter de consommer le ton agressif que cet auteur emploie trop souvent sur son blog, et cesser de le recommander. On pourrait même envisager de bannir complètement ce domaine.
Et je pense qu’un protocole où « tout est graphe » devrait effectivement être traité comme un projet de recherche. La conclusion était en somme : « mince, les algorithmes de graphes sont vraiment difficiles à raisonner en pratique ».