vertical title

title component

main title

La cryptographie forte est très puissante lorsqu'elle est réalisée correctement, mais elle n'est pas la panacée. Se focaliser sur les algorithmes cryptographiques en ignorant les autres aspects de la sécurité c'est comme défendre votre maison sans construire de grillage autour, mais en plaçant un pieu immense dans le sol et en espérant que votre adversaire ira s'empaler dessus.

Bruce
Schneier

Counterpane
Systems

 

big l letter

es magazines populaires décrivent souvent les produits de cryptographie en termes d'algorithmes et de longueurs de clefs. Ces techniques de sécurité font de bons titres. Ils peuvent être expliqués en quelques mots et ils sont faciles pour comparer les produits entre-eux. Nous avons vu des déclarations comme: "des clefs de 128 bits offrent une meilleure sécurité, tandis que les clefs de 40 bits sont faibles" ou bien "le triple-DES est beaucoup plus fort que le DES simple" et même "le RSA 2048 bits est meilleur que le RSA 1024 bits".

  Malheureusement, la cryptographie n'est pas aussi simple. Des clefs plus longues ne garantissent pas plus de sécurité.

  Comparez l'algorithme cryptographique au verrou de votre porte. La plupart des verrous ont quatre broches, chacune pouvant adopter une position sur dix. Une clef métallique déplace les broches dans une configuration précise. Si la clef les aligne correctement, le verrou s'ouvre. Il n'y a que 10 000 clefs possibles, et un voleur qui voudra tenter toutes les 10 000 combinaisons est sûr de pouvoir entrer dans votre maison.

  Mais un verrou amélioré avec 10 broches &endash; ce qui fait 10 milliards de clefs possibles &endash; ne rendra pas votre maison plus sûre. Les voleurs n'auront même pas à essayer chaque clef possible (ce que nous appelons une attaque de force-brute); la plupart ne sont pas assez habiles pour crocheter la serrure (ce qui revient à réaliser une attaque cryptographique). Non; ils vont briser les fenêtres, défoncer les portes et se déguiser en policiers, voler les détenteurs des clefs à la force des pistolets. Une anecdote: en Californie, un groupe de voleurs de grand art entrait dans les appartements en utilisant des tronçonneuses pour faire des trous des les murs. Les meilleurs verrous ne peuvent empêcher ces attaques.

  La cryptographie forte est très puissante quand elle est réalisée correctement, mais elle n'est pas la panacée. Se focaliser sur les algorithmes cryptographiques en ignorant les autres aspects de la sécurité c'est comme défendre votre maison sans construire de grillage autour, mais en plaçant un pieu immense dans le sol et en espérant que votre adversaire ira s'empaler dessus. Les attaquants intelligents feront en sorte de contourner les algorithmes.

  Counterpane Systems a consacré des années à concevoir, analyser et casser des systèmes cryptographiques. Tandis que nous avons réalisé des recherches sur des algorithmes et protocoles publiés, la plupart de nos travaux examinent des produits existants.
Nous avons conçu et analysé des systèmes qui protègent la vie privée, assurent la confidentialité, créent une égalité et favorisent le commerce. Nous avons travaillé sur du logiciel, des matériels dédiée et tout ce qui se trouve entre. Nous avons cassé notre lot d'algorithmes, mais ne n'avons pas toujours trouvé des attaques qui contournent tous les algorithmes.

  Nous n'avons pas eu à essayer chaque clef ou même rechercher des failles dans les algorithmes. Nous avons exploité des erreurs dans la conception, dans l'implémentation et l'installation. Parfois nous avons inventé une nouvelle technique pour briser un système, mais la plupart du temps nous avons exploité les erreurs qui sont toujours les mêmes et que les concepteurs font encore et encore. Cet article rapporte quelques leçons que nous avons apprises.

ATTAQUES CONTRE LA CONCEPTION

