Remote Client Authentication

8/3/2019 Remote Client Authentication

http://slidepdf.com/reader/full/remote-client-authentication 1/8

Secure Authentication

36 PublishedbytheieeeComPutersoCiet y■1540-7993/08/$25.00©2008ieee■ieeeseCurity&PrivaCy

remoteClientauthentiction

Thomas

Weigold,

ThorsTen

K ramp,

andmichael

BaenTsch

IBM Research

The eectiveness o remote client-authentication schemes

varies signifcantly in relation to today’s security

challenges, which include phishing, man-in-the-middle

attacks, and malicious sotware. A survey o remote

authentication methods shows how each measures up

and includes recommendations or solution developers

and consumers.

In today’s world o distributed data sources and

Web services, the need or remote authentication

is ubiquitous. By “remote,” we mean any inra-

structure in which client and server are con-

nected via some potentially insecure network—be it

the Internet or a data connection using short-message

service (SMS). Internet banking might be the primeexample; with it comes the added challenge o a user

base that’s not necessarily technically savvy. Ease o

use and high resilience against accidental misuse are

thus o particular importance.

So ar, researchers have proposed many remote

authentication methods, including simple passwords,

public-key inrastructures (PKIs), biometrics running

on desktop PCs, smart cards, and mobile phones. Each

has a reason to exist, depending on the design criteria

or the overall usage scheme. The challenge thereore

has become less one o inventing a working scheme,

and more o deciding which scheme to choose giventhe design criteria. In this article, we assume that de-

velopers are addressing security as the oremost con-

cern. Security can, however, conict with business or

usability goals. It might be acceptable, or example, to

deploy password-based authentication solutions when

developers are more concerned with cost and minimal

user training and support than with the threat o im-

proper authentication.

Remote authentication schemes Any remote authentication method’s goal is to establish

and secure an authenticated inormation channel byproving a user’s identity through an associated security

channel. For most methods, the inormation channel

also serves as the

security channel

and—unless we state otherwise—we assume this is

the case in our discussion. Terminology-wise, we also

assume that it’s always the client who connects to and

authenticates with a server.

Static passwords The oldest, most primitive remote authentication

method is the use o static passwords, which typically

change—at most—only every ew months. With this

method, a client presents a single static password to the

server or each authentication; the server then matches

it with the password stored or that client.

Static passwords are still widely used in application

domains where the environment is well controlled, the

protected values are limited, or the potential risks are

manageable. Example domains include authenticating

a user locally with his or her personal computer (PC);remote authentication within local-area networks or

intranets; or access control to an Internet bookstore.

However, when it comes to highly sensitive data—

such as inormation about nancial institutions, their

customers, and their transactions—researchers today

deem static passwords an insucient remote authen-

tication method.1 We thereore exclude this approach

rom our discussion.

One-time codes Remote authentication with one-time codes is based

on the idea that both client and server share a secret.The client presents it to the server either as is (that is,

the secret is the one-time code) or in a derived orm




www.cp./c/■ieeeseCurity&PrivaCy 37

according to some algorithm, possibly with additional

data also known to the server. (An exception here is

with systems based on one-way hash unctions—such

as the S/KEY system.2 In these systems, rather than

use a shared secret, the server authenticates the next

code in a sequence based on the previous code.) In the

one-time code approach, clients present each code to

the server only once; codes can’t be reused.

Scratch lists. A scratch list is the simplest orm o a

one-time code. A scratch list is typically given to the

client once, in paper orm, and usual ly contains about

40 to 100 codes. The server knows these codes, and

clients use them sequentially or in an indexed orm.

So, the shared secret is the listed code and clients use

it as is, without urther derivation.

I the client uses an indexed scratch list, the server

decides which one-time code should be used next byspeciying its index in the list; otherwise, clients typi-

cally have to track the used codes themselves. Either

way, each code is used once and only once, and the

server automatically sends the client a new list when

only a certain number o codes are let. Figure 1a il-

lustrates a scratch list scenario.

Short-time codes. With short-time codes, both client

and server share one or more secrets exchanged in ad-

vance. They might, or example, use a symmetric key

and derive one-time codes or authentication based on

these shared secrets and the current time. They never actually exchange the shared secrets, just the codes de-

