CHAPTER 5 ACO BASED MOBILE AGENT FOR SECURED KEY MANAGEMENT

Transcription

1 112 CHAPTER 5 ACO BASED MOBILE AGENT FOR SECURED KEY MANAGEMENT 5.1 Related Work Security in ad hoc network becomes a critical issue for the past few decades. Attacks will be avoided by authenticating users and by isolating attackers. Hence, key management and digital signatures are proposed for user authentication. There are many research works are proposed in the past, still authentication using key management is an important research issue. Key management segregates authorized user and attacker. The important aspect of the key management is, the key which is used by other authorized user cannot be identified or predicted by the attackers. Hence, hash based mathematical function, complex digital signatures are in use, for ex: keyed MD5, digital signatures (Chung et al., 2009). In MD5, the sender concatenates the pre-configured key with message m, where the pre-configuration is an initial process which is processed by using Kerberos. Let m be the message, k be the preconfigured key to transfer and the process in the keyed MD5 is

2 113 m + MD5 (m + k) (5.1) The digital signature is proposed by the National Institute for Standards and Technology (NIST). The digital signature is a specially designed and digitally signed document which is used for authentication. Now, the digital signature is implemented in many protocols such as X.509, Secured Shell (SSH), and Pretty Good Privacy (PGP) (Tashtoush and Alkasassbeh, 2013). Most of the web based applications and software using digital signature for their authentication. In the scenario called as a man-in-the-middle attack, in which an attacker could intercept and even manipulate communications secured with public key cryptography. The attack is possible because public key cryptography provides no means of establishing trust when used on its own. Public Key Infrastructure (PKI) established trust by binding public keys and identities(ahmed, 2012). Using public key cryptography, user can assure that only the encrypted data can be decrypted with the corresponding private key. If we combine this with the use of a message digest algorithm to compute a signature, the user can be authenticated that the encrypted data has not been tampered with. PKI is important to using public key cryptography effectively, and is essential to understanding and using the SSL protocol. Certificates works same as PKI, in simple terms, a certificate binds a public key with a distinguished name (Prem and Swamynathan, 2012). A distinguished name is simply the name of the person or entity that owns the

3 114 public key to which it's bound. Perhaps a certificate can be best compared to a passport, which binds a picture with a name, thus solidifying a person's identity. A passport is issued by a trusted third party (the government) and contains information about the person to whom it has been issued (the subject) as well as information about the government that issued it (the issuer). Similarly, a certificate is also issued by a trusted third party, contains information about the subject, and contains information about the third party that issued it. Not unlike a passport, which contains a watermark used to verify its authenticity, a certificate also contains safeguards intended to allow the authenticity of the certificate to be verified, and aid in the detection of forgery or tampering (Rahman et al., 2013). Also similar to a passport, a certificate is valid only for a defined period. Once it has expired, a new certificate must be issued, and the old one should no longer be trusted. A certificate is signed with the issuer's private key, and it contains almost all of the information necessary to verify its validity. It contains information about the subject, the issuer, and the period for which it is valid. The key component that is missing is the issuer's certificate. The issuer's certificate is the key component for verifying the validity of a certificate because it contains the issuer's public key, which is necessary for verifying the signature on the subject's certificate. By signing a certificate with the issuer's private key, anyone that has the issuer's public key can verify its authenticity. The signature serves as a safeguard to prevent tampering. By signing the subject's certificate, the issuer asserts that it has verified the authenticity of the public key that the certificate contains and states that it may be trusted. As long as the issuer is trusted, the certificates that it issues can

4 115 also be trusted. It's important to note that the issuer's certificate or public key may be contained in an issued certificate. It's more important to note that this information cannot be trusted to authenticate the certificate. If it was trusted, the element of trust established from a third party is effectively eliminated. Anyone could create another key pair to use in signing a certificate and place that the public key in the certificate. Certificates are also created with a serial number embedded in them. The serial number is unique only to the issuer of the certificate. No two certificates issued by the same issuer should ever be assigned the same serial number. The certificate's serial number is often used to identify a certificate quickly. A Certification Authority (CA) is an organization or company that issues certificates. By its very nature, a CA has a huge responsibility to ensure that the certificates it issues are legitimate. That is, the CA must ensure beyond all reasonable doubt that every certificate it issues contains a public key that was issued by the party that claims to have issued it. It must be able to produce acceptable proof for any certificate that it issues on demand. There are two basic types of CA. A private CA has the responsibility of issuing certificates only for members of its own organization, and is likewise trusted only by members of its own organization. A public CA, such as VeriSign or Thawte, has the responsibility of issuing certificates for any member of the public, and must be trusted by the public. The burden of proof varies depending on the type of the CA that has issued a certificate and the type of certificate that is issued.

