Bringing strong authentication and transaction security to the realm of mobile devices

Bringing strongauthentication andtransaction security to therealm of mobile devices

D. A. Ortiz-YepesR. J. HermannH. Steinauer

P. Buhler

Widespread usage of mobile devices in conjunction with malicioussoftware attacks calls for the development of mobile-device-orientedmechanisms aiming to provide strong authentication and transactionsecurity. This paper considers the eBanking application scenarioand argues that the concept of using a trusted companion device canbe ported to the mobile realm. Trusted companion devices involveestablished and proven techniques in the PC (personal computer)environment to secure transactions. Various options for thecommunication between mobile and companion devices arediscussed and evaluated in terms of technical feasibility, usability,and cost. Accordingly, audio communication across the 3.5-mmaudio jackValso known as tip-ring-ring-sleeve, or TRRSconnector,Vis determined to be quite appropriate. We present aproof-of-concept companion device implementing binary frequencyshift keying across this interface. Results from a field study performedwith the proof-of-concept device further confirm the feasibilityof the proposed solution.

IntroductionMobile devices (MDs) such as smart phones and tabletsare increasingly used for personal and business-relatedtasks. Many applications that have traditionally beenused on PCs (personal computers) are nowadays expectedto run on MDs. This trend is extending toVor alreadyincludesVsecurity-sensitive applications such as eBanking,the main application domain considered in this paper.This trend has not gone unnoticed by cyber criminals, andtheir attack efforts have accordingly shifted to MDs [1].The complexity of today’s MDs is approaching that oftraditional PC platforms in terms of operating systemsoftware, services, applications, and communicationinterfaces, which increases their attack surface.Correspondingly, their vulnerability to cyber-attacks isvastly higher than that of MDs a decade ago. While mobilephones have beenVand still areVused to secure eBankingexecuted on PCs via techniques such as mTAN (mobiletransaction authentication number), their capabilities and

vulnerabilities have enabled coordinated attacks acrossPCs and MDs, defeating the effectiveness of these securitymechanisms. Malware simultaneously executing on a user’sPC and MD is capable of covertly manipulating thetransaction details entered by the user on the PC andsimultaneously stealing the corresponding mTAN that thebank sends via SMS (Short Message Service) to the user’sMD to confirm the transaction. The stolen mTAN is thenused to confirm the manipulated transaction. Eurograbber,a variant of the Zeus Trojan-horse malware, has reportedlymanaged to steal $47 million (U.S.) from more than30,000 accounts in Europe [2]. Further evidence ofmalware in MDs and its consequences can be found inthe academic literature, e.g., [3, 4]; security vendor studies,e.g., [1, 2, 5, 6]; reports from the press [7, 8]; and publicwarnings from the police [9]. The coordination andsophistication required to perform such attacks will onlybecome even simpler, given the emerging scenario ofusers executing their eBanking from their MDs.The business value of eBanking, as well as of many

other security-sensitive applications, is directly relatedto the fact that they can be accessed by customers from

�Copyright 2014 by International Business Machines Corporation. Copying in printed form for private use is permitted without payment of royalty provided that (1) each reproduction is done withoutalteration and (2) the Journal reference and IBM copyright notice are included on the first page. The title and abstract, but no other portions, of this paper may be copied by any means or distributed

royalty free without further permission by computer-based and other information-service systems. Permission to republish any other portion of this paper must be obtained from the Editor.

D. A. ORTIZ-YEPES ET AL. 4 : 1IBM J. RES. & DEV. VOL. 58 NO. 1 PAPER 4 JANUARY/FEBRUARY 2014

0018-8646/14 B 2014 IBM

Digital Object Identifier: 10.1147/JRD.2013.2287810

general-purpose devices that users own or are providedwith by a third party, e.g., their employers. Familiarity withthe user interfaces of those devices boost usability andconvenience, but their trustworthiness is questionableowing to their general-purpose nature. In other words, it isdifficult to ensure that the information, which is enteredby the user on the device and intended for the server, is whatthe server actually receives, and that the information sentby the server to be shown to the user is in fact what she sees.Particularly, if the device has been compromised by anattacker, any information entered by the user can be changedbefore it is sent to the server. Similarly, information receivedfrom the server can be altered before it is actually shownto the user on the device’s screen.In this paper, we present a proof-of-concept

implementation, which we have developed, of asecurity mechanism providing strong (dynamic andhard-token-based) authentication and transaction securityfor eBanking on MDs. We shall refer to this implementationasMobile ZTIC (MZTIC), as the work is a direct extension ofprevious work on the ZTIC (the Zone Trusted InformationChannel) [10]. Section 2 of this paper introduces ZTIC,reviews its basic working principles (as they will equallyapply to MZTIC), and explains what is needed to evolveZTIC to MZTIC. Section 3 explores some communicationinterfaces that can be used to achieve a link betweenMZTIC and the eBanking server. Section 4 describesour proof-of-concept MZTIC using the audio channel.Section 5 discusses related work, and Section 6 concludes.

From ZTIC to Mobile ZTICThe fundamental concept of the ZTIC is used by severalbanks to ensure that their eBanking services can be securelyused from PCs [10, 11]. In this section, we review the ZTICdevice and its operation in a typical eBanking scenario.We then revisit the objectives originally formulated for theZTIC, extending and discussing them in the context of theMZTIC. Next, we outline how the ZTIC concept can beadapted to achieve the same level of security for MDs.