Un système cryptographique ne peut être plus fort que ses algorithmes de chiffrement, de signature numérique, fonctions de hachage à sens unique et d'authentification de message. En d'autres mots, si vous cassez un seul élément, vous brisez tout le système. Et comme il est possible de construire un bâtiment vacillantt avec des matériaux solides, il est possible de construire un système cryptographique faible avec des algorithmes et des protocoles forts.

  Beaucoup de systèmes "annulent la garantie" de leur cryptographie à cause d'un mauvais usage: ils oublient de vérifier la taille des valeurs, réutilisent des paramètres aléatoires qui ne doivent jamais être utilisés plus d'une fois, et ainsi de suite. Les algorithmes de chiffrement n'apportent pas toujours une vérification de l'intégrité des données. Les protocoles d'échange de clefs ne s'assurent pas nécessairement que les deux parties reçoivent la même clef.

  Certains &endash; pas tous &endash; systèmes qui utilisent des clefs cryptographiques liées peuvent être cassés, bien que chaque clef soit individuellement sûre. La sécurité c'est beaucoup plus qu'utiliser un algorithme et espérer que le système fonctionne. Même des bons ingénieurs, des compagnies réputées et beaucoup d'efforts ne garantissent pas une implémentation robuste. Des faiblesses cryptographiques découvertes dans le Code Division Multiple Access (CDMA) et le chiffrement des Global System for Mobile §GSM) ainsi que dans le protocole Microsoftt Point-to-Point Tunneling Protocol (PPTP) l'illustrent. Dans PPTP, par exemple, nous avons découvert que l'algorithme fort RC4 est utilisé dans un mode qui annule complètement sa sécurité.



L'infrastructure globale à clef publique: termes et concepts

Andrew Csinger, Xcert Software
Keng Siau, université de Nebraska, Lincoln

Dans un sens, vous n'êtes pas un citoyen de votre pays à moins de ne pouvoir prouver votre nationalité. Et vous ne pourrez pas faire partie de l'infrastructure globale à clef publique (GPKI) tant que vous n'êtes pas un citoyen authentique de la communauté électronique globale.

Clefs publiques et privées
   
La cryptographie à clef publique implique l'utilisation de deux clefs &endash; une clef privée et une clef publique &endash; qui sont liées mathématiquement afin qu'un message chiffré avec une clef puisse être déchiffré par la seconde. Il est très difficile &endash; si ce n'est pas impossible &endash; de déterminer la valeur d'une clef par l'examination d'une autre.
   La clef publique est souvent appelée la clef de chiffrement. Pour envoyer un message à Jacques &endash; et que seul Jacques pourra lire &endash; Julien utilisera la clef publique de Jacques. Ce dernier utilisera alors sa clef privée pour déchiffrer le message. Lorsque Jacques transmet sa réponse, il utilisera la clef publique de Julien, et Julien utilisera sa clef privée pour la déchiffrer.

   De cette manière, la cryptographie à clef publique assure la confidentialité.

Résumés
   Ceux qui envoient les messages peuvent aussi signer numériquement leurs messages afin que les destinataires puisse avoir l'assurance que le message est authentique. D'abord, l'utilisateur crée une empreinte unique du message &endash; ou résumé &endash; en utilisant une fonction mathématique de hachage à sens unique. Le résultat du chiffrement du résumé avec la clef privée sera la signature, qui sera transmise avec le message.
   Le destinataire qui reçoit le message déchiffre le message et crée à nouveau le résumé en utilisant la même fonction de hachage. Déchiffrer la signature avec la clef publique de l'émetteur du message produit le résumé original. Si les deux résumés sont identiques, alors le message reçu est authentifié et il n'a pas été altéré pendant la transmission.
   De cette manière, la cryptographie à clef publique assure aussi bien l'authenticité et l'intégrité. Elle assure que celui qui signe numériquement un message ne pourra désavouer sa signature plus tard.

Certificats de clef publique
   Un certificat de clef publique est un document digital qui lie irrévocablement l'identité d'une personne à une clef publique. Les certificats peuvent être utilisés comme un élément du processus de signature numérique de documents au sens du Droit, en garantissant que le message n'est transmis et lisible que par les destinataires choisis.

Comme les signatures numériques, les certificats garantissent l'identité d'un individu.
   Une autorité de certification (CA) crée des certificats. Un CA peut être un service maintenu par ou pour une partie de la communauté qui décide qui peut faire partie de la communauté, et disposer de ses privilèges. Un CA peut aussi être une entité du gouvernement qui distribue des certificats au public en conjonction avec la législation qui spécifie l'interprétation possible des signatures numériques.

Communautés d'intérêt
   
Une communauté d'intérêt (COI) est comme un pays ou une confrérie. Soit vous êtes membre, soit vous ne l'êtes pas. Au contraire des pays, les communautés d'intérêt ne connaissent pas de limites géographiques. En fait, elles ne connaissent aucune limite du tout.
   Par exemple, les lecteurs d'un magazine forment un COI. Si un magazine veut mettre son éditorial disponible sur Internet uniquement à leurs lecteurs, et seulement à leurs lecteurs, il devient un COI.
   Peu de temps après le développement de la technologie des certificats, il est devenu évident que les communications autour des CA est critique. Désormais, un COI peut décider s'il veut ou pas honorer les CA produits par un autre COI. Chaque COI peut les honorer comme il l'entend, soit en les considérant équivalents au siens, sois avec un accès restreint.



Les générateurs de nombres aléatoires sont aussi un autre point où les systèmes cryptographiques échouent souvent. Les bons générateurss de nombres aléatoires sont difficiles à concevoir parce que la sécurité dépend souvent des particularités du matériel et du logiciel1. Leur cryptographie peut être forte, mais si le générateur de nombres aléatoires produit des clefs faibles, le système est beaucoup plus facile à casser. Certains produits utilisent des générateurs de nombres aléatoires sûrs, mais ils n'utilisent pas assez d'aléatoire pour rendre la cryptographie sûre. L'un des résultats les plus surprenants dans ce domaine sont des générateurs de nombres aléatoires qui peuvent être sûrs dans certaines applications, et n'avoir aucune sécurité dans d'autres.

  D'autres attaques utilisent les interactions entre des protocoles cryptographiques individuellement sûrs2. Étant donné un protocole sûr, il est parfois possible de construire un autre protocole sûr qui cassera le premier si les deux sont utilisés avec la même clef sur le même appareil. Considérée la prolifération des standards divers de sécurité qui utilisent la même infrastructure, ce type d'interaction est potentiellement très dangereux.

ATTAQUES CONTRE L'IMPLEMENTATION

  Beaucoup de systèmes échouent à cause d'erreurs dans l'implémentation. Certains systèmes n' assurent pas que le texte clair est détruit après son chiffrement. D'autres systèmes utilisent des fichiers temporaires pour se prémunir contre la perte de données en cas de plantage système, ou bien la mémoire virtuelle utilisée pour augmenter la quantité de mémoire disponible. Ces fonctionnalités peuvent laisser accidentellement traîner du texte en clair sur le disque dur.

  Les dépassements de tampons, les secrets mal effacés, et les mauvais contrôles d'erreurs sont tous des exemples de mauvaises implémentations qui peuvent être exploitées.

  Dans des cas extrêmes, le système d'exploitation pourrait laisser les clefs sur le disque dur. Un produit par une compagnie très importante utilise une fenêtre spéciale pour l'entrée du mot de passe. Mais ce dernier reste dans la mémoire réservée pour la fenêtre, bien après qu'elle soit refermée. La cryptographie d'un produit peut être bonne, mais elle ne sert à rien si elle peut être brisée à cause de son interface utilisateur.

  D'autres systèmes échouent à cause de vulnérabilités plus subtiles. Parfois, une même donnée est chiffrée deux fois de suite, avec deux clefs, une forte et une faible. D'autres systèmes utilisent une clef principale et des clefs de session à usage unique. Certains pourront malgré cela être brisés au-travers de la récupération partielle d'informations au sujet de plusieurs clefs. Et certains systèmes ont une protection inadaptée des clefs maîtres, en faisant reposer par erreur leur sécurité sur des clefs de sessions. Il est vital de déterminer tous les moyens possibles d'obtenir une clef, et pas seulement les plus évidents.

  Les systèmes de commerce électronique utilisent souvent des améliorations qui visent à améliorer la facilité d'utilisation. Il y a là beaucoup de subtilités, et bien souvent les concepteurs n'imaginent pas les implications des modifications qu'ils apportent. Réaliser une comparaison de données une fois par jour, par exemple, peut être plus facile, mais quel type de dégâts un attaquant peut réaliser en quelques heures? Est-ce que les mécanismes de surveillance peuvent être submergés de données afin de cacher l'identité d'un attaquant? Certains systèmes conservent des listes de clefs compromises dans un fichier; les attaques contre ces listes sont souvent très fructueuses. D'autres systèmes peuvent être brisés en rejouant des informations déjà échangées, soit en utilisant des anciens messages, soit en utilisant des parties de messages, afin de tromper les parties en présence.

Les systèmes qui permettent la récupération d'anciennes clefs en cas d'urgence, les systèmes à dépôt de clef, fournissent une autre zone où l'attaque est possible4. Les bons systèmes cryptographiques sont conçus afin que les clefs n'existent que pendant la période la plus courte possible; la récupération de clef annule bien souvent le bénéfice de sécurité en forçant l'existence des clefs bien au-delà de leur période d'utilisé. Qui plus est, les bases de données contenant les clefs sont elles-mêmes des sources de vulnérabilité et doivent être conçues et implémentées avec la plus grande sécurité. Dans certains systèmes publiés, des failles dans les bases de données de récupération de clefs pourraient permettre à des criminels de commettre des fraudes, qui feraient alors accuser les utilisateurs légitimes.

ATTAQUES CONTRE LE MATÉRIEL

  Certains systèmes, en particulier ceux destinés au commerce, reposent sur un "périmètre de sécurité", du matériel résistant à l'investigation comme les cartes intelligentes, les valises électroniques et les dongles. Ces systèmes sont basés sur une notion où les secrets au sein du périmètre de sécurité ne peuvent être manipulés par ceux qui ne disposent pas d'un accès. Tandis que la sécurité matérielle est une composante importante dans beaucoup de systèmes protégés, il est prudent de ne pas faire confiance aux systèmes dont la sécurité ne repose que sur des hypothèses sur la résistance à l'investigation.

  La plupart des techniques de résistance à l'investigation ne fonctionnent pas, et les outils pour passer outre ces résistancess s'améliorent au fur et à mesure5,6. Lors de la conception des systèmes qui utilisent la résistance à l'investigation, il est important de construire des mécanismes de sécurité complémentaires, au cas où la résistance à l'investigation échouerait.

  Il est tout aussi important de s'assurer que la valeur des données à protéger est bien plus réduite que le coût estimé pour briser la sécurité contre l'investigation.

  Le coût des protections physiques d'un système pour surveiller le trafic et les accès des transports publics est bien plus réduit que celui d'un système conçu pour protéger les échanges commerciaux électroniques.

  L'attaque par "mesure du temps" a fait beaucoup de bruit en 1995; les clefs privées RSA pouvaient être récupérées en mesurant le temps relatif des opérations cryptographiques7. L'attaque a été réalisée avec succès contre les cartes intelligentes et autres matériels de sécurité, et contre les serveurs de commerce électronique au-travers d'Internet. Les cryptographes ont généralisé ces méthodes pour créer de nouveaux types d'attaques, en mesurant la consommation électrique d'un appareil, les radiations électromagnétiques produites et d'autres "voies parallèles", et ils ont implémenté ces attaques contre une grande variété d'algorithmes à clef publique dans des éléments "sûrs"8.

ATTAQUES CONTRE LES MODÈLES DE CONFIANCE

Nous dirigeons beaucoup de nos attaques les plus intéressantes contre le modèle de confiance sous-jacent; qui ou quoi dispose de la confiance du système, de quelle manière et dans quelle étendue. Des systèmes simples &endash; comme les programmes de chiffrement des disques durs ou les produits de protection des communications par téléphone &endash; ont des modèles de confiance simples. Les systèmes plus complexes &endash; comme les systèmes de commerce électronique ou les programmes de sécurité pour le courrier électronique dans un cadre multi-utilisateur &endash; ont des modèles de confiance aussi complexes que subtils, impliquant de nombreuses parties.

Construire un système cryptographique sans sécurité est facile et concevoir un système sûr est difficile.
Malheureusement, la plupart des gens sont incapables de faire la différence.

Un logiciel de courrier électronique pourrait utiliser une cryptographie incassable pour ses messages, mais à moins que les clefs ne soient certifiées par une source de confiance (et à moins que la certification ne puisse être vérifiée en temps réel) le système reste vulnérable. Certains systèmes de commerce électronique peuvent être brisés par un commerçant et un client qui travaillent ensembles, ou par deux clients différents de connivence. D'autres systèmes font des hypothèses implicites au sujet des structures de sécurité, mais ne se soucient pas de vérifier que ces hypothèses sont actuellement vraies. Si le modèle de confiance n'est pas documenté, alors un ingénieur peut modifier secrètement le produit pendant son développement afin d'en compromettre la sécurité.

  Beaucoup de systèmes logiciels font des hypothèses médiocres au sujet des ordinateurs sur lesquels ils sont utilisés. Ces programmes peuvent presque toujours être brisés par l'utilisation d'un cheval de Troie, qui récupère les mots de passe, capturent le texte sous sa forme claire, ou contournent par toute autre manière les systèmes de sécurité. Les systèmes qui fonctionnent au travers de réseaux informatiques ont aussi des failles dans leur sécurité à cause des protocoles utilisés sur le réseau. Les ordinateurs qui sont reliés à Internet sont aussi vulnérables.

  A nouveau, la cryptographie peut être inadéquate si elle peut être contournée au travers de l'insécurité du réseau. Et aucun logiciel n'est sûr contre le désassemblage. Bien souvent, un système sera conçu avec un modèle de confiance à l'esprit, et un autre pour son implémentation. Les décisions prises pendant le processus de développement peuvent être complètement ignorés lorsqu'il est temps de vendre le produit aux clients. Un système qui est sûr quand ses opérateurs sont de confiance, sur des ordinateurs qui sont tous sous contrôle de la compagnie qui utilise le système peut ne pas être sûr lorsque les opérateurs sont payés au minimum de salaire et que les ordinateurs ne sont pas protégés.

ATTAQUES CONTRE LES UTILISATEURS

Même lorsqu'un système est sûr s'il est utilisé correctement, ses utilisateurs peuvent détourner sa sécurité par accident &endash; en particulier si le système n'est pas très bien conçu8 &endash; et l'exemple classique est celui de l'utilisateur qui donne son mot de passe à son collaborateur afin qu'il puisse régler un problème alors qu'il n'est pas au bureau. Ces attaques que l'on appelle d'ingiénerie sociale donnent souvent de meilleurs résultats que des mois de cryptanalyse9.

  Les utilisateurs pourraient ne pas signaler que des cartes intelligentes sont manquantes pendant quelques jours, pensant qu'elles sont mal rangées ou égarées. Ils pourraient ne pas vérifier dans le détail le nom d'un certificat numérique. Ils pourraient utiliser plusieurs fois de suite le même mot de passe sur plusieurs systèmes, certains à faible sécurité. Ils pourraient ne pas modifier les préférences par défaut de leurs logiciels, qui créent un environnement sans sécurité. Les bonnes conceptions de systèmes ne peuvent corriger tous ces problèmes sociaux, mais ils peuvent en éviter beaucoup.

  Beaucoup de systèmes sont cassés parce qu'ils reposent sur des mots de passe produits par les utilisateurs. Abandonnés à eux-mêmes, les gens ne choisissent pas des mots de passe assez forts.

  S'ils sont forcés à utiliser des mots de passe forts, ils ne s'en souviennent généralement pas. Si le mot de passe devient une clef, il est généralement beaucoup plus facile &endash; et rapide &endash; de deviner le mot de passe plutôt que d'obtenir la clef par une attaque de force brute; nous avons vu des systèmes élaborés échouer de la sorte.

  Certains interfaces utilisateur rendent le problème pire encore, en limitant les mots de passe à huit caractères, en les convertissant en minuscules, et ainsi de suite. Même des phrases passe peuvent être faibles: faire une recherche sur des phrases passe de 40 caractères est souvent bien plus facile que de faire une recherche sur les 64 bits aléatoires d'une clef. Parfois, les systèmes de récupération de clefs contournent des clefs de session très fortes en utilisant des mots de passe faibles pour la récupération des clefs. Le désir de redondance contre les échecs ouvre une porte secrète aux attaquants.

ATTAQUES CONTRE LA RÉCUPÉRATION D'UNE ERREUR

Les systèmes forts sont conçus afin d'empêcher que de petits failles de sécurité deviennent des failles plus grandes. Récupérer une clef vers un fichier ne devrait pas permettre à un attaquant de lire tous les fichiers d'un disque dur. Être capable de frapper de la fausse monnaie est un crime grave; être un capable d'écrire un programme qui permet à tout le monde de faire de la fausse monnaie peut détruire une économie. Un pirate qui désassemble une carte intelligente ne devrait pouvoir découvrir que les secrets de cette carte, et aucune information qui pourrait l'aider à briser d'autres cartes au sein du système. Dans un système multi-utilisateur, connaître les secrets d'une personne ne doit pas compromettre ceux des autres.

  Beaucoup de systèmes ont par défaut un mode sans sécurité. Si la fonction de sécurité ne fonctionne pas, alors la plupart des gens la désactiveront pour accomplir leur travail. Ceci rend les attaques de refus-de-service très efficaces! Si le système de vérification des cartes de paiement en-ligne ne fonctionne plus, les commerçants passeront à un système papier moins sûr.

  De manière similaire, il est parfois possible de réaliser une attaque par compatibilité arrière contre un système qui a été modifié pour corriger un problème de sécurité: le besoin de compatibilité arrière permet à un attaquant de forcer le système à utiliser une ancienne version, bien moins sûre.
   D'autres systèmes n'ont aucune capacité à récupérer d'un désastre. Si la sécurité est brisée, il n'y a alors aucun moyen de la réparer. Pour les systèmes de commerce électronique, qui peuvent disposer de millions d'utilisateurs, ceci peut s'avérer particulièrement désastreux. Ces systèmes devraient pouvoir répondre aux attaques, et être capables de mettre à jour la sécurité sans interrompre le fonctionnement du système.

  La phrase "et alors la compagnie ferma" n'est jamais quelque chose que vous souhaitez voir apparaître dans vos plans commerciaux. Les bons concepts de systèmes doivent prévoir ce qui peut arriver si la sécurité est brisée, et comment contenir les dégâts et récupérer de l'attaque.

ATTAQUES CONTRE LA CRYPTOGRAPHIE

Parfois, des produits traitent la cryptographie n'importe comment. Certains vont reposer sur des algorithmes propriétaires. Invariablement, ces algorithmes sont faibles.

  Les cryptographes ont souvent un succès surprenant lorsqu'ils brisent des algorithmes de chiffrement publiés; leurs réussites sont encore mieux retenues contre les algorithmes propriétaires. Garder un algorithme secret n'empêche pas son analyse, parce qu'il ne faudra que quelques jours pour désassembler l'algorithme cryptographique à partir du code exécutable.

   Le standard S/MIME 2 pour le courrier électronique a utilisé une conception relativement forte, mais avec un algorithme de chiffrement faible. Le système utilisé pour le chiffrement des communications GSM a repris un algorithme faible, et l'a rendu encore plus faible. Et beaucoup de systèmes utilisent des clefs bien trop courtes10.

Il y a encore beaucoup d'erreurs cryptographiques: des implémentations qui répètent des valeurs aléatoires "uniques", des algorithmes de signature numérique qui ne vérifient pas correctement leurs paramètres, des fonctions de hachage modifiées et qui perdent alors les propriétés indispensables qui fondent leur utilisation normale.

   Les protocoles cryptographiques sont souvent utilisés de manière inattendue par les concepteurs des protocoles. Par exemple, ils sont "optimisés" par des moyens si triviaux que toute sécurité est brisée.

PRÉVENTION CONTRE LA DÉTECTION