5 116 A CA must be trusted, and so for that trust to be extended, its certificate containing its public key must be widely distributed. For public CAs, their certificates are generally published so that anyone can obtain them. More commonly, the software that makes use of them, such as a web browser, is shipped containing them. Most often, the software allows certificates from other CAs to be added to its list of trusted certificates, thus facilitating the use of private CAs with off-the shelf software. A private CA has been often ideal for use in a corporate setting. For example, a company could set up its own CA for , using S/MIME as the standard for encrypting and authenticating messages. The company's CA would issue certificates to each employee, and each employee would configure their S/MIME-capable clients recognize the company's CA as being trusted. For a private CA, verifying the identity of a subject is often a reasonably simple and straightforward matter. When used in a corporate environment, for example, employees are known, and their identities can be easily identified using information obtained from the company's human resources department. In such a scenario, the human resources department is said to be acting as a Registration Authority (RA). A public CA commonly issues certificates for public web sites requiring encryption and/or authentication, often for e-commerce in which customer information must be transmitted securely to place an order. For such operations, it's essential that the customers transmit their information to the site that is supposed to be receiving it without worrying about someone else obtaining the information.

6 117 For a public CA, verifying the identity of a subject is considerably more difficult than it is for a private CA. The information required from the subject to prove its identity to the CA varies depending on whether the subject is an individual or a business. For an individual, the proof required could be as simple as a photocopy of a government-issued ID, such a driver's license or passport. For a business or other organization, similar government documentation proving user right to use the name will also likely be required. Technically the job of an RA instead of a CA, but the CA generally deals with the RA transparently. It's important to note that most public CAs provide their services to make money, and not to simply benefit the public. They still have a responsibility to verify a subject's identity, but not actually guarantee anything the liability is too great to provide an absolute guarantee. Certainly, it is in the CA's best interests to verify a subject's identity to the best of its ability, however. If a CA gains the reputation of issuing certificates to anyone who asks (and pays them enough money), they're not going to remain in business for very long because nobody will trust them. A certificate that is issued by a CA can be used to issue and sign another certificate, if the issued certificate is created with the appropriate permissions to do so. In this way, certificates can be chained. At the root of the chain is the root CA's certificate. Because it is at the root of the chain and there is no other authority to sign its certificate, the root CA signs its own certificate. Such a certificate is known as a self-signed certificate. There is no way to digitally verify the authenticity of a self-signed certificate because the issuer and the subject are the same, which is why it has become a common practice to provide them with the software that uses them.

7 118 When they're included with an application, they are generally obtained by the software author through some physical means. For example, Thawte provides its root certificates on its website, free and clear, but strongly advises anyone making use of them to confirm the certificate fingerprints with Thawte via telephone before using or distributing them. To verify the authenticity and validity of a given certificate, each certificate in the chain must also be verified, from the certificate in question's issuer all the way up to the root certificate. If any certificate in the chain is invalid, each certificate below it in the chain must also be considered invalid. Invalid certificates typically have either expired or been revoked (perhaps due to certificate theft). A certificate is also considered invalid if it has been tampered with and the signatures on the certificate don't match with the ones that should have been used to sign it. The decision whether to employ a certificate hierarchy more complex than a single root CA depends on many factors. The most widely accepted format for certificates is the X.509 format, first introduced in There are three versions of the format, known as X.509v1, X.509v2, and X.509v3. The most recent revision of the standard was introduced in 1996, and most, if not all, modern software now supports it. A large number of changes were made between X.509v1 and X.509v3, but perhaps one of the most significant features introduced in the X.509v3 standard is its support of extensions.

