html/OTC_CompSecBrowsers

Compartmented Security for Browsers –

Or How to Thwart a Phisher with Trusted Computing

Sebastian Gajek, Ahmad-Reza Sadeghi, Christian St¨uble, and Marcel Winandy

Horst G¨ortz Institute for IT Security, Ruhr-University Bochum

Universit¨atsstr. 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 become a ma-

jor concern for Internet users. Typically, phishing attacks
aim at luring the user to a faked web site to disclose per-
sonal information. Existing solutions proposed against this
kind of attack can, however, hardly counter the new genera-
tion of sophisticated malware phishing attacks, e.g., pharm-
ing Trojans, designed to target certain services. This paper
aims at making the first steps towards the design and imple-
mentation of a security architecture that prevents both clas-
sical and malware phishing attacks. Our approach is based
on the ideas of compartmentalization for isolating applica-
tions of different trust level, and a trusted wallet for stor-
ing credentials and authenticating sensitive services. Once
the wallet has been setup in an initial step, our solution re-
quires no special care from users for identifying the right
web sites while the disclosure of credentials is strictly con-
trolled. Moreover, a prototype of the basic platform exists
and we briefly describe its implementation.

1. Introduction

Identity theft has become a subject of great concern for

Internet users in the recent years: Since password-based
user authentication has established on the Internet to grant
users access to security critical services, identity theft and
fraud attracted attackers [25].

Hence, phishing—a col-

loquial abbreviation of

password fishing

—has become a

prominent attack. Whereas

classical

phishing attacks pri-

marily used spoofed emails to lure unwary users to faked
web sites where they reveal personal information (e.g.,
passwords, credit card numbers), current attacks have be-
come advanced in their number and technical sophistica-
tion [2, 11, 15]. The new generation of phishing attacks
does not solely address the weaknesses of careless Inter-
net users, but also exploits vulnerabilities of the underlying

computing platforms and takes advantage of legacy flaws
of the Internet:

Hostile profiling

addresses specific email

recipients to mount classical phishing attacks more pre-
cisely [6],

pharming

compromises DNS servers to resolve

domain name requests to phishing sites [2], and

malware

phishing

infiltrates customers’ computers, e.g., to log their

password stroking using malicious programs [17].

The most dominant reason for the proliferation of phish-

ing attacks is that strong assumptions and requirements are
made on the ability of ordinary Internet users when access-
ing sensitive services [13]. Internet users of average skill
often do not understand security indicators and cannot dis-
tinguish between legitimate and faked web sites [21]. To
reliably authenticate a web site, the user has to verify the
domain name, ‘https’ in the URL, and the server’s certifi-
cate. However, ordinary Internet users are unfamiliar with
the meaning of SSL and DNS. This is in particular true for
phishing victims, as most faked sites may have been ex-
posed if users had properly checked for the presence of SSL
channels. On the other hand, the rise of malware phishing
indicates that common computing platforms lack of appro-
priate protection in practice. The problem with malware
phishing attacks is that they are (i) specifically designed to
target certain services (e.g., regional banks), (ii) exploit op-
erating system characteristics, and (iii) deploy tailored func-
tionalities to obtain users’ credentials [2, 17]. It is straight-
forward for malware phishing attacks, e.g., to fake security
indicators, imitate the browser’s (or any security-critical ap-
plication’s) chrome or modify the system configuration, and
thus to circumvent current phishing (and malware) coun-
termeasures (see Section 5). Moreover, malware phishing
attacks are not transparent to the user and hence raise less
suspicion of identity theft than its classical variant.

In this paper, we make the first steps towards the design

and implementation of a security architecture that counters
both phishing attacks. We propose a modular platform that
uses a trusted wallet to store user’s credentials and authen-
ticate the sensitive services as a proxy on behalf of the user.
Hence, it does not require specific skills from users, e.g.,

to distinguish between real and faked web sites by identify-
ing security indicators. We discuss how to setup and update
credentials that are to be stored in the wallet and how to
solve problems that may arise when security-unaware users
want to apply the same credentials to different services. In
contrast to existing proposals our solution provides protec-
tion measures against the strongest type of phishing attacks,
namely malware phishing. To establish a secure execution
environment for the wallet, we show that a secure and com-
patible operating system can be efficiently realized by using
virtualization and we justify why trusted computing func-
tionality is needed.

In Section 2, we define terms and notations. In Section 3,

we discuss assumptions on the parties involved in a phish-
ing scenario. We infer the security requirements to prevent
phishing attacks in Section 4 and discuss related work in
Section 5. We describe our architecture in Section 6 and its
details in Section 7. In Section 8 we briefly describe an im-
plementation, and we conclude in Section 9. An extended
version of this paper can be found in [9].

