Towards Multicolored Computing -

Compartmented Security to Prevent Phishing Attacks

Sebastian Gajek, Ahmad-Reza Sadeghi, Christian Stuble, and Marcel Winandy

Horst Gortz Institute for IT Security

Ruhr-University Bochum

Universitatsstr. 150, D-44780 Bochum, Germany

sebastian.gajek@nds.rub.de, sadeghi@crypto.rub.de, stueble@acm.org, winandy@ieee.org

Abstract

Identity theft through phishing attacks has fosteredto a major concern of Internet users. Classicalphishing attacks aim at luring the user to a fakedweb site to disclose personal information. Varioussolutions have been proposed against this kind of at-tack. However, these solutions can hardly counterthe new generation of sophisticated malware phish-ing attacks designed to target certain services.

This paper aims at making the first steps towardsthe design and implementation of an open sourceand interoperable security architecture that pre-vents both classical and malware phishing attacks.Our approach is based on the ideas of (i) the multi-colored computing (e.g., red for the risky and greenfor the trusted domain), and (ii) a trusted walletfor storing credentials and authenticating sensitiveservices. Our solution requires no special care fromusers for identifying the right web sites while thedisclosure of credentials is strictly controlled.

We present the main idea of how to integratecountermeasures against Phishing and malware intoone sound security architecture. Our approach es-tablishes compartmented security for mounting iso-lated applications, provides a secure graphical userinterface to configure sensitive applications, andperforms secure booting to preserve the system in-tegrity. We also give hints on how to implement thisarchitecture efficiently by utilizing trusted comput-ing functionality and virtualization.

1 Introduction

The Internet and its underlying infrastructuremight constitute the most complex IT system everbuilt. On the one hand, this huge platform offersus many opportunities to access information, gainknowledge and set up a variety of business mod-els with sophisticated functional and security re-

quirements. On the other hand, it also bears manyrisks that can be exploited by adversaries who mis-use this powerful medium driven by various moti-vations. In this context, the issue of identity thefthas become a subject of great concern in the recentyears: Since password-based user authentication es-tablished on the Internet to grant users access tosecurity critical services, identity theft and fraudattracted attackers [37]. Hence, phishing—a collo-quial abbreviation of password fishing—has becomea prominent attack. Whereas classical phishing at-tacks primarily used rogue emails to lure unwaryusers to faked web sites where they revealed per-sonal information (e.g., passwords, credit card num-bers, transaction numbers), current attacks havebecome advanced in their number and technical so-phistication [2, 16, 20]. This type of phishing doesnot solely address the weaknesses of careless Inter-net users, but also exploits vulnerabilities of theunderlying computing platforms and takes advan-tage of legacy flaws of Internet technologies: Hos-

tile profiling addresses specific email recipients tomore precisely mount classical phishing attacks [10],pharming compromises DNS servers to resolve do-main name requests to phishing sites [2], and mal-

ware phishing infiltrates customers’ computers tolog their password stroking using special maliciousprograms [24].

The most dominant reason for the proliferationof phishing attacks is that strong assumptions andrequirements are made on the ability of ordinary In-ternet users when accessing sensitive services (see,e.g., [18]). Studies point out that ordinary Inter-net users often do not distinguish legitimate fromfaked web sites and do not understand security in-dicators [31]. Thus, they are vulnerable to classi-cal phishing attacks: To reliably authenticate a website, the user has to verify the domain name, ‘https’in the URL, and the server certificate. However, or-dinary Internet users are unfamiliar with the mean-ing of SSL. This is in particular true for common

1

phishing attacks, as most phishing sites may havebeen exposed, if users had properly looked at thepresence of SSL.1

More dramatically, the rise of malware phishingattacks is a strong evidence for the lack of appropri-ate and fundamental protection of common comput-ing platforms in practice. The problem with mal-ware phishing attacks is that they are specificallydesigned to target certain service providers (e.g.,domestic banks) providing tailored functionality toobtain users’ credentials [2, 15, 24]. For this, thesephishing attacks fake , e.g., security indicators, im-itate the browser’s (or any security-critical applica-tion’s) chrome or modify the system configuration.Thus, malware phishing attacks likely circumventpresent phishing countermeasures and most anti-virus products that generally support updates ofwide-spread threats.

Contribution In this paper, we make the firststeps toward the design and implementation of asecurity architecture with the property to counterboth classical and malware phishing attacks. Wepropose a modular platform that is interoperableto legacy operating systems and uses a trusted wal-let to (i) store user’s credentials and (ii) authenti-cate the sensitive services as a proxy on behalf ofthe user. Hence, it does not require specific skillsfrom users, e.g., to distinguish between real andfaked web sites by identifying security indicators.To establish a secure execution environment for thewallet, our implementation uses Trusted Comput-ing functionality2, and virtualization to efficientlyreuse existing software, keeping the developmentcosts low. The novelty of the work is to present aconcrete solution idea that combines both aspects ofsecure operating systems using trusted computingfunctionalities and secure wallet-based user authen-tication applied to the problem of phishing attacks.While this paper only describes the main conceptsof our approach, a future paper will describe thearchitecture and its implementation in more detail.Currently, we have implemented a prototype basedon the L4 microkernel and Linux.

2 Basic Approach

The main motivation behind our architecture is tofulfill the following security objective:

Objective (Confidentiality of Credentials)The system must protect the user’s credentials

against any unauthorized access.

1We analyzed several phishing sites and observed thatnone of them was triggered over SSL (cf. [14]).

2as specified by the Trusted Computing Group