rived via some derivation unction (x) (see Figure 1b).

Time granularity is typically on the order o a ew

minutes—that is, the same code is derived during

that time. This permits small time shits between the

client and server, and the server also usually accepts

codes derived rom times within the previous and

next time slots.

Challenge/response codes. As Figure 1c shows,

challenge/response codes modiy the short-time-

code concept by substituting a server-specied chal-lenge or the current time. That is, client and server

are again initially equipped with one or more shared

secrets, such as a symmetric key and a counter value

that’s incremented ater each authentication attempt.

Then, or authentication, the server presents a ran-

domly chosen challenge to the client. The client then

responds with a code derived rom the shared secrets

and the challenge, while the server perorms the same

derivation; the counter value thereby prevents identi-

cal responses to the same challenge.

Although there’s no time-shit problem with this

approach, the client can still inadvertently calculateresponse codes, potentially misaligning some secrets

shared with the server. Equally, the server might be

accidentally or intentionally triggered to send out

challenges and calculate response codes, which again

misaligns shared client-server secrets. Given this, theserver typically doesn’t accept one and only one re-

sponse code; it also accepts codes neighboring the tar-

get code up to a certain limit (such as the ve previous

and ollowing ones). I it detects a match, the server

realigns its shared secrets accordingly.

Alternatively, the server might send the challenge

via a separate security channel that’s authenticated

by some other means (such as an SMS communica-

tion secured via the mobile phone network). Thus,

the identity unction can derive the response and no

shared secrets are required. In this case, the resulting

authentication’s strength is inherited rom the selectedsecurity channel.

PKI-based authentication In contrast to one-time codes, authentication based

on public-key cryptography doesn’t rely on shared se-

crets.3 Instead, each client is initially equipped with a

private key (never to be exposed) and a matching pub-

lic key. Furthermore, the server uses a PKI that issues

a digital certicate to bind the client’s identity to his

or her public key. The certicate contains the client’s

public key, which is signed by one or more certicate

agency (CA) that the server trusts.Although it’s somewhat dicult to establish and

maintain a PKI, the authentication itsel is rather sim-

One-time code

Index (optional)

Scratch list

Short-time code

Response code

Challenge

Short-time

Challenge/response

Signature(Challenge) + Certicate

ChallengeCerticate

Private key

Challenge

Revoked clientcerticate list (CRL)

Certicate(s)

PKI-based

Client Server

f (x )

f (x ) f (x )

Time

Secrets(s)

Time

Secrets(s)

Challenge

Secrets(s)

Challenge

Secrets(s)

f (x )

1. 29372. 96653. 9754…

1. 29372. 96653. 9754…

(a)

(b)

(c)

(d)

Figure 1. Remote authentication schemes. There are currently our

primary approaches to advanced security: (a) a scratch list scenario,

(b) short-time codes, (c) challenge/response codes, and (d) public-key

inrastructure (PKI) authentication.




38 ieeeseCurity&PrivaCy■July/august2008

ple. The server presents a randomly chosen challenge,

and the client signs with its private key. (I both parties

ail to use necessary saeguards to prevent well-known

crypto-analytic attacks, such as the chosen-plaintext at-

tack, however, then the authentication scheme can be

broken.) As Figure 1d shows, both the signed challenge

and the client’s certicate are then returned to the serv-

er in response. The server thereupon ensures that:

the client’s certicate is val id (that is, it’s signed by a

trusted CA and the signature veries), and

the signature o the challenge veries with the given

client certicate.

The server also maintains a list o revoked client cer-

ticates (CRLs) in case, or example, a client’s private

key is compromised and must be invalidated. During

authentication, the server checks each client-presentedcerticate against the CRL and i it nds a match, it

denies the authentication. For a positive test, or i more

than one server uses the same CA without necessar-

ily authenticating the same group o clients, the server

usually stores either copies o the certicates or corre-

sponding hash values that it can authenticate. Further-

more, each certicate’s lietime is usually limited rom

a couple o months to a couple o years, ater which the

server issues a replacement certicate to the client.

Biometrics

Biometrics base remote authentication on “being some-thing” instead o “knowing something” (such as a one-

time code) or “having something” (such as a private

key). In biometrics, the server matches one or more cli-