2. Terms and Notations

Principals

are parties involved in the phishing scenario.

These are the user

who is interfaced to a computer system

and the service provider’s system

is a collection of

software components, such as the browsing application

Compartments

are isolated logical components in

. We de-

note the phishing adversary as

and say that

uses a set

of collection servers, such as a phishing site, to store and
retrieve identities.

Channels

are abstractions of communi-

cation paths. We distinguish between secure and insecure
channels and denote a secure channel as a communication
of two principals which is authentic, confidential, and of
integrity. For example,

send

→

is the unilateral channel

that

uses to send a message to

Identities

are security

sensitive information and are the targets of phishing attacks.
We denote an identity

as the tuple (

attr

)

where

indicates a set of unique service provider identi-

fiers to authenticate

a set of credentials to get access

, and

attr

a set of attributes specific to user and ser-

vice, such as age, address, or credit card number. The set of
identifiers

are the URL and a server certificate (in case

of SSL), which we abbreviate as the tuple (

U RL

cert

Credentials

establish the claim that

is in possession

and are denoted as the tuple (

pwd

), whereas

and

pwd

are username and password.

3. Security Assumptions

Based on the diversity of current phishing attacks, we

make the following assumptions.

Assumption 1 (Ordinary User):

We assume that an

ordinary Internet user

is unable to properly authenti-

cate

according to

, e.g., the domain name, HTTPS in

the URL, and the SSL certificate. However, recent studies
[13, 21] point out that ordinary Internet users usually do not
distinguish legitimate web sites from faked ones and do not
understand indicators which signal trustworthiness.

Assumption 2 (Honest Provider):

Let

be a stan-

dard service provider, then we assume that

and its ser-

vices are not corrupted.

fulfills all requirements to pro-

tect his services and enforces sound security policies; other-
wise intruders were able to steal identities from the service
provider’s database. This is in particular true for certifying
services. An adversary

may gain an original certificate

cert

for a phishing site [10]. This is rather a problem of

public key infrastructures and not the scope of the present
work. Moreover, services are resilient against so called web
spoofing attacks [7], where the adversary

initially dis-

plays a completely faked Internet and is able to spoof any
service. This is crucial because the user would disclose his
identity while signing in to any service.

Assumption 3 (Sound Browser):

Let

be a standard

browsing application running on

, then we assume that the

functionalities of

are implemented correctly. Browser de-

velopers are responsible for the soundness of their software
and features, e.g., Javascript. Nevertheless, if the browser is
vulnerable to, e.g., buffer overflow attacks, then the user’s
system should safeguard that the intruder gains no more in-
formation than given in the application boundaries of the
browser (see requirements below).

4. Security Requirements

The main motivation is to fulfill the following objective.

Objective (Confidentiality of Credentials):

The system

approves that user

and service provider

are mutually

authenticated and use a secure communication path. An ad-
versary must not gain access to the user’s credentials, i.e.,
credentials must only be given to authorized sites and au-
thorized components of

. The problem is that most web

applications provide only entity authentication, i.e., the au-
thentication is based on credentials and does not include all
components in the communication path. This opens a gap
for the communication of

and

, respectively.

To be able to provide the security objective, the system

has to fulfill the following requirements. In Section 7.1.5

we argue that only the fulfillment of all these requirements
protects against phishing attacks.

Requirement 1 (System Integrity):

The integrity of

security-critical components in

should be preserved. The

system cannot meet the other security requirements if its
critical components are infected by malicious programs.
Therefore, these components must be isolated from non-

critical components. Moreover, there must be means to pre-
vent offline attacks, e.g., when a different system is booted
on the same hardware device. Otherwise the system com-
ponents may be maliciously modified. Thus, an integrity
verification at system startup is required (secure boot).

Requirement 2 (Isolation):

The code and data of appli-

cations in

have to be protected during runtime and when

being persistently stored. Malware attacks may try to ex-
ploit vulnerabilities of the computing platform in order to,
e.g., log the user’s key strokes. Thus, applications of differ-
ent tasks should be isolated, e.g., scripts running in the web
browser should not be able to access the credential store of
the wallet. Where communication is necessary, only con-
trolled communication interfaces should be possible.

Requirement 3 (Trusted Path):

The input and output of

the application in

in which the user enters his credentials,

must be protected from unauthorized access by other appli-
cations. For instance, emulating password input dialogs is
a common attack of Trojan horse programs. Thus, the user
must be sure about the integrity, authenticity, and confiden-
tiality of the communication path to the application.

Requirement 4 (Robustness):

Security-critical compo-

nents of

should be robust against wrong configuration or

setup. Since we assume ordinary users, any configuration
or setup that the user must perform and which are needed to
fulfill the objective must be robust against mistakes.

5. Related Work

In this section, we discuss recent work on protection

mechanisms against phishing attacks. Since executing a
digital wallet for passwords on top of a secure operating sys-
tem is a fundamental approach of our work, we also discuss
related wallet-based solutions. We retain the discussion on
approaches that try to increase user awareness or prevent
the mounting of phishing attacks (e.g., secure DNS, sign-
ing emails) and building blocks of secure operating systems
(e.g., secure GUI) due to space limitations.

Phishing Countermeasures.

Boneh et al. [4] propose

heuristic checks of web sites. According to user-defined
thresholds, several iterative checks are performed to dis-
close a site’s authenticity. Other heuristics deploy whitelist-
ing and blacklisting approaches, recently adapted by promi-
nent web browser vendors [8]. Of course, these approaches
depend on the report of phishing sites.

There has also been work on fixing flaws of the browser’s

chrome, as some phishing attacks trick the user in verifying
a web site’s identity: Ye and Smith [27] render boundaries
of browser dialogs according to their origin in different col-
ors blinking synchronized to a reference window. Adels-
bach et al. [1] propose to personalize the chrome.

Since SSL authentication is a reliable method to authen-

ticate web sites, some research has been done to display

SSL to non-experts or to strengthen the user authentication.
Yee [28] proposes to color the address bar depending on the
trustworthiness of server certificates following the policies
of traffic lights. Moreover, Herzberg/Gbara [14] propose
to augment X.509 certificate with logos being displayed in
tamper-resistant regions of the chrome. Ross et al. [22] pro-
pose to hash a user-typed password and domain name to
provide stronger user authentication. This is an appropriate
countermeasure against classical phishing, assuming DNS-
based attacks are not present. We will make use of this idea,
which we slightly modify and discuss in Section 6.

None of the approaches achieves our security objective.

In particular, they do not fulfill requirements of isolation
and trusted paths. Malware phishing attacks are able to alter
the chrome and falsify security indicators, as no integrity
check of content and programs is provided in general.

Wallet-based Solutions.

Wu et al. [26] introduce a web

wallet, which distinguishes between input of sensitive data
and service usage by strictly deactivating login forms in the
browser. The user has to press a special security key when-
ever he wants to enter sensitive data. The wallet verifies
the security properties of the web site and asks the user to
explicitly choose the destination site for the sensitive data
from a list. The wallet passes the data to the chosen site
then. Herzberg [13] discusses a single-click approach stor-
ing passwords in a wallet that may be cryptographically pro-
tected by keys saved on hardware tokens. To defend against
malicious content, he proposes a browser sandbox model, in
which unapproved web objects (e.g., unsigned content) are
strictly blocked. Although these approaches reduce the risk
of classical phishing attacks, they do not prevent attacks that
fake the user interface and thus do not meet requirement 3.

Operation System Approaches.

Cox et al. [5] propose

the Tahoma browser operating system for web applications.
They use a security kernel that isolates different web ap-
plications by assigning to each service site a browser com-
partment, running an instance of a web browser, and re-
stricting the communication of that browser compartment.
Service providers may provide a policy defining to which
web sites the browser instance is allowed to communicate.
The authors also present an implementation based on Xen,
where the browser compartments are realized as virtual ma-
chines. The network communication of these browser com-
partments is controlled by a network proxy within the secu-
rity kernel. While the Tahoma approach is effective against
a malware-infected browser trying to pass credentials to a
different site other than stated in the policy, it provides no
means against classical phishing. If the user is tricked to
open a phishing site the Tahoma architecture can only guar-
antee that there will be an isolated browser compartment for
this site. But the user still has to authenticate the web site
and may be tricked to enter his credentials in the phishing
site. Thus, to prevent both classical and malware phishing

attacks, a combination of operating system approaches and
other phishing countermeasures seems to be necessary.

6. Architecture

To prevent phishing attacks, our approach relies on the

following ideas: We let a trusted component, called

wallet-

proxy

, (i) authenticate legitimate service sites, and (ii) con-

trol the secret data of the user’s identity including per-
forming the user authentication procedure (see Fig. 1) The
wallet-proxy acts as a web proxy from the browser’s point
of view. This allows the system to be interoperable to ex-
isting web browsers. The only action users need to per-
form is to initialize the wallet by storing sensitive data once.
Since the wallet performs the authentication on behalf of
the user and passes sensitive user data solely to approved
service sites, an unintentional disclosure of the user’s iden-
tity is prevented. This approach protects only against clas-
sical phishing. To protect the user also against malware

Figure 1. Conceptual view of the architecture.

phishing attacks, we need a trusted execution environment.
We accomplish this requirement by exploring the idea of
trusted and untrusted compartments (multicolored comput-
ing). The browser is contained within one compartment,
and the wallet-proxy within another compartment. This
is the main difference to existing wallet-based approaches,
since the wallet functionality is not realized as a browser
plug-in, but it is strictly isolated from the browser except
for one communication channel controlled by the security
kernel. Malware attacks targeting the browser compartment
are confined to this compartment and will not effect the
wallet-proxy compartment or other parts of the user’s sys-
tem. Moreover, malware attacks targeting the wallet-proxy
compartment must not result in an unauthorized disclosure
of the user’s credentials. Therefore we need an execution
environment that guarantees strong isolation and integrity.

Security Kernel.

We realize this environment by us-

ing the PERSEUS security framework [20]. The PERSEUS
framework has a security kernel that provides

isolation of

applications

system integrity

, a

secure graphical user in-

terface

, and a

trusted storage

. Moreover, the PERSEUS ar-

chitecture uses virtualization [3, 12] technology to execute
one or more instances of a legacy operating system on top of
the trusted software layer. Each virtual machine has its own
virtual resources and cannot interfere with the resources of
another virtual machine. Virtualization allows for an effi-
cient implementation and usage of legacy software.

However, virtualization alone is not sufficient to provide

a secure operating system. For instance, the integrity verifi-
cation process must rely on correct integrity reference val-
ues. Malware may try to modify these, and offline attacks
(e.g., booting a different system) may maliciously modify
critical system components. To confirm the security guar-
antees of integrity and confidentiality, the PERSEUS secu-
rity kernel is executed on hardware that supports Trusted
Computing functionality, e.g., as provided by a TPM

Trusted Computing Support.

Trusted Computing (TC)

provides security functionalities which we use for

secure

booting

and

sealed storage

. For this, we deploy TC-enabled

hardware that measures the integrity of the initial platform
boot code and enables the boot loader to establish a secure
booting sequence. A measurement is performed by accu-
mulating a cryptographic hash of the binaries in the boot
stack. Thus, the security kernel can check the integrity of
application binaries that are to be executed in compartments
(see, e.g., [19]). The TPM can encrypt data using a key that
never leaves the TPM. The decryption is bound to the plat-
form configuration stored in the TPM at encryption time
(sealing). Hence, the data can only be decrypted if the plat-
form has the desired state defined as being trustworthy. We
use this functionality to securely store the user’s credentials
and to ensure that only the wallet can access the storage if
the integrity of its inherent compartment is preserved.

7. Realization

In the following, we present details of our security ar-

chitecture. We first consider a pragmatic approach in Sec-
tion 7.1, assuming the underlying platform is an off-the-
shelf operating system. We describe a generic architecture
and show that this system is insufficient against malware
phishing attacks. Second, we show in Section 7.2 how the
needed security can be achieved by integrating the wallet-
based approach into the PERSEUS framework.

7.1. Wallet-Proxy

Our wallet-based approach basically consists of two

modules (see Figure 2): An arbitrary web browser

to ac-

cess and use services, and a wallet-proxy

to store cre-

The Trusted Platform Module (TPM) is the basic building block of

Trusted Computing technology as specified by the Trusted Computing
Group (TCG), see

https://www.trustedcomputinggroup.org

dentials, to identify legitimate service sites, and to perform
the user authentication. We prerequisite that the user en-
ters security-sensitive data only into

. Then

acts as

a network proxy for

in order to transparently encapsu-

late the mutual authentication between user

and service

provider

. The authentication information is the tuple (

attr

), which is kept in a credential store for each

7.1.1

Setup

In general, there are three cases of user authentication:

Two-Factor Authentication.

The user receives creden-

tials out-of-band that he uses in an SSL-protected connec-
tion. For example, in some European countries banks prefer
to send the authentication information by snail mail. Then
the authentication is split into two stages: First,

is in-

structed to login to site

:= (

U RL

) using user name

and password denoted as the tuple (

pwd

) to get access

to his account. Second, he uses an acknowledgment code

pwd

Ack
id

to confirm the login. The code may be printed,

such as a TAN list, or dynamically generated by a hard-
ware device (token). In that case,

sets up

manually

to store the credentials

:= (

pwd

) and the service

identifier

:= (

U RL

) received out-of-band. To config-

ure

uses channel

authenticate

→

. He may also

deposit some specific attributes

attr

. When the browser

requests

U RL

for the first time, a dialog pops up in-

forming

that the deposited credentials have been associ-

ated with this URL. Then,

saves the server’s certificate

fingerprint

cert

print
id

∈

cert

, which is used in subsequent

requests to identify that site, i.e., if

matches the tuple

(

U RL

cert

performs the login on behalf of

One-Factor Authentication.

User and service provider

have not agreed on a shared secret before. Therefore, the
user negotiates credentials over an SSL-protected web site
while signing in to the service. A registration is manda-
tory for

. For this,

looks for forms on the web site

which have to be filled out by

, blocks the forms to pre-

vent an unintentional disclosure of credentials and gener-
ates a credential profile. Blocking the forms is realized by
modifying the HTML code presented to the browser, and
this ensures that

enters credentials and attributes only into

. To setup the credentials,

configures

using chan-

nel

authenticate

→

by selecting the credential profile

and entering the required credentials.

will save them

with one slight modification, it will bind credentials to ser-
vice identifiers. Loosely speaking,

stores random pass-

words that are linked to cryptographically unique service
identifier, such as the fingerprint of the server’s certificate

cert

print
id

. Therefore,

retains the hash value of

pwd

user

concatenated with a random value

instead of the user-

typed password

pwd

user

∈

pwd

hash

(

pwd

user

)

As it has been pointed out in, e.g., [22], we prevent on the
one hand that

applies low-entropy passwords to set up

the account, on the other hand we ensure that

does not

use the same password for different accounts.

Unprotected Authentication.

The user and service

provider negotiate credentials over an unprotected web site.
Note that confidentiality and authentication of transferred
data is not provided then. However, recall that this case
is of particular interest because most phishing-sites use an
unprotected connection. When an insecure channel is estab-
lished,

shows a warning dialog to inform

that eaves-

dropping attacks are possible. Anyway, should

decide to

proceeds as in

the case of one-factor authentication. Although the com-
munication is insecure, we show in Section 7.1.4 that this
prevents a certain class of attacks anyway.

7.1.2

The

user

requests

site

U RL

using

channel

use service

↔

The

request

sent

through

use service

↔

identifies the service

according to

embeds the credentials

into the site

and logs in the user. All the user sees is being redirected to
the original logged-in site in the successful case. Then the
service is assumed to be trusted and the user

is allowed

to fill out additional forms (e.g., requests for the acknowl-
edgment code), which are not stored in

. Otherwise,

sees blocked forms requesting for credentials. This keeps
the user from revealing personal data to unknown sites and
alerts him to enter sensitive data into

only.

7.1.3

Update

An update is important if the user wants to modify some
service specific attributes

attr

or if the server certificate

is invalid. Changing the password should not be necessary,
as

uses high-entropy passwords linked to cryptographic

identifiers. To update

attr

, the user

invokes channel

authenticate

↔

and selects the corresponding creden-

tial profile to configure

. If the server certificate has to be

updated, we propose the following policy.

compares the

attributes of the original certificate

cert

to the new certifi-

cate

cert

new

. In particular, if the issuer is the same and

the issuing party is a trusted certificate authority, then

replaces

cert

in the credential store; otherwise, a warning

message pops up and the user is asked to run the setup.

We argue that the proposed architecture ensures that

user’s credentials are only transferred to legitimate sites and
hence protects against

classical phishing

attacks.

7.1.4

Security Analysis (Sketch)

We first show that the wallet-driven login protects against
unintentional disclosure of credentials. Then we consider
security aspects of setting up and updating the wallet. Re-
call that in a classical phishing attack two cases are possible
to lure the user

to a faked site

Figure 2. Communication channels of the browser and the wallet-proxy.

First, the user is tricked to request a faked site. This at-

tack is detected because

was invoked with an unknown

service identifier

and hence does not authenticate

. Moreover,

blocks the login forms. As the user typi-

cally does not have to type in the credentials

to get ac-

cess to

, the login request therefore attracts his attention.

Since we assumed that users enter critical data only into the
wallet,

’s identity is not disclosed. Nonetheless, the user

could intend to register to the faked site

. Because

unfamiliar to the wallet,

has to run the setup of

. Then,

initiates

to configure credentials bound to

, i.e.,

generates the password

pwd

. Due to the one-wayness

of the hash function, it is impossible for a computationally
bounded adversary

to gain access to the user-typed pass-

word

pwd

user

and

is unable to reconstruct

pwd

Second, the DNS server used by

has been manipu-

lated to resolve domain names to phishing sites. This attack
is detected because

fails to authenticate the site on the

basis of server certificate

cert

. More precisely,

com-

pares the digital fingerprints

cert

print
id

. Again,

a computationally bounded adversary

is unable to com-

pute

pwd

(due to the one-wayness of the hash function).

This is also true for the update. Consider, e.g., the attack in
which the adversary

uses self-issued certificates.

sets

a password

pwd

, which is only valid for the faked side.

If credentials have been set up for an unauthenticated

service, it is straightforward for the adversary

to spoof

U RL

and to receive

pwd

in cleartext. But note that then

identity theft could occur at any node of the Internet. Nev-
ertheless, the randomness in

pwd

prevents that

reveals

pwd

user

. Assuming that

uses the same passwords for

different sites, we deter

from reusing the credentials

Thus, the setup mechanism meets requirement 4.

7.1.5

Discussion

The assumption that the user enters security-critical data
only into the wallet-proxy is in practice more realistic and
thus weaker than the assumption that the user always cor-
rectly verifies the result of the certificate verification. For
ordinary users, cryptographic certificates have a rather com-
plex meaning, whereas the identification of a clear-cut wal-
let interface should be much easier. However, in practice,
off-the-shelf operating systems do not meet the security re-

quirements 1, 2, and 3. Since we do not expect that the se-
curity of the those systems will significantly improve in the
future, the following subsection describes how the wallet-
proxy is integrated into the PERSEUS security framework.

7.2. Secure Platform for the Wallet-Proxy

We divide the system into trusted and untrusted parts fol-

lowing the approach of red/green computing [16]. Although
a division into only two domains, trusted and untrusted,
may not be generally adequate, this distinction will suf-
fice for the phishing scenario. In Section 6 we have already
summarized the security properties of the security kernel in
PERSEUS. So we only need to show how the wallet-proxy
interacts with the security kernel.

7.2.1

Interaction with Trusted System Components

In the following, we focus only on the core components of
the security kernel that are of relevance, see Figure 3. Each
component is executed within a distinct compartment. The
user

must be able to clearly authenticate the application

currently interacting with, especially when entering creden-
tials in

. Thus,

must be able to distinguish between the

different compartments. The Compartment Manager

loads and starts all other components.

also measures

the components and stores the measurement in the TPM.

Figure 3. Communication channels of the
wallet-proxy with trusted components.

The SecureGUI

solely controls the input and output

channels to

. In order to enable the user to clearly iden-

tify compartments,

provides the channel

app id

→

which provides the user with the name and color of
the compartment that is currently displayed in channel

use app

↔

. The input in this channel is passed to the

corresponding compartment. If

is currently displayed,

’s input is passed through

input

→

, and the out-

put of

is displayed to

through

use app

↔

. Each

compartment has its own distinct input/output channel to

. The name and color of a compartment are derived from

its measurement, which authenticates the compartment.

To protect the confidentiality of the user’s credentials,

we use the sealing functionality to bind the secret data to
the measurement of

and the underlying security kernel.

uses the Storage Manager

to persistently store the

credentials and its configuration.

sends the data through

channel

store

→

, and

securely stores the

data by using the sealing functionality of the TPM and sav-
ing the encrypted data. This means, the credentials are en-
crypted using a key that is protected by the TPM, and the
decryption is only possible if the measurement of

and of

the security kernel are the same as at encryption time. When

requests to load its credential store, e.g., on system start-

up,

uses the unsealing functionality of the TPM to de-

crypt the data. Then

sends the decrypted data through

channel

load

→

7.2.2

Security Analysis (Sketch)

We have already discussed that the wallet-based approach
protects against classical phishing attacks. We argue next
that our proposed architecture provides a secure platform to
also protect against malware phishing attacks. We classify
the attacks regarding the targets of modification:

First,

attacks the user-to-compartment channels. He

may try to (i) eavesdrop the channel between

and

, (ii)

fake the user interface of a compartment to emulate the user
interface of

, or (iii) modify the browser compartment

to unblock the forms and deceive

to disclose the cre-

dentials. In the first case, the SecureGUI

controls the

input and output and only the compartment currently dis-
played receives

’s input. This means, malware running

in a compartment cannot obtain data

enters into another

compartment due to isolation. In the second case,

pro-

vides a visual labeling of each compartment through chan-
nel

app id

→

so that the user can identify the compart-

ment currently mapped to channel

use app

;

recognizes

the faked interface due to the red color of the compartment.
Thus,

fulfills requirement 3. In the third case,

fills out

the unblocked forms and thus discloses the user-typed pass-
word

pwd

user

. However, due to the randomness

, which

is only known to

is unable to reconstruct

pwd

Second,

modifies the channels between compartments

in order to access secret data. However, the isolation mech-
anism confines changes to compartment boundaries, which
meets requirement 2. Any modification resulting from mal-

ware is restricted to that compartment the malware is run-
ning in. So, only the outgoing communication of this com-
partment can be changed. Since

measures and authen-

ticates each compartment, the integrity of trusted compart-
ments can be verified. If the integrity of those components
is preserved, their channels are secure and thus confidential.

Third,

may try to modify a specific component, e.g.,

. There are two possible cases: If the attack is mounted

while the system is running, the isolation mechanism pre-
vents a modification across compartment boundaries. Al-
though modifications are allowed in untrusted compart-
ments, they cannot affect the trusted compartments. If, in
the second case,

can mount an offline attack, i.e., when

the system is not running, the secure boot process will de-
tect a modification of system components at next system
start-up, meeting requirement 1. Since

’s credentials are

sealed by the TPM to a specific measurement of the system,
they cannot be unsealed and thus cannot be accessed by

8. Prototype Implementation

Although our implementation is an early prototype, the

basic platform is available and executable. It is an instance
of the PERSEUS framework [20], where we use an x86
based system equipped with a TPM [23] to enable Trusted
Computing functionalities. We use the bootloader Trusted-
GRUB [24] to establish a secure boot process. The secu-
rity kernel is based on an L4 microkernel [18], which pro-
vides isolation of processes and controls inter-process com-
munication (IPC). IPC is used to realize the communication
channels between compartments. The trusted software layer
is implemented by native L4 applications. To reuse existing
software, we realized the browser and wallet-proxy com-
partments with L4Linux [12], i.e., a para-virtualized Linux
system. We used Linux because it is open source software
and can be easily modified, which is currently necessary for
the virtualization. Principally, an implementation based on
a virtualized Windows system would also be possible.

Within L4Linux compartments, ordinary Linux applica-

tions can be executed. We use a standard Firefox browser as
web browser. The wallet-proxy compartment is a stripped
down Linux system. It provides an interface to enter user-
name and password for web sites. However, we have not
implemented a web form parser functionality yet. We use a
hard-coded version where only the connection to our own
test server can be established, which simulates a service
provider. The Linux kernel in the wallet-proxy compart-
ment acts as a Internet network router for the browser com-
partment. If the browser compartment requests a connection
to the server, the wallet-proxy actually establishes the con-
nection, authenticates the user and the server’s SSL certifi-
cate, and redirects the traffic to the browser compartment.

We also have a SecureGUI that controls the input/output

to the user and provides each compartment an isolated
screen framebuffer. For more information, see [9].

9. Conclusion and Outlook

We have presented a security architecture to protect

against different types of phishing attacks. The solution
we propose is based on the concept of trusted wallets. It
particularly considers the average skilled users, who are
the main victims of phishing attacks. If the wallet is exe-
cuted on a secure platform, malware phishing attacks can
be prevented as well. We have shown how to efficiently im-
plement such a secure platform based on Trusted Comput-
ing and virtualization technology to reuse existing software
and keep development costs low. The security architecture
can also be implemented on top of a different virtualization
layer (e.g., Xen [3]). Upcoming processor architectures will
provide better support of virtualization, enabling the kernel
to run unmodified operating systems in compartments, such
as Windows. Since several computer vendors already ship
their platforms equipped with a TPM, we can reasonably as-
sume hardware support of Trusted Computing functionality.
The security kernel of our architecture is also used as basic
platform for other research and development projects

Future work includes enhancing the functionality of the

wallet-proxy, such as parsing forms embedded in emerging
web languages like Ajax, or storing and protecting addi-
tional attributes, e.g., age and address. We are also working
on a study to evaluate the usability of our implementation.

References

[1] A. Adelsbach, S. Gajek, and J. Schwenk. Visual Spoofing

of SSL Protected Web Sites and Effective Countermeasures.
In

ISPEC 2005

, volume 3439 of

LNCS

. Springer, 2005.

[2] Anti Phishing Working Group. Phishing Trend Report(s),

2005-2006.

http://www.antiphishing.com

[3] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris,

A. Ho, R. Neugebauer, I. Pratt, and A. Warfield. Xen and
the Art of Virtualization. In

SOSP ’03

. ACM Press, 2003.

[4] N. Chou, R. Ledesma, Y. Teraguchi, D. Boneh, and J. C.

Mitchell.

Client-side defense against web-based identity

theft. In

11th Annual Network and Distributed System Se-

curity Symposium (NDSS ’04)

. Internet Society, 2004.

[5] R. S. Cox, S. D. Gribble, H. M. Levy, and J. G. Hansen. A

Safety-Oriented Platform for Web Applications. In

Proceed-

ings of the 2006 IEEE Symposium on Security and Privacy
(S&P’06)

, pages 350–364. IEEE Computer Society, 2006.

[6] J. Evers.

Phishers get personal,

26 May 2005.

http://news.com.com/Phishers+get+

personal/2100-7349_3-5720672.html

[7] W. E. Felten, D. Balfanz, D. Dean, and D. S. Wallach. Web

Spoofing: An Internet Con Game. Technical Report 540-96,
Dept. of Computer Science, Princeton University, 1996.

For instance, the Turaya distribution at

http://www.emscb.org

[8] D. Florencio and C. Herley. Stopping a Phishing Attack,

Even when the Victims Ignore Warnings. Technical Report
MSR-TR-2005-142, Microsoft Research, 2005.

[9] S. Gajek, A.-R. Sadeghi, C. St¨uble, and M. Winandy. Com-

partmented Security for Browsers. Technical Report HGI-
TR-2007-001, Horst G¨ortz Institute for IT Security, Ruhr-
University Bochum, 2007.

http://www.prosec.rub.

de/publication.html

[10] I. Giang.

SSL Phishing, Microsoft Moves to Brand,

and Nyms.

Financial Cryptography

14 February

2006.

https://www.financialcryptography.

com/mt/archives/000654.html

[11] G. Goth. Phishing Attacks Rising, But Dollar Losses Down.

IEEE Security and Privacy

, 03(1):8, 2005.

[12] H. H¨artig, M. Hohmuth, J. Liedtke, and S. Sch¨onberg. The

Performance of

-Kernel-based Systems.

SOSP ’97

pages 66–77. ACM Press, 1997.

[13] A. Herzberg. Protecting web users from phishing, spoofing

and malware. Cryptology ePrint Archive, Report 2006/083,
2006.

http://eprint.iacr.org/

[14] A. Herzberg and A. Gbara.

TrustBar: Protecting (even

Naive) Web Users from Spoofing and Phishing Attacks.
Cryptology ePrint Archive, 2004.

http://eprint.

iacr.org/2004/155.pdf

[15] K. J. Hole, V. Moen, and T. Tjstheim. Case Study: Online

Banking Security.

IEEE Security and Privacy

, 4(2):14–20,

2006.

[16] C. E. Landwehr. Green Computing.

IEEE Security & Pri-

vacy

, 3(6):3, Nov/Dec 2005.

[17] E. Levy. Criminals Become Tech Savvy.

IEEE Security and

Privacy

, 02(2):65–68, 2004.

[18] J. Liedke. On Microkernel Construction. In

15th ACM Sym-

posium on Operating System Principles

, 1995.

[19] J. Marchesini, S. W. Smith, O. Wild, J. Stabiner, and

A. Barsamian. Open-Source Applications of TCPA Hard-
ware. In

ACSAC

, 2004.

[20] B. Pfitzmann, J. Riordan, C. St¨uble, M. Waidner, and A. We-

ber. The PERSEUS System Architecture. Technical Report
RZ 3335 (#93381), IBM Research Division Zurich, 2001.

[21] J. D. T. Rachna Dhamija and M. Hearst. Why Phishing

Works. In

Proceedings of the Conference on Human Fac-

tors in Computing Systems (CHI2006)

, 2006.

[22] B. Ross, C. Jackson, N. Miyake, D. Boneh, and J. C.

Mitchell. Stronger password authentication using browser
extensions. In

14th USENIX Security Symposium

, 2005.

[23] Trusted Computing Group. TPM main specification. Main

Specification Version 1.2 rev. 85, Feb. 2005.

[24] TrustedGRUB.

http://trustedgrub.sf.net

[25] W. Wang, Y. Yuan, and N. Archer. A Contextual Framework

for Combating Identity Theft.

IEEE Security and Privacy

4(2):30–38, 2006.

[26] M. Wu, R. C. Miller, and G. Little.

Web Wallet: Pre-

venting Phishing Attacks by Revealing User Intentions. In

SOUPS’06

, pages 102–113. ACM Press, 2006.

[27] Z. E. Ye and S. Smith. Trusted Paths for Browsers. In

USENIX Security Symposium

, pages 263–279, 2002.

[28] K.-P. Yee.

Designing and Evaluating a Petname Anti-

Phishing Tool, 2005.

http://cups.cs.cmu.edu/

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