multichannel security protocols - university of...

1536-1268/07/$25.00 © 2007 IEEE ■ Published by the IEEE Computer Society PERVASIVEcomputing 31

Multichannel SecurityProtocols

Multichannel security protocolstransmit messages over multi-ple communication channels,taking into account each chan-nel’s security properties. Our

first intentional use of these protocols goes backto a 1999 article that proposed physical contactfor imprinting as opposed to the wireless channelused in subsequent operations.1 Only later did weunderstand three key points.2 First, explicit use ofmultiple channels in the same protocol can offersignificant advantages for both security andusability. Second, explicitly stating the propertiesof the channel on which each protocol message istransmitted is useful for understanding one’s ownprotocol in greater depth and therefore for ad-dressing subtle vulnerabilities early on. Third,

multichannel protocols existedlong before we recognized themas such—think of the courierhandcuffed to the briefcase car-rying the code book that will

later protect postal or telegraphic traffic.As protocol designers, we have much to gain

by adopting the multichannel viewpoint: it forcesus to be more precise about security requirementsand the attacker model. Such precision of expres-sion (and, by implication, of purpose) helps usanticipate and avoid design flaws.

Multichannel protocols are particularly rele-vant for ubiquitous computing, which typicallyinvolves heterogeneous communication chan-nels—as opposed to, for example, the compara-tively more uniform scenario offered by the

packet-switched Internet. One of Mark Weiser’sseminal articles about ubicomp asked, “Can thedevice communicate simultaneously along mul-tiple channels?”3 And if it can, we add, what arethe advantages for security?

In this article, we describe several protocols thatwe’ve designed using the multichannel approachand the benefits gained in security and usability.Our work’s original contribution is as much in theprotocols as in the explicit adoption of the multi-channel viewpoint. (The sidebar “Related Work inMultichannel Security Protocols” provides fur-ther information about the field.)

Bootstrapping ubicomp securityOne classical ubicomp problem is that of form-

ing a security association (a shared secret) be-tween two devices that can talk over an insecurechannel—for example, a camera phone and ashared printer linked by radio—without an au-thentication infrastructure.

A solution based only on symmetric cryptog-raphy lets a passive eavesdropper derive thesecret. To prevent eavesdropping, the devices canform a shared secret through a Diffie-Hellman(DH) exchange.4

However, a Dolev-Yao attacker5 (which canintercept, stop, modify, and insert messages atwill) could still mount a man-in-the-middle(MITM) attack. Such a bugging device—let’s callit Mallory—intercepts all messages between cam-era phone Alice and printer Bob, establishes anAlice-Mallory key and a Mallory-Bob key, andthen decrypts, reads, and re-encrypts all messages

The authors’ security protocols exploit additional transmissions overlower-capacity channels, typically found in ubicomp environments, thatoffer a different combination of security properties.

S E C U R I T Y & P R I V A C Y

Ford Long Wong and Frank StajanoUniversity of Cambridge

as they come through. So there are tworelated problems: first, Mallory can read(and rewrite) the traffic between Aliceand Bob; second, and more fundamen-tally, Alice and Bob believe they’veestablished a secure channel with some-body, but they’re not sure whether thatis the right party.

With channels such as radio, you can’tbe too sure where messages come from.On the other hand, if a device you recog-nize as the source displays a value on itsLCD, you can be sure that the value comesfrom that device and not from an MITM

one. We describe this channel property asdata origin authenticity. It’s also practi-cally impossible for a MITM attacker tomake you see a different value on the gen-uine display; we refer to this as integrityfor this channel. However, given that thescreen might be visible to nonparticipants,that channel doesn’t offer confidentiality.In what follows, we’ll assume that aDolev-Yao attacker operates on the radiochannel but that other, lower-capacitychannels are also available on which theattackers’ powers are reduced—for exam-ple, just to eavesdropping.

As an example, let’s see how Alice andBob can verify, using multiple channels,whether they’re both sharing the sameDH key gab (we omit all the “(mod n)”for brevity). Figure 1a presents protocol1a. The key will be the same essentiallyonly if there’s no MITM. Alice computesthe key’s hash, h((gb)a), and Bob com-putes his, h((ga)b). By comparing theseindependently computed hashes over adifferent channel offering data originauthenticity—for example, by display-ing them on their respective LCD pan-els—the users can verify whether the

32 PERVASIVEcomputing www.computer.org/pervasive


S everal authors have recently published significant work usingauxiliary channels, including• Dirk Balfanz and his colleagues, who use a “location-limited”

