Security of DNS


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Security of DNS

  1. 1. Security challenges in DNS Philippe Camacho Department of Computer Science University of Chile Workshop on Formal Methods in Cryptography 27-30 april 2009 / Campinas - Brazil
  2. 2. Outline DNS DNSSEC Basics Key Rollover Problems and Limitations How to improve the Security of DNS? Threshold Cryptography Identity Based Cryptography
  3. 3. DNSA (brief) history ARPANET in the 70’s Small, friendly network of a few hundreds of hosts. A centralized HOSTS.TXT file was used to map host names to network adresses. This file was updated once or twice a week. BUT, with the growth of ARPANET this scheme became unpracticable Traffic Load Name Collision Consistency
  4. 4. DNSBasics Domain Name System (DNS) Maps IP adresses to human friendly computer hostnames But also manages other type of information such as the list of mail servers associated to a domain Distributed, Replicated, Fault Tolerant Developped by the IETF (Internet Engineering Task Force) at the beginning of 1980’s
  5. 5. DNSDomain Namespace root cl edu mil org uchile .cl DOMAIN Domain contains information called dcc Resource Records (RR). For example the IP address associated to
  6. 6. DNSName servers and Zones / cl edu mil org uchile NAME SERVER of the ZONE ingenieria dim dcc Delegation
  7. 7. DNSName servers and Zones / cl edu com org uchile NAME SERVER of the ZONE + ingenieria dim dcc Delegation
  8. 8. DNSType of Resource Records (RR) A Host Addresses PTR Reverse address name mappingCNAME Aliases MX Mail exchange for the domain NS Authoritative Name Servers
  9. 9. DNSResolvers and Name Resolution Clients that access name servers Name Space Name serverResolver assignedname server is200.1.123.4
  10. 10. DNSResolving Algorithms / Iterative Resolver .cl l? .c 3. 4 .12 .1 00 ? 2 cl hile. .uc .70 .3 ? 0.8 20 ? dcc.uch .2 192.80.24 www.dcc.uc ? 192.80 .2 4.4 Name Server
  11. 11. DNSResolving Algorithms Recursive ww w. go og le. co Resolver m ? ? om .c le o og .g w w 7 w 14 ? 63. .1 ? 33 ww .2 64 w. go og le. co m ? 64.233 .163.1 47 Name Server
  12. 12. DNSCaching DNS uses cache to improve performance e.g: In the case of iterative resolving What is the IP for I know the IP for the name server of the zone I can ask this server directly without starting from the root. Time To Live (TTL) Tradeoff between consistency and efficiency
  13. 13. DNSAttacks Many attacks on the DNS (references) Man in the Middle Cache poisoning (Distributed) Denial of Service Major problem Lack of integrity / authenticity Consequences are HUGE Phishing Defacements Internet is down
  14. 14. DNSAttacks Man in the Middle (1) (True IP) (3) (Too late) (2 )( Ev il ar 1. ri v 2. 3. es 4 fir st )
  15. 15. DNSAttacks Cache Poisoning (AlterNIC 1997) ww w.s o me site .co m? 1. 2 ( 5) (6) .3.4 (Fro mc (2) ach e) 1) ?( om (4) Too late again… sit e.c ome w.s ter ww .3. 4 as 1 .2 sf E vil’ (3)
  16. 16. DNSAttacks (Distributed) Denial of Service Such as every internet service, DNS is exposed to (D)DoS However the specificity of the protocol allows amplification attacks (D)DoS is really hard to avoid As we shall see DNSSEC do not pretend to solve this problem and could possibly make it worse…
  17. 17. DNSAttacks A new attack [Kaminsky 08] Presented at Black Hat 2008 Previous attack only allows to forge only one (url,ip) mapping. Kaminsky’s attack is far more devastating Allows to control a whole domain (.cl) This is scary… Many certificate authorities validate a user’s certificate by sending an email… So in this case even SSL is useless!
  18. 18. DNSAttacks The Attack [Kaminsky 08] / (basic idea) Resolver .cl ) te la oo l? (T .c 3. 4 .12 .1 00 ? 2 cl hile. .uc 2 .3. ? 1.2 ? dcc.uch l t.c xis ote www.dcc.uc esn ? .do www (First)
  19. 19. DNSSECBasicsWhat it is for? Authenticate data exchanged between the participants of the protocolWhat it is NOT for? Guarantee privacy (except for NSEC3) Ensure availability
  20. 20. DNSSECBasicsCore RFCs that describe DNSSEC DNS Security Introduction and Requirements (4033) Resource Records for the DNS Security Extensions (4034) Protocol Modifications for the DNS Security Extensions (4035)Another important RFC DNSSEC Operational Practices (4641)Web
  21. 21. DNSSECBasics / cl edu mil org • Every zone signs the public uchile key of its children • The public key of the root is preinstalled in nameserver. • Every message (resource ingenieria dim dcc record) is signed by its author.
  22. 22. DNSSECResolution & Verification / Iterative Resolver .cl NS1 .cl l? .c 3. 4 .12 .1 00 ? 2 cl hile. .uc .70 9 .3 ? 0.8 20 ? dcc.uch .2 192.80.24 / www.dcc.uc ? 192.80 .2 4.4 Name Server NS1
  23. 23. DNSSECResolution & Verification Recursive NS2 NS3 ww w. go og le. co Resolver m ? NS1 NS3 ? om e.c NS4 gl oo .g w w 7 w 14 ? 63. .1 ? 33 ww .2 64 w. go og NS4 le. co m ? NS5 64.233 .163.1 47 NS2 Name Server NS1 NS5
  24. 24. DNSSECOperational Practices Time Assumption: global clock. Every signed information has a limited lifetime. This also applies to keys.
  25. 25. DNSSECOperational Practices Two types of Keys KSK Parent Zone Signing Keys (ZSK) signs Are used to sign all the information of the zone ZSK Key Signing Keys (KSK) ZSK Are used to sign the ZSK Child signs ZSK are used to sign the KSK of the child KSK
  26. 26. DNSSECOperational Practices Motivation of the use of KSK/ZSK No parent/child interaction is required when ZSKs are updated. The KSK can be made stronger. KSK is only used to sign a set of keys. It can be stored in a safer place. KSK have longer effectivity period.
  27. 27. DNSSECOperational Practices KEY ROLLOVER It is necesarry to change the keys from time to time As to make cryptanalysis harder => Scheduled Rollover Private keys may be stolen or cracked => Unscheduled Rollover
  28. 28. DNSSECOperational Practices Where can a keyrollover occur? / Parent Resolver Warn that NEW PK is available Get NEW PK Child Name Server Publish NEW public key
  29. 29. DNSSECOperational Practices Scheduled Key Rollover How do name servers/resolvers know this new public key? Pre-Publish Key Rollover Double Signature Rollover ZSK Rollover No interaction needed KSK Rollover Interaction needed between child and parent
  30. 30. DNSSECOperational Practices ZSK Prepublish Rollover initial New DNSKEY New Signatures DNSKEY Removal KSK KSK KSK KSK ZSK1 ZSK1 ZSK1 ZSK2 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZSK2}KSK{ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  31. 31. DNSSECOperational Practices ZSK Prepublish Rollover initial New DNSKEY New Signatures DNSKEY Removal KSK KSK KSK KSK ZSK1 ZSK1 ZSK1 ZSK2 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZSK2}KSK{ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  32. 32. DNSSECOperational Practices ZSK Prepublish Rollover initial New DNSKEY New Signatures DNSKEY Removal KSK KSK KSK KSK ZSK1 ZSK1 ZSK1 ZSK2 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZSK2}KSK{ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  33. 33. DNSSECOperational Practices ZSK Prepublish Rollover initial New DNSKEY New Signatures DNSKEY Removal KSK KSK KSK KSK ZSK1 ZSK1 ZSK1 ZSK2 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZSK2}KSK{ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  34. 34. DNSSECOperational Practices ZSK Double Signature Rollover initial New DNSKEY DNSKEY Removal KSK KSK KSK ZSK1 ZSK1 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  35. 35. DNSSECOperational Practices ZSK Double Signature Rollover initial New DNSKEY DNSKEY Removal KSK KSK KSK ZSK1 ZSK1 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  36. 36. DNSSECOperational Practices ZSK Double Signature Rollover initial New DNSKEY DNSKEY Removal KSK KSK KSK ZSK1 ZSK1 ZSK2 ZSK2 {ZSK1}KSK {ZSK1}KSK {ZSK2}KSK {ZSK2}KSK {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK1 {ZONE_DATA}ZSK2 {ZONE_DATA}ZSK2
  37. 37. DNSSECOperational Practices Pros and Cons Prepublish Key Rollover + Does not involve signing all the zone data twice. - Process requires 4 steps. Double Signature + Process requires 3 steps. - The number of signatures in the zone doubles. Prohibitive for big zones.
  38. 38. DNSSECOperational Practices KSK Rollover Same idea Now the data to sign are (zone signing) keys However Double Signature Rollover seems better as the data signed is only a set of key The child needs to warn the parent securely that the keys have changed. The way to do this is left to the DNSSEC administrators.
  39. 39. DNSSECOperational Practices Unscheduled Key Rollover PANIC! “An authenticated out-of-band and secure notify mechanism to contact parent is needed in this case.” (RFC 4641)
  40. 40. DNSSECOperational Practices Unscheduled Key Rollover Keep the chain of trust intact Resign with the compromised key the new set of keys with a very short lifetime, then make a rollover Problem: DOMAIN DISPUTE The adversary controls the compromised key, so he can also make a keyrollover… At the end who should we believe? Break the chain of trust Say to the clients that there is a problem Fix the problem Interact with the clients to distribute the new public key Problem: DNSSEC is down for a while
  41. 41. NSEC 3 DNSSEC not only provides an authenticated mapping between IP and domains but also provides proofs of non existence (membership) e.g: Q: ? A: this domain does not exist For efficiency As to avoid signing dynamically the response the consecutive pair of domains ordered in alphabetic order are signed. All proofs are precomputed. [,], [,], [,], [,] does not exist < <
  42. 42. NSEC 3 Problem: Zone Walking An attacker can collect all the domains of a zone, by asking for domain that lies inside of every succesive intervals. Is that a problem? After all the information is public… Yes but in some case knowing all the domain names for a given level can be a useful information to build an attack for example.
  43. 43. NSEC 3 Solution Applying a hash function H to the domain names as to hide the information of the domain and still be able get nonmembership proofs. H( H( H( H( H( H(
  44. 44. DNSSECProblems and Limitations First proposal 1999 (RFC 2535) but still no current implementation at root level 2009 Only a few of the Top Level Domains (.com, .org, countries…) run DNSSEC Chile is working hard at this moment to implement it! Why? Who signs the root? Practical Experiences (Netherlands,…) have been painful DNSSEC is complex People may not see the immediate benefit …
  45. 45. DNSSECProblems and Limitations DNSSEC is a “Non End to End” Protocol End to End Protocol: SSH The end user does NOTknow whether the chain of trust has been broken! Non End to End Protocol: DNSSEC
  46. 46. DNSSECProblems and Limitations How to set the public keys life-time? Too big => gives more time to the Adversary Too short => inefficient Need to rollover key very often
  47. 47. DNSSECProblems and Limitations How to detect (automaticaly) that a private key has been stolen? Users generally don’t notice they have been victim of a phishing attack. Defacement When obtained by DNS cache poisoning, the owner of the website is not aware of it. So in practice can we really detect that a key has been compromised?
  48. 48. DNSSECProblems and Limitations Key Rollover/Revocation Problem There is no real satisfactory solution for Key Revocation Key Rollver is complex Lack of specification No precise procedure in case of key compromise. How does the child warn its parent?
  49. 49. How to improve the Security ofDNS? There is no definition for the Adversary What can or cannot do the adversary Steal private keys? Only forge some signatures? Intercept any packet? Control a DNS Name Server? Create a Zone / Domain? Injection attack in Registrars Databases …
  50. 50. How to improve the Security ofDNS? Use of Threshold Cryptography [Cachin, Samar 04] What is Threshold Cryptography (very short)? N participants T participants can jointly sign T-1 participant cannot do anything =>Adversary must control T servers to perform an attack N=4 T=2 participants required to sign
  51. 51. How to improve the Security ofDNS? Use of Threshold Cryptography [Cachin, Samar 04] Concrete proposal They use standard RSA signature Need to change the server implementation but not the client Benchmark Stealing private key is harder It can be effective against internal attacks. However If the servers that hold the share have got the same configuration, a same vulnerability can be enough to compromise all the servers. More Complex
  52. 52. How to improve the Security ofDNS? Identity Based Cryptography [Chan 03] Master Thesis work. Analyzes the possibilty to use IBC to improve the security of DNS instead of using standard public key cryptography. Original approach to solve this problem.
  53. 53. IBC Idea A Trusted Authority (TA) generates (SK,PK) and distributes securely the private keys to every participant. Then the TA publishes a public key PK The public key of every participant can be computed from PK and a public information Email, Name, Passport Number, Biometric data
  54. 54. DNS with IBC [Shamir, 84] First introduction of the concept. [Boneh,Franklin 01] First efficient scheme for IBC using bilinear maps. Many other works, this is a very active field.
  55. 55. IBC Advantages No need to store public keys No need to sign/verify public keys No need to manage certificates
  56. 56. DNS with IBC Problem: Key Escrow The TA knows (generates) all the private keys of users. Is that really a problem? ANSWER NO: in our setting, a parent can always create new children with their respective private keys.
  57. 57. DNS with IBC Key Rollover Add timestamp to the identity || 28-4-2009::29-4-2009 Key Revocation Still hard We could use a database of revocated keys but we would loose the good properties of IBC…
  58. 58. DNS with IBC Problem of scalability A single authority has to generate all the private keys. This is not reasonable in the case of DNS. Solution Use of Hierchical Identity Based Cryptography The private key generation can be delegated to subauthorities [Gentry, Silverberg 02]
  59. 59. DNS with HIBC ID1: root ID2:cl edu mil org ID3:uchile ID1 ID2 ID3 ID4 root cl uchile dcc ID4:dcc ingenieria
  60. 60. DNS with HIBC How to sign? ID1 ID2 ID3 ID4 ID5 root cl uchile dcc PKA SKA PKB SKB = {}SKA Verification process (1) R random (2) C = Encrypt(PKB,R) (3) R’ = Decrypt(SKB,C) (4) R = R’ ?
  61. 61. DNS with HIBC Efficiency The size of a signature grows linearly in the depth of the hierarchy. So we do not win to much (even we may loose) compared to the classical DNSSEC verification procedure.
  62. 62. DNS with HIBC So at the end, is HIBC useful? HIBC has attractive properties No need to manage public key/certificates Simplifies the scheduled key rollover However some problems remain unsolved Key revocation (unscheduled key rollover) Verification time proportional to the depth of the domain name tree. Not clear that how to adapt the Recursive Resolving Algorithm In practice developping standards for pairings and HIBC takes time.
  63. 63. Conclusion DNS is essential for Internet DNS is not secure and this is a big problem DNSSEC adds integrity/authenticity to DNS DNSSEC raises some practical problems Key Rollover All or Nothing security / Not Point to Point Administrative problem: who signs the root? But DNSSEC is to the date the only concrete proposal to make DNS more secure. Can we do better?
  64. 64.