ZTICThe ZTIC provides a physically separate trusted andtamper-evident secure communication endpoint. The ZTICis a device about the size of a memory stick consisting ofa system-on-chip (SoC) controller, an embedded display, twobuttons (confirm/cancel), a rotary wheel, a smart card reader,and a USB (Universal Serial Bus) device interface.The ZTIC firmware consists of a hardware-abstraction

layer (HAL) wrapping the drivers for the display, buttons,rotary wheel, smart card reader, and USB interface. On topof the HAL, service componentsVsuch as a Transport LayerSecurity (TLS) engine, custom file system (CFS), graphicsengine, and secure persistent storeVprovide the buildingblocks for the application logic. The ZTIC firmware

implementation is designed to forgo the use of an embeddedoperating system in order to minimize the complexity ofthe trusted computing base.When connected to a PC, the ZTIC presents itself as a

USB mass storage device (MSD). The CFS hosts two files:a read-only ZTIC Proxy executable, which can be run onthe PC, and a file enabling the execution of the proprietaryprotocol between the ZTIC Proxy and ZTIC via read/writeoperations. Any other operations on the CFS are ignored,in particular, any attempts to create or delete files. Asa result, attacks on the ZTIC via its external interfaceare infeasible.The ZTIC is capable of establishing TLS end-to-end

communication sessions to the server, which protects againstphishing [12], man-in-the-middle (MITM) attacks [13], andmalware such as man-in-the-browser (MITB) attacks [12].The TLS sessions can be used to securely interact withsecurity-critical remote services, such as application services(e.g., an eBanking service) and maintenance services(e.g., provisioning of new firmware and/or certificates).From a data-flow point of view, there are two possible modesof operation: side-stream and in-stream. With side-streamoperation, application data is exchanged via two logicallyseparate paths: the TLS session between PC and remoteserver, and the TLS session between ZTIC and remoteserver. When the application enters a security-criticalpart, such as the confirmation of a transaction, the serveruses the TLS session to the ZTIC to interact with the user.With in-stream operation, all application data is exchangedvia TLS sessions ending in the ZTIC, with any partsconcerning the application running on the PC beingforwarded to the PC by the ZTIC, and any security-criticalparts retained and processed in the ZTIC. In the remainderof the paper, side-stream operation is assumed.The ZTIC adds strong authentication and authorization

as described in the following prototypical side-streamusage scenario, which is illustrated on the left-hand sideof Figure 1:

1. The user connects the ZTIC to her PC via the USBinterface and starts the ZTIC Proxy residing on theZTIC file system. The ZTIC Proxy relays data packetsbetween the ZTIC and the eBanking Server (EBS),providing the ZTIC with network connectivity.

2. The ZTIC Proxy commands the ZTIC to establish aTLS session with the EBS using mutual authenticationbased on server certificates previously provisionedto the ZTIC (pinned certificates). As the TLS sessionendpoints are the EBS and the ZTIC, eavesdroppingor purposefully manipulating the exchanges in the user’sPC or anywhere in the network is prevented.

3. The ZTIC requests the user to insert her eBankingsmart card into its smart card reader and to enter thesmart card PIN (personal identification number). Upon

4 : 2 D. A. ORTIZ-YEPES ET AL. IBM J. RES. & DEV. VOL. 58 NO. 1 PAPER 4 JANUARY/FEBRUARY 2014

correct PIN entry, the ZTIC opens a session to the cardand sends the card number to the server.

4. The browser establishes a TLS connection to the EBS.In contrast to the TLS session terminating in the ZTIC,this TLS session is vulnerable to locally or remotelyexecuted MITM attacks or locally executed MITB attacks.

5. The user performs the login operation via the browserinterface using her user ID. Then, the EBS sends a

challenge to the ZTIC, which prompts the user toapprove. Then, the ZTIC interacts with the smart card tocompute a response to the challenge and sends the resultback to the EBS. If the response validates, the EBSaccepts the eBanking application session from thebrowser and binds the two TLS sessions using the cardnumber and the user ID. Otherwise, it terminates bothsessions.

Figure 1

Operation of the ZTIC and the Mobile ZTIC (MZTIC) in a client-server architecture. Components, connections, and interfaces that are shaded in greenare trusted, whereas those shaded in red hues may be compromised by an attacker. As the user PC may be compromised, neither the connectionbetween the web browser and the eBanking server, nor what is shown on the PC display can be trusted. The connection between the ZTIC and theeBanking server cannot be compromised by the attacker because both endpoints are outside of his control. Therefore, the server can use the ZTIC toexplicitly ask the user to confirm the integrity of sensitive pieces of information received via the browser connection. In case of an attack, the user willnotice that the information that she entered on the PC does not match the information shown on the ZTIC, thus preventing the attack from completingsuccessfully. On the right-hand side of this figure, the PC has been replaced by the mobile device (MD), and an app is used instead of the browser. Thisis not required but is expected to be the preferred implementation on mobile platforms because it makes better use of the user-interface capabilities ofthese platforms. Like the PC, the MD is considered untrusted. If the connection interface between the Mobile ZTIC and the MD is sufficiently fast, adirect TLS connection between the Mobile ZTIC and the eBanking Server, as in the PC case, can be used. If such a connection takes place on top of aslow interface, we suggest securing the messages between these entities cryptographically using a bandwidth-saving message-oriented mechanism thatavoids the TLS handshake, which is expensive in terms of the amount of data (particularly certificate) exchanges. In either case, the server can use theMobile ZTIC to explicitly ask the user to confirm the integrity of sensitive pieces of information received via the untrusted connection to the MD. Incase of an attack, the user will notice that the information she entered on the MD does not match the information shown on the Mobile ZTIC, thuspreventing the attack from completing successfully.


