ONE-TOUCH FINANCIAL TRANSACTION AUTHENTICATION

Daniel V. Bailey, John Brainard

RSA, the Security Division of EMC, Bedford, MA U.S.A.

Sebastian Rohde, Christof Paar

Horst-G¨ortz Institute for IT Security, Ruhr-Universit¨at Bochum, Germany

Keywords:

User authentication, Online banking, Wi-Fi.

Abstract:

We present a design for a Wi-Fi user-authentication token that tunnels data through the SSID ﬁeld, packet

timing, and packet length. Previous attempts to build an online-banking transaction-signing token have been

only moderately successful, due in large part to usability problems. Average consumers, especially in the

United States, are simply unwilling to transcribe strings of digits from PC to token and back again. In a

departure from previous work, our token communicates using point-to-point side-channels in Wi-Fi that allow

two devices to directly exchange messages – even if one is also connected to an access point. The result is a

token that can authenticate transactions using only one touch by the user. The increased usability means more

transactions can be authenticated, reducing fraud and driving more banking business online.

1 INTRODUCTION

The contribution of this paper is a design for a Wi-

Fi user-authentication token with a focus on online

banking. In its most basic form, our token tunnels au-

thentication data through the SSID ﬁeld found in Wi-

Fi management frames. Our new techniques allow

the seamless operation of three devices: a specialized

token, a standard Access Point (AP) and a PC with

application-layer software to interact with the token.

To that end, this paper introduces a constructive use

of Wi-Fi side channels. Although side channels are

usually treated in the literature as a means to attack

systems, in this paper we propose their use as a legit-

imate communication channel.

For its part, Wi-Fi represents both an opportunity

and a challenge. It is widespread, especially in PCs.

Because it suffers fromseveral disadvantages, we pro-

pose new methods of co-opting Wi-Fi using certain

data ﬁelds, packet length, and packet timing, to over-

come these limitations.

Our work is motivated by the difﬁculties of user-

authentication schemes for retail online banking. We

equip users with a wireless device which we’ll call the

token. The token is used during login and transaction

execution. Although authentication tokens have been

available for years, they have historically imposed a

serious burden on users. Our new design addresses

this shortcoming by using wireless communication.

Because we aim to use this device on a broad

range of consumer PCs as well as embedded systems,

Wi-Fi support is a top priority. At least in the United

States, Bluetooth isn’t supported by most laptops used

by consumers. Although in principle one could outﬁt

users with a USB-to-Bluetooth adapter, requiring the

user to manage two pieces of hardware (adapter and

token) would defeat our usability goals.

2 RELATED WORK

The use of PCs with handhelds has been seen as a way

to secure user input and output. The Pebbles project

uses a handheld as an additional user interface for a

PC (Myers, 2001), as does the Apple Remote Con-

trol (Apple, 2008). In “Bump in the Ether” (McCune

et al., 2006), the authors leverage trusted input and

output on the handheld to compensate for the possibil-

ity of malware on the PC. The authors of “Handheld

Computers can be Better Smartcards” (Balfanz and

Felten, 1999) similarly use the assumption of trusted

output on the handheld screen to allow the user to ver-

ify data before signing.

V. Bailey D., Brainard J., Rohde S. and Paar C. (2009).

ONE-TOUCH FINANCIAL TRANSACTION AUTHENTICATION.

In Proceedings of the International Conference on Security and Cryptography, pages 5-12

DOI: 10.5220/0002182400050012

 SciTePress

The “Zero-Interaction Authentication (ZIA)” pa-

per by Corner and Noble (Corner and Noble, 2002),

envisions a Wi-Fi token worn by users. That work

focuses on encrypting data held on the PC with the

keys supplied by the token as needed. This scheme re-

quires essentially continuous operation of the token’s

radio and processor leading to high power consump-

tion. The difference with our work illustrates our con-

tribution. The ZIA token uses ordinary Wi-Fi associ-

ation and UDP for data transmission and reception.

This exceptionally high duty cycle leads in practice to

a token with power consumption that is unacceptably

high. In addition, this design makes roaming difﬁcult:

in order for the PC to communicate both with Internet

services and the token, both would need to associate