channel to commit to a public key’s hash;1

• Jaap-Henk Hoepman, who studies the ephemeral key exchange

(�KE) problem with explicit consideration of various channels’

security-related properties;2

• Jonathan McCune, Adrian Perrig, and Michael Reiter, who study

the visual channel using camera phones;3

• Serge Vaudenay, who describes commitment schemes and in-

troduces stronger authenticity properties;4

• Mario C̆agalj, Srdjan C̆apkun, and Jean-Pierre Hubaux, who pro-

pose three protocols based on visual and verbal interaction be-

tween the participants;5 and

• Sven Laur and Kaisa Nyberg, with their round-efficient Mana IV

protocol.6

Before all these, Lars Erik Holmquist and his colleagues proposed

an imaginative auxiliary channel for pairing—shaking devices to-

gether;7 the associated security protocol came later.

In terms of security proofs, Ueli Maurer and Pierre Schmid de-

veloped early on a calculus of channel security properties and

transformations between them.8 Hoepman,2 Vaudenay,4 and Laur

and Nyberg6 provide security proofs for their proposals. Sadie

Creese and her colleagues argue that, in formalizing the attacker

model in a ubicomp environment, assuming a Dolev-Yao attacker

across all channels isn’t necessary.9 They consider how to model

this in formal tools such as the CSP (Communicating Sequential

Processes) language, the FDR (Failures-Divergences Refinement)

model checker, and the Casper compiler.

Finally, industry associations such as the Bluetooth Special

Interest Group, the Wi-Fi Alliance, and Wireless USB have

also introduced multichannel pairing protocols in their latest

proposals.

REFERENCES

1. D. Balfanz et al., “Talking to Strangers: Authentication in Ad Hoc Wire-less Networks,” Proc. Network and Distributed System Security Symp.,Internet Soc., 2002.

2. J.-H. Hoepman, “The Ephemeral Pairing Problem,” Proc. Financial Cryp-tography, LNCS 3110, Springer, 2004, pp. 212�226.

3. J.M. McCune, A. Perrig, and M.K. Reiter, Seeing Is Believing: Using Cam-era Phones for Human-Verifiable Authentication, tech. report CMU-CS-04-174, Computer Science Dept., Carnegie Mellon Univ., 2004.

4. S. Vaudenay, “Secure Communications over Insecure Channels Basedon Short Authenticated Strings,” Proc. 25th Ann. Int’l Cryptology Conf.(CRYPTO 05), LNCS 3621, Springer, 2005, pp. 309–326.

5. M. C̆agalj, S. C̆apkun, and J.P. Hubaux, “Key Agreement in Peer-to-PeerWireless Networks,” Proc. IEEE, vol. 94, no. 2, 2006, pp. 467–478.

6. S. Laur and K. Nyberg, “Efficient Mutual Data Authentication UsingManually Authenticated Strings,” Proc. 5th Int’l Conf. Cryptology andNetwork Security (CANS 06), LNCS 4301, Springer, 2006, pp. 90�107.

7. L.E. Holmquist et al., “Smart-Its Friends: A Technique for Users to EasilyEstablish Connections between Smart Artefacts,” Proc. 3rd Int’l Conf.Ubiquitous Computing (Ubicomp 01), LNCS 2201, Springer, 2001, pp.116�122.

8. U. Maurer and P. Schmid, “A Calculus for Secure Channel Establishmentin Open Networks,” Proc. 3rd European Symp. Research in ComputerSecurity (ESORICS 94), LNCS 875, Springer, 1994, pp. 173�192.

9. S. Creese et al., “The Attacker in Ubiquitous Computing Environments:Formalising the Threat Model,” Proc. 1st Int’l Workshop Formal Aspects inSecurity and Trust (FAST 03), tech. report, Inst. of Informatics andTelematics�Italian Nat’l Research Council, 2003, pp. 83�97.

Related Work in Multichannel Security Protocols

devices share the same key. If the hashesdon’t match, the user can abort the trans-action and call the bug-sweeping teamto look for Mallory.

The figure’s shaded rectangles showthat protocols 1a and 1b would lookessentially the same to Alice and Bob. Inother words, neither Alice nor Bob couldtell, simply on the basis of the messagesthey receive, whether there’s an MITMattacker Mallory.

There are many possible ways to per-form the verification over a nonradiochannel. The double-headed arrow atthe end of Protocol 1a is actually a sub-protocol in itself that we could expand inseveral ways, including the following:

