00 positive Bewertungen00 negative Bewertungen

3 Ansichten12 SeitenAug 02, 2017

© © All Rights Reserved

PDF, TXT oder online auf Scribd lesen

© All Rights Reserved

Als PDF, TXT **herunterladen** oder online auf Scribd lesen

3 Ansichten

00 positive Bewertungen00 negative Bewertungen

© All Rights Reserved

Als PDF, TXT **herunterladen** oder online auf Scribd lesen

Sie sind auf Seite 1von 12

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

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

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

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)

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

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

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

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

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)

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

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

(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)

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

init sign verify init encrypt decrypt init key establish

(ECDSA) (ECDSA) (ECDSA) (ECIES) (ECIES) (ECIES) (ECDH) (ECDH)

[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)

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,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

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

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

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

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

231.59

229.81

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

## Viel mehr als nur Dokumente.

Entdecken, was Scribd alles zu bieten hat, inklusive Bücher und Hörbücher von großen Verlagen.

Jederzeit kündbar.