1. Trang chủ
  2. » Giáo Dục - Đào Tạo

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

38 18 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 38
Dung lượng 371,2 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Le déploiement global de DNSSEC fournit aussi une infrastructure pour publier des clefs publiques et des certificats d’une façon sécurisée .Cette mémoire de fin d’études parle de la poss

Trang 1

Mémoire de fin d’études du : DIPLOME D’ETUDES PROFESSIONNELLES APPROFONDIES

par

TA Quoc An

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

Novembre, 2004

Trang 2

Je tiens à remercier Prof Ahmed Serhrouchni de m’a voir accueilli dans son équipe durant mon stage de DEPA à Ecole Nationale Supérieure des Télécommunications, et d’avoir encadré et animé ce stage avec enthousiasme Grâceà ses connaissances profondes et vastes j’ai été encouragé à accomplir ce stage.

Trang 3

Table des matières

Résumé 2

Abstract 3

1 Système de nom de domaine (DNS) 4

1.1 La structure de DNS 4

1.2 Le fichier de zone 7

1.3 Le message DNS 8

1.4 La résolution DNS 8

1.5 L’enregistrements de colle et les points de délégation 9

1.6 Les attaques sur le DNS 9

1.6.1 L’empoisonnement de la cache 10

1.6.2 L’attaque de date de naissance 10

1.6.3 L’analyse d’espace de phase 11

2 Le système de nom sécurisé (DNSSEC) 13

2.1 Rappels de cryptographie à clefs publiques 13

2.1.1 Les algorithmes de chiffrement asymétriques 13

2.1.2 La fonction d’hachage 14

2.1.3 La signature numérique 14

2.1.4 Le certificat 15

2.2 La structure de DNSSEC 16

2.3 Les nouveaux enregistrements de ressource (RRs) 17

2.3.1 L’enregistrement de ressource KEY (KEY RR) 17

2.3.2 L’enregistrement de ressource SIG (SIG RR) 17

2.3.3 L’enregistrement de ressource NXT (NXT RR) 18

2.3.4 L’enregistrement de ressource DS (DS RR) 19

2.3.5 Le roulement des clefs 21

3 La distribution sécurisée de clefs 23

3.1 Les problèmes de la distribution de clefs 23

3.1.1 La sécurité à configuration nulle 23

3.1.2 La distribution de clef à distance 23

3.2 Stockage des clefs dans le DNS (DNSSEC) 23

3.2.1 Les points forts de DNS/DNSSEC 24

3.2.2 Les points faibles de DNS/DNSSEC 24

3.2.3 Le problème du stockage des clefs d’application dans le KEY RR 25

3.3 Les solutions proposées 26

3.3.1 Définir un nouveau type d’enregistrement pour toutes les clefs d’application 26 3.3.2 Définir un nouveau enregistrement pour chaqueapplication 27

3.3.3 Stocker la référence dans le DNS, retrouveresl clefs via autres protocoles 27

3.4 La résolution des clefs 27

3.4.1 La chaîne de confiance 27

3.4.2 L’outil digsec 28

4 Conclusion 29

Abréviation 30

Références 31

Trang 4

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

Résumé

Le système de nom de domaine (Domain name system - DNS) est le service le plus utilisésur l’Internet Sa fonction principale est d’établir l’association entre les noms desordinateurs (dit nom de domaine) et les adresses IP et vice versa Il y a cependant certainsproblèmes de sécurité avec le DNS Il est possiblede corrompre le système DNS avec desdonnées falsifiées

Pour aborder les défauts de DNS, on a proposé une xtension, le DNSSEC (DNSSECurity) qui est spécifié à l’IETF par le biais de la RFC2535 Le DNSSEC utilise lacryptographie à clefs publiques pour protéger les enregistrements et les transactions DNS,donc il permet de détecter et éviter des falsifications

Le déploiement global de DNSSEC fournit aussi une infrastructure pour publier des clefs publiques et des certificats d’une façon sécurisée Cette mémoire de fin d’études parle de

la possibilité de créer une base de données des clefs publiques que tout le monde peut utiliser pour chiffrer, déchiffrer et établir l’authenticité des communications numériques.Mots clés : Domain name system, Security and Protection, Public key cryptography

Trang 5

