TinyECC: A Configurable Library for Elliptic Curve Cryptographyin Wireless Sensor Networks∗

An LiuDepartment of Computer Science

NC State University, Raleigh, NC 27695email: aliu3@ncsu.edu

Peng NingDepartment of Computer Science

NC State University, Raleigh, NC 27695email: pning@ncsu.edu

Abstract

Public Key Cryptography (PKC) has been the enablingtechnology underlying many security services and proto-cols in traditional networks such as the Internet. In thecontext of wireless sensor networks, elliptic curve cryptog-raphy (ECC), one of the most efficient types of PKC, is be-ing investigated to provide PKC support in sensor networkapplications so that the existing PKC-based solutions canbe exploited.

This paper presents the design, implementation, andevaluation of TinyECC, a configurable library for ECC op-erations in wireless sensor networks. The primary objec-tive of TinyECC is to provide a ready-to-use, publicly avail-able software package for ECC-based PKC operations thatcan be flexibly configured and integrated into sensor net-work applications. TinyECC provides a number of opti-mization switches, which can turn specific optimizationson or off based on developers’ needs. Different combi-nations of the optimizations have different execution timeand resource consumptions, giving developers great flexi-bility in integrating TinyECC into sensor network applica-tions. This paper also reports the experimental evaluationof TinyECC on several common sensor platforms, includ-ing MICAz, Tmote Sky, and Imote2. The evaluation resultsshow the impacts of individual optimizations on the exe-cution time and resource consumptions, and give the mostcomputationally efficient and the most storage efficient con-figuration of TinyECC.

1. IntroductionRecent technological advances have made it possible

to develop wireless sensor networks consisting of a largenumber of low-cost, low-power, and multi-functional sen-sor nodes that communicate over short distances through

∗This work is supported by the National Science Foundation undergrants CAREER-0447761 and CNS-0721424, and by the Army ResearchOffice under grant W911NF-05-1-0247. The contents of this paper do notnecessarily reflect the position or the policies of the U.S. Government.

wireless links. Such sensor networks are ideal candidatesfor a wide range of applications such as monitoring of crit-ical infrastructures, data acquisition in hazardous environ-ments, and military operations. The desirable features ofwireless sensor networks have attracted many researchersto develop protocols and algorithms that can fulfill the re-quirements of these applications.

Security services such as authentication and key man-agement are critical to communication security in wire-less sensor networks as well as the security of sensor net-work applications. In traditional networks such as the Inter-net, Public Key Cryptography (PKC) has been the enablingtechnology underlying many security services and proto-cols (e.g., SSL [3] and IPsec [18]). For example, PKC hasbeen used to bootstrap symmetric session keys and authen-ticate messages to multiple receivers. However, in wirelesssensor networks, PKC has not been widely adopted due tothe resource constraints on sensor platforms, particularlythe limited and depleteable battery power.

There has been intensive research aimed at developingtechniques that can bypass PKC operations in sensor net-work applications. For example, there has been a substan-tial amount of research on random key pre-distribution forpairwise key establishment (e.g., [13, 23]) and broadcastauthentication (e.g., [24, 25]). However, these alternativeapproaches do not offer the same degree of security or func-tionality as PKC. For instance, none of the random keypre-distribution schemes can guarantee key establishmentbetween any two nodes and tolerate arbitrary node com-promises at the same time. As another example, the afore-mentioned broadcast authentication schemes, which are allbased on TESLA [32], require loose time synchronization,which itself is a challenging task to achieve in wirelesssensor networks. In contrast, PKC can address all theseproblems easily. Pairwise key establishment can always beachieved using, for example, the Diffie-Hellman (DH) keyexchange protocol [12], without suffering from the nodecompromise problem. Similarly, broadcast authenticationcan be provided with, for example, the ECDSA digital sig-

2008 International Conference on Information Processing in Sensor Networks

978-0-7695-3157-1/08 $25.00 © 2008 IEEEDOI 10.1109/IPSN.2008.47

245

nature scheme [7], without requiring time synchronization.Thus, it is desirable to explore the application of PKC onresource constrained sensor platforms.

There have been a few recent attempts to use PKC inwireless sensor networks [15, 26, 33], which demonstratethat it is feasible to perform limited PKC operations on thecurrent sensor platforms such as MICAz motes [2]. EllipticCurve Cryptography (ECC) has been the top choice amongvarious PKC options due to its fast computation, smallkey size, and compact signatures. For example, to provideequivalent security to 1024-bit RSA, an ECC scheme onlyneeds 160 bits on various parameters, such as 160-bit finitefield operations and 160-bit key size [8].

Despite the recent progress on ECC implementationson sensor platforms, all the previous attempts [15, 26, 33]have limitations. In particular, all these attempts were de-veloped as independent packages/applications without se-riously considering the resource demands of sensor net-work applications. As a result, developers may find it dif-ficult, and sometimes impossible, to integrate an ECC im-plementation with the sensor network applications, thoughthe ECC implementation may be okay on its own. For ex-ample, an ECC implementation may require so much RAMthat it would be impossible to fit both the sensor networkapplication and the ECC implementation on the same node.

Moreover, various optimization techniques are availableto speed up the ECC operations. Such optimizations, how-ever, typically will increase the ROM and RAM consump-tions, though they may reduce the execution time and en-ergy consumption. It is not clear what optimizations shouldbe used and how they should be combined to achievethe best trade-off among security protection, computationoverheads, and storage requirements. Additional researchis necessary to clarify these issues and facilitate the adop-tion of ECC-based PKC in wireless sensor networks.

It is certainly possible to have dedicated PKC hardwareincluded on sensor platforms. However, given that thereis no PKC hardware that is currently available on currentsensor platforms, it is a sensible choice to explore softwareapproaches for PKC support on sensor platforms.

In this paper, we present the design, implementation,and evaluation of TinyECC, a configurable library for ECCoperations in wireless sensor networks.1 The primary ob-jective of TinyECC is to provide a ready-to-use, publiclyavailable software package for ECC-based PKC operationsthat can be flexibly configured and integrated into sensornetwork applications.

Targeted at TinyOS [5], TinyECC is written innesC [14], with occasional in-line assembly code to achievefurther speedup for popular sensor platforms including MI-CAz [2], TelosB [4], Tmote Sky [6], and Imote2 [1]. A

1TinyECC 1.0 and its previous versions are publicly available athttp://discovery.csc.ncsu.edu/software/TinyECC/.

unique feature of TinyECC is its configurability. TinyECCincludes almost all known optimizations for ECC opera-tions. Each optimization is controlled by a software switch,which can turn the optimization on or off based on devel-opers’ needs. Different combinations of optimizations havedifferent ROM/RAM consumption, execution time, and en-ergy consumption. This gives the developers great flexibil-ity in integrating TinyECC in their applications.

To provide guidance in using TinyECC, we perform aseries of experiments with different combinations of ac-tivated optimizations. To understand the impact of eachoptimization technique, we compare the execution time,ROM/RAM consumption, and energy consumption withand without the given optimization enabled on MICAz [2],Tmote Sky [6], and Imote2 [1]. In addition, our experi-ments also present the performance results and the resourceusages for the most computationally efficient configuration(i.e., fastest execution and least energy consumption) andthe most storage-efficient configuration (i.e., least ROMand RAM usage) of TinyECC on these common sensorplatforms, respectively.

The contribution of this paper is two-fold: First, we de-velop TinyECC to allow flexible integration of ECC-basedPKC in sensor network applications. Second, we per-form a substantial amount of experimental evaluation us-ing representative sensor platforms, including MICAz [2],TelosB [4], Tmote Sky [6], and Imote2 [1]. The experi-mental results provide useful experience and guidance fordevelopers to choose different TinyECC optimizations fortheir needs.