1. Both devices display their hash, thenthe user compares them and pressesOK or Cancel on each device.

2. The user prints out the hash usingthe printer Bob and types it on thecamera phone Alice’s numeric key-pad.

3. Using the camera phone Alice, theuser takes a picture of the hash thatBob printed.

Further alternatives are possible. As-surance about the message’s origin comesnot only from using a visual channelinstead of radio but also from actuallyinvolving the human user in the process.

Unfortunately, almost all variations ofthis auxiliary authentic channel have somecapacity limitation imposed by usabilityand robustness constraints. For example,the user won’t enjoy comparing or typinga hash much longer than half a dozencharacters. So, using truncated hashes—say, 20 to 30 bits—might be necessary. The

design of the protocols that use such shortvalues is critical, because unsuitable designcan give rise to feasible attacks.

Going back to protocol 1a, imaginethat the hashes are short (that is, trun-cated) enough to be brute-forced in realtime. Then Mallory could still mount aMITM attack despite the visual check.As protocol 1b shows, Mallory choosesthe forged DH contributions via brute-force search to ensure that, when com-bined with the victims’ own contribu-tions, Alice and Bob respectively formkeys gab� and ga�b� that yield the sametruncated hash. Consequently, the userwill confirm that the truncated hashesfrom the two devices match and mis-takenly assume that all is fine, eventhough the calculated session keys areactually different and an MITM attackis taking place.

OCTOBER–DECEMBER 2007 PERVASIVEcomputing 33

Radio

ga

Verify: h((gb)a) = h((ga)b)?

Channel with data origin authenticity

Computeh((ga)b)

Chooserandom b

Radio

Radio

ga

Choose random a ′g a ′

Find b ′ such thath((gb ′)a) = h((gb)a ′)

gb

Radio

Radiogb ′

Computeh((gb ′)a)

Computeh((ga ′)b)

Chooserandom b

MalloryAlice BobChoose

random a

Alice BobChoose

random a

Computeh((gb)a)

gb

Radio

Channel with data origin authenticity

(a) (b)

Verify: h((gb ′)a) = h((ga ′)b)?(answer: yes, even though gb ′a � ga ′b)

Figure 1. A Diffie-Hellman key exchange protocol (a) over a radio with hash verification on a separate channel, and (b) in the presence of a man-in-the-middle attacker.

Low-capacity channels Usability prevents us from adopting

full-size hashes (greater than 200 bits)on the data-origin-authentic channel, buta robust protocol is still possible, evenwith truncated hashes. We must forceMallory to guess correctly in just oneattempt, instead of allowing a brute-force search. Used this way, a 20-bithash gives us a 2–20 (1 in a million)probability that the MITM attack willsucceed (strong security), whereas pre-viously it gave us only the modest pro-tection of a 220 workload for the brute-force attacker (weak security).

Protocol 2 (see figure 2) is a slightlymore efficient version of our 2005 pro-posal.2 It achieves strong security bycombining long values sent over radiowith short values sent over the data-origin-authentic auxiliary channel.

Imagine two camera phones (againnamed Alice and Bob) taking pictures ofeach other’s screen in turn. The protocolis essentially symmetric, so let’s considerAlice’s side and the messages she sends.Initially, Alice randomly selects a (long)

private value a, a short (for example, 20-bit) nonce RA (an arbitrary number usedonly once per security session), and a long(for example, 256-bit) message authenti-cation code key KA. Alice then computesher ephemeral DH public key ga and acommitment . In mes-sage 1, Alice sends her identifier, the pub-lic key, and the commitment. Because thishappens over radio, length isn’t a prob-lem, so the MAC itself can be long, too.In message 3, after having received Bob’spublic key and commitment, she releasesher short nonce RA over the visual chan-nel. In message 5, after receiving Bob’snonce RB, she releases her (long) MACkey KA via radio.

At that point Bob can compute Alice’scommitment using Alice’s identifier andpublic key from message 1, her noncefrom message 3, and her MAC key frommessage 5, and verify whether he obtainsthe same MAC value as the one he re-ceived in message 1. If the values match,he’s assured that the ga he received is theone that Alice transmitted, so he can safelyuse it to calculate the shared secret gab.

Why can Bob be assured? ConsiderMallory’s perspective. To substitute hisown ga� on the way from Alice to Bob,Mallory would need to send a commit-ment in message 1. He can substitute aMAC key but can’t anticipate (or forge)the RA nonce that Alice will release inmessage 3—indeed, as we mentioned ear-lier, he only has, say, a one-in-a-millionchance of predicting correctly. If Malloryguesses incorrectly, Bob will notice itwhen he receives message 5 and tries toverify the MAC.

