On Measuring SSL-based Secure Data Transferwith Handheld Devices

Diana BerbecaruPolitecnico di Torino, Dip. di Automatica e Informatica

Corso Duca degli Abruzzi, No. 24, 10129, Torino (ITALY)

Abstract- The Secure Sockets Layer (SSL) security protocol islargely used nowadays by the World Wide Web to secure Internetcommunications and an increasing number of handheld devicesare provided by the manufactures with preinstalled applications(e.g. web browsers) and digital certificates in order to supportSSL in wireless environments too. We present first a comprehen-sive analysis of SSL protocol and the cryptographic algorithmsused as building blocks in the protocol. We demonstrate next thatSSL support embedded also in other applications for some mobiledevices does not impact significantly on overall application'sperformance when communicating with other parties.We wanted to use for our experimental setup, APIs and

tools that are either available for the majority of the handhelddevices or that can be downloaded and tested freely and withoutmajor modifications. This is the especially the case of applicationdevelopers, who preferably would not use modified versionsof cryptographic libraries and special drivers characteristic toacademic/commercial testing environments. We also developed atool named SSLPerf (SSL Performance) for testing SSL securityprotocol's performance when transferring either small amountsof data (e.g. credit card number) or of medium dimension(e.g. a document in PDF format), with handheld devices. We'vecompared the results obtained with SSLPerf on Windows CE-enabled Handheld and Pocket PCs and 'powerful' Windows2000/XP-enabled platforms with other related works.

I. INTRODUCTION

Today, an increasing number of mobile and handheld de-vices - e.g. laptops, Personal Digital Assistants (PDAs), cellphones, pocket and handheld PCs - are used to perform mobilecommerce (m-commerce) transactions, to search for specificdata and to exchange information with other mobile devicesor with fixed devices that are part of a broader network.Security becomes thus an important issue when storing, manip-ulating or communicating data in these environments. Securemechanisms and protocols are continuously investigated forsuch systems with limited computing, power and networkcapabilities and they address mostly the user identification,secure storage and access of information, secure execution ofsoftware and secure communications.

Secure communication is typically achieved by means ofseveral security protocols at various layers of the networkprotocol stack, e.g. IEEE.802.11 uses WEP [1] at the linklayer, while IPSec [2] provides security at the network layer,TLS/SSL [3] at the transport layer and SET at the applicationlayer. The security protocols rely on encryption or encryptionrelated mechanisms to provide security services. In practice,the security protocols make use of cryptographic algorithms,which are selected based on the security objectives that are

0-7803-9206-X/05/$20.00 ©2005 IEEE

to be achieved by the protocol. Thus, the cryptographic algo-rithm's features and its implementation influence in the end thesecurity protocol's performance. However, when measuringthe performance of a security protocol, the cryptographicalgorithms involved and their performance are not the onlyparameters to be taken into consideration. Other factors areimportant as well, such as the processor's clock rate, the net-work bandwidth, the delays due to operating system featuresand due to application context switching.The security protocols and the cryptographic algorithms

they contain must be first of all correct so that they providesecurity services like authentication, integrity or confidential-ity. A further requirement is the "interoperability" feature[4], i.e. the security protocols designed primarily for wiredenvironments should be supported (when possible) in wirelessenvironments also in order to obtain interoperable applications.

Further, it is worth mentioning that many handheld andmobile devices are constrained by the environments theyoperate in and the resources (e.g. battery, memory, processor)they possess. For such systems, several challenges need tobe addressed in order to enable secure computing and com-munication. One challenge in battery-powered devices is themismatch between the energy and the security performancerequirements. This challenge is called also the battery gap [5],[6]. Another challenge is the impossibility to utilize strongcryptographic functions for implementing security protocolson mobile devices with low processing capability and limitedmemory resources [7], [8]. This is named the security pro-cessing gap and it states basically that some wireless devicescannot support cryptographic operations required by the se-curity protocols within reasonable amounts of time or at highdata rates. For example, a PalmIlIx handset requires almost 3.5minutes to perform 512-bit RSA key generation and 7 secondsto perform digital signature generation even if the CPU iscompletely devoted to perform cryptographic operations [8].Another challenge is the ability to configure (in hardwareor software) the wireless devices to use only some securityprotocols so that to obtain a gain in the efficiency of securityprocessing. Thus, the flexibility challenge refers for exampleto the case of a wireless LAN enabled PDA connecting to aVPN and that might need to execute WEP, IPSec and SSLfor secure web browsing even though some of the securityprotocols are not always required. It is also desirable to allowfor easy upgrade to future security protocols and evolvingstandards as well as for rapid prototyping methods, applicable