The remainder of this paper is organized as follows.Section 2 discusses the design principles of TinyECC. Sec-tion 3 gives background information on ECC. Section 4 de-scribes the optimization techniques adopted by TinyECC.Section 5 discusses the implementation of TinyECC. Sec-tion 6 presents the experimental evaluation of TinyECC onMICAz, Tmote Sky, and Imote2. Section 7 discusses therelated work, and Section 8 concludes this paper.

2. Design PrinciplesAs mentioned earlier, the primary objective of TinyECC

is to provide a ready-to-use, publicly available softwarepackage for ECC-based PKC operations that can be flexiblyconfigured and integrated into sensor network applications.To make sure we achieve this objective, we follow severalprinciples in the design and development of TinyECC.

Security: TinyECC should provide PKC schemes thathave proven to be secure. To follow this principle,TinyECC only includes support for the well-studied ECCschemes such as ECDSA, ECDH, and ECIES, which aredefined in the Standards for Efficient Cryptography [8].Moreover, TinyECC also includes elliptic curve parame-ters recommended by SECG (Stands for Efficient Cryp-

246

tography Group), such as secp160k1, secp160r1 andsecp160r2, as defined in [9].

Portability: TinyECC should run on as many sensorplatforms as possible. Due to this reason, we choose toimplement TinyECC on TinyOS [5], which is a popular,open-source OS for networked sensors. All the TinyECCcomponents have nesC [14] implementations, though somemodules also include inline assembly code, which can beturned on for faster execution on some sensor platforms.This allows TinyECC to be compiled and used on any sen-sor platform that can run TinyOS. TinyECC has been testedsuccessfully on MICAz, TelosB, Tmote Sky, and Imote2.

Resource Awareness and Configurability: TinyECCshould accommodate the typical resource constraints onsensor nodes. Moreover, TinyECC should allow for flex-ible configuration so that it can take advantage of the avail-able resources on a wide spectrum of sensor platforms. Tofollow this principle, TinyECC is implemented carefullyto avoid unnecessary resource usage. Moreover, TinyECCuses a set of optimization switches, which can be turnedon or off to achieve different combinations of performanceand resource consumptions.

Efficiency: TinyECC should be computationally effi-cient to reduce the battery consumption as well as the de-lay introduced by PKC operations. We make three designdecisions to improve the efficiency of TinyECC. The firstis about the type of finite fields over which the ECC opera-tions are performed. ECC can be implemented over eithera prime field Fp, where p is a large prime number, or a bi-nary extension field F2m , where m is an integer. Since arith-metic operations over F2m are insufficiently supported bymicro-controllers, we choose to support prime fields Fp inTinyECC. Second, we adopt almost all existing optimiza-tions for ECC operations in TinyECC. As mentioned ear-lier, these optimizations can be turned on or off to balancethe efficiency and the resource requirements. Third, we in-clude inline assembly code in critical parts of TinyECCfor popular sensor platforms, including MICAz, TelosB,Tmote Sky, and Imote2.

Functionality: TinyECC should support the typicaldemands for PKC. To follow this principle, the currentversion of TinyECC includes a digital signature scheme(ECDSA), a key exchange protocol (ECDH), and a pub-lic key encryption scheme (ECIES). These cover all typicaluses of PKC.

3. Background on ECCIn this and next sections, we give an overview of ECC

and the optimizations adopted by TinyECC as a convenientreference. The reader can find details in the references.

Elliptic curve cryptography (ECC) is an approach topublic-key cryptography based on the algebraic structure ofelliptic curves over finite fields [16]. Elliptic curves used in

cryptography are typically defined over two types of finitefields: prime fields Fp, where p is a large prime number,and binary extension fields F2m . For space reasons, we fo-cus on elliptic curves over Fp in this paper.

An elliptic curve over Fp is defined by a cubic equationy2 = x3 + ax + b, where a,b ∈ Fp are constants such that4a3 + 27b3 �= 0 [16]. An elliptic curve over Fp consists ofthe set of all pairs of affine coordinates (x,y) for x,y ∈ Fq

that satisfy an equation of the above form and an infinitypoint O . The points on an elliptic curve form an abeliangroup with O as the additive identity. (The formulas defin-ing point addition and its special case, point doubling, canbe found in [16].)

For any point G on an elliptic curve, the set{O,G,2G,3G, ...} is a cyclic group [16]. The calcula-tion of kG, where k is an integer, is called a scalar mul-tiplication. The problem of finding k given points kGand G is called the elliptic curve discrete logarithm prob-lem (ECDLP). It is computationally infeasible to solveECDLP for appropriate parameters [16]. The hardness ofECDLP allows several cryptographic schemes based on el-liptic curves.

TinyECC includes three well-known ECC schemes:(1) the Elliptic Curve Diffie-Hellman (ECDH) key agree-ment scheme, (2) the Elliptic Curve Digital Signature Algo-rithm (ECDSA), and (3) the Elliptic Curve Integrated En-cryption Scheme (ECIES). ECDH is a variant of the Diffie-Hellman key agreement protocol [12] on elliptic curvegroups. ECDSA is a variant of the Digital Signature Al-gorithm (DSA) [29] that operates on elliptic curve groups.ECIES is a public-key encryption scheme which providessemantic security against an adversary who is allowed touse chosen-plaintext and chosen-ciphertext attacks [16].ECIES is also known as the Elliptic Curve Augmented En-cryption Scheme (ECAES) or simply the Elliptic Curve En-cryption Scheme. These ECC schemes allow smaller keysizes for similar security level to the alternatives such as theoriginal DH and DSA schemes. For each of the schemes,a party that would like to use the scheme needs to agreeon some domain parameters such as the elliptic curve and apoint G on the curve, and must have a key pair consisting ofa private key d and a public key Q = dG. The specificationof ECDH, ECDSA, and ECIES can be found in [8, 16].

4. Optimizations Adopted by TinyECC

In this section, we briefly discuss the optimization tech-niques adopted by TinyECC. We will omit the details, sincethe focus of this paper is not these individual optimizationtechniques. More information about these techniques canbe found in the relevant references.

247

4.1. Optimizations for Large Integer Operations

Barrett Reduction [28]: A straightforward way toperform large integer modular reductions is to use divi-sion [19]. A nice side effect is that it reuses the code ofdivision, thus resulting in more compact code size.

Barrett Reduction is an alternative method for modularreduction [28]. It converts the reduction modulo an arbi-trary integer to two multiplications and a few reductionsmodulo integers of the form 2n. When used to reduce asingle number, Barrett reduction is slower than a normaldivision algorithm. However, when used to reduce vari-ous numbers modulo the same number many times, by pre-computing some value, Barrett reduction can achieve fasterspeed than modular reductions obtained by division. De-tails of Barrett reduction can be found in [28].

In TinyECC, since almost all the modular operationsare modulo the same prime number p, Barrett reductioncan potentially speed up the computation. However, thisrequires the implementation of a separate reduction algo-rithm, which implies larger code size (i.e., greater ROMrequirement) on sensor nodes. In addition, Barrett reduc-tion also increases RAM use. Assume the target micro-controller has a w-bit word size. Given a finite field Fp,where p is a k words long prime number, Barrett reductionrequires the pre-computation of µ = � bk

p �, where b = 2w

(e.g., b = 28 on a 8-bit processor). This number µ has tobe stored and used throughout all the modular reductions.Thus, to exchange for faster computation, Barrett reductionrequires more ROM and RAM than the traditional division-based modular reduction.

Hybrid Multiplication and Hybrid Squaring [15]:Standard large integer multiplication algorithms [19] storethe operands and the product in arrays. When such an al-gorithm is implemented in a high-level language such asnesC, the compiler cannot use the registers in the micro-controller efficiently, and the binary code usually needsto load the operands from memory to registers multipletimes [15]. Gura et al. [15] proposed a hybrid multipli-cation algorithm, which was intended for assembly code.This algorithm can maximize the utilization of registersand reduce the number of memory operations. TinyECCadopts this hybrid multiplication algorithm for MICAz [2],TelosB [4]/Tmote Sky [6], and Imote2 [1]. Indeed, the codecan be used on any sensor platforms that have processorsusing the same instruction sets.