An adversary must not gain access to the user’scredentials. These credentials must be protectedagainst phishing attacks. This especially meansthat credentials must only be given to authorizedsites. To prevent phishing attacks, our approachrelies on the following ideas: We let a trusted com-ponent, called trusted wallet, (i) authenticate legit-imate service sites, and (ii) control the secret dataof the user’s identity including performing the userauthentication procedure on behalf of the user (seeFig. 1). The trusted wallet acts as a web proxyfrom the browser’s point of view. This allows thesystem to be interoperable to existing web browsers.The only action users need to perform is to initial-ize the wallet by storing sensitive data once.3 Sincethe wallet performs the authentication on behalf ofthe user and passes sensitive user data solely to ap-proved service sites, an unintentional disclosure ofthe user’s identity is prevented. This approach pro-tects only against classical phishing.

Figure 1: Illustration of the general idea.

To protect the user also against malware phish-ing attacks, we require a trusted execution environ-ment. We accomplish this requirement by explor-ing the idea of trusted and untrusted compartments(multicolored computing) relying on Trusted Com-puting functionality and virtualization technology.The latter allows for an efficient implementationand usage of legacy software. The underlying se-curity kernel provides a variety of security proper-ties, such as strong isolation of compartments facil-itating controlled communication channels betweencertain compartments and remote systems, and asecure user interface to enable the user to clearlydistinguish between trusted and untrusted compart-ments.

Trusted Computing Support Trusted Com-puting (TC) provides security functionalities whichwe use for secure booting and sealed storage. For

3To ensure that the user initially is not tricked by faked(password) dialogs, we utilize a trusted Graphical User In-terface (GUI).

2

this, we deploy TC-enabled hardware that measuresthe integrity of the BIOS boot code and enablesthe operating system’s boot loader to establish asecure booting sequence. TC allows to store an im-age of the current system configuration in a specialhardware component, the Trusted Platform Mod-ule (TPM).4 The TPM can encrypt data using akey that never leaves the TPM. The decryption canbe bound to the system configuration stored in theTPM at encryption time (sealing). Hence, the datacan only be decrypted if the computing platformhas the desired state defined as being trustworthy.We use this functionality to securely store the user’scredentials and to ensure that the wallet accessesthe storage only if the integrity of its inherent com-partment is preserved.

3 Model

3.1 Terms and Notations

Principals are parties involved in the phishingscenario. These are the user U who is interfacedto a computer system S and the service provider’ssystem P . We denote the phishing adversary as A

and say that A uses a set of collection servers, suchas a phishing site, to store and retrieve identities.

Channels are virtual abstractions of communi-cation paths. We distinguish between secure andinsecure channels and denote a secure channel asa communication of two principals, which is au-thentic, confidential, and of integrity. For example,sendU→S is the unilateral channel that U uses tosend a message to S.

Identities are security sensitive information andtarget of phishing attacks. We denote an identityidentitysid

as the tuple (sid, cid, attrid) where sid

indicates a set of unique service provider identifiers(e.g., domain name, server certificate), cid a set ofcredentials to get access to P , and attrid a set ofattributes and claims specific to user and service(e.g., age, address, credit card number). Creden-tials cid establish the claim that U is in possession ofidentitysid

and are denoted as the tuple (uid, pwdid),whereas uid and pwdid are username and password.

3.2 Phishing Attacks

The goal of phishing attacks is to obtain identitysid.

These attacks generally consist of two elementarystages [1]: In the first stage, preliminary attacksare launched to mount the actual illusion. In thesecond stage, illusion attacks are launched to mimic,

4Today, several computer manufacturers already shiptheir computer platforms equipped with a TPM chip.

e.g., legitimate text, images and windows to deceivethe user. In this stage all the stolen identities aregathered in a collection server. Phishers thereforeutilize various strategies, which we briefly introducein the following:

Classical phishing attacks have in commonthat the divulgement of identitysid

occurs on a re-mote phishing site. The phishing site imitates alegitimate service provider and occasionally mas-querades security and connection identifiers of thebrowsing application (e.g., address bar). As men-tioned in the introduction, classical phishing at-tacks presuppose that the user does not authenti-cate the malicious remote machine. To lure users tospoofed sites, phishing mails containing obfuscatedlinks, cross site scripting (XSS) attacks, or DNS-based attacks are used to name a few. For moredetails, see [1].

Malware phishing attacks collect identitysid

on client side. Some variants of malware phishingattacks alter local host’s files to resolve a false do-main name and redirect users to faked sites. Ad-vanced attacks capture the user’s input when a tar-geted service is requested, or mimic original loginsites. However, malware phishing attacks prereq-uisite that S has been corrupted; more precisely,that weaknesses of the software layer have been ex-ploited. To infiltrate S, phishers anticipate the la-tency time of unfixed exploits [41] or attach mali-cious programs to phishing mails (see [2]).

3.3 Security Assumptions

Based on the diversity of current phishing attacks,we make the following assumptions on principles:

Assumption 1 (Ordinary User) Let U be an

ordinary Internet user, i.e., potentially threatened

by phishing attacks, then we assume that U is un-

able to properly authenticate P according to sid.

We already mentioned in the introduction that U

has to verify sid to reliably authenticate a web siteof P , i.e., the domain name, HTTPS in the URL,and the SSL server certificate. However, recentstudies [18, 31] point out that ordinary Internetusers are bad in distinguishing legitimate from fakedweb sites and do not understand indicators, whichsignal trustworthiness. This is in particular true forphishing attacks, as most phishing sites may havebeen exposed, if users had properly looked at thepresence5 of SSL. Therefore, chanU↔S is assumed

5Note that phishers generally do not endeavor to deployand/or imitate SSL. We reviewed more than 10.000 phishingsites [14] and remark that no site was protected by SSL.

3

to be untrusted if U has to verify the authenticityof P .

Assumption 2 (Honest Provider) Let P be a

standard service provider, then we assume that P