6. When the user submits a transaction via the eBankinginterface of the browser, the EBS extracts the relevanttransaction details and sends them to the ZTIC foruser authorization, which involves displaying thetransaction details on the ZTIC display and asking theuser to verify them. If the user agrees and presses theconfirm button, a cryptographic signature is computed onthe smart card and sent back to the EBS as evidenceof the user’s acceptance. If the user notices a discrepancybetween the transaction details entered via the browserand those displayed on the ZTIC, she presses the cancelbutton, which is reported to the EBS and aborts thetransaction.

Malware might eavesdrop and even attempt to manipulatebank transfers submitted by the user, but these would bedetected during the authorization step (6). In particular,it is impossible for the attacker to mask his manipulationsin the authorization request sent from the EBS to the ZTIC,because any such attempt would break the TLS connectionand implicitly abort the transaction.For PIN entry, several mechanisms exist that vary in terms

of security versus usability: the safest is PIN entry on theZTIC using the rotary wheel. Alternatively, a scheme couldbe used where the user encrypts her PIN and enters it onthe PC. At each occasion, she uses a different substitutioncipher, whose code table is displayed on the ZTIC [14].As another alternative, the PIN can be entered directly on theuntrusted PC, which exposes its secrecy, but its use mustbe explicitly approved by the user by pressing the confirmbutton on the ZTIC.On the right-hand side of Figure 1, the PC has been