ent biometric—such as a ngerprint, acial eature, iris

pattern, or hand geometry—with the same inorma-

tion previously stored at the server during enrollment.

During the enrollment process, the serving orga-

nization captures and stores each client’s biometric

inormation under well-controlled conditions. Then,

or authentication, the client again captures that in-

ormation and sends it and the claimed identity to the

server or matching. The server can thus reliably au-thentic clients given three assumptions. That is, that

biometric inormation

can be reproducibly captured repeatedly,

cannot be easily aked, and

is suciently diferent between any two clients.

Unortunately, clients can’t capture biometric in-

ormation reproducibly, but rather only in close ap-

proximation. A biometric match never returns a

clear-cut yes or no result—it returns only a probabil-

ity as to the veriability o the client’s identity. Thiscoercively causes so-called “alse rejects” (genuine

clients aren’t authenticated) and “alse accepts” (im-

•

•

•

•

•

poster are authenticated). Although developers can

move a threshold to adjust the tendency as to which

side a method will err on and with what probability,

each biometric authentication is inherently prone to

this type o misjudgment.

A signicant drawback here is that it’s possible to

obtain some biometric properties, such as ater physi-

cal contact (ngerprint on a water glass, or example)

or by using a high-resolution picture o a person’s eyes.

This limits biometrics’ value in scenarios where org-

ery o this type—say, plastic ngers or photographs

presented during the authentication phase—are un-

detectable. Also, like static passwords, clients can use

biometric eatures repeatedly once they’re obtained.

To prevent such misuse, we’d have to authenticate the

biometric device used to capture the biometrics to

ensure the authentication data’s origin.4 This would

introduce a whole new complexity level, makingbiometrics o limited value or remote authentication

over insecure networks.

Client security devices The most common client hardware is a standard desk-

top PC, which is also an easy platorm to attack. Peo-

ple thus oten additionally use a security device, such

as a smart card (either in a standalone reader or one that

connects to the PC), a mobile phone or PDA, or a smart

memory stick. The security device’s sotware then (at

least partially) perorms the authentication, preventing

certain types o attacks against the PC. As we nowdescribe, there are currently several commonly used

client-security devices. Although this might make the

security channel distinct rom the inormation chan-

nel, we assume that the inormation channel is always

established between a client’s PC and the server.

Smart cards A smart card consists o a plastic card with a smal l em-

bedded microprocessor with various memory types

(such as ROM, RAM, and Eeprom) and tamper-

resistant properties (such as secure crypto-coprocessors

or symmetric and public-key cryptography). Typi-cally, smart cards have external power and clock, and

communication is serial (contact-based or contactless).

To communicate with the smart card, users need

a reader that connects it with either a PC or stand-

alone device. Standalone readers typical ly have at least

a small display and a numeric keypad where users

enter their PIN and commands. Readers providing a

PC connection are commonly classied according to

their capabilities, with class 1 readers simply providing

connection, class 2 adding a pinpad, and class 3 readers

ofering a display and some programming capabilities.

Class 4 readers eature a separate security module anda virtual machine or custom application execution;

we thus consider them secure execution platorms.





Given their resistance to tampering, smart cards are

generally accepted as suciently secure to store sen-

sitive data, particularly private keys. Ideally, private

keys are generated on the smart card and are never

directly exposed to the outside world.

Mobile phones and PDAs Mobile phones or personal digital assistants (PDAs) are

separate computing platorms with their own displays

and keypads. Both can serve either as standalone devices

(or storing and computing one-time codes, or exam-

ple) or as a PC connection using Bluetooth, inrared, or

USB to remotely authenticate users. Mobile phones also

can use their mobile networks as security channels.

Functionality-wise, mobile phones are increasing-

ly general-purpose computing platorms that support

more or less open sotware execution platorms. By ar

the most prevalent code execution platorm is Sun’s Java, which is used in mil lions o phones. Download-

ing and installing Java applications is simple; vendors

have a huge commercial interest in making any sot-

ware purchase (such as games) easy or mobile phone

users. All versions o J2ME—the stripped-down

“embedded” Java version run in mobile phones—lack

