An Effective Anti-phishing Mechanism Using Graphic-CAPTCHA K.Neetha1 ,A.Poonkuzhali1 and S.

Shanthi2 1 Final Year Student/IT, SNS College of Engineering, Coimbatore. 2 Lecturer/IT , SNS College of Engineering, Coimbatore. Email: neethakinethetic@gmail.com, a.poonkuzhali@gmail.com, shanregal@gmailcom .
ABSTRACT
CAPTCHAs are programs that generate grade tests which human can solve but computers cannot. The main reason for the usage of CAPTCHAs is to ensure that only human beings are accessing a particular resource but not bots or automatas. Text based CAPTCHAs are very easily broken whereas graphic object based CAPTCHAs are not that easy to break. Even graphic based CAPTCHAs are dodged easily by attackers. Though graphic object based CAPTCHA remain a most efficient mechanism of ensuring human involvement, they are insufficient in the presence of MitM attacks or ensuring that the intended human user is solving it. In our paper we introduce the concept of an Anti-Phishing mechanism using object based graphic CAPTCHAs.

These CAPTCHAs contain a user-specic image object and a pattern (for e.g. a sub-string) of a secure channel invariant, wherein the image object and pattern are linked. By virtue of a built-in one/two-way implicit challenge mechanism and this veriable association between the image object and the specic sub-pattern of the Public Key, they help in detecting/resisting automated or human-assisted Phishing and MitM attacks.

Key Terms:
Phishing, CAPTCHA, Public Key, Authentication

I. INTRODUCTION
CAPTCHAs introduced a new genre of problems which are easy to generate but hard to solve for computers. Their typical usage has been to ensure that humans are accessing a website instead of an automaton or stopping bots from reading/downloading content on the Internet. Not surprisingly, attackers have also devised solutions to circumvent them. The simplest one, being the trick to pull in a different human-user to solve the CAPTCHA rather than the one it was intended for. Or launching a Man-in-the-Middle (MitM) attack to get the human user to solve the CAPTCHA but still pick up the content. Though graphic object-based CAPTCHAs

remain a mostly effective mechanism of ensuring human involvement, they are insufcient in the presence of MitM attacks or ensuring that the intended human user is solving it. The problem of MitM attacks can be solved theoretically by establishing a secure Transport Layer Security (TLS)-based connection, which builds on the strength of Public-Key cryptography. However, when it comes to practical security, attackers have targeted that one single link, which can never be completely secured via any computing-based technology namely, the Human-Computer Interface. Various Phishing attacks have repeatedly targeted this weakest link by different schemes. When it comes to Username and Password-based authentication mechanisms, inspite of the various problems associated with them, they have proved to be the most popular means of User authentication over the Internet. They offer the most simplicity in terms of plaintext-equivalence usage, which is easiest for humans to remember and use. Additionally, they also provide for easy provisioning and life-time manageability. However, with very low intrinsic entropy, they have also ended up easy targets for dictionary-based attacks. With this background, the goal of this paper is the design of an easy-to-use Anti-Phishing mechanism, augmenting the popular Username/Password-based authentication, yet without any need for alertness or intelligence on the part of Users. In this paper, we propose a novel mechanism wherein the power of CAPTCHAs (viz. not being easily solvable by automata) is coupled with embedding unique secure-channel characteristics, for e.g. a TLS-session invariant (which cannot be duplicated nor falsied) information from the underlying channel security mechanism. We further encode sufcient information within the CAPTCHA, to enable the Users system to validate that the CAPTCHA was generated by the authentic website and delivered over a secure channel with the authentic web-site only.

II. PUBLIC KEY-EMBEDDED GRAPHIC CAPTCHAS

This section proposes various mechanisms, wherein these weak-points are specically attacked to gradually converge on to the overall solution. It must be noted that at times, the solution refers to a browser-based User

Support Function which is expected to execute some described functionality, on behalf of the User. It is assumed,
that this function is trustworthy, as it is running on the Users system and under their control.

A. Generation
CAPTCHA encoded with partial Public Key: As hinted in the previous section, if the authentic website were to generate a CAPTCHA (ensuring that the Phisher cannot solve it) with encoded secure channel MitMresistant invariants (enabling the User to check them with the actual session characteristics of its secure channel), then the authentic web-site can present a mechanism to the User to detect and effectively prevent) a Phishing attack.