and communicate through the same access point.

In a similar vein, in the “Zero-Stop Authentica-

tion” paper by Matsumiya, et al (Matsumiya et al.,

2005), the system designers aim to imbue the physical

environment with Wi-Fi radios and RFID readers to

automatically engage in a challenge-response proto-

col with the user’s cellphone or PDA. “Context-Aware

User Authentication” by Bardram, et al (Bardram

et al., 2003) also aims to combine location data into

an overall authentication decision.

A commercial offering from Ozmo, in collabo-

ration with the Intel Cliffside project, has been an-

nounced (Merritt, 2008). At the time of this writing,

little is known about how the system actually works.

From the available high-level description, their goals

are similar to ours: an alternative use of Wi-Fi for

point-to-point networking. Their solution requires

rewriting of network drivers; our solution needs only

application-layer software with no chipset-by-chipset

customization. Ultimately, Ozmo should be seen as

a complementary solution: we could use it for data

transmission and reception.

3 IMPEDIMENTS TO WI-FI USE

IN ONLINE BANKING TOKENS

The model of a standard PC using Wi-Fi communicat-

ing to an AP equipped with a backhaul connection to

the Internet is now ubiquitous among online-banking

customers worldwide, and we aim to devise a secu-

rity token consonant with this use case. This mode

of operation, called “infrastructure mode,” has the AP

intermediate all trafﬁc. As deﬁned in Section 7.2.2 of

(IEEE, 2007), even if two PCs are in close proxim-

ity, data frames are sent from the PCs to the AP to be

relayed, and never directly to one another.

IEEE 802.11 association

with data encryption

IEEE 802.11

shared medium

the token the PC

no simultaneous

Ad-Hoc sessions!

Figure 1: IEEE 802.11 communication limits.

3.1 Single-session Only

Wi-Fi offers “ad-hoc mode” in which two PCs may

directly communicate, but after testing a broad range

of wireless cards (ten different cards representing ﬁve

different chipset vendors) on Windows and Linux, we

found that none were capable of holding simultane-

ous ad-hoc and infrastructure mode sessions, as de-

picted in Figure 1. This fact means that for practical

purposes, a PC must communicate directly with the

token, or with the AP (and, by extension, the online

bank), but not both simultaneously.

3.2 Lengthy Wi-Fi Association Process

Unlike a PC, an authentication token is used infre-

quently, say to initially log in to the bank or to

sign a transaction. If a token must register to an

AP, a designer faces two unappealing choices: ei-

ther the token registers with the AP once and con-

tinuously runs its radio to remain registered during

the PC’s entire session, or the token automatically re-

registers on-demand. Re-registration introduces un-

acceptably long delays while the user waits for a re-

sponse. The other choice - continuously running the

radio - quickly drains the battery.

3.3 Key Distribution for MAC-layer

Security

The token could be provisioned with access creden-

tials to associate with the AP and complete 802.1X

authentication (hereafter, we’ll abuse the terminol-

ogy and refer to these two separate processes sim-

ply as “registration”) just like the PC. Unfortunately,

the registration process varies among APs, which be-

comes particularly problematic among mobile bank-

ing users who may use fee-for-service hotspots. Some

use a static WEP/WPA passphrase which would need

to be manually entered into the token, defeating our

usability goals. Others use 802.1X, for which a user-

name and password would be required. Still others

rely on an IPSec VPN.

SECRYPT 2009 - International Conference on Security and Cryptography

3.4 Our Contribution

To enable bidirectional communications in the token,

we propose the use of side channels to simulate si-

multaneous sessions, independent of Wi-Fi associa-

tion or MAC-layer encryption, as depicted in Figure

2. We will propose a number of unidirectional side

channels which may be used together to implement

cryptographic protocols with a sharp application fo-

cus on online banking. The side channels will be con-

structed by ﬁnding ways to tunnel security-protocol

data through standard 802.11 frames.

IEEE 802.11 association

with data encryption

IEEE 802.11

shared medium

sidechannel

communication

the token the PC

forward channel

back channel

Figure 2: Our design.

4 BRIEF SURVEY OF ONLINE

BANKING AUTHENTICATION

