draft-ietf-lwig-crypto-sensors-00.txt   draft-ietf-lwig-crypto-sensors-01.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: March 8, 2017 Ericsson Expires: May 4, 2017 Ericsson
H. Back H. Back
Comptel Comptel
September 4, 2016 October 31, 2016
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-00 draft-ietf-lwig-crypto-sensors-01
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 small devices using those libraries, and discusses
trade-offs involving different types of approaches. trade-offs involving different types of approaches.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 March 8, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5 4. Proposed Deployment Model . . . . . . . . . . . . . . . . . . 5
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 8 7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 8. Implementation Experiences . . . . . . . . . . . . . . . . . 11
9. Example Application . . . . . . . . . . . . . . . . . . . . . 16 9. Example Application . . . . . . . . . . . . . . . . . . . . . 17
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 21
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 26
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
17. Informative references . . . . . . . . . . . . . . . . . . . 26 17. Informative references . . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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 (see devices in constrained implementations and environments. In
Section 3). Section 3) we specifically discuss three challenges: the
implementation difficulties encountered on resource-constrained
platforms, the problem of provisioning keys and making the choice of
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 smart object networking environments. typical communication practices in smart object networking
environments.
Thirdly, Section 7 discusses the availability of cryptographic Thirdly, Section 7 discusses the availability of cryptographic
libraries. Section 8 presents some experiences in implementing small libraries. Section 8 presents some experiences in implementing
devices using those libraries, including information about achievable cryptography on small devices using those libraries, including
code sizes and speeds on typical hardware. information about achievable code sizes and speeds on typical
hardware.
Finally, Section 10 discusses trade-offs involving different types of Finally, Section 10 discusses trade-offs involving different types of
security approaches. security approaches.
2. Related Work 2. Related Work
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight Constrained Application Protocol (CoAP) [RFC7252] is a light-weight
protocol designed to be used in machine-to-machine applications such protocol designed to be used in machine-to-machine applications such
as smart energy and building automation. Our discussion uses this as smart energy and building automation. Our discussion uses this
protocol as an example, but the conclusions may apply to other protocol as an example, but the conclusions may apply to other
similar protocols. CoAP base specification [RFC7252] outlines how to similar protocols. CoAP base specification [RFC7252] outlines how to
use DTLS [RFC6347] and IKEv2 [RFC7296] for securing the protocol. use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol.
DTLS can be applied with group keys, pairwise shared keys, or with DTLS can be applied with pairwise shared keys, raw public keys or
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 specification says little about how DTLS keys are different. The CoAP specification says little about how DTLS keys
managed. The IPsec mode is described with regards to the protocol are managed. The use of IPsec with CoAP is described with regards to
requirements, noting that small implementations of IKEv2 exist the protocol requirements, noting that small implementations of IKEv2
[RFC7815]. However, the specification is silent on policy and other exist [RFC7815]. However, the CoAP specification is silent on policy
aspects that are normally necessary in order to implement and other aspects that are normally necessary in order to implement
interoperable use of IPsec in any environment [RFC5406]. interoperable use of IPsec in any environment [RFC5406].
[RFC6574] gives an overview of the security discussions at the March [RFC6574] gives an overview of the security discussions at the March
2011 IAB workshop on smart objects. The workshop recommended that 2011 IAB workshop on smart objects. The workshop recommended that
additional work is needed in developing suitable credential additional work is needed in developing suitable credential
management mechanisms (perhaps something similar to the Bluetooth management mechanisms (perhaps something similar to the Bluetooth
pairing mechanism), understanding the implementability of standard pairing mechanism), understanding the implementability of standard
security mechanisms in small devices and additional research in the security mechanisms in small devices and additional research in the
area of lightweight cryptographic primitives. area of lightweight cryptographic primitives.
skipping to change at page 3, line 50 skipping to change at page 4, line 7
[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.garcia-core-security] discusses the overall security problem for [I-D.irtf-t2trg-iot-seccons] discusses the overall security problem
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 bootstrapping mechanisms, and challenges associated with implementing
security mechanisms in these environments. security mechanisms in these environments.
3. Challenges 3. Challenges
This section discusses three challenges: implementation difficulties, This section discusses three challenges: implementation difficulties,
practical provisioning problems, and layering and communication practical provisioning problems, and layering and communication
skipping to change at page 5, line 40 skipping to change at page 5, line 47
The basis of the proposed architecture are self-generated secure The basis of the proposed architecture are self-generated secure
identities, similar to Cryptographically Generated Addresses (CGAs) identities, similar to Cryptographically Generated Addresses (CGAs)
[RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume [RFC3972] or Host Identity Tags (HITs) [RFC7401]. That is, we assume
the following holds: the following holds:
I = h(P|O) I = h(P|O)
where I is the secure identity of the device, h is a hash function, P where I is the secure identity of the device, h is a hash function, P
is the public key from a key pair generated by the device, and O is is the public key from a key pair generated by the device, and O is
optional other information. optional other information. | here denotes the concatenation
operator.
5. Provisioning 5. Provisioning
As provisioning security credentials, shared secrets, and policy As it is difficult to provision security credentials, shared secrets,
information is difficult, the provisioning model is based only on the and policy information, the provisioning model is based only on the
secure identities. A typical network installation involves physical secure identities. A typical network installation involves physical
placement of a number of devices while noting the identities of these placement of a number of devices while noting the identities of these
devices. This list of short identifiers can then be fed to a central devices. This list of short identifiers can then be fed to a central
server as a list of authorized devices. Secure communications can server as a list of authorized devices. Secure communications can
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
skipping to change at page 9, line 20 skipping to change at page 9, line 33
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. Please verify the numbers before relying
on them for building something. No significant effort was done to on them for building something. No significant effort was done to
optimize ROM memory usage beyond what the libraries provided optimize ROM memory usage beyond what the libraries provided
themselves, so those numbers should be taken as upper limits. 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 DES/Triple DES/AES etc. different symmetric key algorithms such as AES and RSA as an
and RSA as an asymmetric key algorithm. We stripped down the asymmetric key algorithm. We stripped down the library to use
library to use only the required RSA components and used a only the required RSA components and used a separate SHA-256
separate SHA-256 implementation from the original AvrCrypto-Lib implementation from the original AvrCrypto-Lib library
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
reduce the size and optimize the performance. The library also reduce the size and optimize the performance. The library also
takes advantage of the fact that Arduino boards allow the takes advantage of the fact that Arduino boards allow the
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
skipping to change at page 10, line 44 skipping to change at page 11, line 10
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
interested in the signature generation operation. This was because
our example application discussed in Section 9 required only the
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
on) the results. The keys were generated separately and were hard on) the results. The keys were generated separately and were hard
coded into the program. All keys were generated with the value of coded into the program. All keys were generated with the value of
the public exponent as 3. The performance of signing with private the public exponent as 3. The performance of signing with private
key was faster for smaller key lengths as was expected. However the key was faster for smaller key lengths as was expected. However the
increase in the execution time was considerable when the key size was increase in the execution time was considerable when the key size was
2048 bits. It is important to note that two different sets of 2048 bits. It is important to note that two different sets of
experiments were performed for each key length. In the first case, experiments were performed for each key length. In the first case,
skipping to change at page 26, line 45 skipping to change at page 27, line 35
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.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013.
[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-08
(work in progress), July 2016. (work in progress), July 2016.
[I-D.irtf-cfrg-eddsa] [I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08
(work in progress), August 2016. (work in progress), August 2016.
[I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "Security
Considerations in the IP-based Internet of Things", draft-
irtf-t2trg-iot-seccons-00 (work in progress), October
2016.
[I-D.jennings-core-senml] [I-D.jennings-core-senml]
Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, Jennings, C., Shelby, Z., Arkko, J., and A. Keranen,
"Media Types for Sensor Markup Language (SenML)", draft- "Media Types for Sensor Markup Language (SenML)", draft-
jennings-core-senml-06 (work in progress), April 2016. 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.
skipping to change at page 28, line 14 skipping to change at page 29, line 5
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<http://www.rfc-editor.org/info/rfc3748>. <http://www.rfc-editor.org/info/rfc3748>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <http://www.rfc-editor.org/info/rfc3972>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <http://www.rfc-editor.org/info/rfc5191>. May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
 End of changes. 20 change blocks. 
46 lines changed or deleted 60 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/