If the protocol used short valuesthroughout, Mallory might alterna-tively consider sending a random com-mitment to Bob in message 1 and brute-forcing a suitable MAC key afterhaving seen Alice’s nonce RA. Mallorywould search for a MAC key x suchthat evaluated to therandom commitment he sent Bob inmessage 1. If the MAC value were onlyt bits long, then he’d try only about 2t

keys before finding a suitable x. But thiswon’t work in our protocol because theMAC key and output, both sent overradio, can afford to be hundreds of bitslong and are therefore out of reach ofa practical brute-force search.

One point to note is whether the pro-tocol designer using an auxiliary chan-nel assumes it to be confidential. Someprevious multichannel protocols haveassumed their auxiliary channels’ con-fidentiality, in addition to authenticity.However, that assumption’s validityshould be reevaluated, especially forvisual channels, now that surveillancecameras and camera phones are so per-vasive. Our protocol, instead, does notassume confidentiality and resists eaves-dropping on the auxiliary channel.

As a general principle, then, the pro-tocol’s DH components help resist eaves-dropping attacks, while short valuestransferred over the auxiliary channel,secured by nonmalleable commitments,6

help resist active attacks.

MACxa

AA g R( )′

MACKa

AAA g R( )



Radio

Radio

Radio

A, g a, MACKA(A⏐ga⏐RA)

B, g b, MACKB(B⏐gb⏐RB)

Verify: MACKA(A⏐ga⏐RA)

= what I got initially?

Verify: MACKB(B⏐gb⏐RB)

= what I got initially?

Choose b, KB, RB

Bob(camera phone)

Alice(camera phone)

Choose a, KA, RA

2

4

6

7

5

3

1

Radio

RB

KA

KB

Data-origin-authentic channel: push button

Data-origin-authentic channel: LCD to camera

Data-origin-authentic channel: LCD to camera

OK/Cancel

RA

Figure 2. Man-in-the-middle-resistantmutual authentication.

Unidirectional authenticchannel

While protocol 2 must transmit shortnonces in both directions, we can actuallyachieve the equivalent of strong Dolev-Yao-resistant mutual authentication withjust a unidirectional low-bandwidth au-thentic channel.

Going back to imagining Alice as acamera phone and Bob as a printer, Alicecan “see” Bob’s short code (either on anLCD panel or printed on paper), but notvice versa. In our protocol 3 (see figure3),2 after receiving Alice’s ephemeral pub-lic key ga over radio, Bob responds withhis own identifier, public key, and a com-mitment , where RBis a short random nonce. Bob releases thisrandom nonce over the authentic (visual)channel and the MAC key KB over theDolev-Yao-affected (radio) channel, butonly after Alice has acknowledged (withmessage 3, which carries only one bit butwhich Mallory can’t fake) that she re-ceived the commitment. This preventsMallory from blocking Bob’s message 2,intercepting RB and KB from messages 4and 5, and then issuing to Alice a forgedmessage 2 constructed with knowledge ofRB and KB.

Message 3 requires only a one-bit-per-message data-origin-authentic chan-nel from Alice to Bob, such as a pair ofOK and Cancel push buttons or a sin-gle push button with a time-out (noticethat pressing buttons implies a humanoperator). Nevertheless, message 3forces Mallory to commit early to aguess if he wants to issue a fake mes-sage 2 to Alice.

After receiving message 5, Alice com-putes and verifieswhether it matches what she received inmessage 2. If the values match, she’s as-sured that she received Bob’s original gb

and that Bob received her original ga,meaning that they can both safely cal-culate their shared secret gab. But Bobdoesn’t know yet whether the verifica-

tion succeeded. So Alice must notify him,again using the one-bit-per-message au-thentic channel.

This protocol is remarkable becauseit achieves strong security even withouta low-capacity authentic channel overwhich to transfer a short nonce fromAlice to Bob. The critical insight is thatAlice (assuming she’s honest and uncom-promised) can perform the verificationand then securely notify Bob of the out-come with the human user’s help. Thisnotification’s authenticity is assured bythe fact that the Dolev-Yao attacker onthe radio can’t press the button on deviceBob. With this multichannel protocol,we’ve essentially amplified the data or-igin authenticity of the one-bit-per-message push-button channel to coverboth parties’ DH keys ga and gb.

