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 Examinons de plus près le fonctionnement du protocole. Parce qu'il serait dommage de lire un article de conférence et de ne pas parler de choses sur lesquelles il attire l'attention. Je tiens à m'excuser à nouveau pour ma technique de dessin sur le tableau noir, après tout, la plupart du temps que je passe à table, en tapant sur un ordinateur.
Il s'agit d'une technologie étrangère. Voici donc le répéteur. Et voici Alice. Voici un autre répéteur et voici Bob. Alice veut maintenant parler avec Bob, donc la première chose qu'elle fait est de créer une chaîne à travers ces répéteurs à Bob. Disons qu'elle a choisi ces deux répéteurs, R1 et R2. Alice établit d'abord un lien TLS vers R1, disons qu'elle a déjà un lien TLS vers R2. Ensuite, tout d'abord, Alice effectue une authentification unidirectionnelle, une correspondance unidirectionnelle des clés anonymes.
L'ancien protocole Tor s'appelait TAP - Tor Authentication Protocol, le nouveau s'appelle NTor. Les deux ont des preuves de sécurité. C'est une preuve correcte, bien que des erreurs aient été commises dans leur description.
Après l'authentification, Alice sélectionne l'ID de circuit ID de canal, disons 3, demande au répéteur de créer le canal "3" - créer "3", et il lui dit que le canal est créé - créé. Alice et le relais partagent maintenant la clé symétrique secrète S1. Et ils le stockent tous les deux avec un index de "3", qui est un lien vers ce canal.
Alice peut désormais utiliser cette clé pour envoyer des messages R1. Elle dit que sur la "troïka", c'est l'identifiant de canal, qui est discuté dans l'article de la conférence, une cellule étendue avec du contenu est envoyée au relais.
Une cellule étendue contient essentiellement la première moitié d'une poignée de main. Mais cette fois, il n'est pas chiffré avec la clé publique R1, mais chiffré avec la clé publique R2. Cela indique que le message est envoyé à R2. Ainsi, R1 sait qu'il est nécessaire d'ouvrir un nouveau canal vers R2, et le signale au relais R2 avec le message create (....), où la même moitié de la poignée de main provenant d'Alice est placée entre crochets. Ce faisant, R1 crée son propre ID de circuit, car les identificateurs de canal définissent d'autres canaux dans cette deuxième connexion TLS. De plus, Alice ne sait pas quels identifiants de canal sont encore utilisés ici, car il s'agit d'une «affaire personnelle» de R1 et R2.
Ainsi, le répéteur peut choisir, par exemple, l'ID 95. En fait, cela est peu probable, car le numéro de canal est sélectionné au hasard dans 4 octets d'espace, mais je ne veux pas écrire tous les nombres 32 bits aujourd'hui.
Après cela, R2 répond au premier relais «créé», et R1 retourne à Alice une cellule étendue, chiffrée avec la clé S1. Désormais, Alice et le relais R2 partagent S2 et Alice peut envoyer des messages, d'abord cryptés avec S2, puis avec S1. Elle envoie un tel message, R1 supprime le cryptage de S1 et le transmet plus loin.
Le premier répéteur sait que les messages du canal 3 doivent être envoyés au deuxième répéteur sur le canal 95. Après avoir reçu ce message, le deuxième répéteur voit que la touche S2 correspond au canal 95, et avec son aide déchiffre ce message: «oh, il dit une connexion ouverte avec Bob»! Après avoir lu ceci, le relais R2 ouvre une connexion TCP avec Bob et le signale à Alice en utilisant le même processus de transmission de message inverse.
Après tout cela, Alice dit: "super, alors dis à Bob quelque chose comme http: 1.0get /index.html", puis la vie continue.
Voyons ce que j'ai manqué dans l'article de la conférence ... alors ... ceci, ceci et ceci. D'accord, alors que relayons-nous réellement? Certaines solutions dans ce domaine prétendent qu'il est nécessaire de transférer des paquets IP dans les deux sens, c'est-à-dire que ce schéma devrait simplement être un moyen de transmettre des paquets IP. L'un des problèmes est que nous voulons prendre en charge autant d'utilisateurs que possible, ce qui signifie que nous devons travailler sur toutes sortes de systèmes d'exploitation.
Mais les piles TCP de différents systèmes d'exploitation agissent différemment. Si vous avez déjà utilisé Nmap ou une sorte d'outil d'analyse du trafic réseau, vous pouvez facilement distinguer Windows TCP de FreeBSD TCP ou TCP Linux. Vous pouvez même distinguer les différentes versions. De plus, si vous pouvez envoyer des paquets IP bruts à un hôte sélectionné, vous pouvez provoquer des réponses basées en partie sur ce que fait l'hôte.
Donc, si vous transférez des paquets IP d'avant en arrière, vous avez besoin d'une normalisation IP. Étant donné que quelque chose de plus petit que la pile IP complète ne pourra pas fonctionner sur la normalisation, vous ne venez pas le faire.
Au lieu de cela, nous choisissons la méthode la plus simple - nous acceptons simplement tout le contenu des flux TCP, en supposant qu'il est fiable et que tout est en ordre. Le programme analyse toutes les données transmises par Alice, accepte d'accepter les connexions TCP provenant de ses applications, et relaie simplement le contenu sans rien faire de compliqué au niveau du réseau.
Vous pouvez essayer d'augmenter la productivité en utilisant d'autres moyens décrits dans les supports de cours. Mais j'ai décrit un schéma qui peut réellement être implémenté, car lors de la création de Tor, nous avons accordé beaucoup plus d'attention aux classes de sécurité et aux compilateurs qu'aux classes de réseau. Nous avons maintenant des spécialistes du réseau, mais en 2003-2004, nous en avons connu une pénurie.
Le protocole TCP semble être un niveau correct et très approprié. Les protocoles de niveau supérieur discutés dans certains projets originaux utilisent des proxys séparés côté Alice pour HTTP, FTP et semblent être une mauvaise idée. En effet, tout protocole doit avoir un cryptage du début à la fin tout au long de la connexion Alice-Bob, et si nous sommes chanceux, Alice sera en mesure de créer une connexion TLS entre R2 et Bob, qui a des fonctionnalités d'intégrité et de sécurité.
Mais si c'est le cas, toutes les transformations d'anonymat que vous souhaitez appliquer aux données chiffrées doivent se produire dans l'application qu'Alice utilise avant que la connexion TLS ne soit entièrement créée. Mais cela n'est pas possible en utilisant un serveur proxy, donc TCP nous convient mieux.
Quelqu'un m'a demandé, où est notre preuve de sécurité? Nous avons des preuves de sécurité pour de nombreuses méthodes de cryptage que nous utilisons, ce sont des versions standard des documents. En général, pour le protocole, il existe des preuves de la sécurité de certains aspects du routage des oignons. Mais les modèles qu'ils doivent utiliser pour prouver que cela fournit l'anonymat devraient être basés sur des propriétés si étranges de l'univers, des propriétés du réseau ou des capacités de l'attaquant qu'ils ne peuvent satisfaire que les commissions de programmation qui siègent à certaines conférences théoriques.
En bref, ces propriétés d'anonymat doivent prouver qu'un attaquant qui peut voir le volume et le minutage des données dans la section Alice-R1 ne pourra pas les identifier, en observant uniquement les octets de sortie dans la section R2-Bob. Mais ce n'est pas un résultat satisfaisant. Disons simplement - quelles garanties de sécurité aimeriez-vous d’un système que vous ne savez pas construire? Eh bien, je dois être prudent avec de telles déclarations ... Rappelez-vous qu'il existe des systèmes avec de fortes garanties d'anonymat, et vous savez comment créer de tels systèmes, mais vous ne voudrez jamais les utiliser. Comme, par exemple, le réseau DC-Net classique, qui garantit l'anonymat, sauf que tout participant peut fermer l'ensemble du réseau simplement en cessant d'y participer. De plus, ce système n'est pas évolutif.
Mais pour les choses créées à notre époque, les propriétés de l'anonymat sont plus probabilistes et ne sont pas catégoriquement garanties. Donc, au lieu de demander si ce système garantit la sécurité d'Alice, il vaudrait la peine de demander combien de trafic Alice peut envoyer en toute sécurité si elle veut avoir 99% de chances que cette activité réseau ne puisse pas être associée à son activité?
La première question que nous nous sommes posée lorsque nous avons commencé à créer Tor est: qui va gérer toutes ces choses? Nous ne savions pas si notre système allait vraiment "se remettre sur pied", alors la seule option était d'essayer de voir ce qui en découlait.
Nous avions suffisamment de bénévoles. Un bon nombre d'organisations à but non lucratif souhaitaient simplement faire des dons et les utiliser pour acheter de la bande passante et lancer des sites Tor. Certaines universités et plusieurs entreprises privées ont participé au projet, dont les services de sécurité ont décidé qu'il serait amusant de lancer leur propre serveur Tor.
Dans ce cas, des problèmes juridiques se sont posés, mais encore une fois, je ne suis pas avocat et je ne peux pas donner une évaluation juridique de ces choses. Cependant, cinq personnes différentes m'ont interrogé sur la légalité de notre système. Pour autant que je sache, au moins aux États-Unis, il n'y a aucun obstacle juridique au démarrage du serveur Tor. Et il me semble qu'une situation similaire se produit dans la plupart des pays européens. Dans les pays avec moins de liberté sur Internet, Tor est plus restrictif.
Le problème n'est pas à quel point l'utilisation du système Tor est légale ou illégale, mais que quelqu'un peut faire quelque chose d'illégal ou indésirable avec mon serveur Tor. Par exemple, mon fournisseur me déconnectera-t-il du réseau si je fournis mon ordinateur en tant que nœud Tor, les services chargés de l'application des lois croiront-ils que j'utilise simplement le serveur Tor, ou ils viendront chercher mon ordinateur pour s'en assurer.
Dans un tel cas, je vous conseille de ne pas démarrer le serveur Tor à partir de votre dortoir, ou plutôt, de ne pas utiliser votre ordinateur pour diffuser une grande quantité de trafic de sortie, en supposant que cela autorise la stratégie réseau. Honnêtement, je n'ai aucune idée de ce que cette politique est maintenant parce qu'elle a beaucoup changé depuis mes jours d'étudiant. Mais dans tous les cas, un trafic sortant important de votre ordinateur dans l'auberge peut entraîner des problèmes. Cependant, démarrer un répéteur sans émettre de trafic vers Internet sera moins problématique. Mais si votre fournisseur vous autorise à agir de cette façon, c'est une chose tout à fait raisonnable.
Quelqu'un m'a demandé si les utilisateurs ne faisaient pas confiance à un site particulier? Cela nous amène au sujet suivant. Les clients du réseau utilisent le logiciel à leur discrétion, et vous ne pouvez pas leur interdire d'utiliser certains programmes et les obliger à en utiliser d'autres. Mais souvenez-vous que l'anonymat aime la compagnie. Si j'utilise trois nœuds, vous utilisez trois autres nœuds et vous êtes trois autres nœuds, notre trafic ne se mélangera pas du tout.
Tant que nous séparons les parties du réseau que nous utilisons, nous nous distinguons facilement les unes des autres. Maintenant, si j'exclus simplement un ou deux nœuds, et que vous excluez simplement un ou deux nœuds, ce ne sera pas une si grande division du réseau en parties et compliquera notre identification. Mais il serait optimal que tout le monde utilise autant que possible les mêmes nœuds. Comment pouvons-nous y parvenir?
Donc, dans la première version de Tor, nous venons de déposer une liste de tous les nœuds aux utilisateurs, il y en avait environ 6, dont trois travaillaient sur un ordinateur dans le laboratoire d'informatique de Tech Square. Mais ce n'était pas une bonne idée, car le nombre de nœuds augmente et diminue, les nœuds eux-mêmes changent et vous ne voudriez pas publier une nouvelle version du logiciel chaque fois que quelqu'un rejoint le réseau.
Mais vous pouvez vous assurer que chaque nœud contient une liste de tous les autres nœuds qui lui sont connectés, et ils se "publieront" tous. Ensuite, lorsque le client se connecte au réseau, il lui suffit de connaître un nœud, puis de dire: «Hé, qui est là sur le réseau»?
En fait, beaucoup de gens ont des projets construits sur ce principe. De nombreux premiers projets d'anonymat par les pairs fonctionnent de cette manière. Mais c'est une terrible idée. Parce que si vous vous connectez à un nœud et demandez qui est en ligne et que vous faites confiance à la personne qui répond, alors je peux vous répondre: «Je suis en ligne, et mon ami est ici en ligne, et mon ami est également en ligne, et plus encore personne n'est en ligne! ” Autrement dit, je peux vous dire n'importe quel nombre de faux nœuds que je gère et qui interceptent tout votre trafic. C'est ce qu'on appelle une attaque de capture rw, ou une attaque d'interception sur le nœud source.
Il est donc possible que si nous n'avons qu'un seul répertoire géré par une partie de confiance, ce n'est pas si bon, alors supposons toujours que nous avons plusieurs parties de confiance. Les clients se rendent auprès de ces parties de confiance, reçoivent de chacun une liste de tous les nœuds et les combinent en une liste commune de nœuds de réseau.
Ce n'est pas bon car nous sommes à nouveau divisés en grappes de réseaux identifiables. Si je sélectionne ces trois nœuds et que vous sélectionnez trois autres nœuds, nous utiliserons différents ensembles de nœuds, ce qui n'est pas bon. De plus, si j'utilise la liste des nœuds qui m'a été transmise, n'importe quelle partie de confiance peut m'empêcher d'utiliser un nœud qu'elle n'aime pas, simplement en ne le spécifiant pas dans la liste. Si j'utilise une liste combinée, quelqu'un peut m'inonder de 20 000 faux serveurs, en les indiquant dans la liste. Je pourrais voter pour leur exclusion et résoudre en quelque sorte les deux derniers problèmes, mais je serai toujours séparé de tous ceux qui utilisent différents partis de confiance.
Nous pourrions créer un DHT magique, ou une table de hachage distribuée, une sorte de structure distribuée magique qui traverse tous les nœuds. Je dis «magique» car, bien qu'il existe des projets dans ce domaine, et certains sont meilleurs que d'autres, aucun d'entre eux n'a actuellement de preuves solides de sécurité. Si dur que je peux dire avec confiance que c'est vraiment sûr.
Voici donc la solution à laquelle nous sommes parvenus. Notre réseau dispose de plusieurs autorités de confiance, gérées par des parties de confiance, qui collectent des listes de nœuds qui votent toutes les heures sur les nœuds qui peuvent travailler sur le réseau et peuvent voter pour exclure les nœuds suspects. Ils travaillent tous sur le même / 16, qui fait des choses étranges avec le trafic, et forment un consensus basé sur le calcul du résultat du vote.
Et les clients n'utilisent pas le nœud s'il n'est pas signé par un nombre suffisant de «votes» de parties de confiance.
Ce n'est pas la version finale du projet, mais c'est la meilleure que nous ayons pu proposer jusqu'à présent. Soit dit en passant, tout ce que vous devez distribuer aux clients est une liste de toutes les clés publiques autorisées et une liste de certains endroits pour recevoir des répertoires. Vous voulez que tous les nœuds mettent en cache ces répertoires, car si vous ne le faites pas, la charge du réseau deviendra dangereuse et la bande passante du réseau diminuera considérablement.
J'ai l'intention de sauter la question suivante et de passer directement à la façon dont les clients doivent choisir les chemins qu'ils doivent acheminer à travers le réseau. Je voudrais parler des problèmes d'utilisation et de création d'applications qui ne se trahiraient pas. Je voudrais parler des abus de réseau, des services cachés et de leur fonctionnement, parler de la résistance à la censure, et je voudrais aussi parler des attaques et de la protection. Mais il ne nous reste que 35 minutes, je ne peux donc pas parler de tout ce que je veux. Je vous demande de voter sur les sujets que vous jugez les plus importants pour la discussion.
Si vous pensez que l'un des sujets les plus importants est le choix des chemins et des nœuds, veuillez lever la main. Si l'un des sujets les plus importants concerne les problèmes d'application et comment vous assurer que les applications ne violent pas votre anonymat, veuillez lever la main. Si l'abus est l'un des problèmes les plus importants et comment le prévenir, veuillez lever la main. Donc, je vois que ce sujet est populaire et le marque.
S'il est important pour vous de savoir comment fonctionnent les services cachés et comment ils peuvent être améliorés, veuillez lever la main. , , . , . , ? , . ?
, . , , . , , — .
, . , IP-, , . , Whole stack, -, , Tor.
«» -, , , , , , , , .
, : , , , . , -, . , . , . . , .
, . , , – , -, . , BitTorrent, Gnutella . , , , .
, , , 80 443. , 80. IRC- - IRC. -, , , , .
, , - 80 443, , , . , Tor. - , . , , .
, - IRC- IP-.
, My Little Pony, IRC-, , , , – . , IP-, , IP- . Tor .
IP- ? , IP ? Non. , IP, . , IP-, .
IP- , , , , , , Tor -.
. - «» ? , IP, , IP IP-. , , IP-.
, , , , . – « ». , , , , , IRC – , , , .
, . , . , , , - IP, .
- . , 2013 , « 2» , Silk Road. « 2» , Tor, , , .
, - , OPSEC – . , , . Tor , .
, , , , , « ». : «, , . , , . , , — ». , , .
54:00
Cours MIT "Sécurité des systèmes informatiques". 19: « », 3 ( Tor).
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?