In addition to hybrid multiplication, we also customizethe hybrid multiplication algorithm for squaring operationsby using the fact that the two multiplicative operands insquaring are the same. This further reduces the executiontime for squaring at the cost of larger code size.

4.2. Optimizations for ECC Operations

Projective Coordinate Systems [16]: As discussed ear-lier, an elliptic curve consists of the infinity point O and theset of points in the affine coordinates (x,y) for x,y ∈ Fp thatsatisfy the defining equation. Alternatively, a point on anelliptic curve can be represented in a projective coordinatesystem in the form of (x,y,z).

Point addition and point doubling are critical operationsin ECC, which are building blocks for scalar multiplica-tions required by all ECC schemes. These operations inaffine coordinate system require modular inversion oper-ations, which are much more expensive than other oper-ations such as modular multiplications. Using a projectivecoordinate system [16], modular inversions can be removedwith the compensation of a few modular multiplicationsand squares. As a result, the execution times of point ad-dition and point doubling based on projective coordinatesystem are faster than those based on affine coordinate sys-tem, respectively [16].

TinyECC uses two additional optimizations along withprojective coordinate representation, which can further re-duce both the execution time and the program size. Thefirst is a mixed point addition algorithm [16], which adds apoint in projective coordinate and a second point in affinecoordinate. This algorithm can be used in scalar multipli-cations to further reduce the number of modular multiplica-tions and squares, leading to smaller and faster code. Thesecond is repeated Doubling [16] for scalar multiplication.If consecutive point doublings are to be performed, the re-peated doubling algorithm may be used to achieve fasterperformance than repeated use of the doubling formula. Inm consecutive doublings, this algorithm trades m− 1 fieldadditions, m− 1 divisions by two, and a multiplication fortwo field squarings (in comparison with repeated applica-tions of the plain point doubling algorithm) [16].

Though reducing the execution time, the projective co-ordinate representation requires a larger code size (for morecomplex formula) and more RAM (for storing additionalvariables) than the affine coordinate system.

Sliding Window for Scalar Multiplications [16]:Scalar multiplication is a basic operation used by all ECCschemes. It is in the form of kP, where k is an integer andP is a point on an elliptic curve. In the most straightfor-ward method to compute kP, k is scanned from the mostsignificant bit to the least significant bit. When each bit isscanned, the algorithm needs to compute a point doubling.When the scanned bit is “1”, the algorithm also needs toperform a point addition. The sliding window method canspeed up the scalar multiplication by scanning w bits at atime. Each time when a w-bit window is scanned, the algo-rithm needs to perform w point doublings. By precomput-ing 2P, 3P, ..., and (2w − 1)P, the sliding window method

248

only needs to perform 1 point addition every w bits, andthus has less computational cost.

It is easy to see that the sliding window method willincrease both the ROM (for additional code size) and RAM(for storing the pre-computed points) consumptions.

Shamir’s Trick [16]: This optimization is only usedfor the verification of ECDSA signatures. The verificationof ECDSA signature requires the computation of the formaP + bQ, where a,b are integers and P,Q are two pointson an elliptic curve. A straightforward implementationrequires two scalar multiplications and a point addition.However, Shamir’s trick allows us to compute the abovevalue at a cost close to one scalar multiplication. Specif-ically, with pre-computed P + Q, we may scan the (same)bits of a and b from the most significant one to the leastsignificant one. For each bit, we need double the interme-diate value, which is initialized as the infinity point. If thescanned bit positions are 〈ai = 0,bi = 1〉, 〈ai = 1,bi = 0〉,or 〈ai = 1,bi = 1〉, we add P, Q, or P + Q to the interme-diate value. This reduces two scalar multiplications to be abit more expensive than one such operation.

Similar to the sliding window method, Shamir’s trickwill increase both the ROM (for additional code size) andRAM (for storing the pre-computed P+ Q) consumptions.

Curve Specific Optimization [15]: A number of el-liptic curves specified by NIST [30] and SECG [9] usepseudo-Mersenne primes. A pseudo-Mersenne prime is ofthe form p = 2n − c, where c � 2n. Reduction modulo apseudo-Mersenne prime can be performed by a few mod-ular multiplications and additions without any division op-eration. As a result, the time for modular reduction canbe reduced significantly. Thus, using elliptic curves overa pseudo-Mersenne prime can achieve additional perfor-mance gain.

5. ImplementationWe implemented TinyECC on TinyOS [5], an open

source operating system designed for wireless embeddedsensor networks. The current version of TinyECC providessupport for ECDSA (digital signatures), ECDH (pairwisekey establishment), and ECIES (PKC-based encryption).Most of the code was written in nesC [14] for portabilityreasons. To best harness the capabilities of the processorson popular sensor platforms such as MICAz and TelosB,we also provided inline assembly implementation of somecritical operations, such as large integer multiplications.

To save implementation efforts, we ported the C code oflarge integer operations in RSAREF 2.0 [20] to nesC codeon TinyOS. These include modular addition, subtraction,multiplication, division, inverse, and exponentiation opera-tions. We then implemented all the elliptic curve operationsand the optimization techniques discussed earlier.

TinyECC has been released publicly at http:

//discovery.csc.ncsu.edu/software/TinyECC/. Some preliminary versions have beenadopted by other researchers (e.g., [11, 21, 27]). Asdiscussed earlier, starting from the current version, weadded a set of optimization switches to provide for flexibleconfiguration of TinyECC so that it can be integratedinto sensor network applications with different resourceconsumptions and performance demands.

Table 1 lists the optimization switches available in thecurrent version of TinyECC. All optimization switches canbe turned on or off by a simple configuration at compiletime, or slight modification in the source code. Moreover,when the sliding window method is used, an additional pa-rameter defining the size of the window (e.g., w = 4) needsto be specified.

6. EvaluationWe performed a series of experiments to evaluate

TinyECC on four representative sensor platforms, includ-ing MICAz [2], TelosB [4], Tmote Sky [6], and Imote2 [1].

The objective of these experiments is three-fold: First,we want to measure the performance and resource con-sumption of TinyECC on a spectrum of sensor platforms,ranging from the low-end ones (such as MICAz, TelosB,and Tmote Sky) to high-end ones (such as Imote2). Sec-ond, we would like to understand the impact of the op-timizations adopted by TinyECC on performance and re-source consumption. Finally, we would like to provide de-tailed performance results and resource demands for com-monly desirable configurations, including the configurationthat provides the fastest execution time and the configura-tion that requires the least memory consumption. The for-mer has the least energy consumption, while the latter is theeasiest one to integrate into sensor network applications.

6.1. Methodology and Experimental Setup

Evaluation Methodology: Given seven optimizationswitches, four sensor platforms, where Imote2 has mul-tiple CPU frequencies due to dynamic voltage scaling,many possible elliptic curves, and three ECC-based PKCschemes, there are a large number of experiments to per-form if we have to observe the performance and resourceconsumptions in all cases.

To simplify the scenarios, we adopted the followingmethodology in our experiments. For each optimizationswitch, we performed two sets of experiments, referred toas case A and case B, respectively. In case A, for each opti-mization, we disabled all the other optimizations, and thenobtained the performance and resource consumption met-rics when the given optimization was enabled and disabled,respectively. In case B, we enabled all the other optimiza-tions and obtained the evaluation metrics again when thegiven optimization was enabled and disabled, respectively.

249

Table 1. TinyECC Optimization SwitchesMethod Optimization Switch Category Description

