Towards quantifying the cost of a secure IoT:

Overhead and energy consumption of ECC

signatures on an ARM-based device

Max Mössinger∗ , Benedikt Petschkuhn∗ , Johannes Bauer∗ ,

Ralf C. Staudemeyer∗ , Marcin Wójcik† , and Henrich C. Pöhls∗
∗ Institute of IT-Security and Security Law (ISL), University of Passau, Innstr. 43, 94032 Passau, Germany
† Computer Laboratory, University of Cambridge, 15 JJ Thomson Avenue, Cambridge CB3 0FD, UK
Emails: ∗ hp|[email protected] † [email protected]

Abstract—In this paper, we document the overhead in terms of curves have been standardized [6], like Curve25519 proposed
runtime, firmware size, communication and energy consumption by Bernstein. Based on Curve25519 a signature algorithm
for Elliptic Curve Cryptography (ECC) signatures of modern named Ed25519 is currently en route to standardization [7].
ARM-based constrained devices. The experiments we have under-
taken show that the cryptographic capabilities of the investigated The question we strive to answer here is: What is the real
Zolertia Re-Mote based on a TI’s CC2538 chipset running Contiki overhead for ECC signatures on constrained devices?1
OS is indeed suitable for the Internet-of-Things (IoT): Computing
a signature using a curve with a 192-bit key length adds an Many implementations of ECC exist, which are well-suited
additional runtime of roughly 200 ms. However, we found that for Wireless Sensor Networks (WSN), like TinyECC [8],
in comparison to sending an unsigned message approximately NanoECC [9], or NIST’s ECClight [10]. ECC on constrained
two-thirds of the runtime overhead is spent on cryptographic devices has been further evaluated and optimised in [11]. That
operations, while sending the signed message accounts for the ECC can be very efficient, such as the curve with 160-bit key
remainder. length implementation, is shown by Kern and Feldhofer [12].
We give real measurements which can be used as a basis A very lightweight ECC-based construction for authentication
for analytical models. Our measurements show that the saving to run on RFID-type devices was presented by Braun, Hess
gained by using curves with lower security levels (i. e., 160-bit key and Mayer [13]. However, hardware has evolved and many
length) is not worth the sacrifice in protection. While signatures of the IoT devices already use ARM-based System on Chip
add non-negligible overhead, we still think that the additional (SoC) [14]2 .
200 ms (signing with secp192r) is worth consideration. This
paper gives an indication of the true costs of cryptographically In our experiments, we evaluate the overhead in terms of
protected message integrity which is greater or equal to the cost runtime, code footprint, energy consumption, and communica-
of encryption. We show what needs to be spent in order to verify tion of signing and verifying a message’s payload with ECC
the origin of the data in the application, since in the IoT it will signatures. We start by giving some background information
have travelled through many ‘things’. about the cryptography, the hardware and the tested libraries
in Section II. In Section III we explain the experimental setup.
I. I NTRODUCTION The evaluation of runtime overhead and code footprint is given
in Section IV, and for energy consumption in Section V.
Deploying cryptographically strong security on constrained Finally, we look at the overhead of a Constrained Applica-
devices used as the underlying platforms in the Internet of tion Protocol (CoAP) communication of a signed message in
Things (IoT) was a long outstanding quest. Still—according Section VI, before we conclude in Section VII.
to a report from HP in 2015—this critical protection of last
mile communication remains an open issue [1]. The tools that
can make the significant impact on this issue are evolving II. BACKGROUND
constantly: Elliptic Curve Cryptography (ECC) is known to We investigate the overhead of a cryptographic operation
be more resource efficient and is currently seeing an update of called digital signature. Signatures protect the integrity of
standards that include new designs. These will aid in security, messages and allow to verify their origin. In the following,
as well as in interoperability. we evaluate several related cryptographic libraries.
Initially, ECC was presented independently by Miller [2]
and Koblitz [3] in 1986. More recently, ECC has become the A. ECC signatures
standard tool for strong cryptographic algorithms in the IoT Integrity is the “property that data has not been altered or
device context. Widely known is the NIST standard containing destroyed in an unauthorised manner” [15]. While integrity
the Elliptic Curve Digital Signature Algorithm (Elliptic Curve
1 based
Digital Signature Algorithm (ECDSA)) [4]. After recent criti- on research in the EU FP7 project RERUM (ict-rerum.eu)
2 We imply ECC remains hardware supported, as in TI’s CC2538 chipset.
cism of ECC parameters being selected in a non-deterministic
fashion, thus less trusted and potentially insecure [5], new Recently ECC support has been dropped, but we presume the co-processor
can be micro-coded to speed up new standardized curves (see: blog.spd.gr/
978-1-5090-2185-7/16/$31.00 2016
c IEEE 2015/04/to-cc-or-not-to-cc.html).
can be achieved on transport- and message-level, we focus the library for both 16-bit and 32-bit platforms. In addition,
on message-level integrity, since it creates an integrity check to perform a more efficient point doubling computation the
value over the actual message. This value can be verified even library supports a sliding window size technique.
after the message was sent over an unsecured communication
channel or stored at a non-trusted system to guarantee integrity. 3) MicroECC library: Similarly to Piñol, the MicroECC li-
This is suitable to the IoT as information from sensors is brary implements five standard NIST curves [4]: secp160r1,
gathered by constrained devices and either forwarded to other secp192r1, secp224r1, secp256k1, and secp256r1
devices or stored in message queues to be picked up by which can be used for ECDSA. The library is implemented in
applications [16]. C, but to increase performance, it can be adjusted to use the
inline assembly feature for our target ARM architecture. The
To generate ECC-based signatures two distinct keys are MicroECC library can optionally be optimised for either speed
required, likewise to all asymmetric based digital signature or code size and, similar to TweetNaCl, features a protection
schemes. One is called private key used to generate signatures, against cache-timing attacks.
the other one is called public key used to verify signatures. The
secret key must be generated, stored, and used, in such a way
III. E XPERIMENTS
that confidentiality is not violated at any time. In addition,
the ECC-based signature algorithm usually involves a hash We use the Zolertia Re-Mote [14] development board as the
function (e. g., SHA-256 [17], or better). underlying platform, which houses the CC2538 chipset—a re-
cent SoC design by Texas Instruments. The device contains an
In order to use signatures in practice, a key pair per
ARM Cortex-M3 as core processor, on-chip memory modules,
device is required. In contrast to symmetric-key cryptography
an IEEE 802.15.4-compliant radio transceiver module, and a
this increases the security, as an extracted key empowers an
co-processor capable of performing cryptographic operations.
attacker to only impersonate that single device. For the tests
The Re-Mote is well-suited to run Contiki [24], an modern
conducted in our experiments, we did not address the key
operating system specifically designed to support a wide-range
distribution problem.
of constrained devices. All our experiments run as applications
on top of Contiki.
B. Cryptographic libraries
For the cryptography-only measurements, we disabled the
From the existing sets of cryptographic libraries, we se- network stack in order to eliminate unnecessary interrupts,
lected those, which were suitable without significant underly- additional energy consumption, and all other side effects, that
ing changes for both: (i) running under Contiki and (ii) run- might be imposed by the integrated radio module and related
ning on the ARM Cortex-M3 core. The following libraries software code.
were short-listed as candidates for further investigation on
our Re-Mote platform: TweetNaCl [18], Piñol [19] and Mi-
croECC [20]. In order to run the libraries on the Re-Mote A. Code footprint tests setup
we ported them to Contiki and adjusted the code whenever To investigate the code footprint of the target primitives
necessary [21]. and schemes, we used a standard gcc-arm toolchain available
A better diversification of results was a main intent of for CC2538 devices. Static code size values can be obtained
our selection process. Thus, we focused on selecting libraries from the Executable and Linkable Format (ELF) file, by using
that support a greater variety of features and standards, i. e., aforementioned toolchain. The ELF file represents a compiled
MicroECC implements curves across different security levels, and already linked executable and can be uploaded into the
whereas Piñol focuses on one security level but different flash memory of the Re-Mote device.
coordinates. While this approach makes a direct comparison The static code size of the target function was obtained as
more challenging, the results give a better understanding of follows: (i) we measured a static code size of the whole project,
the actual ECC signature overhead on ARM-based constrained (ii) all code dependencies to our target library were removed,
devices, being the objective of this paper. and (iii) the resulting elf file was stripped and the code size
1) TweetNaCl library: TweetNaCl [18] is a compact im- measured. Finally, (iv) we compared the measured size to the
plementation of the NaCl [22] library. It only contains a C original project size, therefore obtaining the requested code
source file with its corresponding header file. The library is footprint.
generic, but some of the design choices are suited to 32-bit
architectures. In addition, the library does not perform any B. Runtime tests setup
dynamic memory allocation and provides protection against
cache-timing attacks. Although TweetNaCl includes all cryp- For measuring timings under Contiki, we developed our
tographic primitives of the original NaCl library, we selected own tool called timelib, due to the lack of any suitable library.
only the Ed25519 [23] primitive for signature evaluation. timelib consists of multiple useful functions to automate the
measurement process and to provide standardised output, well
2) Piñol library: the Piñol [19] library implements the suitable as an input to other tools. Our tool supports two
secp256r1 standardized NIST curve [4] using three different modes: timing and power-trace. In timing mode, timelib prints
coordinate representations: affine, homogeneous and jacobian. the values of the internal Re-Mote timer for each measured task
The library is generic, although it features several optimisation to standard output. Alternatively, in power-trace mode timelib
techniques and design choices, i. e., it allows a different word triggers power measurement periods by activating/inactivating
size for a point representation and thus one can easily configure an external pin.
 For runtime measurements, we used the internal real-time
