One document matched: draft-aks-crypto-sensors-01.xml
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902"
docName="draft-aks-crypto-sensors-01"
category="info">
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>
<front>
<title abbrev="Smart Object Security Experiences">Practical Considerations and Implementation Experiences in Securing Smart Object Networks</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials="A" surname="Keranen" fullname="Ari Keranen">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<author initials="M" surname="Sethi" fullname="Mohit Sethi">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>mohit.m.sethi@ericsson.com</email>
</address>
</author>
<date month="March" year="2012" />
<keyword>CoAP</keyword>
<keyword>security</keyword>
<abstract>
<t>This memo describes challenges associated with securing smart
object devices in constrained implementations and environments. The
memo describes a possible deployment model suitable for these
environments, discusses the availability of cryptographic libraries
for small devices, presents some experiences in implementing small
devices using those libraries, and discusses trade-offs involving
different types of approaches.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This memo describes challenges associated with securing smart
object devices in constrained implementations and environments (see
<xref target="problem"/>).</t>
<t>Secondly, <xref target="solution"/> discusses a deployment model
that the authors are considering for constrained environments. The
model requires minimal amount of configuration, and we believe it is a
natural fit with the typical communication practices smart object
networking environments.</t>
<t>Thirdly, <xref target="libs"/> discusses the availability of
cryptographic libraries. <xref target="impexp"/> presents some
experiences in implementing small devices using those libraries,
including information about achievable code sizes and speeds on
typical hardware. </t>
<t>Finally, <xref target="trade"/> discusses trade-offs involving different
types of security approaches.</t>
<section title="Related Work">
<t>Constrained Application Protocol (CoAP)
<xref target="I-D.ietf-core-coap"/> is a light-weight protocol
designed to be used in machine-to-machine applications such as smart
energy and building automation. Our discussion uses this protocol as
an example, but the conclusions may apply to other similar
protocols. CoAP base specification <xref target="I-D.ietf-core-coap"/>
outlines how to use DTLS <xref target="RFC5238"/> and IPsec
<xref target="RFC4306"/> for securing the protocol. DTLS can be
applied with group keys, pairwise shared keys, or with certificates.
The security model in all cases is mutual authentication, so while
there is some commonality to HTTP in verifying the server identity, in
practice the models are quite different. The specification says little
about how DTLS keys are managed.
The IPsec mode is described with regards to the protocol
requirements, noting that small implementations of IKEv2 exist
<xref target="I-D.kivinen-ipsecme-ikev2-minimal"/>. However, the
specification is silent on policy and other aspects that are normally
necessary in order to implement interoperable use of IPsec in any
environment <xref target="RFC5406"/>.</t>
<t><xref target="I-D.iab-smart-object-workshop"/> gives an overview of
the security discussions at the March 2011 IAB workshop on smart
objects. The workshop recommended that additional work is needed in
developing suitable credential management mechanisms (perhaps
something similar to the Bluetooth pairing mechanism), understanding
the implementability of standard security mechanisms in small devices
and additional research in the area of lightweight cryptographic
primitives.</t>
<t><xref target="I-D.moskowitz-hip-rg-dex"/> defines a light-weight
version of the HIP protocol for low-power nodes. This version uses a
fixed set of algorithms, Elliptic Curve Cryptography (ECC), and
eliminates hash functions. The protocol still operates based on host
identities, and runs end-to-end between hosts, protecting IP layer
communications. <xref target="RFC6078"/> describes an extension of
HIP that can be used to send upper layer protocol messages without
running the usual HIP base exchange at all.</t>
<t><xref target="I-D.daniel-6lowpan-security-analysis"/> makes a
comprehensive analysis of security issues related to 6LoWPAN networks,
but its findings also apply more generally for all low-powered
networks. Some of the issues this document discusses include the need
to minimize the number of transmitted bits and simplify
implementations, threats in the smart object networking environments,
and the suitability of 6LoWPAN security mechanisms, IPsec, and key
management protocols for implementation in these environments.</t>
<t><xref target="I-D.garcia-core-security"/> discusses the overall
security problem for Internet of Things devices. It also discusses
various solutions, including IKEv2/IPsec <xref target="RFC4306"/>,
TLS/SSL <xref target="RFC5246"/>, DTLS <xref target="RFC5238"/>, HIP
<xref target="RFC5201"/> <xref target="I-D.ietf-hip-rfc5201-bis"/>
<xref target="I-D.moskowitz-hip-rg-dex"/>, PANA
<xref target="RFC5191"/>, and EAP <xref target="RFC3748"/>. The draft
also discusses various operational scenarios, bootstrapping mechanisms,
and challenges associated with implementing security mechanisms in these
environments.</t>
</section>
</section>
<section anchor="problem" title="Challenges">
<t>This section discusses three challenges: implementation
difficulties, practical provisioning problems, and layering and
communication models.</t>
<t>The most often discussed issues in the security for the Internet of
Things relate to implementation difficulties. The desire to build
small, battery-operated, and inexpensive devices drives the creation
of devices with a limited protocol and application suite. Some of the
typical limitations include running CoAP instead of HTTP, limited
support for security mechanisms, limited processing power for long key
lengths, sleep schedule that does not allow communication at all
times, and so on. In addition, the devices typically have very limited
support for configuration, making it hard to set up secrets and trust
anchors.</t>
<t>The implementation difficulties are important, but they should not
be overemphasized. It is important to select the right security
mechanisms and avoid duplicated or unnecessary functionality. But at
the end of the day, if strong cryptographic security is needed, the
implementations have to support that. Also, the use of the most
lightweight algorithms and cryptographic primitives is useful, but
should not be the only consideration in the design. Interoperability
is also important, and often other parts of the system, such as key
management protocols or certificate formats are heavier to implement
than the algorithms themselves.</t>
<t>The second challenge relates to practical provisioning problems. These
are perhaps the most fundamental and difficult issue, and unfortunately
often neglected in the design. There are several problems in the provisioning
and management of smart object networks:
<list style="symbols">
<t>Small devices have no natural user interface for configuration that
would be required for the installation of shared secrets and other
security-related parameters. Typically, there is no keyboard, no
display, and there may not even be buttons to press. Some devices may
only have one interface, the interface to the network.</t>
<t>Manual configuration is rarely, if at all, possible, as the
necessary skills are missing in typical installation environments
(such as in family homes).</t>
<t>There may be a large number of devices. Configuration tasks that
may be acceptable when performed for one device may become
unacceptable with dozens or hundreds of devices.</t>
<t>Network configurations evolve over the lifetime of the devices, as
additional devices are introduced or addresses change. Various central
nodes may also receive more frequent updates than individual devices
such as sensors embedded in building materials.</t>
</list></t>
<t>Finally, layering and communication models present difficulties for
straightforward use of the most obvious security mechanisms. Smart
object networks typically pass information through multiple
participating nodes <xref target="I-D.arkko-core-sleepy-sensors"/> and
end-to-end security for IP or transport layers may not fit such
communication models very well. The primary reasons for needing
middleboxes relates to the need to accommodate for sleeping nodes as
well to enable the implementation of nodes that store or aggregate
information.</t>
</section>
<section anchor="solution" title="Proposed Deployment Model">
<t><xref target="I-D.arkko-core-security-arch"/> recognizes the
provisioning model as the driver of what kind of security architecture
is useful. This section re-introduces this model briefly here in
order to facilitate the discussion of the various design alternatives
later.</t>
<t>The basis of the proposed architecture are self-generated secure identities,
similar to Cryptographically Generated Addresses (CGAs)
<xref target="RFC3972"/> or Host Identity Tags (HITs)
<xref target="RFC5201"/>. That is, we assume the following holds:
<list style="empty">
<t>I = h(P|O)</t>
</list>
where I is the secure identity of the device, h is a hash function, P
is the public key from a key pair generated by the device, and O is
optional other information.</t>
<section anchor="provisioning" title="Provisioning">
<t>As provisioning security credentials, shared secrets, and policy
information is difficult, the provisioning model is based only on the
secure identities. A typical network installation involves physical
placement of a number of devices while noting the identities of these
devices. This list of short identifiers can then be fed to a central
server as a list of authorized devices. Secure communications can then
commence with the devices, at least as far as information from from
the devices to the server is concerned, which is what is needed for
sensor networks. Actuator networks and server-to-device communication
is covered in Section 4.4 of <xref
target="I-D.arkko-core-security-arch"/>.</t>
<t>Where necessary, the information collected at installation time may
also include other parameters relevant to the application, such as the
location or purpose of the devices. This would enable the server to
know, for instance, that a particular device is the temperature sensor
for the kitchen.</t>
<t>Collecting the identity information at installation time can be
arranged in a number of ways. The authors have employed a simple but not
completely secure method where the last few digits of the identity are
printed on a tiny device just a few millimeters across.
Alternatively, the packaging for the device may include the full
identity (typically 32 hex digits), retrieved from the device at
manufacturing time. This identity can be read, for instance, by a bar
code reader carried by the installation personnel. (Note that the
identities are not secret, the security of the system is not dependent
on the identity information leaking to others. The real owner of an
identity can always prove its ownership with the private key which
never leaves the device.) Finally, the device may use its wired
network interface or proximity-based communications, such as
Near-Field Communications (NFC) or Radio-Frequency Identity tags
(RFIDs). Such interfaces allow secure communication of the device
identity to an information gathering device at installation time.</t>
<t>No matter what the method of information collection is, this
provisioning model minimizes the effort required to set up the
security. Each device generates its own identity in a random, secure
key generation process. The identities are self-securing in the sense
that if you know the identity of the peer you want to communicate
with, messages from the peer can be signed by the peer's private key
and it is trivial to verify that the message came from the expected
peer. There is no need to configure an identity and certificate of
that identity separately. There is no need to configure a group secret
or a shared secret. There is no need to configure a trust anchor. In
addition, the identities are typically collected anyway for
application purposes (such as identifying which sensor is in which
room). Under most circumstances there is actually no additional
configuration effort from provisioning security.</t>
<t>Groups of devices can be managed through single identifiers as
well. See Section 4.2 in <xref
target="I-D.arkko-core-security-arch"/> for further information.</t>
</section>
<section anchor="protocolarch" title="Protocol Architecture">
<t>As noted above, the starting point of the architecture is that
nodes self-generate secure identities which are then communicated
out-of-band to the peers that need to know what devices to trust. To
support this model in a protocol architecture, we also need to use
these secure identities to implement secure messaging between the
peers, explain how the system can respond to different types of
attacks such as replay attempts, and decide at what protocol layer and
endpoints the architecture should use.</t>
<t>The deployment itself is suitable for a variety of design choices
regarding layering and protocol mechanisms. <xref
target="I-D.arkko-core-security-arch"/> was mostly focused on
employing end-to-end data object security as opposed to hop-by-hop
security. But other approaches are possible. For instance, HIP in
its opportunistic mode could be used to implement largely the same
functionality at the IP layer. However, it is our belief that the
right layer for this solution is at the application layer. More
specifically, in the data formats transported in the payload part of
CoAP. This approach provides the following benefits:
<list style="symbols">
<t>Ability for intermediaries to act as caches to support different
sleep schedules, without the security model being impacted.</t>
<t>Ability for intermediaries to be built to perform aggregation,
filtering, storage and other actions, again without impacting the
security of the data being transmitted or stored.</t>
<t>Ability to operate in the presence of traditional middleboxes,
such as a protocol translators or even NATs (not that we recommend
their use in these environments).</t>
</list></t>
<t>However, as we will see later there are also some technical
implications, namely that link, network, and transport layer solutions
are more likely to be able to benefit from sessions where the cost of
expensive operations can be amortized over multiple data
transmissions. While this is not impossible in data object security
solutions either, it is not the typical arrangement either.</t>
</section>
</section>
<section anchor="libs" title="Code Availability">
<t> For implementing public key cryptography on resource constrained
environments, we chose Arduino Uno board <xref target="arduino-uno"/>
as the test platform. Arduino Uno has an ATmega328 microcontroller
with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of flash
memory. For selecting potential asymmetric cryptographic
libraries, we did an extensive survey and came up with an initial set
of possible code sources:
<list style="symbols">
<t>AvrCryptolib <xref target="avr-cryptolib"/>: This library provides
a variety of different symmetric key algorithms such as DES/Triple
DES/AES etc. and RSA as an asymmetric key algorithm. We stripped down
the library to use only the required RSA components and used a
separate SHA-256 implementation from the original AvrCrypto-Lib
library <xref target="avr-crypto-lib"/>. Parts of SHA-256 and RSA
algorithm implementations were written in AVR-8 bit assembly language
to reduce the size and optimize the performance. The library also
takes advantage of the fact that Arduino boards allow the programmer
to directly address the flash memory to access constant data which can
save the amount of SRAM used during execution.</t>
<t>Relic-Toolkit <xref target="relic-toolkit"/>: This library is
written entirely in C and provides a highly flexible and customizable
implementation of a large variety of cryptographic algorithms. This
not only includes RSA and ECC, but also pairing based asymmetric
cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures and
many more. The toolkit provides an option to build only the desired
components for the required platform. While building the library, it
is possible to select a variety mathematical optimizations that can be
combined to obtain the desired performance (as a general thumb rule,
faster implementations require more SRAM and flash). It includes a
multi precision integer math module which can be customized to use
different bit-length words.</t>
<t>TinyECC <xref target="tinyecc"/>: TinyECC was designed for using
Elliptic Curve based public key cryptography on sensor networks. It is
written in nesC programming language and as such is designed for
specific use on TinyOS. However, the library can be ported to standard
C99 either with hacked tool-chains or manually rewriting parts of the
code. This allows for the library to be used on platforms that do not
have TinyOS running on them. The library includes a wide variety of
mathematical optimizations such as sliding window, Barrett reduction
for verification, precomputation, etc. It also has one of the smallest
memory footprints among the set of Elliptic Curve libraries surveyed
so far. However, an advantage of Relic over TinyECC is that it can do
curves over binary fields in addition to prime fields. </t>
<t>Wiselib <xref target="wiselib"/>: Wiselib is a generic library written for sensor
networks containing a wide variety of algorithms. While the stable version
contains algorithms for routing only, the test version includes
many more algorithms including algorithms for cryptography, localization
, topology management and many more. The library was designed with the idea
of making it easy to interface the library with operating systems like iSense and
Contiki. However, since the library is written entirely in C++ with a template based
model similar to Boost/CGAL, it can be used on any platform directly without using
any of the operating system interfaces provided. This approach was taken by the authors to test
the code on Arduino Uno. The structure of the code is similar to TinyECC and
like TinyECC it implements elliptic curves over prime fields only. In order to make
the code platform independent, no assembly level optimizations were incorporated. Since
efficiency was not an important goal for the authors of the library while designing,
many well known theoretical performance enhancement features were
also not incorporated. Like the relic-toolkit, Wiselib is also Lesser GPL licensed. </t>
<t>MatrixSSL <xref target="matrix-ssl"/>: This library provides a low
footprint implementation of several cryptographic algorithms including
RSA and ECC (with a commercial license). However, the library in the
original form takes about 50 kB of ROM which is not suitable for our
hardware requirements. Moreover, it is intended for 32-bit systems and
the API includes functions for SSL communication rather than just
signing data with private keys.</t>
</list>
</t>
</section>
<section anchor="impexp" title="Implementation Experiences">
<t>
We have summarized the initial results of RSA private key performance
using AvrCryptolib in <xref target="rsa-performance"/>. All results
are from a single run since repeating the test did not change (or had
only minimal impact on) the results. The keys were generated
separately and were hard coded into the program. All keys were
generated with the value of the public exponent as 3. The performance
of encryption with private key was faster for smaller key lengths as
was expected. However the increase in the execution time was
considerable when the key size was 2048 bits. It is important to note
that two different sets of experiments were performed for each key
length. In the first case, the keys were loaded into the SRAM from the
ROM (flash) before they were used by any of the functions. However, in
the second case, the keys were addressed directly in the ROM. As was
expected, the second case used less SRAM but lead to longer execution
time.
<texttable anchor='rsa-performance'>
<ttcol align='left'>Key length (bits)</ttcol>
<ttcol align='right'>Execution time (ms); key in SRAM</ttcol>
<ttcol align='right'>Memory footprint (bytes); key in SRAM</ttcol>
<ttcol align='right'>Execution time (ms); key in ROM</ttcol>
<ttcol align='right'>Memory footprint (bytes); key in ROM</ttcol>
<c>64</c><c>66</c><c>40</c><c>70</c><c>32</c>
<c>128</c><c>124</c><c>80</c><c>459</c><c>64</c>
<c>512</c><c>25,089</c><c>320</c><c>27,348</c><c>256</c>
<c>1,024</c><c>199,666</c><c>640</c><c>218,367</c><c>512</c>
<c>2,048</c><c>1,587,559</c><c>1,280</c><c>1,740,267</c><c>1,024</c>
<postamble>RSA private key operation performance</postamble>
</texttable>
The code size was less than 3.6 kB for all the test cases with scope
for further reduction. It is also worth noting that the implementation
performs basic exponentiation and multiplication operations without
using any mathematical optimizations such as Montgomery
multiplication, optimized squaring, etc. as described in <xref
target="rsa-high-speed"/>. With more SRAM, we believe that
1024/2048-bit operations can be performed in much less time as has
been shown in <xref target="rsa-8bit"/>. 2048-bit RSA is nonetheless
possible with about 1 kB of SRAM as is seen in <xref
target="rsa-performance"/>. </t>
<t> In <xref target="ecc-performance"/> we present the results obtained by
manually porting TinyECC into C99 standard and
running ECDSA signature algorithm on the Arduino Uno board. TinyECC
supports a variety of SEC 2 recommended Elliptic Curve domain
parameters. The execution time and memory footprint are shown next to
each of the curve parameters. SHA-1 hashing algorithm included in the
library was used in each of the cases. It is clearly observable that
for similar security levels, Elliptic Curve public key cryptography
outperforms RSA. These results were obtained by turning on all the
optimizations. These optimizations include - Curve Specific Optimizations
for modular reduction (NIST and SEC 2 field primes were chosen as pseudo-Mersenne primes),
Sliding Window for faster scalar multiplication, Hybrid squaring procedure
written in assembly and Weighted projective Co-ordinate system for efficient scalar point addition, doubling
and multiplication. We did not use optimizations like Shamir Trick and Sliding Window as they are only useful for signature verification and tend
to slow down the signature generation by precomputing values (we were only interested in fast signature generation). There is still
some scope for optimization as not all the assembly code provided with the library could be ported to Arduino directly. Re-writing these
procedures in compatible assembly would further enhance the performance.
<texttable anchor='ecc-performance'>
<ttcol align='left'>Curve parameters</ttcol>
<ttcol align='right'>Execution time (ms)</ttcol>
<ttcol align='left'>Memory Footprint (bytes)</ttcol>
<ttcol align='right'>Comparable RSA key length</ttcol>
<c>128r1</c><c>1,858</c><c>776</c><c>704</c>
<c>128r2</c><c>2,002</c><c>776</c><c>704</c>
<c>160k1</c><c>2,228</c><c>892</c><c>1,024</c>
<c>160r1</c><c>2,250</c><c>892</c><c>1,024</c>
<c>160r2</c><c>2,467</c><c>892</c><c>1,024</c>
<c>192k1</c><c>3,425</c><c>1008</c><c>1,536</c>
<c>192r1</c><c>3,578</c><c>1008</c><c>1,536</c>
<postamble>ECDSA signature performance with TinyECC</postamble>
</texttable>
We also performed experiments by removing the assembly code for hybrid multiplication and squaring thus using a C only form of the
library. This gives us an idea of the performance that can be achieved with TinyECC on any platform regardless of
what kind of OS and assembly instruction set available. The memory footprint remains the same with our without
assembly code. The tables contain the maximum RAM that is used when all the possible optimizations are on. If however, the amount
of RAM available is smaller in size, some of the optimizations can be turned off to reduce the memory consumption accordingly.
<texttable anchor='ecc-perf-noasm'>
<ttcol align='left'>Curve parameters</ttcol>
<ttcol align='right'>Execution time (ms)</ttcol>
<ttcol align='left'>Memory Footprint (bytes)</ttcol>
<ttcol align='right'>Comparable RSA key length</ttcol>
<c>128r1</c><c>2,741</c><c>776</c><c>704</c>
<c>128r2</c><c>3,086</c><c>776</c><c>704</c>
<c>160k1</c><c>3,795</c><c>892</c><c>1,024</c>
<c>160r1</c><c>3,841</c><c>892</c><c>1,024</c>
<c>160r2</c><c>4,118</c><c>892</c><c>1,024</c>
<c>192k1</c><c>6,091</c><c>1008</c><c>1,536</c>
<c>192r1</c><c>6,217</c><c>1008</c><c>1,536</c>
<postamble>ECDSA signature performance with TinyECC (No assembly optimizations)</postamble>
</texttable>
</t>
<t><xref target='wiselib-performance'/> documents the performance of Wiselib. Since
there were no optimizations that could be turned on or off, we have only one set of results. By default
Wiselib only supports some of the standard SEC 2 Elliptic curves. But it is easy to change the domain parameters
and obtain results for for all the 128, 160 and 192-bit SEC 2 Elliptic curves. SHA-1 algorithm
provided in the library was used. The ROM size for all the experiments was less than 16 kB.
<texttable anchor='wiselib-performance'>
<ttcol align='left'>Curve parameters</ttcol>
<ttcol align='right'>Execution time (ms)</ttcol>
<ttcol align='left'>Memory Footprint (bytes)</ttcol>
<ttcol align='right'>Comparable RSA key length</ttcol>
<c>128r1</c><c>10,744</c><c>732</c><c>704</c>
<c>128r2</c><c>10,615</c><c>732</c><c>704</c>
<c>160k1</c><c>20,164</c><c>842</c><c>1,024</c>
<c>160r1</c><c>20,231</c><c>842</c><c>1,024</c>
<c>160r2</c><c>20,231</c><c>842</c><c>1,024</c>
<c>192k1</c><c>34,486</c><c>952</c><c>1,536</c>
<c>192r1</c><c>34,558</c><c>952</c><c>1,536</c>
<postamble>ECDSA signature performance with Wiselib</postamble>
</texttable>
</t>
</section>
<t>
For testing the relic-toolkit we used a different board because it required more RAM/ROM and we were unable to
perform experiments with it on Arduino Uno. We decided to use the Arduino Mega which has the same 8-bit architecture
like the Arduino Uno but has a much larger RAM/ROM for testing relic-toolkit.
The relic-toolkit supports curves over prime as well as binary fields. Since it is shown in
<xref target='binary-prime'/> that Kolobitz curves perform better over binary fields
than prime fields, we have experimented with curves over binary fields only. We leave the comparison of ordinary
curves over prime and binary fields on 8-bit platforms as future work.
The results from relic-toolkit are documented in two separate tables shown in <xref target='relic-fast'/> and
<xref target='relic-lowmem'/>. The first set of results were performed with the library configured for high
speed performance with no consideration given to the amount of memory used. For the second set, the library was
configured for low memory usage irrespective of the execution time required by different curves. By turning on/off
optimizations included in the library, a trade-off between memory and execution time between these values can be
achieved.
<texttable anchor='relic-fast'>
<ttcol align='left'>Curve parameters</ttcol>
<ttcol align='right'>Execution time (ms)</ttcol>
<ttcol align='left'>Memory Footprint (bytes)</ttcol>
<ttcol align='right'>Comparable RSA key length</ttcol>
<c>NIST K163 (assembly math)</c><c>300</c><c>2,804</c><c>1024</c>
<c>NIST K163</c><c>966</c><c>2,750</c><c>1024</c>
<c>NIST B163</c><c>2,408</c><c>2,444</c><c>1024</c>
<c>NIST K233</c><c>1,828</c><c>3,675</c><c>2,048</c>
<c>NIST B233</c><c>4,834</c><c>3,261</c><c>2,048</c>
<postamble>ECDSA signature performance with relic-toolkit (Fast)</postamble>
</texttable>
<texttable anchor='relic-lowmem'>
<ttcol align='left'>Curve parameters</ttcol>
<ttcol align='right'>Execution time (ms)</ttcol>
<ttcol align='left'>Memory Footprint (bytes)</ttcol>
<ttcol align='right'>Comparable RSA key length</ttcol>
<c>NIST K163 (assembly math)</c><c>1,128</c><c>2,087</c><c>1024</c>
<c>NIST K163</c><c>3,178</c><c>2,215</c><c>1024</c>
<c>NIST B163</c><c>3,464</c><c>2,071</c><c>1024</c>
<c>NIST K233</c><c>6,995</c><c>2,935</c><c>2,048</c>
<c>NIST B233</c><c>6,535</c><c>2,737</c><c>2,048</c>
<postamble>ECDSA signature performance with relic-toolkit (Low Memory)</postamble>
</texttable>
It is important to note the following points about the elliptic curve measurements:<list style="symbols">
<t> The arduino board only provides pseudo random numbers with the random() function call. In order to create private
keys with a better quality of random number, we can use a true random number generator like the one provided by TrueRandom library <xref target='truerandom'/>,
or create the keys separately on a system with a true random number generator and then use them directly in the code.</t>
<t> For measuring the memory footprint of all the ECC libraries, we used the Avrora simulator <xref target='avrora'/>. Only stack memory was used to easily
track the RAM consumption. </t>
</list>
</t>
<section anchor="trade" title="Design Trade-Offs">
<t>This section attempts to make some early conclusions regarding
trade-offs in the design space, based on deployment considerations for
various mechanisms and the relative ease or difficulty of implementing
them. This analysis looks at layering and the choice of symmetric
vs. asymmetric cryptography.</t>
<section title="Feasibility">
<t>The first question is whether using cryptographic security and
asymmetric cryptography in particular is feasible at all on small
devices. The numbers above give a mixed message. Clearly, an
implementation of a significant cryptographic operation such as public
key signing can be done in surprisingly small amount of code space. It
could even be argued that our chosen prototype platform was
unnecessarily restrictive in the amount of code space it allows: we
chose this platform on purpose to demonstrate something that is as
small and difficult as possible.</t>
<t>In reality, ROM memory size is probably easier to grow than other
parameters in microcontrollers. A recent trend in microcontrollers is
the introduction of 32-bit CPUs that are becoming cheaper and more
easily available than 8-bit CPUs, in addition to being more easily
programmable. In short, the authors do not expect the code size to be
a significant limiting factor, both because of the small amount of
code that is needed and because available memory space is growing
rapidly.</t>
<t>The situation is less clear with regards to the amount of CPU power
needed to run the algorithms. The demonstrated speeds are sufficient
for many applications. For instance, a sensor that wakes up every now
and then can likely spend a fraction of a second for the computation
of a signature for the message that it is about to send. Or even spend
multiple seconds in some cases. Most applications that use protocols
such as DTLS that use public key cryptography only at the beginning of
the session would also be fine with any of these execution times.</t>
<t>Yet, with reasonably long key sizes the execution times are in the
seconds, dozens of seconds, or even longer. For some applications this
is too long. Nevertheless, the authors believe that these algorithms
can successfully be employed in small devices for the following
reasons:
<list style="symbols">
<t>As discussed in <xref target="wiman"/>, in general the power requirements
necessary to send or receive messages are far bigger than those needed
to execute cryptographic operations. There is no good reason to choose
platforms that do not provide sufficient computing power to run the
necessary operations.
</t>
<t>Commercial libraries and the use of full potential for various
optimizations will provide a better result than what we arrived at in
this paper.</t>
<t>Using public key cryptography only at the beginning of a session
will reduce the per-packet processing times significantly.</t>
</list>
</t>
</section>
<section title="Layering">
<t>It would be useful to select just one layer where security is
provided at. Otherwise a simple device needs to implement multiple
security mechanisms. While some code can probably be shared across
such implementations (like algorithms), it is likely that most of the
code involving the actual protocol machinery cannot. Looking at the different
layers, here are the choices and their implications:
<list style="hanging">
<t hangText="link layer"><vspace blankLines="1"/> This is probably the
most common solution today. The biggest benefits of this choice of
layer are that security services are commonly available (WLAN secrets,
cellular SIM cards, etc.) and that their application protects the
entire communications.
<vspace blankLines="1"/>
The main drawback is that there is no security beyond the first
hop. This can be problematic, e.g., in many devices that communicate
to a server in the Internet. A Withings scale <xref
target="Withings"/>, for instance, can support WLAN security but
without some level of end-to-end security, it would be difficult to
prevent fraudulent data submissions to the servers.
<vspace blankLines="1"/>
Another drawback is that some commonly implemented link layer security
designs use group secrets. This allows any device within the local
network (e.g., an infected laptop) to attack the communications.</t>
<t hangText="network layer"><vspace blankLines="1"/> There are a
number of solutions in this space, and many new ones and variations
thereof being proposed: IPsec, PANA, and so on. In general, these
solutions have similar characteristics to those in the transport
layer: they work across forwarding hops but only as far as to the next
middlebox or application entity. There is plenty of existing solutions
and designs.
<vspace blankLines="1"/>
Experience has shown that it is difficult to control IP layer entities
from an application process. While this is theoretically easy, in
practice the necessary APIs do not exist. For instance, most IPsec
software has been built for the VPN use case, and is difficult or
impossible to tweak to be used on a per-application basis. As a
result, the authors are not particularly enthusiastic about
recommending these solutions.</t>
<t hangText="transport and application layer"><vspace blankLines="1"/>
This is another popular solution along with link layer designs. SSL,
TLS, DTLS, and HTTPS are examples of solutions in this space, and have
been proven to work well. These solutions are typically easy to take
into use in an application, without assuming anything from the
underlying OS, and they are easy to control as needed by the
applications. The main drawback is that generally speaking, these
solutions only run as far as the next application level entity. And
even for this case, HTTPS can be made to work through proxies, so this
limit is not unsolvable. Another drawback is that attacks on link
layer, network layer and in some cases, transport layer, can not be
protected against. However, if the upper layers have been protected,
such attacks can at most result in a denial-of-service. Since
denial-of-service can often be caused anyway, it is not clear if this
is a real drawback.</t>
<t hangText="data object layer"><vspace blankLines="1"/> This solution
does not protect any of the protocol layers, but protects individual
data elements being sent. It works particularly well when there are
multiple application layer entities on the path of the data. The
authors believe smart object networks are likely to employ such
entities for storage, filtering, aggregation and other reasons, and as
such, an end-to-end solution is the only one that can protect the
actual data.
<vspace blankLines="1"/>
The downside is that the lower layers are not protected. But again,
as long as the data is protected and checked upon every time it passes
through an application level entity, it is not clear that there are
attacks beyond denial-of-service.
<vspace blankLines="1"/>
The main question mark is whether this type of a solution provides
sufficient advantages over the more commonly implemented transport and
application layer solutions.</t>
</list>
</t>
</section>
<section title="Symmetric vs. Asymmetric Crypto">
<t>The second trade-off that is worth discussing is the use of plain
asymmetric cryptographic mechanisms, plain symmetric cryptographic mechanisms,
or some mixture thereof.</t>
<t>Contrary to popular cryptographic community beliefs, a symmetric
crypto solution can be deployed in large scale. In fact, the largest
deployment of cryptographic security, the cellular network
authentication system, uses SIM cards that are based on symmetric
secrets. In contrast, public key systems have yet to show ability to scale
to hundreds of millions of devices, let alone billions. But the
authors do not believe scaling is an important differentiator when
comparing the solutions.</t>
<t>As can be seen from the <xref target="impexp"/>, the time needed to
calculate some of the asymmetric crypto operations with reasonable key
lengths can be significant. There are two contrary observations that
can be made from this. First, recent wisdom indicates that computing
power on small devices is far cheaper than transmission power <xref
target="wiman"/>, and keeps on becoming more efficient very
quickly. From this we can conclude that the sufficient CPU is or at
least will be easily available.</t>
<t>But the other observation is that when there are very costly
asymmetric operations, doing a key exchange followed by the use of
generated symmetric keys would make sense. This model works very well
for DTLS and other transport layer solutions, but works less well for
data object security, particularly when the number of communicating
entities is not exactly two.</t>
</section>
</section>
<section title="Security Considerations">
<t>This entire memo deals with security issues.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA impacts in this memo.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.draft-ietf-core-coap-06.xml"?>
<reference anchor="arduino-uno"
target="http://arduino.cc/en/Main/arduinoBoardUno">
<front>
<title>Arduino Uno</title>
</front>
</reference>
<reference anchor="relic-toolkit"
target="http://code.google.com/p/relic-toolkit/">
<front>
<title>Relic Toolkit</title>
<author fullname='D. F. Aranha'>
</author>
<author fullname='C. P. L. Gouv'>
</author>
</front>
</reference>
<reference anchor="avr-crypto-lib"
target="http://www.das-labor.org/wiki/AVR-Crypto-Lib/en">
<front>
<title>AVR-CRYPTO-LIB</title>
<author fullname='Tobias Baumgartner'>
</author>
<author fullname='Ioannis Chatzigiannakis'/>
<author fullname='Sandor P. Fekete'/>
<author fullname='Christos Koninis'/>
<author fullname='Alexander Kroeller'/>
<author fullname='Apostolos Pyrgelis'/>
</front>
</reference>
<reference anchor="avr-cryptolib"
target="http://www.emsign.nl/">
<front>
<title>AVR CRYPTOLIB</title>
<author fullname='Emile van der Laan'>
</author>
</front>
</reference>
<reference anchor="avrora"
target="http://compilers.cs.ucla.edu/avrora/">
<front>
<title>AVR CRYPTOLIB</title>
<author fullname='Ben L. Titzer and others'>
</author>
</front>
</reference>
<reference anchor="truerandom"
target="http://code.google.com/p/tinkerit/wiki/TrueRandom">
<front>
<title>AVR CRYPTOLIB</title>
<author fullname='Cathe Drow'>
</author>
</front>
</reference>
<reference anchor="wiselib"
target="www.wiselib.org/">
<front>
<title></title>
<author fullname="Tobias Baumgartner"></author>
<author fullname="Ioannis Chatzigiannakis"></author>
<author fullname="Sandor Fekete"></author>
<author fullname="Christos Koninis"></author>
<author fullname="Alexander Kroller"></author>
<author fullname="Apostolos Pyrgelis"></author>
</front>
</reference>
<reference anchor="tinyecc"
target="http://discovery.csc.ncsu.edu/software/TinyECC/">
<front>
<title>TinyECC</title>
<author fullname='An Liu'>
<organization>North Carolina State University</organization>
</author>
<author fullname='Dr. Peng Ning'>
<organization>North Carolina State University</organization>
</author>
</front>
</reference>
<reference anchor="matrix-ssl"
target="http://www.matrixssl.org/">
<front>
<title>Matrix SSL</title>
<author fullname=''>
<organization>PeerSec Networks</organization>
</author>
</front>
</reference>
<reference anchor="rsa-high-speed"
target="http://cs.ucsb.edu/~koc/docs/r01.pdf">
<front>
<title>High-Speed RSA Implementation</title>
<author fullname='C. K. Koc'>
<organization>RSA Labs</organization>
</author>
</front>
</reference>
<reference anchor="binary-prime"
target="http://cs.ucsb.edu/~koc/docs/r01.pdf">
<front>
<title>High-Speed RSA Implementation</title>
<author fullname='M. Brown'>
<organization>University of Waterloo
</organization>
</author>
<author fullname='D. Hankerson'>
<organization>Auburn University
</organization>
</author>
<author fullname='J. Lopez'>
<organization>University of Valle
</organization>
</author>
<author fullname='A. Menezes'>
<organization>Certicom Research
</organization>
</author>
</front>
</reference>
<reference anchor="rsa-8bit"
target="">
<front>
<title>Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs
</title>
<author fullname='Nils Gura'>
<organization>Sun Microsystems</organization>
</author>
<author fullname='Arun Patel'>
</author>
<author fullname='Arvinderpal Wander'>
</author>
<author fullname='Hans Eberle'>
</author>
<author fullname='Sheueling Chang Shantz'>
</author>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3748.xml"?>
<!-- <?rfc include="reference.RFC.3971.xml"?> -->
<?rfc include="reference.RFC.3972.xml"?>
<?rfc include="reference.RFC.4306.xml"?>
<?rfc include="reference.RFC.5191.xml"?>
<?rfc include="reference.RFC.5201.xml"?>
<?rfc include="reference.RFC.5238.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.5406.xml"?>
<?rfc include="reference.RFC.6078.xml"?>
<?rfc include="reference.I-D.arkko-core-sleepy-sensors.xml"?>
<?rfc include="reference.I-D.arkko-core-security-arch.xml"?>
<?rfc include="reference.I-D.daniel-6lowpan-security-analysis.xml"?>
<?rfc include="reference.I-D.garcia-core-security.xml"?>
<?rfc include="reference.I-D.iab-smart-object-workshop.xml"?>
<?rfc include="reference.I-D.ietf-hip-rfc5201-bis.xml"?>
<?rfc include="reference.I-D.kivinen-ipsecme-ikev2-minimal.xml"?>
<?rfc include="reference.I-D.moskowitz-hip-rg-dex.xml"?>
<reference anchor="Withings" target="http://www.withings.com/en/bodyscale">
<front>
<title>The Withings scale</title>
<author fullname=''>
<organization>Withings</organization>
</author>
<date year="2012" month="February"/>
</front>
</reference>
<reference anchor="wiman">
<front>
<author fullname="C. B. MARGI"></author>
<author fullname="B. T. OLIVEIRA"></author>
<author fullname="G. T. SOUSA"></author>
<author fullname="M. A. SIMPLÍCIO"></author>
<author fullname="S. L. M. B. Paulo"></author>
<author fullname="T. C. M. CARVALHO"></author>
<author fullname="M. NÄSLUND"></author>
<author fullname="R. GOLD"></author>
<title>Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds. In International Conference on Computer Communication Networks (ICCCN'2010) / IEEE International Workshop on Wireless Mesh and Ad Hoc Networks (WiMAN 2010), 2010, Zürich. Proceedings of ICCCN'2010/WiMAN'2010</title>
<date year="2010"/>
</front>
</reference>
</references>
<section title="Acknowledgments">
<t>The authors would like to thank Mats Naslund, Salvatore Loreto, Bob
Moskowitz, Oscar Novo, Heidi-Maria Rissanen, Vlasios Tsiatsis, Eric Rescorla and Tero
Kivinen for interesting discussions in this problem space. The authors would also like to thank
Diego Aranha for helping with the relic-toolkit configurations and Tobias Baumgartner for helping with questions regarding wiselib.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:51 |