The Domain Name System (DNS) is the busiest service on the Internet It takes care ofthe mapping between domain names and IP address and vice versa There are howeversome security problems with DNS It has been shown that one could corrupt the systemwith bogus data

To address this and others shortcomings of the DNS an addition has been taken out,called the secure domain name system (DNSSEC) DNSSEC uses cryptographicallysigned responses to authenticate the results, thus detecting falsified data

The global deploy of the DNSSEC creates also an infrastructure for issuing the publickeys and the certificates in a secure manner This master thesis discusses the possibility ofcreating a public key database serving the coding, decoding, authenticating requirementfor everyone

Keywords: Domain name system, Security and Protection, Public key cryptography

Trang 6

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

1 Système de nom de domaine (DNS)

Jusqu’en 1984, toutes les associations entre les noms des machines connectées au réseau Internet (successeur d’ARPAnet) et leur(s) adresse(s) étaient contenues dans un simple fichier host.txt présent sur chaque machine Ce fichier était géré par une autorité centrale, le SRI-NIC (Stanford Reasearch Institute- Network Information Center) chargé de recueillir lesmises à jour et de diffuser régulièrement une version actualisée

Cette manière de procéder est devenue totalement inadaptée devant la croissance rapide du nombre d’équipements connectés au réseau : les ollisionsc entre noms ainsi que les

difficultés inhérentes à une conception centralisée(mises à jour et diffusion des

informations) ont rendu ce modèle obsolète Le protocole DNS a donc été conçu en 1984 pour répondre à ces besoins: création d’un espace de nommage quasi infini grâce à un modèle arborescent, robustesse et performance ont été les priorités de conception; la

sécurité n’était à l’époque pas au centre des préoccupations

Le DNS est donc devenu le deuxième catalyseur de l’expansion de l’internet aprèsl’adoption du protocole TCP/IP quelques temps auparavant, et il est aujourd’hui l’un despiliers de son bon fonctionnement

Mais parallèlement, les raisons de ce succès (notamment sa simplicité et son efficacité protocolaire) ainsi que son rôle critique dans l’In ternet moderne ont fait du DNS la cible idéale d’attaques simples mais aux conséquences pouvant être très néfastes

Ceci est d’autant plus problématique que le DNS est à la fois omniprésent et invisibledans l’utilisation grand public de l’Internet actue l: un utilisateur qui croit accéder à undomaine en le désignant par son nom peut être redirigé sur la machine d’un pirate sanss’en rendre compte si l’entrée DNS correspondante a été corrompue

1.1 La structure de DNS

Son architecture repose sur un modèle client/serveur classique dans lequel le client, appelé

résolveur, est une bibliothèque de fonctions de résolution DNS située sur une machine

cliente et le serveur est un serveur de nom Les requêtes effectuées par le client au(x)

serveur(s) de noms interrogent la base de données qui contient les associations entre les noms de domaine et un certain nombre d’informations qui leur sont propres

Trang 7

Cette base de données, ou arbre de nommage, a étéonçuec suivant trois caractéristiques principales :

(1) elle est hiérarchique: ce qui lui confère l’appellation d’arbre DNS ó chaque nom de

domaine est représenté par un nœud de l’arbre, la racine étant représentée par "." Cette structuration en arbre inversé permet de relier la racine à un nœud quelconque de l’arbre par

un chemin unique Un nom de domaine est donc représenté par la succession d’étiquettes

(labels) rencontrées sur le chemin reliant le noeud à la racine, séparés par des points.

Ex : le noeud enst sur la figure 1 correspond au nom de domaine enst.idsa.prd.fr.

Un domaine est tout simplement un sous-arbre de l’arbre DNS débutant à un noeud

spécifique et recouvrant l’arborescence située en dessous de ce point

Ex : le domaine idsa.prd.fr est inclus dans le domaine fr (cf figure 1).

(2) elle est distribuée : cette base de données est répartie sur un grandnombre de serveurs,

chacun de ces serveurs étant en charge d’un sous-arbre de l’arbre DNS et des informations correspondantes On évite ainsi la lourdeur d’un système centralisé ó toutes les requêtes sont traitées par une base de onnéesd unique, même si celle-ci est répliquée sur plusieurs serveurs