clock of the CC2538 chip, which runs at 32.768 kHz [25].
We observed each cryptographic operation over a period of
10 minutes, performing the measurements multiple times. The
timelib tool analyses the output, aggregates the measured time
of each task and computes the average over several iterations.

C. Energy consumption tests setup

We did tap the power supply lines going via USB to the Re-
Mote device. To perform the power measurements an analog-
digital-converter (AD-converter) of type MCP3008 [26] was
used. The said converter is triggered by a Raspberry Pi over
the Serial Peripheral Interface (SPI) and results are read back.
Each measurement contains time-stamp and measured value.
The python scripts and wiring diagrams, are based on the

Power[mW]
work of Erik Bartmann [27]. The MCP3008 is supplied by
3.25V and has a resolution of 1024 bits, these parameters limit
the maximal resolution to 3.17mV/bit [26]. The AD converter
works within the range of 2.5 ms to 10 ms per measurement.
To be safe, we assume the worst resolution and set the shortest
measurable task cycle to 10 ms.
To automate the process of analysing these traces, we
developed another tool called powertracer-tool. The tool gen-
erates two kinds of traces: a time trace and a power trace.
The time trace consists of the task names and their dura-
tion, whereas the power trace consists of the voltage on the
measurement points and the marker positions of the glowing
LED marker points. The measurement process starts by the
generation of a timing trace, which is next saved as a log file.
Furthermore the Raspberry Pi generates the power data, which
is then analysed together with the timing trace. In the end
the powertracer-tool syncs the information from the timing of Time[ms]
each selected task with the power trace and thus gives energy
Fig. 1. Power trace output for first 150 ms of the test’s duration
statistics for each given task. The output of a power trace is
partially shown in Figure 1.
To achieve the aforementioned synchronisation, task tests to 15 bytes. Since our selected cryptographic primitives
start/stop checkpoints are marked by activating the LEDs heavily use the memory stack, we increased the stack size from
and its higher—clearly observable—power drain is used as a Contiki’s default value for the CC2538 chipset of 2048 bytes
marker. Consequently, the energy consumption for each power to 4096 bytes.
measuring point within this interval is calculated. The interval
does not contain the power measuring point for the marker. TweetNaCl: Although the source code does not target Contiki,
The energy consumption is calculated in mJ. Please note that the code integration was straightforward; with little need for
the limitation of the used hardware gives a minimum timing adjustments. Our investigated implementation of Ed25519 uses
interval of 10 ms. Afterwards the sum of all measuring points an internal SHA-512 hash function.
between the two markers will be used to calculate the total Piñol: The library was originally designed for Contiki, thus
consumption of a given task. In a test run each task is executed no source code tweaks were required. Similarly to TweetNaCl
several times. The measurements stated in this paper’s tables the implementation includes a hash function, but this time the
are the average value of several runs. SHA-256 version. We investigated all three different coordi-
nate systems provided by the author and two 16-bit and 32-
D. Cryptographic libraries adjustments bit word size options. For brevity we only present the 32-bit
results, since this is the target architecture on the Re-Mote.
No optimisation for the processor, Contiki, or otherwise
was done to the libraries. In order to achieve consistent and MicroECC: Here the original library is not perfectly suited to
reproducible measurements, we crippled security and all calls run under Contiki, thus we performed a few minor tweaks. Our
to Pseudo-Random Number Generator (PRNG) are replaced investigated library version excludes a hashing step, therefore,
with a function generating a fixed output. For all curves, the we applied SHA-256 to be consistent across libraries. For
used hash function is included into the measurement. We have each of the curves there are three possible configurations,
timed the hash function explicitly for each task and found that use different inline assembly code optimisations: no inline
the overhead to be minimal, i.e. in the region of a few ms. assembler code, inline assembler code optimised for compact
Note that we fixed the length of the message to sign in our size, and inline assembler code optimised for fast execution.
 TABLE II. P I ÑOL TIMING AND CODE FOOTPRINT RESULTS