The Public key associated with a website is tightly coupled with the web-sites identity, as exposed within the Server Certicate message within a TLS handshake protocol. Though the actual identity itself may be dubious (in case of Phishing website), it is still linked with the certicate as well as the corresponding Public/Private keys. The Public Key cannot be falsied once it has been exposed and used at the time of secure channel establishment. At the same time, it cannot be simply duplicated from the authentic website by the Phisher, as it would require the corresponding Private key for successful decryption. Thus, it qualies as a MitM resistant invariant of the secure channel. We propose that the authentic website create a CAPTCHA by encoding its own Public key information. On solving such a CAPTCHA, the User could verify the usage of the same Public Key for session establishment and be assured that it was indeed generated by the authentic ebsite. However, this mechanism is not sufficient in itself, due to various possible attacks The Phisher could generate a new CAPTCHA with its own Public Key information. On solving this CAPTCHA, the user would nd the Public Key of the TLS session matching with the one in the CAPTCHA (both belong to the Phisher). This attack is dealt with in a later section. However, the Phisher still has the challenge of solving the authentic websites CAPTCHA and thus would require human assistance. A simple well-known attack is to pull-in a different user to solve this CAPTCHA. Again, this attack is dealt with later, by encoding an implicit challenge which can only be answered by authentic User client software, after a human has solved the CAPTCHA. Since the Phisher knows the Public Key of the authentic website, it can effectively solve the CAPTCHA. Hence, the authentic website must not embed its complete Public key, but rather a specic sub-part for e.g. bits 031, 32-63 etc. The trick lies in selecting which sub-part to embed within the CAPTCHA in a manner, so that it is not decipherable to the Phisher.

CAPTCHA with specic object-based images: Though there have been recent advances allowing computers to solve simpler text-based CAPTCHAs, graphic object-based CAPTCHAs are still considered to be mostly unsolvable. We suggest the following to take advantage of this limitation The CAPTCHA would carry additional semantics, via the encoding of a certain type of object images. In
further discussion, this is referred to as an Image List for the CAPTCHA viz. a List of the various type of Objects which can be included within the CAPTCHA. For e.g. Image List = [car, house, ...]. Additionally, the type of the object in the CAPTCHA would decide which specic sub-part of the Public Key is embedded with the CAPTCHA. This is referred to as the Bit Position Map, which provides a map from the objects in the Image List into various Bit Position ranges of the Public Key. For e.g. Bit Position Map = {car 031 bits, house 32-63 bits} etc.

B. Usage (with Defense against attacks)

Any successful Identication mechanism is based on proof of Identity. One of the ways is to prove knowledge of some secret associated with that Identity. To enable the association of the Public Key-embedded Graphic CAPTCHAs with Identity-based relationship between the Authentic website and the User, we need a similar mechanism. Hence, we propose the Image List and the Bit Position Map to be a shared secret between the User and the website. Now, when the User Browser receives a Public Key-embedded Graphic CAPTCHA, it would ask the User to solve it. The User can easily recognize the object image as well as the embedded string of the Public-key subpart. Then, the Users browser (or an appropriate plug-in) can validate whether the Public-key (which was presented by the website at the time of TLS session establishment) has the specic sub-part at the location (obtained by indexing the Object Image type contained in the CAPTCHA into the Bit Position Map) same as the Public-Key sub-string encoded within the CAPTCHA. If this check fails, then the browser is immediately convinced of a phishing attack, and can take appropriate action. If the check succeeds, then it can be sufficiently convinced, that at least there is no MitM attack between itself and the website, which generated the CAPTCHA. At this point, it must be claried that though novel in their own right, these steps of generating and issuing graphic CAPTCHAs based on partial Public-key information indexed by the type of the Object in the graphic image are not sufficient on its own, as they still do not yet satisfy the primary requirement of forcing a Phisher to contact the Authentic website. Forcing a connection towards the Authentic website: It is easy to incorporate this requirement within our Public Key-embedded CAPTCHAs, by dening the authentic website to maintain the Image List and the Bit Position Map, on a per-user basis. Thus, it is not possible for the Phishing website to launch an attack on the User, by generating a CAPTCHA including a sub-part of its own Public key. For launching such an attack

successfully, it would need to guess the type of object images, which are expected and thus need to be encoded within the CAPTCHA, as well as their corresponding mapping onto specic sub-parts of the Public key. Indeed, it is forced to contact the Authentic website to get access to that information.
Identifying the authentic Website at the Users Browser: For knowing which graphic object types to expect within the CAPTCHA, as well as the corresponding mapping to specic Public-Key sub-parts, the Users Browser would need to store that information, indexed with the name of the Authentic Website. We propose that, this name be picked up from the identity which was exposed within the Server certicate, at the time of TLS session establishment. It is but natural that the Phishing website would present the same website name (as the Authentic Website) within its own dubious certicate to carry out a successful phishing attack. It may be argued, that a Phisher could include its own identity (dubious website name) within the certicate, but shows a webpage similar to the authentic website, thus still trying to fool the User into entering