Barrett Reduction BARRETT large number Allow Barrett reduction.Hybrid Multiplication HYBRID MULT large number Allow hybrid multiplication in inline assembly.Hybrid Squaring HYBRID SQR large number Allow hybrid squaring in inline assembly.Projective Coordinate System PROJECTIVE EC Use projective coordinate system along with mixed point addition and repeated doubling.Sliding Window Method SLIDING WIN EC Use sliding window method for scalar multiplication. A window size (e.g. w = 4) has to be

defined along with this switch.Shamir’s Trick SHAMIR TRICK EC Allow Shamir’s trick when verifying ECDSA signatures. A window size (e.g. w = 2) has to be

defined along with this switch.Curve-Specific Optimization CURVE OPT EC Allow curve specification optimization. This has to be used for the curves defined over pseudo-

Mersenne primes [9, 30].

The differences in these metrics reflect the impact of thegiven optimization technique.

Moreover, as discussed earlier, we also performed ad-ditional experiments to examine in detail two commonlydesirable configurations: the one that provides the fastestexecution time, and the one that requires the least storage.

Experimental Setup: We evaluated TinyECC on thelatest CVS version of TinyOS 1.x [5]. As discussed ear-lier, we chose four representative sensor platforms, MI-CAz, TelosB, Tmote Sky, and Imote2, for the experiments,since they are popular sensor platforms and cover the 8-bit,16-bit and 32-bit processors. Other sensor platforms (e.g.,Mica2, Mica2Dot) are expected to perform similarly to oneof these platforms, due to the use of the same processor.

TelosB and Tmote Sky have almost the same hardware.The only difference is that TelosB can only run at 4 MHz,while Tmote Sky can run at 8 MHz when an external resis-tor is enabled. We configure Tmote Sky to run at 8 MHz inour experiments. Due to the similarity between TelosB andTmote Sky, we only report the results on Tmote Sky in thispaper. The reader may refer to the technical report versionof this paper [22] for experimental results on TelosB.

As a high-end sensor platform, Imote2 uses an XScaleprocessor and supports dynamic voltage scaling. To ob-tain a relatively complete view of Imote2, we used four dif-ferent frequencies on Imote2 in our experiments: 13MHz,104MHz, 208MHz, and 416MHz.

By default, TinyECC includes all 128-bit, 160-bit and192-bit ECC parameters recommended by SECG [9]. Itis well-known that 160-bit ECC has the same securitylevel as 1024-bit RSA. We selected a 160-bit elliptic curvesecp160r1 [9] to evaluate the impact of individual op-timization techniques. Note that the actual selection ofcurves depends on the security needs in the sensor networkapplications, and is outside of the scope of this paper.

We used the following evaluation metrics in all ex-periments: ROM consumption (byte), RAM consumption(byte), execution time (ms), and energy consumption (mil-lijoule). We used the check size.pl script in theTinyOS distribution to obtain the ROM and RAM sizes re-quired by the TinyECC components. The execution timewas measured directly on the sensor nodes. To get the over-

all performance result, we randomly generated the parame-ters (e.g., random message, random public and private keypairs) other than those defining the curves, and obtainedthe execution time for each data point by taking the av-erage of 10 test instances. The energy consumption wasthen calculated as U × I × t based on the execution time(t), the voltage (U), and current draw (I) on these sensorplatforms [1, 2, 4, 6].

6.2. Evaluation ResultsDue to the space limit, we can only report a portion of

the evaluation results. Please refer to the full version of thispaper [22] for more details.

6.2.1. Impact of Individual Optimizations

In the following, we use the experimental results forECDSA to show the impact of individual optimizationtechniques. More results on the impacts of these optimiza-tions on ECDH and ECIES can be found in [22].

There are three aspects of the execution time forECDSA. Figures 1(a) and 1(b) show the initialization timerequired to prepare for ECDSA in cases A and B, respec-tively. Figures 1(c) and 1(d) show the signature generationtime in cases A and B, respectively. Figures 1(e) and 1(f)show the signature verification time in cases A and B, re-spectively.

In the initialization of ECDSA, TinyECC needs to pre-compute µ for Barrett reduction, a few points for the slid-ing window method, and a few points for Shamir’s trick.In case A, as Figure 1(a) shows, only these 3 optimiza-tion techniques have impact on the initialization time. ForMICAz, the initialization of the sliding window methodwith window size 4 requires 3,587 ms, which is longerthan Shamir’s trick (1,672 ms for window size 2) andBarrett reduction (6 ms). The same situation applies toTelosB/Tmote Sky, and Imote2. If we disable all thesethree techniques, the initialization time of ECDSA is closeto 0. In case B, as Figure 1(b) shows, the disabling of se-lected optimization technique does not reduce the initial-ization time dramatically, except that the disabling of thesliding window method reduces the initialization time byhalf.

In Figure 1, we can see that PROJECTIVE is the most

250

0.07

81

0.05

19

0.02

81

0.00

41

0.00

23

0.00

23

6.39

78

4.07

71

0.78

64

0.09

88

0.04

98

0.02

71

0.07

81

0.04

88

0.02

78

0.00

40

0.00

23

0.00

23

0.07

81

0.04

88

0.02

84

0.00

40

0.00

25

0.00

23

0.07

81

0.05

80

0.02

77

0.00

43

0.00

23

0.00

23

0.07

81

0.04

27

0.02

82

0.00

42

0.00

23

0.00

20

3586

.693

3

2465

.432

6

319.

7278

39.9

632

19.9

811

10.0

027

1671

.878

8

1146

.420

2

148.

8784

18.6

104

9.30

50

4.65

58

0.0001

0.0100

1.0000

100.0000

10000.0000

1000000.0000

MICAz(8 MHz)

Tmote Sky(8 MHz)

Imote2(13 MHz)

Imote2(104 MHz)

Imote2(208 MHz)

Imote2(416 MHz)

Tim

e (m

s)Disable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(a) Init. time when all other optimizations are disabled (case A)

3493

.36

2545

.18

341.

25

42.6

8

21.3

4

10.7

4

2544

.20

340.

46

42.5

7

21.2

9

10.7

1

3772

.85

2594

.95

360.

12

45.0

1

22.5

0

11.3

2

3572

.08

2566

.90

346.

92

43.3

6

21.6

8

10.9

1

3826

.72

2934

.96

378.

47

47.3

1

23.6

6

11.8

5

3292

.86

2327

.40

300.

22

37.5

3

18.7

6

9.40

1684

.46

1230

.10

164.

50

20.5

6

10.2

8

5.17

3626

.14

2641

.15

353.

18

44.1

4

22.0

7

11.1

1

3486

.92

0.0001

0.0100

1.0000

100.0000

10000.0000

1000000.0000

MICAz(8 MHz)

Tmote Sky(8 MHz)

Imote2(13 MHz)

Imote2(104 MHz)

Imote2(208 MHz)

Imote2(416 MHz)

Tim

e (m

s)

Enable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(b) Init time when all other optimizations are enabled (case B)

3072

3.00

2128

4.39

2785

.11

348.

11

174.

06

87.1

2

3176

0.27

2177

9.61

2936

.58

367.

06

183.

53

91.8

1

3042

3.74

2122

0.11

2766

.76

345.

82

172.

91

86.5

6

3020

7.65

2119

6.15

2750

.48

343.

79

171.

89

2959

1.55

2091

8.37

2710

.26

338.

76

169.

38

84.8

1

9086

.12

4177

.88

891.

13

111.

39

55.7

0

28.3

1

2527

3.89

1733

3.41

2270

.90

283.

84

141.

92

71.0

7

3072

5.57

2132

3.55

2785

.10

348.

11

174.

06

87.1

2

86.0

4

1

10

100

1000

10000

100000

1000000

MICAz(8 MHz)

Tmote Sky(8 MHz)