Several major approaches to user authentication for

online banking are currently in use. User acceptance

and a bank’s tolerance for fraud typically guide these

procurement choices. In this section, we survey the

major authentication mechanisms in use with banking

websites. We focus on the susceptibility to protocol-

level attacks as well as usability characteristics.

4.1 The Threat

Strong user authentication is a critical component of

an online banking application. The failure of the

user authentication component can allow an attacker

to perform an account takeover attack. In this form

of online fraud, the attacker steals login credentials,

such as passwords and proceeds to log into a legiti-

mate user’s banking account. Afterward, the attacker

can steal by transferring money to his own account.

This attack is so proﬁtable in the real world that crim-

inals have evolvedsophisticated organizationsto steal

and evade detection and prosecution.

4.2 Static Passwords

Despite widespread shortcomings, the static password

remains quite common for online banking, especially

in the United States. The main attractions are clear:

very low-cost provisioning and no need for the user

to carry another device. The downsides, however, are

well-documented. Passwords can often be guessed by

the adversary or obtained through social engineering.

Phishing attacks result in a perfect clone of a static

password. In their most familiar form, these amount

to a bogus-website attack. The attacker assembles a

website that looks similar to that of a legitimate bank.

Then the attacker sends mass emails enticing users

to visit the fake website and provide their password

which can be later replayed. Each of the major al-

ternative approaches to online banking authentication

aims to disrupt this protocol attack and strike a subtle

balance between usability and security.

4.3 TAN Lists

An alternative is for the bank to supply the user with

a printed list of passwords called a Transaction Au-

thentication Number (TAN) List. This numbered list

of one-time passwords allows a form of challenge-

response protocol: the bank website asks the user for

a password located at a random position on the list

with each challenge used only once.

At the protocol level, introducing a security arti-

fact - even one as simple as a list of passwords - in-

troduces a potential attack vector. If the user leaves

the list unattended, an attacker can clone it using a

photocopier and return the original intact to the user.

Relying on physical possession to deter cloning

is an improvement in practice over the cloning resis-

tance of a static password which often can be sim-

ply guessed. Moreover, it thwarts the most common

phishing attacks since the adversary does not know

which password the server will request on the next

called active, spear-phishing, or man-in-the-middle

(MITM) attacks still succeed (Parno et al., 2006). In

these scenarios, the attacker intercepts the password

and replays it to the bank in real time.

The list of passwords also harms usability. With-

out the password list, the user cannot log in. For

online banking, any decrease in usability means less

business transacted online, translating into less proﬁt

for the bank. If measures to increase security harm

usability, few banks are interested.

4.4 Handheld OTP Tokens

Traditional handheld one-time password (OTP) to-

kens are today available from commercial vendors. In

general, these are handheld devices with a small LCD

that shows changing passwords. Standardization has

ONE-TOUCH FINANCIAL TRANSACTION AUTHENTICATION

begun in the IETF, including (M’Raihi et al., 2005;

M’Raihi et al., 2008a; M’Raihi et al., 2008b). Unlike

a printed password list, the device throttles the dis-

play of passwords either using an internal clock or a

button, making it harder to clone. MITM attacks can

still succeed, as the adversary can intercept a pass-

word and instantly replay it to the website.

An OTP token is still an artifact that must be car-

ried by the user, who in turn must transcribe digits

into the PC – both harming usability.

4.5 Keypad Signing Tokens

The MITM attacks on OTP tokens are a product of

the lack of direct linkage between the generation and

consumption of passwords. Authenticating the user

only at login time means that a MITM attacker can in-

tercept and instantly replay passwords. Once logged

in, the attacker can fraudulently transfer funds. To tie

passwords directly to ﬁnancial transactions (instead

of user sessions), some tokens are equipped with key-

pads to accept external inputs. The user enters trans-

action details like transaction ID, account numbers,

transaction amount and/or random challenge directly

into the token. In response, the signing token uses

a symmetric key shared with the server to compute

and display a truncated message authentication code.

The user then enters the message authentication code

into the PC which relays it on to the banking server.

Observe that relying on the user to transcribe digits

in this way offers a protocol advantage: she has an