and its services are not corrupted.

The service provider P fulfills all requirements toprotect his services; otherwise intruders were ableto steal identities from the service provider’s data-base. Moreover, services are resilient against webspoofing attacks [11], which provide adversaries tocompletely display a faked web, i.e., we do not con-sider scenarios, where phishers may impersonate aservice while U registers to P .

Assumption 3 (Sound Browser) Let B be a

standard browsing application running on S, then

we assume that the functionalities of B are imple-

mented correctly.

Browser developers are responsible for the sound-ness of their software and features (e.g., Javascript),respectively. Nevertheless, if the application is vul-nerable to, e.g., buffer overflow or format string at-tacks, then the security platform only safeguardsthat the intruder gains no more information thangiven in the compartment.

3.4 Requirements

To be able to provide the security objective, thesystem S has to fulfill the following requirements:

Requirement 1 (System Integrity) The in-

tegrity of security-critical components in S is pre-

served.

The system is incapable to provide protectionmechanisms and meet the other security require-ments if its critical components are infected by mali-cious programs. Therefore, these components mustbe isolated from non-critical components. More-over, there must be means to prevent offline attacks,e.g., when a different system is booted on the samehardware device. Otherwise the initial system com-ponents may be modified and integrity violationsare not recognized. Thus, a weaker version of thisrequirement is to demand a verification of the in-tegrity and to stop the execution of the system whenan integrity violation has occurred.

Requirement 2 (Isolation) The code and data

of applications in S have to be protected during run-

time and when it is persistently stored.

Malicious processes must not be able to access theinternal state or the persistently stored state ofother processes.

Requirement 3 (Trusted Path) The input and

output of the application in S, in which the user

enters his credentials, must be protected from unau-

thorized access by other applications.

The user must be sure about the integrity andauthenticity of the application when he is going toenter credentials. For instance, emulating passwordinput dialogs is a common attack of Trojan horseprograms. Thus, the user needs a way to invoke atrusted path to security-critical input dialogs.

Requirement 4 (Robustness) Security-critical

components of S should be robust against wrong

configuration or setup.

In the context of phishing attacks, we consideraverage users who are not skilled regarding securityindicators (e.g., SSL padlock icon). This holds espe-cially for the configuration of security-critical appli-cations. Thus, any configuration or setup that theuser must perform and which are needed to fulfillthe security objective must be easy to understandand robust against mistakes.

Requirement 5 (Interoperability) The system

S should be interoperable to commodity services that

third parties provide.

We do not make any requirements concerning theservice providers, i.e., the user’s system should notpresume adjustments and modifications of serviceinfrastructures and software. Although this is nota security-critical requirement, the issue is neces-sary to give the system a realistic chance for be-ing deployed and commercially used. Wheneverchanges to a system are demanded (e.g., attestingthe client’s system configuration), they should notrequire high costs for the provider and client. Oth-erwise, we believe that the system would not bewidely deployed.

4 Related Work

In this section, we discuss recent work on counter-acting phishing attacks and categorize them in pro-tection mechanisms addressing the browser, the op-erating system, and the interaction of the user andthe server. We also discuss wallet-based solutions,which are tangential to our trusted wallet approach.

Browser-based Countermeasures Methods ofthis class support unwary users to identify fakedweb sites and/or not to reveal their credentials.In [5] a heuristic check of web sites is proposed. Ac-cording to user-defined thresholds, several iterativechecks are performed to disclose a site’s identity.The shortcomings of this approach are false posi-tives: If the phisher knows how web sites are ana-lyzed, he can modify phishing sites to circumvent

4

the corresponding checks. Less advanced heuris-tics deploy whitelisting and respectively blacklist-ing approaches, recently adapted by prominent webbrowser vendors (e.g., [13]). There has also beenwork on fixing flaws of the browser chrome, assome phishing attacks deceive the user from cor-rectly identifying a web site: The authors in [39]propose to render boundaries of browsers’ dialogsaccording to their origin in different colors blinkingsynchronized to a reference window. In [1, 7], theauthors propose to personalize the chrome. Someresearch was also made to display SSL with respectto the diligence and capabilities of average Inter-net users: In [40], the author proposes to color theaddress bar depending on certificates’ trustworthi-ness according to policies of traffic lights. Moreover,the authors in [19] propose the deployment of logo-type certificates and display logotypes (e.g., brandmarks) in tamper-resistant regions of the browserchrome. The provision of an interface transparentto users is essential, since a basic methodology ofphishing attacks is to fake relevant connection andsecurity indicators of browsers to hide the illicit ori-gin of phishing sites.

However, these approaches do not achieve our se-curity objective. In particular, these approaches donot fulfill requirements 2 and 3: Malware phishingattacks are able to alter the chrome and securityindicators respectively, as no integrity check of con-tent and programs is provided in general.

Wallet-based Solutions In [38], the authors in-troduce a web wallet, which distinguishes betweeninput of sensitive data and service usage by strictlydeactivating login forms in the browser. The userhas to press a special security key whenever hewants to enter sensitive data. The web wallet veri-fies the security properties of the web site and asksthe user to explicitly choose the destination sitefor the sensitive data from a list. The list con-tains apart from the current site also sites for whichan identity has been previously stored. The wal-let passes sensitive data to the chosen site. Also[18] discusses a single-click approach storing pass-words in a wallet that may be cryptographicallyprotected by keys saved on hardware tokens. Todefend against malicious content (which the authorconsiders as the main reason of transporting mal-ware through web browsers), he proposes a browsersandbox model, in which unapproved web objects(e.g., unsigned content) are strictly blocked.

Although these approaches reduce the risk of clas-sical phishing attacks, they do not prevent attacksthat fake the user interface of the wallet and thus donot meet requirement 3. Moreover, the authors donot provide any means to prevent malware phishingattacks and thus do not meet requirement 1.

