Sie sind auf Seite 1von 12

TinyECC: A Configurable Library for Elliptic Curve Cryptography

in Wireless Sensor Networks

An Liu Peng Ning


Department of Computer Science Department of Computer Science
NC State University, Raleigh, NC 27695 NC State University, Raleigh, NC 27695
email: aliu3@ncsu.edu email: pning@ncsu.edu

Abstract wireless links. Such sensor networks are ideal candidates


for a wide range of applications such as monitoring of crit-
Public Key Cryptography (PKC) has been the enabling ical infrastructures, data acquisition in hazardous environ-
technology underlying many security services and proto- ments, and military operations. The desirable features of
cols in traditional networks such as the Internet. In the wireless sensor networks have attracted many researchers
context of wireless sensor networks, elliptic curve cryptog- to develop protocols and algorithms that can fulfill the re-
raphy (ECC), one of the most efficient types of PKC, is be- quirements of these applications.
ing investigated to provide PKC support in sensor network
applications so that the existing PKC-based solutions can Security services such as authentication and key man-
be exploited. agement are critical to communication security in wire-
This paper presents the design, implementation, and less sensor networks as well as the security of sensor net-
evaluation of TinyECC, a configurable library for ECC op- work applications. In traditional networks such as the Inter-
erations in wireless sensor networks. The primary objec- net, Public Key Cryptography (PKC) has been the enabling
tive of TinyECC is to provide a ready-to-use, publicly avail- technology underlying many security services and proto-
able software package for ECC-based PKC operations that cols (e.g., SSL [3] and IPsec [18]). For example, PKC has
can be flexibly configured and integrated into sensor net- been used to bootstrap symmetric session keys and authen-
work applications. TinyECC provides a number of opti- ticate messages to multiple receivers. However, in wireless
mization switches, which can turn specific optimizations sensor networks, PKC has not been widely adopted due to
on or off based on developers needs. Different combi- the resource constraints on sensor platforms, particularly
nations of the optimizations have different execution time the limited and depleteable battery power.
and resource consumptions, giving developers great flexi- There has been intensive research aimed at developing
bility in integrating TinyECC into sensor network applica- techniques that can bypass PKC operations in sensor net-
tions. This paper also reports the experimental evaluation work applications. For example, there has been a substan-
of TinyECC on several common sensor platforms, includ- tial amount of research on random key pre-distribution for
ing MICAz, Tmote Sky, and Imote2. The evaluation results pairwise key establishment (e.g., [13, 23]) and broadcast
show the impacts of individual optimizations on the exe- authentication (e.g., [24, 25]). However, these alternative
cution time and resource consumptions, and give the most approaches do not offer the same degree of security or func-
computationally efficient and the most storage efficient con- tionality as PKC. For instance, none of the random key
figuration of TinyECC. pre-distribution schemes can guarantee key establishment
between any two nodes and tolerate arbitrary node com-
1. Introduction promises at the same time. As another example, the afore-
mentioned broadcast authentication schemes, which are all
Recent technological advances have made it possible
based on TESLA [32], require loose time synchronization,
to develop wireless sensor networks consisting of a large
which itself is a challenging task to achieve in wireless
number of low-cost, low-power, and multi-functional sen-
sensor networks. In contrast, PKC can address all these
sor nodes that communicate over short distances through
problems easily. Pairwise key establishment can always be
This work is supported by the National Science Foundation under
achieved using, for example, the Diffie-Hellman (DH) key
grants CAREER-0447761 and CNS-0721424, and by the Army Research
exchange protocol [12], without suffering from the node
Office under grants W911NF-05-1-0247 and W911NF-04-D-0003. The
contents of this paper do not necessarily reflect the position or the policies compromise problem. Similarly, broadcast authentication
of the U.S. Government. can be provided with, for example, the ECDSA digital sig-
nature scheme [7], without requiring time synchronization. unique feature of TinyECC is its configurability. TinyECC
Thus, it is desirable to explore the application of PKC on includes almost all known optimizations for ECC opera-
resource constrained sensor platforms. tions. Each optimization is controlled by a software switch,
There have been a few recent attempts to use PKC in which can turn the optimization on or off based on devel-
wireless sensor networks [15, 26, 33], which demonstrate opers needs. Different combinations of optimizations have
that it is feasible to perform limited PKC operations on the different ROM/RAM consumption, execution time, and en-
current sensor platforms such as MICAz motes [2]. Elliptic ergy consumption. This gives the developers great flexibil-
Curve Cryptography (ECC) has been the top choice among ity in integrating TinyECC in their applications.
various PKC options due to its fast computation, small To provide guidance in using TinyECC, we perform a
key size, and compact signatures. For example, to provide series of experiments with different combinations of ac-
equivalent security to 1024-bit RSA, an ECC scheme only tivated optimizations. To understand the impact of each
needs 160 bits on various parameters, such as 160-bit finite optimization technique, we compare the execution time,
field operations and 160-bit key size [8]. ROM/RAM consumption, and energy consumption with
Despite the recent progress on ECC implementations and without the given optimization enabled on MICAz [2],
on sensor platforms, all the previous attempts [15, 26, 33] Tmote Sky [6], and Imote2 [1]. In addition, our experi-
have limitations. In particular, all these attempts were de- ments also present the performance results and the resource
veloped as independent packages/applications without se- usages for the most computationally efficient configuration
riously considering the resource demands of sensor net- (i.e., fastest execution and least energy consumption) and
work applications. As a result, developers may find it dif- the most storage-efficient configuration (i.e., least ROM
ficult, and sometimes impossible, to integrate an ECC im- and RAM usage) of TinyECC on these common sensor
plementation with the sensor network applications, though platforms, respectively.
the ECC implementation may be okay on its own. For ex- The contribution of this paper is two-fold: First, we de-
ample, an ECC implementation may require so much RAM velop TinyECC to allow flexible integration of ECC-based
that it would be impossible to fit both the sensor network PKC in sensor network applications. Second, we per-
application and the ECC implementation on the same node. form a substantial amount of experimental evaluation us-
Moreover, various optimization techniques are available ing representative sensor platforms, including MICAz [2],
to speed up the ECC operations. Such optimizations, how- TelosB [4], Tmote Sky [6], and Imote2 [1]. The experi-
ever, typically will increase the ROM and RAM consump- mental results provide useful experience and guidance for
tions, though they may reduce the execution time and en- developers to choose different TinyECC optimizations for
ergy consumption. It is not clear what optimizations should their needs.
be used and how they should be combined to achieve The remainder of this paper is organized as follows.
the best trade-off among security protection, computation Section 2 discusses the design principles of TinyECC. Sec-
overheads, and storage requirements. Additional research tion 3 gives background information on ECC. Section 4 de-
is necessary to clarify these issues and facilitate the adop- scribes the optimization techniques adopted by TinyECC.
tion of ECC-based PKC in wireless sensor networks. Section 5 discusses the implementation of TinyECC. Sec-
It is certainly possible to have dedicated PKC hardware tion 6 presents the experimental evaluation of TinyECC on
included on sensor platforms. However, given that there MICAz, Tmote Sky, and Imote2. Section 7 discusses the
is no PKC hardware that is currently available on current related work, and Section 8 concludes this paper.
sensor platforms, it is a sensible choice to explore software
approaches for PKC support on sensor platforms. 2. Design Principles
In this paper, we present the design, implementation, As mentioned earlier, the primary objective of TinyECC
and evaluation of TinyECC, a configurable library for ECC is to provide a ready-to-use, publicly available software
operations in wireless sensor networks.1 The primary ob- package for ECC-based PKC operations that can be flexibly
jective of TinyECC is to provide a ready-to-use, publicly configured and integrated into sensor network applications.
available software package for ECC-based PKC operations To make sure we achieve this objective, we follow several
that can be flexibly configured and integrated into sensor principles in the design and development of TinyECC.
network applications. Security: TinyECC should provide PKC schemes that
Targeted at TinyOS [5], TinyECC is written in have proven to be secure. To follow this principle,
nesC [14], with occasional in-line assembly code to achieve TinyECC only includes support for the well-studied ECC
further speedup for popular sensor platforms including MI- schemes such as ECDSA, ECDH, and ECIES, which are
CAz [2], TelosB [4], Tmote Sky [6], and Imote2 [1]. A defined in the Standards for Efficient Cryptography [8].
1 TinyECC 1.0 and its previous versions are publicly available at Moreover, TinyECC also includes elliptic curve parame-
http://discovery.csc.ncsu.edu/software/TinyECC/. ters recommended by SECG (Stands for Efficient Cryp-