opportunity to validate the transaction details. If an

attacker tries to introduce say a fraudulent account

number or transaction amount, the user can recog-

nize this fact and decline to enter it into the token.

Merely intercepting the resulting authentication code

does not allow the attacker to fraudulently transfer

funds. Modifying the account number would invali-

date the authentication code. Unfortunately, this im-

4. user types OTP

3. user reads OTP

2. user types challenge

1. user reads challenge

Figure 3: Keypad signing token.

proved protocol performance comes at the price of re-

duced usability. If users already complain about tran-

scribing six-to-eight digit passwords, then transcrib-

ing digits from the PC to the token and back for each

transaction is even worse.

4.6 Smart Cards

Smart cards offer a bidirectional machine interface in

a set of electrical contacts. Because smart-card read-

ers are not standard equipment on most PCs, the user

must keep track of two pieces of hardware: card and

reader. This requirement makes it difﬁcult to log in

away from home or ofﬁce, such as at a kiosk. But like

the signing tokens, one can authenticate transactions

to thwart network-based MITM attacks.

The direct PC data-interface, however, leads to a

lack of direct agency on the part of the user and a new

MITM vulnerability, described as the “rogue termi-

nal” problem in (Schneier and Shostack, 1999). The

potential avenue for attack lies in the lack of trusted

I/O between the smart card and the user. In contrast

to our previous MITM where the attacker is active on

the network, here the attacker is active on the PC-to-

smart card channel. For instance, malware on the PC

could display the user’s requested transaction details

while providing fraudulent details to the smart card

for signature. A standard countermeasure is to collect

a PIN from the user, but unfortunately if malware is

present on the PC, it can intercept and replay the PIN.

To thwart this attack one needs a direct interface

on which the user can conﬁrm transaction details be-

fore a signature is computed. Some banks provide

a smart-card reader with keypad and display for this

purpose, but this is expensive and requires the user to

manage two pieces of hardware. Nevertheless, smart

cards are often engineered to resist certain forms of

physical and side-channel attack, which is more difﬁ-

cult with our software-only solution.

5 THE TOKEN-PC “FORWARD

CHANNEL”

Our solution aims for the same protocol security as

the smart card solution, but using only PC and mo-

bile phone software. In addition, the user should have

these protocol guarantees without typing digits.

By exploiting different frames, we will construct

two unidirectional channels: one from the token to

the PC which we call the “forward channel,” and a

channel from the PC to the token which we call the

“back channel.” We assume the PC runs Windows

XP or Vista and is already using its Wi-Fi adapter

in an infrastructure session. There are three possible

token conﬁgurations: those capable of neither moni-

tor mode nor packet injection; monitor mode but not

packet injection; and both monitor mode and packet

injection. We will treat two possible cases for the to-

ken: those capable of both monitor mode and packet

SECRYPT 2009 - International Conference on Security and Cryptography

injection and those capable of neither, as we believe

these are the two most common cases in practice.

The token-to-PC forward channel does not require

any special modes of Wi-Fi and may therefore be im-

plemented on any device. To construct the forward

channel, we exploit the methods by which 802.11

clients determine which wireless networks in range

offer service. Both APs and ad-hoc network partici-

pants advertise their existence by sending out beacon

frames, which are unsolicited management frames

sent to the broadcast address; and probe response

frames, which are sent in response to probe frames

sent out by stations seeking access points.

These two data paths deﬁne two different meth-

ods for a PC to obtain information about nearby APs:

passive scanning, wherein a station merely listens for

beacons, and active scanning where a station sends

probe requests and listens for probe responses. Pas-

sive scanning is used in the popular Kismet wireless

network-detection software (Kershaw, 2004). Like

Kismet, our experiments conﬁrmed that few network

adapters are capable of passive scanning on Win-

dows, with most only supporting active scanning, and

none supporting only passive scanning. Building a

widely-usable forward channel thus requires using ac-

tive scanning on the PC. We wrote a simple user-mode

PC application that scans for APs, sending out probe

requests and listening for probe responses.

A probe response frame contains the 32-byte

SSID ﬁeld, which typically indicates the natural lan-

guage name of a network. The SSID ﬁeld can be