desktop and enterprise Java security eatures such as

the byte-code verier, which perorms static code and

integrity checks.5 Without this on-device verier, at-

tackers can write “subversive” code and thereby access

the data o other Java code—such as a banking appli-

cation—residing on the same mobile phone.Only the most recent J2ME version (MIDP 2.0)

includes the possibility o digitally signing code and

thus tying code executed on the device to a trusted

source that presumably perorms proper of-device

byte-code verication. Only devices that conorm to

this specication level meet the recommendation to

only run code o known origin. It’s highly dubious,

however, that we’ll be able to educate typical users

enough to veriy that a piece o code’s digital signa-

ture reers to a trusted source. The underlying issue

o checking certicate origin—that is, checking SSL

certicates to avoid man-in-the-middle (MITM) at-tacks—has already proven intractable in PC-based

online banking.

Java’s prevalence, combined with a nonexistent

or dicult-to-veriy code-origin check and a weak

code security model, makes mobile phones ar weaker

than PCs when it comes to security. Storing secret

inormation (such as private keys) to support banking

applications on a mobile phone that lacks a security

module—that is, one that uses sot tokens, or sotware-

only authentication implementations—is, in our

opinion, ar too dangerous and users should not even

consider it. Instead, they should use a smart card as atamper-resistant security module. Nearly all mobile

phones have a security interace module (SIM), which

are smart cards that, among other things, authenticate

the mobile phone with the mobile network provider.

Network operators can deploy additional applications

on these SIMs, which can use the mobile phone net-

work as a security channel.

The new generation o mobile phones also has a

second smart card that ofers secure storage or appli-

cations running on the phone’s runtime platorm. The

card also provides a runtime platorm or secure ap-

plications. These new phones can connect smart cards

to PCs using near-eld communication (NFC),6 a

short-range contactless communication interace and

protocol based on ISO proximity card standards.7 Al-

though it’s convenient or users, such direct commu-

nication between NFC-enabled mobile phones and

PCs requires them to add a contactless reader device

to their PCs. To use the second smart card simply,

that is, as a phone-based authentication with user inter-action on the phone, is similar to using the SIM. The

only diference is the chip’s availability (which is rare

compared to SIM) and accessibility (which is better

than SIM).

Still, short o the phone-internal chip that drives

all external user interactions—through a SIM Appli-

cation Toolkit (SAT)8 application, or example—us-

ing a security device helps protect only the secret

data. It can’t guarantee overall application integrity. I

a user can be tricked into providing the password to

the secret data, a malicious on-phone application can

reely access the data, even i it’s saely stored. Any ap-plication that uses a mobile phone as a security device

must account or this act when designing what on-

phone code can do with the secret inormation once

it’s unlocked. As an obvious example, it should be im-

possible or an application to copy out this data, even

i the user presents the correct PIN code.

Smart memory sticks Memory sticks equipped with a smart card—in, or

example, a USB orm actor or use with PCs—are a

rather new development. The memory stick mounts

as a write-protected volume (like a CD) and usuallycontains some immutable sotware or remote au-

thentication. This sotware might be a Web browser,

such as Fireox, that’s restricted to connecting only to

certain Web sites. For added convenience, users can

congure some or all o this sotware to automatical ly

launch whenever the memory stick is mounted. Any

mutable state and any data that can’t be exposed (such

as a shared secret or a private key) are stored and pro-

cessed on the embedded smart card.

One o this technology’s main challenges is how to

create user-riendly updating o the read-only memory

i, or example, security patches require installation o a new version o the memory stick’s sotware. Further-

more, not all applications can operate rom a read-only





device. As a result, they must be temporarily copied to

the PC’s hard drive prior to each execution.

In principle, smart memory sticks can work with

mobile phones—by inserting them into the secure

digital (SD) slot, or example—as o now, however,

we’re not aware o any such products.

Attacks and countermeasures All o the methods mentioned earlier authenticate a

client with a server and are thus equivalent in terms o

unctionality. However, their power to resist attacks

difers signicantly. We must thereore understand the

potential attacks on a remote authentication method

beore choosing one. Here, we ocus on three types o

attack: phishing, malicious sotware, and MITM. All

three are attacks against the client, whose protection

