Protection of DNS using HAVAL

Transcription

1 International Journal of Electronics and Computer Science Engineering 972 Available Online at ISSN Protection of DNS using HAVAL Raghvendra Vikram Singh 1, Deepak Chaudhary Department of Computer Science & Engineering 1 raghvendra076@gmail.com 2 Affiliation name 1 - XYZ Abstract- The obligatory of IP addresses to host names became a major problem in the rapidly growing Internet and the higher level obligatory effort went through different stages of development up to the currently used Domain Name System (DNS). The DNS Security is designed to provide security by combining the concept of both the Digital Signature and Asymmetric key (Public key) Cryptography. Here the Public key is send instead of Private key. The DNS security uses Message Digest Algorithm to compress the Message(text file) and PRNG(Pseudo Random Number Generator) Algorithm for generating Public and Private key. The message combines with the Private key to form a Signature using DSA Algorithm, which is send along with the Public key.the receiver uses the Public key and DSA Algorithm to form a Signature. If this Signature matches with the Signature of the message received, the message is Decrypted and read else abandoned. Keywords DNS, FQDN, PRNG, DSA, HAVAL A. Scope of the Project I. INTRODUCTION The Domain Name System(DNS) has become a critical operational part of the Internet Infrastructure, yet it has no strong security mechanisms to assure Data Integrity or Authentication. Extensions to the DNS are described that provide these services to security aware resolves are applications through the use of Cryptographic Digital Signatures. These Digital Signatures are included zones as resource records. The extensions also provide for the storage of Authenticated Public keys in the DNS. This storage of keys can support general Public key distribution services as well as DNS security. These stored keys enables security aware resolvers to learn the authenticating key of zones, in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. In addition, the security extensions provide for the Authentication of DNS protocol transactions.[9] The DNS Security is designed to provide security by combining the concept of both the Digital Signature and Asymmetric key (Public key) Cryptography. Here the Public key is send instead of Private key. The DNS security uses Message Digest Algorithm to compress the Message(text file) and PRNG(Pseudo Random Number Generator) Algorithm for generating Public and Private key. The message combines with the Private key to form a Signature using DSA Algorithm, which is send along with the Public key.[2] The receiver uses the Public key and DSA Algorithm to form a Signature. If this Signature matches with the Signature of the message received, the message is Decrypted and read else discarded. B. Problem Statement Authenticity is based on the identity of some entity. This entity has to prove that it is genuine. In many Network applications the identity of participating entities is simply determined by their names or addresses. High level applications use mainly names for authentication purposes, because address lists are much harder to create, understand, and maintain than name lists. Assuming an entity wants to spoof the identity of some other entity, it is enough to change the mapping between its low level address and its high level name. It means that an attacker can fake the name of someone by modifying the association of his address from his own name to the name he wants to impersonate. Once an attacker has done that, an authenticator can no longer distinguish between the true and fake entity.

2 Protection of DNS using HAVAL 973 RELATED WORKS A. The Domain Name Space II. PROPOSED ALGORITHM The DNS is a hierarchical tree structure whose root node is known as the root domain. A label in a DNS name directly corresponds with a node in the DNS tree structure. A label is an alphanumeric string that uniquely identifies that node from its brothers. Labels are connected together with a dot notation, ".", and a DNS name containing multiple labels represents its path along the tree to the root. Labels are written from left to right. Only one zero length label is allowed and is reserved for the root of the tree. This is commonly referred to as the root zone. Due to the root label being zero length, all FQDNs end in a dot.[10] As a tree is traversed in an ascending manner (i.e., from the leaf nodes to the root), the nodes become increasingly less specific (i.e., the leftmost label is most specific and the right most label is least specific). Typically in an FQDN, the left most label is the host name, while the next label to the right is the local domain to which the host belongs. The local domain can be a subdomain of another domain. The name of the parent domain is then the next label to the right of the subdomain (i.e., local domain) name label, and so on, till the root of the tree is reached. Root. Least specific Org com Plain example example sample www testbed Most specific host1 Figure 1. Domain Name Space example When the DNS is used to map an IP address back into a host name (i.e., inverse resolution), the DNS makes use of the same notion of labels from left to right (i.e., most specific to least specific) when writing the IP address. This is in contrast to the typical representation of an IP address whose dotted decimal notation from left to right is least specific to most specific. To handle this, IP addresses in the DNS are typically represented in reverse order. IP addresses fall under a special DNS top level domain (TLD), known as the in-addr.arpa domain. By doing this, using IP addresses to find DNS host names are handled just like DNS host name lookups to find IP addresses.