Operating System Approaches Lampson [22,23] proposed a security architecture for ordinarycomputing and ordinary users based on two colors:A red one to perform potentially untrusted tasks(e.g., downloads, adding plugins to browsers fromuntrustworthy sources), and a green one to performsecurity-critical tasks (e.g., online banking, taxes).Secure graphical user interfaces enable the user toclearly identify the application he intends to sendinput to. Moreover, the input and output chan-nels of different applications can be isolated and,hence, this provides a protection against malwaretrying to eavesdrop data, e.g., keyloggers. Epstein[8] provides a policy for labeling windows, showingthe security level of the corresponding application.This is accomplished by Trusted X [9], a special X11window system that enforces the labeling and pro-vides isolation between different security domains.More recently, GUI security was also considered by[33], which is related to the EROS operating systemin special. In [12], a framebuffer-based secure GUIserver is presented. This allows a more generic ap-plication of this technique, since not all operatingsystems use an X11 like window system.

Other work is related to integrity preservationand verification, which can be used to prevent mal-ware attacks in general. AEGIS [3] performs an in-tegrity check during the boot process of the wholeoperating system. It protects the integrity referencevalues by building a chain of trust and protectingthe root reference value by special hardware [36].The authors of [26] show how to use a TPM to im-plement this approach. The upcoming release ofMicrosoft Windows “Vista” [27] will also provide asimilar approach by encrypting the entire systemand binding the encryption key to the boot stack,thus ensuring that system files are unmodified.

Protecting the Interaction of User andServer Work in this category elaborates new ap-proaches on the level of user-friendly security pro-tocols: In [21], the authors propose an oblivioustransfer protocol to conjunct password-based mu-tual authentication and images, i.e., passwords con-sist of a sequence of images, which are visual sharedsecrets. The authors in [28] propose the notion ofSSL session awareness and augment SSL to coupleusers’ passwords (or any credentials) to SSL ses-sions. As a result, servers are able to thwart Man-in-the-Middle attacks, as passwords contain infor-mation about actually involved parties. Anotherextension of the SSL handshake is introduced in[29], where a trusted device (e.g., mobile device)instead of the web browser is used to automaticallyverify a web site’s authenticity.

These approaches are appropriate to combat clas-sical phishing attacks, where the user discloses cre-

5

dentials on a remote system. Nevertheless, they donot fulfill requirements 2 and 3, and thus do notprotect against malware phishing attacks. Theseattacks may latch onto the SSL layer and manipu-late the communication. That is also true for mobiledevices (see e.g., [6]), which do not provide a securearchitecture.

5 Architecture

In this section, we present our security architectureto prohibit identity theft through phishing attacks.We describe the static structure and the dynamicbehavior of our architecture along one major usecase. We first consider in Section 5.1 a pragmaticapproach, where we assume that the underlyingcomputing platform used for a wallet-based solutionis an off-the-shelf operating system. We describe ageneric architecture based on this and show that thesecurity properties this system provides are insuffi-cient against current phishing attacks. Second, weshow in Section 5.2 how the security properties canbe achieved by an efficient secure operating systemdesign and Trusted Computing functionality.

5.1 Wallet-based Solution

Despite the fact that an honest web browser maybe applied, the user may be cheated to request afaked web site. Moreover, he may be tricked to dis-close credentials, if he does not closely verify theauthenticity of the site. To counteract this typeof identity theft, we argue that the user’s systemshould be responsible for authenticating the serviceprovider and perform the user authentication on le-gitimate service sites. Based on this, we propose toutilize the following wallet-based architecture:

Figure 2: Architecture of the wallet-based Solution.

The architecture basically consists of two mod-ules (see Figure 2): A standard web browser B toaccess the services of provider P , and a Proxy Wal-let W to store credentials cid, identify legitimateservice sites, and perform the user authentication.We assume that the user enters security-sensitivedata only into W . Then W acts as a local net-

work proxy for the browser B in order to trans-parently encapsulate the mutual authentication be-tween user U and provider P .

5.1.1 Web Browser

The web browser B provides the user U to use webservices. However, connection requests for servicesthat require authentication are redirected to W .The only action of the user U we presume is enteringcredentials into W instead of B. W configures B

such that access to these services is redirected to theproxy. This functionality is supported by commonweb browsers. Hence, B forwards the connectionrequest to W using the channel use serviceB↔W ,if a user authentication is required. After W hasperformed the mutual authentication, the user canuse the service within B.

5.1.2 Proxy Wallet

The Proxy Wallet W provides a configuration dialog(channel authenticateU→W [sid, uid, pwdid]) allow-ing the user to enter credentials cid := (uid, pwdid)belonging to the service identified by sid. Since W

should perform the mutual authentication automat-ically, the user has to enter the sensitive informationbefore they are used to authenticate a session.

When the browser B requests a connection tothe service site sid, W actually establishes the con-nection to the service provider’s system P and au-thenticates P based on a verification of a SSL/TLScertificate (more precisely, the certificate’s finger-print). Note that typically the user has to ver-ify the result of the verification, while in our ar-chitecture this is done by W . If the site is notlegitimate, W aborts the connection and displaysan eye-catching error message. Only if the ser-vice site is legitimate, W transfers the correspond-ing credentials to P by using the secure channelauthenticateW→P [uid, pwdid]. If the login data arecorrect, P returns an authenticated session denotedby using the channel use serviceP↔W , which is for-warded by W to the web browser B. The user U

may now use the service as usual.

5.1.3 Security Analysis (Sketch)