409

to industrial environments.This paper addresses the security processing challenge since

it deals with evaluating SSL protocol's performance in base ofsome parameters that can dramatically impact on the securityprotocol itself and (after all) on the SSL-enabled application'sperformance itself. For most secure wireless transactions,the processing at the client is dominated by the public keyalgorithm [9]. Nevertheless, this is not the only parameter to beconsidered. Other parameters, like the processor architectureand the data rate are important as well when evaluatingSSL security protocol. The parameters used in our SSL testmethodology are explained in Section II. The experimentalsetup and the tools we've used for measuring SSL-based datatransfer are given in Section III. Section IV shows the resultsobtained and provides a comparison with other related works.Finally, Section V gives the conclusions and the future work.

II. MOTIVATION AND METHODOLOGYMost of the SSL-enabled applications for small wireless

devices nowadays are either browser-based and usually requireconnecting to web servers over wireless connections to provideweb services [7], [10]. Other specific purpose applications usevarious 'in-house" built SSL client libraries, that are usuallyadapted for different small device platforms. PKI applicationdevelopers instead will most probably want to use crypto-graphic libraries and tools freely available when integratingsupport for security protocols in their applications. We wantedto provide thus some guidelines for this type of users and toprovide an estimation of the results to be expected in baseof some precise and controllable parameters. Optimizations ofthe tools specific to laboratory environments for measuring asexactly as possible the cryptographic algorithm's performancein not the target of this work. Moreover, SSL has been studiedand optimized intensively for e-commerce servers, networkrouters, firewalls and VPN gateways [9], [11]. Thus, thecase when the SSL server is a handheld device with limitedresources is still an open issue. This situation would be mostprobably to be encountered in the recently proposed PersonalArea Networks (PANs).PANs [12] denote several components in the proximity of

a person that are interconnected via wireless connections andthat are able also to access broader networks. PANs are deviceensembles composed of a wide variety of platforms withdifferent processing capabilities and using technologies likeIrDA, FireWire, WiFi or Bluetooth [13] for communicatingbetween them. From the convenience point of view, this isa very promising technology. With PANs, the user wouldpotentially have the ability to approach the desk in their officeand the working files would be automatically downloadedto/from his PDA to the workstation PC, or when a personis approaching his car, the smart vehicle would automaticallyadjust the seat and stereo setting at user's likings based onuser's indentification and his personalized settings. Neverthe-less, security is at an early stage in this area [14] and PANsand Bluetooth Wireless Personal Area Networks (BT-WPANs)should be investigated not only from the functional perspective

but also in terms of times required for providing the securityservices. SSL could be used to provide security services inPANs, but evaluation of delays in terms of the communicationtechnologies used or in base of data rate supported and ofprocessors' capabilities were not studied yet.

A. The SSL security protocol in briefSSL offers encryption, source authentication and integrity

protection of application data over insecure public networks.SSL operates above a reliable transport protocol (e.g. TCP)and it comes below the application layer protocols like HTTPor IMAP. The protocol is very flexible and can accomodate avariety of algorithms for key agreement, encryption and hash-ing. The standard specification explicitly lists combinations ofthese algorithms, called cipher-suites.An SSL session protocol is layered and has two layers:

the SSL Handshake protocol and the SSL Record protocol.The SSL Handshake protocol is the most complex part ofSSL with many possible variants, like the full handshake (full)and the abbreviated handshake (abbr.). It allows the client andthe server to authenticate each other, negotiate the encryptingalgorithm and the keys for encryption before the applicationstarts transmitting or receiving the data. The SSL Recordprotocol provides encapsulation to the upper layer protocols.It fragments the data into data blocks of 16384 bytes or less.For example, in SSLPerf we've allowed to set the dimension ofthe fragmenting block size to 8192 bytes. SSL fragments themessage to be transmitted, optionally compresses it, appliesmessage authentication code (MAC), encrypts it and transmitsthe message using the services provided by TCP. At thereceiving end the message is received, decrypted, verified,decompressed, reassembled and delivered to the upper layer.We will describe shortly next the SSL handshake that uses

RSA public key exchange. When an SSL client establishesa connection with a server for the first time, it executes afull handshake. In the first two messages exchanged the clientand the server exchange random nonces and then negotiatea mutually acceptable cipher suite. The server sends thenits RSA public-key inside an X.509 certificate. The clientverifies the server's public-key and it generates afterwards a48-byte random number (the pre-master secret) and sends itencrypted with the server's public key. The server uses its RSAprivate-key to decrypt the pre-master secret. Both the clientand the server use the pre-master secret to create a mastersecret (common for more connections) which, along with thepreviously exchanged nonces, is used to derive the cipher keys,initialization vectors and MAC different for each connection.SSL employs thus two different encryption mechanisms:

public-key and "bulk" encryption. The actual data being trans-mitted is encrypted using a symmetric encryption algorithm(i.e. "bulk" encryption) and typically uses 40- or 128-bit keys.Nevertheless the difference in symmetric key length has asmall impact on performance. The shared secret instead isencrypted using public-key encryption and the key lengthsare typically 512- or 1024-bit. The key size for the public-key encryption can make an appreciable difference in the

410

performance of SSL transactions. An abbreviated SSL hand-shake is encountered when the client proposes to the serverto reuse the master key derived in a previous session byincluding that session's (non-zero) ID in the first message.The server indicates its acceptance by echoing that sessionID in the second message. Thus, in this case the exchange ofcertificates doesn't take place and no public-key cryptographicoperations are performed, so fewer messages are exchanged.Consequently, an abbreviated SSL handshake is significantlyfaster than a full handshake.

B. SSL test methodologyGuidelines for structuring tests to benchmark SSL secured

web sites are provided in [15]. This work gives useful indica-tions on how to structure the tests with SSL to simulate some"real world" traffic patterns, and we've considered some ofthem in our tests, even though in the present paper we are notdealing with HTTPS traffic. The patterns are given below:

a) Session ID re-use: An important pattern is how oftenthe handshake portion of SSL is repeated. This initial activity,including the exchange of a shared secret and the negotiationof a bulk-encryption protocol is the most time-consuming andcomputationally expensive SSL operation.

b) Encryption strength: The key lengths used for public-key encryption are usually either 512- or 1024- bit and thekey size can make an appreciable difference in performance.Table I summarizes the relative strength of encryption keysrequired for different types of cryptographic algorithms. Theseare roughly estimates taken from [16]. The majority of SSLtransactions today use 1024-bit keys and consequently, thiskey size should be used when creating an SSL benchmark.Bulk encryption typically uses 40- or 128-bit keys and thedifference in key length has a small impact on performance.

TABLE IKEY SIZES RECOMMENDED FOR SECURITY

YearSymm. key schemes(key size in bits)Asymm. key schemes(key size in bits)

1982 2013 2055 2075 2159 224256 80 112 128 192 256

512 1024 2048 3072 7680 15360

c) Traffic type: The effect of protocol features such asSession ID re-use can vary dramatically depending on the typeof the traffic being encrypted. In the tests we've consideredsingle clients operating at one time and we've modified thesize (small, medium) of the data items exchanged.

d) Data rate and network latency: In "real" environ-ments, the client-to-server latency could be significantly higherthan in the test environment. The one-to-one communicationnature of devices with infrared ports should provide in ouropinion a quite accurate measure of SSL performance in anenvironment where no interference should occur (at an instantof time) between two communicating devices, making thus the

network traffic delays close to zero. Varying instead the datarate of the device, it should be possible to note the variationof SSL performance too, i.e. higher the data rate better theSSL performance should be, if the processor supports it.Additionally, the focus of our work was to individuate andtest also the other factors, such as the processor architecture,the block size used by SSL for fragmenting the applicationdata and and the operating system used, which also proved toaffect the SSL performance.

III. EXPERIMENTAL SETUP AND TOOLS

The wireless environment is populated with various kindsof devices and all devices have different performance becauseof their varying architecture: CPU, memory, and battery. Inour study the devices selected for study are: one HP Compaqmobile laptop nw8000, a Dell Latitude C800 Intel PentiumIII (Coppermine) laptop, a Compaq iPAQ Pocket PC and anHP Jornada 720 Handheld PC 2000. The HP Compaq mobilelaptop has an Intel Pentium Mobile processor at 1.7 GHz,1GB of RAM, it runs Windows XP Professional and it allowsfor infrared (IR) communication at speed rates from 9.6 kbpsup to 4Mbps and for Bluetooth communication. The DellLatitude C800 laptop has an Intel Pentium III (Coppermine)processor at 1GHz with 256 MB of RAM, it runs Windows2000 Professional and it allows also for IR communicationwith speed rates from 9.6 kbps up to 4Mbps. The HP Jornada720 has a 206 MHz 32-bit StrongARM SA 110 processor with32 MB SDRAM, it runs Microsoft Windows CE for HandheldPC 2000 and allows for IR communication up to 115.2 Kbps.The Compaq iPAQ Pocket PC (h5500) has an Intel XScaleprocessor at 400 MHz with 128 SDRAM, it runs MS PocketPC and allows for IR communication up to 115.2 Kbps andBluetooth support.The tools used are given below:

e) SSLPerf: SSL Performance (SSLPerf) is a small sizetool we've implemented for measuring the secure data transferover SSL channels. SSLPerf is basically composed of threemodules: the interface module, the networking module and thecryptographic module. The interface module is used for gettinginput values for the user, e.g. the file to be transferred or toconfigure the other modules, e.g. switch between Bluetoothand IR for communication channel. The networking module iscomposed basically of the functions used for (IrDA, Bluetooth)socket communication while the cryptographic module con-tains the functions for SSL connection setup and managementand the support for cryptographic operations, e.g. public-keyor symmetric key encryption/decryption.

f) OpenSSL library for Windows CE: OpenSSL library(http://www.openssl.org) starting with vO.9.7 can be built forWinCE platform with the help of three external tools: theMicrosoft eMbedded Visual C++ 3.0, the wcecompat com-patibility library and the ceutils for running automated tests(http://www.essemer.com.au). Additionally, it is required tohave Perl for win32 installed (e.g. ActiveState Perl) and aC compiler, among Visual C++ (advised), Borland C or GNUC.

411

g) Microsoft eMbedded Visual C++ 4.0 & Handheld2000 SDK: These packages were used to update SSLPerf forPocket PC 2000 and Handheld PC 2000 platforms. They allowalso integration of Bluetooth support into SSLPerf. To transferthe SSLPerf from the development platform on the Pocket PCand Jomada devices, Microsoft ActiveSync synchronizationsoftware was used.

IV. RESULTS

For SSL connection establishment a typical SSL handshakerequires the client to perform two RSA public-key operations:(server) certificate verification and key exchange. Certificateverification means that the client has to verify the digitalsignature of the CA that issued the server certificate. Thisinvolves decryption with the public key of the CA. Keyexchange means that the client encrypts the pre-master secretusing the public key of the server.

TABLE II

MEASUREMENTS OF RSA OPERATIONS ON DEVICES USED

TABLE IIIAPPROXIMATE CONNECTION ESTABLISHMENT TIMES (IN SECONDS) FORIPAQ POCKET PC (AS SSL CLIENT) WITH SSLPerf, DATA RATE 11 5.2 KBPS

RSA Operation iPAQ Jornada HP Com-(key length) Pocket PC Handheld PC paq laptop

(400 MHz) (206 MHz) (1.7 GHz)Sign (512-bit) 0.0260 s 0.0460 s 0.0016 sVerify (512-bit) 0.0010 s 0.0020 s 0.0002 sSign (1024-bit) 0.0560 s 0.1070 s 0.0089 sVerify (1024-bit) 0.0030 s 0.0060 s 0.0005 sSign (2048-bit) 0.2950 s 0.5670 s 0.0564 sVerify (2048-bit) 0.0090 s 0.0170 s 0.0016 sSign (4096-bit) 1.8490 s 3.5500 s 0.3756 sVerify (4096-bit) 0.0300 s 0.0580 s 0.0056 s

Table II shows that a RSA public key operation measuredwith SSL Perf on a processor at 400 MHz takes approximately0.03 s for signing and 0.001 s for verifying using an RSA keyof 512 bits length and grows slowly up to approximately 2 sfor signing and 0.003 s for verifying for an 4096-bit RSAkey. Even though the software and the plaforms used in otherrelated works are different, these results are encouraging. Theperformance of KSSL'RSA [7] for example is of 0.8-1.5 s forverifying on a 20 MHz Palm CPU for RSA key sizes of 768bits and 1024 bits respectively. Tests performed on a PalmPilotrunning a Motorola DragonBall chip (68K family) at 16 MHzreport that a 512 bit RSA verify operation takes instead almost1.5 s [8].The SSL connection establishment latency measured with

SSLPerf for different cipher suites is illustrated in Table III. Forthe description of the ciphers (e.g. AES256-SHA means thatRSA is used for key exchange and authentication, AES(256) isused for encryption and SHAI is used for MAC ) it is enoughto run the openssl's command "openssl ciphers -v". Duringtests, the iPAQ Pocket PC (used as client) and the other devices(used as servers) were relatively close to each other (e.g. 2 cm)and communicate over infrared ports. For the RSA-based SSLhandshake we used the same server certificate, containing a1024-bit RSA public key. The tests run on the StrongARM

processor SA-1110, capable of delivering 235 MIPS at 206MHz, confirm the results obtained in [17]. In the above paper,authors state that a 300 MIPS handset processor can support1024-bit RSA-based authentication at connection latencies of0.5 seconds and 1 seconds but not at 0.1 seconds.

Table IV illustrates the overhead introduced by SSL, whenthe OpenSSL cipher suite negotiated among the iPAQ (as SSLclient) and the other devices (as SSL servers) is AES128-SHA and the data rate of the communication infrared channelis 115.2 Kbps. We've simulated tests when SSL fragmentsapplication data in blocks of either 8192 bytes or 16384 bytes,both for full and the abbreviated handshake. We measuredthe overall time required for transmitting the data. This timeincludes the times for SSL connection establishment and forencrypting and transmitting data. It took 0.124 s and 91.48 s

to send 1K (1024 bytes) and respectively 909 K of data fromJomada to iPAQ over a "no SSL" channel and 1.394 s and96.76 s respectively to send it over an SSL channel with fullhandshake, data rates and the negotiated cipher suite as inTable IV.

Discussion of results. SSLPerf is not a professional bench-marking tool, consequently it was not optimized for exampleto ensure the fastest data transfer possible. We used SSLPerfrather to measure the delays introduced by SSL and fromthis point of view the SSLPerf tool requiring almost 90 sfor transferring 909 KB has a much less performance whencompared with the tests in [18]. In any case, we must notethat the results of 1.14 s required for full handshake (for 1024bit keys) in [18] is close to our results, as well as the SSLoverhead.The results obtained for SSL connection establishment with

iPAQ Pocket PC evidentiate a good performance. In compar-ison, tests performed with a Palm MIDP at 20 MHz resultin an SSL handshake that takes from 2 s for an abbreviatedhandshake up to 10 s for a full handshake [7]. Thus, the CPU

412