The sidebar “Multichannel GroupKey Agreement” discusses how to ex-tend such a protocol to more than twoparties.

Implementation issuesTo validate our protocols’ feasibility,

we implemented prototypes of the keybuilding blocks (though not full imple-mentations) and experimented with two

auxiliary channels. Here are the moresignificant quantitative aspects.

Computing timeThe DH protocol is often deemed

unsuitable for ubicomp devices becauseof the computational load of modulararithmetic. While this is true for simplerdevices such as wireless headphones andRFID tags, it’s less of a concern for mod-ern phones, cameras, MP3 players, orPDAs. We ported the relevant C routinesfrom Shamus Software’s MIRACL cryp-tographic library (www.shamus.ie) tothe Symbian v7.0s operating system usedin several Nokia camera phones. Wethen compiled them using the develop-ment environment of Symbian’s Series60 Developer Platform 2.0.

We obtained reasonably fast per-exponentiation timings: for elliptic-curve group key sizes of 160, 192, and224 bits, we respectively measured 81,118, and 160 milliseconds on a Nokia6600 (104-MHz ARM CPU) and 68, 98,and 137 ms on a Nokia 6670 (123 MHz,see figure 4a). We obtained each mea-surement by averaging 1,000 exponenti-ations. Compared to exponentiations,MAC computations take negligible time.

MACKb a

BBB g g R( )

MACKb a

BBB g g R( )


Radio

Radio

Radio

g a

B, g b, MACKB(B⏐gb⏐g a⏐RB)

Verify:MACKB(B⏐g

b⏐g a⏐RB)= what I got initially?

Choose b, KB, RB

Bob(printer)

Alice(camera phone)

Choose a

2

4

6

5

3

1

RB

KB

Data-origin-authentic channel

OK/Cancel

OK (= acknowledge)

Push button

Push button

Figure 3. Strong security despite the unidirectional visual channel.

On PDAs, laptops, and PCs, computa-tions are, of course, even less of an issue.The cryptographic code was 17,175 linesof C and, once compiled, occupied just122 Kbytes—insignificant compared tothe phones’ 6 and 8 Mbytes of sharedmemory (further expandable with Mul-tiMediaCards). The radio messaging isstraightforward to implement using theSymbian Platform Bluetooth API.

Visual channel2D visual-code software is now widely

available. We experimented with ourlab’s Target Recognition Using Image

Processing (TRIP) system and the Sema-code’s open-source software develop-ment kit on both PCs and our two cam-era phones. TRIP was designed to enableautomatic recognition (and estimationof location and orientation) of its circu-lar targets in a video frame of a clutteredscene. The square Data Matrix (ISO/IEC 16022) targets used by Semacodewere meant to be acquired by explicitlyphotographing the tag straight on. So,for a given pixel count of the acquiredtarget, Semacode tags carry many morebits and are better suited to our securityapplication; we want the user to per-

form an explicit acquisition operationinstead of letting the software grab anycode it locks onto.

We set out to measure the maximumcapacity of the phone-to-phone visualchannel by encoding progressivelylonger strings as Semacode tags ofincreasing pixel count, displaying themon the Nokia 6600, acquiring themwith the Nokia 6670 (the one with thebetter camera), and recording thelargest size at which they could betransferred reliably. We spent 5 secondsattempting to acquire each frame, re-peating 10 times for each frame, and we



W hen more than two devices must establish a commonsecret, we can build on a multiparty extension to Diffie-Hellman,1 such as the Cliques Group Key Agreement (GKA) proto-

col suite. The basic scheme2 arranges the members in a linear

chain: each member Mi receives a bit string from its predecessor

Mi – 1 and passes it on to its successor Mi + 1 after merging its own

contribution ri to the key. The last member in the chain (Mn)

broadcasts the final keying material to all other members, en-

abling each to compute the common group key .

Olivier Pereira and Jean-Jacques Quisquater have shown3 that, in

the presence of a Dolev-Yao attacker,4 the protocols in this family fail

to provide implicit key authentication, perfect forward secrecy, and

resistance to known key attacks. We can address these problems in

various ways, but ultimately we must ensure that everyone computes

the same group key . Previously we proposed a protocol that

authenticated intermediate keys’ origin at every round, using com-

mitments and auxiliary channels.5

A more efficient scheme, as shown in

figure A, runs after an unauthenticated

GKA finishes, enabling all participants to

check whether they’ve computed the

same group key. This scheme resists

Dolev-Yao attacks.

Topologically, after using a linear

chain for the GKA, we now have a

“star” structure for the verification in

which the various Mi (for I � {1, 2, �,

n – 1}) talk back only to the group

leader Mn and not to each other, while

Mn broadcasts to all others. For radio, a

broadcast, instead of unicasts, is what

physically happens. We make the rea-

sonable assumption that the group

leader Mn is honest, since a leader is

typically chosen carefully. For the low-

gr r rn1 2�

gr r rn1 2�

Radio broadcast

Radio broadcast

MACK(M1⏐M2⏐...⏐Mn⏐F(gr1r2...rn)⏐R)

Wait until allresponsesreceived

Verify:MACK(M1⏐M2⏐...⏐Mn⏐F(g

r1r2...rn)⏐R)= what I got initially?

Wait until all acks. received

MnMi(each Mi does this)

Choose K, R

2

4

6

5

3

1

K

Authentic broadcast or unicasts

Authentic (e.g. visual) broadcastor up to n – 1 unicasts

OK/Cancel

OK/Cancel

R

Push button

Push button

OK (= acknowledge)

Figure A. Multichannel man-in-

the-middle-resistant validation

of a computed group key.

Multichannel Group Key Agreement


recorded the number of successes foreach size. We didn’t perform usabilitytests, but we expect casual users to havea somewhat lower success rate.

The largest frame we could transferreliably—that is, with at most one fail-ure in 10 trials—was 14 � 14 pixels (12� 12 = 144 nonborder pixels, of which80 were used for Reed-Solomon errorcorrection). The frame carried eight codewords and took two further seconds todecode on the 6670 after successfulacquisition. With the ASCII-based encod-ing (6 bits per code word) imposed by theAPI, this meant 48 bits of payload,

although in theory 8 code words couldcarry up to 64 bits of payload. If used asa public-key fingerprint as in protocol 1,48 bits can still be brute-forced (and 64wouldn’t give that much more margin),but this payload size is quite secure if usedaccording to protocol 2. The largestframe for which at least one transfer outof 10 still worked was 22 � 22 pixels, car-rying 180 bits of payload at 6 bits percode word.

With our equipment, the limiting fac-tor wasn’t the acquiring phone’s cameraresolution (1,152 � 864 pixels) or thesource display’s much lower resolution

(176 � 208 pixels). It was the absence ofa macro facility: we needed at least 8 cmfor the 6670 to focus, but at that distancethe 6600’s screen was too small for the6670 to be able to extract high-densitySemacodes. We could successfully ac-quire much larger codes, at distances of15 to 30 cm, from a laptop’s LCD dis-play, as shown in figure 4b. There, thelargest frame transferred with at most 1out of 10 failures was 40 � 40 pixels, car-rying 912 bits at 8 bits per code word andtaking 10 seconds to decode. Such mes-sage capacity is sufficient to defeat brute-force attacks. Most Japanese phones

capacity authentic channel (for example, when Mi takes a picture of

Mn’s screen), broadcasting might be possible (for example, by con-

necting Mn to a projector). If not, iterating a point-to-point trans-

mission to each Mi would also work. For the one-bit-per-message

authentic channel in the opposite direction (for example, when the

human operator presses the OK or Cancel button on Mn depen-

ding on Mi’s result), it will be necessary to repeat for each member

the point-to-point procedure and track which Mi is causing this

button press.

First, Mn broadcasts a keyed commitment

to all Mi, using the high-capacity (for example, radio) channel, on

which the Dolev-Yao attacker is assumed to operate. Here F () is a

pseudorandom key derivation function, R is a short random nonce

(an arbitrary number used only once per security session), and K is

a long random MAC key. Then, after all the Mi devices acknowl-

edge receiving the broadcast (using the authentic one-bit-per-

message channel), Mn releases the nonce R and the key K to all Miover the visual and radio channel, respectively. Each Mi then re-

computes the commitment, verifies whether it matches the one

received from Mn, and reports the answer to Mn over the one-bit

authentic channel. Finally, after receiving everyone’s reports, Mntells everyone over an authentic channel whether they all reported

success. The channel needs to carry only one bit but could be the

visual channel, because it can broadcast instead of using the push

button. If even a single verification fails, the protocol will abort.

Several comparable protocols appear in the literature, such as

those by Long Nguyen and Bill Roscoe6 and Jukka Valkonen and

his colleagues.7 Our use of the authentic one-bit-per-message