Imote2(13 MHz)

Imote2(104 MHz)

Imote2(208 MHz)

Imote2(416 MHz)

Tim

e (m

s)

Disable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(c) Sig. generation time when all other optimizations are disabled (case A)20

01.6

2

1580

.63

363.

98

45.6

3

22.8

2

11.8

0

2007

.97

1585

.60

364.

97

45.8

6

22.9

3

11.9

5

3249

.44

1865

.71

447.

39

55.9

2

27.9

3

14.3

4

2957

.78

1894

.93

431.

97

53.9

9

27.0

0

4066

.37

3045

.78

611.

52

76.4

4

38.2

1

19.2

5

2356

5.96

1677

7.23

2179

.79

272.

45

136.

20

68.2

8

2456

.95

2041

.65

459.

20

57.4

0

28.7

0

14.7

8

2001

.62

1583

.22

365.

73

45.7

2

22.8

6

11.8

2

13.9

1

1

10

100

1000

10000

100000

1000000

MICAz(8 MHz)

Tmote Sky(8 MHz)

Imote2(13 MHz)

Imote2(104 MHz)

Imote2(208 MHz)

Imote2(416 MHz)

Tim

e (m

s)

Enable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(d) Sig. generation time when all other optimizations are enabled (case B)

6180

0.34

4288

6.27

5560

.35

694.

99

347.

49

174.

00

6389

2.90

4384

1.09

5863

.27

732.

85

366.

43

183.

31

6119

7.70

4272

4.94

5523

.87

690.

44

345.

22

172.

87

6076

1.77

4267

5.35

5491

.07

686.

41

343.

17

5951

7.10

4211

5.65

5411

.92

676.

45

338.

22

169.

55

1829

4.94

8425

.67

1783

.73

222.

95

111.

46

56.1

9

5080

7.12

3474

5.25

4514

.04

564.

21

282.

10

141.

20

3048

4.70

2079

3.69

2710

.03

338.

73

169.

37

84.7

7

171.

75

1

10

100

1000

10000

100000

1000000

MICAz(8 MHz)

Tmote Sky(8 MHz)

Imote2(13 MHz)

Imote2(104 MHz)

Imote2(208 MHz)

Imote2(416 MHz)

Tim

e (m

s)

Disable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(e) Sig. verification time when all other optimizations are disabled (case A)

2436

.46

2016

.02

446.

85

56.0

2

28.0

1

14.4

9

2442

.09

2020

.10

446.

29

55.9

6

27.9

8

14.4

9

4108

.00

2411

.19

557.

07

69.6

3

34.7

8

17.8

4

3556

.52

2347

.82

525.

87

65.7

3

32.8

7

5048

.30

3804

.69

754.

55

94.3

1

47.1

5

23.7

5

2850

9.93

2015

7.31

2606

.36

325.

77

162.

91

81.6

5

2436

.49

2018

.40

447.

57

55.9

4

27.9

7

14.4

8

4020

.43

3175

.11

725.

52

90.6

8

45.3

4

23.3

8

16.9

3

1

10

100

1000

10000

100000

1000000

MICAz(8 MHz)

Tmote Sky(8 MHz)

Imote2(13 MHz)

Imote2(104 MHz)

Imote2(208 MHz)

Imote2(416 MHz)

Tim

e (m

s)

Enable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(f) Sig. verification time when all other optimizations are enabled (case B)

Figure 1. ECDSA timing result (Projective coordinate system is the most effective optimization, while Barrettreduction does not have obvious impact.)

effective switch to improve the speed of signature genera-tion and verification. In case A, by enabling the PROJEC-TIVE switch, the signature generation and verification of allplatforms can speed up by at least 3 times. In case B, if wedisable the PROJECTIVE switch, the signature generationand verification has at least 6 times slowdown comparedwith enabling all optimization techniques.

Although PROJECTIVE is the most efficient switch, itincreases the ROM usage. Figures 2(a) and 2(b) show thatwhen the PROJECTIVE switch is enabled in case A, theROM size is increased by 1,218, 1,326, and 1,752 bytesfor MICAz, TelosB/Tmote Sky, and Imote2, respectively,while the RAM size does not change at all. In case B,

as Figures 2(c) and 2(d) show, disabling the PROJECTIVEswitch can save 3,816, 3,880, and 4,660 bytes in ROM forMICAz, TelosB/Tmote Sky, and Imote2, respectively. ThePROJECTIVE switch is the most effective switch to speedup ECDSA operations, but it also incurs larger ROM con-sumption than any other optimization technique.

SHAMIR TRICK is also an efficient option to speed upECDSA signature verification. From Figure 1(e), we cansee that the verification can speed up by 2 times on allplatforms when enabling SHAMIR TRICK in case A. BothROM and RAM sizes are increased. In case A, the RAMsize is increased by 634, 676, and 784 bytes for MICAz,TelosB/Tmote Sky, and Imote2, respectively. Similarly, the

251

ROM size of MICAz, TelosB/Tmote Sky and Imote2 is in-creased by 638, 632, and 620 bytes, respectively. In caseB, disabling SHAMIR TRICK makes verification 1.6 timesslower but saves 2,148, 2,068, and 2,208 bytes in ROM forMICAz, TelosB/Tmote Sky, and Imote2, respectively. TheRAM size does not decrease much because the sliding win-dow method is used for verification when SHAMIR TRICKis disabled.

Now let us take a look at the SLIDING WIN option. Incase A, as Figures 1(c), 1(e), 2(a) and 2(b) show, enablingSLIDING WIN can make signature generation and verifica-tion 1.2 times faster at the cost of dramatic RAM increase(1,262, 1,328 and 1,472 bytes for MICAz, TelosB/TmoteSky, and Imote2, respectively). In case B, as Figures1(d), 1(f), 2(c) and 2(d) show, disabling SLIDING WINcan save 632, 668, and 752 bytes of RAM for MICAz,TelosB/Tmote Sky, and Imote2 with 1.2 times slower sig-nature generation and verification. Since MICAz andTelosB/Tmote Sky are low-end sensor platforms, they havemuch smaller RAM (4kB, 10kB) compared with Imote2(256kB). Before enabling SLIDING WIN, we should bevery careful if the sensing application has large RAM con-sumption. Since SLIDING WIN is the most RAM consum-ing switch in TinyECC, application developers may disableit or reduce the window size to reserve more RAM for theapplications.

Now consider the HYBRID MULT, HYBRID SQR, andCURVE OPT options. In case A, HYBRID MULT, HY-BRID SQR and CURVE OPT do not have big impact onthe timing result. However, in case B, HYBRID MULTcan speed up signature generation by 1.6 times for MI-CAz, 1.2 times for TelosB/Tmote Sky, and 1.2 times forImote2. Similarly, it can speed up signature verificationby 1.7 times for MICAz, 1.2 times for TelosB/Tmote Sky,and 1.2 times for Imote2. HYBRID SQR can speed up sig-nature generation by 1.5 times for MICAz, 1.2 times forTelosB/Tmote Sky, and 1.2 times for Imote2, and speed upsignature verification by 1.5 times for MICAz, 1.2 times forTelosB/Tmote Sky, and 1.2 times for Imote2. CURVE OPTcan speed up signature generation by 2 times for MICAz,1.9 times for TelosB/Tmote Sky, and 1.7 times for Imote2.Similarly, it can speed up signature verification by 2.1times for MICAz, 1.9 times for TelosB/Tmote Sky, and1.7 times for Imote2. The reason that HYBRID MULT,HYBRID SQR and CURVE OPT cannot speed up ECDSAmuch in case A is that the PROJECTIVE option is disabledwhen each of these switches is enabled. Thus, inverse op-eration is the major computation of signature generationand verification. In case B, when PROJECTIVE is enabled,multiplication and squaring become the major computationin ECDSA.