SSL cipher Win XP Win 2000 Jornadasuite negotiated (SSL server, (SSL client, (SSL server,(OpenSSL 1.7 MHz, 1GHz, 206 MHz,naming) handshake) handshake) handshake)

full abbr. full abbr. full abbr.AES256-SHA 0.330 0.223 0.509 0.260 0.902 0.432DES-CBC3-SHA 0.362 0.222 0.491 0.262 0.866 0.325RC4-SHA 0.356 0.221 0.489 0.259 0.891 0.401IDEA-CBC-SHA 0.330 0.218 0.490 0.260 0.779 0.362EDH-RSA-DES- 1.071 0.573 1.223 0.623 1.314 0.803CBC3-SHADHE-RSA- 0.644 0.552 0.821 0.626 1.121 0.823AES256-SHADHE-RSA- 0.645 0.553 0.815 0.640 1.321 0.723AES 128-SHAAES 128-SHA 0.358 0.244 0.984 0.286 1.126 0.556

TABLE IVAPPROXIMATE SSLPerf DATA TRANSFER TIMES (IN SECONDS) WITH IPAQ

Parameter Win XP Win 2000 Jomada(SSL server, (SSL server, (SSL server,1.7 MHz) 1GHz) 206 MHz)1K 909K 1K 909K 1K 909K

No SSL 0.118 90.031 0.135 91.730 0.173 93.390SSL, 8192 1.050 94.150 1.155 96.150 1.417 97.140bytes, fullSSL, 8192 0.426 93.110 0.467 95.110 0.783 96.550bytes, abbr.SSL, 16384 0.509 90.502 1.204 92.810 1.415 94.433bytes, fullSSL, 16384 0.446 90.432 0.490 91.540 0.814 94.207bytes, abbr.

data rate would clearly determine better SSL performance, ifcrypto operations are supported by the processor architecture.For example, for Bluetooth device allowing up to 723 Kbpsdata rate in normal environments we expect to obtain bettertimes both in terms of SSL connection establishment and ofdata tranfers. Experimental tests are currently in course forthis case. Furtheremore, features specific to a different traffictype would also result in a different (less) delay. For example,the overhead of Web browsing largely depends on whetherpersistent HTTP connections are used or a new connection isopened per downloadable component. Using the "Connection:Keep-Alive" HTTP header, it is possible to allow multipledata transfers over a single TCP connection, and consequentlyobtain a much better transfer time.

enhancements clearly have a direct impact on the speed ofSSL's cryptographic operations. Only for devices with lowCPU clock rate tiny smart cards could be further used for hard-ware acceleration. However, even on CPUs with higher clockrates, for some security protocols like SSL and that generallyuse RSA, the security of the RSA algorithm is derived fromthe NP-hard problem, integer factorization. Thus, RSA canprovide high security if the modulus is a large integer (e.g.2048 bits) whose factoring becomes extremely difficult. Forexample, RSA recommends that 1024-bit keys may be useduntil 2010 and 2048-bit keys until 2030. Thus, in the futurethe basic crypto data computation must be performed using alarge key, making it computationally expensive. Consequently,the SSL connection latency for a RSA key with high modulussize (e.g. 4096 bits) would increase. It is not clear whetherwireless security processing gap would be a problem in PANswith high data rates. To support a data rate of 10 Mpbs forexample, the security processing requirement is 651.3 MIPS,while a StrongARM processor SA-1110 can deliver around235 MIPS at 206 MHz [19].

V. CONCLUSIONS AND FUTURE WORKEstablishing an SSL connection (in SSLPert) from an iPAQ

(400 MHz) to a Jomada (206 MHz) requires approximately1 s and is about 3 times more expensive than establishingthe connection to a laptop at 1.7 GHz for a full handshakewith 1024 key length. SSLPerf indicates that the overheadthe SSL introduces when transferring small amount of data(about 1K, in text format) is significant since it takes about10 times more time than transferring data over a "no SSL"channel. Nevertheless, for medium size data (about 1MB, inPDF format) sent to Jomada, the SSL overhead is - 3 s (for a1024 public key length, 8129 bytes SSL fragmentation) and1 s when data is sent to laptop or the SSL fragmentation blockhas the maximum size (16K). We believe this overhead is smallenough to allow for secure data transfers between devicesplaced within a short range, e.g. inside device ensemblesforming PANs. The parameters we've taken into account whenstructuring tests with SSL in this paper were the processor'sclock rate, the encryption strength and the data rate. Higher