3 IJECSE,Volume2, Number 3 Raghvendra Vikram Singh and Deepak Chaudhary 974 Figure 2. Example of inverse domains and the Domain Name Space[5] B. DNS Components The DNS has three major components, the database, the server, and the client[4]. The database is a distributed database and is comprised of the Domain Name Space, which is essentially the DNS tree, and the Resource Records (RRs) that define the domain names within the Domain Name Space. The server is commonly referred to as a name server. Name servers are typically responsible for managing some portion of the Domain Name Space and for assisting clients in finding information within the DNS tree. Name servers are authoritative for the domains in which they are responsible. They can also serve as a delegation point to identify other name servers that have authority over subdomains within a given domain. The RR data found on the name server that makes up a domain is commonly referred to as zone information. Thus, name servers have zones of authority. A single zone can either be a forward zone (i.e., zone information that pertains to a given domain) or an inverse zone (i.e., zone information that maps IP addresses into DNS host names). DNS allows more than one name server per zone, but only one name server can be the primary server for the zone.[3] Primary servers are where the actual changes to the data for a zone take place. All the other name servers for a zone basically maintain copies of the primary ry server s database for the zone. These servers are commonly referred to as secondary servers. A DNS RR has 6 fields: NAME, TYPE, CLASS, TTL, RD Length, and RDATA. The NAME field holds the DNS name, also referred to as the owner name, to which the RR belongs. The TYPE field is the TYPE of RR. This field is necessary because it is not uncommon for a DNS name to have more than one type of RR. The more common types of RR are found in Table 1. RECORD TYPE A PTR NS SOA DESCRIPTION An address record A pointer record A name server record A Start of Authority record USAGE Maps FQDN into an IP address Maps an IP address into FQDN Denotes a name server for a zone Specifies many attributes concerning

4 Protection of DNS using HAVAL 975 the zone, such as the name of the domain (forward or inverse), administrative contact, the serial number of the zone, refresh interval, retry interval, etc. CNAME A canonical name record Defines an alias name and maps it to the absolute (canonical) name MX A Mail Exchanger record Used to redirect for a given domain or host to another host Table 1. Common DNS Resource Records[1] The CLASS in this case is "IN" which stands for Internet. Other classes exist but are omitted for brevity. The TTL is the time, in seconds, that a name server can cache a RR. A zero time to live means that a server is not to cache the RR. RD Length is the RDATA field s length in octets. The RDATA field is the resource data field and is uniquely defined for each TYPE of RR, but in general it can be thought of as the value into which the entity specified in the NAME field maps. The NAME field can be thought of as the subject of a query, although this is not always the case, and the answer is the data contained in the RDATA field (even though the entire RR is returned in a DNS response) [RFC 1035].RRs are grouped into resources records sets (RRSets). RRSets contain 0 or more RRs [RFC 2136] that have the same DNS name, class, and type, but the data (i.e., RDATA) is different. If the name, class, type, and data are the same for two or more records then duplicate records exist for the same DNS name. Name servers should suppress duplicate records [14]. The Figure 3 shows an example of a RRSet.[6] example.com. example.com. example.com. IN IN IN NS NS NS ns1.example.com. ns2.example.com. ns.plain.org. Figure 3. These three records are grouped into a RRSet. The client component of the DNS typically contains software routines, known as functions, which are responsible for requesting information from the Domain Name Space on behalf of an application. These functions are bundled

