draft-ietf-lwig-crypto-sensors-02.txt | draft-ietf-lwig-crypto-sensors-03.txt | |||
---|---|---|---|---|
Light-Weight Implementation Guidance M. Sethi | Light-Weight Implementation Guidance M. Sethi | |||
Internet-Draft J. Arkko | Internet-Draft J. Arkko | |||
Intended status: Informational A. Keranen | Intended status: Informational A. Keranen | |||
Expires: August 14, 2017 Ericsson | Expires: January 26, 2018 Ericsson | |||
H. Back | H. Back | |||
Comptel | Comptel | |||
February 10, 2017 | July 25, 2017 | |||
Practical Considerations and Implementation Experiences in Securing | Practical Considerations and Implementation Experiences in Securing | |||
Smart Object Networks | Smart Object Networks | |||
draft-ietf-lwig-crypto-sensors-02 | draft-ietf-lwig-crypto-sensors-03 | |||
Abstract | Abstract | |||
This memo describes challenges associated with securing smart object | This memo describes challenges associated with securing resource- | |||
devices in constrained implementations and environments. The memo | constrained smart object devices. The memo describes a possible | |||
describes a possible deployment model suitable for these | deployment model suitable for these environments, discusses the | |||
environments, discusses the availability of cryptographic libraries | availability of cryptographic libraries for small devices, and | |||
for small devices, presents some preliminary experiences in | presents some preliminary experiences in implementing cryptography on | |||
implementing cryptography on small devices using those libraries, and | small devices using those libraries. Lastly, the memo discusses | |||
discusses trade-offs involving different types of approaches. | trade-offs involving different types of security approaches. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on August 14, 2017. | This Internet-Draft will expire on January 26, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 | 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 | |||
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 | 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 | 6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Implementation Experiences . . . . . . . . . . . . . . . . . 11 | 8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 | |||
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 | 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 | 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 | |||
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 | 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | |||
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |||
17. Informative references . . . . . . . . . . . . . . . . . . . 27 | 17. Informative references . . . . . . . . . . . . . . . . . . . 26 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
1. Introduction | 1. Introduction | |||
This memo describes challenges associated with securing smart object | This memo describes challenges associated with securing smart object | |||
devices in constrained implementations and environments. In | devices in constrained implementations and environments. In | |||
Section 3 we specifically discuss three challenges: the | Section 3 we specifically discuss three challenges: the | |||
implementation difficulties encountered on resource-constrained | implementation difficulties encountered on resource-constrained | |||
platforms, the problem of provisioning keys and making the choice of | platforms, the problem of provisioning keys and making the choice of | |||
implementing security at the appropriate layer. | implementing security at the appropriate layer. | |||
Secondly, Section 4 discusses a deployment model that the authors are | Section 4 discusses a deployment model that the authors are | |||
considering for constrained environments. The model requires minimal | considering for constrained environments. The model requires minimal | |||
amount of configuration, and we believe it is a natural fit with the | amount of configuration, and we believe it is a natural fit with the | |||
typical communication practices in smart object networking | typical communication practices in smart object networking | |||
environments. | environments. | |||
Thirdly, Section 7 discusses the availability of cryptographic | Section 7 discusses the availability of cryptographic libraries. | |||
libraries. Section 8 presents some experiences in implementing | Section 8 presents some experiences in implementing cryptography on | |||
cryptography on small devices using those libraries, including | small devices using those libraries, including information about | |||
information about achievable code sizes and speeds on typical | achievable code sizes and speeds on typical hardware. | |||
hardware. | ||||
Finally, Section 10 discusses trade-offs involving different types of | Finally, Section 10 discusses trade-offs involving different types of | |||
security approaches. | security approaches. | |||
2. Related Work | 2. Related Work | |||
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight | Constrained Application Protocol (CoAP) [RFC7252] is a light-weight | |||
protocol designed to be used in machine-to-machine applications such | protocol designed to be used in machine-to-machine applications such | |||
as smart energy and building automation. Our discussion uses this | as smart energy and building automation. Our discussion uses this | |||
protocol as an example, but the conclusions may apply to other | protocol as an example, but the conclusions may apply to other | |||
similar protocols. CoAP base specification [RFC7252] outlines how to | similar protocols. CoAP base specification [RFC7252] outlines how to | |||
use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. | use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. | |||
DTLS can be applied with pairwise shared keys, raw public keys or | DTLS can be applied with pairwise shared keys, raw public keys or | |||
with certificates. The security model in all cases is mutual | with certificates. The security model in all cases is mutual | |||
authentication, so while there is some commonality to HTTP in | authentication, so while there is some commonality to HTTP [RFC7230] | |||
verifying the server identity, in practice the models are quite | in verifying the server identity, in practice the models are quite | |||
different. The CoAP specification says little about how DTLS keys | different. The use of IPsec with CoAP is described with regards to | |||
are managed. The use of IPsec with CoAP is described with regards to | ||||
the protocol requirements, noting that small implementations of IKEv2 | the protocol requirements, noting that small implementations of IKEv2 | |||
exist [RFC7815] . However, the CoAP specification is silent on policy | exist [RFC7815]. However, the CoAP specification is silent on policy | |||
and other aspects that are normally necessary in order to implement | and other aspects that are normally necessary in order to implement | |||
interoperable use of IPsec in any environment [RFC5406]. | interoperable use of IPsec in any environment [RFC5406]. | |||
[RFC6574] gives an overview of the security discussions at the March | [RFC6574] gives an overview of the security discussions at the March | |||
2011 IAB workshop on smart objects. The workshop recommended that | 2011 IAB workshop on smart objects. The workshop recommended that | |||
additional work is needed in developing suitable credential | additional work is needed in developing suitable credential | |||
management mechanisms (perhaps something similar to the Bluetooth | management mechanisms (perhaps something similar to the Bluetooth | |||
pairing mechanism), understanding the implementability of standard | pairing mechanism), understanding the implementability of standard | |||
security mechanisms in small devices, and additional research in the | security mechanisms in small devices, and additional research in the | |||
area of lightweight cryptographic primitives. | area of lightweight cryptographic primitives. | |||
skipping to change at page 4, line 39 ¶ | skipping to change at page 4, line 37 ¶ | |||
limited support for security mechanisms, limited processing power for | limited support for security mechanisms, limited processing power for | |||
long key lengths, sleep schedule that does not allow communication at | long key lengths, sleep schedule that does not allow communication at | |||
all times, and so on. In addition, the devices typically have very | all times, and so on. In addition, the devices typically have very | |||
limited support for configuration, making it hard to set up secrets | limited support for configuration, making it hard to set up secrets | |||
and trust anchors. | and trust anchors. | |||
The implementation difficulties are important, but they should not be | The implementation difficulties are important, but they should not be | |||
overemphasized. It is important to select the right security | overemphasized. It is important to select the right security | |||
mechanisms and avoid duplicated or unnecessary functionality. But at | mechanisms and avoid duplicated or unnecessary functionality. But at | |||
the end of the day, if strong cryptographic security is needed, the | the end of the day, if strong cryptographic security is needed, the | |||
implementations have to support that. Also, the use of the most | implementations have to support that. It is important for developers | |||
lightweight algorithms and cryptographic primitives is useful, but | and product designers to determine what security threats they want to | |||
should not be the only consideration in the design. Interoperability | tackle and the resulting security requirements before selecting the | |||
is also important, and often other parts of the system, such as key | hardware. Often, development work in the wild happens in the wrong | |||
management protocols or certificate formats are heavier to implement | order: a particular platform with a resource-constrained | |||
than the algorithms themselves. | microcontroller is chosen first, and then the security features that | |||
can fit on it are decided. Also, the use of the most lightweight | ||||
algorithms and cryptographic primitives is useful, but should not be | ||||
the only consideration in the design and development. | ||||
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. | ||||
The second challenge relates to practical provisioning problems. | The second challenge relates to practical provisioning problems. | |||
These are perhaps the most fundamental and difficult issue, and | These are perhaps the most fundamental and difficult issue, and | |||
unfortunately often neglected in the design. There are several | unfortunately often neglected in the design. There are several | |||
problems in the provisioning and management of smart object networks: | problems in the provisioning and management of smart object networks: | |||
o Small devices have no natural user interface for configuration | o Small devices have no natural user interface for configuration | |||
that would be required for the installation of shared secrets and | that would be required for the installation of shared secrets and | |||
other security-related parameters. Typically, there is no | other security-related parameters. Typically, there is no | |||
keyboard, no display, and there may not even be buttons to press. | keyboard, no display, and there may not even be buttons to press. | |||
skipping to change at page 9, line 25 ¶ | skipping to change at page 9, line 28 ¶ | |||
solutions are more likely to be able to benefit from sessions where | solutions are more likely to be able to benefit from sessions where | |||
the cost of expensive operations can be amortized over multiple data | the cost of expensive operations can be amortized over multiple data | |||
transmissions. While this is not impossible in data object security | transmissions. While this is not impossible in data object security | |||
solutions either, it is not the typical arrangement either. | solutions either, it is not the typical arrangement either. | |||
7. Code Availability | 7. Code Availability | |||
For implementing public key cryptography on resource constrained | For implementing public key cryptography on resource constrained | |||
environments, we chose Arduino Uno board [arduino-uno] as the test | environments, we chose Arduino Uno board [arduino-uno] as the test | |||
platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit | platform. Arduino Uno has an ATmega328 microcontroller, an 8-bit | |||
processor with a clock speed of 16 MHz, 2 kB of SRAM, and 32 kB of | processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of | |||
flash memory. | flash memory. Our choice of 8-bit platform may be surprising since | |||
it. | ||||
For selecting potential asymmetric cryptographic libraries, we | For selecting potential asymmetric cryptographic libraries, we | |||
surveyed and came up with a set of possible code sources, and | surveyed and came up with a set of possible code sources, and | |||
performed an initial analysis of how well they fit the Arduino | performed an initial analysis of how well they fit the Arduino | |||
environment. Note that the results are preliminary, and could easily | environment. Note that the results are preliminary, and could easily | |||
be affected in any direction by implementation bugs, configuration | be affected in any direction by implementation bugs, configuration | |||
errors, and other mistakes. It is advisable to verify the numbers | errors, and other mistakes. It is advisable to verify the numbers | |||
before relying on them for building something. No significant effort | before relying on them for building something. No significant effort | |||
was done to optimize ROM memory usage beyond what the libraries | was done to optimize ROM memory usage beyond what the libraries | |||
provided themselves, so those numbers should be taken as upper | provided themselves, so those numbers should be taken as upper | |||
limits. | limits. | |||
Here is the set of libraries we found: | Here is the set of libraries we found: | |||
o AvrCryptolib [avr-cryptolib]: This library provides a variety of | o AvrCryptolib [avr-cryptolib]: This library provides a variety of | |||
different symmetric key algorithms such as AES and RSA as an | different symmetric key algorithms such as AES, triple DES and | |||
asymmetric key algorithm. We stripped down the library to use | SkipJack. It provides RSA as an asymmetric key algorithm. Parts | |||
only the required RSA components and used a separate SHA-256 | of the library were written in AVR-8 bit assembly language to | |||
implementation from the original AvrCrypto-Lib library | reduce the size and optimize the performance. | |||
[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. | ||||
o Relic-Toolkit [relic-toolkit]: This library is written entirely in | o Relic-Toolkit [relic-toolkit]: This library is written entirely in | |||
C and provides a highly flexible and customizable implementation | C and provides a highly flexible and customizable implementation | |||
of a large variety of cryptographic algorithms. This not only | of a large variety of cryptographic algorithms. This not only | |||
includes RSA and ECC, but also pairing based asymmetric | includes RSA and ECC, but also pairing based asymmetric | |||
cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures | cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures | |||
and many more. The toolkit provides an option to build only the | and many more. The toolkit provides an option to build only the | |||
desired components for the required platform. While building the | desired components for the required platform. | |||
library, it is possible to select a variety of 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. | ||||
o TinyECC [tinyecc]: TinyECC was designed for using Elliptic Curve | o TinyECC [tinyecc]: TinyECC was designed for using elliptic curve | |||
based public key cryptography on sensor networks. It is written | based public key cryptography on sensor networks. It is written | |||
in nesC programming language and as such is designed for specific | in nesC programming language and as such is designed for specific | |||
use on TinyOS. However, the library can be ported to standard C99 | use on TinyOS. However, the library can be ported to standard C | |||
either with hacked tool-chains or manually rewriting parts of the | either with tool-chains or manually rewriting parts of the code. | |||
code. This allows for the library to be used on platforms that do | It also has one of the smallest memory footprints among the set of | |||
not have TinyOS running on them. The library includes a wide | elliptic curve libraries surveyed so far. | |||
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. | ||||
o Wiselib [wiselib]: Wiselib is a generic library written for sensor | o Wiselib [wiselib]: Wiselib is a generic library written for sensor | |||
networks containing a wide variety of algorithms. While the | networks containing a wide variety of algorithms. While the | |||
stable version contains algorithms for routing only, the test | stable version contains algorithms for routing only, the test | |||
version includes many more algorithms including algorithms for | version includes many more algorithms including algorithms for | |||
cryptography, localization, topology management and many more. | cryptography, localization, topology management and many more. | |||
The library was designed with the idea of making it easy to | The library was designed with the idea of making it easy to | |||
interface the library with operating systems like iSense and | interface the library with operating systems like iSense and | |||
Contiki. However, since the library is written entirely in C++ | Contiki. However, since the library is written entirely in C++ | |||
with a template based model similar to Boost/CGAL, it can be used | with a template based model similar to Boost/CGAL, it can be used | |||
on any platform directly without using any of the operating system | on any platform directly without using any of the operating system | |||
interfaces provided. This approach was taken by the authors to | interfaces provided. This approach was taken by the authors to | |||
test the code on Arduino Uno. The structure of the code is similar | test the code on Arduino Uno. | |||
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. | ||||
o MatrixSSL [matrix-ssl]: This library provides a low footprint | o MatrixSSL [matrix-ssl]: This library provides a low footprint | |||
implementation of several cryptographic algorithms including RSA | implementation of several cryptographic algorithms including RSA | |||
and ECC (with a commercial license). However, the library in the | and ECC (with a commercial license). The library in the original | |||
original form takes about 50 kB of ROM which is not suitable for | form takes about 50 kB of ROM and is intended for 32-bit | |||
our hardware requirements. Moreover, it is intended for 32-bit | platforms. | |||
systems and the API includes functions for SSL communication | ||||
rather than just signing data with private keys. | o ARM mbed OS [mbed]: The ARM mbed operating system provides various | |||
cryptographic primitives that are necessary for SSL/TLS protocol | ||||
implementation as well as X509 certificate handling. The library | ||||
provides an intuitive API for developer with a minimal code | ||||
foodprint. It is intended for various ARM platforms such as ARM | ||||
Cortex M0, ARM Cortex M0+ and ARM Cortex M3. | ||||
This is by no ways an exhaustive list and there exist other | This is by no ways an exhaustive list and there exist other | |||
cryptographic libraries targeting resource-constrained devices | cryptographic libraries targeting resource-constrained devices. | |||
8. Implementation Experiences | 8. Implementation Experiences | |||
While evaluating the implementation experiences, we were particularly | While evaluating the implementation experiences, we were particularly | |||
interested in the signature generation operation. This was because | interested in the signature generation operation. This was because | |||
our example application discussed in Section 9 required only the | our example application discussed in Section 9 required only the | |||
signature generation operation on the resource-constrained platforms. | signature generation operation on the resource-constrained platforms. | |||
We have summarized the initial results of RSA private key performance | We have summarized the initial results of RSA private key | |||
using AvrCryptolib in Table 1. All results are from a single run | exponentiation performance using AvrCryptolib [avr-crypto-lib] in | |||
since repeating the test did not change (or had only minimal impact | Table 1. All results are from a single run since repeating the test | |||
on) the results. The keys were generated separately and were hard | did not change (or had only minimal impact on) the results. The | |||
coded into the program. All keys were generated with the value of | execution time for a key size of 2048 bits was inordinately long and | |||
the public exponent as 3. The performance of signing with private | would be a deterrent in real-world deployments. | |||
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. | ||||
More importantly, any RSA key size less than 2,048-bit should be | ||||
considered legacy and insecure. The performance measurements for | ||||
these keys are provided here for reference only. | ||||
+--------+--------------+--------------+-------------+--------------+ | +--------------+------------------------+---------------------------+ | |||
| Key | Execution | Memory | Execution | Memory | | | Key length | Execution time (ms); | Memory footprint (bytes); | | |||
| length | time (ms); | footprint | time (ms); | footprint | | | (bits) | key in RAM | key in RAM | | |||
| (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | | +--------------+------------------------+---------------------------+ | |||
| | | in SRAM | | in ROM | | | 2048 | 1587567 | 1,280 | | |||
+--------+--------------+--------------+-------------+--------------+ | +--------------+------------------------+---------------------------+ | |||
| 64 | 64 | 40 | 69 | 32 | | ||||
| 128 | 434 | 80 | 460 | 64 | | ||||
| 512 | 25076 | 320 | 27348 | 256 | | ||||
| 1024 | 199688 | 640 | 218367 | 512 | | ||||
| 2048 | 1587567 | 1,280 | 1740258 | 1024 | | ||||
+--------+--------------+--------------+-------------+--------------+ | ||||
RSA private key operation performance | RSA private key operation performance | |||
Table 1 | Table 1 | |||
The code size was less than 3.6 kB for all the test cases with | The code size was about 3.6 kB with potential for further reduction. | |||
potential for further reduction. It is also worth noting that the | It is also worth noting that the implementation performs basic | |||
implementation performs basic exponentiation and multiplication | exponentiation and multiplication operations without using any | |||
operations without using any mathematical optimizations such as | mathematical optimizations such as Montgomery multiplication, | |||
Montgomery multiplication, optimized squaring, etc. as described in | optimized squaring, etc. as described in [rsa-high-speed]. With more | |||
[rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit | RAM, we believe that 2048-bit operations can be performed in much | |||
operations can be performed in much less time as has been shown in | less time as has been shown in [rsa-8bit]. | |||
[rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of | ||||
SRAM as is seen in Table 1. | ||||
In Table 2 we present the results obtained by manually porting | In Table 2 we present the results obtained by manually porting | |||
TinyECC into C99 standard and running ECDSA signature algorithm on | TinyECC into C99 standard and running ECDSA signature algorithm on | |||
the Arduino Uno board. TinyECC supports a variety of SEC 2 | the Arduino Uno board. TinyECC supports a variety of SEC 2 | |||
recommended Elliptic Curve domain parameters. The execution time and | recommended Elliptic Curve domain parameters. The execution time and | |||
memory footprint are shown next to each of the curve parameters. | memory footprint are shown next to each of the curve parameters. | |||
SHA-1 hashing algorithm included in the library was used in each of | These results were obtained by turning on all the optimizations and | |||
the cases. The measurements reflect the performance of elliptic | using assembly code where available. It is clearly observable that | |||
curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now | for similar security levels, Elliptic Curve public key cryptography | |||
known to be insecure and should not be used in live deployments. It | outperforms RSA. | |||
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 Coordinate | ||||
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. | ||||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
| Curve | Execution | Memory | Comparable RSA | | | Curve | Execution | Memory | Comparable RSA | | |||
| parameters | time (ms) | Footprint | key length | | | parameters | time (ms) | Footprint | key length | | |||
| | | (bytes) | | | | | | (bytes) | | | |||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
| 128r1 | 1858 | 776 | 704 | | | secp160k1 | 2228 | 892 | 1024 | | |||
| 128r2 | 2002 | 776 | 704 | | | secp160r1 | 2250 | 892 | 1024 | | |||
| 160k1 | 2228 | 892 | 1024 | | | secp160r2 | 2467 | 892 | 1024 | | |||
| 160r1 | 2250 | 892 | 1024 | | | secp192k1 | 3425 | 1008 | 1536 | | |||
| 160r2 | 2467 | 892 | 1024 | | | secp192r1 | 3578 | 1008 | 1536 | | |||
| 192k1 | 3425 | 1008 | 1536 | | ||||
| 192r1 | 3578 | 1008 | 1536 | | ||||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
ECDSA signature performance with TinyECC | Performance of ECDSA sign operation with TinyECC | |||
Table 2 | Table 2 | |||
We also performed experiments by removing the assembly code for | We also performed experiments by removing the assembly optimization | |||
hybrid multiplication and squaring thus using a C only form of the | and using a C only form of the library. This gives us an idea of the | |||
library. This gives us an idea of the performance that can be | performance that can be achieved with TinyECC on any platform | |||
achieved with TinyECC on any platform regardless of what kind of OS | regardless of what kind of OS and assembly instruction set available. | |||
and assembly instruction set available. The memory footprint remains | The memory footprint remains the same with or without assembly code. | |||
the same with our without assembly code. The tables contain the | The tables contain the maximum RAM that is used when all the possible | |||
maximum RAM that is used when all the possible optimizations are on. | optimizations are on. If however, the amount of RAM available is | |||
If however, the amount of RAM available is smaller in size, some of | smaller in size, some of the optimizations can be turned off to | |||
the optimizations can be turned off to reduce the memory consumption | reduce the memory consumption accordingly. | |||
accordingly. | ||||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
| Curve | Execution | Memory | Comparable RSA | | | Curve | Execution | Memory | Comparable RSA | | |||
| parameters | time (ms) | Footprint | key length | | | parameters | time (ms) | Footprint | key length | | |||
| | | (bytes) | | | | | | (bytes) | | | |||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
| 128r1 | 2741 | 776 | 704 | | | secp160k1 | 3795 | 892 | 1024 | | |||
| 128r2 | 3086 | 776 | 704 | | | secp160r1 | 3841 | 892 | 1024 | | |||
| 160k1 | 3795 | 892 | 1024 | | | secp160r2 | 4118 | 892 | 1024 | | |||
| 160r1 | 3841 | 892 | 1024 | | | secp192k1 | 6091 | 1008 | 1536 | | |||
| 160r2 | 4118 | 892 | 1024 | | | secp192r1 | 6217 | 1008 | 1536 | | |||
| 192k1 | 6091 | 1008 | 1536 | | ||||
| 192r1 | 6217 | 1008 | 1536 | | ||||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
ECDSA signature performance with TinyECC (No assembly optimizations) | Performance of ECDSA sign operation with TinyECC (No assembly | |||
optimizations) | ||||
Table 3 | Table 3 | |||
Table 4 documents the performance of Wiselib. Since there were no | Table 4 documents the performance of Wiselib. Since there were no | |||
optimizations that could be turned on or off, we have only one set of | 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 | results. By default Wiselib only supports some of the standard SEC 2 | |||
Elliptic curves, but it is easy to change the domain parameters and | 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 | 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 | curves. The ROM size for all the experiments was less than 16 kB. | |||
measurements reflect the performance of elliptic curve signing only | ||||
and not the SHA-1 hashing algorithm. SHA-1 is now known to be | ||||
insecure and should not be used in real deployments. The ROM size | ||||
for all the experiments was less than 16 kB. | ||||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
| Curve | Execution | Memory | Comparable RSA | | | Curve | Execution | Memory | Comparable RSA | | |||
| parameters | time (ms) | Footprint | key length | | | parameters | time (ms) | Footprint | key length | | |||
| | | (bytes) | | | | | | (bytes) | | | |||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
| 128r1 | 5615 | 732 | 704 | | | secp160k1 | 10957 | 842 | 1024 | | |||
| 128r2 | 5615 | 732 | 704 | | | secp160r1 | 10972 | 842 | 1024 | | |||
| 160k1 | 10957 | 842 | 1024 | | | secp160r2 | 10971 | 842 | 1024 | | |||
| 160r1 | 10972 | 842 | 1024 | | | secp192k1 | 18814 | 952 | 1536 | | |||
| 160r2 | 10971 | 842 | 1024 | | | secp192r1 | 18825 | 952 | 1536 | | |||
| 192k1 | 18814 | 952 | 1536 | | ||||
| 192r1 | 18825 | 952 | 1536 | | ||||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
ECDSA signature performance with Wiselib | Performance ECDSA sign operation with Wiselib | |||
Table 4 | Table 4 | |||
For testing the relic-toolkit we used a different board because it | For testing the relic-toolkit we used a different board because it | |||
required more RAM/ROM and we were unable to perform experiments with | 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 | 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 | same 8-bit architecture like the Arduino Uno but has a much larger | |||
RAM/ROM for testing relic-toolkit. Again, SHA-1 hashing algorithm | RAM/ROM for testing relic-toolkit. Again, it is important to mention | |||
included in the library was used in each of the cases. The | that we used Arduino as it is a convenient prototyping platform. Our | |||
measurements reflect the performance of elliptic curve signing only | intention was to demonstrate the feasibility of the entire | |||
and not the SHA-1 hashing algorithm. SHA-1 is now known to be | architecture with public key cryptography on an 8-bit | |||
insecure and should not be used in real deployments. The library | microcontroller. However it is important to state that 32-bit | |||
does provide several alternatives with such as SHA-256. | microcontrollers are much more easily available, at lower costs and | |||
are more power efficient. Therefore, real deployments are better off | ||||
using 32-bit microcontrollers that allow developers to include the | ||||
necessary cryptographic libraries. There is no good reason to choose | ||||
platforms that do not provide sufficient computing power to run the | ||||
necessary cryptographic operations. | ||||
The relic-toolkit supports Koblitz curves over prime as well as | The relic-toolkit supports Koblitz curves over prime as well as | |||
binary fields. We have experimented with Koblitz curves over binary | binary fields. We have experimented with Koblitz curves over binary | |||
fields only. We do not run our experiments with all the curves | fields only. We do not run our experiments with all the curves | |||
available in the library since the aim of this work is not prove | available in the library since the aim of this work is not prove | |||
which curves perform the fastest, and rather show that asymmetric | which curves perform the fastest, and rather show that asymmetric | |||
cryptography is possible on resource-constrained devices. | cryptography is possible on resource-constrained devices. | |||
The results from relic-toolkit are documented in two separate tables | The results from relic-toolkit are documented in two separate tables | |||
shown in Table 5 and Table 6. The first set of results were | shown in Table 5 and Table 6. The first set of results were | |||
skipping to change at page 15, line 45 ¶ | skipping to change at page 14, line 20 ¶ | |||
| | | (bytes) | | | | | | (bytes) | | | |||
+-----------------+--------------+----------------+-----------------+ | +-----------------+--------------+----------------+-----------------+ | |||
| NIST K163 | 261 | 2,804 | 1024 | | | NIST K163 | 261 | 2,804 | 1024 | | |||
| (assembly math) | | | | | | (assembly math) | | | | | |||
| NIST K163 | 932 | 2750 | 1024 | | | NIST K163 | 932 | 2750 | 1024 | | |||
| NIST B163 | 2243 | 2444 | 1024 | | | NIST B163 | 2243 | 2444 | 1024 | | |||
| NIST K233 | 1736 | 3675 | 2048 | | | NIST K233 | 1736 | 3675 | 2048 | | |||
| NIST B233 | 4471 | 3261 | 2048 | | | NIST B233 | 4471 | 3261 | 2048 | | |||
+-----------------+--------------+----------------+-----------------+ | +-----------------+--------------+----------------+-----------------+ | |||
ECDSA signature performance with relic-toolkit (Fast) | Performance of ECDSA sign operation with relic-toolkit (Fast) | |||
Table 5 | Table 5 | |||
+-----------------+--------------+----------------+-----------------+ | +-----------------+--------------+----------------+-----------------+ | |||
| Curve | Execution | Memory | Comparable RSA | | | Curve | Execution | Memory | Comparable RSA | | |||
| parameters | time (ms) | Footprint | key length | | | parameters | time (ms) | Footprint | key length | | |||
| | | (bytes) | | | | | | (bytes) | | | |||
+-----------------+--------------+----------------+-----------------+ | +-----------------+--------------+----------------+-----------------+ | |||
| NIST K163 | 592 | 2087 | 1024 | | | NIST K163 | 592 | 2087 | 1024 | | |||
| (assembly math) | | | | | | (assembly math) | | | | | |||
| NIST K163 | 2950 | 2215 | 1024 | | | NIST K163 | 2950 | 2215 | 1024 | | |||
| NIST B163 | 3213 | 2071 | 1024 | | | NIST B163 | 3213 | 2071 | 1024 | | |||
| NIST K233 | 6450 | 2935 | 2048 | | | NIST K233 | 6450 | 2935 | 2048 | | |||
| NIST B233 | 6100 | 2737 | 2048 | | | NIST B233 | 6100 | 2737 | 2048 | | |||
+-----------------+--------------+----------------+-----------------+ | +-----------------+--------------+----------------+-----------------+ | |||
ECDSA signature performance with relic-toolkit (Low Memory) | Performance of ECDSA sign operation with relic-toolkit (Low Memory) | |||
Table 6 | Table 6 | |||
It is important to note the following points about the elliptic curve | It is important to note the following points about the elliptic curve | |||
measurements: | measurements: | |||
o As with the RSA measurements, curves giving less that 112-bit | ||||
security are insecure and considered as legacy. The measurements | ||||
are only provided for reference. | ||||
o The Arduino board only provides pseudo random numbers with the | o The Arduino board only provides pseudo random numbers with the | |||
random() function call. In order to create private keys with a | random() function call. Real-world deployments must rely on a | |||
better quality of random number, we can use a true random number | hardware random number generator for cryptographic operations such | |||
generator like the one provided by TrueRandom library | as generating a public-private key pair. The Nordic nRF52832 | |||
[truerandom], or create the keys separately on a system with a | board [nordic] for example provides a hardware random number | |||
true random number generator and then use them directly in the | generator. | |||
code. | ||||
o For measuring the memory footprint of all the ECC libraries, we | o For measuring the memory footprint of all the ECC libraries, we | |||
used the Avrora simulator [avrora]. Only stack memory was used to | used the Avrora simulator [avrora]. Only stack memory was used to | |||
easily track the RAM consumption. | easily track the RAM consumption. | |||
Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the | ||||
performance of Elliptic Curve Cryptography (ECC) on ARM Coretex | ||||
platform. The results for ECDSA sign operation shown in Table 7 are | ||||
performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM | ||||
Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB | ||||
of RAM. The sliding window technique for efficient exponentiation | ||||
was used with a window size of 2. All other optimizations were | ||||
disabled for these measurements. | ||||
+------------------+---------------------+--------------------------+ | ||||
| Curve parameters | Execution time (ms) | Comparable RSA key | | ||||
| | | length | | ||||
+------------------+---------------------+--------------------------+ | ||||
| secp192r1 | 2165 | 1536 | | ||||
| secp224r1 | 3014 | 2048 | | ||||
| secp256r1 | 3649 | 2048 | | ||||
+------------------+---------------------+--------------------------+ | ||||
Performance of ECDSA sign operation with ARM mbed TLS stack on | ||||
Freescale FRDM-KL25Z | ||||
Table 7 | ||||
The authors also measured the performance of curves on a ST Nucleo | ||||
F091 (STM32F091RCT6) board [stnucleo] that has a ARM Cortex-M0 48MHz | ||||
microcontroller with 256 kB of flash memory and 32kB of RAM. The | ||||
execution time for ECDSA sign operation with different curves is | ||||
shown in Table 8. The sliding window technique for efficient | ||||
exponentiation was used with a window size of 7. Fixed point | ||||
optimization and NIST curve specific optimizations were used for | ||||
these measurements. | ||||
+------------------+---------------------+--------------------------+ | ||||
| Curve parameters | Execution time (ms) | Comparable RSA key | | ||||
| | | length | | ||||
+------------------+---------------------+--------------------------+ | ||||
| secp192k1 | 291 | 1536 | | ||||
| secp192r1 | 225 | 1536 | | ||||
| secp224k1 | 375 | 2048 | | ||||
| secp224r1 | 307 | 2048 | | ||||
| secp256k1 | 486 | 2048 | | ||||
| secp256r1 | 459 | 2048 | | ||||
| secp384r1 | 811 | 7680 | | ||||
| secp521r1 | 1602 | 15360 | | ||||
+------------------+---------------------+--------------------------+ | ||||
ECDSA signature performance with ARM mbed TLS stack on ST Nucleo F091 | ||||
(STM32F091RCT6) | ||||
Table 8 | ||||
The authors also measured the RAM consumption by calculating the heap | ||||
consumed for the cryptographic operations using a custom memory | ||||
allocation handler. The authors did not measure the minimal stack | ||||
memory consumption. Depending on the curve and the different | ||||
optimizations enable or disabled, the memory consumption for the | ||||
ECDSA sign operation varied from 1500 bytes to 15000 bytes. | ||||
At the time of performing these measurements and study, it was | At the time of performing these measurements and study, it was | |||
unclear which exact elliptic curve(s) would be selected by the IETF | unclear which exact elliptic curve(s) would be selected by the IETF | |||
community for use with resource-constrained devices. However now, | community for use with resource-constrained devices. However now, | |||
[RFC7748] defines two elliptic curves over prime fields (Curve25519 | [RFC7748] defines two elliptic curves over prime fields (Curve25519 | |||
and Curve448) that offer a high level of practical security for | and Curve448) that offer a high level of practical security for | |||
Diffie-Hellman key exchange. Correspondingly, there is ongoing work | Diffie-Hellman key exchange. Correspondingly, there is ongoing work | |||
to specify elliptic curve signature schemes with Edwards-curve | to specify elliptic curve signature schemes with Edwards-curve | |||
Digital Signature Algorithm (EdDSA). [RFC8032] specifies the | Digital Signature Algorithm (EdDSA). [RFC8032] specifies the | |||
recommended parameters for the edwards25519 and edwards448 curves. | recommended parameters for the edwards25519 and edwards448 curves. | |||
From these, curve25519 (for elliptic curve Diffie-Hellman key | From these, curve25519 (for elliptic curve Diffie-Hellman key | |||
skipping to change at page 17, line 20 ¶ | skipping to change at page 17, line 10 ¶ | |||
also show that signing of data using the curve Ed25519 from the NaCl | also show that signing of data using the curve Ed25519 from the NaCl | |||
library needs only 23,216,241 cycles on the same microcontroller that | library needs only 23,216,241 cycles on the same microcontroller that | |||
we used for our evaluations (Arduino Mega ATmega2560). This | we used for our evaluations (Arduino Mega ATmega2560). This | |||
corresponds to about 14510 milliseconds of execution time. When | corresponds to about 14510 milliseconds of execution time. When | |||
compared to the results for other curves and libraries that offer | compared to the results for other curves and libraries that offer | |||
similar level of security (such as NIST B233, NIST K233), this | similar level of security (such as NIST B233, NIST K233), this | |||
implementation far outperforms all others. As such, it is recommend | implementation far outperforms all others. As such, it is recommend | |||
that the IETF community uses these curves for protocol specification | that the IETF community uses these curves for protocol specification | |||
and implementations. | and implementations. | |||
A summary library ROM use is shown in Table 7. | A summary library flash memory use is shown in Table 9. | |||
+------------------------+---------------------------+ | +------------------------+------------------------------------+ | |||
| Library | ROM Footprint (Kilobytes) | | | Library | Flash memory Footprint (Kilobytes) | | |||
+------------------------+---------------------------+ | +------------------------+------------------------------------+ | |||
| AvrCryptolib | 3.6 | | | AvrCryptolib | 3.6 | | |||
| Wiselib | 16 | | | Wiselib | 16 | | |||
| TinyECC | 18 | | | TinyECC | 18 | | |||
| Relic-toolkit | 29 | | | Relic-toolkit | 29 | | |||
| NaCl Ed25519 [naclavr] | 17-29 | | | NaCl Ed25519 [naclavr] | 17-29 | | |||
+------------------------+---------------------------+ | +------------------------+------------------------------------+ | |||
Summary of library ROM needs | Summary of library flash memory consumption | |||
Table 7 | Table 9 | |||
All the measurements here are only provided as an example to show | All the measurements here are only provided as an example to show | |||
that asymmetric-key cryptography (particularly, digital signatures) | that asymmetric-key cryptography (particularly, digital signatures) | |||
is possible on resource-constrained devices. These numbers by no way | is possible on resource-constrained devices. These numbers by no way | |||
are the final source for measurements and some curves presented here | are the final source for measurements and some curves presented here | |||
may not be acceptable for real in-the-wild deployments anymore. For | may not be acceptable for real in-the-wild deployments anymore. For | |||
example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also | example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also | |||
document performance of ECDSA on similar resource-constrained | document performance of ECDSA on similar resource-constrained | |||
devices. | devices. | |||
skipping to change at page 18, line 27 ¶ | skipping to change at page 18, line 17 ¶ | |||
The only role that the sensor has is to register itself at the | The only role that the sensor has is to register itself at the | |||
publish-subscribe broker, and periodically update the readings. All | publish-subscribe broker, and periodically update the readings. All | |||
queries from the rest of the world go to the publish-subscribe | queries from the rest of the world go to the publish-subscribe | |||
broker. | broker. | |||
We constructed a system with four entities: | We constructed a system with four entities: | |||
Sensor | Sensor | |||
This is an Arduino-based device that runs a CoAP publish-subscribe | This is an Arduino-based device that runs a CoAP publish-subscribe | |||
broker client and Relic-toolkit. Relic takes 29 Kbytes of ROM, | broker client and Relic-toolkit. Relic takes 29 Kbytes of flash | |||
and the simple CoAP client roughly 3 kilobytes. | memory, and the simple CoAP client roughly 3 kilobytes. | |||
Publish-Subscribe Broker | Publish-Subscribe Broker | |||
This is a publish-subscribe broker that holds resources on the | This is a publish-subscribe broker that holds resources on the | |||
sensor's behalf. The sensor registers itself to this node. | sensor's behalf. The sensor registers itself to this node. | |||
Resource Directory | Resource Directory | |||
While physically in the same node in our implementation, a | While physically in the same node in our implementation, a | |||
resource directory is a logical function that allows sensors and | resource directory is a logical function that allows sensors and | |||
skipping to change at page 19, line 11 ¶ | skipping to change at page 18, line 49 ¶ | |||
The security of this system relies on an SSH-like approach. In Step | The security of this system relies on an SSH-like approach. In Step | |||
1, upon first boot, sensors generate keys and register themselves in | 1, upon first boot, sensors generate keys and register themselves in | |||
the publish-subscribe broker. Their public key is submitted along | the publish-subscribe broker. Their public key is submitted along | |||
with the registration as an attribute in the CORE Link Format data | with the registration as an attribute in the CORE Link Format data | |||
[RFC6690]. | [RFC6690]. | |||
In Step 2, when the sensor makes a measurement, it sends an update to | In Step 2, when the sensor makes a measurement, it sends an update to | |||
the publish-subscribe broker and signs the message contents with a | the publish-subscribe broker and signs the message contents with a | |||
JOSE signature on the used JSON/SENML payload [RFC7515] | JOSE signature on the used JSON/SENML payload [RFC7515] | |||
[I-D.ietf-core-senml]. The sensor can also alternatively use CBOR | [I-D.ietf-core-senml]. The sensor can also alternatively use CBOR | |||
Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] for signing | Object Signing and Encryption (COSE) [RFC8152] for signing the sensor | |||
the sensor measurement. | measurement. | |||
In Step 3, any other device in the network -- including the publish- | In Step 3, any other device in the network -- including the publish- | |||
subscribe broker, resource directory and the application -- can check | subscribe broker, resource directory and the application -- can check | |||
that the public key from the registration corresponds to the private | that the public key from the registration corresponds to the private | |||
key used to make the signature in the data update. | key used to make the signature in the data update. | |||
Note that checks can be done at any time and there is no need for the | Note that checks can be done at any time and there is no need for the | |||
sensor and the checking node to be awake at the same time. In our | sensor and the checking node to be awake at the same time. In our | |||
implementation, the checking is done in the application node. This | implementation, the checking is done in the application node. This | |||
demonstrates how it is possible to implement end-to-end security even | demonstrates how it is possible to implement end-to-end security even | |||
skipping to change at page 19, line 38 ¶ | skipping to change at page 19, line 29 ¶ | |||
implementation uses the standard C99 programming language on the | implementation uses the standard C99 programming language on the | |||
Arduino Mega board. In this prototype, the publish-subscribe broker | Arduino Mega board. In this prototype, the publish-subscribe broker | |||
and the Resource Directory (RD) reside on the same physical host. A | and the Resource Directory (RD) reside on the same physical host. A | |||
64-bit x86 linux machine serves as the broker and the RD, while a | 64-bit x86 linux machine serves as the broker and the RD, while a | |||
similar but physically different 64-bit x86 linux machine serves as | similar but physically different 64-bit x86 linux machine serves as | |||
the client that requests data from the sensor. We chose the Relic | the client that requests data from the sensor. We chose the Relic | |||
library version 0.3.1 for our sample prototype as it can be easily | library version 0.3.1 for our sample prototype as it can be easily | |||
compiled for different bit-length processors. Therefore, we were | compiled for different bit-length processors. Therefore, we were | |||
able to use it on the 8-bit processor of the Arduino Mega, as well as | able to use it on the 8-bit processor of the Arduino Mega, as well as | |||
on the 64-bit processor of the x86 client. We used ECDSA to sign and | on the 64-bit processor of the x86 client. We used ECDSA to sign and | |||
verify data updates with the standard NIST-K163 curve parameters | verify data updates with the standard NIST-K163 curve parameters. | |||
(163-bit Koblitz curve over binary field). While compiling Relic for | While compiling Relic for our prototype, we used the fast | |||
our prototype, we used the fast configuration without any assembly | configuration without any assembly optimizations. | |||
optimizations. | ||||
The gateway implements the CoAP base specification in the Java | The gateway implements the CoAP base specification in the Java | |||
programming language and extends it to add support for publish- | programming language and extends it to add support for publish- | |||
subscribe broker and Resource Directory REST interfaces. We also | subscribe broker and Resource Directory REST interfaces. We also | |||
developed a minimalistic CoAP C-library for the Arduino sensor and | developed a minimalistic CoAP C-library for the Arduino sensor and | |||
for the client requesting data updates for a resource. The library | for the client requesting data updates for a resource. The library | |||
has small SRAM requirements and uses stack-based allocation only. It | has small RAM requirements and uses stack-based allocation only. It | |||
is interoperable with the Java implementation of CoAP running on the | is interoperable with the Java implementation of CoAP running on the | |||
gateway. The location of the publish-subscribe broker was configured | gateway. The location of the publish-subscribe broker was configured | |||
into the smart object sensor by hardcoding the IP address. We used | into the smart object sensor by hardcoding the IP address. | |||
an IPv4 network with public IP addresses obtained from a DHCP server. | ||||
Some important statistics of this prototype are listed in table | Our intention was to demonstrate that it is possible to implement the | |||
Table 8. Our straw man analysis of the performance of this prototype | entire architecture with public-key cryptography on an 8-bit | |||
is preliminary. Our intention was to demonstrate the feasibility of | ||||
the entire architecture with public-key cryptography on an 8-bit | ||||
microcontroller. The stated values can be improved further by a | microcontroller. The stated values can be improved further by a | |||
considerable amount. For example, the flash memory and SRAM | considerable amount. For example, the flash memory and RAM | |||
consumption is relatively high because some of the Arduino libraries | consumption is relatively high because some of the Arduino libraries | |||
were used out-of-the-box and there are several functions which can be | were used out-of-the-box and there are several functions which can be | |||
removed. Similarly we used the fast version of the Relic library in | removed. Similarly we used the fast version of the Relic library in | |||
the prototype instead of the low memory version. | the prototype instead of the low memory version. However, it is | |||
important to note that this was only a research prototype to verify | ||||
+-----------------------------------------------------------+-------+ | the feasibility of this architecture and as stated elsewhere, most | |||
| Flash memory consumption (for the entire prototype | 51 kB | | modern development boards have a 32-bit microcontroller since they | |||
| including Relic library + CoAP + Arduino UDP) | | | are more economical and have better energy efficiency. | |||
| | | | ||||
| SRAM consumption (for the entire prototype including key | 4678 | | ||||
| generation + signing the hash of message + COAP + UDP + | bytes | | ||||
| Ethernet) | | | ||||
| | | | ||||
| Execution time for creating the key pair + sending | 2030 | | ||||
| registration message + time spent waiting for | ms | | ||||
| acknowledgement | | | ||||
| | | | ||||
| Execution time for signing the hash of message + sending | 987 | | ||||
| update | ms | | ||||
| | | | ||||
| Signature overhead | 42 | | ||||
| | bytes | | ||||
+-----------------------------------------------------------+-------+ | ||||
Prototype Performance | ||||
Table 8 | ||||
To demonstrate the efficacy of this communication model we compare it | ||||
with a scenario where the smart objects do not transition into the | ||||
energy saving sleep mode and directly serve temperature data to | ||||
clients. As an example, we assume that in our architecture, the | ||||
smart objects wake up once every minute to report the signed | ||||
temperature data to the caching broker. If we calculate the energy | ||||
consumption using the formula W = U * I * t (where U is the operating | ||||
voltage, I is the current drawn and t is the execution time), and use | ||||
the voltage and current values from the datasheets of the ATmega2560 | ||||
(20mA-active mode and 5.4mA-sleep mode) and W5100 (183mA) chips used | ||||
in the architecture, then in a one minute period, the Arduino board | ||||
would consume 60.9 Joules of energy if it directly serves data and | ||||
does not sleep. On the other hand, in our architecture it would only | ||||
consume 2.6 Joules if it wakes up once a minute to update the broker | ||||
with signed data. Therefore, a typical Li-ion battery that provides | ||||
about 1800 milliamps per hour (mAh) at 5V would have a lifetime of 9 | ||||
hours in the unsecured always-on scenario, whereas it would have a | ||||
lifetime of about 8.5 days in the secured sleepy architecture | ||||
presented. These lifetimes appear to be low because the Arduino | ||||
board in the prototype uses Ethernet which is not energy efficient. | ||||
The values presented only provide an estimate (ignoring the energy | ||||
required to transition in and out of the sleep mode) and would vary | ||||
depending on the hardware and MAC protocol used. Nonetheless, it is | ||||
evident that our architecture can increase the life of smart objects | ||||
by allowing them to sleep and can ensure security at the same time. | ||||
10. Design Trade-Offs | 10. Design Trade-Offs | |||
This section attempts to make some early conclusions regarding trade- | This section attempts to make some early conclusions regarding trade- | |||
offs in the design space, based on deployment considerations for | offs in the design space, based on deployment considerations for | |||
various mechanisms and the relative ease or difficulty of | various mechanisms and the relative ease or difficulty of | |||
implementing them. This analysis looks at layering and the choice of | implementing them. This analysis looks at layering and the choice of | |||
symmetric vs. asymmetric cryptography. | symmetric vs. asymmetric cryptography. | |||
11. Feasibility | 11. Feasibility | |||
skipping to change at page 21, line 39 ¶ | skipping to change at page 20, line 27 ¶ | |||
The first question is whether using cryptographic security and | The first question is whether using cryptographic security and | |||
asymmetric cryptography in particular is feasible at all on small | asymmetric cryptography in particular is feasible at all on small | |||
devices. The numbers above give a mixed message. Clearly, an | devices. The numbers above give a mixed message. Clearly, an | |||
implementation of a significant cryptographic operation such as | implementation of a significant cryptographic operation such as | |||
public key signing can be done in surprisingly small amount of code | public key signing can be done in surprisingly small amount of code | |||
space. It could even be argued that our chosen prototype platform | space. It could even be argued that our chosen prototype platform | |||
was unnecessarily restrictive in the amount of code space it allows: | was unnecessarily restrictive in the amount of code space it allows: | |||
we chose this platform on purpose to demonstrate something that is as | we chose this platform on purpose to demonstrate something that is as | |||
small and difficult as possible. | small and difficult as possible. | |||
In reality, ROM memory size is probably easier to grow than other | A recent trend in microcontrollers is the introduction of 32-bit CPUs | |||
parameters in microcontrollers. A recent trend in microcontrollers | that are becoming cheaper and more easily available than 8-bit CPUs, | |||
is the introduction of 32-bit CPUs that are becoming cheaper and more | in addition to being more easily programmable. The flash memory size | |||
easily available than 8-bit CPUs, in addition to being more easily | is probably easier to grow than other parameters in microcontrollers. | |||
programmable. In short, the authors do not expect the code size to | The authors do not expect the flash memory size to be the most | |||
be a significant limiting factor, both because of the small amount of | significant limiting factor. Before picking a platform, developers | |||
code that is needed and because available memory space is growing | should also plan for firmware updates. This would essentially mean | |||
rapidly. | that the platform should at least have a flash memory size of the | |||
total code size * 2, plus some space for buffer. | ||||
The situation is less clear with regards to the amount of CPU power | The situation is less clear with regards to the amount of CPU power | |||
needed to run the algorithms. The demonstrated speeds are sufficient | needed to run the algorithms. The demonstrated speeds are sufficient | |||
for many applications. For instance, a sensor that wakes up every | for many applications. For instance, a sensor that wakes up every | |||
now and then can likely spend a fraction of a second for the | 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. | computation of a signature for the message that it is about to send. | |||
Or even spend multiple seconds in some cases. Most applications that | Or even spend multiple seconds in some cases. Most applications that | |||
use protocols such as DTLS that use public key cryptography only at | 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 | the beginning of the session would also be fine with any of these | |||
execution times. | execution times. | |||
skipping to change at page 26, line 28 ¶ | skipping to change at page 25, line 18 ¶ | |||
sufficient advantages over the more commonly implemented transport | sufficient advantages over the more commonly implemented transport | |||
and application layer solutions. | and application layer solutions. | |||
14. Symmetric vs. Asymmetric Crypto | 14. Symmetric vs. Asymmetric Crypto | |||
The second trade-off that is worth discussing is the use of plain | The second trade-off that is worth discussing is the use of plain | |||
asymmetric cryptographic mechanisms, plain symmetric cryptographic | asymmetric cryptographic mechanisms, plain symmetric cryptographic | |||
mechanisms, or some mixture thereof. | mechanisms, or some mixture thereof. | |||
Contrary to popular cryptographic community beliefs, a symmetric | Contrary to popular cryptographic community beliefs, a symmetric | |||
crypto solution can be deployed in large scale. In fact, one of the | cryptographic solution can be deployed in large scale. In fact, one | |||
largest deployment of cryptographic security, the cellular network | of the largest deployment of cryptographic security, the cellular | |||
authentication system, uses SIM cards that are based on symmetric | network authentication system, uses SIM cards that are based on | |||
secrets. In contrast, public key systems have yet to show ability to | symmetric secrets. In contrast, public key systems have yet to show | |||
scale to hundreds of millions of devices, let alone billions. But | ability to scale to hundreds of millions of devices, let alone | |||
the authors do not believe scaling is an important differentiator | billions. But the authors do not believe scaling is an important | |||
when comparing the solutions. | differentiator when comparing the solutions. | |||
As can be seen from the Section 8, the time needed to calculate some | As can be seen from the Section 8, the time needed to calculate some | |||
of the asymmetric crypto operations with reasonable key lengths can | of the asymmetric cryptographic operations with reasonable key | |||
be significant. There are two contrary observations that can be made | lengths can be significant. There are two contrary observations that | |||
from this. First, recent wisdom indicates that computing power on | can be made from this. First, recent wisdom indicates that computing | |||
small devices is far cheaper than transmission power [wiman], and | power on small devices is far cheaper than transmission power | |||
keeps on becoming more efficient very quickly. From this we can | [wiman], and keeps on becoming more efficient very quickly. From | |||
conclude that the sufficient CPU is or at least will be easily | this we can conclude that the sufficient CPU is or at least will be | |||
available. | easily available. | |||
But the other observation is that when there are very costly | But the other observation is that when there are very costly | |||
asymmetric operations, doing a key exchange followed by the use of | asymmetric operations, doing a key exchange followed by the use of | |||
generated symmetric keys would make sense. This model works very | generated symmetric keys would make sense. This model works very | |||
well for DTLS and other transport layer solutions, but works less | well for DTLS and other transport layer solutions, but works less | |||
well for data object security, particularly when the number of | well for data object security, particularly when the number of | |||
communicating entities is not exactly two. | communicating entities is not exactly two. | |||
15. Security Considerations | 15. Security Considerations | |||
skipping to change at page 27, line 19 ¶ | skipping to change at page 26, line 11 ¶ | |||
16. IANA Considerations | 16. IANA Considerations | |||
There are no IANA impacts in this memo. | There are no IANA impacts in this memo. | |||
17. Informative references | 17. Informative references | |||
[arduino-uno] | [arduino-uno] | |||
Arduino, "Arduino Uno", September 2015, | Arduino, "Arduino Uno", September 2015, | |||
<http://arduino.cc/en/Main/arduinoBoardUno>. | <http://arduino.cc/en/Main/arduinoBoardUno>. | |||
[armecdsa] | ||||
Tschofenig, H. and M. Pegourie-Gonnard, "Performance | ||||
Investigations", March 2015, | ||||
<https://www.ietf.org/proceedings/92/slides/slides-92- | ||||
lwig-3.pdf>. | ||||
[avr-crypto-lib] | [avr-crypto-lib] | |||
AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, | AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, | |||
<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. | <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. | |||
[avr-cryptolib] | [avr-cryptolib] | |||
Van der Laan, E., "AVR CRYPTOLIB", September 2015, | Van der Laan, E., "AVR CRYPTOLIB", September 2015, | |||
<http://www.emsign.nl/>. | <http://www.emsign.nl/>. | |||
[avrora] Titzer, Ben., "Avrora", September 2015, | [avrora] Titzer, Ben., "Avrora", September 2015, | |||
<http://compilers.cs.ucla.edu/avrora/>. | <http://compilers.cs.ucla.edu/avrora/>. | |||
[freescale] | ||||
NXP, "Freescale FRDM-KL25Z", June 2017, | ||||
<https://developer.mbed.org/platforms/KL25Z/>. | ||||
[huang] Huang, C., "Low-overhead freshness transmission in sensor | [huang] Huang, C., "Low-overhead freshness transmission in sensor | |||
networks", 2008. | networks", 2008. | |||
[I-D.arkko-core-security-arch] | [I-D.arkko-core-security-arch] | |||
Arkko, J. and A. Keranen, "CoAP Security Architecture", | Arkko, J. and A. Keranen, "CoAP Security Architecture", | |||
draft-arkko-core-security-arch-00 (work in progress), July | draft-arkko-core-security-arch-00 (work in progress), July | |||
2011. | 2011. | |||
[I-D.arkko-core-sleepy-sensors] | [I-D.arkko-core-sleepy-sensors] | |||
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. | Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. | |||
skipping to change at page 28, line 8 ¶ | skipping to change at page 27, line 8 ¶ | |||
[I-D.daniel-6lowpan-security-analysis] | [I-D.daniel-6lowpan-security-analysis] | |||
Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. | Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. | |||
Laganier, "IPv6 over Low Power WPAN Security Analysis", | Laganier, "IPv6 over Low Power WPAN Security Analysis", | |||
draft-daniel-6lowpan-security-analysis-05 (work in | draft-daniel-6lowpan-security-analysis-05 (work in | |||
progress), March 2011. | progress), March 2011. | |||
[I-D.ietf-core-coap-pubsub] | [I-D.ietf-core-coap-pubsub] | |||
Koster, M., Keranen, A., and J. Jimenez, "Publish- | Koster, M., Keranen, A., and J. Jimenez, "Publish- | |||
Subscribe Broker for the Constrained Application Protocol | Subscribe Broker for the Constrained Application Protocol | |||
(CoAP)", draft-ietf-core-coap-pubsub-00 (work in | (CoAP)", draft-ietf-core-coap-pubsub-02 (work in | |||
progress), October 2016. | progress), July 2017. | |||
[I-D.ietf-core-resource-directory] | [I-D.ietf-core-resource-directory] | |||
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE | Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. | |||
Resource Directory", draft-ietf-core-resource-directory-09 | Amsuess, "CoRE Resource Directory", draft-ietf-core- | |||
(work in progress), October 2016. | resource-directory-11 (work in progress), July 2017. | |||
[I-D.ietf-core-senml] | [I-D.ietf-core-senml] | |||
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. | Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. | |||
Bormann, "Media Types for Sensor Measurement Lists | Bormann, "Media Types for Sensor Measurement Lists | |||
(SenML)", draft-ietf-core-senml-04 (work in progress), | (SenML)", draft-ietf-core-senml-10 (work in progress), | |||
October 2016. | July 2017. | |||
[I-D.ietf-cose-msg] | ||||
Schaad, J., "CBOR Object Signing and Encryption (COSE)", | ||||
draft-ietf-cose-msg-24 (work in progress), November 2016. | ||||
[I-D.irtf-t2trg-iot-seccons] | [I-D.irtf-t2trg-iot-seccons] | |||
Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security | Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- | |||
Considerations in the IP-based Internet of Things", draft- | the-Art and Challenges for the Internet of Things | |||
irtf-t2trg-iot-seccons-00 (work in progress), October | Security", draft-irtf-t2trg-iot-seccons-04 (work in | |||
2016. | progress), June 2017. | |||
[I-D.moskowitz-hip-dex] | [I-D.moskowitz-hip-dex] | |||
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", | Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", | |||
draft-moskowitz-hip-dex-05 (work in progress), January | draft-moskowitz-hip-dex-05 (work in progress), January | |||
2016. | 2016. | |||
[I-D.sarikaya-t2trg-sbootstrapping] | [I-D.sarikaya-t2trg-sbootstrapping] | |||
Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT | Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT | |||
Bootstrapping: A Survey", draft-sarikaya-t2trg- | Bootstrapping: A Survey", draft-sarikaya-t2trg- | |||
sbootstrapping-03 (work in progress), February 2017. | sbootstrapping-03 (work in progress), February 2017. | |||
[matrix-ssl] | [matrix-ssl] | |||
PeerSec Networks, "Matrix SSL", September 2015, | PeerSec Networks, "Matrix SSL", September 2015, | |||
<http://www.matrixssl.org/>. | <http://www.matrixssl.org/>. | |||
[mbed] ARM, "mbed TLS", May 2017, | ||||
<https://www.mbed.com/en/technologies/security/mbed-tls/>. | ||||
[micronacl] | [micronacl] | |||
MicroNaCl, "The Networking and Cryptography library for | MicroNaCl, "The Networking and Cryptography library for | |||
microcontrollers", <http://munacl.cryptojedi.org/>. | microcontrollers", <http://munacl.cryptojedi.org/>. | |||
[mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic | [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic | |||
curve cryptography for 8 bit and 32 bit embedded systems | curve cryptography for 8 bit and 32 bit embedded systems | |||
time efficiency and power consumption analysis", Pomiary | time efficiency and power consumption analysis", Pomiary | |||
Automatyka Kontrola , 2010. | Automatyka Kontrola , 2010. | |||
[nacl] NaCl, "Networking and Cryptography library", | [nacl] NaCl, "Networking and Cryptography library", | |||
<http://nacl.cr.yp.to/>. | <http://nacl.cr.yp.to/>. | |||
[naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR | [naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR | |||
Microcontrollers", International Conference on Cryptology | Microcontrollers", International Conference on Cryptology | |||
in Africa , Springer Berlin Heidelberg , 2013. | in Africa , Springer Berlin Heidelberg , 2013. | |||
[nordic] Nordic Semiconductor, "nRF52832 Product Specification", | ||||
June 2017, <http://infocenter.nordicsemi.com/pdf/ | ||||
nRF52832_PS_v1.3.pdf>. | ||||
[relic-toolkit] | [relic-toolkit] | |||
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, | Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, | |||
<http://code.google.com/p/relic-toolkit/>. | <http://code.google.com/p/relic-toolkit/>. | |||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |||
Levkowetz, Ed., "Extensible Authentication Protocol | Levkowetz, Ed., "Extensible Authentication Protocol | |||
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | |||
<http://www.rfc-editor.org/info/rfc3748>. | <http://www.rfc-editor.org/info/rfc3748>. | |||
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", | [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", | |||
skipping to change at page 30, line 22 ¶ | skipping to change at page 29, line 22 ¶ | |||
January 2012, <http://www.rfc-editor.org/info/rfc6347>. | January 2012, <http://www.rfc-editor.org/info/rfc6347>. | |||
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object | [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object | |||
Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, | Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, | |||
<http://www.rfc-editor.org/info/rfc6574>. | <http://www.rfc-editor.org/info/rfc6574>. | |||
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
<http://www.rfc-editor.org/info/rfc6690>. | <http://www.rfc-editor.org/info/rfc6690>. | |||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | ||||
Protocol (HTTP/1.1): Message Syntax and Routing", | ||||
RFC 7230, DOI 10.17487/RFC7230, June 2014, | ||||
<http://www.rfc-editor.org/info/rfc7230>. | ||||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7252>. | <http://www.rfc-editor.org/info/rfc7252>. | |||
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | |||
2014, <http://www.rfc-editor.org/info/rfc7296>. | 2014, <http://www.rfc-editor.org/info/rfc7296>. | |||
skipping to change at page 31, line 10 ¶ | skipping to change at page 30, line 15 ¶ | |||
[RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 | [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 | |||
(IKEv2) Initiator Implementation", RFC 7815, | (IKEv2) Initiator Implementation", RFC 7815, | |||
DOI 10.17487/RFC7815, March 2016, | DOI 10.17487/RFC7815, March 2016, | |||
<http://www.rfc-editor.org/info/rfc7815>. | <http://www.rfc-editor.org/info/rfc7815>. | |||
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | |||
Signature Algorithm (EdDSA)", RFC 8032, | Signature Algorithm (EdDSA)", RFC 8032, | |||
DOI 10.17487/RFC8032, January 2017, | DOI 10.17487/RFC8032, January 2017, | |||
<http://www.rfc-editor.org/info/rfc8032>. | <http://www.rfc-editor.org/info/rfc8032>. | |||
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | ||||
RFC 8152, DOI 10.17487/RFC8152, July 2017, | ||||
<http://www.rfc-editor.org/info/rfc8152>. | ||||
[rsa-8bit] | [rsa-8bit] | |||
Gura, N., Patel, A., Wander, A., Eberle, H., and S. | Gura, N., Patel, A., Wander, A., Eberle, H., and S. | |||
Shantz, "Comparing Elliptic Curve Cryptography and RSA on | Shantz, "Comparing Elliptic Curve Cryptography and RSA on | |||
8-bit CPUs", 2010. | 8-bit CPUs", 2010. | |||
[rsa-high-speed] | [rsa-high-speed] | |||
Koc, C., "High-Speed RSA Implementation", November 1994, | Koc, C., "High-Speed RSA Implementation", November 1994, | |||
<http://cs.ucsb.edu/~koc/docs/r01.pdf>. | <http://cs.ucsb.edu/~koc/docs/r01.pdf>. | |||
[stnucleo] | ||||
STMicroelectronics, "NUCLEO-F091RC", June 2017, | ||||
<http://www.st.com/en/evaluation-tools/ | ||||
nucleo-f091rc.html/>. | ||||
[tinyecc] North Carolina State University and North Carolina State | [tinyecc] North Carolina State University and North Carolina State | |||
University, "TinyECC", 2008, | University, "TinyECC", 2008, | |||
<http://discovery.csc.ncsu.edu/software/TinyECC/>. | <http://discovery.csc.ncsu.edu/software/TinyECC/>. | |||
[truerandom] | ||||
Drow, C., "Truerandom", September 2015, | ||||
<http://code.google.com/p/tinkerit/wiki/TrueRandom>. | ||||
[wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, | [wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, | |||
S., Carvalho, T., Naslund, M., and R. Gold, "Impact of | S., Carvalho, T., Naslund, M., and R. Gold, "Impact of | |||
Operating Systems on Wireless Sensor Networks (Security) | Operating Systems on Wireless Sensor Networks (Security) | |||
Applications and Testbeds.", International Conference on | Applications and Testbeds.", International Conference on | |||
Computer Communication Networks (ICCCN'2010) / IEEE | Computer Communication Networks (ICCCN'2010) / IEEE | |||
International Workshop on Wireless Mesh and Ad Hoc | International Workshop on Wireless Mesh and Ad Hoc | |||
Networks (WiMAN 2010) , 2010. | Networks (WiMAN 2010) , 2010. | |||
[wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis, | [wiselib] Baumgartner, T., Chatzigiannakis, I., Fekete, S., Koninis, | |||
C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010, | C., Kroller, A., and A. Pyrgelis, "Wiselib", 2010, | |||
End of changes. 65 change blocks. | ||||
318 lines changed or deleted | 290 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |