Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année
Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.
Cours 1: «Introduction: modèles de menace»
Partie 1 /
Partie 2 /
Partie 3Conférence 2: «Contrôle des attaques de pirates»
Partie 1 /
Partie 2 /
Partie 3Conférence 3: «Débordements de tampon: exploits et protection»
Partie 1 /
Partie 2 /
Partie 3Conférence 4: «Séparation des privilèges»
Partie 1 /
Partie 2 /
Partie 3Conférence 5: «D'où viennent les systèmes de sécurité?»
Partie 1 /
Partie 2Conférence 6: «Opportunités»
Partie 1 /
Partie 2 /
Partie 3Conférence 7: «Native Client Sandbox»
Partie 1 /
Partie 2 /
Partie 3Conférence 8: «Modèle de sécurité réseau»
Partie 1 /
Partie 2 /
Partie 3Conférence 9: «Sécurité des applications Web»,
partie 1 /
partie 2 /
partie 3Conférence 10: «Exécution symbolique»
Partie 1 /
Partie 2 /
Partie 3Conférence 11: «Ur / Web Programming Language»
Partie 1 /
Partie 2 /
Partie 3Conférence 12: Sécurité du réseau,
partie 1 /
partie 2 /
partie 3Conférence 13: «Protocoles réseau»,
partie 1 /
partie 2 /
partie 3Conférence 14: «SSL et HTTPS»
Partie 1 /
Partie 2 /
Partie 3Conférence 15: «Logiciel médical»
Partie 1 /
Partie 2 /
Partie 3Conférence 16: «Side Channel Attacks»
Partie 1 /
Partie 2 /
Partie 3Conférence 17: «Authentification des utilisateurs»,
partie 1 /
partie 2 /
partie 3Conférence 18: «Navigation privée sur Internet»
Partie 1 /
Partie 2 /
Partie 3Conférence 19: «Réseaux anonymes»
Partie 1 /
Partie 2 /
Partie 3 Supposons que vous utilisiez la probabilité bayésienne, en argumentant ainsi: «le tribunal serait-il convaincu que ce type a été arrêté à cause d'une mauvaise OPSEC? Oui, ils l'ont fait. C'est-à -dire que j'ai besoin de rapports indiquant qu'il a été arrêté en raison du non-respect de la sécurité des informations des opérations Internet. » Ainsi, pour le «double design», j'aurais besoin de rapports indiquant que le gars a été pris dans un mauvais OPSEC, car des preuves de ce type sont assez accessibles dans une enquête policière régulière, sans mentionner les informations obtenues des services de renseignement.
Nous ne pouvons pas tirer des conclusions sur cette affaire à partir de rapports publics, mais il semble que ce type ait été arrêté précisément en raison du non-respect des règles OPSEC, c'est-à -dire de ce que vous recherchiez, en essayant d'attraper quelqu'un qui se livre à des activités illégales. Donc, comme je l'ai dit plus tôt, n'utilisez pas mon réseau pour enfreindre des lois. De plus, si votre vie ou votre liberté dépend de l'utilisation de Tor ou de tout autre produit de sécurité, n'utilisez pas ces produits isolément.
Envisagez de créer plusieurs lignes de défense si votre vie ou votre liberté est en jeu, ou si l'effondrement du système vous est totalement inacceptable. Cela est vrai pour Tor, TLS et PGP. Le logiciel est un travail en cours.
C'est tout ce que je voulais dire sur les abus sur Internet. Il me reste 25 minutes pour les services cachés.
L'anonymat du répondant est un problème beaucoup plus complexe que l'anonymat de l'initiateur. L'anonymat de l'initiateur est ce que vous obtenez quand Alice veut acheter des chaussettes, mais en même temps, rester anonyme pour le vendeur de chaussettes.
L’anonymat du répondant est quand Alice veut publier ses poèmes sur Internet et démarre un serveur Web avec sa poésie, mais ne veut pas que quiconque découvre où se trouve ce serveur Web, car la poésie est si maladroite. Alors oui, en fait, il y a un service caché avec mes mauvais poèmes. Non, je ne pense pas que quelqu'un les ait déjà publiés. Non, je ne dirai à personne où il est. J'attends juste qu'il soit rendu public.
Supposons qu'Alice veuille publier ses poèmes. Je vais la mettre à droite parce qu'elle est l'intimée. Alice peut ouvrir la voie - cette ligne en spirale montre plusieurs répéteurs - au réseau Tor, ici à ce R, et se tourner vers lui avec une demande: "veuillez accepter ces connexions!" Alors maintenant, quiconque se connecte à ce répéteur peut dire qu'il veut parler avec Alice. Il y avait des projets qui fonctionnaient de cette façon.
Cependant, il y a quelques problèmes. Un problème est que ce répéteur peut être un homme au milieu, qui intercepte tout le trafic s'il n'y a pas de clé TLS bien connue ici. Le deuxième problème peut être que ce répéteur appartient à une personne qui est aussi timide de ses poèmes et qui ne veut pas être un distributeur public de poésie, car c'est tellement terrible!
Il peut également être affecté par d'autres personnes qui possèdent le relais R, qui détestent tellement la poésie qu'ils veulent censurer ce composé. Enfin, ce relais R peut simplement devenir la cible de l'attaque.
Par conséquent, vous voulez qu'Alice bascule entre différents relais tout le temps, et aucun d'entre eux ne pourrait affecter son trafic non crypté. C'est tout à fait faisable.
Mais si nous avons beaucoup de répéteurs différents, qu'est-ce qu'Alice a à dire aux gens? Il devrait y avoir quelque chose comme une clé publique, car si elle accède simplement au réseau: «relais X, relais Y, relais Z», cela ne fonctionnera pas, car le réseau change toutes les 5 minutes, et pour obtenir le bon, le relais de travail est assez difficile .
Supposons qu'elle dise la clé publique à tous les participants du réseau, et quand elle vient ici à R, elle dit: "c'est Alice, je vais le prouver avec ma clé publique." Ainsi, R sait que la clé publique PKz lance un service caché spécifique - la poésie d'Alice. Par conséquent, si quelqu'un d'autre dit: «Hé, connectez-moi avec la clé publique Z», vous pouvez faire une poignée de main avec Alice en utilisant une clé partagée. Et c'est la même poignée de main qui est utilisée dans la chaîne Tor.
Désormais, Bob pourra lire les poèmes d'Alice en établissant une autre connexion via le réseau Tor. Connaissant la clé PKz, Bob pourra dire au répéteur: "Hé, connectez-moi à Alice avec ce PKz." Une fois que le répéteur a fait une poignée de main commune, Bob et Alice auront une clé commune, qu'ils peuvent utiliser pour crypter tout au long de la connexion.
Il y a quelque chose que j'ai raté, à savoir comment Bob sait-il comment arriver ici? Comment ce répéteur reconnaît-il la clé publique PKz? Nous pouvons ajouter un système d'annuaire au système où Alice télécharge anonymement une déclaration signée indiquant que PKz est sur le relais X via Tor. Dans ce cas, Bob demande au système d'annuaire de lui fournir cette déclaration signée à propos de PKz, afin que Bob découvre où il a besoin aller. Nous pourrions faire encore mieux - laissez Alice fournir une autre clé publique, appelons-la PKw, et l'application qu'elle télécharge dans le répertoire et qui dit que si vous voulez parler au service de clé publique Z, alors vous devriez aller au relais Rx en utilisant la clé publique W.
Dans ce cas, la clé publique Z n'est pas publiée sur le relais Rx. Vous pouvez continuer et crypter l'expression (Rx, PKw) avec une sorte de secret commun connu d'Alice et Bob. Si vous procédez ainsi, le service d'annuaire et les personnes qui peuvent contacter le service d'annuaire ne pourront pas apprendre à se connecter à Alice à l'aide de cette clé PKz.
Étudiant: si ce n'est pas chiffré, le répéteur Rx peut découvrir qu'il démarre le service pour Alice, non?
Nick Mathewson: non, pas pour Alice. Il ne peut découvrir qu'il utilise la clé PKz que si cette expression n'est pas chiffrée. Nous avons une décision sur la façon de créer un tel système, il n'a pas encore été construit, mais ce sera cool.
Supposons que vous ne souhaitiez pas utiliser un répertoire centralisé pour cela. Dans ce cas, nous utilisons en fait du DHT, ce qui n'est pas idéal et soumis à la censure, mais nous essayons de rendre de moins en moins possible la censure. Je pourrais vous en dire plus à ce sujet, mais je crains de ne pas avoir le temps de couvrir les autres sujets.
Il y a un autre problème: si vous utilisez l'un de ces répertoires de service et que vous disposez d'une liste complète de clés, vous pouvez vous connecter à tous ceux qui n'ont pas chiffré leurs connexions pour savoir ce qu'ils contiennent. C'est ce qu'on appelle une attaque d'énumération ou «attaque d'énumération». Nous ne l'avons pas mentionné dans notre journal, non pas parce que cela ne nous dérange pas, mais parce que nous ne sommes pas encore prêts à résister à de telles attaques.
J'espère qu'en 2014 nous trouverons une solution dans laquelle Alice et Bob partagent la clé PKz, mais cette expression (Rx, PKw) n'est pas signée avec la clé PKz. Il est signé par PKz
1 , qui est dérivé de PKz et, disons, la date:
PKz
1 - > PKz, Date
Si vous connaissez PKz et la date, vous pouvez obtenir PKz
1 . Si, comme Alice, vous connaissez le secret de SKz, vous pouvez créer des messages signés par PKz
1 .
Mais si vous ne voyez que PKz
1 , même en connaissant la date, vous ne pouvez pas recevoir de nouveau PKz. Nous avons des preuves de la possibilité de cette solution, et si vous voulez savoir comment cela fonctionne, écrivez-moi et je vous les enverrai. C'est un truc sympa. Nous n'avons pas été les premiers à proposer cette idée. Mais c'est ainsi que nous allons résoudre le problème des attaques par dénombrement cette année, si je trouve vraiment le temps pour la mise en œuvre pratique de cette solution. C'est tout pour les services cachés.
Considérez la question des attaques et de la défense. Jusqu'à présent, la catégorie d'attaques la plus importante que nous ayons vue est celle des attaques au niveau de l'application. Si vous exécutez l'application via Tor et qu'elle envoie du trafic non chiffré, comme une connexion HTTP normale, le nœud de point de sortie hostile, comme tout autre nœud qui autorise les connexions HTTP, peut surveiller et modifier ce trafic. Il s'agit de l'attaque numéro 1 dans notre système. Il peut être résisté à l'aide d'un trafic chiffré.
Heureusement, au cours des dernières années, le cryptage a augmenté, et plus de trafic est crypté par l'excellente autorité de certification gratuite que EFF, Mozilla et Cisco ont signalée il y a un jour ou deux. J'espère qu'en 2015, il y aura encore moins de trafic non crypté qu'il n'y en avait cette année. Cette approche résout donc ce problème.
Les attaques les plus intéressantes incluent des éléments comme le marquage du trafic ou le marquage du trafic. Nous avons fait une erreur lors de notre précédente mise en œuvre du contrôle d'intégrité. Notre première implémentation de la vérification d'intégrité s'est terminée par une vérification d'intégrité dans la section entre le programme d'Alice et le nœud du point de sortie, mais il s'est avéré que cela ne suffisait pas. Parce que si le premier relais R1 «confond» le trafic de telle manière qu'il crée un modèle qui peut détecter le nœud de point de sortie, alors pour le premier et le dernier relais, il servira de moyen de découvrir qu'ils sont sur le même chemin commun, dans la même chaîne et d'identifier Alice.
Bien sûr, si le premier et le dernier relais coopèrent d'une manière ou d'une autre, ils peuvent en tout cas déterminer Alice en comparant le trafic, mais nous espérons que ce ne sera pas facile pour eux, et au fil du temps, le processus de corrélation du trafic deviendra plus compliqué que nous le pensons.
En fait, ce serait bien de mettre fin une fois pour toutes à ce type d'attaque. Pour cela, nous avons deux solutions. L'un des résultats escomptés de ces attaques est une défaillance périodique des chaînes, car l'attaquant du premier concentrateur a commis une erreur concernant le contrôle du dernier concentrateur.
Par conséquent, chaque client Tor vérifie un taux de rebond étrange. Une solution efficace à long terme au problème consiste à s'assurer que le «tapage» avec le modèle sur le premier concentrateur ne crée pas plus d'un bit d'informations sur le dernier concentrateur. Vous ne pouvez pas éviter d'envoyer 1 bit d'informations, car le premier concentrateur peut toujours simplement déconnecter la connexion, mais vous pouvez limiter ces informations à 1 bit. Ou mieux jusqu'à 2 bits, car ils auront alors le choix de corrompre les données ou de déconnecter la connexion. J'avais une idée de la meilleure façon de procéder, alors je vais réfléchir à ce problème.
Le déni de service, ou DOS, est également important. L'année dernière, il y avait un article sur ce que les auteurs ont appelé une "attaque de tireur d'élite". Vous voyez le trafic provenant du nœud Tor que vous ne contrôlez pas, et souhaitez donc chasser tout le monde de ce nœud. Pour ce faire, vous vous connectez à ce nœud, débordez tous les tampons de sa mémoire, et il "plante". Après cela, vous redirigez le trafic qui vous intéresse vers le nœud que vous contrôlez, et s'il tombe sur un nœud non contrôlé, répétez cette technique plusieurs fois jusqu'à ce que le résultat souhaité soit atteint.
Nos meilleures solutions visent à éliminer la possibilité d'une attaque DOS sur la mémoire, et nos correctifs ont pratiquement éliminé cette possibilité. Une autre option pour résoudre des problèmes de ce type consiste à s'assurer que le répéteur a une grande capacité de mémoire. Par conséquent, n'utilisez pas de répéteurs de petite capacité sur le réseau. Nous le faisons également - si vous essayez de démarrer le site Tor sur votre téléphone, il ne recevra pas d'autorisation et ne sera pas inclus dans la liste des sites de confiance.
Nous essayons également de développer des algorithmes de planification de chaîne, bien qu'il soit très difficile d'essayer de développer un schéma de réseau de nœuds que vous ne contrôlez pas, donc pour l'instant c'est un problème non résolu.
Maintenant, dites-moi ce qui est le mieux - parlez-vous d'attaques intéressantes ou d'attaques importantes?
Étudiant: sur les plus intéressants!
Nick Mathewson: bien. Que ceux qui souhaitent écrire un programme utilisant la cryptographie lèvent la main? Eh bien, c'est ce que vous devez apprendre! Mais ne faites jamais confiance à l'implémentation de votre cryptographie. Même si c'est correct, c'est toujours faux. Il y a très longtemps, nous avons eu l'une des pires erreurs de sécurité. Nous avons considéré que chaque répéteur pouvait être un «homme au milieu» dans n'importe quelle chaîne de nœuds, car nous supposions que la mise en œuvre correcte de l'algorithme Diffie-Hellman vérifierait si 0 passait comme l'une des entrées.
Les auteurs de notre implémentation Diffie-Hellman ont suggéré qu'une application appropriée ne passerait jamais une implémentation Diffie-Hellman nulle.
Comment fonctionne l'algorithme Diffie-Hellman correct? Supposons que j'ai g
x et que vous ayez g
y . Je connais X, tu connais Y, et nous pouvons tous les deux calculer g
xy . Mais si à la place "l'homme au milieu" remplace ma valeur g par zéro, alors je calcule 0
x , vous calculez 0
y , nous aurons la même clé, et nous pourrons facilement communiquer entre nous, mais ce sera la clé que l'attaquant connaît, car qu'est-ce que c'est 0.
L'unité fonctionne, P fonctionne également, P + 1 fonctionne également. Ainsi, il vous suffit de vous assurer que vos valeurs g
x et g
y sont comprises entre 2 et P-1 si vous implémentez l'algorithme Diffie-Hellman sous la forme z sub p.
Je voudrais parler davantage de la censure. Après tout, en fait, c'est l'un des domaines où nous pouvons faire le plus de bien. Au début, nous pensions que Tor ressemblerait à un client Web parlant au serveur Web via HTTPS et rendrait le blocage difficile. Il s'avère que c'est incroyablement difficile et probablement pas la peine.
Nous utilisons maintenant une approche utilisant divers plugins qui permettent d'utiliser des répéteurs non signalés comme pont, et l'utilisateur peut utiliser ce schéma pour diverses conversions de trafic. Nous parvenons à nous assurer que de nouveaux répéteurs sont ajoutés au réseau plus rapidement que les censeurs ne réalisent leur blocage.
En fait, c'est le cas lorsqu'aucune des solutions n'est catégoriquement réalisable. Je suppose que je n'ai pas formulé ma pensée de cette façon. Il serait plus correct de dire qu'aucun de ces plug-ins n'est essentiellement non bloquant par les technologies modernes, mais ils sont assez bons pour garder le trafic débloqué pendant 1-2 ans dans la plupart des pays ou 6-7 mois en Chine.
La Chine possède actuellement les censeurs les plus compétents au monde, principalement parce qu'elle n'a pas recours à l'externalisation. La plupart des autres pays où la censure d'Internet est agressive transfèrent les fonctions de censure aux entreprises européennes, américaines et asiatiques, dont les intérêts ne sont pas de vendre réellement des logiciels de censure Internet efficaces, mais de forcer leurs clients à participer constamment à la course aux mises à jour.
Par exemple, vous pouvez acheter votre logiciel censuré aux États-Unis. Techniquement parlant, les entreprises américaines ne sont pas autorisées à réaliser des programmes de censure pour les pays tiers, mais aux États-Unis, elles ont développé un pare-feu d'entreprise pouvant atteindre 10 millions d'utilisateurs. Je pense que c'est contraire à l'éthique, mais encore une fois, je ne suis pas membre d'organisations politiques et pas philosophe.
Paul Cyverson, l'un des auteurs de Tor, est diplômé en philosophie, mais même lui ne peut pas répondre à ces questions. Mais il passe beaucoup de temps à ne pas y répondre.
Alors, où je me suis arrêté? 90 minutes, c'est long. Censuré! Ainsi, Tor a contourné à plusieurs reprises la censure de divers développeurs. Ils essaient de bloquer les versions les plus récentes de Tor, mais en même temps, ils font un bloc assez faible. Par conséquent, si nous changeons 1 bit quelque part dans le même identifiant de nœud, nous pouvons facilement contourner un tel verrou.
Nous ne pouvons pas prouver qu'ils obligent spécifiquement Tor à contourner le verrou, c'est-à -dire qu'ils vendent des programmes de blocage qui ne fonctionnent pas, afin de pouvoir vendre plus tard une mise à jour après l'autre. Mais il nous semble que c'est ainsi. – , , .
, , , . , , . , «» – , , .
, – . Tor — , . , , . freehaven.net/anonbib/ , .
I2P, Gnunet, Freedom — «», , , Mixmaster, Mixminion, Sphynx Y, Sphinx I – - , DC-net, DC-net . , . , Tor — , , .
— . , — , , , , — , , . . , . , , , , , . , : « , ». , 10 , .
, Tor. , :
PKz
1 → PKz, Date
, , . , , .
. 2003 RSA-1024, . RSA-1024 Ed25519. , , .
path selection, . 5-6 , . .
, - . , , , , - . , - - , 2015 . - – , !
, . , . . 10 20 . , , , 100 , - .
, , , . — , .
, , 100 – - . , , , - .
- , . , , , , .
, , .
- , , - , . : «, , !». , 2 , 6. , , , - .
, , , . «», , - , . , , , - .
, . ? Non? , . , . , 12:25, . . , , !
.
Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une
réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en janvier gratuitement en payant pour une période de six mois, vous pouvez commander ici .Dell R730xd 2 fois moins cher? Nous avons seulement
2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la
création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?