given an arbitrary value and still be propagated un-

molested up the protocol stack by commodity 802.11

hardware and Windows drivers.

After testing different Wi-Fi PC adapters (from

Linksys, D-Link, Belkin, Hawking, Netgear, and

Intel) with different chipsets (from Prism, Ralink,

Atheros, Broadcom, and Intel), we found that only

the SSID ﬁeld can be reliably received by the PC in

this way. Other ﬁelds we tested were unsuccessful.

Vendor speciﬁc ﬁelds of up to 255 bytes can also be

appended to probe response frames and used to carry

authentication data. Unfortunately, one adapter only

reported the ﬁrst 240 bytes and others did not report

these other ﬁelds at all.

Because of these limitations, our authentication

token thus sends messages by essentially advertising

itself as an ad-hoc network participant, sending out

beacon frames and probe response frames upon acti-

vation with the SSID ﬁeld set to the base-64 ASCII

encoding of the cryptographic message. The SSID

ﬁeld identiﬁes the frame as part of the authentication

protocol using the “;” character (an arbitrary choice)

and carries the cryptographic payload necessary to au-

thenticate the token to the PC. Software on the PC

continuously searches for access points and ad-hoc

network participants; when one is found whose SSID

begins with the “;” character, it delivers the crypto-

graphic payload to security applications. The delay

from when the prototype begins to advertise the ad-

hoc network to the time the payload is passed to ap-

plication software on the mobile varies depending on

what 802.11 chipset and driver is used on the mobile.

We experimented the most with a Belkin F5D7050

ver. 3; using it, the delay is around three seconds.

The SSID ﬁeld is at most 32 bytes long; the “;”

character consumes one byte leaving 31 bytes. This

is a very small payload, but much larger than user-

transcribed OTPs which amount to around 33 bits.

For fragmented messages, the token can masquerade

as multiple access points simultaneously.

6 THE PC-TOKEN “BACK

CHANNEL”

Once associated with an AP using MAC-layer encryp-

tion, the operating system does not offer an API to

enable or disable encryption on a frame-by-frame ba-

sis. For this reason, application software running on

the PC cannot directly send cryptographic challenges

or transaction details in data frames that can be read

by the token. Because the token does not have the

MAC-layer encryption keys, even if its drivers sup-

port monitor mode, the best the token can hope for is

to intercept encrypted frames, shown in Figure 2.

Regardless of the type of MAC-layer encryption

in use, the token can expect to observe some prop-

erties of the encrypted data frames. In particular,

the size of data frames can be seen by an adapter in

monitor mode. In addition, Wi-Fi encryption is ap-

plied only to the data payload of a frame and not to

its headers. Fortunately, Wi-Fi interfaces provide the

ability to set certain unencrypted header ﬁelds from

application-layer software. In this section, we will

explore the use of these side-channels to construct

a back channel from the PC to the token to deliver

challenge or transaction details. The token must be

capable of monitor mode operation in order to use

one of these back channels. Personal wireless devices

including the Nokia Internet Tablet offer this feature

and naturally any purpose-built token would as well.

6.1 The MAC-Channel

Because the PC usually is already engaged in an in-

frastructure session – and most chipsets are single-

session only – its Wi-Fi stack is not able to di-

ONE-TOUCH FINANCIAL TRANSACTION AUTHENTICATION

rectly address the token. Using only application-layer

software to create explicitly malformed Ethernet-II

frames, a PC using Windows or Linux can be tricked

to set certain header ﬁelds of the IEEE 802.11 proto-

col to arbitrary values, allowing us to create a side-

channel that can be received by any phone or wireless

device with monitor-mode capability. These frames

can therefore be used as a side channel to transfer data

out of a Wi-Fi network.

6.2 The Length-Channel

The other option for the PC to transport data to the

token is to use the lengths of packets as a side chan-

nel. This alternative approach is valuable in cases

where the operating system does not easily support

the MAC-Channel, or could be combined with the

MAC-Channel to increase throughput. A simple en-

coding is used to translate the data into a sequence of

packet lengths. n distinct packet lengths provide an

entropy of e = log

(n) bits of information. Sending

one packet of length l