correct credentials. However, to carry out such an attack successfully, the Phisher would need to i) solve the CAPTCHA issued by the Authentic web-site, and more importantly ii) have preinstalled the Image List and Bit Position Map for its own fake web-site (registered with its name) within the Users system. Otherwise, the Users Browser would not successfully execute the proposed protocol, of solving the CAPTCHA and comparing the Public-key subparts. We believe, that this attack is more difcult for the Phisher to execute, yet can be defended by using the following mechanism. Validating the CAPTCHA is solved by the intended user: For successful mutual identication, it is also necessary to convince the Authentic website that the CAPTCHA is indeed reaching and solved by the intended User. Any CAPTCHA provides an implicit challenge mechanism, wherein the User may be asked to respond with the information which is encoded within the CAPTCHA. However, this does not guarantee that the CAPTCHA is actually solved by its intended recipient User. For e.g. a Phishing automata could take assistance of a human user to solve a CAPTCHA. This can be solved, by dening additional semantics in the form of an implicit challenge within the CAPTCHA. In the Public Key-embedded Graphic CAPTCHA scheme described herein, the implicit challenge could be dened to mean return the type of the image object, which corresponds to the xth (can be user-specic) sub-part after the sub-part (of the Public Key), which was encoded within the CAPTCHA. This would require the human-assisted Phisher to guess the Image List for the User as well as the Bit Position Map. However, an authentic Users system can easily lookup the Image List and Bit Position Map to respond to the challenge. This, forces the Phisher to deliver the Authentic Web-sites CAPTCHA towards the Users system. One possible attack theoretically could be for a phisher to take help of a human user, to solve the authentic websites CAPTCHA and identify the embedded Object and the sub-string. Based on it, it could search the location of that sub-string within the Authentic websites Public Key. Then, it could generate another CAPTCHA with the same/similar Object Image, but containing the sub-string at that location of the Phishers Public Key. However, within a typical 1024-bit Public Key, any bit-pattern would surely repeat at various positions. Effectively, the Phisher has not one, but a set of locations to choose from, while selecting the bit-pattern from its own Public Key. The Phishers attack is now reduced to guessing from those locations, as the chances of have a recurring bit-pattern, at all the corresponding locations between both the Public Keys, are probabilistically small.

III. PROPOSED SOLUTION

A.

Functional Architecture and Protocol Scenarios

Fig 2. Protocol Scenarios In Figure 1, we bring together the various ideas presented earlier to propose an overall framework for generation and usage of Public Key-embedded Graphic CAPTCHAs. Due to space limitations, we leave the description of the framework, to the gure itself. Protocol Scenario 1 - One-way Authentication: Fig 2 describes how the proposed mechanisms can be used for augmenting the existing Username/Password authentication by making it resistant to MitM-based Phishing attacks. Essentially, this is a one-way authentication function, wherein the website is proving its authenticity to the User, but still requiring the Users password for User Authentication. Protocol Scenario 2 - Two-way Authentication: Fig 2 also describes the extended protocol ow, which has different steps from point A onwards, wherein the USF is using its knowledge about the Image List and Bit Position Map to indicate that it is representative of the correct User. The USF does so by identifying and returning the Image Object tag,which corresponds to the the xthsub-part before/after the sub-part, which was embedded within the CAPTCHA.

IV. CONCLUSION
In this paper, we have presented a mutual authentication mechanism based on simple identication of an image and text within a CAPTCHA. The solution is based on the proposed concept of Public-Key embedded Graphic CAPTCHAs, which encode a challenge based on a unique mapping between Image object types and bit positions of the Public Key of the website. We have also described how the proposed solution can augment the legacy Password-based authentication mechanisms and make them resistant to Man-in-the-Middle Phishing attacks. We have also given a proposed functional architecture for the solution as well as a set of guidelines for effective implementation. We have implemented a browser-plugin based on this ideas and plan to conduct User studies to test its effectiveness and user acceptance.

REFERENCES
[1] Y. Amit and A. Kong. Graphical templates for model registration. IEEE Trans. PAMI, 1996.

[2] G. Mori and J. Malik. Recognizing objects in adversarial clutter breaking a visual captcha, 2003. [3] L. von Ahn, M. Blum, N. Hopper, and J. Langford. Captcha: Using hard ai problems for security. In Proceedings of Eurocrypt, pages 294311, 2003. [4] Zishuang (Eileen) Ye, Sean Smith, and Denise Anthony. Trusted paths for browsers. ACM Trans. Inf. Syst. Secur., 8(2):153186, 2005. [5] D. Gusfield. Algorithms on Strings, Trees, and Sequences: Computer Science and Computational Biology. Press Syndicate of the University of Cambridge, 1997.