channel makes our protocol more efficient in some respects; we

believe this illustrates the usefulness of making channel modeling

more explicit in protocol design.

In message 3, if we use n – 1 unicasts instead of one broadcast,

the unicasts don’t necessarily need to take place over the same

type of authentic channel. If the Mi devices are heterogeneous,

they may each use their preferred auxiliary channel (camera, key-

pad, audio, near-field, contact, and so on). We just require that

each auxiliary channel offer data origin authenticity and sufficient

capacity to transmit R, and that Mn can act as a source for it.

REFERENCES

1. W. Diffie and M.E. Hellman, “New Directions in Cryptography,” IEEETrans. Information Theory, vol. 22, no. 6, 1976, pp. 644�654.

2. M. Steiner, G. Tsudik, and M. Waidner, “Cliques: A New Approach toGroup Key Agreement,” Proc. 18th Int’l Conf. Distributed Computing Sys-tems (ICDCS 98), IEEE CS Press, 1998, pp. 380�387.

3. O. Pereira and J.-J. Quisquater, “Generic Insecurity of Cliques-Type Auth-enticated Group Key Agreement Protocols,” Proc. IEEE Computer SecurityFoundations Workshop (CSFW 17), IEEE CS Press, 2004, pp. 16�29.

4. D. Dolev and A.C. Yao, “On the Security of Public Key Protocols,” IEEETrans. Information Theory, vol. 29, no. 2, 1983, pp. 198�208.

5. F.-L. Wong and F. Stajano, “Multi-Channel Protocols for Group KeyAgreement in Arbitrary Topologies,” Proc. 3rd IEEE Int’l Workshop Perva-sive Computing and Communication Security (PerSec 06), IEEE Press, 2006.

6. L.H. Nguyen and A.W. Roscoe, “Efficient Group Authentication Proto-cols Based on Human Interaction,” Proc. FCS-ARSPA, 2006, pp. 9–32.

7. J. Valkonen, N. Asokan, and K. Nyberg, “Ad Hoc Security Associationsfor Groups,” Proc. 3rd European Workshop Security in Ad Hoc and SensorNetworks (ESAS 06), LNCS 4357, Springer, 2006, pp. 150–164.

MACK nr r rM M M F G Rn1 2 1 2……( )⎛⎝⎜ ⎞⎠⎟

today are equipped with macro lensesand automatically decode QR Code(ISO/IEC 18004). We expect that mostphones worldwide will eventually be-come macro capable if visual codesbecome widespread. This would allowthe phone-to-phone transfer of visualcodes long enough to act as full public-key fingerprints, defeating the MITMin protocol 1 without requiring ourprotocol 2.

Melodic audioWe also experimented with transferring

a random nonce from one device to an-

other by playing a short monophonictune. The audio channel provides someintegrity—it’s hard for Mallory to inter-fere without the human operator detect-ing it. Data origin authenticity isn’t asstrongly guaranteed as by the visual chan-nel (sometimes you can’t quite tell wherea tune came from), but it’s still better thanwith radio. There’s no confidentiality,because anyone in range also hears. Aspeaker and microphone are cheaper thanan LCD and camera and, especially onthe source side, smaller; this might makethem more suitable for certain ubicompgadgets. It’s also harder for the operator

to miss the fact that a transmission is tak-ing place, which might be good for secu-rity but bad for usability. We tried toaddress the latter point by making thetunes more pleasant-sounding.

Our prototype algorithms generate3.5-second monophonic tunes, encod-ing values in the notes’ pitch. We didn’texplore the limits of the transmissionrange, but with commodity hardware(external PC speakers and mobile-phonemicrophones), we repeatedly achievedzero symbol errors over a room-scale dis-tance of two meters (no failures over 10trials, without error correction).

We sought musical guidance anddeveloped three monophony (musicwith a single unaccompanied melodicline) generation algorithms: the first ran-domly chose notes from an octave, thesecond chose notes only from the C-major scale, and the third restrictedlarge pitch changes between consecutivenotes. Figure 4c shows the waveform ofa generated audio signal received by thePC microphone. In informal usabilityexperiments with 14 human listenersaged 20 to 35, the algorithms received“pleasantness” scores averaging 3.1, 4.7,and 5.6, respectively, on a scale of 1(worst) to 10 (best), revealing clear pref-erences for the third algorithm. This alsoillustrates a security-versus-usabilitytrade-off because, for the same mono-phony length, our most listener-friendlyscheme gives an entropy of around 15bits per tune, while the least listener-friendly scheme gives 25. There are op-portunities for further research in de-termining algorithms for generatinghigh-entropy but pleasant melodies, ashuman perception of pleasantness isquite subjective and subject to culturalinfluences.