Based on the assumptions made about the webbrowser and Proxy Wallet, we argue that the pro-posed architecture ensures that the user’s creden-tials only are transferred to legitimate sites andhence protects against classical phishing attacks.To lure the user U to a faked site sid, two casesare possible:

In the first case, the user U is tricked to requesta faked site because of being cheated by an obfus-

6

cated URL (e.g., in a phishing mail). The attack isdetected because W was invoked with an unknownservice identifier sid 6= sid and hence does not au-thenticate U . Moreover, Proxy Wallet locks the lo-gin forms. As the user U typically does not haveto type in the credentials cid to get access to sid,the authentication request therefore attracts his at-tention. Since we assumed that users enter criticaldata only into the wallet, the user’s identity is notdisclosed.

In the second case, the DNS server used by U

has been manipulated to resolve legitimate domainnames to IP addresses of phishing sites. Althoughthe locally used domain name is correct and B in-vokes W to perform the user authentication, theattack is detected because W fails to authenticatethe site on the basis of server certificates by com-paring the fingerprints. However, the comparisonis only feasible, if an SSL-protected connection hasbeen established. In the case of unprotected connec-tions, we may not reliably verify the server’s iden-tity. But note that in this case, the service providerP does not intend to provide a secure channel andthus identity theft could occur at any node of theInternet.

5.1.4 Discussion of Assumptions

The assumption that the user enters security-critical data only into the Proxy Wallet is in prac-tice more realistic and thus weaker than the as-sumption that the user always correctly verifies theresult of the certificate verification. For unskilledusers regarding security issues, cryptographic cer-tificates have a rather complex meaning, whereasthe identification of a clear-cut wallet interfaceshould be much easier. If we additionally assumethat applications behave honestly and do not lieabout their identity, they will provide an authen-tic user interface and will not manipulate the userinterface of other applications. Thus, the user willhave a trusted path to them. As a very pragmaticsolution, we therefore expect that an implementa-tion of the Proxy Wallet based on existing operat-ing systems, such as Linux or Microsoft Windows,might prevent most of current classical phishing at-tacks. This assumption is reasonable because theseattacks do not impact the integrity of S. Classicalphishing attacks do not change or modify systemcomponents; instead they relay the communicationchannel to a remote system.

However, the experience has shown that a newform of sophisticated malware phishing attacks canbe mounted bypassing theses security mechanisms.In practice, legacy operating systems do not providethe desired security properties against this type of

attack. In the following, we are going to considerthe most important and well-known shortcomings:

• No trusted path: Since legacy operating sys-tems lack support of a secure user interface pro-viding a trusted path, malicious applicationsmay access the authentication data when usersenter them into W .

• No application authentication: Since any appli-cation may claim to be another one, users areunable to authenticate applications, and mali-cious programs (e.g., Trojan horses) may de-ceive users to reveal sensitive data to dishonestapplications.

• No isolation: Since applications are not pro-tected from each other, a malicious applicationmay access the configuration data of W .

• No secure boot: An adversary could manipu-late the binary of W or the operating systemto mount malicious functions.

• Insecure browser: An adversary may usescripting and browser plugins to manipulatethe behavior of B.

Since we do not expect that the security of theoff-the-shelf operating systems will significantly im-prove in the future, the following subsection 5.2 de-scribes a security architecture providing a trustwor-thy computing base for the Proxy Wallet with re-spect to reuse of present components.

5.2 Secure Platform for the Wallet

We now show how the security requirements canactually be realized. The wallet-based architectureis therefore slightly modified, and we introduce asecure computing platform as execution environ-ment. This follows the approach of red/green com-puting [23] by dividing the system into trusted anduntrusted parts6 as shown in Figure 3 and 4.

Handling Insecure Browsers Since users tendto install additional software (plugins) into theirweb browsers, probably originating from an un-trustworthy source, we assume that manually in-stalled software may be infected by malware andthus be dishonest. For using security-sensitive ser-vices, such as online banking, this is a critical issue.Therefore, we additionally use a trusted browser

TB. The trusted browser is a zero-footprint versionof a standard web browser, i.e., any modifications,

6Although a division into only two domains, trusted anduntrusted, may not be generally adequate, this distinctionwill suffice for the phishing scenario. For real applicationscenarios, additional distinct domains may be possible, e.g.,one for gaming and one for office work. But this requiresmore elaborated access policies and will be future work.

7

Figure 3: Logical view of the architecture with untrusted components (colored in white).

such as installing plugins, are disallowed. We useTB then to access security-sensitive services thatrequire an authentication of the user.

We modify the wallet-based architecture in thefollowing way (cf. Figure 3): Only the trustedbrowser TB is authorized to call W and to con-nect to the service site. Communication channelsbetween an untrusted browser B and W are forbid-den. B provides the user a way to use services thatdo not require an authentication. Modifications ofB are allowed, e.g., the user can add extra function-ality. Thus, malware may infect B and establish a(covered) connection to adversary A, i.e., a collec-tion server, denoted by the channels sendU↔B andsendB↔A. The channels transfer arbitrary data andthe user is not able to identify the endpoint of thiscommunication.

Providing Isolation To protect the differentcomponents and to prevent unintentional communi-cation, we have to isolate the processes and only al-low controlled communication channels. We there-fore execute each component in a different compart-ment. There can be trusted and untrusted compart-ments. W is executed in a trusted compartment,whereas the untrusted browser is executed in an un-trusted compartment. To efficiently realize the iso-lation through compartments, we use virtualization[4, 17]. This means, we can execute off-the-shelf ap-plications and their corresponding operating systemin a compartment. This allows for us to reuse exist-ing software meeting requirement 5 and minimizesdevelopment and maintenance costs.