2
tography Group), such as secp160k1, secp160r1 and cryptography are typically defined over two types of finite
secp160r2, as defined in [9]. fields: prime fields Fp , where p is a large prime number,
Portability: TinyECC should run on as many sensor and binary extension fields F2m . For space reasons, we fo-
platforms as possible. Due to this reason, we choose to cus on elliptic curves over Fp in this paper.
implement TinyECC on TinyOS [5], which is a popular,
open-source OS for networked sensors. All the TinyECC An elliptic curve over Fp is defined by a cubic equation
components have nesC [14] implementations, though some y2 = x3 + ax + b, where a, b Fp are constants such that
modules also include inline assembly code, which can be 4a3 + 27b3 6= 0 [16]. An elliptic curve over Fp consists of
turned on for faster execution on some sensor platforms. the set of all pairs of affine coordinates (x, y) for x, y Fq
This allows TinyECC to be compiled and used on any sen- that satisfy an equation of the above form and an infinity
sor platform that can run TinyOS. TinyECC has been tested point O. The points on an elliptic curve form an abelian
successfully on MICAz, TelosB, Tmote Sky, and Imote2. group with O as the additive identity. (The formulas defin-
Resource Awareness and Configurability: TinyECC ing point addition and its special case, point doubling, can
should accommodate the typical resource constraints on be found in [16].)
sensor nodes. Moreover, TinyECC should allow for flex-
For any point G on an elliptic curve, the set
ible configuration so that it can take advantage of the avail-
{O, G, 2G, 3G, ...} is a cyclic group [16]. The calcula-
able resources on a wide spectrum of sensor platforms. To
tion of kG, where k is an integer, is called a scalar mul-
follow this principle, TinyECC is implemented carefully
tiplication. The problem of finding k given points kG
to avoid unnecessary resource usage. Moreover, TinyECC
and G is called the elliptic curve discrete logarithm prob-
uses a set of optimization switches, which can be turned
lem (ECDLP). It is computationally infeasible to solve
on or off to achieve different combinations of performance
ECDLP for appropriate parameters [16]. The hardness of
and resource consumptions.
ECDLP allows several cryptographic schemes based on el-
Efficiency: TinyECC should be computationally effi-
liptic curves.
cient to reduce the battery consumption as well as the de-
lay introduced by PKC operations. We make three design TinyECC includes three well-known ECC schemes:
decisions to improve the efficiency of TinyECC. The first (1) the Elliptic Curve Diffie-Hellman (ECDH) key agree-
is about the type of finite fields over which the ECC opera- ment scheme, (2) the Elliptic Curve Digital Signature Algo-
tions are performed. ECC can be implemented over either rithm (ECDSA), and (3) the Elliptic Curve Integrated En-
a prime field Fp , where p is a large prime number, or a bi- cryption Scheme (ECIES). ECDH is a variant of the Diffie-
nary extension field F2m , where m is an integer. Since arith- Hellman key agreement protocol [12] on elliptic curve
metic operations over F2m are insufficiently supported by groups. ECDSA is a variant of the Digital Signature Al-
micro-controllers, we choose to support prime fields Fp in gorithm (DSA) [29] that operates on elliptic curve groups.
TinyECC. Second, we adopt almost all existing optimiza- ECIES is a public-key encryption scheme which provides
tions for ECC operations in TinyECC. As mentioned ear- semantic security against an adversary who is allowed to
lier, these optimizations can be turned on or off to balance use chosen-plaintext and chosen-ciphertext attacks [16].
the efficiency and the resource requirements. Third, we in- ECIES is also known as the Elliptic Curve Augmented En-
clude inline assembly code in critical parts of TinyECC cryption Scheme (ECAES) or simply the Elliptic Curve En-
for popular sensor platforms, including MICAz, TelosB, cryption Scheme. These ECC schemes allow smaller key
Tmote Sky, and Imote2. sizes for similar security level to the alternatives such as the
Functionality: TinyECC should support the typical original DH and DSA schemes. For each of the schemes,
demands for PKC. To follow this principle, the current a party that would like to use the scheme needs to agree
version of TinyECC includes a digital signature scheme on some domain parameters such as the elliptic curve and a
(ECDSA), a key exchange protocol (ECDH), and a pub- point G on the curve, and must have a key pair consisting of
lic key encryption scheme (ECIES). These cover all typical a private key d and a public key Q = dG. The specification
uses of PKC. of ECDH, ECDSA, and ECIES can be found in [8, 16].
3. Background on ECC
In this and next sections, we give an overview of ECC 4. Optimizations Adopted by TinyECC
and the optimizations adopted by TinyECC as a convenient
reference. The reader can find details in the references. In this section, we briefly discuss the optimization tech-
Elliptic curve cryptography (ECC) is an approach to niques adopted by TinyECC. We will omit the details, since
public-key cryptography based on the algebraic structure of the focus of this paper is not these individual optimization
elliptic curves over finite fields [16]. Elliptic curves used in techniques. More information about these techniques can
be found in the relevant references.

