draft-ietf-lwig-crypto-sensors-01.txt | draft-ietf-lwig-crypto-sensors-02.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: May 4, 2017 Ericsson | Expires: August 14, 2017 Ericsson | |||
H. Back | H. Back | |||
Comptel | Comptel | |||
October 31, 2016 | February 10, 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-01 | draft-ietf-lwig-crypto-sensors-02 | |||
Abstract | Abstract | |||
This memo describes challenges associated with securing smart object | This memo describes challenges associated with securing smart object | |||
devices in constrained implementations and environments. The memo | devices in constrained implementations and environments. The memo | |||
describes a possible deployment model suitable for these | describes a possible deployment model suitable for these | |||
environments, discusses the availability of cryptographic libraries | environments, discusses the availability of cryptographic libraries | |||
for small devices, presents some preliminary experiences in | for small devices, presents some preliminary experiences in | |||
implementing small devices using those libraries, and discusses | implementing cryptography on small devices using those libraries, and | |||
trade-offs involving different types of approaches. | discusses trade-offs involving different types of 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 May 4, 2017. | This Internet-Draft will expire on August 14, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
skipping to change at page 2, line 27 ¶ | skipping to change at page 2, line 27 ¶ | |||
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 . . . . . . . . . . . . . . . . . 11 | |||
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 | 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 | 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21 | |||
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 | 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | 15. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 | 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
17. Informative references . . . . . . . . . . . . . . . . . . . 26 | 17. Informative references . . . . . . . . . . . . . . . . . . . 27 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
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 | Secondly, 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. | |||
skipping to change at page 3, line 25 ¶ | skipping to change at page 3, line 25 ¶ | |||
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 in | |||
verifying the server identity, in practice the models are quite | verifying the server identity, in practice the models are quite | |||
different. The CoAP specification says little about how DTLS keys | different. The CoAP specification says little about how DTLS keys | |||
are managed. 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. | |||
[I-D.moskowitz-hip-dex] defines a light-weight version of the HIP | [I-D.moskowitz-hip-dex] defines a light-weight version of the HIP | |||
protocol for low-power nodes. This version uses a fixed set of | protocol for low-power nodes. This version uses a fixed set of | |||
algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash | algorithms, Elliptic Curve Cryptography (ECC), and eliminates hash | |||
functions. The protocol still operates based on host identities, and | functions. The protocol still operates based on host identities, and | |||
runs end-to-end between hosts, protecting IP layer communications. | runs end-to-end between hosts, protecting all IP layer | |||
[RFC6078] describes an extension of HIP that can be used to send | communications. [RFC6078] describes an extension of HIP that can be | |||
upper layer protocol messages without running the usual HIP base | used to send upper layer protocol messages without running the usual | |||
exchange at all. | HIP base exchange at all. | |||
[I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis | [I-D.daniel-6lowpan-security-analysis] makes a comprehensive analysis | |||
of security issues related to 6LoWPAN networks, but its findings also | of security issues related to 6LoWPAN networks, but its findings also | |||
apply more generally for all low-powered networks. Some of the | apply more generally for all low-powered networks. Some of the | |||
issues this document discusses include the need to minimize the | issues this document discusses include the need to minimize the | |||
number of transmitted bits and simplify implementations, threats in | number of transmitted bits and simplify implementations, threats in | |||
the smart object networking environments, and the suitability of | the smart object networking environments, and the suitability of | |||
6LoWPAN security mechanisms, IPsec, and key management protocols for | 6LoWPAN security mechanisms, IPsec, and key management protocols for | |||
implementation in these environments. | implementation in these environments. | |||
[I-D.irtf-t2trg-iot-seccons] discusses the overall security problem | [I-D.irtf-t2trg-iot-seccons] discusses the overall security problem | |||
for Internet of Things devices. It also discusses various solutions, | for Internet of Things devices. It also discusses various solutions, | |||
including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], | including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], | |||
HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP | HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP | |||
[RFC3748]. The draft also discusses various operational scenarios, | [RFC3748]. The draft also discusses various operational scenarios, | |||
bootstrapping mechanisms, and challenges associated with implementing | and challenges associated with implementing security mechanisms in | |||
security mechanisms in these environments. | these environments. | |||
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping | ||||
mechanisms available for resource-constrained IoT devices. | ||||
3. Challenges | 3. Challenges | |||
This section discusses three challenges: implementation difficulties, | This section discusses three challenges: 1) implementation | |||
practical provisioning problems, and layering and communication | difficulties, 2) practical provisioning problems, 3) layering and | |||
models. | communication models. | |||
The most often discussed issues in the security for the Internet of | One of the most often discussed issues in the security for the | |||
Things relate to implementation difficulties. The desire to build | Internet of Things relate to implementation difficulties. The desire | |||
small, battery-operated, and inexpensive devices drives the creation | to build small, battery-operated, and inexpensive devices drives the | |||
of devices with a limited protocol and application suite. Some of | creation of devices with a limited protocol and application suite. | |||
the typical limitations include running CoAP instead of HTTP, limited | Some of the typical limitations include running CoAP instead of HTTP, | |||
support for security mechanisms, limited processing power for long | limited support for security mechanisms, limited processing power for | |||
key lengths, sleep schedule that does not allow communication at all | long key lengths, sleep schedule that does not allow communication at | |||
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. Also, the use of the most | |||
lightweight algorithms and cryptographic primitives is useful, but | lightweight algorithms and cryptographic primitives is useful, but | |||
should not be the only consideration in the design. Interoperability | should not be the only consideration in the design. Interoperability | |||
skipping to change at page 6, line 23 ¶ | skipping to change at page 6, line 23 ¶ | |||
then commence with the devices, at least as far as information from | 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 | from the devices to the server is concerned, which is what is needed | |||
for sensor networks. | for sensor networks. | |||
The above architecture is a perfect fit for sensor networks where | The above architecture is a perfect fit for sensor networks where | |||
information flows from large number of devices to small number of | information flows from large number of devices to small number of | |||
servers. But it is not sufficient alone for other types of | servers. But it is not sufficient alone for other types of | |||
applications. For instance, in actuator applications a large number | applications. For instance, in actuator applications a large number | |||
of devices need to take commands from somewhere else. In such | of devices need to take commands from somewhere else. In such | |||
applications it is necessary to secure that the commands come from an | applications it is necessary to secure that the commands come from an | |||
authorized source. This can be supported, with some additional | authorized source. | |||
provisioning effort and optional pairing protocols. The basic | ||||
provisioning approach is as described earlier, but in addition there | This can be supported, with some additional provisioning effort and | |||
must be something that informs the devices of the identity of the | optional pairing protocols. The basic provisioning approach is as | |||
trusted server(s). There are multiple ways to provide this | described earlier, but in addition there must be something that | |||
information. One simple approach is to feed the identities of the | informs the devices of the identity of the trusted server(s). There | |||
trusted server(s) to devices at installation time. This requires | are multiple ways to provide this information. One simple approach | |||
either a separate user interface, local connection (such as USB), or | is to feed the identities of the trusted server(s) to devices at | |||
using the network interface of the device for configuration. In any | installation time. This requires either a separate user interface, | |||
case, as with sensor networks the amount of configuration information | local connection (such as USB), or using the network interface of the | |||
is minimized: just one short identity value needs to be fed in. Not | device for configuration. In any case, as with sensor networks the | |||
both an identity and a certificate. Not shared secrets that must be | amount of configuration information is minimized: just one short | |||
kept confidential. An even simpler provisioning approach is that the | identity value needs to be fed in. Not both an identity and a | |||
devices in the device group trust each other. Then no configuration | certificate. Not shared secrets that must be kept confidential. An | |||
is needed at installation time. When both peers know the expected | even simpler provisioning approach is that the devices in the device | |||
cryptographic identity of the other peer off-line, secure | group trust each other. Then no configuration is needed at | |||
communications can commence. Alternatively, various pairing schemes | installation time. | |||
can be employed. Note that these schemes can benefit from the | ||||
already secure identifiers on the device side. For instance, the | When both peers know the expected cryptographic identity of the other | |||
server can send a pairing message to each device after their initial | peer off-line, secure communications can commence. Alternatively, | |||
power-on and before they have been paired with anyone, encrypted with | various pairing schemes can be employed. Note that these schemes can | |||
the public key of the device. As with all pairing schemes that do | benefit from the already secure identifiers on the device side. For | |||
not employ a shared secret or the secure dentity of both parties, | instance, the server can send a pairing message to each device after | |||
there are some remaining vulnerabilities that may or may not be | their initial power-on and before they have been paired with anyone, | |||
acceptable for the application in question. In any case, the secure | encrypted with the public key of the device. As with all pairing | |||
identities help again in ensuring that the operations are as simple | schemes that do not employ a shared secret or the secure identity of | |||
as possible. Only identities need to be communicated to the devices, | both parties, there are some remaining vulnerabilities that may or | |||
not certificates, not shared secrets or IPsec policy rules. | may not be acceptable for the application in question. | |||
In any case, the secure identities help again in ensuring that the | ||||
operations are as simple as possible. Only identities need to be | ||||
communicated to the devices, not certificates, not shared secrets or | ||||
e.g. IPsec policy rules. | ||||
Where necessary, the information collected at installation time may | Where necessary, the information collected at installation time may | |||
also include other parameters relevant to the application, such as | also include other parameters relevant to the application, such as | |||
the location or purpose of the devices. This would enable the server | the location or purpose of the devices. This would enable the server | |||
to know, for instance, that a particular device is the temperature | to know, for instance, that a particular device is the temperature | |||
sensor for the kitchen. | sensor for the kitchen. | |||
Collecting the identity information at installation time can be | Collecting the identity information at installation time can be | |||
arranged in a number of ways. The authors have employed a simple but | arranged in a number of ways. The authors have employed a simple but | |||
not completely secure method where the last few digits of the | not completely secure method where the last few digits of the | |||
skipping to change at page 9, line 20 ¶ | skipping to change at page 9, line 28 ¶ | |||
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 SRAM, and 32 kB of | |||
flash memory. | flash memory. | |||
For selecting potential asymmetric cryptographic libraries, we did an | For selecting potential asymmetric cryptographic libraries, we | |||
extensive survey 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. Please verify the numbers before relying | errors, and other mistakes. It is advisable to verify the numbers | |||
on them for building something. No significant effort was done to | before relying on them for building something. No significant effort | |||
optimize ROM memory usage beyond what the libraries provided | was done to optimize ROM memory usage beyond what the libraries | |||
themselves, so those numbers should be taken as upper limits. | provided themselves, so those numbers should be taken as upper | |||
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 and RSA as an | |||
asymmetric key algorithm. We stripped down the library to use | asymmetric key algorithm. We stripped down the library to use | |||
only the required RSA components and used a separate SHA-256 | only the required RSA components and used a separate SHA-256 | |||
implementation from the original AvrCrypto-Lib library | implementation from the original AvrCrypto-Lib library | |||
[avr-crypto-lib]. Parts of SHA-256 and RSA algorithm | [avr-crypto-lib]. Parts of SHA-256 and RSA algorithm | |||
implementations were written in AVR-8 bit assembly language to | implementations were written in AVR-8 bit assembly language to | |||
skipping to change at page 9, line 51 ¶ | skipping to change at page 10, line 12 ¶ | |||
programmer to directly address the flash memory to access constant | programmer to directly address the flash memory to access constant | |||
data which can save the amount of SRAM used during execution. | 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. While building the | |||
library, it is possible to select a variety mathematical | library, it is possible to select a variety of mathematical | |||
optimizations that can be combined to obtain the desired | optimizations that can be combined to obtain the desired | |||
performance (as a general thumb rule, faster implementations | performance (as a general thumb rule, faster implementations | |||
require more SRAM and flash). It includes a multi precision | require more SRAM and flash). It includes a multi precision | |||
integer math module which can be customized to use different bit- | integer math module which can be customized to use different bit- | |||
length words. | 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 C99 | |||
skipping to change at page 10, line 27 ¶ | skipping to change at page 10, line 37 ¶ | |||
Barrett reduction for verification, precomputation, etc. It also | Barrett reduction for verification, precomputation, etc. It also | |||
has one of the smallest memory footprints among the set of | has one of the smallest memory footprints among the set of | |||
Elliptic Curve libraries surveyed so far. However, an advantage | Elliptic Curve libraries surveyed so far. However, an advantage | |||
of Relic over TinyECC is that it can do curves over binary fields | of Relic over TinyECC is that it can do curves over binary fields | |||
in addition to prime 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. The structure of the code is similar | |||
to TinyECC and like TinyECC it implements elliptic curves over | to TinyECC and like TinyECC it implements elliptic curves over | |||
prime fields only. In order to make the code platform | prime fields only. In order to make the code platform | |||
independent, no assembly level optimizations were incorporated. | independent, no assembly level optimizations were incorporated. | |||
skipping to change at page 11, line 6 ¶ | skipping to change at page 11, line 14 ¶ | |||
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). However, the library in the | |||
original form takes about 50 kB of ROM which is not suitable for | original form takes about 50 kB of ROM which is not suitable for | |||
our hardware requirements. Moreover, it is intended for 32-bit | our hardware requirements. Moreover, it is intended for 32-bit | |||
systems and the API includes functions for SSL communication | systems and the API includes functions for SSL communication | |||
rather than just signing data with private keys. | rather than just signing data with private keys. | |||
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 performance | |||
using AvrCryptolib in Table 1. All results are from a single run | using AvrCryptolib in Table 1. All results are from a single run | |||
since repeating the test did not change (or had only minimal impact | since repeating the test did not change (or had only minimal impact | |||
skipping to change at page 11, line 41 ¶ | skipping to change at page 12, line 13 ¶ | |||
these keys are provided here for reference only. | these keys are provided here for reference only. | |||
+--------+--------------+--------------+-------------+--------------+ | +--------+--------------+--------------+-------------+--------------+ | |||
| Key | Execution | Memory | Execution | Memory | | | Key | Execution | Memory | Execution | Memory | | |||
| length | time (ms); | footprint | time (ms); | footprint | | | length | time (ms); | footprint | time (ms); | footprint | | |||
| (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | | | (bits) | key in SRAM | (bytes); key | key in ROM | (bytes); key | | |||
| | | in SRAM | | in ROM | | | | | in SRAM | | in ROM | | |||
+--------+--------------+--------------+-------------+--------------+ | +--------+--------------+--------------+-------------+--------------+ | |||
| 64 | 64 | 40 | 69 | 32 | | | 64 | 64 | 40 | 69 | 32 | | |||
| 128 | 434 | 80 | 460 | 64 | | | 128 | 434 | 80 | 460 | 64 | | |||
| 512 | 25,076 | 320 | 27348 | 256 | | | 512 | 25076 | 320 | 27348 | 256 | | |||
| 1,024 | 199688 | 640 | 218367 | 512 | | | 1024 | 199688 | 640 | 218367 | 512 | | |||
| 2,048 | 1587567 | 1,280 | 1740258 | 1,024 | | | 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 scope | The code size was less than 3.6 kB for all the test cases with | |||
for further reduction. It is also worth noting that the | potential for further reduction. It is also worth noting that the | |||
implementation performs basic exponentiation and multiplication | implementation performs basic exponentiation and multiplication | |||
operations without using any mathematical optimizations such as | operations without using any mathematical optimizations such as | |||
Montgomery multiplication, optimized squaring, etc. as described in | Montgomery multiplication, optimized squaring, etc. as described in | |||
[rsa-high-speed]. With more SRAM, we believe that 1024/2048-bit | [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 | operations can be performed in much less time as has been shown in | |||
[rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of | [rsa-8bit]. 2048-bit RSA is nonetheless possible with about 1 kB of | |||
SRAM as is seen in Table 1. | 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 | SHA-1 hashing algorithm included in the library was used in each of | |||
the cases. The measurements reflect the performance of elliptic | the cases. The measurements reflect the performance of elliptic | |||
curve signing only and not the SHA-1 hashing algorithm. SHA-1 is now | 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. It | known to be insecure and should not be used in live deployments. It | |||
is clearly observable that for similar security levels, Elliptic | is clearly observable that for similar security levels, Elliptic | |||
Curve public key cryptography outperforms RSA. These results were | Curve public key cryptography outperforms RSA. These results were | |||
obtained by turning on all the optimizations. These optimizations | obtained by turning on all the optimizations. These optimizations | |||
include - Curve Specific Optimizations for modular reduction (NIST | include - Curve Specific Optimizations for modular reduction (NIST | |||
and SEC 2 field primes were chosen as pseudo-Mersenne primes), | and SEC 2 field primes were chosen as pseudo-Mersenne primes), | |||
Sliding Window for faster scalar multiplication, Hybrid squaring | Sliding Window for faster scalar multiplication, Hybrid squaring | |||
procedure written in assembly and Weighted projective Coordinate | procedure written in assembly and Weighted projective Coordinate | |||
system for efficient scalar point addition, doubling and | system for efficient scalar point addition, doubling and | |||
multiplication. We did not use optimizations like Shamir Trick and | multiplication. We did not use optimizations like Shamir Trick and | |||
Sliding Window as they are only useful for signature verification and | Sliding Window as they are only useful for signature verification and | |||
skipping to change at page 14, line 8 ¶ | skipping to change at page 14, line 26 ¶ | |||
| 192r1 | 6217 | 1008 | 1536 | | | 192r1 | 6217 | 1008 | 1536 | | |||
+-------------+---------------+-----------------+-------------------+ | +-------------+---------------+-----------------+-------------------+ | |||
ECDSA signature performance with TinyECC (No assembly optimizations) | ECDSA signature performance 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. SHA-1 algorithm provided in the library was used. The | |||
measurements reflect the performance of elliptic curve signing only | measurements reflect the performance of elliptic curve signing only | |||
and not the SHA-1 hashing algorithm. SHA-1 is now known to be | 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 | insecure and should not be used in real deployments. The ROM size | |||
for all the experiments was less than 16 kB. | 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 | | |||
skipping to change at page 14, line 50 ¶ | skipping to change at page 15, line 21 ¶ | |||
measurements reflect the performance of elliptic curve signing only | measurements reflect the performance of elliptic curve signing only | |||
and not the SHA-1 hashing algorithm. SHA-1 is now known to be | and not the SHA-1 hashing algorithm. SHA-1 is now known to be | |||
insecure and should not be used in real deployments. The library | insecure and should not be used in real deployments. The library | |||
does provide several alternatives with such as SHA-256. | does provide several alternatives with such as SHA-256. | |||
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 | |||
crypto 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 | |||
performed with the library configured for high speed performance with | performed with the library configured for high speed performance with | |||
no consideration given to the amount of memory used. For the second | no consideration given to the amount of memory used. For the second | |||
set, the library was configured for low memory usage irrespective of | set, the library was configured for low memory usage irrespective of | |||
the execution time required by different curves. By turning on/off | the execution time required by different curves. By turning on/off | |||
optimizations included in the library, a trade-off between memory and | optimizations included in the library, a trade-off between memory and | |||
execution time between these values can be achieved. | execution time between these values can be achieved. | |||
skipping to change at page 16, line 9 ¶ | skipping to change at page 16, line 29 ¶ | |||
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 | o As with the RSA measurements, curves giving less that 112-bit | |||
security are insecure and considered as legacy. The measurements | security are insecure and considered as legacy. The measurements | |||
are only provided for reference. | 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. In order to create private keys with a | |||
better quality of random number, we can use a true random number | better quality of random number, we can use a true random number | |||
generator like the one provided by TrueRandom library | generator like the one provided by TrueRandom library | |||
[truerandom], or create the keys separately on a system with a | [truerandom], or create the keys separately on a system with a | |||
true random number generator and then use them directly in the | true random number generator and then use them directly in the | |||
code. | 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. | |||
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). [I-D.irtf-cfrg-eddsa] specifies | Digital Signature Algorithm (EdDSA). [RFC8032] specifies the | |||
the recommended parameters for the edwards25519 and edwards448 | recommended parameters for the edwards25519 and edwards448 curves. | |||
curves. From these, curve25519 (for elliptic curve Diffie-Hellman | From these, curve25519 (for elliptic curve Diffie-Hellman key | |||
key exchange) and edwards25519 (for elliptic curve digital | exchange) and edwards25519 (for elliptic curve digital signatures) | |||
signatures) are especially suitable for resource-constrained devices. | are especially suitable for resource-constrained devices. | |||
We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries | We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries | |||
provide highly efficient implementations of Diffie-Hellman key | provide highly efficient implementations of Diffie-Hellman key | |||
exchange with curve25519. The results have shown that these | exchange with curve25519. The results have shown that these | |||
libraries with curve25519 outperform other elliptic curves that | libraries with curve25519 outperform other elliptic curves that | |||
provide similar levels of security. Hutter and Schwabe [naclavr] | provide similar levels of security. Hutter and Schwabe [naclavr] | |||
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 1,4510 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 ROM use is shown in Table 7. | |||
+-------------------------+---------------------------+ | +------------------------+---------------------------+ | |||
| Library | ROM Footprint (Kilobytes) | | | Library | ROM 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 ROM needs | |||
Table 7 | Table 7 | |||
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 | |||
skipping to change at page 17, line 41 ¶ | skipping to change at page 18, line 10 ¶ | |||
public key crypto mechanisms, data object security, and an easy | public key crypto mechanisms, data object security, and an easy | |||
provisioning model. Our application was originally developed to test | provisioning model. Our application was originally developed to test | |||
different approaches to supporting communications to "always off" | different approaches to supporting communications to "always off" | |||
sensor nodes. These battery-operated or energy scavenging nodes do | sensor nodes. These battery-operated or energy scavenging nodes do | |||
not have enough power to be stay on at all times. They wake up | not have enough power to be stay on at all times. They wake up | |||
periodically and transmit their readings. | periodically and transmit their readings. | |||
Such sensor nodes can be supported in various ways. | Such sensor nodes can be supported in various ways. | |||
[I-D.arkko-core-sleepy-sensors] was an early multicast-based | [I-D.arkko-core-sleepy-sensors] was an early multicast-based | |||
approach. In the current application we have switched to using | approach. In the current application we have switched to using | |||
resource directories [I-D.ietf-core-resource-directory] and mirror | resource directories [I-D.ietf-core-resource-directory] and publish- | |||
proxies [I-D.vial-core-mirror-proxy] instead. Architecturally, the | subscribe brokers [I-D.ietf-core-coap-pubsub] instead. | |||
idea is that sensors can delegate a part of their role to a node in | Architecturally, the idea is that sensors can delegate a part of | |||
the network. Such a network node could be either a local resource or | their role to a node in the network. Such a network node could be | |||
something in the Internet. In the case of CoAP mirror proxies, the | either a local resource or something in the Internet. In the case of | |||
network node agrees to hold the web resources on behalf of the | CoAP publish-subscribe brokers, the network node agrees to hold the | |||
sensor, while the sensor is asleep. The only role that the sensor | web resources on behalf of the sensor, while the sensor is asleep. | |||
has is to register itself at the mirror proxy, and periodically | The only role that the sensor has is to register itself at the | |||
update the readings. All queries from the rest of the world go to | publish-subscribe broker, and periodically update the readings. All | |||
the mirror proxy. | queries from the rest of the world go to the publish-subscribe | |||
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 mirror proxy | This is an Arduino-based device that runs a CoAP publish-subscribe | |||
client and Relic-toolkit. Relic takes 29 Kbytes of ROM, and the | broker client and Relic-toolkit. Relic takes 29 Kbytes of ROM, | |||
simple CoAP client roughly 3 kilobytes. | and the simple CoAP client roughly 3 kilobytes. | |||
Mirror Proxy | Publish-Subscribe Broker | |||
This is a mirror proxy that holds resources on the sensor's | This is a publish-subscribe broker that holds resources on the | |||
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 | |||
mirror proxies to register resources in the directory. These | publish-subscribe brokers to register resources in the directory. | |||
resources can be queried by applications. | These resources can be queried by applications. | |||
Application | Application | |||
This is a simple application that runs on a general purpose | This is a simple application that runs on a general purpose | |||
computer and can retrieve both registrations from the resource | computer and can retrieve both registrations from the resource | |||
directory and most recent sensor readings from the mirror proxy. | directory and most recent sensor readings from the publish- | |||
subscribe broker. | ||||
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 mirror proxy. Their public key is submitted along with the | the publish-subscribe broker. Their public key is submitted along | |||
registration as an attribute in the CORE Link Format data [RFC6690]. | with the registration as an attribute in the CORE Link Format data | |||
[RFC6690]. | ||||
In Step 2, when the sensor makes a sensor reading update to the | In Step 2, when the sensor makes a measurement, it sends an update to | |||
mirror proxy it signs the message contents with a JOSE signature on | the publish-subscribe broker and signs the message contents with a | |||
the used JSON/SENML payload [RFC7515] [I-D.jennings-core-senml]. | JOSE signature on the used JSON/SENML payload [RFC7515] | |||
[I-D.ietf-core-senml]. The sensor can also alternatively use CBOR | ||||
Object Signing and Encryption (COSE) [I-D.ietf-cose-msg] for signing | ||||
the sensor measurement. | ||||
In Step 3, any other device in the network -- including the mirror | In Step 3, any other device in the network -- including the publish- | |||
proxy, resource directory and the application -- can check that the | subscribe broker, resource directory and the application -- can check | |||
public key from the registration corresponds to the private key used | that the public key from the registration corresponds to the private | |||
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 | |||
with the presence of assisting middleboxes. | with the presence of assisting middleboxes. | |||
To verify the feasibility of our architecture we developed a proof- | To verify the feasibility of our architecture we developed a proof- | |||
of-concept prototype. In our prototype, the sensor was implemented | of-concept prototype. In our prototype, the sensor was implemented | |||
using the Arduino Ethernet shield over an Arduino Mega board. Our | using the Arduino Ethernet shield over an Arduino Mega board. Our | |||
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 Mirror Proxy (MP) and the | Arduino Mega board. In this prototype, the publish-subscribe broker | |||
Resource Directory (RD) reside on the same physical host. A 64-bit | and the Resource Directory (RD) reside on the same physical host. A | |||
x86 linux machine serves as the MP and the RD, while a similar but | 64-bit x86 linux machine serves as the broker and the RD, while a | |||
physically different 64-bit x86 linux machine serves as the client | similar but physically different 64-bit x86 linux machine serves as | |||
that requests data from the sensor. We chose the Relic library | the client that requests data from the sensor. We chose the Relic | |||
version 0.3.1 for our sample prototype as it can be easily compiled | library version 0.3.1 for our sample prototype as it can be easily | |||
for different bit-length processors. Therefore, we were able to use | compiled for different bit-length processors. Therefore, we were | |||
it on the 8-bit processor of the Arduino Mega, as well as on the | able to use it on the 8-bit processor of the Arduino Mega, as well as | |||
64-bit processor of the x86 client. We used ECDSA to sign and verify | on the 64-bit processor of the x86 client. We used ECDSA to sign and | |||
data updates with the standard NIST-K163 curve parameters (163-bit | verify data updates with the standard NIST-K163 curve parameters | |||
Koblitz curve over binary field). While compiling Relic for our | (163-bit Koblitz curve over binary field). While compiling Relic for | |||
prototype, we used the fast configuration without any assembly | our prototype, we used the fast 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 Mirror Proxy | programming language and extends it to add support for publish- | |||
and Resource Directory REST interfaces. We also developed a | subscribe broker and Resource Directory REST interfaces. We also | |||
minimalistic CoAP C-library for the Arduino sensor and for the client | developed a minimalistic CoAP C-library for the Arduino sensor and | |||
requesting data updates for a resource. The library has small SRAM | for the client requesting data updates for a resource. The library | |||
requirements and uses stack-based allocation only. It is inter- | has small SRAM requirements and uses stack-based allocation only. It | |||
operable with the Java implementation of CoAP running on the gateway. | is interoperable with the Java implementation of CoAP running on the | |||
The location of the mirror proxy was pre-configured into the smart | gateway. The location of the publish-subscribe broker was configured | |||
object sensor by hardcoding the IP address. We used an IPv4 network | into the smart object sensor by hardcoding the IP address. We used | |||
with public IP addresses obtained from a DHCP server. | an IPv4 network with public IP addresses obtained from a DHCP server. | |||
Some important statistics of this prototype are listed in table | Some important statistics of this prototype are listed in table | |||
Table 8. Our straw man analysis of the performance of this prototype | Table 8. Our straw man analysis of the performance of this prototype | |||
is preliminary. Our intention was to demonstrate the feasibility of | is preliminary. Our intention was to demonstrate the feasibility of | |||
the entire architecture with public-key cryptography on an 8-bit | 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 SRAM | |||
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 | were used out-of-the-box and there are several functions which can be | |||
be removed. Similarly we used the fast version of the Relic library | removed. Similarly we used the fast version of the Relic library in | |||
in the prototype instead of the low memory version. | the prototype instead of the low memory version. | |||
+-----------------------------------------------------------+-------+ | +-----------------------------------------------------------+-------+ | |||
| Flash memory consumption (for the entire prototype | 51 kB | | | Flash memory consumption (for the entire prototype | 51 kB | | |||
| including Relic crypto + CoAP + Arduino UDP, Ethernet and | | | | including Relic library + CoAP + Arduino UDP) | | | |||
| DHCP Libraries) | | | ||||
| | | | | | | | |||
| SRAM consumption (for the entire prototype including DHCP | 4678 | | | SRAM consumption (for the entire prototype including key | 4678 | | |||
| client + key generation + signing the hash of message + | bytes | | | generation + signing the hash of message + COAP + UDP + | bytes | | |||
| COAP + UDP + Ethernet) | | | | Ethernet) | | | |||
| | | | | | | | |||
| Execution time for creating the key pair + sending | 2030 | | | Execution time for creating the key pair + sending | 2030 | | |||
| registration message + time spent waiting for acknowl- | ms | | | registration message + time spent waiting for | ms | | |||
| edgement | | | | acknowledgement | | | |||
| | | | | | | | |||
| Execution time for signing the hash of message + sending | 987 | | | Execution time for signing the hash of message + sending | 987 | | |||
| update | ms | | | update | ms | | |||
| | | | | | | | |||
| Signature overhead | 42 | | | Signature overhead | 42 | | |||
| | bytes | | | | bytes | | |||
+-----------------------------------------------------------+-------+ | +-----------------------------------------------------------+-------+ | |||
Prototype Performance | Prototype Performance | |||
Table 8 | Table 8 | |||
To demonstrate the efficacy of this communication model we compare it | To demonstrate the efficacy of this communication model we compare it | |||
with a scenario where the smart objects do not transition into the | with a scenario where the smart objects do not transition into the | |||
energy saving sleep mode and directly serve temperature data to | energy saving sleep mode and directly serve temperature data to | |||
clients. As an example, we assume that in our architecture, the | clients. As an example, we assume that in our architecture, the | |||
smart objects wake up once every minute to report the signed | smart objects wake up once every minute to report the signed | |||
temperature data to the caching MP. If we calculate the energy | temperature data to the caching broker. If we calculate the energy | |||
consumption using the formula W = U * I * t (where U is the operating | 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 | 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 | the voltage and current values from the datasheets of the ATmega2560 | |||
(20mA-active mode and 5.4mA-sleep mode) and W5100 (183mA) chips used | (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 | 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 | 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 | 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 MP with | consume 2.6 Joules if it wakes up once a minute to update the broker | |||
signed data. Therefore, a typical Li-ion battery that provides about | with signed data. Therefore, a typical Li-ion battery that provides | |||
1800 milliamps per hour (mAh) at 5V would have a lifetime of 9 hours | about 1800 milliamps per hour (mAh) at 5V would have a lifetime of 9 | |||
in the unsecured always-on scenario, whereas it would have a lifetime | hours in the unsecured always-on scenario, whereas it would have a | |||
of about 8.5 days in the secured sleepy architecture presented. | lifetime of about 8.5 days in the secured sleepy architecture | |||
These lifetimes appear to be low because the Arduino board in the | presented. These lifetimes appear to be low because the Arduino | |||
prototype uses Ethernet which is not energy efficient. The values | board in the prototype uses Ethernet which is not energy efficient. | |||
presented only provide an estimate (ignoring the energy required to | The values presented only provide an estimate (ignoring the energy | |||
transition in and out of the sleep mode) and would vary depending on | required to transition in and out of the sleep mode) and would vary | |||
the hardware and MAC protocol used. Nonetheless, it is evident that | depending on the hardware and MAC protocol used. Nonetheless, it is | |||
our architecture can increase the life of smart objects by allowing | evident that our architecture can increase the life of smart objects | |||
them to sleep and can ensure security at the same time. | 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 22, line 6 ¶ | skipping to change at page 22, line 17 ¶ | |||
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. | |||
Yet, with reasonably long key sizes the execution times are in the | Yet, with reasonably long key sizes the execution times are in the | |||
seconds, dozens of seconds, or even longer. For some applications | seconds, dozens of seconds, or even longer. For some applications | |||
this is too long. Nevertheless, the authors believe that these | this is too long. Nevertheless, the authors believe that these | |||
algorithms can successfully be employed in small devices for the | algorithms can successfully be employed in small devices for the | |||
following reasons: | following reasons: | |||
o With the right selection of algorithms and libraries, the | o With the right selection of algorithms and libraries, the | |||
execution times can actually be smaller. Using the Relic-toolkit | execution times can actually be very small (less than 500 ms). | |||
with the NIST K163 algorithm (roughly equivalent to RSA at 1024 | ||||
bits) at 0.3 seconds is a good example of this. | ||||
o As discussed in [wiman], in general the power requirements | o As discussed in [wiman], in general the power requirements | |||
necessary to send or receive messages are far bigger than those | necessary to send or receive messages are far bigger than those | |||
needed to execute cryptographic operations. There is no good | needed to execute cryptographic operations. While there are newer | |||
reason to choose platforms that do not provide sufficient | radios that significantly lower the energy consumption of sending | |||
computing power to run the necessary operations. | and receiving messages, there is no good reason to choose | |||
platforms that do not provide sufficient computing power to run | ||||
the necessary cryptographic operations. | ||||
o Commercial libraries and the use of full potential for various | o Commercial libraries and the use of full potential for various | |||
optimizations will provide a better result than what we arrived at | optimizations will provide a better result than what we arrived at | |||
in this paper. | in this memo. | |||
o Using public key cryptography only at the beginning of a session | o Using public key cryptography only at the beginning of a session | |||
will reduce the per-packet processing times significantly. | will reduce the per-packet processing times significantly. | |||
12. Freshness | 12. Freshness | |||
In our architecture, if implemented as described thus far, messages | In our architecture, if implemented as described thus far, messages | |||
along with their signatures sent from the sensors to the mirror proxy | along with their signatures sent from the sensors to the publish- | |||
can be recorded and replayed by an eavesdropper. The mirror proxy | subscribe broker can be recorded and replayed by an eavesdropper. | |||
has no mechanism to distinguish previously received packets from | The publish-subscribe broker has no mechanism to distinguish | |||
those that are retransmitted by the sender or replayed by an | previously received packets from those that are retransmitted by the | |||
eavesdropper. Therefore, it is essential for the smart objects to | sender or replayed by an eavesdropper. Therefore, it is essential | |||
ensure that data updates include a freshness indicator. However, | for the smart objects to ensure that data updates include a freshness | |||
ensuring freshness on constrained devices can be non-trivial because | indicator. However, ensuring freshness on constrained devices can be | |||
of several reasons which include: | non-trivial because of several reasons which include: | |||
o Communication is mostly unidirectional to save energy. | o Communication is mostly unidirectional to save energy. | |||
o Internal clocks might not be accurate and may be reset several | o Internal clocks might not be accurate and may be reset several | |||
times during the operational phase of the smart object. | times during the operational phase of the smart object. | |||
o Network time synchronization protocols such as Network Time | o Network time synchronization protocols such as Network Time | |||
Protocol (NTP) [RFC5905] are resource intensive and therefore may | Protocol (NTP) [RFC5905] are resource intensive and therefore may | |||
be undesirable in many smart object networks. | be undesirable in many smart object networks. | |||
There are several different methods that can be used in our | There are several different methods that can be used in our | |||
architecture for replay protection. The selection of the appropriate | architecture for replay protection. The selection of the appropriate | |||
choice depends on the actual deployment scenario. | choice depends on the actual deployment scenario. | |||
Including sequence numbers in signed messages can provide an | Including sequence numbers in signed messages can provide an | |||
effective method of replay protection. The mirror proxy should | effective method of replay protection. The publish-subscribe broker | |||
verify the sequence number of each incoming message and accept it | should verify the sequence number of each incoming message and accept | |||
only if it is greater than the highest previously seen sequence | it only if it is greater than the highest previously seen sequence | |||
number. The mirror proxy drops any packet with a sequence number | number. The publish-subscribe broker drops any packet with a | |||
that has already been received or if the received sequence number is | sequence number that has already been received or if the received | |||
greater than the highest previously seen sequence number by an amount | sequence number is greater than the highest previously seen sequence | |||
larger than the preset threshold. | number by an amount larger than the preset threshold. | |||
Sequence numbers can wrap-around at their maximum value and, | Sequence numbers can wrap-around at their maximum value and, | |||
therefore, it is essential to ensure that sequence numbers are | therefore, it is essential to ensure that sequence numbers are | |||
sufficiently long. However, including long sequence numbers in | sufficiently long. However, including long sequence numbers in | |||
packets can increase the network traffic originating from the sensor | packets can increase the network traffic originating from the sensor | |||
and can thus decrease its energy efficiency. To overcome the problem | and can thus decrease its energy efficiency. To overcome the problem | |||
of long sequence numbers, we can use a scheme similar to that of | of long sequence numbers, we can use a scheme similar to that of | |||
Huang [huang], where the sender and receiver maintain and sign long | Huang [huang], where the sender and receiver maintain and sign long | |||
sequence numbers of equal bit-lengths but they transmit only the | sequence numbers of equal bit-lengths but they transmit only the | |||
least significant bits. | least significant bits. | |||
It is important for the smart object to write the sequence number | It is important for the smart object to write the sequence number | |||
into the permanent flash memory after each increment and before it is | into the permanent flash memory after each increment and before it is | |||
included in the message to be transmitted. This ensures that the | included in the message to be transmitted. This ensures that the | |||
sensor can obtain the last sequence number it had intended to send in | sensor can obtain the last sequence number it had intended to send in | |||
case of a reset or a power failure. However, the sensor and the | case of a reset or a power failure. However, the sensor and the | |||
mirror proxy can still end up in a discordant state where the | publish-subscribe broker can still end up in a discordant state where | |||
sequence number received by the mirror proxy exceeds the expected | the sequence number received by the publish-subscribe broker exceeds | |||
sequence number by an amount greater than the preset threshold. This | the expected sequence number by an amount greater than the preset | |||
may happen because of a prolonged network outage or if the mirror | threshold. This may happen because of a prolonged network outage or | |||
proxy experiences a power failure for some reason. Therefore it is | if the publish-subscribe broker experiences a power failure for some | |||
essential for sensors that normally send Non-Confirmable data updates | reason. Therefore it is essential for sensors that normally send | |||
to send some Confirmable updates and re-synchronize with the mirror | Non-Confirmable data updates to send some Confirmable updates and re- | |||
proxy if a reset message is received. The sensors re-synchronize by | synchronize with the publish-subscribe broker if a reset message is | |||
sending a new registration message with the current sequence number. | received. The sensors re-synchronize by sending a new registration | |||
message with the current sequence number. | ||||
Although sequence numbers protect the system from replay attacks, a | Although sequence numbers protect the system from replay attacks, a | |||
mirror proxy has no mechanism to determine the time at which updates | publish-subscribe broker has no mechanism to determine the time at | |||
were created by the sensor. Moreover, if sequence numbers are the | which updates were created by the sensor. Moreover, if sequence | |||
only freshness indicator used, a malicious eavesdropper can induce | numbers are the only freshness indicator used, a malicious | |||
inordinate delays to the communication of signed updates by buffering | eavesdropper can induce inordinate delays to the communication of | |||
messages. It may be important in certain smart object networks for | signed updates by buffering messages. It may be important in certain | |||
sensors to send data updates which include timestamps to allow the | smart object networks for sensors to send data updates which include | |||
mirror proxy to determine the time when the update was created. For | timestamps to allow the publish-subscribe broker to determine the | |||
example, when the mirror proxy is collecting temperature data, it may | time when the update was created. For example, when the publish- | |||
be necessary to know when exactly the temperature measurement was | subscribe broker is collecting temperature data, it may be necessary | |||
made by the sensor. A simple solution to this problem is for the | to know when exactly the temperature measurement was made by the | |||
mirror proxy to assume that the data object was created when it | sensor. A simple solution to this problem is for the publish- | |||
subscribe broker to assume that the data object was created when it | ||||
receives the update. In a relatively reliable network with low RTT, | receives the update. In a relatively reliable network with low RTT, | |||
it can be acceptable to make such an assumption. However most | it can be acceptable to make such an assumption. However most | |||
networks are susceptible to packet loss and hostile attacks making | networks are susceptible to packet loss and hostile attacks making | |||
this assumption unsustainable. | this assumption unsustainable. | |||
Depending on the hardware used by the smart objects, they may have | Depending on the hardware used by the smart objects, they may have | |||
access to accurate hardware clocks which can be used to include | access to accurate hardware clocks which can be used to include | |||
timestamps in the signed updates. These timestamps are included in | timestamps in the signed updates. These timestamps are included in | |||
addition to sequence numbers. The clock time in the smart objects | addition to sequence numbers. The clock time in the smart objects | |||
can be set by the manufacturer or the current time can be | can be set by the manufacturer or the current time can be | |||
communicated by the mirror proxy during the registration phase. | communicated by the publish-subscribe broker during the registration | |||
However, these approaches require the smart objects to either rely on | phase. However, these approaches require the smart objects to either | |||
the long-term accuracy of the clock set by the manufacturer or to | rely on the long-term accuracy of the clock set by the manufacturer | |||
trust the mirror proxy thereby increasing the potential vulnerability | or to trust the publish-subscribe broker thereby increasing the | |||
of the system. The smart objects could also obtain the current time | potential vulnerability of the system. The smart objects could also | |||
from NTP, but this may consume additional energy and give rise to | obtain the current time from NTP, but this may consume additional | |||
security issues discussed in [RFC5905]. The smart objects could also | energy and give rise to security issues discussed in [RFC5905]. The | |||
have access to a GSM network or the Global Positioning System (GPS), | smart objects could also have access to a mobile network or the | |||
and they can be used obtain the current time. Finally, if the | Global Positioning System (GPS), and they can be used obtain the | |||
sensors need to co-ordinate their sleep cycles, or if the mirror | current time. Finally, if the sensors need to co-ordinate their | |||
proxy computes an average or mean of updates collected from multiple | sleep cycles, or if the publish-subscribe broker computes an average | |||
smart objects, it is important for the network nodes to synchronize | or mean of updates collected from multiple smart objects, it is | |||
the time among them. This can be done by using existing | important for the network nodes to synchronize the time among them. | |||
synchronization schemes. | This can be done by using existing synchronization schemes. | |||
13. Layering | 13. Layering | |||
It would be useful to select just one layer where security is | It would be useful to select just one layer where security is | |||
provided at. Otherwise a simple device needs to implement multiple | provided at. Otherwise a simple device needs to implement multiple | |||
security mechanisms. While some code can probably be shared across | security mechanisms. While some code can probably be shared across | |||
such implementations (like algorithms), it is likely that most of the | such implementations (like algorithms), it is likely that most of the | |||
code involving the actual protocol machinery cannot. Looking at the | code involving the actual protocol machinery cannot. Looking at the | |||
different layers, here are the choices and their implications: | different layers, here are the choices and their implications: | |||
skipping to change at page 27, line 35 ¶ | skipping to change at page 28, line 5 ¶ | |||
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. | Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. | |||
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- | Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- | |||
sleepy-sensors-01 (work in progress), July 2011. | sleepy-sensors-01 (work in progress), July 2011. | |||
[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] | ||||
Koster, M., Keranen, A., and J. Jimenez, "Publish- | ||||
Subscribe Broker for the Constrained Application Protocol | ||||
(CoAP)", draft-ietf-core-coap-pubsub-00 (work in | ||||
progress), October 2016. | ||||
[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., and P. Stok, "CoRE | |||
Resource Directory", draft-ietf-core-resource-directory-08 | Resource Directory", draft-ietf-core-resource-directory-09 | |||
(work in progress), July 2016. | (work in progress), October 2016. | |||
[I-D.irtf-cfrg-eddsa] | [I-D.ietf-core-senml] | |||
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital | Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. | |||
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 | Bormann, "Media Types for Sensor Measurement Lists | |||
(work in progress), August 2016. | (SenML)", draft-ietf-core-senml-04 (work in progress), | |||
October 2016. | ||||
[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, "Security | |||
Considerations in the IP-based Internet of Things", draft- | Considerations in the IP-based Internet of Things", draft- | |||
irtf-t2trg-iot-seccons-00 (work in progress), October | irtf-t2trg-iot-seccons-00 (work in progress), October | |||
2016. | 2016. | |||
[I-D.jennings-core-senml] | ||||
Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, | ||||
"Media Types for Sensor Markup Language (SenML)", draft- | ||||
jennings-core-senml-06 (work in progress), April 2016. | ||||
[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.vial-core-mirror-proxy] | [I-D.sarikaya-t2trg-sbootstrapping] | |||
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- | Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT | |||
proxy-01 (work in progress), July 2012. | Bootstrapping: A Survey", draft-sarikaya-t2trg- | |||
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/>. | |||
[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", 2010. | time efficiency and power consumption analysis", Pomiary | |||
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. | |||
[relic-toolkit] | [relic-toolkit] | |||
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, | Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, | |||
skipping to change at page 30, line 28 ¶ | skipping to change at page 31, line 5 ¶ | |||
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves | [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves | |||
for Security", RFC 7748, DOI 10.17487/RFC7748, January | for Security", RFC 7748, DOI 10.17487/RFC7748, January | |||
2016, <http://www.rfc-editor.org/info/rfc7748>. | 2016, <http://www.rfc-editor.org/info/rfc7748>. | |||
[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 | ||||
Signature Algorithm (EdDSA)", RFC 8032, | ||||
DOI 10.17487/RFC8032, January 2017, | ||||
<http://www.rfc-editor.org/info/rfc8032>. | ||||
[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>. | |||
[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] | [truerandom] | |||
Drow, C., "Truerandom", September 2015, | Drow, C., "Truerandom", September 2015, | |||
<http://code.google.com/p/tinkerit/wiki/TrueRandom>. | <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. In 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, Zurich. Proceedings of | Networks (WiMAN 2010) , 2010. | |||
ICCCN'2010/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, | |||
<www.wiselib.org/>. | <www.wiselib.org/>. | |||
[Withings] | [Withings] | |||
Withings, "The Withings scale", February 2012, | Withings, "The Withings scale", February 2012, | |||
<http://www.withings.com/en/bodyscale>. | <http://www.withings.com/en/bodyscale>. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
End of changes. 63 change blocks. | ||||
237 lines changed or deleted | 265 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/ |