Cette décentralisation permet d’augmenter la flexibilité du système : une administration locale est plus à même de gérer les mises à jour des informations du sous-arbre dont elle est en charge C’est pour cela qu’au sein d’un doma ine, on choisit souvent de transférer la responsabilité de certains sous ensembles de noms, c’est ce qu’on appelle une délégation etcela a pour conséquence la création d’une nouvelle zone dite zone fille de la première (zone parente)

Une zone est la partie descriptive des informations DNS d’un sous-arbre Ces informationssont contenues dans un fichier de zone stocké sur les serveurs qui sont dits autoritaires pour la zone et qui sont en charge de la mise à jour et de la diffusion de ces informations

La robustesse du système bénéficie également de ctet répartition : l’indisponibilité de

certains serveurs n’affectera que les sous-arbres concernés

Trang 8

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

zoneinfres.enst.fr

domaineinfres.enst.fr

fr

ftp

Figure 1 L'arbre DNS

(3) elle est redondante : la décentralisation des responsabilités s’accompagne

évidemment d’une redondance des données pour augmenter la robustesse Chaque zone est

en fait prise en charge par plusieurs serveurs répartis géographiquement ettopologiquement

Parmi les serveurs autoritaires pour une zone, l’un d’entre eux (le serveur primaire) estchargé de transmettre une réplique du fichier de zone chaque fois qu’il est modifié auxautres serveurs (les secondaires), une telle opération est appelée transfert de zone

Il y a un autre type de serveur de nom qui ne contrôle pas la zone mais fournit unmécanisme d’augmentation de performance, appelé serveur de cache (caching server) Leserveur de cache met en cache les réponses des serveurs autoritaires Plus tard si les clients(résolveurs) lui demandent des mêmes informations, il peut leur répondre immédiatementsans passer les requêtes au serveurutoritaire (figure 2)

Les logiciels pour le serveur de nom les plus utilisés sont BIND de l’Internet Software Consortium, djbdns de D J Bernstein, Domain name server de Microsoft.

Trang 9

Figure 2 Le flux des requêtes/réponses

1.2 Le fichier de zone

Les informations d’une zone sont gardées dans le fichier de zone qui contient les enregistrements de ressource (resource record – RR) [1]

Un enregistrement de ressource se compose des champs suivants :

- Name : Nom de domaine auquel appartient l'enregistrement

- Class : Classe de l'enregistrement, normalement la classe IN (Internet) est utilisée

- Type : Type de l'enregistrement

- TTL : Durée de validité de l'enregistrement (Timeto live)

- RLENGTH : Longueur du champ 'RDATA'

- RDATA : Contenu de l'enregistrement

Les RRs de même nom et de même type sont regroupésen un ensemble de RRs, ditRRset Dans la classe Internet, différents types deRRs sont définis, dont :

- A : conversion d'une adresse IP en un nom

- CNAME : alias au nom

- MX : liste de sites avec préférence pour l'envoiede courriers

- NS : serveur autoritaire du domaine

- PTR : conversion d'un nom en adresse IP

- SOA : début d’une zone, ensemble de paramètres caractérisant une zone

Exemples :

Trang 10

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

Les deux lignes suivantes définissent les serveurs autoritaires du domaine enst.fr et aussi

Pour définir un alias :

apache.enst.fr IN CNAME www.enst.fr

1.3 Le message DNS

Dans la plupart des cas, un message DNS (requête ouréponse) est transporté par UDP(User Datagram Protocol) Le format d'un message DNS, défini par le RFC 1035 [1], est lesuivant :

- En-tête : Spécifie le type du message

- Question : Question posée au serveur de nom

- Réponse : RRs répondant à la question

- Autorité : RRs pointant sur un serveur d'autorité

- Additionnel : RRs donnant des informations complémentaires

1.4 La résolution DNS

La résolution DNS adresse à parcourir l’arbre DNS jusqu’à ce que le bon nœud soit

trouvé Considérons nous maintenant l’exemple précédant, on veut trouver l’adresse IP

du nom www.enst.fr et on suppose qu’aucune information n’est dans la cache La

première chose à chercher est l’adresse du serveur de nom du domaine fr, cette

information est connue par les serveurs de racine dont les adresses IP sont bien connues Puis le résolveur demande l’adresse du serveur de nom du domaine enst.fr et il reçoit l’adresse de ns1.enst.fr Enfin, ce serveur va nous donner l’adresse IP de www.enst.fr Si ns1.enst.fr n’est pas disponible, le résolveur essayera ns2.enst.fr