Based on the timing results obtained for ECDSA, theeffectiveness of these optimization switches in terms of

10,1

80

8,17

2

8,64

411,4

68

9,35

8

10,0

48

11,2

78

8,20

8

8,69

611,5

00

8,31

0

8,82

4

10,6

90

8,66

0

9,23

211,3

98

9,49

8

10,3

96

10,3

74

8,36

4

8,89

6

10,8

18

8,80

4

9,26

4

0

5,000

10,000

15,000

20,000

25,000

MICAz Tmote Sky Imote2

RO

M s

ize

(Byt

e)

Disable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(a) ROM size w/ all other optimizations disabled (case A)

152

160

176

244

258

292

152

160

176

152

160

176

152

160

176

152

160

176

1,41

4

1,48

8

1,64

8

786

836 96

0

0

500

1,000

1,500

2,000

2,500

MICAz Tmote Sky Imote2

RA

M s

ize

(Byt

e)

Disable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(b) RAM size w/ all other optimizations disabled (case A)

19,3

08

14,7

08

16,3

52

17,9

70

13,5

20

14,9

4018,3

78

14,6

72

16,3

00

18,0

80

14,5

70

16,1

72

18,2

46

13,9

04

15,4

52

15,4

92

10,8

28

11,6

92

18,1

96

13,5

46

14,9

7217,1

60

12,6

40

14,1

44

0

5,000

10,000

15,000

20,000

25,000

MICAz Tmote Sky Imote2

RO

M s

ize

(Byt

e)

Enable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(c) ROM size w/ all other optimizations enabled (case B)

1,51

0

1,60

2 1,82

8

1,41

8

1,50

4 1,71

2

1,51

0

1,60

2 1,82

8

1,51

0

1,60

2 1,82

8

1,51

0

1,60

2 1,82

8

1,51

0

1,60

2 1,82

8

878

934 1,

076

1,50

6

1,58

6

1,76

4

0

500

1,000

1,500

2,000

2,500

MICAz Tmote Sky Imote2

RA

M s

ize

(Byt

e)

Disable All BARRETT HYBRID_MULT HYBRID_SQR

CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

(d) RAM size w/ all other optimizations enabled (case B)

Figure 2. Code size of ECDSA (Sliding window hasthe most memory demand, Shamir’s trick ranks thenext, while all the other optimizations have similarmemory demands.)

252

Available ROM (byte) How to Conf. TinyECC’s Switches[10,180,10,374) disable all[10,374,11,398) enable SLIDING WIN[11,398,17,160) enable PROJECTIVE[17,160,17,970) enable all & disable SHAMIR TRICK[17,970,19,308) enable all & disable BARRETT[19,308,+∞) enable all

Table 2. Configuration based on Free ROM for MICAz

Available RAM (byte) How to Conf. TinyECC’s Switches[152,786) disable all[786,878) enable SHAMIR TRICK[878,1,418) enable all & disable SLIDING WIN[1,418,1,510) enable all & disable BARRETT[1,510,+∞) enable all

Table 3. Configuration based on Free RAM for MICAz

execution time can be ordered as follows: PROJECTIVE> CURVE OPT > HYBRID MULT > HYBRID SQR >SLIDING WIN > SHAMIR TRICK > BARRETT. In termsof RAM size, the optimization switches can be ordered asfollows: SLIDING WIN > SHAMIR TRICK > BARRETT> HYBRID MULT = HYBRID SQR = CURVE OPT =PROJECTIVE.

In terms of ROM size, the optimization switches are or-dered differently for different platforms. For MICAz, PRO-JECTIVE > BARRETT ≈ HYBRID SQR > CURVE OPT≈ SHAMIR TRICK ≈ HYBRID MULT > SLIDING WIN.For TelosB/Tmote Sky, PROJECTIVE > BARRETT ≈SHAMIR TRICK > CURVE OPT ≈ SLIDING WIN >HYBRID SQR > HYBRID MULT. For Imote2, PROJEC-TIVE > BARRETT > SHAMIR TRICK ≥ CURVE OPT >SLIDING WIN > HYBRID SQR > HYBRID MULT.

Configuration Guideline: To summarize and assistusers of TinyECC, in Tables 2 and 3, we show how tochoose optimization switches on MICAz motes when theamount of available ROM and RAM for TinyECC can beestimated. TinyECC requires at least 10,180 bytes ROMand 152 bytes RAM to be used on MICAz. As more ROMand RAM are available, we can gradually enable the opti-mization switches as indicated in these tables to get betterperformance. For example, having a ROM size between11,398 bytes and 17,160 bytes allows us to enable bothSLIDING WIN and PROJECTIVE switches (but not oth-ers). Note that an optimization can be enabled if both ROMand RAM sizes allow it. Optimization switches can be de-termined for other platforms similarly.

6.2.2. Most Computationally Efficient Configuration

Now consider the most computationally efficient con-figuration. Apparently, TinyECC provides the most com-putationally efficient configuration when all the optimiza-

3493

.36

2001

.62

2436

.46

1838

.74

3907

.46

2632

.66

1838

.74

2117

.43

2545

.18

1580

.63

2016

.02

1319

.32

3271

.01

2127

.77

1319

.54

1755

.96

341.

25

363.

98

446.

85

178.

34

736.

97

466.

10

179.

16 392.

12

42.6

8

45.6

3

56.0

2

22.2

9

92.0

6

58.1

5

22.3

9 49.0

1

21.3

4

22.8

2

28.0

1

11.1

5

46.0

6

29.1

3

11.2

0 24.5

1

10.7

4

11.8

0

14.4

9

5.64

24.2

6

15.1

0

5.65

12.8

9

1

10

100

1000

10000

100000

init(ECDSA)

sign(ECDSA)

verify(ECDSA)

init(ECIES)

encrypt(ECIES)

decrypt(ECIES)

init(ECDH)

key establish(ECDH)

Tim

e (m

s)

MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz) Imote2 (208 MHz) Imote2 (416 MHz)

Figure 3. Execution time of ECDSA, ECIES, andECDH w/ all optimization switches enabled

tion switches are enabled. Figure 3 shows the executiontime required by ECDSA initialization, signature genera-tion, signature verification; ECIES initialization, encryp-tion, decryption; ECDH initialization, key establishment.

From figure 3, we can see that enabling all optimiza-tion switches requires long pre-computation. For exam-ple, it takes MICAz 3,493, 1,839 and 1,839 ms to do pre-computation for ECDSA, ECIES and ECDH, respectively.Most of the pre-computation time is for the sliding win-dow method and Shamir’s trick (ECDSA only). Tmote Skyruns slightly faster than MICAz. Running at 13 MHz, thedefault CPU frequency for Imote2, Imote2 is faster thanTmote Sky in all operations. If we set the frequency to416 MHz, it only takes 12 and 14 ms to generate ECDSAsignature and verify it. Moreover, it can perform ECIESencryption in 24 ms and decrypt in 15 ms. Finally, ECDHkey establishment only takes 13 ms.

Enabling all optimization switches requires the largestROM and RAM consumptions. Figure 4 shows the ROMand RAM requirements by all schemes. Imote2 has thelargest RAM size due to its word size. MICAz has thesmallest RAM size due to its 8-bit word size, but it has thelargest ROM size because it has additional assembly codefor minimizing memory operation when CURVE OPT op-tion is enabled.

Now consider the energy consumption of ECDSA,ECIES and ECDH on the testing platforms. We estimateenergy consumption using W = U × I × t, where U is thevoltage, I is the current draw in active mode with radio off,and t is the execution time. We took the voltage and cur-rent draw (with radio off) from the data sheet of each sensorplatform [1, 2, 4, 6], and used the execution time obtainedin our experiments. Specifically, we chose U as 3v for MI-CAz and TelosB/Tmote Sky. The current draw for MICAzand TelosB/Tmote Sky was 8 mA and 1.8 mA, respectively.For Imote2, U is 0.95v for 13 MHz and 104 MHz [1]. TheImote2 data sheet [1] does not give the current draw whenthe node runs at 104 MHz with radio off. To be conserva-tive, we use the current draw with radio on in our compu-tation. That is, we chose 31 mA and 66 mA for Imote2 at