with i = 1..n will transport e

bits of information.

7 IMPLEMENTATION

The forward channel is compatible with every driver

and chipset combination we tested. By contrast, the

backchannels require the token to operate in mon-

itor mode – only available for certain driver and

chipset combinations. Nevertheless, the proliferation

of Linux in personal wireless devices makes moni-

tor mode available in mainstream devices such as the

Nokia Internet Tablet N810. Our token implementa-

tion was tested on both a Linux PC and the N810. The

implementation relies on a specialized library called

Lorcon (LORCON, 2008) to support monitor mode.

It also provides helper methods to support injection

of raw 802.11 packets.

7.1 The SSID Channel from Token to

From the point of view of software running on the

token, there are two possible ways to establish a side

channel using the SSID ﬁeld. The ﬁrst is to let the net-

work interface act as a regular access point. We exper-

imented with the Belkin F5D7050 Version 3 adapter,

which uses the Ralink RT73 chipset, and the Atheros-

based Netgear WG511T adapter. We found that the

driver (MadWiﬁ, 2008) for the Atheros-based card is

natively capable of emulating two access points si-

multaneously, but more lead to a kernel crash. To em-

ulate more access points, the implementation resorts

to packet injection. Section 8.1 elaborates on the per-

formance impact of simultaneous SSIDs. The SSID

ﬁeld can transport 32 bytes. Because some drivers

have difﬁculty with non-ASCII characters, the token

uses base64 encoding. As previously mentioned, the

ﬁrst character is “;”. The second is a monotonically

increasing packet counter, necessary for the recon-

struction of fragmented messages and detection of

lost fragments. The token software responds directly

to 802.11 probe requests and sends out beacons. Each

virtual access point is announced for ﬁve seconds so

the software on the PC has a chance to receive data.

The receiving part of the SSID channel on the PC

uses the wireless API introduced in Windows Vista

and Windows XP SP3 to listen continuously for new

networks. If new networks match the discriminator,

they are accepted and if necessary, defragmented.

7.2 The Length Channel from PC to

Token

As described in Section 6, the length of packets trans-

ferred over the wireless interface is used to encode

information. Therefore the PC needs to be able to

send packets and control their length which can eas-

ily be done by using the library libnet(Libnet, 2008)

which in turn relies on WinPCap(WinPcap, 2008).

The receiving part for the token only needs to look

at the length of certain encrypted packets. The re-

cipient has no direct way to distinguish side-channel

packets from those that are created through regular

network trafﬁc. However, by reserving certain packet

lengths to serve as start-of-blockand end-of-block de-

limiters, one can decrease the likelihood of misinter-

preted packets. This sequence also has some basic en-

coding to detect if some packets have been falsely in-

terpreted. The data is divided into ﬁxed-length blocks.

Every n bits of every block is encoded into one out of

e = 2

packet lengths. To provide ﬂow control, the

encoded blocks are surrounded by packets of length

corresponding to the reserved start- and end-of-block

values. By counting the number of packets in a block,

the PC can detect either extraneous or lost packets.

One could apply sophisticated codes to detect and

repair errors; our purpose here is merely to imple-

ment and report on the basic channel characteristics

to which coding could be applied.

7.3 The MAC Channel

The basic mechanism of the MAC Channel is compar-

atively simple. The sending part forges raw Ethernet

SECRYPT 2009 - International Conference on Security and Cryptography

II frames through the libnet packet factory. The des-

tination ﬁeld of the protocol header is used to encode

data, providing six bytes of data per packet. In addi-

tion the packets are sent with only one byte of pay-

load. The Windows networking stack in conjunction

with the appropriate drivers will just translate these

ﬁelds into the corresponding IEEE 802.11 data ﬁelds.

This results in a very unusual packet length which

is used to distinguish these side-channel packets from

other network trafﬁc. To avoid problems caused if

the destination matches an existing MAC address the

Ethernet II protocol ﬁeld is set to an invalid value.

7.4 Experimental Setup

The Nokia Internet Tablet N810 is capable of pro-

viding the SSID channel and monitor mode without

modiﬁcations, but not arbitrary wireless packet injec-