mechanisms are arguably less sophisticated than those

typically ound at a server. We don’t discuss attacksagainst the server, such as denial o service.

Figure 2 ofers an intentionally generic outline o

the three attack types; we don’t consider combination

attacks or urther relationships between the attacker

and the client.

Phishing As Figure 2a shows, phishing combines spooed emails

and mocked-up Web pages. An attacker, might, or

example, hijack a well-known nancial institution’s

trusted brand and trick users into entering their au-

thentication credentials (such as a one-time code) intoa aked Web orm. Such trickery is commonly achieved

through emails that look genuine i users only casually

examine them; most users don’t actually know how to

reliably identiy a genuine server. Phishers reportedly

convince up to 5 percent o users receiving a spooed

email to respond and reveal their secrets.9

Scratch lists, even indexed ones, are inherently

prone to phishing attacks because the one-time code’s

validity period is itsel rather long (or even unlim-

ited). Also, the code isn’t specically connected with

a particular inormation channel. So, when attackers

get a one-time code rom a scratch list, they can use

it with any inormation channel to the genuine server

any time ater an attack and prior to the legitimate

user’s next attempt to authenticate with that server.

Biometric authentication is also conceptually vulner-

able to phishing attacks or the same reasons.

To make it more dicult or phishers to obtain se-

cret inormation stored on a mobile phone’s security

module, it might help to authenticate not just the user,but also the backend system to the secret data container.

Also, the secret data container is unaware o the current

time. By reliably provisioning it with the current time,

we might prevent repeated/recurrent use o the secret

data without the container’s knowledge, and also possi-

bly have it shut down i it becomes aware o an attack.

In contrast, short-time codes at least limit an at-

tacker’s window o opportunity to a couple o min-

utes. Still, only challenge/response authentication

efectively prevents phishing by strictly associating

each response to a specic authentication attempt.

Applying this line o reasoning, PKI-based authenti-cation methods also prevent phishing attacks. In act,

we can consider the server challenge’s digita l signature

as a response, much like a one-time code challenge/

response scheme, though the latter usually employ a

simpler inrastructure than PKI.

Man in the middle The inamous MITM is a network attack. Rather than

trying to obtain a user’s authentication credentials, the

attacker covertly intercepts messages between the cli-

ent and server, masquerading as the server to the client

and as the client to server, respectively (see Figure 2b).Although virtually all o today’s servers are authenti-

cated via a public-key certicate when users establish

an SSL/TLS session, users oten naively ignore warn-

ing messages about invalid or untrusted certicates.

This lets attackers hijack an authenticated inormation

channel or silently modiy transaction data. In con-

trast to phishing, however, an MITM attack doesn’t

necessarily compromise a user’s credentials.

On the protocol level, the SSL/TLS protocol’s cli-

ent-authentication option can render MITM attacks

impossible. Unortunately, the SSL/TLS protocol

doesn’t support one-time code schemes or cl ient au-thentication (although researchers have made a pro-

posal in that direction10). On the application level,

Fakeserver

login:

Fake server

Malicioussoftware

Spoofed email

LinkCredentials

Credentials

Man in the middle

Impersonationwhile genuine

client connects

Fakeclient

Client Attacker

Server

Trojan horse virus

Impersonationat any time

Impersonationat any time

(a)

(b)

(c)

Figure 2. Three types o attack scenarios. (a) Phishing attacks trick users

into revealing their credentials. (b) Man-in-the-middle attacks intercept

communication between client and server to modiy transactions or

hijack the authenticated channel. (c) Malicious sotware invades PCs to

raudulently gather user credentials.





MITM attacks can be prevented only by challenge/

response one-time codes or PKI-based authentication

methods—i both are extended to this end. To ex-

clude an MITM, the client and server must uniquely

identiy the inormation channel, and then

use this identication as an additional input parame-

ter when calculating the one-time code response, or

concatenate it with the data to be digitally signed.

The client and server could, or example, use the

session-specic SSL/TLS protocol inormation—such

as the handshake message’s hash value—to identiy

the inormation channel. Such inormation would be

diferent or client and server i, instead o one end-

to-end session, they had two sessions with an MITM.

Consequently, either the client’s one-time code re-

