sumption of RSA and ECC algorithms such as digital signatures and key ... also required as part of Class 3 security for data transactions in the WTLS standard.
A Variation of the WTLS Authentication Protocol for Reducing Energy Consumption in Wireless Devices Phongsak Prasithsangaree and Prashant Krishnamurthy Telecommunications Program Department of Information Science and Telecommunications University of Pittsburgh 135 N. Bellefield Ave, Pittsburgh, PA, 15232, USA. Tel +1 412-624-4099, Fax +1 412-624-2788 {phongsak, prashant}@sis.pitt.edu
Abstract. Energy efficiency has been an important factor in protocol design in wireless networks where small handheld wireless devices rely solely on battery power. Security is also of great concern in wireless networks. Several security protocols adapted from wired networks have been used in wireless networks to provide identity authentication. Security protocols could contribute significantly to energy consumption, especially authentication protocols such as Wireless Transport Layer Security (WTLS) or Transport Layer Security (TLS) Handshake protocol that are based on computationally intensive public key cryptography. There have been many efforts trying to reduce cryptographic load and energy consumption at wireless devices. Some are complicated and others may not comply with existing WTLS/TLS standards. In this paper, we propose a simple variant of TLS Handshake protocol for mutual authentication and key exchange, which reduces energy consumption in wireless devices. The proposed protocol uses RSA and ECC algorithms differently to make the Handshake protocol more energy efficient. With our proposed protocol, we can save about 25% compared to 1024-bit RSA or 70% compared to 163-bit ECC Handshake protocol. Our proposed protocol can also be easily integrated into the standard WTLS protocol with small modification.
1. Introduction Energy efficiency is one of the most important factors in protocol design in wireless networks [1]. Energy consumption is of great concern for wireless devices since they operate with limited battery power. From Moore's law, the number of transistors in a chip will be doubled every 18 months [2]. It implicitly says that the power of computing will grow exponentially also. However, the capacity of battery is growing linearly, and this introduces a “battery gap” which is the difference between the power required by the computing and the battery capacity [2, 3]. It is believed that fuel cells may replace batteries; however, they are still too big and too expensive for wireless devices and are unlikely to be used prevalently until 2009 [4]. Thus, battery power tends to be a very limited resource for small wireless devices.
In wireless networks, components contributing to energy consumption include not only the transmission process but also computation required for a security service such as identity authentication. The standard authentication protocol for Wireless Application Protocol (WAP) enabled devices is Wireless Transport Layer Security (WTLS) [5], which is similar to the popular Secure Socket Layer (SSL) [6] or Transport Layer Security (TLS) [7] protocol. The SSL/TLS protocol is widely used to secure various network application protocols. It is the de facto standard for webbased transactions for e-commerce (such as online banking and shopping). The SSL/TLS protocol consists of four protocols, of which we are interested in the Handshake protocol. The Handshake protocol provides server authentication and optional client authentication. It enables the negotiation of a “cipher suite” which specifies which cryptographic algorithms can be used to provide authentication, confidentiality, and data integrity. The Handshake protocol is also used to establish a shared master secret (key) using a public key cryptography (PKC) algorithm. In the WTLS standard, two PKC algorithms are recommended, RSA [8] and Elliptic Curve Cryptography (ECC) [9]. RSA is based on the mathematically hard integer factorization problem. It typically involves modular exponentiation of 1024 bit numbers. ECC is based on the hard discrete-logarithm problem and typically involves several operations on 160 bit numbers. Both tend to be computationally intensive draining the battery of small wireless devices. Using RSA or ECC as is with the WTLS protocol may not be energy efficient. Several efforts have tried to reduce the energy consumption of the WTLS/TLS protocol. In [10], the computational complexity of public key encryption has been studied on an embedded processor. This work uses several mathematical techniques to improve the performance of public key algorithms. Gupta et al. [11] studied the performance of ECC for Handshake protocol. Several experiments were run on a wireless client and a server, and results are compared to those of RSA in term of latency at the client and the server. In [12], Karri and Mishra study an optimization of energy consumption of SSL protocol. They use different compression algorithms to reduce the size of the exchanged messages in order to reduce energy consumed by the transmission processes. There are also several efforts trying to reduce cryptographic load on client’s devices by moving it to servers which are more powerful [13, 14]. However, they are not standardized and are probably too complex which may lead to implementation flaws. In this paper, we propose a simple method of reducing the energy consumption using a variation of the TLS protocol. We use two algorithms, RSA and ECC, to complement each other to minimize the energy consumption of Handshake protocol. Our proposed protocol is simple, yet effective and complies with the existing standard. The proposed idea here seems to be quite obvious, but no prior work has really discussed this approach or studied its performance. The rest of this paper is organized as follows. We discuss the Handshake protocol, RSA, and ECC protocols in Section 2. Then, we describe our proposed variation of the Handshake protocol based on a combination of RSA and ECC in Section 3. We discuss the estimation of energy consumption of RSA and ECC algorithms such as digital signatures and key exchanges in Section 4. We show the comparison results of our protocol with existing protocols in Section 5, and we conclude our work in Section 6.
2. Background
2.1 The WTLS/TLS Handshake Protocol The main purpose of the Handshake protocol is for a client and a server to mutually authenticate each other, and to exchange a temporary session key used in other security services. However, client authentication is optional as specified in the TLS standard [7], and often omitted because it requires a client public key certificate. This requires an investment in a Public Key Infrastructure (PKI) to certify client certificates, and this can be a complicated process. However, high-risk transactions such as stock purchasing and banking do need client authentication. Client authentication is also required as part of Class 3 security for data transactions in the WTLS standard for WAP-enabled phones, which is based on the TLS Handshake protocol [5]. Fig. 1 shows the protocol primitives of the TLS Handshake protocol. First, the client and the server exchange random numbers (or nonces) and negotiate the “cipher suite” using ClientHello and ServerHello messages. The server then sends its certificate (ServerCert) signed by a third-party Certificate Authority (CA) which is trusted by the client and the server. The server also sends a client’s certificate request (CertRequest) for client authentication. The client uses a verification function (PKC_Verify) to validate ServerCert by using the CA’s public key (which is distributed beforehand), and obtains the server’s public key if it is valid. The client then initiates a key exchange function (PKC_KeyEx) to exchange a pre-master secret using ClientKeyExchange message, and sends it to the server so that the server can generate the same pre-master secret. Then the client needs to authenticate itself to the server by showing the possession of its private key. The client produces a message digest of previously exchanged messages and signs the digest with its private key (using PKC_Sign function), and sends the signed digest (CertVerify) to the server. Using the client’s public key obtained from the ClientCert, the server verifies the CertVerify (using PKC_Verify). If it is valid, the client truly possesses the private key that pairs with the public key in the client’s certificate. At some point, if any check fails, the session is disconnected. At this point, the client and the server are authenticated to each other. They already possess a shared master key derived from the key exchange process. To complete the Handshake protocol, the client and the server send a ChangeSpec message to confirm the end of the protocol and also use the pre-master key to encrypt the message digest of all previously exchanged messages, and send it within a Finished message to ensure the integrity of the whole session and to show the possession of the pre-master key. In the protocol transactions, three functions (PKC_Verify, PKC_KeyEx, and PKC_Sign) are based on public key cryptography (PKC) such as RSA or ECC. PKC is known to have asymmetric performance. For example, RSA encryption requires much less computation than decryption. Based on this asymmetry, the performance of the Handshake protocol can be improved, and our proposed work is related to this fact.
AS
STA (1)
PKC_Verify (2)
ClientHello ServerHello, ServerCert, CertRequest, ServerHelloDone
ClientCert, ClientKeyExchange, CertVerify, PKC_KeyEx ChangeSpec, Finished (Encrypted) PKC_Sign (3) PKC_Verify (4)
Fig. 1.
ChangeSpec., Finished (Encrypted)
PKC_KeyEx
The TLS Handshake protocol with mutual authentication
2.2 The RSA Digital Signature and Key Exchange The RSA algorithm is based on the integer factorization problem. Basically, given the product of two very large prime numbers, it is computationally hard to find each prime number. In RSA, to encrypt a message m, a client uses a server’s public key (n, e) to produce the ciphertext c = (m)e mod n. To decrypt the ciphertext, the server will need the private key (d) to compute (c)d = (me)d mod n = m. In a manner similar to the decryption, the digital signature of a client is sig = (m)d mod n, and the client sends (m, sig) to a server. Like encryption, the signature verification process computes (sig)e = (md)e mod n = m. A detailed explanation of RSA encryption and decryption as well as signature signing and verification algorithms can be found in [15]. Note that often times a hash of the message is signed rather than the entire message itself. In WTLS, RSA encryption is used in PKC_KeyEx and RSA signature verification is used in PKC_Verify, and they are not computationally intensive because their computation is based on exponentiation of an integer e which can be chosen to be as small as three [15]. On the contrary, RSA decryption that is used in PKC_KeyEx and RSA signing that is used in PKC_Sign are much more computationally intensive since the private key d is large and cannot be controlled for security reasons. This makes the exponentiation more expensive. The private key d has to be on the order of 21024 for today’s security [16]. 2.3 ECDSA and ECDH The security of the ECC is based on the mathematically hard problem called the Elliptic Curve Discrete Log Problem (ECDLP) unlike RSA. Given G and Q = kG where G and Q are discrete points (coordinates) on an elliptic curve and k is a random integer, it is computationally hard to find k given G and Q. The operation kG is called scalar multiplication. To prevent a successful attack, k must be a large integer, and the number of all discrete points on the elliptic curve must also be large. For
ECC, the public key is (G, Q) and the private key is k. For security, k must be on the order of 2160 [16]. Several elliptic curves (ECs) are recommended by NIST (National Institute of Standard and Technology of the USA) in the FIPS 186-2 standard [17], which can be categorized into three types, prime curves, random binary curves and Koblitz binary curves. Each of prime and binary curves has five different key sizes. Prime curves or elliptic curves over prime fields are popular because they can be used with many existing efficient techniques for software implementation. The key sizes of prime curves are 160, 224, 256, 384, or 521 bits. However, in terms of hardware implementation, binary curves or elliptic curves over binary fields are preferred [18]. The key sizes of binary curves are 163, 233, 283, 409, or 571 bits. Two standard ECC algorithms used in WTLS/TLS protocol are Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures and Elliptic Curve DiffieHellman (ECDH) for key exchange [19]. The ECDH algorithm used for PKC_KeyEx generates a pre-master key by “combining” a client’s private key with a server’s public key. The ECDSA signing used for PKC_Sign and verification used for PKC_Verify algorithms use the private key to generate the signature of a message and the public key to verify it. A detailed explanation of the ECDH algorithm and the ECDSA algorithm can also be found in [9].
3. A New TLS Handshake Protocol Fundamentally, the Handshake protocol is composed of three processes, server authentication, key exchange, and client authentication. We propose a variation of this protocol that minimizes energy consumption. In the proposed protocol, at the client’s device, we use RSA verification for PKC_Verify and RSA encryption for PKC_KeyEx; however, we use ECC for PKC_Sign. In this case, the server needs to own an RSA-based certificate, but the client needs to own an ECC-based certificate. The client also needs to be able to process an RSA certificate. From Fig. 1, a client uses the RSA PKC_Verify function to validate the server’s RSA certificate. Then, by using the RSA PKC_KeyEx encryption algorithm, the client produces the ClientKeyExchange message by generating and encrypting a premaster secret with the server’s public key (obtained from the previously received server’s RSA certificate). The client also signs the hash of all previously exchanged messages using the ECDSA PKC_Sign algorithm to produce the CertVerify message. The client then sends its ECC certificate (ClientCert), ClientKeyExchange, CertVerify along with other standard messages to the server, and waits for the authentication result. The advantage of the proposed protocol is that it is simple, and it uses widely available algorithms (RSA and ECC) which are provably secure. It also complies with the existing TLS standard with a small modification that allows different ciphersuites within the handshake protocol. However, it has some shortcomings. The proposed protocol increases the computational load on the server since it tries to reduce energy consumption only at the client device. However, this would be tolerable since the server often has higher computing resources and does not operate using battery
power. The proposed protocol also requires more memory storage to keep all necessary RSA and ECC parameters. The security strength of the proposed protocol is the same as that of the ECC and RSA algorithms only if the proper key sizes are selected. For security the recommended key size is 1024 bits for RSA and 160 bits for ECC. The key size of the premaster key should be at least 128 bits [16].
4. Performance Study For performance study, we use an IBM laptop with an Intel Mobile Pentium III 800 MHz processor, which runs Linux (kernel version 2.4). We use the laptop as a substitute since we do not have a development platform for testing the performance with a cellular phone. Thus, we perform all cryptographic functions related to WTLS handshake protocol on the laptop instead. We expect the energy consumption on the cellular phone to be more critical since it often has a less powerful processor and a smaller battery. These preliminary results only give us an idea of how much the energy consumption from the cryptographic operations would be, and how much we can conserve energy by using the new protocol. 4.1 Measurements In our measurement, energy consumption is estimated by using an instruction set to set and read the total number of cycles taken by cryptographic functions from a special register. About 500 experiments are performed to get an average of the number of cycles for each cryptographic function. Then, by using the average number of cycles (C), the operating voltage of the CPU (V), the average current drawn for each cycle (I), and the CPU clock frequency (F), we can calculate the average energy consumption as E = C×V×I/F. This technique is also used in [20]. The average current used in our experiments is estimated because we do not have the data for an Intel Pentium III 800 MHz processor. Our estimation is based on the available data for other processors. For example, on average, each cycle consumes approximately 270 mA on an Intel 486DX2 processor [21] or 180 mA on Intel Strong ARM [22]. Thus, for Pentium III 800 MHz we assume it is close to 200 mA. Also in our experiment, we estimate the total time required for each cryptographic function, and we use this to calculate the latency of the Handshake protocol session. For the cryptographic algorithms, we use an open source crypto library from the OpenSSL project [23] because it is robust and commercial-grade and it is widely used in the security research community. 4.2 Performance of Digital Signature Algorithms We show the energy consumption of the RSA digital signature algorithm in Fig. 2 (a) and ECDSA in Fig. 2 (b) with different key sizes. The RSA signing algorithm con-
sumes more energy than the ECDSA algorithm, and the difference is even larger when key size increases. In contrast, we can see that the RSA verifying algorithm consumes a very small amount of energy compared to ECDSA verification. In the case of binary curves, the ECDSA signing process consumes about half the energy consumed by the corresponding ECDSA verifying algorithms. However, ECDSA signing and verifying algorithms with prime curves consume almost the same amount of energy. Table 1 shows the latency of digital signature schemes with different key sizes. Like energy consumption, the latency is increased as the size of the key increases. The latency is very significant in the case of the RSA signing algorithm. 200
200
RSA-sign RSA-verify
prime-sign prime-verify binary-random-sign binary-random-verify binary-koblitz-sign binary-koblitz-verify
180
160
Energy Consumption (mJ)
Energy Consumption (mJ)
180
140 120 100 80 60 40
160 140 120 100 80 60 40 20
20 0 512
1024
2048
4096
0 100
200
300
500
600
(b)
(a)
Fig. 2.
400
key size (bits)
key size (bits)
Energy consumption of RSA and ECDSA digital signatures
Table 1. Latency (in millisecond) of digital signature algorithms with different key sizes.
ECC Prime Key Size 160 224 256 384 521
Sign
Verify
24.34 32.92 40.75 101.29 195.38
29.14 39.22 50.22 125.51 243.36
ECC Binary Random Key Sign Verify Size 163 33.89 66.04 233 65.55 128.07 283 125.29 251.34 409 303.64 581.49 571 704.95 1384.9
Binary Koblitz Sign
Verify
30.84 60.56 110.80 260.05 610.5
61.06 115.20 222.14 522.49 1227.6
RSA Key Sign Verify Size 512 9.83 0.94 1024 45.69 2.69 2048 263.19 8.67 4096 1781.71 29.22
4.3 Energy Consumption of Key Exchange Algorithms We show the energy consumption of the RSA encryption/decryption in Fig. 3 (a) and the ECDH algorithm in Fig. 3 (b) which are used to exchange a pre-master secret between a client and a server. From the figure, it is seen that the energy consumed by RSA encryption and decryption does not depends on the size of the pre-master secret. In the TLS standard, the pre-master secret size is 48 bytes (384 bits) [7]; therefore, encrypting the pre-master secret using 1024-bit RSA saves about 9 mJ and 25 mJ
compared to that using the 384-bit ECDH (prime curve) and the 409-bit ECDH (Koblitz curve), respectively. 80
rsa-encrypt-1024bit rsa-decrypt-1024bit rsa-encrypt-2048bit rsa-decrypt-2048bit
70 60 50
Energy Consumption (mJ)
Energy Consumption (mJ)
80
40 30 20 10 0 100
200
300
400
500
secret size (bits)
600
70 60
ecdh-prime ecdh-binary-koblitz ecdh-binary-random
50 40 30 20 10 0 100
200
300
(a)
Fig. 3.
400
500
600
secret size (bits)
(b)
Energy consumption of RSA and ECDH key exchange algorithms
Table 2 shows the latency of key exchange algorithms with different secret sizes. Like energy consumption, the delay in exchanging a pre-master key is increased as the size of the pre-master secret increases only in the case of ECDH. For example, exchanging a 48-byte pre-master secret, using RSA encryption would approximately take only 50 ms, against 98.86 ms with ECDH (prime curve). Table 2. Latency (in millisecond) of key exchange algorithms with different secret (premaster key) sizes (in bits).
ECC Prime Secret Prime Size Curve 160 23.08 224 30.99 256 38.76 384 98.86 521 195.12
ECC Binary Secret Random Koblitz Size Curve Curve 163 32.16 29.63 233 64.06 57.40 283 122.52 108.04 409 297.63 257.19 571 704.17 610.14
RSA Secret 1024-bit 1024-bit 2048-bit 2048-bit Size Encrypt Decrypt Encrypt Decrypt 163 2.97 45.25 9.32 273.14 233 2.96 45.16 8.69 268.17 283 2.99 44.67 8.96 268.43 409 2.97 43.96 8.72 269.38 571 3.02 44.72 9.41 270.44
5. Performance of the New Handshake Protocol In this section, we show the performance of the newly proposed Handshake protocol compared to existing RSA and ECC standard protocols. In the new protocol, we use RSA encryption, RSA verification, and ECDSA with a Random binary curve for digital signing. We compare their performance in terms of energy consumption due to cryptographic functions, message transmission, and latency.
5.1 Energy Consumption of Cryptographic Functions Table 3 shows the total energy consumption at the client wireless device using different Handshake protocols and different key sizes. We see that by using the new protocol, we can conserve about 25% energy compared to 1024-bit RSA and about 70% compared to 163-bit ECC Handshake protocol. The energy conservation is more with longer key sizes. Table 3. The average energy consumption of the Handshake protocols.
Energy Consumption (mJ)
ECC Key Size (RSA Key Size)
RSA
ECC Random Curve
New
163 (1024) 233 (2048) 283 (4096)
5.07 28.51 186.05
13.02 25.86 50.13
3.82 8.14 18.27
5.2 Message Sizes and Energy Consumption due to Transmission In wireless networks, the other source of energy consumption is from the message transmission. The more the number of bits transmitted, the more the energy consumed. The ECC Handshake protocol has advantages over the RSA Handshake protocol because for the same security level, it uses a smaller key size, which results in messages exchanged between a client and a server being of smaller size. A client in the new protocol uses an ECC-based certificate, which reduces the size of the CertVerify message sent to a server. Table 4 shows the total number of bytes sent and received at a client device with different Handshake protocols and the energy consumption from the transmissions. It is shown that the energy requirement for the new protocol is comparable to that with only RSA and only ECC. Table 4. The amount of bytes exchanged and energy for message transmission.
Key sizes
Total Bytes Sent1
RSA ECC New 163 (1024) 850 663 770 233 (2048) 1106 688 914 283 (4096) 1618 708 1184
Total Bytes Received1 RSA 597 597 597
ECC 597 597 597
New 597 597 597
Total Transmission Energy (mJ)2 RSA ECC New 1.182 1.092 1.144 1.305 1.104 1.213 1.551 1.114 1.342
1 The public key certificates of RSA, ECC, and the new protocol all have the same size based on ASN.1 X.509 standard [24]. 2 For transmission, E = 0.48 x + 431 (µJ) and for reception, 0.12 x + 272 (µJ) where E is the energy consumed and x is the number of bytes transmitted or received [25].
5.3 Latency Table 5 shows the total latency of different Handshake protocols measured at the client side. Latency includes only that from performing cryptographic functions. Latency from propagation delay tends to be the same for all protocols; hence, it is not included here. From the table, it is seen that the new protocol has lesser overall delay compared to the handshake protocols based solely on RSA or ECC. Table 5. The total latency to establish a TLS session
Key Sizes 163 (1024) 233 (2048) 283 (4096)
Total Latency (ms) RSA ECC New 51.35 132.09 39.55 280.58 257.68 82.94 1840.74 499.15 184.32
6. Conclusion In this paper, we consider the need for an energy efficient security protocol for wireless devices whose energy resources are limited. The WTLS Handshake protocol which is used for client and server authentication as well as for exchanging a premaster secret in WAP networks is then described. Like SSL/TLS, the WTLS Handshake protocol is based on public key cryptography that is known to be computationally intensive and energy hungry. The existing handshake protocol is based either on RSA or on ECC both of which are not energy efficient. We proposed a simple variation of the Handshake protocol that is more energy efficient, and has better performance. By using the new protocol, we can save about 25% energy compared to 1024bit RSA or 70% compared to 163-bit ECC Handshake protocol. The savings are more when longer keys are used. The new protocol can also be easily integrated into the WTLS or TLS protocol standard.
References 1. C.E. Jones, K.M. Sivalingam, P. Agrawal, and J.C. Chen, “A Survey of Energy Efficient Network Protocols for Wireless Networks,” Wireless Networks, 7, 343-358, 2001. 2. G. E. Moore. Cramming more components onto integrated circuits. Electronics, 38(8), April 19, 1965, ftp://download.intel.com/research/silicon/moorespaper.pdf [last access Feb. 3, 2004]. 3. K. Lahiri, A. Raghunathan, S. Dey, and D. Panigrahi, “Battery-driven system design: A new frontier in low power design,” In Asia South Pacific Design Automation Conference (ASP-DAC) / International Conference on VLSI Design, pages 261–267, Jan. 2002. 4. L. D. Paulson, “Will fuel cells replace batteries in mobile devices?”, IEEE Computer, Nov. 2003, pp. 10-12.
5. WAP Forum, Wireless Transport Layer Security Specification, http://www.wapforum.com, April 2001 [last accessed Feb. 03, 2004]. 6. A. O. Freier, P. Karlton, P. C. Kocher, “The SSL Protocol Version 3.0,” Internet Draft, IETF, November 1996 . Work in progress. 7. S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright, “Transport Layer Security (TLS) Extensions”, Request for Comments RFC 3546, June 2003. 8. R. Rivest, A. Shamir, and L. Adleman, A Method for Obtaining Digital Signatures and Public Key Cryptosystems, Communications of the ACM, vol. 21, no. 2, pp. 120-126, February 1978. 9. A. J. Menezes, Elliptic Curve Public Key Cryptosystems, Kluwer Academic Publishers, 1st edition, June 1993. 10. N.R. Potlapally, et. al., “Optimizing Public-Key Encryption for Wireless Clients,” International Conference on Communications (ICC), May 2002. 11. V. Gupta, S. Gupta, S. Chang and D. Stebila, “Performance Analysis of Elliptic Curve Cryptography for SSL,” The First ACM Workshop on Wireless Security, September 2002, Atlanta, GA, USA 12. R. Karri and P. Mishra, “Optimizing the Energy Consumed by Secure Wireless Sessions – Wireless Transport Layer Security Case Study,” Mobile Networks and Applications, 8, 177-185, 2003. 13. X. Ding, D. Mazzocchi and G. Tsudik, Experimenting with Server-Aided Signatures, 2002 Network and Distributed Systems Security Symposium (NDSS'02), February 2002. 14. N. Asokan, G. Tsudik and M. Waidner, Server-Supported Signatures, European Symposium on Research in Computer Security , September 1996. 15. A. J. Menezes, P. C. van Oorschot and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, October 1996. 16. A.K. Lenstra and E. R. Verheul, “Selecting Cryptographic Key sizes", Journal of Cryptology, vol. 14, no. 4, pp. 255-293, 2001. 17. U.S. Department of Commerce/National Institute of Standards and Technology, Digital Signature Standard (DSS), FIPS PUB 186-2, January 2000. 18. D. Hankerson, J.L. Hernandez and A. Menezes, “Software Implementation of Elliptic Curve Cryptography Over Binary Fields,” Cryptographic Hardware and Embedded Systems (CHES), Lecture Notes in Computer Science, Springer-Verlag, 1965:1--24, 2000. 19. V. Gupta, S. Blake-Wilson, B. Moeller, C. Hawk, “ECC Cipher Suites for TLS”, Internet Draft, IETF, Feb. 2003, draft-ietf-tls-ecc-02.txt. 20. D.W. Carmen, P.S. Kruus and B.J. Matt, “Constraints and Approaches for Distributed Sensor Network Security,” Technical Report 00-010, NAI Labs, September 2000. 21. K. Naik, D. S.L. Wei, “Software Implementation Strategies for Power-Conscious Systems,” Mobile Networks and Applications, 6, 291-305, 2001. 22. A. Sinha and A.P. Chandrakasan, “JouleTrack- A Web Based Tool for Software Energy Profiling,” Proceedings of the 38th Design Automation Conference, DAC 2001, Las Vegas, NV, USA, pp. 220-225. 23. OpenSSL Software Distribution, http://www.openssl.org/ 24. R. Housley, W. Ford, W. Polk, and D. Solo, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” RFC2459, IETF, January 1999. 25. L.M. Feeney and M. Nilsson, “Investigating the Energy Consumption of a Wireless Network Interface in an Ad Hoc Networking Environment,” In Proceedings of IEEE Infocom, Anchorage AK, April, 2001.
