AMY: A SIMPLE AND SECURE WAY TO CONNECT DEVICES USING PAIRING-BASED CRYPTOGRAPHY Wook Shin, Kazuhide Fukushima, Shinsaku Kiyomoto, Toshiaki Tanaka KDDI R&D Laboratories, Inc., Saitama 356-8502, Japan

ABSTRACT We present the design of an apparatus that creates a personal private communication channel over computer-embedded devices. The prototype implementation of the apparatus demonstrated that it can securely and intuitively link devices with no contact with an online server while imposing low overhead. INTRODUCTION By enabling diverse computer-embedded devices (the devices, hereinafter) to cooperate with each other instantly, we can enhance their capability and encourage the advent of new services and applications. The benefits of combining data or functionality of the devices are accompanied by a stipulation: users must be able to connect the devices easily and securely. Existing methods of establishing secure connections among devices often impose complicated workflow and administrative costs, and are sometimes insecure. Moreover, communication channels are not always owned by the creators, especially when the underlying network is being administered by someone else. These problems can be reduced by providing an apparatus equipped with Pairing-based cryptography (PBC) primitives and that facilitates authentication and key negotiation among devices. This paper presents a prototype of the apparatus implemented on a cell phone, demonstrating affordable performance overhead and sufficient security while brokering network-enabled devices. DESIGNING A MAGIC WAND USING PBC The communication channel we want to create delivers private information that needs to be protected, and is also personal in that the user who creates the channel owns it, where ownership implies the right to create and destroy a channel, add and remove members of a channel, and recover encryption keys. We call such a communication channel a personal private channel (PPC). To circumvent a man-in-the-middle attack and eavesdropping while a PPC is created over devices, the devices need to authenticate each other, and safely negotiate message encryption keys. Although there are off-the-shelf ways of setting up a protected network over the devices, they do not provide sufficient usability and security. They make users to enter humangenerated numbers to devices, or copy machine-generated keys from one to another by going through a number of steps manually1 . Otherwise, they require online servers2 that are 1 Bluetooth 2 Wi-Fi

and Wi-Fi Protected Access-Personal Protected Access-Enterprise

Charge

1 (create security parameters)

2 Cast

3 Cast

(distribute security parameters)

4 Handshake (negotiate an encryption key)

Fig. 1.

Creating a PPC using AMY

accompanied by prohibitive costs and administrative burden. Moreover, users who create the network may not have control over it when the authentication information or encryption keys are managed by a third party. As an alternative, we propose the use of an interface apparatus called AMY (Authentication Manager for You). AMY mechanically generates and distributes security parameters to devices via a location-limited channel (LLC) [1] implementable by state-of-the-art technologies3 . Next, the devices can negotiate encryption keys autonomously without prior interaction or consultation with an online third party. Figure 1 shows how to use AMY, which is analogous to using a magic wand: Charge it with spells, cast the spells on devices one after another, and then the enchanted devices can handshake and talk to each other privately. Charging is the phase where a user creates a private channel c. The following channel parameters are generated as well: A channel secret (CSc ), a broadcast ID (IDnet ) for the channel, private/public key pair for broadcast (Privnet /Pubnet ). The channel secret and all identifiers are randomly chosen. PubIDi , the public key of IDi , is calculated by hash(IDi ). PrivIDi , the private key, is calculated by CSc *PubIDi . AMY has a unique ID, IDamy , but the corresponding private/public key pair differs for each channel. Casting occurs when the user brings AMY to a device, and messages that appear in Figure 2 are exchanged via LLC. The first message is used to check if the channel already exists on the device. The second one is to authenticate AMY: After a device returns nonce, AMY calculates a sign, nonceCSc , and returns it. The device can verify it by checking if e(Pubi , sign) is equivalent to e(Privi , nonce). Only AMY knows CSc and can generate a correct sign. This authentication procedure fixes the flaw existing in the previous protocol we proposed for an ad-hoc network in [2], which enables a malicious member to pretend to be AMY. The third message includes 3 Communication methods where the participants are visually identifiable, e.g., IrDA, Giga-IR, TransferJet, barcode and camera, etc.

TABLE I E XECUTION TIMES OF PBC FUNCTIONS AID

A

Device

PubAID Check if the channel exists

“No”, nonce, AddrA Create necessary parameters & Record the device’s address and IDA as a participant

nonceCSc, PubAID, IDNet, PubNet, PrivNet, IDA, PubA, PrivA, {(IDj, Addrj)} Record the created channel information

Fig. 2.

Casting protocol

A

B

Function Name

Description

initGeneralBytes() setGeneralBytes() finGeneralBytes() makeNonce() addNonce() getSHA1() concatData() makeDevPubKey() makeDevPrivKey() applyPairing() simpleSign() veryfySimpleSign() makeSecParamFull() makeDevAll()