IV. P ERFORMANCE AND C ODE F OOTPRINT E VALUATION
Configuration KeyGen [s] Sign [s] Verify [s] Code Size [bytes]
In this section, we state and compare the results of time and
secp256r1 af 32 26.644 26.420 52.977 6915
code footprint measurements for the implementations of our
secp256r1 af 32sw 26.712 26.503 52.832 6915
TweetNaCl, Piñol and MicroECC target libraries. This includes
secp256r1 hm 32 10.829 10.820 21.449 8153
all possible configuration options supported.
secp256r1 hm 32sw 10.842 10.858 21.798 8153
TweetNaCl: Table I shows the timing and the code footprint secp256r1 jb 32 6.425 6.439 13.075 8317
results of the TweetNaCl library. TweetNaCl accomplished the secp256r1 jb 32sw 6.521 6.588 13.175 8317
key generation in 3.518 s, signature generation in 3.532 s, and
verification in 7.047 s. TABLE III. M ICRO ECC TIMING AND CODE FOOTPRINT RESULTS

Configuration KeyGen [s] Sign [s] Verify [s] Code Size [bytes]
Piñol: Table II shows the timing and the code footprint results
of the Piñol library. We measured all 12 possible configurations secp160r1 fast 0.177 0.211 0.225 5301
supported by the library, i. e., 16-bit and 32-bit options with secp160r1 std 0.318 0.356 0.386 4679
affine (af), homogeneous (hm) and Jacobian (jb) coordinates. secp160r1 small 0.260 0.296 0.320 4522
secp192r1 fast 0.181 0.206 0.224 5225
For the purpose of the paper, we included only results for 32-
secp192r1 std 0.409 0.437 0.485 4223
bit option. We successfully replicated timing and code footprint
secp192r1 small 0.305 0.333 0.368 4042
results documented in [19].
secp224r1 fast 0.262 0.297 0.324 5825
As shown in Table II, the best performing configuration is secp224r1 std 0.593 0.630 0.700 4311
with the Jacobian coordinate system without sliding window secp224r1 small 0.438 0.475 0.525 4130
and optimised for 32-bit operations. However, in all variants secp256k1 fast 0.420 0.467 0.476 6301
the timing differences in the configuration with and without secp256k1 std 0.925 0.972 1.010 4227
sliding window are either negligible or slightly (within the secp256k1 small 0.665 0.714 0.737 4050
range of 100 ms on average) in disfavour of the latter. secp256r1 fast 0.489 0.537 0.595 6605
secp256r1 std 1.129 1.177 1.320 4531
As shown in Table II, the smallest code size is accom- secp256r1 small 0.805 0.855 0.957 4354
plished by using the affine coordinates optimised for 32-
bit architecture. In this case the compactness is achieved at
the expense of speed. In addition, there is no difference in V. P OWER CONSUMPTION EVALUATION
the static code size of the implementations between versions
with and without a sliding window. The largest static code Now we shift our focus to the evaluation of the energy
footprint results from the implementation that achieved the best efficiency. In this section, we present the energy consumption
performance results. The difference between the smallest and results of all investigated signature schemes. Similarly to
the largest code size is in the range of 1418 bytes. timing and code size results, we perform our tests using all
possible configurations available in the libraries. All values
MircoECC: Table III shows the timing and the code footprint are expressed in joule.
results of the MicroECC library. We measured all possible
configurations, i. e., all five curves with all possible speed 1) TweetNaCl: Table IV shows the measured energy con-
versus code size optimisation (fast, standard, small). The sumption results of the TweetNaCl library, i. e., the signature
optimisations are possible through inline assembly insertion scheme Ed25519. As it can be seen, energy consumption of
in critical parts of the code. Verify is much higher than KeyGen and Sign. This is
expected since the execution time of Verify is longer.
Since MicroECC includes elliptic curves on different se-
curity levels, a direct comparison is misleading. Instead, we TABLE IV. T WEET NAC L ENERGY CONSUMPTION RESULTS
noticed differences between a generic implementation and a Configuration KeyGen [J] Sign [J] Verify [J]
platform-dependent assembler-optimised version. For example, Ed25519 small 0.332 0.333 0.665
secp256r1 without any inline assembler optimisations runs
in 1.129 s, while the platform-dependent fast version took only 2) Piñol: The measured power consumption results of the
0.489 s on average. This is a notable advantage of 0.640 s, Piñol library are given in Table V. It is not surprising, that
which is around 2.3 times faster. the energy consumption of a particular primitive is strongly
As shown in Table III, the general difference of the code related to its execution time, similarly to TweetNaCl.
size between a curve with a short key size and one with a larger
TABLE V. P I ÑOL ENERGY CONSUMPTION RESULTS
key size is considerably small. There is only a difference of
168 bytes between the curve with the lowest security level Configuration KeyGen [J] Sign [J] Verify [J]
(secp160r1) and the highest security level secp256r1. In secp256r1 af 32 2.712 2.709 5.494
addition, savings in terms of code size between the versions secp256r1 af 32sw 2.569 2.542 5.073
optimised in this regard compared to those without are of secp256r1 hm 32 1.050 1.048 2.112
around 200 bytes. secp256r1 hm 32sw 1.045 1.032 2.094
secp256r1 jb 32 0.632 0.638 1.276
TABLE I. T WEET NAC L TIMING AND CODE FOOTPRINT RESULTS secp256r1 jb 32sw 0.625 0.623 1.248
Configuration KeyGen [s] Sign [s] Verify [s] Code Size [bytes]
Ed25519 small 3.518 3.532 7.047 6776 3) MicroECC: In Table VI we present the results of the
measured energy consumption for the MicroECC library. Sim-
 TABLE VI. M ICRO ECC ENERGY CONSUMPTION RESULTS