3
4.1. Optimizations for Large Integer Operations 4.2. Optimizations for ECC Operations
Projective Coordinate Systems [16]: As discussed ear-
Barrett Reduction [28]: A straightforward way to
lier, an elliptic curve consists of the infinity point O and the
perform large integer modular reductions is to use divi-
set of points in the affine coordinates (x, y) for x, y Fp that
sion [19]. A nice side effect is that it reuses the code of
satisfy the defining equation. Alternatively, a point on an
division, thus resulting in more compact code size.
elliptic curve can be represented in a projective coordinate
Barrett Reduction is an alternative method for modular system in the form of (x, y, z).
reduction [28]. It converts the reduction modulo an arbi- Point addition and point doubling are critical operations
trary integer to two multiplications and a few reductions in ECC, which are building blocks for scalar multiplica-
modulo integers of the form 2n . When used to reduce a tions required by all ECC schemes. These operations in
single number, Barrett reduction is slower than a normal affine coordinate system require modular inversion oper-
division algorithm. However, when used to reduce vari- ations, which are much more expensive than other oper-
ous numbers modulo the same number many times, by pre- ations such as modular multiplications. Using a projective
computing some value, Barrett reduction can achieve faster coordinate system [16], modular inversions can be removed
speed than modular reductions obtained by division. De- with the compensation of a few modular multiplications
tails of Barrett reduction can be found in [28]. and squares. As a result, the execution times of point ad-
dition and point doubling based on projective coordinate
In TinyECC, since almost all the modular operations
system are faster than those based on affine coordinate sys-
are modulo the same prime number p, Barrett reduction
tem, respectively [16].
can potentially speed up the computation. However, this
requires the implementation of a separate reduction algo- TinyECC uses two additional optimizations along with
rithm, which implies larger code size (i.e., greater ROM projective coordinate representation, which can further re-
requirement) on sensor nodes. In addition, Barrett reduc- duce both the execution time and the program size. The
tion also increases RAM use. Assume the target micro- first is a mixed point addition algorithm [16], which adds a
controller has a w-bit word size. Given a finite field Fp , point in projective coordinate and a second point in affine
where p is a k words long prime number, Barrett reduction coordinate. This algorithm can be used in scalar multipli-
k cations to further reduce the number of modular multiplica-
requires the pre-computation of = bp , where b = 2w
tions and squares, leading to smaller and faster code. The
(e.g., b = 28 on a 8-bit processor). This number has to second is repeated Doubling [16] for scalar multiplication.
be stored and used throughout all the modular reductions. If consecutive point doublings are to be performed, the re-
Thus, to exchange for faster computation, Barrett reduction peated doubling algorithm may be used to achieve faster
requires more ROM and RAM than the traditional division- performance than repeated use of the doubling formula. In
based modular reduction. m consecutive doublings, this algorithm trades m 1 field
Hybrid Multiplication and Hybrid Squaring [15]: additions, m 1 divisions by two, and a multiplication for
Standard large integer multiplication algorithms [19] store two field squarings (in comparison with repeated applica-
the operands and the product in arrays. When such an al- tions of the plain point doubling algorithm) [16].
gorithm is implemented in a high-level language such as Though reducing the execution time, the projective co-
nesC, the compiler cannot use the registers in the micro- ordinate representation requires a larger code size (for more
controller efficiently, and the binary code usually needs complex formula) and more RAM (for storing additional
to load the operands from memory to registers multiple variables) than the affine coordinate system.
times [15]. Gura et al. [15] proposed a hybrid multipli- Sliding Window for Scalar Multiplications [16]:
cation algorithm, which was intended for assembly code. Scalar multiplication is a basic operation used by all ECC
This algorithm can maximize the utilization of registers schemes. It is in the form of kP, where k is an integer and
and reduce the number of memory operations. TinyECC P is a point on an elliptic curve. In the most straightfor-
adopts this hybrid multiplication algorithm for MICAz [2], ward method to compute kP, k is scanned from the most
TelosB [4]/Tmote Sky [6], and Imote2 [1]. Indeed, the code significant bit to the least significant bit. When each bit is
can be used on any sensor platforms that have processors scanned, the algorithm needs to compute a point doubling.
using the same instruction sets. When the scanned bit is 1, the algorithm also needs to
perform a point addition. The sliding window method can
In addition to hybrid multiplication, we also customize
speed up the scalar multiplication by scanning w bits at a
the hybrid multiplication algorithm for squaring operations
time. Each time when a w-bit window is scanned, the algo-
by using the fact that the two multiplicative operands in
rithm needs to perform w point doublings. By precomput-
squaring are the same. This further reduces the execution
ing 2P, 3P, ..., and (2w 1)P, the sliding window method
time for squaring at the cost of larger code size.

4
only needs to perform 1 point addition every w bits, and //discovery.csc.ncsu.edu/software/
thus has less computational cost. TinyECC/. Some preliminary versions have been
It is easy to see that the sliding window method will adopted by other researchers (e.g., [11, 21, 27]). As
increase both the ROM (for additional code size) and RAM discussed earlier, starting from the current version, we
(for storing the pre-computed points) consumptions. added a set of optimization switches to provide for flexible
Shamirs Trick [16]: This optimization is only used configuration of TinyECC so that it can be integrated
for the verification of ECDSA signatures. The verification into sensor network applications with different resource
of ECDSA signature requires the computation of the form consumptions and performance demands.
aP + bQ, where a, b are integers and P, Q are two points Table 1 lists the optimization switches available in the
on an elliptic curve. A straightforward implementation current version of TinyECC. All optimization switches can
requires two scalar multiplications and a point addition. be turned on or off by a simple configuration at compile
However, Shamirs trick allows us to compute the above time, or slight modification in the source code. Moreover,
value at a cost close to one scalar multiplication. Specif- when the sliding window method is used, an additional pa-
ically, with pre-computed P + Q, we may scan the (same) rameter defining the size of the window (e.g., w = 4) needs
bits of a and b from the most significant one to the least to be specified.
significant one. For each bit, we need double the interme-
diate value, which is initialized as the infinity point. If the 6. Evaluation
scanned bit positions are hai = 0, bi = 1i, hai = 1, bi = 0i, We performed a series of experiments to evaluate
or hai = 1, bi = 1i, we add P, Q, or P + Q to the interme- TinyECC on four representative sensor platforms, includ-
diate value. This reduces two scalar multiplications to be a ing MICAz [2], TelosB [4], Tmote Sky [6], and Imote2 [1].
bit more expensive than one such operation. The objective of these experiments is three-fold: First,
Similar to the sliding window method, Shamirs trick we want to measure the performance and resource con-
will increase both the ROM (for additional code size) and sumption of TinyECC on a spectrum of sensor platforms,
RAM (for storing the pre-computed P + Q) consumptions. ranging from the low-end ones (such as MICAz, TelosB,
Curve Specific Optimization [15]: A number of el- and Tmote Sky) to high-end ones (such as Imote2). Sec-
liptic curves specified by NIST [30] and SECG [9] use ond, we would like to understand the impact of the op-
pseudo-Mersenne primes. A pseudo-Mersenne prime is of timizations adopted by TinyECC on performance and re-
the form p = 2n c, where c 2n . Reduction modulo a source consumption. Finally, we would like to provide de-
pseudo-Mersenne prime can be performed by a few mod- tailed performance results and resource demands for com-
ular multiplications and additions without any division op- monly desirable configurations, including the configuration
eration. As a result, the time for modular reduction can that provides the fastest execution time and the configura-
be reduced significantly. Thus, using elliptic curves over tion that requires the least memory consumption. The for-
a pseudo-Mersenne prime can achieve additional perfor- mer has the least energy consumption, while the latter is the
mance gain. easiest one to integrate into sensor network applications.
5. Implementation 6.1. Methodology and Experimental Setup
We implemented TinyECC on TinyOS [5], an open Evaluation Methodology: Given seven optimization
source operating system designed for wireless embedded switches, four sensor platforms, where Imote2 has mul-
sensor networks. The current version of TinyECC provides tiple CPU frequencies due to dynamic voltage scaling,
support for ECDSA (digital signatures), ECDH (pairwise many possible elliptic curves, and three ECC-based PKC
key establishment), and ECIES (PKC-based encryption). schemes, there are a large number of experiments to per-
Most of the code was written in nesC [14] for portability form if we have to observe the performance and resource
reasons. To best harness the capabilities of the processors consumptions in all cases.
on popular sensor platforms such as MICAz and TelosB, To simplify the scenarios, we adopted the following
we also provided inline assembly implementation of some methodology in our experiments. For each optimization
critical operations, such as large integer multiplications. switch, we performed two sets of experiments, referred to
To save implementation efforts, we ported the C code of as case A and case B, respectively. In case A, for each opti-
large integer operations in RSAREF 2.0 [20] to nesC code mization, we disabled all the other optimizations, and then
on TinyOS. These include modular addition, subtraction, obtained the performance and resource consumption met-
multiplication, division, inverse, and exponentiation opera- rics when the given optimization was enabled and disabled,
tions. We then implemented all the elliptic curve operations respectively. In case B, we enabled all the other optimiza-
and the optimization techniques discussed earlier. tions and obtained the evaluation metrics again when the
TinyECC has been released publicly at http: given optimization was enabled and disabled, respectively.

