Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Using Digital Signature with DNS
Document related concepts
Cryptography wikipedia , lookup
Mobile security wikipedia , lookup
Information privacy law wikipedia , lookup
Quantum key distribution wikipedia , lookup
Denial-of-service attack wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
History of cryptography wikipedia , lookup
Data remanence wikipedia , lookup
Certificate authority wikipedia , lookup
Post-quantum cryptography wikipedia , lookup
Diffie–Hellman key exchange wikipedia , lookup
Transcript
Using Digital Signature with DNS DNS structure • Virtually every application uses the Domain Name System (DNS). • DNS database maps: – Name to IP address www.darpa.mil = 128.9.176.20 – And many other mappings (mail servers, IPv6, reverse…) • Data organized as tree structure. – Each zone is authoritative for its local data. Example of Zone file Example Zone file dacht.net 7200 IN SOA ns.ripe.net. olaf.ripe.net.( 2001061501 ; Serial 43200 ; Refresh 12 hours 14400 ; Retry 4 hours 345600 ; Expire 4 days 7200 ; Negative cache 2 hours ) dacht.net 7200 IN NS ns.ripe.net. dacht.net 7200 IN NS ns.high5.net. pinkje.dacht.net 3600 IN A 193.0.1.162 host25.dacht.net 2600 IN A 193.0.3.25 DNS resolving Question: www.cnn.com . www.cnn.com A ? dns.cs.umass.edu lab.cs.umass.edu stub resolver ask .com server the ip address of .com server www.cnn.com A ? xxx.xxx.xxx.xxx resolver www.cnn.com A ? .com ask cnn.com server the ip address of cnn.com server add to cache www.cnn.com A ? xxx.xxx.xxx.xxx www.cnn.com cnn.com DNS Vulnerabilities Client <-> DHCP Server Client <-> Resolver Resolver itself (rootfile) Resolver's communication to the net Various glue records and their update mechanism Various nameserver <-> nameserver communication Various network <-> network communication • • • • • • • Focus on vulnerabilities Cache impersonation Corrupting data Impersonating master Zone administrator Zone file master Dynamic updates slaves resolver stub resolver Unauthorized updates Server Protection Cache pollution by Data spoofing Data Protection Historical reasons • Original DNS design focused on data availability – DNS zone data is replicated at multiple servers. – A DNS zone works as long as one server is available. • DDoS attacks against the root must take out 13 root servers. • But the DNS design included no authentication. – Any DNS response is generally believed. – No attempt to distinguish valid data from invalid. • Just one false root server could disrupt the entire DNS. Simple attack Easy to observe UDP DNS query sent to well known server on well known port. www.darpa.mil A? Root DNS Server www.darpa.mil A 192.5.18.19 Doug’s Laptop www.darpa.mil A 128.9.128.127 Caching DNS Server mil DNS Server Dan’s Laptop First response wins. Second response is silently dropped on the floor. darpa.mil DNS Server More complex attack DARPA Caching Server Response www.attacker.com attacker.com attacker.com ns.attacker.com www.google.com www.google.com = 128.9.128.127 A 128.9.128.127 NS ns.attacker.com NS www.google.com A 128.9.128.2 A 128.9.128.127 ns.attacker.com Query www.attacker.com Query www.google.com Any DARPA Computer Remote attacker What is the problem ? • Resolver can not distinguish between valid and invalid data in a response. • Idea is to add source authentication – Verify the data received in a response is equal to the data entered by the zone administrator. – Must work across caches and views. – Must maintain a working DNS for old clients. What is solution ? • Each DNS zone signs its data using a private key. – Recommend signing done offline in advance • Query for a particular record returns: – The requested resource record set. – A signature (SIG) of the requested resource record set. • Resolver authenticates response using public key. – Public key is pre-configured or learned via a sequence of key records in the DNS heirarchy. Protect DNS with digital signature • Secure client <-> resolver communication – Secure LAN/DHCP – DNSSEC aware Resolver on Client(!) • Secure communication between nameservers – Zone transfers (AXFR) – dynamic updates • Secure data storage integrity – Zonefiles – Caches DNSSEC • The core of the DNSSEC specification is described in the following 3 RFCs, published March 2005: • RFC 4033 - DNS Security Introduction and Requirements • RFC 4034 - Resource Records for the DNS Security Extensions • RFC 4035 - Protocol Modifications for the DNS Security Extensions Main Goal of DNSSEC • a) origin authentication of DNS data, • b) data integrity • c) authenticated denial of existence. New record types • The KEY record: The public key used • The SIG record: The signatures created by that key • The NXT record: For denial of existance • The DS record: For building the chain of trust How does it work • The DNS servers sign (digitally encrypt)the hash of resource record set with its private keys • Resouce record set: The set of resource records of the same type. • Public KEYs can be used to verify the SIGs • The authenticity of public KEYs is established by a SIGnature over the keys with the parent’s private key • In the ideal case, only one public KEY needs to be distributed off-band (the root’s public KEY) Key record RRlabel TTL IN KEY <flags> <protocol> <algorithm> <key material> freeswan.nl. 3600 IN KEY 256 3 5 ( AQPRv8TN8ayfxrtRo1dveOMVSSpT4PGEZvfGjaERldQZ izYKgVBj/l84DjVktGUbkJ3pBiLBAzZ+5nbGkWn+Lz5Z gHMlQnjWde/mKKDlZnwQ13vU+HPt3cszNy9CdBmn6l8= ) ; key id = 56954 flags: authentication, confidentiality protocol: DNSSEC = 3, IPsec = 4 [only protocol 3 is allowed since RFC3445] algorithm: RSAMD5 = 1, DiffieHellman = 2, DSA = 3, EllipticCurve = 4, RSASHA1 = 5 The SIG record RRlabel TTL IN SIG <type covered> <algorithm> <# of labels> <original ttl> <sig expiration> <sig inception> <key tag> <signer name> <key material> freeswan.nl. freeswan.nl. freeswan.nl. 3600 IN NS ns.xtdnet.nl. 3600 IN NS ns1.xtdnet.nl. 3600 IN SIG NS 5 2 3600 20030506165654 ( 20030406165654 56954 freeswan.nl. bTKJvyrwmP+nsFoE8oelC4gFqoyJxkawNIExMVupI+ie NeyUYdkrpDVBF5yn7U0dLxQu/+wqbOGYjPWx/r1ybZF7 JMd1PRefb30TsBtsrA9Ah13EKmO18oyJEZdDWwPV ) The NXT record RRlabel TTL IN NXT <alphanumeric next RRlabel> <list of existing RRsets> alpha.freeswan.nl. 3600 IN NXT gamma.freeswan.nl. NS SOA MX SIG KEY NXT Denial of existance: We now know there is no RRset beta.freeswan.nl. Delegation problem • The Parent should securely delegate authority of the child zone – Parent cannot give a “non-authoritative” answer • Parent cannot not sign child zone data – It has no private key of child • Parent should not sign child zone data – It is not authoritative for child zone • Parent will need to serve NS (and perhaps glue) records of child zone • Answer needs to be secure The DS record Sign a hash of the child key RRlabel TTL IN DS <key tag> <algorithm> <20 bit SHA-1 Digest> freeswan.nl. 345600 IN NS ns.xtdnet.nl. freeswan.nl. 345600 IN NS ns1.xtdnet.nl. freeswan.nl. 345600 IN DS 49601 5 1 ( C7D3B76F7DEE10E6A73B7D0F6EDAF55FFF60CA78 ) freeswan.nl. 345600 IN SIG DS 1 2 345600 20030416070311 ( 20030409070311 6869 nl. W2pmK7IGF1W7SDJxyyTep707lDRQ36IEkmyEhezJO72U 3g1YeWTI4r5lSAOkGW/+u74FRuQgMFzYzRisCZKYCiBm rNiatRg+TTf9+yzJcqg9A2CuygNBi8I7aVloYxsM+qri 9J1CJQuxAzbKLPAppQw4UP1VOiB4NvHWG2jwFNw= ) - These are all the freeswan.nl records at the parent - Parent only signs DS record for which it is authoritative. Is it deployed • • • • • Standard since 2005 Not yet deployed at a large scale !! Considerable overhead (CPU, network). No major attacks against DNS justify the need. Could we consider it as a “failed” case for security ? • Telnet was replaced by SSH, FTP replace with secure version. Only DNS and SMTP remain totally unsecured. THANK YOU QUESTIONS ?
