Beruflich Dokumente
Kultur Dokumente
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
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
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
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
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
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
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)
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
HYBRID SQR and CURVE OPT cannot speed up ECDSA MICAz Tmote Sky Imote2
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)
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
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)
2,064
1,828
1,816
1,816
1,774
1,774
2,000
1,510
1,504
RAM size (byte)
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
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
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
1473.64
Energy consumption (mJ)
1600
vided guidelines for configuring TinyECC for sensor net-
1200 work applications.
764.93
749.00
737.35
229.81
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