Realizing a Trusted Path The user U mustbe able to clearly authenticate the application cur-rently interacting with, especially when enteringsecret credentials in W . Thus, U must be ableto distinguish between the different compartments.Moreover, communication channels between theuser and trusted compartments must be secure, i.e.,a trusted path. Therefore, we use the concept of aSecure GUI : There is one trusted component solelycontrolling the input and output to the user, i.e.,keyboard/mouse events and the screen. Depending

on the currently used channel by the user, the inputdata is only passed to the corresponding compart-ment and vice versa for the output. Each compart-ment is visually labeled to enable the user to au-thenticate the currently displayed application. TheSecureGUI provides each compartment an isolatedframebuffer for drawing GUI elements. There is areserved area solely controlled by the SecureGUI todisplay the compartment label and its color. Thisrealization is similar to the one described in [12].

System Integrity Isolation confines maliciousmodifications to compartment boundaries and thuscan help to preserve the system integrity. However,the system behavior changes if the compartmentis infected. Best practice is to verify the integrityof components before they are executed. Integrityverification relies on the comparison of current com-ponent properties to reference values. The securityof integrity verification thus relies on the integrityof the reference values. We use Trusted Computingfunctionality to protect the initial reference valueand establish a secure boot process. During thisprocess, the integrity of all relevant system com-ponents, i.e., the trusted computing base (TCB),is measured and the measurement result is storedwithin the TPM. The concepts of this are borrowedfrom [26, 36].

We briefly describe the secure boot process: Thebootloader is bound to the system configuration ofthe hardware, i.e., the BIOS; the bootloader loadsthe basic modules of the security kernel and checkstheir integrity. This includes a special componentwe call Compartment Manager. The CompartmentManager loads the remaining compartments andmeasures their integrity. The Compartment Man-ager uses the measurements to authenticate trustedand untrusted compartments. The compartmentauthentication allows for us to control the commu-nication through channels as well as to create thecorresponding labeling for the SecureGUI.

Sealing Secret Data To protect the confiden-tiality of credentials, we use the sealing functional-ity and bind secret data to the configuration of W

8

and the TCB. This means, the credentials are en-crypted using a key that is protected by the TPM,and the decryption is only possible if the state of W

and the TCB are the same as at encryption time.Moreover, before W uses the data to perform an au-thentication, it verifies the properties of TB by us-ing the information provided by the CompartmentManager. Only if TB is unmodified, W will passthe secret data to the corresponding service site andestablish a proxy connection to TB.

Figure 4: Layered view of the architecture showinguntrusted (red) and trusted (green) compartments.The hardware is TC-enabled, e.g., by a TPM.

Figure 4 shows the layers of our security archi-tecture. The secure computing platform is realizedby the security kernel and hardware that providesTrusted Computing support. We divide the secu-rity kernel into two further layers: The Hypervisor

Layer is responsible for the actual virtualizationof hardware resources, whereas the Trusted Soft-

ware Layer comprises the security services that areneeded to fulfill the security requirements.

5.2.1 Security Analysis (Sketch)

We have already argued that the wallet-basedapproach protects against classical phishing at-tacks. We argue next that our proposed computingplatform provides a secure execution environmentto also protect against malware phishing attacks.These attacks try to modify the intended systembehavior. They can be classified regarding the tar-get of modification:

1. Modification of channels from the user to thesystem compartments.

2. Modification of channels between compart-ments.

3. Modification of a compartment itself.

4. Modification of components of the underlyingsecurity kernel.

1) There are two possible cases: In the first case,an attacker may try to modify a channel directly,e.g., to eavesdrop data the user enters into W . How-ever, the SecureGUI controls the input and output,and only the currently displayed compartment re-ceives the user’s input. This means, malware run-ning in a compartment cannot obtain data the userenters into another compartment. In the secondcase, a malicious compartment can try to indirectlychange the channel by faking the user interface ofa trusted compartment. For instance, an attackermay try to emulate the user interface of W to de-ceive the user to enter her credentials in the channelsendU→B . The SecureGUI though provides a visuallabeling of each compartment, and the user can def-initely identify the current communication channel.This prevents the user from entering data into acompartment that claims to be a different one.

2) Malware may try to change the channels be-tween compartments in order to eavesdrop sensitivedata. However, the isolation mechanism confineschanges to compartment boundaries. Any modifi-cation resulting from malware is restricted to thatcompartment the malware is running in. Hence,only the communication channels for this compart-ment can be changed. Since the CompartmentManager measures and authenticates each compart-ment, the channels for trusted compartments can-not be changed. If the integrity of the trusted com-ponents is preserved, their channels are trusted, i.e.,authentic, confidential, and have integrity.

3) An attacker may try to modify a specific com-partment, such as W . There are two possible cases:If the attack is mounted while the system is run-ning, the isolation mechanism prevents a modifi-cation across compartment boundaries. Althoughmodifications are allowed in the untrusted compart-ment, they cannot affect the trusted compartments.If, in the second case, an adversary can mount anoffline attack, i.e., when the system is not running,the secure boot process will detect a modification atnext start-up. Since the user’s credentials are sealedto a specific platform configuration (hardware andsoftware), they cannot be unsealed and thus cannotbe accessed after a malicious modification.

4) The integrity of the trusted components is ver-ified during the secure boot process. If the underly-ing security kernel is maliciously manipulated, theintegrity measurement results in the TPM will alsochange. Because the measurement will differ fromthe one at sealing time, the user’s credentials can-not be unsealed. Thus, the secret data cannot beaccessed and their confidentiality is preserved.

9

6 Implementation