Trang 11

Racine «.»

.frRésolveur

.enst.fr

www.enst.fr

Figure 3 La résolution récursive

Pour faciliter les requêtes suivantes, le serveur de nom local (serveur de cache) va mettre

en cache l’adresse IP du nom www.enst.fr et toutes les autres informations acquises pourune certaine période de temps (TTL)

Il y aussi la résolution inverse qui traduit adresse IP en nom de domaine et elle fonctionne

de même manière que la résolution normale

1.5 L’enregistrements de colle et les points de délégation

Pour parcourir l’arbre DNS, la zone parent doit contenir les informations de sa zone fille.Dans le fichier de zone, ce sont les enregistrements de type NS que l’on appelle points dedélégation Ces enregistrements donnent les noms deserveur autoritaire de la zone fille.Pour communiquer avec ces serveurs, le résolveur a besoin des adresses IP qui sontstockées dans des enregistrements de colle Il estsimplement un enregistrement de type Aqui contient l’adresse IP de serveur de nom

Par exemple dans le fichier de zone fr :

ns1.enst.fr IN

N S A

ns1.enst.fr 137.194.8.214 point de délégation.enregistrement de colle.

1.6 Les attaques sur le DNS

DNS manque d’un mécanisme d’authentifier les informations que le serveur ou le résolveurreçoit Les messages ont une structure préformatée simple et sont transportés dans un

Trang 12

paquet UDP simple, non chiffré, non signé,ce qui rend très facile la génération de faux paquets et leur insertion dans le trafic DNS Le DNS est vulnérable aux fausses données.

Trang 13

1.6.1 L’empoisonnement de la cache

Dans le cas le plus simple, l’attaquant contrôle un serveur de nom autoritaire d’une zone(figure 4) D’abord, il demande au serveur de cache de victime des informations de sondomaine (1) Ce serveur doit transférer la requêteau serveur autoritaire qui est sous lecontrôle de l’attaquant (2) L’attaquant, à son tou r, force son serveur de retourner uneréponse contenant des fausses informations (3) Lavictime la croit et met en cache Doncl’attaquant a empoisonné la cache par les données orgéesf L’empoisonnement de cacheest difficile à détecter parce qu’il n’y a aucune erreur dans le fichier journal (log file)

Résolveur

Serveurautoritaire

Figure 4 L'empoisonnement de la cache 1.6.2 L’attaque de date de naissance

Pour identifier la paire requête-réponse, DNS utilise un nombre de transaction (transactionID) aléatoire de longueur 16 bits Quand le résolveur ou serveur de nom local (serveur de cache) reçoit des réponses, il doit comparer les numéros de transaction pour savoir quelle réponse est pour quelle requête Pourfausser la réponse, l’attaquant doit deviner le numéro

de transaction Dans ce type d’attaque (Figure 5), l’attaquant envoie n requêtes au serveur

de cache vulnérable (1) Le serveur de cache doit demander le serveur autoritaire de faire

la résolution (2) En même temps, l’attaquant va imiter le serveur autoritaire en envoyant nfausses réponses au serveur de cache (3) S’il y a une collision, c'est-à-dire qu’il y a une réponse dont le numéro de transaction est égal à celui d’une requête que le serveur de cache a envoyée, l’attaque est réussie Bien sur, la fausse réponse doit arriver avant la bonne réponse du serveur autoritaire et l’attaquant doit fausser aussi l’adresse de source des paquets L’at taquant peut aussi faire une attaque de

Trang 15

type DoS sur le serveur autoritaire pour le ralentir (3 bis) On peut calculer la probabilité

de collision par la fonction suivante [7]:

ó t = 65535 pour les numéro de transaction 16bits,n est le nombre de requêtes

L’attaque de date de naissance approche de 100% de succès quand le nombre de requête envoyée par l’attaquant est environ 700

Serveurautoritaire

(3 bis)

Attaquant(2)

(1)

Serveurrécursif(victime)

Avec BIND8, cet outil peut prédire le numéro aléatoire suivant en basant sur trois

numéros précédents avec la probabilité de succès 100%de !!!