REFERENCES[1] LAN MAN Standards Committee of the IEEE Computer Society, Wire-

less LAN Medium Access Control (MAC) and Physical Layer (PHY)Specification: IEEE standard 802.11, 1990.

[2] IPSec Working Group. http://www.ietf.org/html.charters/ipsec-charter.html

[3] SSL 3.0 Specification. http://wp.netscape.com/eng/ssl3/.[4] W. Stallings, "Cryptography and Network Security: Principles and

Practice", Prentice Hall, 1998.[5] N.R. Potlapally, S. Ravi, A. Raghunathan, and N. K. Jha, "Analyzing

the Energy Consumption of Security Protocols", Proc of InternationalSymposium on Low Power Electronics and Design, Seoul, Korea, 2003,pp: 30-35.

[6] S. Hirani, "Energy Consumption of Encryption Schemes in WirelessDevices", Master of Science in Telecommunications thesis, Universityof Pittsburgh, 2003.

[7] V. Gupta, and S. Gupta, "Experiments in Wireless Internet Security",Proc. of Wireless Communications and Networking Conference, Orlando,Florida, 2002, pp: 860-864.

[8] N. Daswani, and D. Boneh, "Experimenting with Electronic Commerceon the PalmPilot", Proc. of Financial Cryptography, LNCS, Vol. 1684,1999, pp: 1-1 6.

[9] G. Apostolopoulos, V. Peris, P. Pradhan, and D. Saha, "SecuringElectronic Commerce: Reducing SSL Overhead", in IEEE Network,14(4), July/August 2000, pp: 8-16.

[10] S. Berger, S. McFaddin, C. Narayanaswami, and M. Raghunath, "WebServices on Mobile Devices - Implementation and Experience", Proc.of Fifth IEEE Workshop on Mobile Computing Systems & Applications,Monterey, California, 2003, pp: 100-109.

[11] K. Kant, R. Iyer, and P. Mohapatra, "Architectural Impact of SecureSockets Layer on Internet Servers", Proc. of International Conferenceon Computer Design, Austin, Texas, USA, 2000, pp: 7-14.

[12] T.G. Zimmerman, "Personal Area Networks (PAN): Near-Field Intra-Body Communication", Master's degree thesis, MIT Media Laboratory,Cambridge, MA, 1995.

[13] Bluetooth SIG, "Specification of the Bluetooth System", Core version1.2, November 2003.

[14] V. L. Hovar, "Personal Area Networks: How Personal Are they?", SANSSecurity Essentials, SANS Institute 2001, whitepaper.

[15] Intel: Designing a Secured WebsiteWhat you need to know about SSLBenchmarking. http://cnscenter.future.co.kr/resource/rsc-center/vendor-wp/intel/sslbenchmarking.pdf

[16] L. Fibikova, and J. Vyskoc, "Practical cryptography - the key sizeproblem: PGP after years", 21 December 2001.

[17] S. Ravi, A. Raghunathan, and N. Potlapally, "Securing Wireless Data:System Architecture Challenges", Proc. of International Symposium onSystem Synthesis, Kyoto, Japan, 2002, pp: 195-200.

[18] P. Argyroudis, R. Verma, H. Tewari, and D. O'Mahony, "PerformanceAnalysis of Cryptographic Protocols on Handheld Devices", Proc. ofthe Third IEEE International Symposium on Network Computing andApplications, Cambridge, MA, USA, 2004, pp: 169-174.

[19] Intel StrongARM SA-110 Microprocessor Brief DataSheet, available athttp:// www.intel.com/design/strong/datashts/27824 1.htm

413