Des chausses-trappes de sécurité en cryptologie
Des articles de périodiques aiment à décrire les produits de cryptologie en termes d’algorithmes et de longueur de clés. Les algorithmes font de bons titres: ils peuvent être expliqués en quelques mots et ils sont faciles à comparer les uns aux autres. “Le triple-DES gage de bonne sécurité”. “Des clés de 40 bits sont une sécurité faible.” ” Le RSA à 2048 bits est meilleur que le RSA à 1024 bits.”
Mais la réalité n’est pas aussi simple. Les clés plus longues ne signifient pas toujours plus de sécurité. Comparez l’algorithme cryptographique au verrou de votre porte d’entrée. La plupart des verrous ont quatre goupilles en métal, qui peuvent prendre chacune dix positions. Une clé place les goupilles dans une configuration particulière. Si la clé les aligne correctement, le verrou s’ouvre. De sorte qu’il n’y a que 10 000 clés possibles, et qu’un cambrioleur prêt à essayer les 10 000 possibilités est sûr d’entrer dans votre maison. Mais un verrou de qualité supérieure à 10 goupilles, qui autorise 10 miliards de clés distinctes, n’améliorera probablement pas la sécurité de votre maison. Des cambrioleurs n’essayent pas toutes les clés (une attaque systématique -“brute-force”); la plupart ne sont pas assez intelligents pour crocheter la serrure (une attaque cryptographique contre l’algorithme). Ils fracassent les fenêtres, donnent des coups de pieds dans les portes, se déguisent en policiers, ou bien dévalisent les détenteurs des clés avec une arme. Un groupe de voleurs en Californie mettait en défaut les systèmes de sécurité en attaquant les murs à la tronçonneuse. Contre ces attaques, de meilleures serrures ne sont d’aucun secours.
La cryptographie forte est très puissante quand elle est bien faite, mais ce n’est pas une panacée. Se focaliser sur les algorithmes cryptologiques tout en ignorant les autres aspects de la sécurité revient à défendre votre maison, non pas en dressant une barrière autour, mais en plantant un seul immense poteau devant en espérant que votre adversaire va juste s’y heurter. Les attaquants intelligents se contentent de contourner les algorithmes.
La société Counterpane Systems a passé des années à concevoir, analyser, et casser des systèmes cryptologiques. Alors que nous faisons de la recherche sur des protocoles et des algorithmes publiés, l’essentiel de notre travail est l’examen des produits réels. Nous avons conçus et mis au point des systèmes qui protègent la vie privée, assurent la confidentialité, fournissent de l’équité et facilitent le commerce. Nous avons travaillé sur du logiciel, sur du matériel autonome, et toute sorte de choses entre deux. Nous avons cassé notre part d’algorithmes, mais nous avons presque toujours trouvé des attaques qui contournaient complètement les algorithmes. Nous n’avons pas [alors] à essayer toutes les clés possibles, ni même à trouver une faille dans les algorithmes; nous exploitons les erreurs de conceptions, les erreurs de réalisations, et les erreurs d’installations. Quelquefois, nous inventons une nouvelle astuce pour casser un système, mais la plupart du temps nous exploitons les vieilles fautes classiques que les concepteurs répètent indéfiniment.
Les vulnérabilités des architectures cryptologiques.
Un système cryptologique ne peut pas être plus solide que l’algorithme de chiffrement, l’algorithme de signature numérique, les fonctions de condensations à sens unique et les codes d’authentifications de messages sur lesquels il repose. Cassez l’un d’entre eux, et vous avez cassé le système. Et, de la même façon qu’il est possible de construire une structure faible avec de solides matériaux, il reste possible de construire un système cryptologique faible en utilisant des algorithmes et des protocoles forts.
Nous trouvons souvent des systèmes qui “annulent la garantie” de leur cryptologie en ne l’utilisant pas correctement: oubli de la vérification de la taille des valeurs, réutilisation intempestive d’aléas qui ne devraient pas l’être, et ainsi à l’infini. Les algorithmes de chiffrement ne garantissent pas l’intégrité. Les protocoles d’échanges de clés ne garantissent pas toujours que les deux partenaires reçoivent une clé identique; dans un projet de recherche récent, nous avons découvert que certains—pas tous—systèmes qui utilisaient des clés liées cryptologiquement pouvaient être cassés, même si séparément chaque clé était sûre. La sécurité, c’est bien plus que de brancher un algorithme en espérant que le système fonctionne. Même de très bons ingénieurs, des compagnies respectables, et des efforts importants ne sont pas une garantie d’une réalisation robuste; notre travail sur l’algorithme de chiffrement du réseau de radiotéléphone digital aux États-Unis l’a bien montré.
Les générateurs de nombres aléatoires sont un autre point de fragilité des systèmes cryptologiques. De bons générateurs de nombres aléatoires sont difficiles à concevoir, car leur sécurité dépend bien souvent de particularités matérielles et logicielles; beaucoup de produits que nous avons examinés utilisent de mauvais générateurs. La cryptologie peut être forte mais si le générateur d’aléas produit des clés faibles, le système est beaucoup plus facile à casser. D’autres produits utilisent des générateurs d’aléas sûrs, mais ils n’utilisent pas assez d’aléas pour rendre la cryptologie sûre.
Récemment la société Counterpane Systems a publié de nouvelles classes d’attaques contre des générateurs de nombres aléatoires, en s’appuyant sur notre travail sur les architectures commerciales. L’une des choses les plus surprenantes que nous ayons trouvées est que des générateurs d’aléas spécifiques peuvent être sûrs pour un emploi, mais non sûrs pour d’autres: la généralisation d’analyses de sécurité est dangereuse.
Dans un autre rapport de recherche, nous nous sommes intéressés aux interactions entre des protocoles sûrs chacun séparément. Étant donné un protocole sûr, nous montrons comment construire un autre protocole sûr qui cassera le premier si tous sont employés avec les mêmes clés sur le même appareil.
Les vulnérabilités des réalisations
Beaucoup de systèmes font défaut suite à des erreurs de réalisation. Quelques systèmes ne garantissent pas que le texte clairement lisible soit détruit après avoir été chiffré. D’autres systèmes utilisent des fichiers temporaires pour protéger contre des pertes de données lors d’un arrêt système, ou bien font usage de la mémoire virtuelle pour augmenter la mémoire disponible; ces dispositifs peuvent accidentellement laisser le texte clair traîner sur le disque dur. Dans des cas extrêmes, le système d’exploitation peut laisser les clés sur le disque dur; un produit que nous avons analysé utilisait une fenêtre spéciale pour l’entrée du mot de passe. Le mot de passe restait dans la mémoire de la fenêtre même après sa fermeture. La force des moyens cryptologiques n’avait aucune importance, elle était annulée par par l’interface utilisateur.
D’autres systèmes connaissent des problèmes plus subtils; quelquefois la même donnée est chiffrée avec des clés distinctes, une forte et une faible. D’autres systèmes utilisent des clés maîtresses et des clés de sessions uniques; nous avons cassé des systèmes en utilisant des informations partielles sur ces différentes clés. Nous avons aussi vu des systèmes qui utilisent des mécanismes inadéquats de protections pour les clés maîtresses, s’appuyant de façon erronées sur les clés de sessions. Il est vital de sécuriser complètement toutes les méthodes d’accès à une clé, et pas seulement les plus évidentes.
Les systèmes de commerce électronique font souvent des choix d’implantations pour améliorer l’ergonomie. Nous avons trouvé dans ce secteur des vulnérabilités subtiles, quand les concepteurs n’examinaient pas complètement toutes les conséquences de sécurité de leurs arbitrages. Faire une conciliation de compte une fois par jour peut être plus facile, mais quel type de dégât un attaquant peut-il faire en quelques heures ? Est-ce que les mécanismes d’imputations ne peuvent pas être inondés et débordés pour masquer l’identité d’un attaquant ? Certains systèmes enregistrent les clés compromisent sur des listes noires; des attaques contre ces listes peuvent avoir des résultats fructueux. D’autres systèmes peuvent être brisés par des attaques de rejeu qui réutilisent des messages passés ou des fragments de messages passés pour tromper les différents partenaires.
Les systèmes qui permettent que les clés anciennes puissent être récupérées en cas d’urgence présentent une autre zone de vulnérabilités. Les bons systèmes cryptographiques sont conçus pour que les clés existent pour le temps le plus court possible; la récupération de clés détruit souvent les acquis de sécurité en contraignant les clés à être conservées après avoir été utilisées. De plus, les bases de données de récupérations de clés sont une source de vulnérabilité en elles-mêmes et ont à être conçues et construites de façons sécurisées. Dans l’un des systèmes que nous avons évalués, des failles dans la base de récupération des clés permettaient à des criminels de frauder et de se faire passer pour des utilisateurs autorisés.
Vulnérabilités liées aux mots de passe.
Beaucoup de systèmes sont cassés car ils reposent sur des mots de passe choisis par l’utilisateur. Laissés à eux-mêmes les utilisateurs ne choisissent pas des mots de passe forts. S’ils sont forcés d’utilisr des mots de passe forts, ils ne peuvent s’en souvenir. Si le mot de passe devient une clé, il est en général plus facile – et plus rapide- de deviner le mot de passe que de rechercher systématiquement la clé; nous avons vu des systèmes de sécurité élaborés tomber en défaut de cette façon. Quelques interfaces d’utilisations font encore empirer le problème: elles limitent les mots de passe à huit caractères, convertissent tout en minuscules, et ainsi de suite. Même les phrases clés peuvent être faibles: rechercher des phrases de 40 caractères est souvent plus facile que de rechercher de clés aléatoire de 64 bits. Nous avons aussi vu des système de récupérations de clés qui contournaient des clés de sessions fortes en utilisant des mots de passes faibles pour la récupération de clés.
Vulnérabilités du matériel.
Quelques systèmes, en particuliers les systèmes pour le commerce, s’appuient sur du matériel résistant à la pénétration pour la sécurité: cartes à micro-circuits, portefeuilles électroniques, bouchons, etc. Ces systèmes peuvent supposer que des terminaux publics ne tomberont jamais dans des mains malveillantes, ou bien que ces mains malveillantes manquent de la connaissance et de l’équipement pour attaquer le matériel. Bien que la sécurité apporté par le matériel soit une composante importante dans beaucoup de systèmes sécurisés, nous ne faisons pas confiance à des systèmes dont la sécurité repose uniquement sur l’hypothèse de la résistance à la pénétration. Nous avons rarement vu des techniques de résistances à la pénétration opérationnelles et les outils de pénétration s’améliorent tous les jours. Quand nous concevons des systèmes qui utilisent la résistance à la pénétration, nous y incorporons toujours des mécanismes de sécurité complémentaires au cas où la pénétration aurait lieu.
L'”attaque temporelle” a eu un grand succès de presse [aux États-Unis] en 1995: des clés privées RSA pouvaient être récupérées en mesurant les temps relatifs pris par les opérations cryptographiques. Cette attaque a été réalisée avec succès contre des cartes à micro-circuits, contre d’autres calculettes de sécurité, et contre des serveurs de commerce électronique à travers l’Internet. La société Counterpane Systems et d’autres ont généralisé ces méthodes pour y inclure des attaques sur des systèmes en mesurant la consommation, les émissions radioélectriques, et d’autres “canaux latéraux”; ils les ont réalisées contre plusieurs types d’algorithmes à clé publique ou à clé unique dans des calculettes “sécurisées”. Il nous faut encore trouver une carte à micro-circuit telle que nous ne puissions en extraire les clés par des canaux latéraux. Une recherche voisine s’est intéressée à l’analyse d’erreurs: l’introduction délibérée d’erreurs dans les processeurs cryptographiques pour déterminer les clés secrètes. Les effets de cette attaque peuvent être dévastateurs.
Vulnérabilité des modèles de la confiance
Beaucoup de nos attaques les plus intéressantes visaient le modèle sous-jacent de la confiance dans le système: à qui ou à quoi fait-on confiance dans le système, de quelle façon, et à quel degré. Des systèmes très simples comme des programmes de chiffrement de disques durs ou la protection de conversations téléphoniques privées ont des modèles de confiance simples. des systèmes complexes, comme des systèmes de commerce électronique ou des programmes de messageries sécurisées multi-utilisateurs ont des modèles de confiance complexe et subtils. Un programme de messagerie peut utiliser de la cryptographie non cassable pour les messages, mais à moins que les clés ne soient certifiées par une source de confiance (et à moins que la certification ne puisse être vérifiée), le système reste vulnérable. Quelques systèmes de commerce électroniques peuvent être cassés par la collusion d’un marchand et d’un client, ou par la collusion de deux clients. D’autres systèmes font des hypothèses implicites sur les infrastructures, et ne s’occupent pas de contrôler la réalité de ces hypothèses. Si le modèle de la confiance n’est pas documenté, alors un ingénieur peut, sans s’en rendre compte, le modifier au cours du développement du produit et compromettre la sécurité.
Beaucoup de systèmes logiciels font de mauvaises hypothèses quant à la confiance à accorder aux ordinateurs sur lesquels ils tournent; ils supposent que le bureau est sûr. Ces programmes peuvent souvent être cassés par des chevaux de Troie en logiciel qui reniflent les mots de passe, lisent les textes clairs, ou contournent de toute autre façon les mesures de sécurité. Les systèmes qui travaillent à cheval sur des réseaux doivent se soucier des failles de sécurité liés aux protocoles de réseaux. Les ordinateurs connectés au réseau Internet sont aussi vulnérables. À nouveau, la cryptologie est inutile si elle peut être contournée par l’insécurité du réseau. Et aucun logiciel ne résiste à la rétro-analyse.
Souvent, un système sera conçu avec un modèle de confiance en tête, et implanté avec un autre. Des décision prises pendant la phase de conception pourraient être complètement ignorées quand on en arrive au moment de la vente aux clients. Un système qui est sûr quand les opérateurs sont des personnes de confiance et quand les ordinateurs sont sous le contrôle total de l’entreprise peut ne plus l’être si les opérateurs sont des intérimaires au salaire minimum et si les ordinateurs ne sont pas contrôlés. Les bons modèles de confiance [politique de sécurité ] sont ceux qui marchent quand bien même certaines hypothèses de confiance s’effondrent.
Vulnérabilités des utilisateurs.
Même quand un système est sécurisé sous réserve d’une utilisation correcte, ses utilisateurs peuvent mettre en danger la sécurité par accident -en particulier si le système n’est pas bien conçu-. L’exemple le plus classique en est l’utilisateur qui donne son mot de passeà ses collègues pour qu’ils dépannent des problèmes en son absence. Les utilisateurs peuvent ne pas rendre compte de la perte d’une carte à micro-circuit pendant quelques jours, au cas où elle aurait été mal rangée. Ils peuvent ne pas vérifier soigneusement le nom sur un certificat numérique. Ils peuvent réutiliser leurs mots de passe sûrs sur des systèmes non sûrs. Ils peuvent ne pas changer la configuration faible par défaut de leur logiciels. Une bonne conception système ne peut résoudre tous ces problèmes d’organisation, mais elle peut éviter beaucoup d’entre eux.
Vulnérabilité de la reprise après incident.
Des systèmes forts sont conçus pour empêcher de petits incidents de sécurité de devenir grands. Récupérer la clé pour un fichier ne doit pas permettre à l’attaquant de lire tous les fichiers du disque dur. Un pirate [corsaire ou flibustier] qui rétro-analyse une carte à micro-circuit ne doit apprendre que les secrets de cette carte, mais aucune information qui l’aiderait à casser d’autres cartes du système. Dans un système à plusieurs utilisateurs, la connaissance des secrets d’une personne ne doit pas compromettre ceux des autres.
Beaucoup de systèmes sont par défaut “en mode non sécurisé”. Si les fonctionnalités de sécurité ne marchent pas , la plupart des personnes se contentent de les débrancher et terminent leur travail. Si le système de vérification par le réseau de cartes de crédit est en panne, le commerçant revient au système du fer à repasser, bien moins sûr. De la même façon, il est possible de monter une attaque “retour à la version antérieure” contre un système après qu’il ait été mis à jour pour régler un problème de sécurité: le besoin de compatibilité arrière permet à un attaquant de forcer le protocole dans une version plus ancienne et non sûre.
D’autres systèmes n’ont pas de capacité à survivre à un désastre. Si la sécurité est cassée, il n’y a pas de moyen de la réparer. Pour des systèmes de commerce électronique qui peuvent avoir plusieurs millions d’utilisateurs, les dégâts peuvent être considérables. De tels systèmes doivent planifier la réponse aux attaques, et la mise à jour de la sécurité sans avoir à arrêter le système. La phrase “et alors l’entreprise a été arnaquée” n’est pas quelque chose que vous voulez faire figurer dans votre plan de développement. Une bonne conception de système prévoit ce qui va se passer quand une attaque se produit, et construit les moyens de limiter les dégâts et de survivre à l’agression.
Vulnérabilités cryptographiques
Quelques fois, des produits ont même une mauvaise cryptologie. Certains reposent sur des algorithmes de chiffrement spécifiques à un fournisseur; invariablement, ils se révèlent très faibles. La société Couterpane Systems a eu un succès considérable à casser des algorithmes de chiffrement publiés; notre palmarès est encore meilleur pour les algorithmes spécifiques. Maintenir secret un algorithme ne constitue pas un obstacle pour l’analyse, de toute façon – cela ne prend que quelques jours pour reconstituer par rétro-analyse l’algorithme à partir du code exécutable. Un système qu e nous avons analysé, la norme S/MIME 2 de messagerie sécurisée, avait une conception relativement forte mais le réalisait avec un algorithme de chiffrement faible. Le système pour les disques DVD prenait un algorithme faible et le rendait encore plus faible.
Nous avons vu bien d’autres erreurs de type cryptologique: des réalisations qui répétaient des valeurs aléatoires “uniques”, des algorithmes de signatures qui ne vérifiaient pas correctement les paramètres, des fonctions de condensation modifiées pour défaire les propriétés pour lesquelles on les utilise. Nous avons vus des protocoles cryptologiqques utilisés de manière non prévue par les concepteurs du protocole et des protocoles “optimisés” de façon apparemment simple ce qui cassait complètement leur sécurité.
Empêcher ou détecter les attaques
La plupart des systèmes cryptologiques reposent sur l’interdiction comme seul moyen de défense: les moyens cryptologiques empêchent les personnes de tricher, de mentir, de mal faire etc. La défense ne doit pas être aussi bornée. Un système fort cherche aussi à détecter la malveillance et à contrôler les effets de toute attaque. L’un de nos principes fondamentaux de conception est que tôt ou tard , tout système sera attaqué avec succès, probablement d’une façon totalement inattendue et avec des conséquences inattendues; il est important d’être capable de détecter une telle attaque, et lors de contrôler cette attaque pour assurer que les dommages seront réduits.
Encore plus important, une fois que l’attaque est détectée, le système doit pouvoir reprendre de façon sûre: générer et promulguer de nouvelles paires de clés, mettre à jour le protocole et bloquer la version antérieure, supprimer le noeud douteux du système, etc. Malheureusement, beaucoup de systèmes ne recueillent pas assez de données pour avoir des traces d’imputation, ou simplement ne réussissent pas à protéger ces données des modifications. La société Counterpane Systems a fait un travail considerable pour securiser les traces électroniques dan les systèmes de commerce életroniques, principalement pour répondre aux architectures de systèmes qui pouvaient se bloquer complètement en cas d’agression réussie. Ces systèmes font bien plus que de détecter une attaque: ils sont aussi capables de produire des éléments de preuves utilisables pour convaincre un juge et des jurés de la culpabilité d’une personne.
Construire des systèmes cryptologiques sûrs.
Les concepteurs de sécurité occupent ce que le général prussien Carl von Clausewitz appelle ” la position intérieure”. Un bon produit de sécurité doit défendre contre toute attaque possible, y compris contre des attaques qui n’ont pas encore été inventées. Les agresseurs, par ailleurs, n’ont besoin que de trouver une seule brèche pour neutraliser le système. Et ils peuvent tricher. Ils peuvent agir par collusion, par conspiration et attendre que la technique leur donne de meilleurs outils. Ils peuvent attaquer le système par des voies inimaginables par le concepteur du système.
La construction d’un système cryptologique sûr est facile à rater et très difficile à bien réussir. Malheureusement, la plupart des personnes ne peuvent voir la différence. Dans d’autres domaines de l’informatique, les fo nctionnalités servent à trier le bon grain de l’ivraie: un bon algorithme de compresssion marche mieux qu’un mauvais; un mauvais programme de compression fera très mauvais effet dans les tableaux comparatifs fonctionnels. La cryptologie [comme la sécurité des système d’information] est différente. Ce n’est pas parce qu’un programme de chiffrement fonctionne qu’il est sûr. Ce qui arrive avec la pluspart des produits est que quelqu’un lit le livre “Cryptographie appliquée”, choisit un algorithme et un protocole, le teste pour vérifier qu’il fonctionne bien et pense qu’il a terminé. Ce n’est pas le cas. Le bon fonctionnement n’est pas un gage de qualité, et aucun essai préliminaire, aussi long soit-il, ne révélera une faille de sécurité. Beaucoup trop de produits sont simplement “conformes à la mode”, ils utilisent de la cryptologie sûre, mais ils ne sont pas sûrs.
Courtesy translation to french.
Traduction gracieuse en français.
[] are translation adjustements, as are emphases.
[] sont les ajouts du traducteur, comme les mises en valeurs
References remains to be supplied.
Il reste à compléter par des références.