The implementation of our prototype is basically aninstance of the PERSEUS secure platform architec-ture [30]. We use an IA32 based system equippedwith a TPM [34] to enable Trusted Computingfunctionalities. We use the bootloader TrustedGRUB [35] to establish a secure booting process.The implementation of the Hypervisor Layer isbased on an L4 microkernel [25], which provides iso-lation of processes and controls inter-process com-munication (IPC). IPC is used to realize the com-munication channels between compartments. TheTrusted Software Layer is implemented by nativeL4 applications, which provide the properties of thesecure platform. To reuse existing software, we re-alized the compartments with L4Linux [17], i.e., apara-virtualized7 Linux system. We used Linux forour prototype implementation because it is opensource software and can be easily modified, which iscurrently necessary for the virtualization. However,an implementation based on the Windows operat-ing system would also be possible in principle.

Within an L4Linux compartment, ordinary Linuxapplications can be executed without modification.Our web browser is a standard Firefox browser.The Trusted Browser compartment is realized byusing a stripped down Linux system running a zero-footprint version of Firefox. In the first version ofthe prototype, the Proxy Wallet compartment isalso a stripped down Linux system running a proxyapplication. However, the Proxy Wallet may laterbe an application running natively on L4. Thus,the Proxy Wallet can be seen as another applica-tion program on a PC, but it is protected by thevirtualization and strong isolation capability of theunderlying security kernel. This is the major dif-ference to existing wallet approaches, which usuallyintegrate the wallet in the browser.

In order to perform the user authentication usingthe user’s credentials, the Proxy Wallet has to ex-amine the HTTP content of the requested servicesites for login form data. It does not need to exam-ine the whole network traffic, since the login processis indirectly triggered by the request of the TrustedBrowser. Thus, the Proxy Wallet “knows” when ithas to scan for login data, since the login sites areusually the first sent by the service provider. Dueto the implementation of the Proxy Wallet withina stripped down Linux compartment we can easilyreuse existing open-source form data scanning en-gines. However, since there is still a lack of a stan-dardization for login form data, the implementationof the Proxy Wallet has to be adjusted to new ser-

7 The guest operating system kernel has to be modified toredirect hardware-critical functions calls to the hypervisor.

vice sites if their login forms differ. But once sucha standardization exists, the implementation of theProxy Wallet will be easily made compatible.

Figure 5: Screenshot, showing compartments differ-ently marked by the SecureGUI.

7 Conclusion and Outlook

We have presented the main idea of a security archi-tecture to protect against different types of phish-ing attacks. The solution we propose is based onthe concept of trusted wallets. It particularly con-siders the average skilled users, who are the mainvictims of phishing attacks. If the wallet is executedon a secure platform, malware phishing attacks canbe prevented as well. We have shown how to effi-ciently implement such a secure platform based onTrusted Computing and virtualization technology.The latter enables us to reuse existing software andkeep development costs low.

The security architecture can also be imple-mented on top of a different hypervisor (e.g.,Xen [4]). Upcoming processor architectures willprovide better support of virtualization, enablingthe hypervisor to run unmodified guest operatingsystems, such as Windows. To overcome updateproblems due to the binary attestation of the sys-tem configuration, we will work on the integrationof property-based attestation [32] within the in-tegrity measurement. Currently, we are working ona user study to evaluate the usability of our ap-proach and our prototype implementation. More-over, to store additional attributes (e.g., age, ad-dress), which are also identity-related, future workwill investigate how to automatically handle suchidentity claims requested by arbitrary services.

10

References

[1] A. Adelsbach, S. Gajek, and J. Schwenk. VisualSpoofing of SSL Protected Web Sites and EffectiveCountermeasures. In Information Security Practiceand Experience Conference, 2005.

[2] Anti Phishing Working Group. Phishing TrendReport(s), 2005-2006. http://www.antiphishing.com.

[3] W. A. Arbaugh, D. J. Farber, and J. M. Smith.A Secure and Reliable Bootstrap Architecture. InIEEE Symposium on Security and Privacy, pages65–71, 1997.

[4] P. Barham, B. Dragovic, K. Fraser, S. Hand,T. Harris, A. Ho, R. Neugebauer, I. Pratt, andA. Warfield. Xen and the Art of Virtualization.In SOSP ’03: Proceedings of the nineteenth ACMsymposium on Operating systems principles, pages164–177, New York, NY, USA, 2003. ACM Press.

[5] N. Chou, R. Ledesma, Y. Teraguchi, D. Boneh,and J. C. Mitchell. Client-side defense againstweb-based identity theft. In 11th Annual Net-work and Distributed System Security Symposium(NDSS ’04), 2004.

[6] D. Dagon, T. Martin, and T. Starner. MobilePhones as Computing Devices: The Viruses areComing! IEEE Pervasive Computing, 03(4):11–15, 2004.

[7] R. Dhamija and J. D. Tygar. The Battle AgainstPhishing: Dynamic Security Skins. In SOUPS ’05:Proceedings of the 2005 Symposium on Usable Pri-vacy and Security, pages 77–88, New York, NY,USA, 2005. ACM Press.

[8] J. Epstein. A Prototype for Trusted X LabelingPolicies. In Sixth Annual Computer Security Ap-plications Conference (ACSAC), 1990.

[9] J. Epstein, J. McHugh, H. Orman, R. Pascale,A. Marmor-Squires, B. Danner, C. R. Martin,M. Branstad, G. Benson, and D. Rothnie. A highassurance window system prototype. Journal ofComputer Security, 2(2):159–190, 1993.

[10] J. Evers. Phishers get personal, 26 May 2005.http://news.com.com/Phishers+get+personal/

2100-7349 3-5720672.html.

[11] W. E. Felten, D. Balfanz, D. Dean, and D. S. Wal-lach. Web Spoofing: An Internet Con Game. Tech-nical Report 540-96, Dept. of Computer Science,Princeton University, 1996.