tion – which yields higher performance. For this fea-

ture we turn to an external USB Wi-Fi adapter. The

N810 development kit includes the complete kernel

source which in turn allows one to easily compile the

RT73 open source driver (RT73, 2008) for the Belkin

FD5D7050 Version 3 Wi-Fi USB adapter. Because

the USB port of the tablet only provides a limited

amount of current, we also use a powered USB hub

between the N810 and the Wi-Fi adapter. We use this

hardware setup to measure the channel performance

by sending a ﬁxed amount of data through the various

side channels.

8 PERFORMANCE

MEASUREMENTS

This section reports on channel delay, throughput and

the loss rate of the proposed side channels. The chan-

nel delay is measured by comparing the time when

data is sent and the time when data arrives. Because of

the amount of time needed by the PC to scan for APs,

it is around one to four seconds for the SSID channel.

The delay for the other channels is close to the delay

of the wireless channel itself as only a few ordinary

packets are needed to deliver data to the channel’s

user. The loss rate is the percentage of bytes lost in

transmission. Throughput denotes the number of un-

compressed bytes per second and the loss rate gives

information about the reliability of the channel. Table

1 shows the results. In the “No other trafﬁc” scenario,

we made no effort to generate additional load on the

AP. For the “Multiple YouTube Video Downloads”

scenario, we launched four simultaneous downloads

to generate some trafﬁc with which the side channels

would have to compete. Finally, for the “SMB File

Table 1: Channel Performance with n

SSID

= 4 and e = 8.

Channel Throughput (bytes/s) Loss Rate

No other trafﬁc

SSID-Channel 19 0.0%

Length-Channel 80 7%

MAC-Channel 2159 1%

Multiple YouTube Video Downloads

SSID-Channel 10 40%

Length-Channel 32 19%

MAC-Channel 1754 7%

SMB File transfer

SSID-Channel 8 50%

Length-Channel 30 20%

MAC-Channel 281 10%

Table 2: SSID Channel Parameter Evaluation.

Channel Throughput (bytes/s) Loss Rate

No other trafﬁc

SSID

= 4 19 0.0%

SSID

= 8 40 0.0%

SSID

= 16 85 0.0%

SSID

= 32 195 0.0%

Transfer,” we initiated a large ﬁle download. In each

scenario, we averaged over four experiments.

8.1 Channel Parameters

The SSID and Length channel provide conﬁguration

options to change the behavior of the channel. The

SSID channel can be conﬁgured by setting the max-

imum number n

SSID

of simultaneously used SSIDs;

each is transmitted for ﬁve seconds. Unfortunately

the increased speed offered by simultaneous SSIDs

comes at a price: large numbers of virtual access

points may confuse both the end-user and the net-

working stack of their PCs. Table 2 shows how n

SSID

affects the channel characteristics.

The length channel can be conﬁgured by the num-

ber of distinct packet lengths n that are used. Be-

sides some overhead the performance is theoretically

proportional to the bits of information e = log

(n)

that are encoded in one packet length. For sim-

plicity we measured e = 2, 4, 8 yielding (together

with one delimiter) 5, 17, 257 distinct packet lengths.

The throughput can be increased by choosing shorter

packet lengths. We chose packet lengths starting from

500 bytes because due to Lauradoux (Lauradoux,

2007) they are very uncommon in normal TCP trafﬁc

and therefore less likely to be mistaken for ordinary

network trafﬁc. In addition, it eases the burden on the

decoder: the packet lengths represent two bits, four

ONE-TOUCH FINANCIAL TRANSACTION AUTHENTICATION

Table 3: Length Channel Parameter Evaluation

Channel Throughput (bytes/s) Loss Rate

No other trafﬁc

e = 2 22 17%

e = 4 46 13%

e = 8 80 7%

bits, and eight bits respectively. The channel char-

acteristics for the parameterized length channel can

be found in Table 3. The loss rate decreases with an

increasing number of lengths because the number of

packets sent per data frame is decreased.

9 CONCLUSIONS

By necessity, authentication tokens have tradition-

ally implemented one-way cryptographic protocols.

Expanding the data channel beyond digits typed by

a human expands both the possibilities and risks.