5
Table 1. TinyECC Optimization Switches
Method 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.
Shamirs Trick SHAMIR TRICK EC Allow Shamirs 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 the all performance result, we randomly generated the parame-
given optimization technique. ters (e.g., random message, random public and private key
Moreover, as discussed earlier, we also performed ad- pairs) other than those defining the curves, and obtained
ditional experiments to examine in detail two commonly the execution time for each data point by taking the av-
desirable configurations: the one that provides the fastest erage of 10 test instances. The energy consumption was
execution time, and the one that requires the least storage. then calculated as U I t based on the execution time
Experimental Setup: We evaluated TinyECC on the (t), the voltage (U), and current draw (I) on these sensor
latest CVS version of TinyOS 1.x [5]. As discussed ear- platforms [1, 2, 4, 6].
lier, we chose four representative sensor platforms, MI- 6.2. Evaluation Results
CAz, TelosB, Tmote Sky, and Imote2, for the experiments,
since they are popular sensor platforms and cover the 8-bit, Due to the space limit, we can only report a portion of
16-bit and 32-bit processors. Other sensor platforms (e.g., the evaluation results. Please refer to the full version of this
Mica2, Mica2Dot) are expected to perform similarly to one paper [22] for more details.
of these platforms, due to the use of the same processor. 6.2.1. Impact of Individual Optimizations
TelosB and Tmote Sky have almost the same hardware. In the following, we use the experimental results for
The only difference is that TelosB can only run at 4 MHz, ECDSA to show the impact of individual optimization
while Tmote Sky can run at 8 MHz when an external resis- techniques. More results on the impacts of these optimiza-
tor is enabled. We configure Tmote Sky to run at 8 MHz in tions on ECDH and ECIES can be found in [22].
our experiments. Due to the similarity between TelosB and There are three aspects of the execution time for
Tmote Sky, we only report the results on Tmote Sky in this ECDSA. Figures 1(a) and 1(b) show the initialization time
paper. The reader may refer to the technical report version required to prepare for ECDSA in cases A and B, respec-
of this paper [22] for experimental results on TelosB. tively. Figures 1(c) and 1(d) show the signature generation
As a high-end sensor platform, Imote2 uses an XScale time in cases A and B, respectively. Figures 1(e) and 1(f)
processor and supports dynamic voltage scaling. To ob- show the signature verification time in cases A and B, re-
tain a relatively complete view of Imote2, we used four dif- spectively.
ferent frequencies on Imote2 in our experiments: 13MHz, In the initialization of ECDSA, TinyECC needs to pre-
104MHz, 208MHz, and 416MHz. compute for Barrett reduction, a few points for the slid-
By default, TinyECC includes all 128-bit, 160-bit and ing window method, and a few points for Shamirs trick.
192-bit ECC parameters recommended by SECG [9]. It In case A, as Figure 1(a) shows, only these 3 optimiza-
is well-known that 160-bit ECC has the same security tion techniques have impact on the initialization time. For
level as 1024-bit RSA. We selected a 160-bit elliptic curve MICAz, the initialization of the sliding window method
secp160r1 [9] to evaluate the impact of individual op- with window size 4 requires 3,587 ms, which is longer
timization techniques. Note that the actual selection of than Shamirs trick (1,672 ms for window size 2) and
curves depends on the security needs in the sensor network Barrett reduction (6 ms). The same situation applies to
applications, and is outside of the scope of this paper. TelosB/Tmote Sky, and Imote2. If we disable all these
We used the following evaluation metrics in all ex- three techniques, the initialization time of ECDSA is close
periments: ROM consumption (byte), RAM consumption to 0. In case B, as Figure 1(b) shows, the disabling of se-
(byte), execution time (ms), and energy consumption (mil- lected optimization technique does not reduce the initial-
lijoule). We used the check size.pl script in the ization time dramatically, except that the disabling of the
TinyOS distribution to obtain the ROM and RAM sizes re- sliding window method reduces the initialization time by
quired by the TinyECC components. The execution time half.
was measured directly on the sensor nodes. To get the over- In Figure 1, we can see that PROJECTIVE is the most

6
Disable All BARRETT HYBRID_MULT HYBRID_SQR Enable All BARRETT HYBRID_MULT HYBRID_SQR
CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2) CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

1000000.0000 1000000.0000

3586.6933

2465.4326
1671.8788

3772.85
3826.72
1146.4202

3572.08

3626.14
3493.36
3486.92

3292.86

2934.96
2594.95

2641.15
2545.18
2544.20
2566.90
2327.40
1684.46

1230.10
319.7278
148.8784
10000.0000 10000.0000

378.47
360.12
346.92

353.18
341.25
340.46

300.22
164.50
39.9632

19.9811
18.6104

47.31
45.01

44.14
42.68
42.57
43.36
37.53
10.0027

23.66
22.50

22.07
21.68
21.34
21.29
20.56

18.76
9.3050
6.3978

11.85
11.32
10.91

11.11
10.74
10.71
10.28
4.6558
4.0771
100.0000 100.0000
Time (ms)

Time (ms)

9.40
5.17
0.7864

0.0988
0.0781
0.0781
0.0781
0.0781
0.0781

0.0580
0.0519

0.0498
0.0488
0.0488
0.0427
1.0000 1.0000

0.0281
0.0278
0.0284
0.0277
0.0282

0.0271
0.0043
0.0041

0.0042
0.0040
0.0040

0.0025
0.0023
0.0023

0.0023
0.0023

0.0023
0.0023
0.0023
0.0023
0.0020
0.0100 0.0100

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

(a) Init. time when all other optimizations are disabled (case A) (b) Init time when all other optimizations are enabled (case B)
Disable All BARRETT HYBRID_MULT HYBRID_SQR Enable All BARRETT HYBRID_MULT HYBRID_SQR
CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2) CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

1000000 1000000
31760.27
30723.00
30423.74
30207.65

30725.57
29591.55
25273.89

23565.96
21779.61
21284.39
21220.11

21323.55
21196.15
20918.37
17333.41

16777.23
100000 100000
9086.12

4177.88

4066.37
3249.44

3045.78
2936.58

2957.78
2785.11
2766.76

2785.10
2750.48
2710.26

2456.95
2270.90

2179.79
2007.97

2041.65
2001.62

2001.62

1865.71
1894.93
1580.63
1585.60

1583.22
10000 10000
891.13

611.52
Time (ms)

Time (ms)