Finally, no matter which auxiliary



(c)0

1.0

0.8

0.6

0.4

0.2

0

–0.2

–0.4

–0.6

–0.8

–1.01.00.5 1.5

Time (seconds)2.0 2.5 3.0 3.5

Enha

nced

aud

io s

igna

l rec

orde

d by

des

ktop

mik

e

(b)(a)

Figure 4. Implementation prototypes: (a) an elliptic-curve cryptography porton a Nokia 6670, (b) visual code transferfrom laptop to mobile phone usingSemacode, and (c) a shaped C-majorscale monophonic tune.

channel is used, designers shouldn’tmake excessive demands on the humanuser in terms of memorability, concen-tration, or sensory acuity.

We encourage you to ex-plore ways to apply mul-tichannel protocols to newproblems. This area could

become a fertile new field for security-protocol research.

ACKNOWLEDGMENTSWe thank our colleagues in the Security Group andthe Digital Technology Group at the University ofCambridge’s Computer Laboratory for providing astimulating environment in which to conduct thisresearch. We particularly thank Oistein Andersen,Ross Anderson, Saar Drimer, Mark Lomas, and theanonymous reviewers for their useful comments.

REFERENCES1. F. Stajano and R. Anderson, “The Resur-

recting Duckling—Security Issues for Ad

Hoc Wireless Networks,” Proc. SecurityProtocols Workshop, LNCS 1796, Springer,1999, pp. 172�182.

2. F.-L. Wong and F. Stajano, “Multi-ChannelProtocols,” Proc. 13th Int’l Workshop Secu-rity Protocols, LNCS 4631, Springer, 2005.

3. M. Weiser, “Some Computer Science Issuesin Ubiquitous Computing,” Comm. ACM,vol. 36, no. 3, 1993, pp. 75�84.

4. W. Diffie and M.E. Hellman, “New Direc-tions in Cryptography,” IEEE Trans. Infor-mation Theory, vol. 22, no. 6, 1976, pp.644�654.

5. D. Dolev and A.C. Yao, “On the Securityof Public Key Protocols,” IEEE Trans. In-formation Theory, vol. 29, no. 2, 1983, pp.198�208.

6. S. Laur and K. Nyberg, “Efficient MutualData Authentication Using Manually Au-thenticated Strings,” Proc. 5th Int’l Conf.Cryptology and Network Security (CANS06), LNCS 4301, Springer, 2006, pp. 90�107.

For more information on this or any other comput-ing topic, please visit our Digital Library at www.computer.org/publications/dlib.


the AUTHORSFord Long Wong recently submitted his PhD dissertation in computer science atthe University of Cambridge. His research interests include cryptographic protocols,authentication, privacy, and ubicomp systems. He received his MEng in electricaland electronic engineering from Imperial College London and his MSc in statisticsfrom the National University of Singapore. He’s a member of the IEEE and the Inter-national Association for Cryptologic Research. Contact him at the Univ. of Cam-bridge, Computer Laboratory, William Gates Bldg., 15 JJ Thomson Ave., CambridgeCB3 0FD, UK; [email protected].

Frank Stajano is a senior lecturer in the Computer Laboratory of the University ofCambridge, where he received his PhD in computer science. His research interestsinclude computer security, ubiquitous computing, and privacy in the electronic soci-ety, and he’s the author of Security for Ubiquitous Computing (Wiley, 2002). He waselected a Toshiba Fellow in 2000. Contact him at the Univ. of Cambridge, ComputerLaboratory, William Gates Bldg., 15 JJ Thomson Ave., Cambridge CB3 0FD, UK;[email protected]; www.cl.cam.ac.uk/~fms27.

Lower nonmember rate of $29for IEEE Security & Privacy!S&P magazine is the premier magazine for security professionals.Each issue is packed with information about cybercrime, security & policy,privacy and legal issues, and intellectual property protection.

Top security professionals in the field share information you can rely on:

Silver Bullet podcasts and interviews • Intellectual Property Protection and

Piracy • Legal Issues and Cybercrime • and more!

www.computer.org/services/nonmem/spbnr

Subscribe now!

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 2.00333 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00167 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName /PDFXTrapped /False

/Description >>> setdistillerparams> setpagedevice

multichannel security protocols - university of...

Documents