La plupart des systèmes cryptographiques se basent sur la prévention comme seul moyen de défense. La cryptographie ne peut qu'empêcher les gens de tricher, mentir ou abuser le système. La défense ne doit jamais être aussi étroite.

  Un système fort tente de détecter les attaques et de les contenir. 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 manière complètement nouvelle et inattendue, avec des conséquences imprévisibles. Il est alors important d'être capable de détecter toute attaque et de les contenir afin de s'assurer que les dégâts sont réduits au minimum.

  Plus important: une fois que l'attaque est détectée, le système à besoin de récupérer. Il a besoin de produire et de propager une nouvelle paire de clefs, de mettre à jour le protocole, de rendre invalide le protocole en cours, de retirer tout node invalide du système, et ainsi de suite. Malheureusement, beaucoup de systèmes ne collectent pas assez de données pour assurer une bonne surveillance, se protéger contre un échec ou protéger les données contre toute modification.

  Un bon journal de surveillance a beaucoup à faire pour détecter les attaques. Il doit être aussi capable de produire des preuves pour convaincre un juge et un jury.

CONCLUSION

Les concepteurs de sécurité occupent ce que le général Prusse Carl von Clausewitz appelle "la position de l'intérieur". Un bon produit de sécurité doit se défendre contre toute attaque possible, même les attaques qui n'ont pas encore été inventées.

  Les attaquants, de leur côté, n'ont besoin de trouver qu'une seule faille dans la sécurité pour briser le système. Et ils peuvent tricher. Ils peuvent travailler à plusieurs, conspirer et attendre des avancées de la technologie, qui leur apporteront de nouveaux outils. Ils peuvent attaquer le système avec des méthodes que son concepteur n'aura jamais imaginées.

  Construire un système cryptographique sans sécurité est facile et concevoir un système sûr est difficile. Malheureusement, la plupart des gens sont incapables de faire la différence.

Dans d'autres domaines de la science informatique, la fonctionnalité sert de référence pour séparer le bon du mauvais.

Un bon codec fonctionnera mieux qu'un mauvais, et un mauvais codec aura de mauvais résultats dans un tableau de comparaison.

  La cryptographie n'est pas différente. Parce qu'un programme de cryptographie fonctionne ne signifie pas qu'il est sûr. Ce qui arrive avec la plupart des produits c'est que quelqu'un va lire Cryptographie appliquée, en choisir un algorithme et un protocole, les programmer et vérifier qu'ils fonctionnent, et penser que le projet est terminé. Il ne l'est pas.

  La fonctionalité n'est pas la qualité, et aucune quantité d'essais ne suffira à révéler une faille de sécurité. Trop de produits sont tout juste satisfaisants; ils utilisent une cryptographie forte mais ils ne sont pas sûrs.

  1. P. Gutmann, "Software Generation of Random Numbers for Cryptographic Purposes", Proc. 1998 Usenix Security Symp. Usenix Assoc. Berkeley, Calif. 1998 pp. 243-257.
  2. J. Kelsey, B. Schneier et D. Wagner, "Protocol interactions and the Chosen Protocol Attack", Security Protocols, 5th Workshop. Springer-Verlag, New York, 1998.
  3. H. Abelson et al., "The Risks of Key Recovery, Key Escrow and Trusted Third-Party Encryption", World Wide Web J., no. 3, 1997, pp. 241-257.
  4. R. Anderson et M. Kuhn, "Tamper Resistance: A Cautionary Note", Proc. Second Usenix Workshop Electronic Commerce, Usenix Assoc., Berkeley, Calif. 1996 pp. 1-11.
  5. J. Mc Cormac, European Scrambling Systems, Baylin Publications, Boulder, Colo., 1997.
  6. P. Kocher, "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and Other Systems.", Proc. Crypto96, Springer-Verlag, New York, 1996, pp. 104-113.
  7. R. Anderson, "Why Cryptosystems Fail", Comm. ACM, Nov. 1994, pp. 32-40.
  8. I. Winkler, Corporate Espionage, Prima Publishing, Placer Country, Calif. 1997. 
  9. M. Blaze et al., "Minimal Key Lengths for Symetric Ciphers to Provide Adequate Commercial Security", Oct. 1996, ftp://ftp.research.att.com/dist/mab/keylength.txt

xhtml 1.0