BIND9 utilise une nouvelle fonction de génération esd nombres aléatoires basant sur/dev/random dans les systèmes Linux pour l’initialisation de la séquence, donc le résultaest mieux calprob peut prédire le numéro suivant dans la séquence avec la probabilité desuccès de 20%

30% est la probabilité de succès pour le teste avecdjbdns

Trang 16

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

En observant les résultats des testes, on peut noter que deux serveurs de nom, djbdns et BIND9, sont vulnérables si l’attaquant envoie un nombre suffisant des requêtes falsifiées (attaque brutale)

Les attaques sur le DNS peuvent causer des conséquences très graves Par exemple,l’attaquant peut rediriger les clients d’une banque vers un faux site pour voler desinformations bancaires Il peut aussi perturber ou bloquer le service DNS Puisque autresservices de réseau dépendent de DNS, donc ceci peutconduire à une perturbation duréseau

Trang 17

2 Le système de nom sécurisé (DNSSEC)

Pour résoudre les problèmes de sécurité de DNS, DNSSEC a été développé Sa spécification

a été détaillée dans le RFC2535 [2]DNSSEC ajoute les signatures numériques aux

informations de DNS, donc permet d’authentifier les informations (l’origine et l’intégrité) DNSSEC ne fournit pas al protection contre les attaques de type déni de service et les autres attaques sur le serveur de nom lui-même Il faut aussi noter que DNSSEC n’assure pas l’exactitude des donnés, elles peuvent être mal configurées au serveur de nom DNSSEC respecte la compatibilité ascendante (backward-compatibility) avec le protocole DNS: tous les nouveaux objets nécessités par DNSSEC suivent le format d’enregistrement de DNS, et les messages DNS restent identique

Dans DNSSEC, une zone est considérée sécurisée s’ily a au moins une signature pourchaque enregistrement de ressource sauf les enregistrements NS et les enregistrements decolle

2.1 Rappels de cryptographie à clefs publiques

2.1.1 Les algorithmes de chiffrement asymétriques

Le chiffrement asymétrique est fondé sur l’existenc de fonctions dites à sens unique, i.e facilement caculables mais dont l’inverse est très difficile à calculer En fait ce ne sont pas

de véritables fonctions à sens unique, mais plutôt des fonctions à sens unique à brèche secrète Une telle fonction est une fonctionqu'il est difficile d'inverser sauf pour celui qui possède une information particulière tenu secrète

De manière générale, les algorithmes de chiffrementasymétriques (RSA, ElGamal,Goldwasser Micali,…) tirent leur robustesse de la c omplexité de certaines opérationsmathématiques:

 La factorisation des nombres entiers

 Le logarithme discret modulo p

 Le résidu quadratique modulo n

Le principe de ces algorithmes est simple: avec une paire de clefs (clef publique et clefprivée), on peut chiffrer en utilisant une clef et déchiffrer en utilisant autre clef En général,

la clef privée est gardée secrète par leropriétaire et utilisée pour chiffrer les messages La

clef publique, sert à déchiffrer, est accessible par tout le monde

Trang 18

DNSSEC ET LA DISTRIBUTION SECURISEE DE CLEF

2.1.2 La fonction d’hachage

Les algorithmes de chiffrement permettent d’assurer la confidentialité des données Par contre, pour assurer l’authentification des entités en communication ou l’intégrité des données, ils ont besoin d’être combinés avec d’autres outils Un de ces outils est la

condensation ou autrement dit le hachage

Le hachage (ou la condensation) est une fonction qui transforme une entrée de taillevariable en une sortie de taille fixe appelée la valeur de hachage (ou le condensat) Cecondensat est l’empreinte du message initial

Le condensat doit vérifier trois propriétés :

 Réduction de la taille des données Le condensat doit avoir une taille inférieure

à celle du message initial Comme le condensat possède une taille fixe, alors quecelle du message ne l’est pas Il peut donc arriver dans certains cas rares que lemessage soit plus petit que le condensat Dans ce cas, on introduit du bourrage

 Reproductibilité Pour une entrée donnée, la foncti de hachage doit toujours retournée la même valeur

 A sens unique Etant donné un message M et son condensat H, il doit être très difficile de pouvoir trouver un message M’ tel que le condensat H’ de M’ soit égale