Before the message was signed, it was hashed with the
Configuration KeyGen [J] Sign [J] Verify [J] built-in, hardware-accelerated SHA-256 function of the Re-
secp160r1 fast 0.016 0.020 0.021 Mote’s CC2538 chip. Afterwards the generated signature was
secp160r1 none 0.030 0.033 0.036 encoded in BASE64URL and put into the JSS message.
secp160r1 small 0.024 0.027 0.030 The runtime overhead of the signing process was determined
secp192r1 fast 0.016 0.019 0.020 by using the integrated timer of the CC2538 chip. These
secp192r1 none 0.037 0.040 0.044 measurements were performed multiple times for each step
secp192r1 none 0.028 0.031 0.034 of the signing process. It turned out that the SHA-256 hashing
secp224r1 fast 0.024 0.027 0.029 and the BASE64URL encoding had a negligible affect on the
secp224r1 none 0.055 0.058 0.065 runtime: The total duration of hashing and encoding was less
secp224r1 small 0.041 0.044 0.049 than 1 ms. The average runtime was 218 ms for generating a
secp256k1 fast 0.038 0.042 0.043 signature using the secp192r1 curve implementation from
secp256k1 none 0.085 0.089 0.093
MicroECC (as shown in Table VII).
secp256k1 small 0.064 0.069 0.071
secp256r1 fast 0.044 0.048 0.054 TABLE VII. TIMING AND CODE FOOTPRINT OVERHEAD FOR
secp256r1 none 0.105 0.109 0.123 SENDING JSS MESSAGES WITH SECP192 R AND MICROECC
secp256r1 small 0.075 0.080 0.089
JSS Signing Total Overhead Code Overhead
[ms] Transm. [ms] Transm. [%] Size [kb] Code [%]
disabled - 92 - 79.58 -
ilarly to TweetNaCl and Piñol the results are strongly related
enabled 218 361 292 85.47 7.4
to execution times.
The code size overhead results for ECC-based signatures
VI. C OMMUNICATION OF SIGNED JSON MESSAGES on the Re-Mote using the MicroECC library, the BASE64URL
Finally, we measure a full interaction by involving a Re- encoding algorithm, and additional variables like the signing
Mote platform, which was able to answer to CoAP requests buffer are shown in Table VII.
with signed messages. To generate ECC-based signatures we To measure the code footprint the previously described
selected the secp192r1 curve and the MicroECC library. We setup was used. A verification with the gcc-arm-none-eabi-
ran the CoAP stack that can be configured within Contiki. objdump tool confirmed that the MicroECC and BASE64URL
For the messages exchanged using CoAP we selected the libraries were not linked into the firmware image when mea-
JSON Signature Scheme (JSS) [16]. The JSS header contains suring the code footprint of the image with disabled signatures.
meta-information about the signature algorithm embedded in Comparing the sizes of both images showed a total code size
a JavaScript Object Notation (JSON) message as a dedicated overhead of 5.89 kb.
element jss.protected. The signature value itself gets Finally, we compared the timing overhead for requesting
encoded in BASE64URL 3 and embedded as the element a signed JSS message and an unsigned JSON message. The
jss.signature. In contrary to JSON Web Signatures request for an unsigned JSON message was answered by
(JWS) [28], only the signature gets encoded in BASE64URL the application with one COAP message, whereas the same
and the payload is untouched. message as signed JSS was transmitted in three COAP blocks.
One sample JSON Sensor Signatures (JSS) message— The timing overhead for transmitting messages is also shown
containing a temperature value of a sensor and a measure- in Table VII. Note that the application doesn’t answer each
ment ID as payload—sent by our application is depicted in request with a new signature: reading the current sensor value
Figure 2. The length of this message is 154 characters, but and signing it is done once in an interval of 30 seconds and
can vary, depending on the size of the measurement ID. The then stored to an internal buffer. Consequently, the overhead
signature algorithm identifier ES192 shows that we were for transmitting a JSS message is almost 300% compared to
using secp192r1 in combination with SHA256. The same an unsigned JSON message due to the increased size of COAP
message without integrity protection, i. e., no signature (it does messages (blocks).
only contain the red marked area in Figure 2) results in a
length of 39 characters. Hence, the overhead of sending a JSS VII. C ONCLUSION AND FUTURE WORK
message is 115 characters (bytes) or 195%. In this paper, we document the overhead in terms of
runtime, firmware size, communication, and energy consump-
{ tion for ECC signatures. The experiments undertaken show
"jss.protected": {
"alg":"ES192"
that the cryptographic capabilities of modern ARM-based
}, constrained devices (Zolertia Re-Mote based on TI’s CC2538)
"chip_temp":20953, running a modern OS (Contiki OS) are suitable for a more
"measurement_id":34,
"jss.signature":"fgj•••lR0JMj" secure Internet-of-Things (IoT): Computing a signature using
} a curve with a 192-bit key length adds an additional runtime
of roughly 200 ms. However, in comparison to sending an
Fig. 2. Sample JSS message (above • • • indicates removed characters;
unsigned message, which would fit in one COAP message, we
spaces were added for better readability) find that roughly two-third of the runtime overhead is spent
on cryptographic operations, and one third is spent on sending
3 Base64 Encoding with URL and Filename Safe Alphabet (RFC4648) the signed message. For the implementation done by Piñol,
which also targets Contiki, we replicated the results on timing [8] A. Liu and P. Ning, “TinyECC: a configurable library for elliptic curve
and extended them by providing real energy consumption cryptography in wireless sensor networks,” in Int. Conf. on Information
measurements complementing the estimations provided in said Processing in Sensor Networks (ipsn 2008), apr 2008, pp. 245–256.
work. Note, that the real measurements we present can be used [9] P. Szczechowiak, L. B. Oliveira, M. Scott, M. Collier, and R. Dahab,
“NanoECC: testing the limits of elliptic curve cryptography in sensor
as a basis for analytical models. networks,” in Wireless Sensor Networks, Berlin, Heidelberg, 2008, pp.
305–320.
Our measurements further reveal that the saving gained
[10] National Institute of Standards and Technology (NIST), “ecc-light-
while using curves with lower security levels (i. e., using a certificate library,” 2014. [Online]. Available: https://github.com/
160-bit key length) is not worth the sacrifice in protection. nist-emntg/ecc-light-certificate
While signatures add a non-negligible overhead, we still think [11] J. Ayuso, L. Marin, A. Jara, and A. F. G. Skarmeta, “Optimization of
that the additional 200 ms (signing with secp192r) is worth Public Key Cryptography (RSA and ECC) for 16-bits Devices based
consideration. This paper gives an indication of the true costs on 6LoWPAN,” in 1st Int. Workshop on the Security of the Internet of
to gain cryptographically protected message integrity. This can Things, Tokyo, Japan, 2010.
be seen as an upper bound to the cost for message encryption [12] T. Kern and M. Feldhofer, “Low-resource ECDSA implementation for
passive RFID tags,” in 17th IEEE Int. Conf. on Electronics, Circuits,
to protect confidentiality. We show what resources need to be and Systems (ICECS’10), 2010, pp. 1236–1239.
spent in order to verify the origin of the data, in the light that
[13] M. Braun, E. Hess, and B. Meyer, “Using elliptic curves on RFID tags,”
in the IoT this data will have travelled through many ‘things’. International Journal of Computer Science and Network Security, vol. 2,
pp. 1–9, 2008.
It is worth noting that some of the cryptographic primitives
[14] Zolertia, “Re-MOTE,” 2015. [Online]. Available: http://zolertia.io/
that we investigated (i. e., NIST ECCs) are suitable for a hard- product/hardware/re-mote
ware acceleration using a cryptographic co-processor available [15] ISO/IEC, “ISO-IEC 7498-2: Information processing systems Open
in some ARM-based chipsets, like TI’s CC2538 System-on- Systems Interconnection Basic Reference Model. Part 2: Security Ar-
Chip. Therefore we expect we expect further improvements in chitecture,” Tech. Rep., 1989.
terms of computational overhead and memory footprint. How- [16] H. C. Pöhls, “JSON Sensor Signatures (JSS): end-to-end integrity
ever, facilitating hardware acceleration is out of the scope of protection from constrained device to IoT application,” in Proc. of the
this paper. Finally, our results hint that it would be worthwhile Workshop on Extending Seamlessly to the Internet of Things (esIoT),
2015, pp. 306–312.
to investigate if the increase in message size for ECC-based
[17] Q. H. Dang, “Secure Hash Standard,” National Institute of Standards
signatures and the induced communication overhead can be and Technology, Gaithersburg, MD, Tech. Rep. August, jul 2015.
reduced by using signatures offering message recovery, e. g.,
[18] D. J. Bernstein, B. van Gastel, W. Janssen, T. Lange, P. Schwabe, and
[29], [30], [31]. S. Smetsers, “TweetNaCl: A Crypto Library in 100 Tweets,” in Progress
in Cryptology–LATINCRYPT 2014, 2015, pp. 64–83.
ACKNOWLEDGMENT [19] O. Piñol Piñol, “Implementation and evaluation of BSD Elliptic
Curve Cryptography,” Master thesis (pre-Bologna period), Universitat
We would like to thank Andrew Moore and George Politècnica de Catalunya, nov 2014.
Oikonomou for their invaluable help during the course of this [20] K. MacKay, “Micro-ecc,” 2016. [Online]. Available: http://kmackay.
work. J. Bauer, B. Petschkuhn, H. C. Pöhls, R. C. Staude- ca/micro-ecc/
meyer, M. Wójcik were supported by the European Unions [21] M. Mössinger, “Measurement of Elliptic Curve Cryptography imple-
mentations for Contiki on a Re-MOTE,” M.Sc. thesis at University of
7th Framework Programme (FP7) under grant agreement no Passau, Germany, 2016.
609094 (RERUM). H. C. Pöhls was also partly supported by [22] D. J. Bernstein, T. Lange, and P. Schwabe, “The security impact of
the European Unions Horizon 2020 Programme under grant a new cryptographic library,” in Progress in Cryptology–LATINCRYPT
agreement no 644962 (PRISMACLOUD). M. Wójcik has also 2012, 2012, pp. 159–176.
partly received funding from the European Union’s Horizon [23] D. J. Bernstein, N. Duif, T. Lange, P. Schwabe, and B.-Y. Yang, “High-
2020 research and innovation programme 2014-2018 under speed high-security signatures,” Journal of Cryptographic Engineering,
grant agreement No. 644866. This paper reflects only the au- vol. 2, no. 2, pp. 77–89, 2012.
thors’ views and the European Commission is not responsible [24] A. Dunkels and E. al., “The Contiki operating system,” 2016. [Online].
Available: http://www.contiki-os.org/
for any use that may be made of the information it contains.
[25] T. Instruments. CC2538 a powerful System-On-Chip for 2.4-
GHz IEEE 802.15.4 and ZigBee applications. [Online]. Available:
R EFERENCES http://www.ti.com/product/cc2538
[26] Microchip Technology Inc., “MCP3004/3008,” p. 40, 2005. [Online].
[1] Hewlett Packard Enterprise, “Internet of Things research study,” Tech. Available: http://www.adafruit.com/datasheets/MCP3008.pdf
Rep. July, nov 2015.
[27] E. Bartmann, “Raspberry Pi - AddOn - Der A/D-Wandler MCP3008
[2] V. Miller, “Use of elliptic curves in cryptography,” in Proc. of Advances v1.3,” adafruit, Tech. Rep., 2012. [Online]. Available: www.
in Cryptology (CRYPTO85). Springer, 1986, pp. 417–426. erik-bartmann.de
[3] N. Koblitz, “Elliptic curve cryptosystems,” Mathematics of Computa- [28] M. Jones, J. Bradley, and N. Sakimura, “IETF draft: JSON Web
tion, vol. 48, no. 177, pp. 203–203, jan 1987. Signatures (JWS),” 2015.
[4] Federal Information Processing Standards Publication, “Digital Signa- [29] R. R. Ramasamy and M. A. Prabakar, “Digital Signature Scheme with
ture Standard (DSS),” Gaithersburg, MD, Tech. Rep., jul 2013. message recovery using Knapsack-based ECC,” IJ Network Security,
[5] D. J. Bernstein, T. Chou, C. Chuengsatiansup, A. Hülsing, E. Lambooij, vol. 12, no. 1, pp. 7–12, 2011.
T. Lange, R. Niederhagen, and C. van Vredendaal, “How to manipulate [30] S.-F. Tzeng and M.-S. Hwang, “Digital signature with message recovery
curve standards: a white paper for the Black Hat,” in IACR Cryptology and its variants based on elliptic curve discrete logarithm problem,”
ePrint Archive, 2015, vol. 2014, pp. 109–139. Computer Standards & Interfaces, vol. 26, no. 2, pp. 61–71, 2004.
[6] A. Langley, M. Hamburg, and S. Turner, “Elliptic curves for security,” [31] Z.-m. Zhao, Y.-g. Wu, and F.-y. Liu, “A signature scheme with message
IRTF RFC 7748, Tech. Rep. 7748, jan 2016. recovery based on elliptic curves,” Computer Engineering & Science,
[7] N. Moeller and S. Josefsson, “IETF Draft: EdDSA and Ed25519,” 2015. vol. 2, p. 2, 2005.