459.20
447.39
431.97
367.06

363.98
364.97

365.73
348.11
345.82

348.11
343.79
338.76
283.84

272.45
183.53
174.06

174.06
172.91
171.89
169.38

1000 1000
141.92

136.20
111.39

91.81
87.12

87.12
86.56
86.04
84.81

76.44
71.07

68.28
57.40
55.92
55.70

53.99
45.63
45.86

45.72

38.21
28.70
28.31

27.93
27.00
22.93

22.86
22.82
100 100

19.25
14.78
14.34
13.91
11.95
11.80

11.82
10 10

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

(c) Sig. generation time when all other optimizations are disabled (case A) (d) Sig. generation time when all other optimizations are enabled (case B)
Disable All BARRETT HYBRID_MULT HYBRID_SQR Enable All BARRETT HYBRID_MULT HYBRID_SQR
CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2) CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

1000000 1000000
63892.90
61800.34
61197.70
60761.77
59517.10
50807.12

43841.09
42886.27
42724.94
42675.35
42115.65
34745.25
30484.70

28509.93
20793.69

20157.31
18294.94

100000 100000
8425.67

5863.27
5560.35
5523.87
5491.07
5411.92

5048.30
4514.04

4108.00

4020.43

3804.69
3556.52

3175.11
2710.03

2606.36
2436.46
2442.09

2436.49

2411.19
2347.82
2016.02
2020.10

2018.40
1783.73

10000 10000

754.55
732.85

725.52
694.99
690.44
686.41
676.45
564.21

557.07
525.87
Time (ms)

Time (ms)

446.85
446.29

447.57
366.43
347.49
345.22
338.73

343.17
338.22

325.77
282.10
222.95

183.31
174.00
172.87
171.75
169.37

169.55

162.91
1000 1000
141.20
111.46

94.31

90.68
84.77

81.65
69.63
65.73
56.19

56.02
55.96

55.94

47.15

45.34
34.78
32.87
28.01
27.98

27.97

23.75

23.38
100 100

17.84
16.93
14.49
14.49

14.48
10 10

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

(e) Sig. verification time when all other optimizations are disabled (case A) (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 Barrett
reduction does not have obvious impact.)
effective switch to improve the speed of signature genera- as Figures 2(c) and 2(d) show, disabling the PROJECTIVE
tion and verification. In case A, by enabling the PROJEC- switch can save 3,816, 3,880, and 4,660 bytes in ROM for
TIVE switch, the signature generation and verification of all MICAz, TelosB/Tmote Sky, and Imote2, respectively. The
platforms can speed up by at least 3 times. In case B, if we PROJECTIVE switch is the most effective switch to speed
disable the PROJECTIVE switch, the signature generation up ECDSA operations, but it also incurs larger ROM con-
and verification has at least 6 times slowdown compared sumption than any other optimization technique.
with enabling all optimization techniques.
SHAMIR TRICK is also an efficient option to speed up
Although PROJECTIVE is the most efficient switch, it ECDSA signature verification. From Figure 1(e), we can
increases the ROM usage. Figures 2(a) and 2(b) show that see that the verification can speed up by 2 times on all
when the PROJECTIVE switch is enabled in case A, the platforms when enabling SHAMIR TRICK in case A. Both
ROM size is increased by 1,218, 1,326, and 1,752 bytes ROM and RAM sizes are increased. In case A, the RAM
for MICAz, TelosB/Tmote Sky, and Imote2, respectively, size is increased by 634, 676, and 784 bytes for MICAz,
while the RAM size does not change at all. In case B, TelosB/Tmote Sky, and Imote2, respectively. Similarly, the

7
ROM size of MICAz, TelosB/Tmote Sky and Imote2 is in- Disable All BARRETT HYBRID_MULT HYBRID_SQR
CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)
creased by 638, 632, and 620 bytes, respectively. In case
25,000
B, disabling SHAMIR TRICK makes verification 1.6 times
slower but saves 2,148, 2,068, and 2,208 bytes in ROM for 20,000

ROM size (Byte)


MICAz, TelosB/Tmote Sky, and Imote2, respectively. The

11,500
11,468

11,398
11,278

10,818
10,690

10,396
10,374
15,000

10,180

10,048
9,498
9,358

9,264
9,232
RAM size does not decrease much because the sliding win-

8,896
8,804

8,824
8,696
8,660

8,644
8,364
8,310
8,172

8,208
10,000
dow method is used for verification when SHAMIR TRICK
is disabled. 5,000

Now let us take a look at the SLIDING WIN option. In 0


MICAz Tmote Sky Imote2
case A, as Figures 1(c), 1(e), 2(a) and 2(b) show, enabling
SLIDING WIN can make signature generation and verifica- (a) ROM size w/ all other optimizations disabled (case A)
tion 1.2 times faster at the cost of dramatic RAM increase
Disable All BARRETT HYBRID_MULT HYBRID_SQR
(1,262, 1,328 and 1,472 bytes for MICAz, TelosB/Tmote CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

Sky, and Imote2, respectively). In case B, as Figures 2,500


1(d), 1(f), 2(c) and 2(d) show, disabling SLIDING WIN

1,648
2,000
can save 632, 668, and 752 bytes of RAM for MICAz,

1,488
1,414
RAM size (Byte)
TelosB/Tmote Sky, and Imote2 with 1.2 times slower sig- 1,500

960
nature generation and verification. Since MICAz and

836
786
1,000

TelosB/Tmote Sky are low-end sensor platforms, they have

292
258
244
500

176

176
176
176
176
160

160
160
160
160
152

152
152
152
152
much smaller RAM (4kB, 10kB) compared with Imote2
0
(256kB). Before enabling SLIDING WIN, we should be MICAz Tmote Sky Imote2
very careful if the sensing application has large RAM con-
sumption. Since SLIDING WIN is the most RAM consum- (b) RAM size w/ all other optimizations disabled (case A)
ing switch in TinyECC, application developers may disable Enable All BARRETT HYBRID_MULT HYBRID_SQR
it or reduce the window size to reserve more RAM for the CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)

applications. 25,000
19,308

18,378

18,246

18,196
18,080
17,970

Now consider the HYBRID MULT, HYBRID SQR, and


17,160

16,352

16,300
16,172
15,492

15,452
20,000

14,940

14,972
14,708

14,672
14,570

14,144
13,904
13,520

13,546
CURVE OPT options. In case A, HYBRID MULT, HY-
ROM size (Byte)

12,640

11,692
10,828
15,000
BRID SQR and CURVE OPT do not have big impact on
the timing result. However, in case B, HYBRID MULT 10,000

can speed up signature generation by 1.6 times for MI- 5,000

CAz, 1.2 times for TelosB/Tmote Sky, and 1.2 times for 0
Imote2. Similarly, it can speed up signature verification MICAz Tmote Sky Imote2

by 1.7 times for MICAz, 1.2 times for TelosB/Tmote Sky,


and 1.2 times for Imote2. HYBRID SQR can speed up sig- (c) ROM size w/ all other optimizations enabled (case B)

nature generation by 1.5 times for MICAz, 1.2 times for Disable All BARRETT HYBRID_MULT HYBRID_SQR
CURVE_OPT PROJECTIVE SLIDING_WIN(w=4) SHAMIR_TRICK(w=2)
TelosB/Tmote Sky, and 1.2 times for Imote2, and speed up
2,500
signature verification by 1.5 times for MICAz, 1.2 times for
1,828