sponse or the signed data wouldn’t match, respective-ly. I the session identication is independent o the

SSL/TLS connection—as in the use o cookies, or

example—the session has no MITM resistance.11

All other remote authentication methods we dis-

cuss here are prone to MITM attacks. Unortunately,

recent research shows that while online services are

becoming more resistant to phishing attacks—such

as by moving rom scratch lists to short-time pass-

word-generating hardware tokens—MITM attacks

are increasing.12

Malicious software Malicious sotware aims to raudulently gather authen-

tication credentials by invading an insuciently pro-

tected client PC by means o a virus or a Trojan horse

(see Figure 2c). For example, once establ ished, a Trojan

horse could read and orward a private key stored on

the PC’s hard drive while monitoring keyboard activ-

ity to access the pass phrase used to decrypt the private

key. Users can protect themselves against malicious

sotware using security precautions—such as install-

ing and maintaining a rewall and regularly updating

antivirus sotware; applying OS and browser patches as

needed; and conguring sotware appropriately—butew users strictly adhere to such procedures.

Considering most users’ lack o attention to secur-

ing their PCs, server providers increasingly classiy

PCs as a generally insecure client platorm and rerain

rom using any sot tokens. This is why smart cards

play an increasingly important security role: they not

only store a client’s credentials, but also perorm any

necessary computations.

A rst step is a smart card directly connected to

a PC by a class 1 reader. When the smart card runs

a scheme to generate challenge/response one-time

codes or a PKI-based authentication method, a client’scredentials are no longer plainly available to malicious

sotware. Even i a virus or Trojan horse obtains the

•

•

smart card’s PIN via a keyboard logger, it can still tr ig-

ger only the client PC’s authentication method, rather

than grab the credentials and use them on any PC.

Developers can achieve higher security by connect-

ing the smart card to the PC using a class 3 or 4 reader,

or a Bluetooth/NFC-connected mobile phone. This

prevents malicious sotware rom opening the smart

card by itsel and restricts it to triggering the authen-

tication method once the user has entered the PIN. I

each authentication method invocation requires some

urther user interaction on the reader, it becomes even

harder because users must be tricked into explicitly

accepting a remote authentication. Similarly, devel-

opers could use a reader to display application-related

inormation and authorize transactions.13

I both challenge and response can be easily trans-

erred manually rom one device to another, users can

get a standalone device that totally eliminates malicioussotware attacks. Such a device can generate short-time

codes, or example, and show them on a small display so

the reader can view the code and enter it into a server

Web orm. I the standalone device has a keypad, it can

generate challenge/response one-time codes and users

can manually transer both challenge and response be-

tween the device and their PCs. A keypad also lets users

protect the device itsel using a PIN, which renders it

useless i lost. I the standalone device—such as a mo-

bile phone—has network connectivity and can receive

short messages, users can leverage this into a separate

security channel and have the server send individualone-time authentication codes on demand. However,

in such cases, the security channel’s properties should

be thoroughly evaluated. For example, with SMS com-

munication, users must consider that messages can be

delayed or lost, network operators can trace them, and

a phone without PIN protection might be stolen.

In contrast to the one-time code approach, PKI-

based authentication methods are slightly more di-

cult to implement on a standalone device. Manually

transerring a digital signature rom the device to a

Web orm is anything but practical. When combined

with a mobile phone, however, users can separate thesecurity and inormation channels. That is, the mo-

bile phone network rst sends a challenge to a cl ient’s

mobile phone running the authentication sotware via

SMS, or example. Next, users enter some authoriza-

tion code into the mobile phone. The server might,

or example, send that authorization code to the cli-

ent via the inormation channel, thereby connecting it

with the digital signature.14 Finally, the PKI-enabled

mobile phone sends the digital signature back to the

server using the mobile phone network.

Discussion Phishing and malicious sotware attacks have now be-

come virtually ubiquitous15,16 and are growing rapidly





(in Korea, or example, phishing has grown at an av-

erage monthly rate o 10.8 percent since June 200417).

In addition, attackers have accomplished this without

sacricing their efectiveness.18 Any newly deployed

remote authentication method must thereore with-

stand these attacks. This rules out scratch lists and bio-