8 119 Version 3 extensions allow a certificate to contain additional fields beyond those defined by previous versions of the X.509 standard. The additional fields may be standardized in X.509v3, such as the basic Constraints or key Usage fields, or they may be completely nonstandard, perhaps recognized only by a single application. Each extension has a name for its field, a designation indicating whether the extension is critical, and a value to be associated with the extension field (Eswaramurthi and Mohanram, 2013). When an extension is designated as critical, software that does not recognize the extension must reject the certificate as being invalid. If the extension is noncritical, it may be ignored. The X.509v3 standard defines 14 extensions in an effort to consolidate the most common extensions implemented by third parties. One example is the permissible uses for a certificate for instance, whether a certificate is allowed to sign another certificate, or is used in an SSL Server. The above discussed methodologies are providing better result in wired networks. Whereas, the ad hoc networks having resource constraint such as limited bandwidth, limited power and limited memory, hence improved key management is a major requirement. Therefore, an ant mobile agent based key management is proposed in this research work. 5.2 Proposed Ant Based Mobile Agent A mobile agent is an autonomous, kind of software which migrates in the network from one host to another host. The mobile agent-based

9 120 programming is attractive to design, implement and maintain distributed systems. Mobile agents used for transmitting messages, distributing network resources and interacting with other mobile agents or communicating with the distributed resource systems. The task assigned by the source node of the mobile agent will move to the network such as internet to perform the assigned task. The mobile agent will return to the source node after the assigned task is completed. The characteristics of the mobile agent are listed below (Chung et al., 2009): It should be able to achieve one or more goals automatically It should be able to clone and propagate itself It should be able to collaborate and communicate with other software and agents It has to have a scope of competence It should have some evolution states to record the computation status From the above characteristics, it is ambiguous that the ants in the ant colony system can be deployed as a mobile agent. The ant is a tiny agent, hence the space complexity of the proposed system is comparably low and which reduces the network traffic. There are many research issues around the mobile agents. Few important research issues and its literature are discussed further. Mobile agent in network security has two manifolds, security through mobile agent and securing mobile agent. In the first, the mobile agent, is used for providing security in computer networks. In the second, mobile

10 121 agent will meet attacks which are becoming a critical issue in the networking domain. Securing a mobile agent through the Elementary Object System, which offers mutual authentication between mobile hosts and its hosting platform. Generating sub-agent for privacy protection, free-roaming mobile agent addresses the code, data and itinerary security issues are few recent interesting research for security. Mobile agent causes an increase of data traffic, hence, many researchers proposed methodology to reduce a number of agent migration. Reducing the number of migrations will lead to performance degradation, therefore trade off condition to be reached. Higashino et al (2012) proposed a cached method for reducing the migration. In the cached method, the mobile agent runtime environment caches the agent codes and the agent status. The cached codes and status are reusable when a mobile agent comes back again. Thus, the method enables to reduce data traffics caused by mobile agent migration at the agent runtime environment level. The functionalities of mobile agent are shown in figure 5.1. The static security policy, security certificates and its access controls are defined as static objects and dynamic objects are defined as mutable objects.in the proposed model, the ants are defined as mobile agent which used to propagate routing packets for mobile routing and also utilized as mobile agent for predefined task such as security of wireless network. In this study, the ant based mobile agent, is used for providing authentication between mobile nodes and control centers.

11 122 Figure 5.1. Typical mobile agent Figure 5.2 The functional diagram of proposed ant mobile agent

12 123 The security model of the proposed paper implemented the Rivest- Shameer-Adelman (RSA) based cryptosystem with Chinese Reminder Theorem (CRT). 5.3 Proposed ACO Mobile Agent (ACO-MA) Based Key Management The methodology and the security requirements of proposed Request based IDS are discussed in this section. For this extended IDS, ACO is used as Identification Agent (IA) and Target Agent (TA). In the initialization of network phase, ACO flooded in the network as IA to identify all authenticated members in order to process handshake. In the later stage, the ACO is used as TA for authenticating member and preventing non-member. Hence, there are four components in the proposed system: Member: A member is an entity who belongs to the group. U G means that U belongs to the group G. Non-member: A non-member is an entity who does not belong to the group. U G means that U does not belong to the group G. ACO-IA is responsible for adding users into his group. ACO-TA is responsible for revealing users as well as checking whether handshake players belong to his own group. hereunder: The implementation of this attractive scenario is explained