1,828
1,828
1,828
1,828

1,764
TelosB/Tmote Sky, and 1.2 times for Imote2. CURVE OPT
1,712

2,000
1,602

1,602
1,602
1,602
1,602

1,586
1,510

1,510
1,510
1,510
1,510

1,506

1,504
1,418
RAM size (Byte)

can speed up signature generation by 2 times for MICAz, 1,500


1,076

1.9 times for TelosB/Tmote Sky, and 1.7 times for Imote2.
934
878

1,000
Similarly, it can speed up signature verification by 2.1
times for MICAz, 1.9 times for TelosB/Tmote Sky, and 500

1.7 times for Imote2. The reason that HYBRID MULT, 0

HYBRID SQR and CURVE OPT cannot speed up ECDSA MICAz Tmote Sky Imote2

much in case A is that the PROJECTIVE option is disabled


(d) RAM size w/ all other optimizations enabled (case B)
when each of these switches is enabled. Thus, inverse op-
eration is the major computation of signature generation Figure 2. Code size of ECDSA (Sliding window has
and verification. In case B, when PROJECTIVE is enabled, the most memory demand, Shamirs trick ranks the
multiplication and squaring become the major computation next, while all the other optimizations have similar
in ECDSA. memory demands.)
Based on the timing results obtained for ECDSA, the
effectiveness of these optimization switches in terms of

8
Available ROM (byte) How to Conf. TinyECCs Switches MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz) Imote2 (208 MHz) Imote2 (416 MHz)

[10, 180, 10, 374) disable all 100000

3907.46
[10, 374, 11, 398) enable SLIDING WIN

3493.36

3271.01

2632.66
2545.18

2436.46

2127.77

2117.43
2016.02
2001.62

1838.74

1838.74

1755.96
10000

1580.63

1319.32

1319.54
[11, 398, 17, 160) enable PROJECTIVE

736.97

466.10
446.85

392.12
363.98
341.25
[17, 160, 17, 970) enable all & disable SHAMIR TRICK 1000

178.34

179.16
Time (ms)

92.06
[17, 970, 19, 308)

58.15
enable all & disable BARRETT

56.02

49.01
45.63

46.06
42.68

29.13
100

28.01

24.26

24.51
22.82

22.39
22.29
21.34

15.10
14.49

12.89
[19, 308, +)

11.80
enable all

11.15

11.20
10.74

5.64

5.65
10

Table 2. Configuration based on Free ROM for MICAz 1


init sign verify init encrypt decrypt init key establish
(ECDSA) (ECDSA) (ECDSA) (ECIES) (ECIES) (ECIES) (ECDH) (ECDH)

Available RAM (byte) How to Conf. TinyECCs Switches


[152, 786) disable all
Figure 3. Execution time of ECDSA, ECIES, and
[786, 878) enable SHAMIR TRICK
[878, 1, 418) enable all & disable SLIDING WIN
ECDH w/ all optimization switches enabled
[1, 418, 1, 510) enable all & disable BARRETT tion switches are enabled. Figure 3 shows the execution
[1, 510, +) enable all time required by ECDSA initialization, signature genera-
tion, signature verification; ECIES initialization, encryp-
Table 3. Configuration based on Free RAM for MICAz tion, decryption; ECDH initialization, key establishment.
From figure 3, we can see that enabling all optimiza-
execution time can be ordered as follows: PROJECTIVE tion switches requires long pre-computation. For exam-
> CURVE OPT > HYBRID MULT > HYBRID SQR > ple, it takes MICAz 3,493, 1,839 and 1,839 ms to do pre-
SLIDING WIN > SHAMIR TRICK > BARRETT. In terms computation for ECDSA, ECIES and ECDH, respectively.
of RAM size, the optimization switches can be ordered as Most of the pre-computation time is for the sliding win-
follows: SLIDING WIN > SHAMIR TRICK > BARRETT dow method and Shamirs trick (ECDSA only). Tmote Sky
> HYBRID MULT = HYBRID SQR = CURVE OPT = runs slightly faster than MICAz. Running at 13 MHz, the
PROJECTIVE. default CPU frequency for Imote2, Imote2 is faster than
In terms of ROM size, the optimization switches are or- Tmote Sky in all operations. If we set the frequency to
dered differently for different platforms. For MICAz, PRO- 416 MHz, it only takes 12 and 14 ms to generate ECDSA
JECTIVE > BARRETT HYBRID SQR > CURVE OPT signature and verify it. Moreover, it can perform ECIES
SHAMIR TRICK HYBRID MULT > SLIDING WIN. encryption in 24 ms and decrypt in 15 ms. Finally, ECDH
For TelosB/Tmote Sky, PROJECTIVE > BARRETT key establishment only takes 13 ms.
SHAMIR TRICK > CURVE OPT SLIDING WIN > Enabling all optimization switches requires the largest
HYBRID SQR > HYBRID MULT. For Imote2, PROJEC- ROM and RAM consumptions. Figure 4 shows the ROM
TIVE > BARRETT > SHAMIR TRICK CURVE OPT > and RAM requirements by all schemes. Imote2 has the
SLIDING WIN > HYBRID SQR > HYBRID MULT. largest RAM size due to its word size. MICAz has the
smallest RAM size due to its 8-bit word size, but it has the
Configuration Guideline: To summarize and assist
largest ROM size because it has additional assembly code
users of TinyECC, in Tables 2 and 3, we show how to
for minimizing memory operation when CURVE OPT op-
choose optimization switches on MICAz motes when the
tion is enabled.
amount of available ROM and RAM for TinyECC can be
Now consider the energy consumption of ECDSA,
estimated. TinyECC requires at least 10,180 bytes ROM
ECIES and ECDH on the testing platforms. We estimate
and 152 bytes RAM to be used on MICAz. As more ROM
energy consumption using W = U I t, where U is the
and RAM are available, we can gradually enable the opti-
voltage, I is the current draw in active mode with radio off,
mization switches as indicated in these tables to get better
and t is the execution time. We took the voltage and cur-
performance. For example, having a ROM size between
rent draw (with radio off) from the data sheet of each sensor
11,398 bytes and 17,160 bytes allows us to enable both
platform [1, 2, 4, 6], and used the execution time obtained
SLIDING WIN and PROJECTIVE switches (but not oth-
in our experiments. Specifically, we chose U as 3v for MI-
ers). Note that an optimization can be enabled if both ROM
CAz and TelosB/Tmote Sky. The current draw for MICAz
and RAM sizes allow it. Optimization switches can be de-
and TelosB/Tmote Sky was 8 mA and 1.8 mA, respectively.
termined for other platforms similarly.
For Imote2, U is 0.95v for 13 MHz and 104 MHz [1]. The
6.2.2. Most Computationally Efficient Configuration Imote2 data sheet [1] does not give the current draw when
Now consider the most computationally efficient con- the node runs at 104 MHz with radio off. To be conserva-
figuration. Apparently, TinyECC provides the most com- tive, we use the current draw with radio on in our compu-
putationally efficient configuration when all the optimiza- tation. That is, we chose 31 mA and 66 mA for Imote2 at

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

61800.34

61401.83
42886.27

42558.09

31872.28

31208.21
30723.00
1000000

21284.39

21415.06

21151.53
20,768
25,000