metrics as methods and the PC as a trusted device.

Even indexed scratch lists are prone to phishing at-

tacks (see www.netpartners.com/securitylabs/alerts/

alert.php?AlertID=580) and provide only slightly

higher resistance than linear scratch lists. Short-time

codes limit the timerame or phishing attacks, but

they don’t generally rule them out.

To render phishing and malicious sotware attacks

useless, users should employ challenge/response one-

time codes or a PKI-based authentication in combina-

tion with some security device.19 In light o current

attacks, we consider such schemes to be state o theart. A good example would be a smart card embed-

ded in either a standalone reader with a display and a

keypad or a mobile phone or PDA connected to a PC

via Bluetooth or NFC and to the server using SMS

messaging. Given this, authentication methods such

as challenge/response one-time codes, PKI-based au-

thentication, and (to a slightly lesser degree) short-time

codes can prevent phishing, while the security device

is immune to malicious sotware. With mobile phones

or PDAs, users must evaluate the extent to which the

device is considered an open platorm that lets attack-

ers load arbitrary code, and, i so, how much smart-card access such code might have. I both are possible,

malicious sotware attacks come back into play.

Neither challenge/response one-time codes nor

application-level PKI-based authentication immedi-

ately protect against MITM attacks, but both can be

extended to do so. To achieve this, developers need

inormation specic to the inormation channel that

the client and server establish during the computation.

They might draw this inormation rom the SSL/TLS

session state, or example, and then use it to either cal-

culate the response or as part o the data to be digital ly

signed during PKI-based authentication.MITM attacks are becoming increasingly common

as easy-to-use MITM toolkits emerge (see www.rsa

security.com/press_release.asp?doc_id=7667). Using

the SSL/TLS protocol’s client-authentication option

with a security device not only renders MITM impos-

sible by design, it leads to a more advanced solution

or near-uture attacks. However, one general prob-

lem remains. The authenticated inormation channel

always ends on the untrustworthy PC, usually at the

Web browser’s SSL/TLS implementation. Conse-

quently, users can’t trust what they see on their PC

display. For example, locally installed malicious sot-ware might run attacks similar to a remote MITM or

silently manipulate transaction data. To prevent such

sophisticated attacks, users must explicitly approve any

sensitive transaction—such as a unds transer in on-

line banking—using a security device with a display

and embedded keypad. The security device can then

ensure that the displayed inormation can’t be urther

modied by digitally signing it.19,20

Given our discussion and ndings, we have three

primary recommendations or any new remote

authentication solution:

Although still widely used, scratch lists are no lon-

ger state o the art as they can’t withstand phishing

and malicious sotware attacks.

Challenge/response one-time codes or PKI-based

schemes, combined with a secure device, should be

the basis or any authentication solution.Because MITM attacks are increasing,12 develop-

ers should build solutions with a clear vision o how

they might be extended to thwart MITM attacks.

An ideal solution to counter today’s security chal-

lenges is to use a security device with a display and

embedded keypad that maintains a secure end-to-end

connection with the server.13 This protects credentials

against phishing, renders MITM attacks impossible,

and lets users detect malicious sotware attacks.

References B. Schneier, “Two-Factor Authentication: Too Little,

Too Late,” Comm. ACM , vol. 48, no. 4, 2005, p. 136.

L. Lamport, “Password Authentication with Insecure

Communication,” Comm. ACM , vol. 24, no. 11, 1981,

pp. 770–772.

R.E. Smith, Authentication: From Passwords to Public Keys ,

Addison-Wesley, 2002.

U. Waldmann et al., “Protected Transmission o

Biometric User Authentication Data or Oncard-

Matching,” Proc. ACM Symp. Applied Computing , ACM

Press, 2004, pp. 425–430.

X. Leroy, “Java Bytecode Verication: Algorithms andFormalizations,” J. Automated Reasoning , vol. 30, nos.

3-4, 2003, pp. 235–269.

The Keys to Truly Interoperable Communications, Near

Field Communication Forum, 2007; www.nc-orum.

org/resources/white_papers/nc_orum_marketing

_white_paper.pd.

Proximity Integrated Circuit Cards (PICCs), ISO/IEC

14443, parts 1-4, http://wg8.de/sd1.html#14443.