replaced by the MD, and an app is used instead of thebrowser. This is not required, but is expected to bethe preferred implementation on mobile platforms as it makesbetter use of the user-interface capabilities of these platforms.The MZTIC is described more fully in the forthcomingsection titled BMobile ZTIC.[

Security objectivesThe main goal is to provide strong authentication of entitiesand information exchanged between them in the presenceof a local active attacker capable of compromising the PC orthe MD. This implies that any ongoing attack can be detectedby the user and the operation interrupted and aborted priorto any damage occurring. In other words, the attack is noteliminated, but it is prevented from running to successfulcompletion. This main goal can be decomposed into thefollowing set of objectives, which consider the user (U)accessing the server (S):

1. User authentication: S can ensure that U is actuallyU and not U0, with U0 being an attacker trying toimpersonate U towards S.

2. Server authentication: U can ensure that S is actuallyS and not S0, with S0 being an attacker trying toimpersonate S toward U.

3. Integrity of sensitive messages S ! U : If S sends asensitive piece of information ISU to U, and U receivesI0SU, then ISU ¼ I0SU.

4. Integrity of sensitive messages U ! S: If U sends acertain piece of sensitive information IUS to S via hercomputing device, and S receives I0US, then IUS ¼ I0US.

5. Freshness of messages: Messages are structured in away that enables the recipient to detect whether thesame message IUS or ISU has been sent more than once.

In the case of the ZTIC, User Authentication is achievedby requiring the user to enter a PIN to unlock the smartcard credentials involved in the log-in operation. ServerAuthentication is achieved by the validation of the servercertificate taking place on the ZTIC. Integrity of sensitivemessages S ! U and Freshness of messages follow from theintegrity and freshness properties of the TLS connectionbetween the ZTIC and the server. Integrity of sensitivemessages U ! S is achieved by letting the server show I0USon the ZTIC display for the user to ensure that it matches IUS.

Further objectivesAside from security, convenience and usability are alsoimportant when developing a security mechanism [15, 16].Specifically, the operation needs to be easy and must havea straightforward interaction pattern.Asking the user to carry and handle an additional device

to achieve the desired level of security is challenging.Care must be exercised to make the companion deviceergonomic. Absolute and relative size matters: it cannotbe expected that users carry a companion device thesize of the MD. A good and sufficiently large displayreadable under daylight conditions is imperative. It shouldaccommodate the validation of security-relevant transactioninformation without needing to scroll. As the user mustalternate between the MD and the companion device, it isdesirable that the companion device attaches itself firmlyto the MD in such a way that the user does not need to holdit and that its display is always readable. Such attachmentmust be mechanically stable, avoiding a device that danglesfrom the MD. The orientation of the displayed content shownin the companion device should match that of the MD.Ideally, the companion device should be visually appealing,and feel robust and of high-quality build.Finally, for the device to be successful in the market,

cost constraints must be met. Typically, the user will obtainthis companion device from her bank for free or at reasonablecost. In either case, there is considerable pressure from thebank to keep device cost low. In the first case, the cost tothe bank for offering a solution scales linearly with thenumber of clients using Internet banking. In the second case,


it is also in the bank’s interest to offer the device at a pricethat will be widely accepted by clients for the benefit ofincreased security and usability.

Mobile ZTICSecurity-sensitive operations performed on MDs deserve thesame level of protection as those performed on PCs, andtherefore the use of an additional trusted device like theZTIC is equally justified. As mentioned, the conceptof the ZTIC can readily be adapted for MDs, as illustratedon the right-hand side of Figure 1. There we show anarchitecture in which the Banking app handles bothconnections to the EBS. User interaction with the EBS isexecuted within that app by the Webview, and the relayfunction (provided in the PC by the ZTIC Proxy) isaccomplished by the ZTIC Handler. The fundamental courseof action during a user login or bank transfer operationremains as described above for the ZTIC, as does theintegration with the EBS.The crucial issue when bringing the ZTIC concept into the

MD realm lies in how the communication between the MDand the MZTIC is accomplished. The nature and qualityof service of this communication link directly impact thesecurity mechanisms that can be implemented on top ofit. For instance, it may not be feasible to run a TLSconnection on top of communication links that operateonly intermittently e.g., near field communication (NFC),or that offer limited bandwidth (e.g., on the order ofhundreds of bytes per second). In these cases, amessage-based security protocol must be used to ensureintegrity, authenticity and confidentiality of the dataexchanges between EBS and MZTIC. For instance, aprotocol relying on pre-shared keys using symmetriccryptography could be used.

Communication options for Mobile ZTICA bidirectional connection between MZTIC and EBS canbe established either directly or via the MD. A directconnection would offer the highest versatility because theMZTIC could be used with all MD models, even withtraditional PCs. Such a direct connection could be achievedby fitting the MZTIC with a WLAN (wireless local areanetwork) or cellular radio. In both cases, a dependence onsignal/network availability is a result. Also, the price of theseradios is in the range of tens of dollars, which is an orderof magnitude higher than the price of the most expensiveZTIC components. These radios would require the MZTIC tobe fitted with a large battery or for the user to frequentlyrecharge the battery, thus diminishing the convenience of themechanism. In the case of a WLAN connection, no recurringcosts arise, but configuring it on the MZTIC can becumbersome owing to the limited user interface of theMZTIC. A connection over the cellular data network requireslittle to no configuration, but would entail additional

recurring costs to be borne either by the user or theserver provider.Instead of a direct connection between MZTIC and EBS,

an indirect connection can be established through the MDas illustrated on the right-hand side of Figure 1. Such aconnection enables the Internet link of the MD to be reusedto reach the EBS. Thus, only a local communication linkbetween MZTIC and MD needs to be implemented. Inthe remainder of this section, we suggest and explorecandidate communication mechanisms.

USBVIncreasingly, MDs have USB host or USBOn-The-Go (OTG) functionality, allowing them to handleUSB devices. Some of these MD models have proprietaryBdock[ connectors instead of standard USB connectors,requiring custom cables or adaptors, which imposes ausability penalty. However, the majority of MD modelsstill do not provide USB host functionality. In the caseof one of the most popular MD manufacturers, accessto the USB application programming interfaces (APIs)is subject to legal agreements [17].

Wireless personal area network: BluetoothVThe BluetoothSerial Port Profile (SPP) could be used to exchangeinformation between MZTIC and MD. High powerconsumption and the prerequisite of device pairingVformany users a cumbersome processVnegatively affectsthe convenience of this mechanism. Even thoughBluetooth is widespread, there are MD models that areoffered without it, do not support the SPP, orVin thecase of one MD manufacturerVwould require legalagreements and additional hardware to access theBluetooth functionality [17]. The Bluetooth 4.0specification contains a feature called Bluetooth LowEnergy (BLE), addressing the high power consumptiontypically associated with traditional Bluetooth. This featureis appealing for our purposes not only because it isdesigned to save power, but also because it requiresneither legal agreements nor additional hardware on anyplatform. Unfortunately, Bluetooth 4.0 is rather new,and consequently it is supported only by some of thelatest MD models.

NFCVNFC provides a standardized contactless interfacefor bidirectional communication. Despite the increase inNFC-enabled MDs offered in the past few years [18],its availability remains limited among the population ofMDs deployed.

Wireless local area network (WLAN)VThe MD can shareits cellular data Internet connection with the MZTICvia WLAN (connection tethering). Aside from thedrawbacks of WLAN already outlined, this has theadditional disadvantage that it only works whenthe MD connects to the Internet via cellular data.

Haptic/opticalVBased on the pervasiveness of touch screenson MDs, the MZTIC can communicate with the MD via


the touch interface (haptic communication) by stimulatingcertain spots in the MD’s touch screen sensor. In theopposite direction (MD ! MZTIC), flickering on certainspots of the MD display (optical communication) canbe used. We have developed a lab prototype implementingthis idea, but found that even though the optical channelworked satisfactorily, the haptic communication workedunreliably, resulting in a very slow communicationchannel.

Magnetometer/opticalVThe magnetometer reading in theMD could be influenced by the MZTIC by perturbingthe magnetic field in the immediate vicinity of the MD.To achieve the communication channel in the oppositedirection, the optical channel could be used. ManyMD models have a magnetometer that can be used forthis purpose. However, such a mechanism would bestrongly susceptible to environmental conditions.

AudioVThe audio interface is essential for making calls,playing/recording sounds, and gathering voice commands.The audio interface can be used in two distinct modes:connected and coupled. Using the connected audiointerface to exchange data between MD and MZTICwould entail physically connecting these devices. The MDwould receive information from the MZTIC using itsmicrophone input and send information via its headphoneoutput. The MD’s microphone input and headphone outputare most frequently combined in the 3.5-mm TRRSaudio jack. Establishing such a physical connectionprovides isolation from the environment. Moreover, theaudio interface on the MZTIC side could be built withinexpensive components.A coupled mode entails fitting the MZTIC with a

microphone and a speaker, placing it in the vicinity of theMD and allowing them to exchange information byplaying and recording sounds without connecting them.As it is undesirable for the audio conversation to beactually heard, high frequencies (ideally around or above20 kHz) would have to be used. This mode has theadvantages that it requires no physical connection and isavailable on virtually any MD. On the other hand, thecommunication channel is subject to environmentalinterference/noise in the frequency band used. Also,even though some MD speakers and microphones areknown to have frequency responses beyond 20 kHz, someaudio-processing circuits or firmware may discard suchfrequency components to reduce noise and aid thecompressibility of the signal. In addition, generating wavesin the lower range of the ultrasound band may upsetyoung children and domestic animals, which are perfectlycapable of hearing them.

A comparison of the interfaces to connect MZTIC andMD considered so far is presented in Table 1. The rowsof the table contain the communication options discussed

above, and the columns rate them with respect to a selectedset of relevant criteria to obtain an overall comparativescoring. The rating indicated by B+[ and B–[ signs expressesto what extent a communication option achieves the desiredproperty, namely: using a standardized (digital) interfacedesigned for machine-to-machine communication,widespread availability among MD models, low componentcost, low susceptibility to interference, high bandwidth,requiring zero configuration from the user, and using littlepower. Security is not taken into account when evaluating thechoice of interfaces because we assume the communicationinterfaces to be untrusted and, therefore, all security shallbe built on top of them. Columns should not be compared,considering that rankings are qualitative and relative. Thereis no clear Bwinner[ from the information provided inthe table. However, the best-scoring alternatives are USBand connected audio. We have decided to base our firstproof-of-concept on the audio interface, mainly because it ismore prevalent than USB on MDs. This proof-of-conceptshall be described in the next section.

Audio ZTIC: A proof-of-concept Mobile ZTIC

Exploration of the connected audio channelWe started our work with the audio channel by searchingfor the TRRS interface specification. It turned out thatthe TRRS electrical interface is not formally specified.On the contrary, we found that the majority of MDs usethe sleeve for the microphone line and the last ring for theground line, while some others (a minority) assign them theother way around.According to our empirical findings, some MD models

fade outgoing audio signals to smooth the transitions fromand to silence, which may adversely affect the operationof modulation schemes. In addition, we noticed that atmaximum volume level, the amplitude of the audio outputsignal would vary by a factor of 2 to 3 across differentMD models. This output was found to have a typicalfrequency range between 5.0 Hz and 15 kHz.The microphone input of MDs supplies a DC bias to power

the attached microphone. To distinguish whether theconnected device has a microphone, the MD senses thecircuit between the last ring and the sleeve. The specificsof such a circuit are not standardized and differ acrossMD models. Some MD models interpret signals on themicrophone line in the form of short circuits as commandsto accept phone calls, change radio stations, skip audiotracks, and so on. Some MD models also change the phaseof the microphone input signal, which would render theuse of phase-modulation schemes difficult. Furthermore,we found that some MD analog-to-digital converters (ADCs)exhibit transient distortions in the output signal after afrequency shift in the input signal. Most devices scale themicrophone input level to accommodate potential future


increases in the dynamic range of the audio signal, whichwould adversely affect amplitude modulation schemes.Compared with MD audio output signals, microphone inputsexhibit a narrower frequency range: some MD models werefound to attenuate the amplitude above 8 kHz, others aslow as 4 kHz. Also, some MDs apply signal-processingtechniques to reduce background noise, limit inputamplitudes, or even mute the input when the signal leveldrops below a certain level.

Proof-of-concept goals and constraintsThe main goal of our proof-of-concept is to demonstrate thefeasibility of realizing strong authentication and achievingthe objectives described in Section 2. Therefore, we decidednot to focus on engineering an optimal modulation schemein terms of robustness, highest achievable data rate, ormaximizing MD coverage. Instead, we focused ondeveloping a solution that would run on Apple iOSversion 5.0 or higher and four popular device modelswith Android 4.0 or higher. In addition, we strove to designand develop a solution that demonstrates that the resultingmechanism works using only publicly available APIs, withoutrequiring native code or rooting/jail-breaking the MD.We decided to run all modulation/demodulation processing

on the SoC used in the ZTIC and inherited by the MZTIC.Alternatively, digital signal processors (DSPs) could beemployed, but these would add complexity and increase costwithout much gain towards achieving our main goal.Finally, we decided to devote a fair amount of attention

to power management in order to minimize the batterysize and frequency of recharge cycles.

Prototype descriptionOur prototype consists of the building blocks shown inFigure 2. Most of these blocks are inherited from the ZTIC,with the notable exceptions of the Power & BatteryManagement, the OLED (organic light-emitting diode)Display, and the Audio Interface blocks. The Power andBattery Management component is particularly advancedas it senses the USB lines to determine whether a standardUSB port, a USB charging port, or a wall-plug charger isconnected. While full compliance with the USB specificationis maintained at all times, any power that is not consumedby our circuit charges the battery. This block also containsDC/DC converters, which can be individually shut downto reduce power consumption.The OLED Display block was adapted to fit a square

display instead of a rectangular one, which is better suitedfor the MD scenario as its contents can easily be rotated tomatch the orientation of the MD screen. The Audio Interfaceblock was added to communicate with the MD via the audiointerface. The MD audio outputs generate an AC-coupledsignal, whereas the corresponding ADC inputs in the MZTICexpect a DC-coupled signal. Therefore, a signal-conditioningstage was added in front of the ADC input, as illustratedin Figure 2. This stage shifts the signal to the middle of theADC range and amplifies it to make the best use of thatrange. In the opposite direction, the lines carrying themicrophone and ground signals are sensed to determinewhich way they are wired, and the switches are setcorrespondingly. For the majority of devices, the microphoneis on the sleeve, for the minority of devices, it is on thelast ring. The output signal generated by the SoC is

Table 1 Comparison of the interfaces considered to connect Mobile ZTIC and a mobile device (MD).


conditioned to adjust its levels before it is AC-coupledto the microphone input of the MD.Based on the results of our channel exploration, our

modulation scheme of choice is binary frequency shift keying(BFSK). BFSK is a frequency modulation scheme thatuses a pair of discrete frequencies, the keying frequencies,to encode and transmit the 0s and 1s of a binary datamessage. During idle periods, when no message is beingtransmitted, the MZTIC outputs a fixed low-frequency signalsufficiently separated from the keying frequencies. This willprevent adverse effects generated by fade-ins and fade-outs,enable frame detection, and allow the MD to detect thepresence of the MZTIC, effectively distinguishing it fromother devicesVnotably headsetsVthat could be connectedvia the TRRS audio socket. As a consequence of themodulation scheme chosen and the keying frequenciesselected, communication between the prototype and theMD yields a maximum theoretical throughput of 500 bytes/second. Given this limited throughput, a TLS handshakewith mutual authentication would take several seconds(depending on the size of the certificates) to complete, whichmay be considered unacceptable. Therefore, as illustratedon the right-hand side of Figure 1, we replace TLS by amessage-based security protocol that meets our security

objectives using symmetric cryptography based either onpre-shared symmetric keys or on ephemeral keys derivedfrom asymmetric entity key pairs.Figure 3 shows our prototype in operation during a

transaction confirmation. The TRRS connector is integratedinto the prototype, rendering a cable between MZTIC andMD as unnecessary. Such a physical connection firmlyanchors the MZTIC to the MD, preventing it from danglingand ensuring that the MZTIC display always faces theuser. In addition, we have implemented functionality inboth the MD app and the MZTIC firmware to enable thesedevices to synchronize their display orientation.

Further testsEven though we restricted our target set to a small set ofdevices, we were curious to see how our prototype fared withother MDs. For this purpose, we developed a test app thatprobed whether communication could be achieved betweenour MZTIC prototype and Android MDs. We distributed thisapp to volunteers among IBM employees in Switzerlandand collected information from 94 distinct MDs. TheseMDs were grouped based on model and operating systemversion, yielding a raw set of 47 groups. Of these, five werediscarded because the corresponding models did not have a

Figure 2

Main components of the Mobile ZTIC prototype using the 3.5-mm TRRS (tip-ring-ring-sleeve)-connected audio interface. (USART: UniversalSynchronous/Asynchronous Receiver/Transmitter; ISO: International Organization for Standardization.)


microphone input on their 3.5-mm audio socket. Using theresulting set of 42 groups, it was found that the MZTICprototype consistently worked on all devices of 32 groups,or about 75%. It worked intermittently on devices of fourgroups or about 10%, and failed to work on the devicesof six groups, or about 15%. The results suggest that morework is needed towards improving MD device coveragefor the solution to be considered viable by banks.

Future workThe development of a product based on connected audiocapable of achieving wider device coverage is a challengingtask because of the peculiarities of the audio channel,many of which can only be discovered empirically on adevice-by-device basis. The audio hardware (which maynot even necessarily be the same across devices of thesame model), firmware, drivers, operating system version,or some software interactions on the MD may preventproper operation of potential communication schemes.These uncertainties are exacerbated by the dynamics andthe consumer-oriented nature of the MD market, producingnew devices at seemingly ever-increasing rates. Therefore,more work is needed to design a reliable and robust schemecatering to such an unpredictable channel.Clearly, the connected audio approach cannot support

devices without a microphone input. Device coverage couldbe increased by equipping the MZTIC with an additionalcommunication interface. However, this would increase bothcost and complexity, and still not guarantee one hundredpercent coverage.Performance gains could be achieved by exploiting the

asymmetry of the audio channel, particularly the stereonature of the MD audio output. In addition, more elaborate

modulation schemes implemented on DSPs might increasethe achievable data rate.

Related workMost two-factor authentication mechanisms based on anadditional token, such as one-time password (OTP)generators [19], provide insufficient protection againstMITM/MITB attacks [20]. Similarly, mTAN can bebypassed as described in Section 1.Mechanisms that generate responses to a given

server-generated challenge, such as the Chip AuthenticationProgram (CAP) of MasterCard and the Dynamic PasscodeAuthentication (DPA) of Visa, have the drawback that inmost cases the relationship of the challenge to the transactiondetails is not evident to the user, making these mechanismvulnerable to MITM/MITB attacks [21]. Naturally, ifall the relevant transaction details are re-entered to computethe response, the feasibility of such attacks is dramaticallyreduced, but this comes at the price of diminishingconvenience.Other mechanisms aim to provide transaction

authentication by displaying a machine-readable codecontaining encrypted details of a transaction, which canbe read using a secondary device. The secondary devicehas a built-in camera to scan the code, which it then decodesand shows on its display. If the additional device consistsof an MD provisioned with the code-reading app [22, 23],then the mechanism is not usable if the user accesses theremote service from that MD. Moreover, it also fails toprovide transaction security under the working assumptionthat MDs are also under control of the attacker. If a dedicateddevice is used [24], then the level of security is comparableto that of our solution. In terms of convenience, themechanism has the drawback that the user is requiredto manually type the response on the MD, as themachine-to-machine communication is unidirectional,from MD to the dedicated device.Square [25] is a credit card magnetic stripe reader that

enables the MD to receive credit card payments. It sendsthe magnetic stripe information to the MD using theTRRS audio interface. It can be used with most iOSand many Android devices, but it is known not to workwith several MD models [26]. Recently we became awareof UniMate Flex from SecuTech, advertised as a two-factorauthentication token with a hybrid audio/USB interfaceproviding complete PKI (Public Key Infrastructure)application support [27]. The UniMate Flex involvessimilar goals as the work presented in this paper.

ConclusionMany tasks performed from MDs, such as eBanking, requireassurances regarding the integrity and confidentiality ofthe information that is entered by or displayed to the user,which are hard to substantiate. In the face of malicious

Figure 3

The Mobile ZTIC prototype attached to the mobile device using the3.5-mm TRRS audio jack. A transaction is awaiting explicitconfirmation by the user.


software, it is not possible to ensure that informationentered or displayed to the user in the MD has not beentampered with. We expect that as MD usage continuesto grow, attacks aimed at such platforms will alsoincrease accordingly.We have described the ZTIC, a device intended to

enable users to conduct security-sensitive operations fromtheir PCs under the assumption that the PC has beencompromised by an attacker. We propose extending theZTIC concept to the realm of MDs. The resulting mechanismalso uses an additional device, the MZTIC, which isconnected to the MD and establishes a link to the server.The messages exchanged on this link are encryptedand authenticated, thereby preventing tampering at any point,particularly at the MD. Using this concept, the injectionof a forged or manipulated request to the server by amalicious entity will become evident to the user, who willbe able to detect it on the MZTIC and prevent the attackfrom completing successfully.We have explored various alternatives to realize the

link between MZTIC and MD. After assessing thosealternatives and conducting preliminary experiments, wechose the 3.5-mm TRRS audio jack interface to develop aproof-of concept targeting a limited number of MD models.Such coverage can be increased by further work on areliable and robust communication scheme catering to thepeculiarities of the audio channel, many of which we havediscovered empirically and reported. Also, the achievabledata rate can be improved by exploiting the stereo nature ofthe MD audio output and using more elaborate modulationschemes implemented on DSPs.Our proof-of-concept successfully confirmed the feasibility

and viability of the MZTIC solution. For the sake ofdemonstration, we have shown that strong transactionauthentication from MDs is feasible in the context ofeBanking. However, such a mechanism can also be usedin other contexts, such as electronic document signingby extracting and showing key parts of the document onthe MZTIC for explicit approval, administration of remotesystems from MDs by confirming sensitive commandsusing the MZTIC, etc.

AcknowledgmentsWe thank Simeon Furrer for his support regarding themodulation scheme used in our proof-of-concept research.

**Trademark, service mark, or registered trademark of Bluetooth SIG,Inc., Apple, Inc., Google, Inc., MasterCard International, Inc., orVisa International Service Association in the United States, othercountries, or both.

References1. F-Secure. (2013, Mar.). Mobile Threat Report Q4 2012,

F-Secure Labs, Helsinki, Finland, Tech. Rep. [Online]. Available:http://www.f-secure.com/static/doc/labs_global/Research/Mobile%20Threat%20Report%20Q4%202012.pdf

2. E. Kalige and D. Burkey, BA Case Study of Eurograbber:How 36 Million Euros was Stolen via Malware,[ Versafeand Check Point, Tel Aviv, Israel, Tech. Rep., Dec. 2012.

3. A. Porter Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner,BA survey of mobile malware in the wild,[ in Proc. 1st ACMWorkshop, New York, NY, USA, 2011, pp. 3–14.

4. N. Leavitt, BMobile phones: The next frontier for hackers?[Computer, vol. 38, no. 4, pp. 20–23, Apr. 2005.

5. Lookout Mobile Security. (2012). State of Mobile Security,San Francisco, CA, USA, Tech. Rep. [Online]. Available: https://www.lookout.com/resources/reports/state-of-mobile-security-2012

6. Sophos. (2012). Security Threat Report, Sophos, Abingdon,U.K., Tech. Rep. [Online]. Available: http://www.sophos.com/medialibrary/PDFs/other/SophosSecurityThreatReport2012.pdf

7. C. Foresman, Truly Malicious iPhone Malware Now Out in theWild. [Online]. Available: http://arstechnica.com/apple/2009/11/truly-malicious-iphone-malware-now-out-in-the-wild

8. J. Kirk, New iPhone Malware Steals Data From JailbrokenPhones. [Online]. Available: http://www.pcworld.com/article/181906/article.html

9. P. Berlin, Praventionshinweis fur Onlinebanking immTAN-Verfahren. [Online]. Available: http://www.berlin.de/polizei/presse-fahndung/archiv/377949/index.html

10. T. Weigold, T. Kramp, R. Hermann, F. Horing, P. Buhler, andM. Baentsch, BThe Zurich Trusted Information ChannelVAnefficient defence against man-in-the-middle and malicioussoftware attacks,[ in Proc.1st Int. Conf. Trusted Comput. TrustInf. Technol., Trusted Comput. – Challenges Appl., vol. 4968,P. Lipp, A.-R. Sadeghi, and K.-M. Koch, Eds., 2008, pp. 75–91,ser. Lecture Notes in Computer Science.

11. IBM Zone Trusted Information Channel (ZTIC)VA BankingServer’s Display on Your Key Chain, IBM Corporation. [Online].Available: http://www.zurich.ibm.com/ztic/

12. N. Utakrit, BReview of browser extensions, a man-in-the browserphishing techniques targeting bank customers,[ in Proc. 7thAustralian Inf. Security Manag. Conf., Perth, WA, Australia, 2009,pp. 110–119.

13. P. Burkholder, BSSL man-in-the-middle Attacks,[ in SANS Inst.Reading Room, 2002. [Online]. Available: http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480

14. S. Li, A. Sadeghi, S. Heisrath, R. Schmitz, and J. Ahmad,BhPIN/hTAN: A lightweight and low-cost e-banking solutionagainst untrusted computers,[ in Proc. 15th Int. Conf.Financial Cryptography Data Sec., Gros Islet, St. Lucia,2011, pp. 235–249.

15. L. Faith-Cranor and S. Garfinkel, Eds., Security and Usability:Designing Secure Systems that People Can Use. Sebastopol,CA, USA: O’Reilly Media, Inc., 2005.

16. S. Garfinkel, BDesign principles and patterns for computer systemsthat are simultaneously secure and usable,[ Ph.D. Thesis,Massachusetts Institute of Technology, May 2005.

17. MFi Program, Apple, Inc. [Online]. Available: https://developer.apple.com/programs/mfi/

18. D. Balaban, NFC Smartphone Chip Shipments in 2012 SurgePast Projections. [Online]. Available: http://nfctimes.com/news/nfc-smartphone-chip-shipments-2012-surge-past-projections

19. BEMC2,[ in RSA SecurID. [Online]. Available: http://www.emc.com/security/rsa-securid.htm

20. B. Schneier, BTwo-factor authentication: Too little, too late,[Commun. ACM, vol. 48, no. 4, p. 136, Apr. 2005.

21. D. A. Ortiz-Yepes, BEnhancing authentication in eBanking withNFC-enabled mobile phones,[ M.S. thesis, Dept. Math. Comput.Sci., Tech. Univ. Eindhoven, Eindhoven, The Netherlands,2008.

22. CrontoSign Mobile App, Cronto. [Online]. Available: http://www.cronto.com/crontosign-transaction-authentication-mobile.htm

23. G. Starnberger, L. Froihofer, and K. Goeschka, BQR-TAN: Securemobile transaction authentication,[ in Proc. Int. Conf. Avail. Rel.Security, 2009, pp. 578–583.

24. CrontoSign Device, Cronto. [Online]. Available: http://www.cronto.com/crontosign-transaction-authentication-device.htm


25. Square Register, Square Inc. [Online]. Available:https://squareup.com/

26. Device Compatibility With Square, Square Inc. [Online]. Available:https://squareup.com/help/en-us/article/3887-device-compatibility-with-square

27. UniMate Flex Two-factor Authentication Token, SecuTech.[Online]. Available: http://www.esecutech.com/mobile-authentication/unimate-flex/unimate-flex-overview-%7C-mobile-authentication.html

Received July 15, 2013; accepted for publicationAugust 15, 2013

Diego A. Ortiz-Yepes IBM Research - Zurich, 8803Ruschlikon, Switzerland ([email protected]). Mr. Ortiz-Yepes isa Software Engineer in the Computer Science department at IBMResearch - Zurich. He received an M.S. degree in computerscience (Information Security Technology) from the TechnischeUniversiteit Eindhoven in the Netherlands (2008). He joined theBlueZ Business Computing Group at the Zurich Research Labin January 2008. Since then, he has been involved in the research,development, implementation, and testing of authenticationmechanisms, particularly those focused on eBanking. Mr. Ortiz-Yepesis pursuing a Ph.D. degree as an external candidate at the RadboudUniversiteit Nijmegen in parallel with his software engineering/researchwork at IBM.

Reto J. Hermann IBM Research - Zurich, 8803 Ruschlikon,Switzerland ([email protected]). Mr. Hermann is a ResearchStaff Member in the Computer Science department at IBMResearch - Zurich. He received a Diploma in electrical engineeringfrom the Swiss Federal Institute of Technology, Zurich, Switzerland.In 1983, he joined the Zurich Research Lab, where he worked onthe development of digital magnetic recording systems until 1992.Since then, he has worked in the field of mobile computing. Hiscurrent interests include security engineering and embedded systems.

Hansruedi Steinauer IBM Research - Zurich, 8803 Ruschlikon,Switzerland ([email protected]). Mr. Steinauer is a member ofthe Electronic Engineering Group in the Science and Technologydepartment at IBM Research - Zurich. He has been working in the fieldof hardware engineering since 1975, and he joined the Zurich ResearchLab in 1979.

Peter Buhler IBM Research - Zurich, 8803 Ruschlikon,Switzerland ([email protected]). Dr. Buhler is the head of theComputer Science department at IBM Research - Zurich. His interestsinclude cryptography, secure protocols, and embedded systems. Hereceived a Ph.D. degree in computer science from the Universityof Kaiserslautern, Germany.


Documents

Bringing strong authentication and transaction security to the realm of mobile devices