253

20,7

68

16,0

18

13,5

20

15,6

58

11,3

96

16,3

52

17,7

28

12,8

52

19,3

08

0

5,000

10,000

15,000

20,000

25,000

ECDSA ECIES ECDH

RO

M s

ize

(byt

e)

MICAz Tmote Sky Imote2

(a) ROM size1,

774

1,77

4

1,50

4 1,81

6

1,81

6

1,82

8 2,06

4

2,06

4

1,51

0

0

500

1,000

1,500

2,000

2,500

ECDSA ECIES ECDH

RA

M s

ize

(byt

e)

MICAz Tmote Sky Imote2

(b) RAM size

Figure 4. Code size of ECDSA, ECIES, and ECDH w/all optimization switches enabled

83.8

4

48.0

4 58.4

8

44.1

3

93.7

8

63.1

8

44.1

3

50.8

2

13.7

4

8.54 10

.89

7.12

17.6

6

11.4

9

7.13 9.48

10.0

5

10.7

2

13.1

6

5.25

21.7

0

13.7

3

5.28 11

.55

2.68

2.86

3.51

1.40 5.

77

3.65

1.40 3.07

0

10

20

30

40

50

60

70

80

90

100

init(ECDSA)

sign(ECDSA)

verify(ECDSA)

init(ECIES)

encrypt(ECIES)

decrypt(ECIES)

init(ECDH)

key establish(ECDH)

Ene

rgy

cons

umpt

ion

(mJ)

MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz)

Figure 5. Energy consumption of ECDSA, ECIES,and ECDH w/ all optimization switches enabled

13 MHz and 104 MHz.Figure 5 shows the energy consumption required by all

these operations. Imote2 is the most energy efficient plat-form when it runs at 104 MHz. It needs 2.86 mJ and 3.51mJ to generate ECDSA signature and verify it; it needs5.77 mJ and 3.65 mJ to do ECIES encryption and decryp-tion; and it needs 3.07 mJ for the ECDH key agreementoperation. MICAz is the most energy consuming platform.TelosB/Tmote Sky is quite efficient at energy consumptiondue to its low current draw with radio off.

6.2.3. Most Storage-Efficient Configuration

Many TinyOS applications may use TinyECC for au-thentication, encryption/decryption, or key establishment.

0.08

3072

3.00

6180

0.34

0.08

6140

1.83

3187

2.28

0.08

3120

8.21

0.05

2128

4.39

4288

6.27

0.05

4255

8.09

2141

5.06

0.04

2115

1.53

0.03

2785

.11

5560

.35

0.04

5514

.29

2811

.87

0.04

2718

.31

0.00

348.

11

694.

99

0.01

689.

23

351.

45

0.01

339.

77

0.00

174.

06

347.

49

0.00

344.

63

175.

73

0.00

169.

89

0.00

87.1

2

174.

00

0.00

172.

42

88.0

2

0.00

85.0

5

0.001

0.01

0.1

1

10

100

1000

10000

100000

1000000

init(ECDSA)

sign(ECDSA)

verify(ECDSA)

init(ECIES)

encrypt(ECIES)

decrypt(ECIES)

init(ECDH)

key establish(ECDH)

Tim

e (m

s)

MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz) Imote2 (208 MHz) Imote2 (416 MHz)

Figure 6. Execution time of ECDSA, ECIES, andECDH w/ all optimization switches disabled

Thus it is likely that TinyECC will be loaded on sen-sor nodes with other applications. Due to the resourceconstraint of low-end sensor platforms (e.g., MICAz,TelosB/Tmote Sky), we may have to reduce ROM andRAM consumption by disabling some optimizations to re-serve enough space for the sensing applications.

For example, when all optimizations are enabled,ECDSA needs 19,308 bytes ROM and 1,510 bytes RAMon MICAz, as figure 4 shows. Stack overflow may happenwhen TinyECC is integrated with other programs such asTOSBase; the available stack for local variables may notbe large enough due to the limited RAM (4K bytes) onMICAz. As another example, Tmote Sky only has 48Kbytes ROM. If ECDSA with all optimizations enabled isintegrated with the SurgeTelos, a popular TinyOS applica-tion [5], the total ROM size would be 40,380 bytes, leavinglittle space for other applications.

We can disable all optimizations to show how compactTinyECC could be. Figure 6 shows the execution time ofECDSA, ECIES and ECDH when all optimization switchesare disabled. In this case, no pre-computation is needed,and the initialization time is close to 0. Imote2 runningat 416 MHz is still the fastest one, which MICAz is theslowest one.

The benefit of disabling all optimizations is the compactcode size. Figure 7 shows the code size of all schemes inTinyECC when all optimization switches are disabled. Dueto their word size, Imote2 has the largest RAM size, whileMICAz has the smallest RAM size. The code size has beenreduced greatly.

Since the execution time of TinyECC is much longer,the energy consumption of TinyECC is also increased asfigure 8 shows. In our experiments, the energy cost is in-creased by 6 to 25.4 times. Please refer to the technicalreport version of this paper [22] for detailed discussion.

7. Related WorkA comprehensive guide for elliptic curve cryptography

is given in [16]. Additional documentation on ECC can be

254

12,4

42

8,63

4

8,17

2

10,4

34

6,95

0

8,64

4

10,9

04

6,87

610,1

80

0

5,000

10,000

15,000

20,000

25,000

ECDSA ECIES ECDH

RO

M s

ize

(byt

e)

MICAz Tmote Sky Imote2

(a) ROM size15

0

150

160

158

158

176

172

172

152

0

500

1,000

1,500

2,000

2,500

ECDSA ECIES ECDH

RA

M s

ize

(byt

e)

MICAz Tmote Sky Imote2

(b) RAM size

Figure 7. Code size of ECDSA, ECIES, and ECDH w/all optimization switches disabled

0.00

737.

35

1483

.21

0.00

1473

.64

764.

93

0.00

749.

00

0.00 11

4.94

231.

59

0.00

229.

81

115.

64

0.00 11

4.22

0.00 82

.02

163.

75

0.00 16

2.40

82.8

1

0.00 80

.05

0.00

21.8

3

43.5

8

0.00 43

.21

22.0

4

0.00

21.3

0

0

400

800

1200

1600

2000

init(ECDSA)

sign(ECDSA)

verify(ECDSA)

init(ECIES)

encrypt(ECIES)

decrypt(ECIES)

init(ECDH)

key establish(ECDH)

Ene

rgy

cons

umpt

ion

(mJ)

MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz)

Figure 8. Energy consumption of ECDSA, ECIES,and ECDH w/ all optimization switches disabled

found in [7–9]. There have been numerous ECC implemen-tations in various contexts (e.g., Crypto++ [10]). Most ofthese implementations are aimed at traditional computingplatforms such as PCs.

Several recent efforts have focused on sensor platforms,such as the MICA series of motes. Malan et al. imple-mented ECC over binary extension fields F2m on TinyOSfor Mica2 [26]. Unfortunately, due to the constraints onthe typical micro-controllers used on sensor platforms, itis difficult to obtain efficient ECC implementation overF2m . Gura et al. implemented and compared ECC andRSA on Atmel ATmega128 in assembly [15]. However,it is not clear how well their implementation can be inte-grated into sensor network applications. Wang et al. imple-mented ECC on specific 160-bit elliptic curves on MICAzand TelosB running TinyOS [33]. They obtained fast ex-

ecution time by hard-coding all the curve parameters intoassembly code.