à H

2.1.3 La signature numérique

Le rôle d’une signature numérique est à la fois de détecter les modifications subites par lesdonnées en cours de transmission, mais également d’identifier de celui qui les a envoyées.Elle peut de plus assure la non répudiation des messages transmis

Les algorithmes de signature permettent la créationet la vérification des signatures Pour ceci, on utilise des techniques de chiffrement asymétriques L’expéditeur signe les données avec sa clé privée et le destinataire la vérifie avec la clé publique de l’expéditeur Comme

la clé privée est la propriété unique de sonpropriétaire et la clé publique est accessible à tous Seul le possesseur de la clé peut signer les messages, par contre tout le monde peut vérifier une signature

La signature utilise aussi des fonctions de condensation Mais ici, la condensation ne sertqu’à diminuer la taille des données à chiffrer En effet, comme on utilise des algorithmes

de chiffrement asymétriques, il faut tenter de réduire au maximum la taille des données à

Trang 19

chiffrer, sous peine de voir le temps de traitement atteindre des limites irréalistes pour une

utilisation commerciale Si la taille des données était suffisamment petite, on pourrait

imaginer des systèmes ne faisant pas intervenir de fonction de hachage Cependant, de

manière générale, une signature est constituée d’uncondensat de données avec des

informations supplémentaires, le tout chiffré grâce à la clé privée d’un algorithme

asymétrique

File

privée

Figure 6 La signature numérique 2.1.4 Le certificat

Lorsque deux entités disposent de certificats, elles s’en servent pour échanger leur clé

publique C’est un tiers de confiance en lequel les différentes parties en présence ont

confiance qui délivrent les certificats

Le certificat contient, au minimum, un identifiant et une clé publique de l’entité auquel il

appartient, ainsi que la signature de l’autorité de certification (AC) C’est cette signature

qui assure de la validité des informations contenues dans le certificat

Les certificats sont délivrés de manière hiérarchique Au sommet de la hiérarchie, il y a un

ou plusieurs autorités de certification capables de communiquer les unes avec les autres

Ces autorités certifient d’autres autoritésde niveau inférieur Chaque entité d’un certain

niveau peut certifier des autorités d’un niveau inférieur, on crée ainsi un arbre Il peut y

avoir plusieurs niveaux avant d’arriver aux autorités qui certifient les entités utilisatrices,

c’est à dire les personnes ou les ma chines qui ont besoin d’un certificat pour faire du

commerce électronique, par exemple

Ngày đăng: 30/10/2020, 21:18

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1] Mockapetris, P. “Domain names - Implementation and specification”, RFC 1035, 1987 Sách, tạp chí
Tiêu đề: Domain names - Implementation and specification
[2] Eastlake, D. “Domain Name System Security Exten sions”, RFC 2535, 1999 [3] Gudmundsson, O. “Delegation Signer (DS) Resourc e Record (RR)”, RFC 3658, 2003 Sách, tạp chí
Tiêu đề: Domain Name System Security Exten sions”, RFC 2535, 1999[3] Gudmundsson, O. “Delegation Signer (DS) Resourc e Record (RR)
[4] Léonard, B. “Sécurisation du DNS : les extensions DNSsec”, AFNIC/projet IDsA, 2003 Sách, tạp chí
Tiêu đề: Sécurisation du DNS : les extensions DNSsec
[5] Gieben, R. “Chain of Trust”, Stichting NLnet La bs, 2001 Sách, tạp chí
Tiêu đề: Chain of Trust
[6] Schlyter, J., “Storing application public key i n DNS”, draft-schlyter-appkey-02.txt (Internet draft), 2002 Sách, tạp chí
Tiêu đề: Storing application public key i n DNS
[7] Steward, J., “DNS Cache Poisoning - The Next Ge neration”, 2003 Sách, tạp chí
Tiêu đề: DNS Cache Poisoning - The Next Ge neration
[8] Zalewski, M. “Strange Attractors and TCP/IP Seq uence Number Analysis”. 2001, 2002 Sách, tạp chí
Tiêu đề: Strange Attractors and TCP/IP Seq uence Number Analysis
[9] Serhrouchni, A. “Les éléments de la cryptographie”, 2004 Sách, tạp chí
Tiêu đề: Les éléments de la cryptographie

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w