Prepare memory space Initialize allocated space Free allocated memory space Generate a nonce Add integer to a nonce Message digest. MD() Concatenate two data Do hashmap an ID. hash() Do CSc * hash(ID) Apply pairing Sign by messageKey Verify the simple sign Generate channel parameters generate necesary parameters for device

Phone (msec) 0.12 0.00 0.10 0.10 0.00 0.08 0.05 12.50 53.60 66.85 63.40 146.14 131.28 63.04

PC (µsec) 0.40 0.40 0.00 1.20 0.40 1.10 10.00 0.45 2020.00 3360.00 2370.00 7260.00 4950.00 2500.00

PubAID, IDA, nA, MD(PubAID, e(PrivA, PubB), nA, 0) Calculate hash(PubAID, e(PubA, PrivB), nA, 0)

nB, MD(PubAID, e(PubB, PrivB)), nA+1, nB, 1 Calculate hash(Pub_AID, e(PrivA, PubB), nA + 1, nB, 1)

Fig. 3.

Handshake protocol

all necessary parameters for a device to join the channel and to negotiate secrets with other channel members. Assuming IDA and IDB are the IDs of devices A and B, respectively, they inherently share the information, e(PrivA , PubB ), which is equivalent to e(PubA , PrivB ) by the bilinearity in PBC. Only with each other’s ID can A and B start communication securely. Neither any previous interaction nor an online server is required. HandShake steps are shown in Figure 3. Based on the inherently shared information between two devices, each assures their opposite is the legitimate channel member that it wants to talk to. Message encryption keys are derived from the shared information. PROTOTYPE ON A CELL PHONE To discuss the feasibility of our design with performance factors, we implemented a prototype of AMY using an ordinary cell phone4 . To carry out the PBC operations efficiently, we used the PBC library built for lightweight systems [3], which implements the Duursma-Lee algorithm and ηT pairing over finite fields F397 . The cryptographic power of the PBC algorithms we use is equivalent to a 154-bit ECC-based scheme. It also corresponds to the security level of a 77-bit symmetric scheme [4]. All cryptographic primitives necessary to execute our protocols are implemented on the cell phone and also on a desktop PC5 ; this allows execution times in both environments to be compared. Table I presents the average execution time of the primitive functions. In the casting protocol, the estimated execution time for conducting cryptographic operations of AMY is 195.9 milliseconds (ms). If the other part, the device, 4 Toshiba W54T equipped with Qualcomm’s MSM6550 Chipset running BREW OS and IrDA (IrSimple) 5 Pentium4 3.00GHz and 2GB Main Memory

has computing power equivalent to our PC, it would take 7 ms to complete the cryptographic operations, while it would take about 150 ms if the device has the same capability as our cell phone. The message transmission can be finished within 0.8 seconds with the standard infrared option of our phone. In the handshake protocol, the cryptographic operations between two cell-phone level embedded devices can be completed in 135.2 ms. In the case of PC-level terminals, it would take only 7 ms. The size of exchanged messages is 286 bytes in total. It imposes negligible delay on a standard wireless network. Once a channel is created, the casting and handshake protocols can be completed in less than 0.5 seconds. Namely, a recognizable delay depends solely on how fast users can move their arms. CONCLUSION We show it is feasible to implement an apparatus that create a personal and private communication network over computer embedded devices using PBC, with reasonable overhead and sufficient security. Our scheme is better than existing methods in terms of usability and security, so that even technologynaive users can easily and almost immediately set up a secure network using a friendly interface. Moreover, the created network is owned by the individual who created it. The apparatus is broadly applicable to various application areas where a private network needs to be created by interconnecting devices, e.g., home network, health monitoring systems [5], and data exchange in mobile devices, regardless of the location or security domain where the connection is created. R EFERENCES [1] D. Balfanz, D. K. Smetters, P. Stewart, and H. C. Wong, “Talking to strangers: Authentication in ad-hoc wireless networks,” in Proc. Network and Distributed Systems Security Symposium, 2002, pp. 23–35. [2] W. Shin, C. A. Gunter, S. Kiyomoto, K. Fukushima, and T. Tanaka, “How to bootstrap security for ad-hoc network: Revisited,” in 24th IFIP International Information Security Conference, 2009, pp. 119–131. [3] M. Yoshitomi, T. Takagi, S. Kiyomoto, and T. Tanaka, “Efficient implementation of the pairing on mobilephones using brew,” IEICE - Trans. Inf. Syst., vol. E91-D, no. 5, pp. 1330–1337, 2008. [4] Certicom research, “The standard for efficient cryptography – sec 1: Elliptic curve cryptography,” Sep 2000. [5] M. J. May, W. Shin, C. A. Gunter, and I. Lee, “Securing the dropbox architecture for assisted living,” in Formal Methods in Software Engineering (FMSE ’06). ACM, 2006.