19,308

5560.35

5514.29
100000

2785.11

2811.87

2718.31
17,728
16,352

16,018
15,658

694.99

689.23
10000
20,000

348.11

347.49

351.45
344.63

339.77
13,520

174.06

174.00

175.73
172.42

169.89
ROM size (byte)

12,852
1000

87.12

88.02

85.05
11,396
15,000

Time (ms)
100

10
10,000
1

0.08

0.08

0.08
0.05
0.05

0.04
0.04
0.04
5,000

0.03
0.1

0.01
0.01
0.00

0.00

0.00
0.00
0.00
0.00
0.00
0.01
0
0.001
ECDSA ECIES ECDH
init sign verify init encrypt decrypt init key establish
(ECDSA) (ECDSA) (ECDSA) (ECIES) (ECIES) (ECIES) (ECDH) (ECDH)

(a) ROM size


MICAz Tmote Sky Imote2 Figure 6. Execution time of ECDSA, ECIES, and
2,500 ECDH w/ all optimization switches disabled
2,064

2,064
1,828

1,816

1,816
1,774

1,774

2,000
1,510

1,504
RAM size (byte)

1,500 Thus it is likely that TinyECC will be loaded on sen-


1,000 sor nodes with other applications. Due to the resource
500
constraint of low-end sensor platforms (e.g., MICAz,
TelosB/Tmote Sky), we may have to reduce ROM and
0
ECDSA ECIES ECDH RAM consumption by disabling some optimizations to re-
serve enough space for the sensing applications.
(b) RAM size For example, when all optimizations are enabled,
ECDSA needs 19,308 bytes ROM and 1,510 bytes RAM
Figure 4. Code size of ECDSA, ECIES, and ECDH w/ on MICAz, as figure 4 shows. Stack overflow may happen
all optimization switches enabled when TinyECC is integrated with other programs such as
TOSBase; the available stack for local variables may not
MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz) be large enough due to the limited RAM (4K bytes) on
93.78

100 MICAz. As another example, Tmote Sky only has 48K


83.84

90
bytes ROM. If ECDSA with all optimizations enabled is
Energy consumption (mJ)

80
63.18
58.48

70
integrated with the SurgeTelos, a popular TinyOS applica-
50.82
48.04

60
44.13

44.13

50
40
tion [5], the total ROM size would be 40,380 bytes, leaving
21.70

little space for other applications.


17.66

30
13.74

13.73
13.16

11.49

11.55
10.72

10.89
10.05

9.48
8.54

20
7.12

7.13
5.77

We can disable all optimizations to show how compact


5.25

5.28
3.65
3.51

3.07
2.86
2.68

1.40

1.40

10
0
init sign verify init encrypt decrypt init key establish
TinyECC could be. Figure 6 shows the execution time of
(ECDSA) (ECDSA) (ECDSA) (ECIES) (ECIES) (ECIES) (ECDH) (ECDH)
ECDSA, ECIES and ECDH when all optimization switches
are disabled. In this case, no pre-computation is needed,
Figure 5. Energy consumption of ECDSA, ECIES, and the initialization time is close to 0. Imote2 running
and ECDH w/ all optimization switches enabled at 416 MHz is still the fastest one, which MICAz is the
slowest one.
The benefit of disabling all optimizations is the compact
13 MHz and 104 MHz. code size. Figure 7 shows the code size of all schemes in
Figure 5 shows the energy consumption required by all TinyECC when all optimization switches are disabled. Due
these operations. Imote2 is the most energy efficient plat- to their word size, Imote2 has the largest RAM size, while
form when it runs at 104 MHz. It needs 2.86 mJ and 3.51 MICAz has the smallest RAM size. The code size has been
mJ to generate ECDSA signature and verify it; it needs reduced greatly.
5.77 mJ and 3.65 mJ to do ECIES encryption and decryp- Since the execution time of TinyECC is much longer,
tion; and it needs 3.07 mJ for the ECDH key agreement the energy consumption of TinyECC is also increased as
operation. MICAz is the most energy consuming platform. figure 8 shows. In our experiments, the energy cost is in-
TelosB/Tmote Sky is quite efficient at energy consumption creased by 6 to 25.4 times. Please refer to the technical
due to its low current draw with radio off. report version of this paper [22] for detailed discussion.
6.2.3. Most Storage-Efficient Configuration 7. Related Work
Many TinyOS applications may use TinyECC for au- A comprehensive guide for elliptic curve cryptography
thentication, encryption/decryption, or key establishment. is given in [16]. Additional documentation on ECC can be

10
MICAz Tmote Sky Imote2 ecution time by hard-coding all the curve parameters into
25,000 assembly code.
20,000 A common limitation of all these efforts is that all
ROM size (byte)

12,442
these attempts were developed as independent pack-

10,904
10,434
10,180
15,000

8,644

8,634
ages/applications without seriously considering the re-
8,172

6,950

6,876
10,000
source demands of sensor network applications. As a re-
5,000
sult, developers may find it difficult, and sometimes im-
0
ECDSA ECIES ECDH
possible, to integrate an ECC implementation with the
sensor network applications (e.g., not enough ROM or
(a) ROM size RAM), though the ECC implementation may be okay on its
MICAz Tmote Sky Imote2
own. In contrast, TinyECC provides a set of optimization
2,500
switches that allow itself to be configured with different re-
source consumptions. This allows TinyECC to be flexibly
2,000
integrated into sensor network applications.
RAM size (byte)

1,500

1,000
8. Conclusion
500
In this paper, we presented the design, implementation,
176

172

172
160

158

158
152

150

150

and evaluation of TinyECC. A unique feature of TinyECC


0
ECDSA ECIES ECDH is its configurability. It provides a number of optimization
switches, which can turn specific optimizations on or off
(b) RAM size based on developers needs. Different combinations of the
optimizations have different execution time and resource
Figure 7. Code size of ECDSA, ECIES, and ECDH w/ consumptions, and thus give the developers flexibility in
all optimization switches disabled integrating TinyECC into sensor network applications. We
also performed a series of experiments to evaluate the per-
MICAz (8 MHz) Tmote Sky (8 MHz) Imote2 (13 MHz) Imote2 (104 MHz)
formance and resource consumptions of TinyECC with
2000
different combinations of enabled optimizations, and pro-
1483.21

1473.64
Energy consumption (mJ)

1600
vided guidelines for configuring TinyECC for sensor net-
1200 work applications.
764.93

749.00
737.35

800 As a final note, we would like to point out that PKC


231.59

229.81

components could become the source of attacks if not prop-


163.75

162.40
114.94

115.64

114.22

400
82.02

82.81

80.05
43.58

43.21
21.83

22.04

21.30
0.00
0.00
0.00
0.00

0.00
0.00
0.00
0.00

0.00
0.00
0.00
0.00