5 IJECSE,Volume2, Number 3 Raghvendra Vikram Singh and Deepak Chaudhary 976 together into a software library that is commonly referred to as the resolver library. For this reason, clients are often called resolvers. The resolver library functions are responsible for sending a query to a name server requesting information concerning a DNS name and returning the answer to the query back to the requestor. C. DNS Transactions DNS transactions occur continuously across the Internet. The two most common transactions are DNS zone transfers and DNS queries/responses. A DNS zone transfer occurs when the secondary server updates its copy of a zone for which it is authoritative. The secondary server makes use of information it has on the zone, namely the serial number, and checks to see if the primary server has a more recent version. If it does, the secondary server retrieves a new copy of the zone. A DNS query is answered by a DNS response. Resolvers use a finite list of name servers, usually not more than three, to determine where to send queries. If the first name server in the list is available to answer the query, than the others in the list are never consulted. If it is unavailable, each name server in the list is consulted until one is found that can return an answer to the query. The name server that receives a query from a client can act on behalf of the client to resolve the query. Then the name server can query other name servers one at a time, with each server consulted being presumably closer to the answer. The name server that has the answer sends a response back to the original name server, which then can cache the response and send the answer back to the client. Once an answer is cached, a DNS server can use the cached information when responding to subsequent queries for the same DNS information. Caching makes the DNS more efficient, especially when under heavy load. This efficiency gain has its tradeoffs; the most notable is in security.[12] D. Proposed System Taking the above prevailing system into consideration the best solution is using Pseudo Random Number Generator for generating KeyPair in a quick and more secured manner. We use HAVAL for producing MessageDigest and Compressing the message. Signature is created using Private Key and MessageDigest which is transmitted along with the Public Key. The transfer of the packets from each System to System is shown using Graphical User Interface (GUI). Each time the System get the message, it verifies the IPAddress of the sender and if no match is found it discards it. For verification, the Destination System generates Signature using PublicKey and DSA Algorithm and verifies it with received one. If it matches it Decrypts otherwise it discards. The Following functions avoids the pitfalls of the existing system. Fast and efficient work Ease of access to system Manual effort is reduced III. EXPERIMENT AND RESULT A one-way hashing algorithm is a deterministic algorithm that compresses an arbitrary long message into a value of specified length. The output value represents the digest or fingerprint of the message. A cryptographically useful property of a one-way hashing algorithm is that it is infeasible to find two distinct messages that have the same digest. This paper proposes a one-way hashing algorithm called HAVAL. HAVAL compresses a message of arbitrary length into a digest of 128, 160, 192, 224 or 256 bits. In addition, HAVAL has a parameter that controls the number of passes a message block (of 1024 bits) is processed. A message block can be processed in 3, 4 or 5 passes. By combining output length with pass, we can provide fifteen (15) choices for practical applications where different levels of security are required. The algorithm is very efficient and particularly suited for 32-bit computers which predominate the current workstation market. Experiments show that HAVAL is 60% faster than MD5 when 3 passes are required, 15% faster than MD5 when 4 passes are required, and as fast as MD5 when full 5 passes are required. It is conjectured that finding two collision messages requires the order of 2n/2 operations, where n is the number of bits in a digest.[18]