Specifcation o the SIM Application Toolkit (SAT), 3GPP

Standard TS 11.14 v. 8.5.0 , www.3gpp.org/tp/Specs/

archive/11_series/11.14/1114-850.zip.

Report on Phishing , Binational Working Group onCross-Border Mass Marketing Fraud, US Department

o Justice & Ministry on Public Saety, Oct. 2006,

•

•

•

1.

2.

3.

4.

5.

6.

7.

8.

9.




www cp /c/ ■ ieee seCurity & PrivaCy 43

www.usdoj.gov/opa/report_on_phishing.pd.

M. Steiner et al, “Secure Password-Based Cipher Suite

or TLS,” ACM Trans., vol. 4, no. 2, 2001, pp. 134–157.

K. Fu et al., “Dos and Don’ts o Client Authentication

on the Web,” Proc. Usenix Security Forum, Usenix As-

soc., 2001, pp. 251–268.

Semi-Annual Report , Federal Oce o Police, Swiss

Reporting and Analysis Centre or Inormation As-

surance (MELANI), 2007; www.melani.admin.ch/

dokumentation/00123/00124/01029/index.html?

lang=en.

T. Weigold et al., “The Zurich Trusted Inormation

Channel—An Ecient Deence against Man-in-the-

Middle and Malicious Sotware Attacks,” P. Lipp, A.R.

Sadeghi, and K.M. Koch, eds., Proc. Trust Con. (Trust

2008), LNCS 4968, Springer-Verlag, 2008, pp. 75–91.

The WPKI Non-Prot Association, WPKI Main Speci-

fcation, v. 2.0, March 2006; www.wpki.net/les/WPK

I%20Main%20Specication%202.0.pd.

R. Thompson, “Why Spyware Poses Multiple Threats to

Security,” Comm. ACM , vol. 48, no. 8, 2005, pp. 41–43.

US-Cert: Quarterly Trends and Analysis Report , vol. 2, no.

2, U.S. Computer Emergency Readiness Team, June

2007; www.us-cert.gov/press_room/trendsandanalysis

Q207.pd

Korea Phishing Activity Trends Report , Korea Internet Se-

curity Center, Mar. 2007; www.krcert.or.kr/english

_www/publication/8_1_publication_list.jsp?board

Type=PUB.

R. Dhamija et al., “Why Phishing Works,” Proc. Con.Human Factors in Computing Systems (CHI), ACM Press,

2006, pp. 581–590.

A. Hiltgen et al., “Secure Internet Banking Authen-

tication,” IEEE Security & Privacy, vol. 4, no. 2, 2006,

pp. 21–29.

F. Puente et al., “Improving Online Banking Security

with Hardware Devices,” Proc. 39th Int’l Carnahan Con.

on Security Technology (CCST), IEEE Press, p. 174–177.

Thomas Weigold is a software engineer at IBM’s Zurich Re-

search Laboratory. His research interests include secure sys-

tems, business process management, and Grid computing.Weigold has an MSc in computer science from the University

of Westminster, UK. Contact him at [email protected].

Thorsten Kramp is a research staff member at IBM’s Zurich

Research Laboratory. His research interests include secure sys-

tems, embedded systems, and sensor networks. Kramp has a

PhD in computer science from the University of Kaiserslautern,

Germany. Contact him at [email protected].

Michael Baentsch is a research staff member at IBM’s Zur-

ich Research Laboratory. His research interests include secure

systems, secure ID, and sensor networks. Baentsch has a PhDin computer science from the University of Kaiserslautern, Ger-

many. Contact him at [email protected].

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

NEW from theComputer Society…

What’s New: Free, newly

published articles fromall 14 of the IEEE ComputerSociety’s magazines

Theme Articles: Freearticles on hot topics,such as computer gamesand agile computing

From the Editors Blog:Perspective and opinionsfrom our expert editors

Multimedia: Links topodcasts and video blogs

CS Newsfeed: Daily technews updates

Book Reviews: Exclusivereviews of technology books

Survey: Weekly opportunitiesto voice your opinion

•

•

•

•

•

•

•

http://computingnow.

computer.org

Log on to:

Documents

Remote Client Authentication