13 124 i. Setup: The common parameter generation algorithm. Given a security parameter k, Setup outputs the public parameters (param) that are common to all groups. ii. KeyGen: The group public/secret key generation algorithm. KeyGen is run by ACO-IA and ACO-TA. Given param, KeyGen outputs agroup public key gpk, a secret key of ACO-IAisk and a secret key of ACO-TAtsk. iii. Add: The member addition algorithm. Add is executed by a nonmember A and ACO-IA. Given param, gpk and isk, Add outputs a membership certificate (certa), a secret key (ska), and ID of A (IDA). iv. Handshake: The authentication protocol executed between two players A and B, based on the public input param. The group public keys (gpka and gpkb), certificates (certa, certb) and secret keys (ska, skb) of A and B are input to Handshake. The output of the algorithm is either rej or acc. A Handshake B means the situation in which A and B executes Handshake. v. Group Trace: A handshake player s group trace algorithm. Given gpk, tsk and a transcript TA, B, Group Trace outputs yes if A, B G; otherwise, Group Trace outputs no. vi. Request Reveal: The handshake player tracing algorithm. Given gpk, tsk, certa, ska, a transcript TA, B and internal information that are used in Handshake by a player A, Request Reveal outputs the member B. The proposed mobile agent based secured model is shown in figure 5.3. In each node, two types of systems are defined, such that Alert system and analyzer. The analyzer consists of mobile agent which is defined and used as

14 125 program model to collect information regarding security information. The analyzer receives the security key and verifies the authentication. The alert system broadcast the alert messages to the authenticated neighbours when it identifies the intruder. This alert message also used for verification if the identified attacker may be authenticated user of other authenticated nodes of the concern node. Alert Sytem Node Analyzer Node Alert System Analyzer Figure 5.3 System design of proposed mobile agent model When an authenticated node of a group receives the message from unknown node, it initiates the mobile agent to collect security information of the unknown node. The MD5 hash function H is used to create message digest H(M) in the authenticated node. The authenticated node generates the following digital signature, if the unknown node is an authenticated node of the group. d sign =(H(M)) d mod n (5.2) The authenticated node is encrypting message by using its digital signature. Encrypting the message digest H(M) with its private key d where, n

15 126 = p q, p and q are random prime numbers with p q. The source node forwards d sign with data M, (d sign, M) to its neighbouring node through the path it takes to reach sink. A neighbouring node on reception of (d sign, M) and the path in the data packet, verifies the digital signature by comparing decrypted value of d e sign mod n with message digest H(M).The d e sign mod n is key (e, n) using the formula, decrypted using sender s public d e signmod n = ((H(M)) d mod n) e mod n (5.3) = (H(M)) ea mod n (5.4) shown that By applying Little Fermat s Theoremto above Equation, it can be d e sign mod n = H(M) (5.5) If the generated H(M) by the receiver and the decrypted H(M) of digital signature d sign is equal, then the receiver accepts the data; otherwise rejects the data and informs the sender that the data is altered through by generating route error packet. This process is repeated in every hop of the node disjoint path between source and destination. The proposed public key crypto system provides authentication, integrity and non-repudiation in the ad hoc network.

16 Results and Discussion The proposed work is simulated in NS2. The simulation parameters of the proposed work are shown in the following Table. The proposed work is compared with existing traditional Target Authority (TA) Model and Mobile Agent (MA) model. The Reliability and scalability are major research issues in the design of networking protocol. Hence, the proposed work are analysed the reliability and scalability of proposed work and compared with TA and MA. The reliability is computed based on the simulation data and result. The number of node is varied and number of attacker node also varied for performance comparison. Table 5.1 Simulation Parameters Parameters Values Simulation area m2 Propagation Two ray ground MAC type Antenna Omni Antenna Queue Drop Tail/Priority Queue Limit 50 No of Nodes 10 to 500 Packet Type CBR Packet Size 220 Bits

17 128 Figure 5.4 Reliability when 10% of Attacker Node Figure 5.5 Reliability when 20% of Attacker Node

18 129 The reliability is computed based on effective packet delivery, which analysed on different test cases, test case 1: when 10% of attacker node, test case 2: 20% of attacker node, and test case 3: 30% of attacker node are shown in following figures. Figure 5.6 Reliability when 30% of Attacker Node 5.5 Conclusion The scalability is observed from the above data, in which the system has 70% and above packet delivery ratio only accepted as scalable system. Hence, when 10% attacker nodes are inserted the TA supports up to 500 Nodes, whereas MA and proposed ACO-MA support 1000Nodes. When attacker nodes are increases, the TA supports up to 200 Nodes only, whereas MA supports 500 Nodes and proposed ACO-MA support even for 1000Nodes.

19 130 Similarly, the TA and MA supports only 100 Nodes when 30% of attacker nodes are inserted. The proposed system always supports above 80% packet delivery ratio. Hence, the proposed system proves better reliability and scalability than the existing systems.