6 Protection of DNS using HAVAL 977 A.The Updating Algorithm H The updating algorithm H processes a block in 3, 4 or 5 passes, which is specified by the 3-bit field PASS in the last block. Denote by H1, H2, H3, H4 and H5 the five passes. Now suppose that the input to H is (Din,B), here Din is a 8-word string and B is a 32-word (1024-bit) block. Let Dout denote the 8-word output of H on input (Din,B). Then processing of H can be described in th following way.[15] E0 = Din; E1 = H1(E0,B); E2 = H2(E1,B); E3 = H3(E2,B); E4 = H4(E3,B); (if PASS=4, 5) E5 = H5(E4,B); (if PASS=5) Dout =8< : E3 + E0 if PASS=3 E4 + E0 if PASS=4 E5 + E0 if PASS=5 Each of the five passes H1, H2, H3, H4 and H5 has 32 rounds of operations and each round processes a different word from B. The orders in which the words in B are processed differ from pass to pass. In addition, each pass employs a different Boolean function to perform bit-wise operations on words.[11] The five functions employed by H1, H2, H3, H4 and H5 are: f1(x6, x5, x4, x3, x2, x1, x0) = x1x4 _ x2x5 _ x3x6 _ x0x1 _ x0 f2(x6, x5, x4, x3, x2, x1, x0) = x1x2x3 _ x2x4x5 _ x1x2 _ x1x4 _ x2x6 _ x3x5 _ x4x5 _ x0x2 _ x0 f3(x6, x5, x4, x3, x2, x1, x0) = x1x2x3 _ x1x4 _ x2x5 _ x3x6 _ x0x3 _ x0 f4(x6, x5, x4, x3, x2, x1, x0) = x1x2x3 _ x2x4x5 _ x3x4x6 _ x1x4 _ x2x6 _ x3x4 _ x3x5 _ x3x6 _ x4x5 _ x4x6 _ x0x4 _ x0 f5(x6, x5, x4, x3, x2, x1, x0) = x1x4 _ x2x5 _ x3x6 _ x0x1x2x3 _ x0x5 _ x0[17] These five Boolean functions have very nice properties when their coordinates are permuted. This will be stated in Section 3 together with rationale behind the design of the functions. The five passes H1, H2, H3, H4 and H5 are specified in more detail in the following sections. Pass 1 Assume that the input to H1 is (E0,B), where E0 consists of 8 words E0,7,E0,6,,E0,0 and B of 32 words W31,W30,,W0. H1 processes the block B in a word-by-word way and transforms the input into a 8-word output E1 = Original (H1) Ord 2 (H2) Ord 3 (H3) Ord 4 (H4) Ord 5 (H5) Table 1. Word Processing Orders Permutations X6 X5 X4 X3 X2 X1 X0 ᴓ 3,1 X1 X0 X3 X5 X6 X2 X4 ᴓ 3,2 X4 X2 X1 X0 X5 X3 X6 ᴓ 3,3 X6 X1 X2 X3 X4 X5 X0 ᴓ 4,1 X2 X6 X1 X4 X5 X3 X0 ᴓ 4,2 X3 X5 X2 X0 X1 X6 X4

7 IJECSE,Volume2, Number 3 Raghvendra Vikram Singh and Deepak Chaudhary 978 ᴓ 4,3 X1 X4 X3 X6 X0 X2 X5 ᴓ 4,4 X6 X4 X0 X5 X2 X1 X3 ᴓ 5,1 X3 X4 X1 X0 X5 X2 X6 ᴓ 5,2 X6 X2 X1 X0 X3 X4 X5 ᴓ 5,3 X2 X6 X0 X4 X3 X1 X5 ᴓ 5,4 X1 X5 X3 X2 X0 X4 X6 ᴓ 5,5 X2 X5 X0 X6 X4 X3 X1 Table 2. Permutations on Coordinates E1,7E1,6 E1,0. Denote by! ROT(X, s) the s position rotate right operation on a word X and by f _ g the composition of two functions f and g (g is evaluated first). B.Security of HAVAL Two messages are said to collide with each other with respect to a one-way hashing algorithm if they are compressed to the same digest. For HAVAL, there are two possibilities for a pair of messages to collide: the number of passes the messages are processed can be the same or differ. Ideally, given a one-way hashing algorithm, we would like to prove formally that it is computationally infeasible to find a collision pair for the hashing algorithm. Like many other hashing algorithms such as the MD family, SHS and FFT-hash, however, HAVAL could not be formally proved to be secure. Recently, Berson has proposed an attack to a single pass of MD5 [15]. His method applies to a single pass of HAVAL as well. However, it seems that the attack can not be extended to two or more passes.it is conjectured that the best way to find a collision pair is by using the birthday attack. In such an attack, an attacker prepares two sets of 2n/2 distinct messages, and calculates their digests. Here n denotes the number of bits in a digest, and it can be 128, 160, 192, 224, 256. Also note that the number of passes the two sets of messages are compressed may differ. The attacker can check (by, for instance, sorting) if there is any collision pair of messages, one is from the first set and the other from the second set. The attacker will succeed with a probability about 0.5. However, such an attack requires the order of 2n/2 operations, which is impractical even for n = 128. It is also conjectured that given a digest, it requires the order of 2n operations to obtain a message that is mapped to the digest.[13] IV.CONCLUSION The DNS as an Internet standard to solve the issues of scalability surrounding the hosts.txt file. Since then, the widespread use of the DNS and its ability to resolve host names into IP addresses for both users and applications alike in a timely and fairly reliable manner, makes it a critical component of the Internet. The distributed management of the DNS and support for redundancy of DNS zones across multiple servers promotes its robust characteristics. However, the original DNS protocol specifications did not include security. Without security, the DNS is vulnerable to attacks stemming from cache poisoning techniques, client flooding, dynamic update vulnerabilities, information leakage, and compromise of a DNS server s authoritative files.in order to add security to the DNS to address these threats, the IETF added security extensions to the DNS, collectively known as DNSSEC. DNSSEC provides authentication and integrity to the DNS. With the exception of information leakage, these extensions address the majority of problems that make such attacks possible. Cache poisoning and client flooding attacks are mitigated with the addition of data origin authentication for RRSets as signatures are computed on the RRSets to provide proof of authenticity. Dynamic update vulnerabilities are mitigated with the addition of transaction and request authentication, providing the necessary assurance to DNS servers that the update is authentic. Even the threat from compromise of the DNS server s authoritative files is almost eliminated as the SIG RR are created using a zone s private key that is kept off-line as to assure key s integrity which in turn protects the zone file from tampering. Keeping a copy of the zone s master file off-line when the SIGs are generated takes that assurance one step further. DNSSEC can not provide protection against threats from information leakage. This is