0
erly used. In particular, developers should pay special at-
init
(ECDSA)
sign
(ECDSA)
verify
(ECDSA)
init
(ECIES)
encrypt
(ECIES)
decrypt
(ECIES)
init
(ECDH)
key establish
(ECDH)
tention to Denial of Service (DoS) attacks against PKC.
For example, TinyECC has been used to bootstrap secure
code dissemination in wireless sensor networks [11, 17].
Figure 8. Energy consumption of ECDSA, ECIES, However, if there is no additional protection, an attacker
and ECDH w/ all optimization switches disabled may repeatedly claim that a new code image is available
found in [79]. There have been numerous ECC implemen- and convincing sensor nodes to perform many PKC opera-
tations in various contexts (e.g., Crypto++ [10]). Most of tions, eventually exhausting their battery power. Additional
these implementations are aimed at traditional computing mechanisms such as message specific puzzles [31] is thus
platforms such as PCs. necessary.
Several recent efforts have focused on sensor platforms, Acknowledgment We would like to thank Ben Greenstein
such as the MICA series of motes. Malan et al. imple- for shepherding our paper. Panos Kampanakis ported an
mented ECC over binary extension fields F2m on TinyOS earlier version of TinyECC to Imote2. We are grateful to
for Mica2 [26]. Unfortunately, due to the constraints on the anonymous reviewers for their helpful comments.
the typical micro-controllers used on sensor platforms, it
References
is difficult to obtain efficient ECC implementation over
F2m . Gura et al. implemented and compared ECC and
[1] Imote2: High-performance wireless sensor network
RSA on Atmel ATmega128 in assembly [15]. However, node. http://www.xbow.com/Products/
it is not clear how well their implementation can be inte- Product_pdf_files/Wireless_pdf/Imote2_
grated into sensor network applications. Wang et al. imple- Datasheet.pdf.
mented ECC on specific 160-bit elliptic curves on MICAz [2] MICAz: Wireless measurement system. http:
and TelosB running TinyOS [33]. They obtained fast ex- //www.xbow.com/Products/Product_pdf_

11
files/Wireless_pdf/MICAz_Datasheet.pdf. [20] RSA Laboratories. RSAREF: A cryptographic toolkit (ver-
[3] SSL 3.0 specification. http://wp.netscape.com/ sion 2.0), March 1994.
eng/ssl3/. [21] P.E. Lanigan, R. Gandhi, and P. Narasimhan. Sluice: Se-
[4] TelosB mote platform. http://www.xbow.com/ cure dissemination of code updates in sensor networks. In
Products/Product_pdf_files/Wireless_ Proceedings of the 26th International Conference on Dis-
pdf/TelosB_Datasheet.pdf. tributed Computing Systems (ICDCS 06), July 2006.
[5] TinyOS: An open-source OS for the networked sensor [22] A. Liu and P. Ning. TinyECC: A configurable library for el-
regime. http://www.tinyos.net/. liptic curve cryptography in wireless sensor networks. Tech-
[6] Tmote sky: Reliable low-power wireless sensor network- nical Report TR-2007-36, North Carolina State University,
ing eases development and deployment. http://www. Department of Computer Science, 2007.
moteiv.com/products-tmotesky.php. [23] D. Liu and P. Ning. Establishing pairwise keys in distributed
[7] American Bankers Association. ANSI X9.62-1998: Public sensor networks. In Proceedings of 10th ACM Confer-
Key Cryptography for the Financial Services Industry: the ence on Computer and Communications Security (CCS03),
Elliptic Curve Digital Signature Algorithm (ECDSA), 1999. pages 5261, October 2003.
[8] Certicom Research. Standards for efficient cryp- [24] D. Liu and P. Ning. Multi-level TESLA: Broadcast au-
tography SEC 1: Elliptic curve cryptography. thentication for distributed sensor networks. ACM Transac-
http://www.secg.org/download/aid-385/ tions in Embedded Computing Systems (TECS), 3(4):800
sec1_final.pdf, September 2000. 836, 2004.
[9] Certicom Research. Standards for efficient cryptography [25] D. Liu, P. Ning, S. Zhu, and S. Jajodia. Practical broad-
SEC 2: Recommended elliptic curve domain parame- cast authentication in sensor networks. In Proceedings of
ters. http://www.secg.org/collateral/sec2_ the 2nd Annual International Conference on Mobile and
final.pdf, September 2000. Ubiquitous Systems: Networking and Services (MobiQui-
[10] W. Dai. Crypto++ library 5.5. http://www. tous 2005), July 2005.
cryptopp.com/, May 2007. [26] D. Malan, M. Welsh, and M. Smith. A public-key infras-
[11] J. Deng, R. Han, and S. Mishra. Secure code distribution tructure for key distribution in tinyos based on elliptic curve
in dynamically programmable wireless sensor networks. In cryptography. In Proceedings of IEEE Conference on Sen-
Proceedings of the Fifth International Conference on Infor- sor and Ad Hoc Communications and Networks (SECON),
mation Processing in Sensor Networks (IPSN 06), April pages 7180, 2004.
2006. [27] K. Malasri and L. Wang. Addressing security in medical
[12] W. Diffie and M.E. Hellman. New directions in cryptogra- sensor networks. In HealthNet 07: Proceedings of the 1st
phy. IEEE Transactions on Information Theory, IT-22:644 ACM SIGMOBILE international workshop on Systems and
654, November 1976. networking support for healthcare and assisted living envi-
[13] L. Eschenauer and V. D. Gligor. A key-management scheme ronments, pages 712, 2007.
for distributed sensor networks. In Proceedings of the 9th [28] A.J. Menezes, P. C. van Oorschot, and S.A. Vanstone. Hand-
ACM Conference on Computer and Communications Secu- book of Applied Cryptography. CRC Press, 1996. ISBN:
rity, pages 4147, November 2002. 0-8493-8523-7.
[14] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and [29] National Institute of Standards and Technology. Federal in-
D. Culler. The nesC language: A holistic approach to net- formation processing standard 186: Digital signature stan-
worked embedded systems. In Proceedings of Program- dard. http://csrc.nist.gov/publications/,
ming Language Design and Implementation (PLDI 03), 1993.
June 2003. [30] National Institute of Standards and Technology. Recom-
[15] N. Gura, A. Patel, and A. Wander. Comparing elliptic curve mended elliptic curves for federal government use, August
cryptography and RSA on 8-bit CPUs. In Proceedings of the 1999.
2004 Workshop on Cryptographic Hardware and Embedded [31] P. Ning, A. Liu, and W. Du. Mitigating DoS attacks against
Systems (CHES 2004), pages 119132, August 2004. broadcast authentication in wireless sensor networks. ACM
[16] D. Hankerson, A. Menezes, and S. Vanstone. Guide to El- Transactions on Sensor Networks, 4(1), February 2008.
liptic Curve Cryptography. Springer, 2004. [32] A. Perrig, R. Canetti, D. Song, and D. Tygar. Efficient
[17] S. Hyun, P. Ning, A. Liu, and W. Du. Seluge: Secure authentication and signing of multicast streams over lossy
and dos-resistant code dissemination in wireless sensor net- channels. In Proceedings of the 2000 IEEE Symposium on
works. In Proceedings of the Seventh International Confer- Security and Privacy, May 2000.
ence on Information Processing in Sensor Networks (IPSN [33] H. Wang and Q. Li. Efficient implementation of public key
08), April 2008. cryptosystems on mote sensors. In Proceedings of Interna-
[18] S. Kent and R. Atkinson. IP authentication header. IETF tional Conference on Information and Communication Se-
RFC 2402, November 1998. curity (ICICS), pages 519528, Dec. 2006.
[19] D.E. Knuth. The Art of Computer Programming, volume 2:
Seminumerical Algorithms. Addison-Wesley, third edition,
1997. ISBN: 0-201-89684-2.

12