A common limitation of all these efforts is that allthese attempts were developed as independent pack-ages/applications without seriously considering the re-source demands of sensor network applications. As a re-sult, developers may find it difficult, and sometimes im-possible, to integrate an ECC implementation with thesensor network applications (e.g., not enough ROM orRAM), though the ECC implementation may be okay on itsown. In contrast, TinyECC provides a set of optimizationswitches that allow itself to be configured with different re-source consumptions. This allows TinyECC to be flexiblyintegrated into sensor network applications.

8. ConclusionIn this paper, we presented the design, implementation,

and evaluation of TinyECC. A unique feature of TinyECCis its configurability. It provides a number of optimizationswitches, which can turn specific optimizations on or offbased on developers’ needs. Different combinations of theoptimizations have different execution time and resourceconsumptions, and thus give the developers flexibility inintegrating TinyECC into sensor network applications. Wealso performed a series of experiments to evaluate the per-formance and resource consumptions of TinyECC withdifferent combinations of enabled optimizations, and pro-vided guidelines for configuring TinyECC for sensor net-work applications.

As a final note, we would like to point out that PKCcomponents could become the source of attacks if not prop-erly used. In particular, developers should pay special at-tention to Denial of Service (DoS) attacks against PKC.For example, TinyECC has been used to bootstrap securecode dissemination in wireless sensor networks [11, 17].However, if there is no additional protection, an attackermay repeatedly claim that a new code image is availableand convincing sensor nodes to perform many PKC opera-tions, eventually exhausting their battery power. Additionalmechanisms such as message specific puzzles [31] is thusnecessary.

Acknowledgment We would like to thank Ben Greensteinfor shepherding our paper. Panos Kampanakis ported anearlier version of TinyECC to Imote2. We are grateful tothe anonymous reviewers for their helpful comments.

References

[1] Imote2: High-performance wireless sensor networknode. http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/Imote2_Datasheet.pdf.

[2] MICAz: Wireless measurement system. http://www.xbow.com/Products/Product_pdf_

255

files/Wireless_pdf/MICAz_Datasheet.pdf.[3] SSL 3.0 specification. http://wp.netscape.com/

eng/ssl3/.[4] TelosB mote platform. http://www.xbow.com/

Products/Product_pdf_files/Wireless_pdf/TelosB_Datasheet.pdf.

[5] TinyOS: An open-source OS for the networked sensorregime. http://www.tinyos.net/.

[6] Tmote sky: Reliable low-power wireless sensor network-ing eases development and deployment. http://www.moteiv.com/products-tmotesky.php.

[7] American Bankers Association. ANSI X9.62-1998: PublicKey Cryptography for the Financial Services Industry: theElliptic Curve Digital Signature Algorithm (ECDSA), 1999.

[8] Certicom Research. Standards for efficient cryp-tography – SEC 1: Elliptic curve cryptography.http://www.secg.org/download/aid-385/sec1_final.pdf, September 2000.

[9] Certicom Research. Standards for efficient cryptography– SEC 2: Recommended elliptic curve domain parame-ters. http://www.secg.org/collateral/sec2_final.pdf, September 2000.

[10] W. Dai. Crypto++ library 5.5. http://www.cryptopp.com/, May 2007.

[11] J. Deng, R. Han, and S. Mishra. Secure code distributionin dynamically programmable wireless sensor networks. InProceedings of the Fifth International Conference on Infor-mation Processing in Sensor Networks (IPSN ’06), April2006.

[12] W. Diffie and M.E. Hellman. New directions in cryptogra-phy. IEEE Transactions on Information Theory, IT-22:644–654, November 1976.

[13] L. Eschenauer and V. D. Gligor. A key-management schemefor distributed sensor networks. In Proceedings of the 9thACM Conference on Computer and Communications Secu-rity, pages 41–47, November 2002.

[14] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, andD. Culler. The nesC language: A holistic approach to net-worked embedded systems. In Proceedings of Program-ming Language Design and Implementation (PLDI ’03),June 2003.

[15] N. Gura, A. Patel, and A. Wander. Comparing elliptic curvecryptography and RSA on 8-bit CPUs. In Proceedings of the2004 Workshop on Cryptographic Hardware and EmbeddedSystems (CHES 2004), pages 119–132, August 2004.

[16] D. Hankerson, A. Menezes, and S. Vanstone. Guide to El-liptic Curve Cryptography. Springer, 2004.

[17] S. Hyun, P. Ning, A. Liu, and W. Du. Seluge: Secureand dos-resistant code dissemination in wireless sensor net-works. In Proceedings of the Seventh International Confer-ence on Information Processing in Sensor Networks (IPSN’08), April 2008.

[18] S. Kent and R. Atkinson. IP authentication header. IETFRFC 2402, November 1998.

[19] D.E. Knuth. The Art of Computer Programming, volume 2:Seminumerical Algorithms. Addison-Wesley, third edition,1997. ISBN: 0-201-89684-2.

[20] RSA Laboratories. RSAREF: A cryptographic toolkit (ver-sion 2.0), March 1994.

[21] P.E. Lanigan, R. Gandhi, and P. Narasimhan. Sluice: Se-cure dissemination of code updates in sensor networks. InProceedings of the 26th International Conference on Dis-tributed Computing Systems (ICDCS ’06), July 2006.

[22] A. Liu and P. Ning. TinyECC: A configurable library for el-liptic curve cryptography in wireless sensor networks. Tech-nical Report TR-2007-36, North Carolina State University,Department of Computer Science, 2007.

[23] D. Liu and P. Ning. Establishing pairwise keys in distributedsensor networks. In Proceedings of 10th ACM Confer-ence on Computer and Communications Security (CCS’03),pages 52–61, October 2003.

[24] D. Liu and P. Ning. Multi-level µTESLA: Broadcast au-thentication for distributed sensor networks. ACM Transac-tions in Embedded Computing Systems (TECS), 3(4):800–836, 2004.

[25] D. Liu, P. Ning, S. Zhu, and S. Jajodia. Practical broad-cast authentication in sensor networks. In Proceedings ofthe 2nd Annual International Conference on Mobile andUbiquitous Systems: Networking and Services (MobiQui-tous 2005), July 2005.

[26] D. Malan, M. Welsh, and M. Smith. A public-key infras-tructure for key distribution in tinyos based on elliptic curvecryptography. In Proceedings of IEEE Conference on Sen-sor and Ad Hoc Communications and Networks (SECON),pages 71–80, 2004.

[27] K. Malasri and L. Wang. Addressing security in medicalsensor networks. In HealthNet ’07: Proceedings of the 1stACM SIGMOBILE international workshop on Systems andnetworking support for healthcare and assisted living envi-ronments, pages 7–12, 2007.

[28] A.J. Menezes, P. C. van Oorschot, and S.A. Vanstone. Hand-book of Applied Cryptography. CRC Press, 1996. ISBN:0-8493-8523-7.

[29] National Institute of Standards and Technology. Federal in-formation processing standard 186: Digital signature stan-dard. http://csrc.nist.gov/publications/,1993.

[30] National Institute of Standards and Technology. Recom-mended elliptic curves for federal government use, August1999.

[31] P. Ning, A. Liu, and W. Du. Mitigating DoS attacks againstbroadcast authentication in wireless sensor networks. ACMTransactions on Sensor Networks, 4(1), February 2008.

[32] A. Perrig, R. Canetti, D. Song, and D. Tygar. Efficientauthentication and signing of multicast streams over lossychannels. In Proceedings of the 2000 IEEE Symposium onSecurity and Privacy, May 2000.

[33] H. Wang and Q. Li. Efficient implementation of public keycryptosystems on mote sensors. In Proceedings of Interna-tional Conference on Information and Communication Se-curity (ICICS), pages 519–528, Dec. 2006.

256