[12] N. Feske and C. Helmuth. A Nitpicker’s guide toa minimal-complexity secure GUI. In 21st AnnualComputer Security Applications Conference (AC-SAC), 2005.

[13] D. Florencio and C. Herley. Stopping a PhishingAttack, Even when the Victims Ignore Warnings.Technical Report MSR-TR-2005-142, MicrosoftResearch (MSR), 2005. ftp://ftp.research.

microsoft.com/pub/tr/TR-2005-142.pdf.

[14] German Anti Identity Theft Working Group (a-i3). List of phishing mails and emails seeking forfinancial agents, 2006. https://www.a-i3.org/

content/category/5/36/84/.

[15] I. Giang. Threatwatch—Trojan hijacking,proxy victims, breaching conflicts of legal in-terest. Financial Cryptography, 18 March 2006.https://www.financialcryptography.com/

cgi-bin/mt/mt-tb.cgi/672.

[16] G. Goth. Phishing Attacks Rising, But DollarLosses Down. IEEE Security and Privacy, 03(1):8,2005.

[17] H. Hartig, M. Hohmuth, J. Liedtke, andS. Schonberg. The Performance of µ-Kernel-basedSystems. In SOSP ’97: Proceedings of the 16thACM Symposium on Operating Systems Principles,pages 66–77, New York, NY, USA, 1997. ACMPress.

[18] A. Herzberg. Protecting web users from phish-ing, spoofing and malware. Cryptology ePrintArchive, Report 2006/083, 2006. http://eprint.

iacr.org/.

[19] A. Herzberg and A. Gbara. TrustBar: Protecting(even Naive) Web Users from Spoofing and Phish-ing Attacks. Cryptology ePrint Archive, 2004.http://eprint.iacr.org/2004/155.pdf.

[20] K. J. Hole, V. Moen, and T. Tjstheim. Case Study:Online Banking Security. IEEE Security and Pri-vacy, 4(2):14–20, 2006.

[21] M. Jakobsson, S. Myers, and M. Augiere.Delayed Password Disclosure, 2005. http:

//www.informatics.indiana.edu/markus/

stealth-attacks.htm.

[22] B. W. Lampson. Accountability and Freedom.http://research.microsoft.com/∼risaacs/

blampson.ppt, Oct 2005.

[23] C. E. Landwehr. Green Computing. IEEE Security& Privacy, 3(6):3, Nov/Dec 2005.

[24] E. Levy. Criminals Become Tech Savvy. IEEESecurity and Privacy, 02(2):65–68, 2004.

[25] J. Liedke. On Microkernel Construction. In 15thACM Symposium on Operating System Principles,1995.

[26] J. Marchesini, S. W. Smith, O. Wild, J. Stabiner,and A. Barsamian. Open-Source Applications ofTCPA Hardware. In 20th Annual Computer Secu-rity Applications Conference (ACSAC), 2004.

[27] Microsoft Corp. Secure Startup - FullVolume Encryption: Technical Overview.http://www.microsoft.com/whdc/system/

platform/pcdesign/secure-start tech.mspx,April 2005.

[28] R. Oppliger, R. Hauser, and D. Basin. SSL/TLSSession-Aware User Authentication-Or How toEffectively Thwart the Man-in-the-Middle, 2005.(Computer Communications, accepted for publica-tion ).

11

[29] B. Parno, C. Kuo, and A. Perrig. PhoolproofPhishing Prevention. In Financial Cryptography,2006. (to appear).

[30] B. Pfitzmann, J. Riordan, C. Stuble, M. Waidner,and A. Weber. The PERSEUS System Architec-ture. Technical Report RZ 3335 (#93381), IBMResearch Division, Zurich Laboratory, Apr. 2001.

[31] J. D. T. Rachna Dhamija and M. Hearst. WhyPhishing Works. In Proceedings of the Confer-ence on Human Factors in Computing Systems(CHI2006), 2006.

[32] A.-R. Sadeghi and C. Stuble. Property-based At-testation for Computing Platforms: Caring aboutproperties, not mechanisms. In NSPW, pages 67–77, 2004.

[33] J. S. Shapiro, J. Vanderburgh, E. Northup, andD. Chizmadia. Design of the EROS Trusted Win-dow System. In USENIX Security Symposium,pages 165–178, 2004.

[34] Trusted Computing Group. TPM main specifi-cation. Main Specification Version 1.2 rev. 85,Trusted Computing Group, Feb. 2005.

[35] Trusted GRUB. http://trustedgrub.

sourceforge.net.

[36] J. Tygar and B. Yee. Dyad: A System Using Phys-ically Secure Coprocessors, 1994. Technical ReportCMU-CS-91-140R.

[37] W. Wang, Y. Yuan, and N. Archer. A ContextualFramework for Combating Identity Theft. IEEESecurity and Privacy, 4(2):30–38, 2006.

[38] M. Wu, R. C. Miller, and G. Little. Web Wallet:Preventing Phishing Attacks by Revealing User In-tentions. In SOUPS ’06: Proceedings of the SecondSymposium on Usable Privacy and Security, pages102–113. ACM Press, 2006.

[39] Z. E. Ye and S. Smith. Trusted Paths for Browsers.In USENIX Security Symposium, pages 263–279,2002.

[40] K.-P. Yee. Designing and Evaluating a PetnameAnti-Phishing Tool, 2005. http://cups.cs.cmu.

edu/soups/2005/2005posters/23-yee.pdf.

[41] Yi-Min Wang, Doug Beck, Xuxian Jiang, RoussiRoussev, Chad Verbowski, Shuo Chen, and SamKing. Automated Web Patrol with Strider Honey-Monkeys: Finding Web Sites That Exploit BrowserVulnerabilities. In Network and Distributed SystemSecurity (NDSS) Symposium, 2006.

12