Fast bidirectional communicationfurther ups the ante,

allowing ﬁne-grained data-origin authentication and

document signing with a robust human interface in-

cluding sensors, biometrics, and other complemen-

tary authentication factors. These robust functions

must continue to be balanced against the severe

power consumption constraints in mobile devices. We

leave the protection of the token-PC link for future

work. Careful modeling of authentication and key-

distribution (pairing) protocols is needed.

REFERENCES

Apple (2008). About the apple remote control. Available at

http://support.apple.com/kb/HT1522.

Balfanz, D. and Felten, E. (1999). Hand-Held Computers

Can Be Better Smart Cards. 8th USENIX Security

Symposium, 271.

Bardram, J., Kjær, R., and Pedersen, M. (2003). Context-

Aware User Authentication–Supporting Proximity-

Based Login in Pervasive Computing. Proceedings

of Ubicomp, pages 107–123.

Corner, M. and Noble, B. (2002). Zero-interaction au-

thentication. Proceedings of the 8th annual interna-

tional conference on Mobile computing and network-

ing, pages 1–11.

IEEE (2007). IEEE 802.11-2007. IEEE standard for infor-

mation technology–telecommunications and informa-

tion exchange between system–local and metropolitan

area networks speciﬁc requirements–part 11: Wire-

less LAN medium access control (MAC) and physical

layer (PHY) speciﬁcations.

Kershaw, M. (2004). Kismet. Referenced 2008 at

http://www.kismetwireless.net/presentations/5hope-

kismet.pdf.

Lauradoux, C. (2007). Throughput/code size tradeoff for

stream ciphers. The State of the Art of Stream Ciphers

- SASC.

Libnet (2008). The libnet packet construction library. avail-

able at http://www.packetfactory.net/libnet/.

LORCON (2008). Lorcon (loss of radio connectivity).

available at http://802.11ninja.net/lorcon.

MadWiﬁ (2008). Madwiﬁ wlan driver. available at

http://madwiﬁ.org/.

Matsumiya, K., Aoki, S., Murase, M., and Tokuda, H.

(2005). A zero-stop authentication system for sensor-

based embedded real-time applications. J. Embedded

Comput., 1(1):119–132.

McCune, J. M., Perrig, A., and Reiter, M. K. (2006). Bump

in the ether: A framework for securing sensitive user

input. In Proceedings of the 2006 USENIX Annual

Technical Conference, page 185198.

Merritt, R. (2008). Wi-ﬁ jumps into the pan. EETimes,

June 6th, 2008. Available at http://www.eetimes.com/

news/latest/showArticle.jhtml?articleID=208401238.

M’Raihi, D., Bellare, M., Hoornaert, F., Nac-

cache, D., and Ranen, O. (2005). Hotp:

An hmac-based one-time password algorithm.

http://www.ietf.org/rfc/rfc4226.txt.

M’Raihi, D., Machani, S., Pei, M., and Rydell, J.

(2008a). Totp: Time-based one-time password

algorithm. http://www.ietf.org/internet-drafts/draft-

mraihi-totp-timebased-00.txt.

M’Raihi, D., Rydell, J., Naccache, D., Machani, S., and

Bajaj, S. (2008b). Ocra: Oath challenge-response

algorithms. http://www.ietf.org/internet-drafts/draft-

mraihi-mutual-oath-hotp-variants-07.txt.

Myers, B. (2001). Using handhelds and PCs together. Com-

munications of the ACM, 44(11):34–41.

Parno, B., Kuo, C., and Perrig, A. (2006). Phoolproof

Phishing Prevention. LECTURE NOTES IN COM-

PUTER SCIENCE: Tenth Financial Cryptography

and Data Security Conference, 4107.

RT73 (2008). The rt73 driver homepage. available at

http://rt2x00.serialmonkey.com/.

Schneier, B. and Shostack, A. (1999). Breaking Up is Hard

to Do: Modeling Security Threats for Smart Cards.

USENIX Workshop on Smartcard Technology.

WinPcap (2008). Winpcap: The windows packet capture

library. available at http://www.winpcap.org/.

SECRYPT 2009 - International Conference on Security and Cryptography