8 Protection of DNS using HAVAL 979 more of an issue of controlling access, which is beyond the scope of coverage for DNSSEC. Adequate protection against information leakage is already provided through such things as split DNS configuration. DNSSEC demonstrates some promising capability to protect the Internet infrastructure from DNS based attacks. DNSSEC has some fairly complicated issues surrounding its development, configuration, and management. Although the discussion of these issues is beyond the scope of this survey, they are documented in RFC 2535 and RFC 2541 and give some interesting insight into the inner design and functions of DNSSEC. In addition to keep the scope of this paper down, many topics such as secure zone transfer have been omitted but are part of the specifications in RFC The first official release of a DNSSEC implementation is available in BIND version REFERENCE [1] Albitz, P. and Liu, C., (1997) DNS and Bind, 2 nd Ed., Sebastopol, CA, O Reilly & Associates, pp.1-9. [2] Herbert Schildt, Edition (2003) The Complete Reference JAVA 2 Tata McGraw Hill Publications [3] IETF DNSSEC WG, (1994) DNS Security (dnssec) Charter, IETF. [4] Michael Foley and Mark McCulley, Edition(2002) JFC Unleashed Prentice-Hall India. [5] Mockapetris, P., (1987) Domain Names - Concepts and Facilities. [6] Public Key Distribution with Secure DNS-James M. Galvin, CommerceNet, Glenwood, MD(2007) [7] Paul Albitz and Cricket Liu, DNS and BIND, 4th Edition O'Reilly, [8] G. Ateniese and A. Del Sorbo, \Design and Implementation Issues in SK-DNSSEC", Manuscript in preparation Available on [9] CURRENT ISSUES IN DNS BY CRAIG S. WRIGHT(2008). [10] B. Cli_ord Neuman and Theodore Ts'o. Kerberos: An Authentication Service for Computer Networks, IEEE Communications, 32(9): September [11] RSA Security site defaced. ZDNet [12] Secure Network Time Protocol (stime), [13] Eastlake, D., \Bigger Domain Name System UDP Replies", Internet Draft, ietf-dnsind-udp-size-02.txt [14] Lottor, M., \Domain Administrators Operations Guide", RFC 1033, November [15] Mockapetris, P., \Domain Names - Concepts and Facilities", RFC 1034, November [16] Mockapetris, P., \Domain Names - Implementation and Speci_cations", RFC 1035, November [17] J. Kohl, C. Neuman, \The Kerberos Network Authentication Service (V5)", RFC 1510, September [18] Eastlake, D. and C. Kaufman, \Domain Name System Security Extensions", RFC 2065, January 1997.