draft-ietf-lwig-crypto-sensors-04.txt | draft-ietf-lwig-crypto-sensors-05.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: February 9, 2018 Ericsson | Expires: June 27, 2018 Ericsson | |||
H. Back | H. Back | |||
Comptel | Comptel | |||
August 8, 2017 | December 24, 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-04 | draft-ietf-lwig-crypto-sensors-05 | |||
Abstract | Abstract | |||
This memo describes challenges associated with securing resource- | This memo describes challenges associated with securing resource- | |||
constrained smart object devices. The memo describes a possible | constrained smart object devices. The memo describes a possible | |||
deployment model where resource-constrained devices sign message | deployment model where resource-constrained devices sign message | |||
objects, discusses the availability of cryptographic libraries for | objects, discusses the availability of cryptographic libraries for | |||
small devices and presents some preliminary experiences with those | small devices and presents some preliminary experiences with those | |||
libraries for message signing on small devices. Lastly, the memo | libraries for message signing on small devices. Lastly, the memo | |||
discusses trade-offs involving different types of security | discusses trade-offs involving different types of security | |||
approaches. | 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 https://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 February 9, 2018. | This Internet-Draft will expire on June 27, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (https://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 | |||
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 . . . . . . . . . . . . . . . . . . 6 | |||
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 8 | 4.2. Protocol Architecture . . . . . . . . . . . . . . . . . . 9 | |||
7. Code Availability . . . . . . . . . . . . . . . . . . . . . . 9 | 5. Code Availability . . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. Implementation Experiences . . . . . . . . . . . . . . . . . 10 | 6. Implementation Experiences . . . . . . . . . . . . . . . . . 11 | |||
9. Example Application . . . . . . . . . . . . . . . . . . . . . 17 | 7. Example Application . . . . . . . . . . . . . . . . . . . . . 18 | |||
10. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 | 8. Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . . 20 | |||
11. Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 8.1. Feasibility . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
12. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 8.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
13. Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 8.3. Layering . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
14. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . . . 25 | 8.4. Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . . 25 | |||
15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 | 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 | |||
17. Informative references . . . . . . . . . . . . . . . . . . . 26 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 31 | 12. Informative references . . . . . . . . . . . . . . . . . . . 27 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 33 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
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. | |||
Section 4 discusses a deployment model that the authors are | Section 4 discusses a deployment model that the authors are | |||
considering for constrained environments. The model requires minimal | considering for constrained environments. The model requires minimal | |||
amount of configuration, and we believe it is a natural fit with the | amount of configuration, and we believe it is a natural fit with the | |||
typical communication practices in smart object networking | typical communication practices in smart object networking | |||
environments. | environments. | |||
Section 7 discusses the availability of cryptographic libraries. | Section 5 discusses the availability of cryptographic libraries. | |||
Section 8 presents some experiences in implementing cryptography on | Section 6 presents some experiences in implementing cryptography on | |||
small devices using those libraries, including information about | small devices using those libraries, including information about | |||
achievable code sizes and speeds on typical hardware. | achievable code sizes and speeds on typical hardware. | |||
Finally, Section 10 discusses trade-offs involving different types of | Finally, Section 8 discusses trade-offs involving different types of | |||
security approaches. | security approaches. | |||
2. Related Work | 2. Related Work | |||
Constrained Application Protocol (CoAP) [RFC7252] is a light-weight | Constrained Application Protocol (CoAP) [RFC7252] is a light-weight | |||
protocol designed to be used in machine-to-machine applications such | protocol designed to be used in machine-to-machine applications such | |||
as smart energy and building automation. Our discussion uses this | as smart energy and building automation. Our discussion uses this | |||
protocol as an example, but the conclusions may apply to other | protocol as an example, but the conclusions may apply to other | |||
similar protocols. CoAP base specification [RFC7252] outlines how to | similar protocols. CoAP base specification [RFC7252] outlines how to | |||
use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. | use DTLS [RFC6347] and IPsec [RFC4303] for securing the protocol. | |||
DTLS can be applied with pairwise shared keys, raw public keys or | DTLS can be applied with pairwise shared keys, raw public keys or | |||
with certificates. The security model in all cases is mutual | with certificates. The security model in all cases is mutual | |||
authentication, so while there is some commonality to HTTP [RFC7230] | authentication, so while there is some commonality to HTTP [RFC7230] | |||
in verifying the server identity, in practice the models are quite | in verifying the server identity, in practice the models are quite | |||
different. The use of IPsec with CoAP is described with regards to | different. 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]. | |||
[I-D.irtf-t2trg-iot-seccons] documents the different stages in the | ||||
lifecycle of a smart object. Next, it highlights the security | ||||
threats for smart objects and the challenges that one might face to | ||||
protect against these threats. The document also looks at various | ||||
security protocols available, including IKEv2/IPsec [RFC7296], TLS/ | ||||
SSL [RFC5246], DTLS [RFC6347], HIP [RFC7401], | ||||
[I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP [RFC3748]. Lastly, | ||||
[I-D.sarikaya-t2trg-sbootstrapping] discusses bootstrapping | ||||
mechanisms available for resource-constrained IoT devices. | ||||
[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 | |||
skipping to change at page 4, line 7 ¶ | skipping to change at page 4, line 16 ¶ | |||
[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 | ||||
for Internet of Things devices. It also discusses various solutions, | ||||
including IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], | ||||
HIP [RFC7401] [I-D.moskowitz-hip-dex], PANA [RFC5191], and EAP | ||||
[RFC3748]. The draft also discusses various operational scenarios, | ||||
and challenges associated with implementing security mechanisms in | ||||
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: 1) implementation | This section discusses three challenges: 1) implementation | |||
difficulties, 2) practical provisioning problems, 3) layering and | difficulties, 2) practical provisioning problems, 3) layering and | |||
communication models. | communication models. | |||
One of the most often discussed issues in the security for the | One of the most often discussed issues in the security for the | |||
Internet of Things relate to implementation difficulties. The desire | Internet of Things relate to implementation difficulties. The desire | |||
to build small, battery-operated, and inexpensive devices drives the | to build small, battery-operated, and inexpensive devices drives the | |||
creation of devices with a limited protocol and application suite. | creation of devices with a limited protocol and application suite. | |||
skipping to change at page 5, line 6 ¶ | skipping to change at page 4, line 51 ¶ | |||
order: a particular platform with a resource-constrained | order: a particular platform with a resource-constrained | |||
microcontroller is chosen first, and then the security features that | microcontroller is chosen first, and then the security features that | |||
can fit on it are decided. Also, the use of the most lightweight | can fit on it are decided. Also, the use of the most lightweight | |||
algorithms and cryptographic primitives is useful, but should not be | algorithms and cryptographic primitives is useful, but should not be | |||
the only consideration in the design and development. | the only consideration in the design and development. | |||
Interoperability is also important, and often other parts of the | Interoperability is also important, and often other parts of the | |||
system, such as key management protocols or certificate formats are | system, such as key management protocols or certificate formats are | |||
heavier to implement than the algorithms themselves. | heavier to implement than the algorithms themselves. | |||
The second challenge relates to practical provisioning problems. | The second challenge relates to practical provisioning problems. | |||
These are perhaps the most fundamental and difficult issue, and | This is perhaps the most fundamental and difficult issue, and | |||
unfortunately often neglected in the design. There are several | unfortunately often neglected in the design. There are several | |||
problems in the provisioning and management of smart object networks: | problems in the provisioning and management of smart object networks: | |||
o Small devices have no natural user interface for configuration | o Small devices have no natural user interface for configuration | |||
that would be required for the installation of shared secrets and | that would be required for the installation of shared secrets and | |||
other security-related parameters. Typically, there is no | other security-related parameters. Typically, there is no | |||
keyboard, no display, and there may not even be buttons to press. | keyboard, no display, and there may not even be buttons to press. | |||
Some devices may only have one interface, the interface to the | Some devices may only have one interface, the interface to the | |||
network. | network. | |||
o Manual configuration is rarely, if at all, possible, as the | o Manual configuration is rarely, if at all, possible, as the | |||
necessary skills are missing in typical installation environments | necessary skills are missing in typical installation environments | |||
(such as in family homes). | (such as in family homes). | |||
o There may be a large number of devices. Configuration tasks that | o There may be a large number of devices. Configuration tasks that | |||
may be acceptable when performed for one device may become | may be acceptable when performed for one device may become | |||
unacceptable with dozens or hundreds of devices. | unacceptable with dozens or hundreds of devices. | |||
o Smart object networks may rely on different radio technologies. | ||||
Provisioning methods that rely on specific link-layer features may | ||||
not work with other radio technologies in a heterogeneous network. | ||||
o Network configurations evolve over the lifetime of the devices, as | o Network configurations evolve over the lifetime of the devices, as | |||
additional devices are introduced or addresses change. Various | additional devices are introduced or addresses change. Various | |||
central nodes may also receive more frequent updates than | central nodes may also receive more frequent updates than | |||
individual devices such as sensors embedded in building materials. | individual devices such as sensors embedded in building materials. | |||
In light of the above challenges, small resource-constrained devices | ||||
are often shipped with a single static identity. In many cases, it | ||||
is a single raw public key. These long-term static identities makes | ||||
it easy to track the devices (and their owners) when they move. The | ||||
static identities may also allow an attacker to track these devices | ||||
across ownership changes. | ||||
Finally, layering and communication models present difficulties for | Finally, layering and communication models present difficulties for | |||
straightforward use of the most obvious security mechanisms. Smart | straightforward use of the most obvious security mechanisms. Smart | |||
object networks typically pass information through multiple | object networks typically pass information through multiple | |||
participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end | participating nodes [I-D.arkko-core-sleepy-sensors] and end-to-end | |||
security for IP or transport layers may not fit such communication | security for IP or transport layers may not fit such communication | |||
models very well. The primary reasons for needing middleboxes | models very well. The primary reasons for needing middleboxes | |||
relates to the need to accommodate for sleeping nodes as well to | relates to the need to accommodate for sleeping nodes as well to | |||
enable the implementation of nodes that store or aggregate | enable the implementation of nodes that store or aggregate | |||
information. | information. | |||
skipping to change at page 6, line 10 ¶ | skipping to change at page 6, line 24 ¶ | |||
[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. | here denotes the concatenation | optional other information. | here denotes the concatenation | |||
operator. | operator. | |||
5. Provisioning | 4.1. Provisioning | |||
As it is difficult to provision security credentials, shared secrets, | As it is difficult to provision security credentials, shared secrets, | |||
and policy information, 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. | |||
skipping to change at page 6, line 46 ¶ | skipping to change at page 7, line 11 ¶ | |||
installation time. This requires either a separate user interface, | installation time. This requires either a separate user interface, | |||
local connection (such as USB), or using the network interface of the | local connection (such as USB), or using the network interface of the | |||
device for configuration. In any case, as with sensor networks the | device for configuration. In any case, as with sensor networks the | |||
amount of configuration information is minimized: just one short | amount of configuration information is minimized: just one short | |||
identity value needs to be fed in. Not both an identity and a | identity value needs to be fed in. Not both an identity and a | |||
certificate. Not shared secrets that must be kept confidential. An | certificate. Not shared secrets that must be kept confidential. An | |||
even simpler provisioning approach is that the devices in the device | even simpler provisioning approach is that the devices in the device | |||
group trust each other. Then no configuration is needed at | group trust each other. Then no configuration is needed at | |||
installation time. | installation time. | |||
When both peers know the expected cryptographic identity of the other | Once both peers know the expected cryptographic identity of the other | |||
peer off-line, secure communications can commence. Alternatively, | peer off-line, secure communications can commence. Alternatively, | |||
various pairing schemes can be employed. Note that these schemes can | various pairing schemes can be employed. Note that these schemes can | |||
benefit from the already secure identifiers on the device side. For | benefit from the already secure identifiers on the device side. For | |||
instance, the server can send a pairing message to each device after | instance, the server can send a pairing message to each device after | |||
their initial power-on and before they have been paired with anyone, | their initial power-on and before they have been paired with anyone, | |||
encrypted with the public key of the device. As with all pairing | encrypted with the public key of the device. As with all pairing | |||
schemes that do not employ a shared secret or the secure identity of | schemes that do not employ a shared secret or the secure identity of | |||
both parties, there are some remaining vulnerabilities that may or | both parties, there are some remaining vulnerabilities that may or | |||
may not be acceptable for the application in question. | may not be acceptable for the application in question. For example, | |||
leap-of-faith or trust-on-first-use based pairing methods assume that | ||||
the attacker is not present during the initial setup and are | ||||
vulnerable to eavesdropping or man-in-the-middle (MitM) attacks. | ||||
In any case, the secure identities help again in ensuring that the | In any case, the secure identities help again in ensuring that the | |||
operations are as simple as possible. Only identities need to be | operations are as simple as possible. Only identities need to be | |||
communicated to the devices, not certificates, not shared secrets or | communicated to the devices, not certificates, not shared secrets or | |||
e.g. IPsec policy rules. | 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 | |||
skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 20 ¶ | |||
communicate with, messages from the peer can be signed by the peer's | communicate with, messages from the peer can be signed by the peer's | |||
private key and it is trivial to verify that the message came from | private key and it is trivial to verify that the message came from | |||
the expected peer. There is no need to configure an identity and | the expected peer. There is no need to configure an identity and | |||
certificate of that identity separately. There is no need to | certificate of that identity separately. There is no need to | |||
configure a group secret or a shared secret. There is no need to | configure a group secret or a shared secret. There is no need to | |||
configure a trust anchor. In addition, the identities are typically | configure a trust anchor. In addition, the identities are typically | |||
collected anyway for application purposes (such as identifying which | collected anyway for application purposes (such as identifying which | |||
sensor is in which room). Under most circumstances there is actually | sensor is in which room). Under most circumstances there is actually | |||
no additional configuration effort from provisioning security. | no additional configuration effort from provisioning security. | |||
As discussed in the previous section, long-term static identities | ||||
negatively affect the privacy of the devices and their owners. | ||||
Therefore, it is beneficial for devices to generate new identities at | ||||
appropriate times during their lifecycle. For example, after a | ||||
factory reset or an ownership handover. Thus, in our proposed | ||||
deployment model, the devices would generate a new asymmetric key | ||||
pair and use the new public-key P' to generate the new identity I'. | ||||
It is also desirable that these identities are only used during the | ||||
provisioning stage. Temporary identities (such as IPv6 addresses) | ||||
can be used for network communication protocols once the device is | ||||
operational. | ||||
Groups of devices can be managed through single identifiers as well. | Groups of devices can be managed through single identifiers as well. | |||
In these deployment cases it is also possible to configure the | In these deployment cases it is also possible to configure the | |||
identity of an entire group of devices, rather than registering the | identity of an entire group of devices, rather than registering the | |||
individual devices. For instance, many installations employ a kit of | individual devices. For instance, many installations employ a kit of | |||
devices bought from the same manufacturer in one package. It is easy | devices bought from the same manufacturer in one package. It is easy | |||
to provide an identity for such a set of devices as follows: | to provide an identity for such a set of devices as follows: | |||
Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) | Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn) | |||
Igrp = h(Pdev1|Pdev2|...|Pdevm) | Igrp = h(Pdev1|Pdev2|...|Pdevm) | |||
skipping to change at page 8, line 31 ¶ | skipping to change at page 9, line 9 ¶ | |||
The installation personnel can scan the identity of the group from | The installation personnel can scan the identity of the group from | |||
the box that the kit came in, and this identity can be stored in a | the box that the kit came in, and this identity can be stored in a | |||
server that is expected to receive information from the nodes. Later | server that is expected to receive information from the nodes. Later | |||
when the individual devices contact this server, they will be able to | when the individual devices contact this server, they will be able to | |||
show that they are part of the group, as they can reveal their own | show that they are part of the group, as they can reveal their own | |||
public key and the public keys of the other devices. Devices that do | public key and the public keys of the other devices. Devices that do | |||
not belong to the kit can not claim to be in the group, because the | not belong to the kit can not claim to be in the group, because the | |||
group identity would change if any new keys were added to Igrp. | group identity would change if any new keys were added to Igrp. | |||
6. Protocol Architecture | 4.2. Protocol Architecture | |||
As noted above, the starting point of the architecture is that nodes | As noted above, the starting point of the architecture is that nodes | |||
self-generate secure identities which are then communicated out-of- | self-generate secure identities which are then communicated out-of- | |||
band to the peers that need to know what devices to trust. To | band to the peers that need to know what devices to trust. To | |||
support this model in a protocol architecture, we also need to use | support this model in a protocol architecture, we also need to use | |||
these secure identities to implement secure messaging between the | these secure identities to implement secure messaging between the | |||
peers, explain how the system can respond to different types of | peers, explain how the system can respond to different types of | |||
attacks such as replay attempts, and decide at what protocol layer | attacks such as replay attempts, and decide at what protocol layer | |||
and endpoints the architecture should use. | and endpoints the architecture should use. | |||
skipping to change at page 9, line 23 ¶ | skipping to change at page 10, line 5 ¶ | |||
such as a protocol translators or even NATs (not that we recommend | such as a protocol translators or even NATs (not that we recommend | |||
their use in these environments). | their use in these environments). | |||
However, as we will see later there are also some technical | However, as we will see later there are also some technical | |||
implications, namely that link, network, and transport layer | implications, namely that link, network, and transport layer | |||
solutions are more likely to be able to benefit from sessions where | solutions are more likely to be able to benefit from sessions where | |||
the cost of expensive operations can be amortized over multiple data | the cost of expensive operations can be amortized over multiple data | |||
transmissions. While this is not impossible in data object security | transmissions. While this is not impossible in data object security | |||
solutions either, it is not the typical arrangement either. | solutions either, it is not the typical arrangement either. | |||
7. Code Availability | 5. 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 RAM, and 32 kB of | processor with a clock speed of 16 MHz, 2 kB of RAM, and 32 kB of | |||
flash memory. Our choice of 8-bit platform may be surprising since | flash memory. Our choice of a 8-bit platform may seem surprising | |||
it. | since cheaper and more energy-efficient 32-bit platforms are | |||
available. However, our intention was to evaluate the performance of | ||||
public-key cryptography on the smallest platforms available. It is | ||||
reasonable to expect better performance results from 32-bit | ||||
microcontrollers. | ||||
For selecting potential asymmetric cryptographic libraries, we | For selecting potential asymmetric cryptographic libraries, we | |||
surveyed and came up with a set of possible code sources, and | surveyed and came up with a set of possible code sources, and | |||
performed an initial analysis of how well they fit the Arduino | performed an initial analysis of how well they fit the Arduino | |||
environment. Note that the results are preliminary, and could easily | environment. Note that the results are preliminary, and could easily | |||
be affected in any direction by implementation bugs, configuration | be affected in any direction by implementation bugs, configuration | |||
errors, and other mistakes. It is advisable to verify the numbers | errors, and other mistakes. It is advisable to verify the numbers | |||
before relying on them for building something. No significant effort | before relying on them for building something. No significant effort | |||
was done to optimize ROM memory usage beyond what the libraries | was done to optimize ROM memory usage beyond what the libraries | |||
provided themselves, so those numbers should be taken as upper | provided themselves, so those numbers should be taken as upper | |||
skipping to change at page 10, line 41 ¶ | skipping to change at page 11, line 28 ¶ | |||
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). The library in the original | and ECC (with a commercial license). The library in the original | |||
form takes about 50 kB of ROM and is intended for 32-bit | form takes about 50 kB of ROM and is intended for 32-bit | |||
platforms. | platforms. | |||
o ARM mbed OS [mbed]: The ARM mbed operating system provides various | o ARM mbed OS [mbed]: The ARM mbed operating system provides various | |||
cryptographic primitives that are necessary for SSL/TLS protocol | cryptographic primitives that are necessary for SSL/TLS protocol | |||
implementation as well as X509 certificate handling. The library | implementation as well as X509 certificate handling. The library | |||
provides an intuitive API for developer with a minimal code | provides an intuitive API for developer with a minimal code | |||
foodprint. It is intended for various ARM platforms such as ARM | footprint. It is intended for various ARM platforms such as ARM | |||
Cortex M0, ARM Cortex M0+ and ARM Cortex M3. | Cortex M0, ARM Cortex M0+ and ARM Cortex M3. | |||
This is by no ways an exhaustive list and there exist other | This is by no ways an exhaustive list and there exist other | |||
cryptographic libraries targeting resource-constrained devices. | cryptographic libraries targeting resource-constrained devices. | |||
8. Implementation Experiences | 6. 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 7 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 | We have summarized the initial results of RSA private key | |||
exponentiation performance using AvrCryptolib [avr-crypto-lib] in | exponentiation performance using AvrCryptolib [avr-crypto-lib] in | |||
Table 1. All results are from a single run since repeating the test | Table 1. All results are from a single run since repeating the test | |||
did not change (or had only minimal impact on) the results. The | did not change (or had only minimal impact on) the results. The | |||
execution time for a key size of 2048 bits was inordinately long and | execution time for a key size of 2048 bits was inordinately long and | |||
would be a deterrent in real-world deployments. | would be a deterrent in real-world deployments. | |||
+--------------+------------------------+---------------------------+ | +--------------+------------------------+---------------------------+ | |||
| Key length | Execution time (ms); | Memory footprint (bytes); | | | Key length | Execution time (ms); | Memory footprint (bytes); | | |||
skipping to change at page 14, line 49 ¶ | skipping to change at page 15, line 30 ¶ | |||
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 The Arduino board only provides pseudo random numbers with the | o The Arduino board only provides pseudo random numbers with the | |||
random() function call. Real-world deployments must rely on a | random() function call. Real-world deployments must rely on a | |||
hardware random number generator for cryptographic operations such | hardware random number generator for cryptographic operations such | |||
as generating a public-private key pair. The Nordic nRF52832 | as generating a public-private key pair. The Nordic nRF52832 | |||
board [nordic] for example provides a hardware random number | board [nordic] for example provides a hardware random number | |||
generator. | generator. A detailed discussion on requirements and best | |||
practices for cryptographic-quality randomness is documented in | ||||
[RFC4086] | ||||
o For measuring the memory footprint of all the ECC libraries, we | o For measuring the memory footprint of all the ECC libraries, we | |||
used the Avrora simulator [avrora]. Only stack memory was used to | used the Avrora simulator [avrora]. Only stack memory was used to | |||
easily track the RAM consumption. | easily track the RAM consumption. | |||
Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the | Tschofenig and Pegourie-Gonnard [armecdsa] have also evaluated the | |||
performance of Elliptic Curve Cryptography (ECC) on ARM Coretex | performance of Elliptic Curve Cryptography (ECC) on ARM Coretex | |||
platform. The results for ECDSA sign operation shown in Table 7 are | platform. The results for ECDSA sign operation shown in Table 7 are | |||
performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM | performed on a Freescale FRDM-KL25Z board [freescale] that has a ARM | |||
Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB | Cortex-M0+ 48MHz microcontroller with 128kB of flash memory and 16kB | |||
skipping to change at page 17, line 35 ¶ | skipping to change at page 18, line 9 ¶ | |||
All the measurements here are only provided as an example to show | All the measurements here are only provided as an example to show | |||
that asymmetric-key cryptography (particularly, digital signatures) | that asymmetric-key cryptography (particularly, digital signatures) | |||
is possible on resource-constrained devices. These numbers by no way | is possible on resource-constrained devices. These numbers by no way | |||
are the final source for measurements and some curves presented here | are the final source for measurements and some curves presented here | |||
may not be acceptable for real in-the-wild deployments anymore. For | may not be acceptable for real in-the-wild deployments anymore. For | |||
example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also | example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also | |||
document performance of ECDSA on similar resource-constrained | document performance of ECDSA on similar resource-constrained | |||
devices. | devices. | |||
9. Example Application | 7. Example Application | |||
We developed an example application on the Arduino platform to use | We developed an example application on the Arduino platform to use | |||
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. | |||
skipping to change at page 19, line 40 ¶ | skipping to change at page 20, line 15 ¶ | |||
While compiling Relic for our prototype, we used the fast | While compiling Relic for our prototype, we used the fast | |||
configuration without any assembly optimizations. | configuration without any assembly optimizations. | |||
The gateway implements the CoAP base specification in the Java | The gateway implements the CoAP base specification in the Java | |||
programming language and extends it to add support for publish- | programming language and extends it to add support for publish- | |||
subscribe broker and Resource Directory REST interfaces. We also | subscribe broker and Resource Directory REST interfaces. We also | |||
developed a minimalistic CoAP C-library for the Arduino sensor and | developed a minimalistic CoAP C-library for the Arduino sensor and | |||
for the client requesting data updates for a resource. The library | for the client requesting data updates for a resource. The library | |||
has small RAM requirements and uses stack-based allocation only. It | has small RAM requirements and uses stack-based allocation only. It | |||
is interoperable with the Java implementation of CoAP running on the | is interoperable with the Java implementation of CoAP running on the | |||
gateway. The location of the publish-subscribe broker was configured | gateway. The location of the resource directory was configured into | |||
into the smart object sensor by hardcoding the IP address. | the smart object sensor by hardcoding the IP address. | |||
Our intention was to demonstrate that it is possible to implement the | Our intention was to demonstrate that it is possible to implement the | |||
entire architecture with public-key cryptography on an 8-bit | 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 RAM | considerable amount. For example, the flash memory and RAM | |||
consumption is relatively high because some of the Arduino libraries | consumption is relatively high because some of the Arduino libraries | |||
were used out-of-the-box and there are several functions which can be | were used out-of-the-box and there are several functions which can be | |||
removed. Similarly we used the fast version of the Relic library in | removed. Similarly we used the fast version of the Relic library in | |||
the prototype instead of the low memory version. However, it is | the prototype instead of the low memory version. However, it is | |||
important to note that this was only a research prototype to verify | important to note that this was only a research prototype to verify | |||
the feasibility of this architecture and as stated elsewhere, most | the feasibility of this architecture and as stated elsewhere, most | |||
modern development boards have a 32-bit microcontroller since they | modern development boards have a 32-bit microcontroller since they | |||
are more economical and have better energy efficiency. | are more economical and have better energy efficiency. | |||
10. Design Trade-Offs | 8. 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. In particular, this analysis looks at layering, | |||
symmetric vs. asymmetric cryptography. | freshness and the choice of symmetric vs. asymmetric cryptography. | |||
11. Feasibility | 8.1. Feasibility | |||
The first question is whether using cryptographic security and | The first question is whether using cryptographic security and | |||
asymmetric cryptography in particular is feasible at all on small | asymmetric cryptography in particular is feasible at all on small | |||
devices. The numbers above give a mixed message. Clearly, an | devices. The numbers above give a mixed message. Clearly, an | |||
implementation of a significant cryptographic operation such as | implementation of a significant cryptographic operation such as | |||
public key signing can be done in surprisingly small amount of code | public key signing can be done in surprisingly small amount of code | |||
space. It could even be argued that our chosen prototype platform | space. It could even be argued that our chosen prototype platform | |||
was unnecessarily restrictive in the amount of code space it allows: | was unnecessarily restrictive in the amount of code space it allows: | |||
we chose this platform on purpose to demonstrate something that is as | we chose this platform on purpose to demonstrate something that is as | |||
small and difficult as possible. | small and difficult as possible. | |||
skipping to change at page 21, line 9 ¶ | skipping to change at page 21, line 32 ¶ | |||
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 very small (less than 500 ms). | execution times can actually be very small (less than 500 ms). | |||
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 turn the radio on/off and sending or receiving | |||
needed to execute cryptographic operations. While there are newer | messages are far bigger than those needed to execute cryptographic | |||
radios that significantly lower the energy consumption of sending | operations. While there are newer radios that significantly lower | |||
and receiving messages, there is no good reason to choose | the energy consumption of sending and receiving messages, there is | |||
platforms that do not provide sufficient computing power to run | no good reason to choose platforms that do not provide sufficient | |||
the necessary cryptographic operations. | 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 memo. | 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 | While we did not do an exhaustive performance evaluation of | |||
asymmetric key pair generation on resource-constrained devices, we | ||||
did note that it is possible for such devices to generate a new key | ||||
pair. Given that this operation would only occur in rare | ||||
circumstances (such as a factory reset or ownership change) and its | ||||
potential privacy benefits, developers should provide mechanisms for | ||||
generating new identities. It is however extremely important to note | ||||
that the security of this operation relies on access to | ||||
cryptographic-quality randomness. | ||||
8.2. 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 publish- | along with their signatures sent from the sensors to the publish- | |||
subscribe broker can be recorded and replayed by an eavesdropper. | subscribe broker can be recorded and replayed by an eavesdropper. | |||
The publish-subscribe broker has no mechanism to distinguish | The publish-subscribe broker has no mechanism to distinguish | |||
previously received packets from those that are retransmitted by the | previously received packets from those that are retransmitted by the | |||
sender or replayed by an eavesdropper. Therefore, it is essential | sender or replayed by an eavesdropper. Therefore, it is essential | |||
for the smart objects to ensure that data updates include a freshness | for the smart objects to ensure that data updates include a freshness | |||
indicator. However, ensuring freshness on constrained devices can be | indicator. However, ensuring freshness on constrained devices can be | |||
non-trivial because of several reasons which include: | non-trivial because of several reasons which include: | |||
skipping to change at page 23, line 25 ¶ | skipping to change at page 24, line 10 ¶ | |||
obtain the current time from NTP, but this may consume additional | obtain the current time from NTP, but this may consume additional | |||
energy and give rise to security issues discussed in [RFC5905]. The | energy and give rise to security issues discussed in [RFC5905]. The | |||
smart objects could also have access to a mobile network or the | smart objects could also have access to a mobile network or the | |||
Global Positioning System (GPS), and they can be used obtain the | Global Positioning System (GPS), and they can be used obtain the | |||
current time. Finally, if the sensors need to co-ordinate their | current time. Finally, if the sensors need to co-ordinate their | |||
sleep cycles, or if the publish-subscribe broker computes an average | sleep cycles, or if the publish-subscribe broker computes an average | |||
or mean of updates collected from multiple smart objects, it is | or mean of updates collected from multiple smart objects, it is | |||
important for the network nodes to synchronize the time among them. | important for the network nodes to synchronize the time among them. | |||
This can be done by using existing synchronization schemes. | This can be done by using existing synchronization schemes. | |||
13. Layering | 8.3. 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: | |||
link layer | link layer | |||
skipping to change at page 25, line 11 ¶ | skipping to change at page 25, line 44 ¶ | |||
The downside is that the lower layers are not protected. But | The downside is that the lower layers are not protected. But | |||
again, as long as the data is protected and checked upon every | again, as long as the data is protected and checked upon every | |||
time it passes through an application level entity, it is not | time it passes through an application level entity, it is not | |||
clear that there are attacks beyond denial-of-service. | clear that there are attacks beyond denial-of-service. | |||
The main question mark is whether this type of a solution provides | The main question mark is whether this type of a solution provides | |||
sufficient advantages over the more commonly implemented transport | sufficient advantages over the more commonly implemented transport | |||
and application layer solutions. | and application layer solutions. | |||
14. Symmetric vs. Asymmetric Crypto | 8.4. Symmetric vs. Asymmetric Crypto | |||
The second trade-off that is worth discussing is the use of plain | The second trade-off that is worth discussing is the use of plain | |||
asymmetric cryptographic mechanisms, plain symmetric cryptographic | asymmetric cryptographic mechanisms, plain symmetric cryptographic | |||
mechanisms, or some mixture thereof. | mechanisms, or some mixture thereof. | |||
Contrary to popular cryptographic community beliefs, a symmetric | Contrary to popular cryptographic community beliefs, a symmetric | |||
cryptographic solution can be deployed in large scale. In fact, one | cryptographic solution can be deployed in large scale. In fact, one | |||
of the largest deployment of cryptographic security, the cellular | of the largest deployment of cryptographic security, the cellular | |||
network authentication system, uses SIM cards that are based on | network authentication system, uses SIM cards that are based on | |||
symmetric secrets. In contrast, public key systems have yet to show | symmetric secrets. In contrast, public key systems have yet to show | |||
ability to scale to hundreds of millions of devices, let alone | ability to scale to hundreds of millions of devices, let alone | |||
billions. But the authors do not believe scaling is an important | billions. But the authors do not believe scaling is an important | |||
differentiator when comparing the solutions. | differentiator when comparing the solutions. | |||
As can be seen from the Section 8, the time needed to calculate some | As can be seen from the Section 6, the time needed to calculate some | |||
of the asymmetric cryptographic operations with reasonable key | of the asymmetric cryptographic operations with reasonable key | |||
lengths can be significant. There are two contrary observations that | lengths can be significant. There are two contrary observations that | |||
can be made from this. First, recent wisdom indicates that computing | can be made from this. First, recent wisdom indicates that computing | |||
power on small devices is far cheaper than transmission power | power on small devices is far cheaper than transmission power | |||
[wiman], and keeps on becoming more efficient very quickly. From | [wiman], and keeps on becoming more efficient very quickly. From | |||
this we can conclude that the sufficient CPU is or at least will be | this we can conclude that the sufficient CPU is or at least will be | |||
easily available. | easily available. | |||
But the other observation is that when there are very costly | But the other observation is that when there are very costly | |||
asymmetric operations, doing a key exchange followed by the use of | asymmetric operations, doing a key exchange followed by the use of | |||
generated symmetric keys would make sense. This model works very | generated symmetric keys would make sense. This model works very | |||
well for DTLS and other transport layer solutions, but works less | well for DTLS and other transport layer solutions, but works less | |||
well for data object security, particularly when the number of | well for data object security, particularly when the number of | |||
communicating entities is not exactly two. | communicating entities is not exactly two. | |||
15. Security Considerations | 9. Summary | |||
This document makes several security recommendations based on our | ||||
implementation experience. We summarize some of the important ones | ||||
here: | ||||
o Developers and product designers should choose the hardware after | ||||
determining the security requirements for their application | ||||
scenario. | ||||
o Elliptic Curve Cryptography (ECC) outperforms RSA based operations | ||||
and therefore it is recommended for resource-constrained devices. | ||||
o Cryptographic-quality randomness is needed for many security | ||||
protocols. Developers and vendors should ensure that the | ||||
sufficient randomness is available for security critical tasks. | ||||
o 32-bit microcontrollers are much more easily available, at lower | ||||
costs and are more power efficient. Therefore, real-world | ||||
deployments are better off using 32-bit microcontrollers. | ||||
o Planning for firmware updates is important. The hardware platform | ||||
chosen should at least have a flash memory size of the total code | ||||
size * 2, plus some space for buffer. | ||||
10. Security Considerations | ||||
This entire memo deals with security issues. | This entire memo deals with security issues. | |||
16. IANA Considerations | 11. IANA Considerations | |||
There are no IANA impacts in this memo. | There are no IANA impacts in this memo. | |||
17. Informative references | 12. Informative references | |||
[arduino-uno] | [arduino-uno] | |||
Arduino, "Arduino Uno", September 2015, | Arduino, "Arduino Uno", September 2015, | |||
<http://arduino.cc/en/Main/arduinoBoardUno>. | <http://arduino.cc/en/Main/arduinoBoardUno>. | |||
[armecdsa] | [armecdsa] | |||
Tschofenig, H. and M. Pegourie-Gonnard, "Performance | Tschofenig, H. and M. Pegourie-Gonnard, "Performance | |||
Investigations", March 2015, | Investigations", March 2015, | |||
<https://www.ietf.org/proceedings/92/slides/slides-92- | <https://www.ietf.org/proceedings/92/slides/ | |||
lwig-3.pdf>. | slides-92-lwig-3.pdf>. | |||
[avr-crypto-lib] | [avr-crypto-lib] | |||
AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, | AVR-CRYPTO-LIB, "AVR-CRYPTO-LIB", September 2015, | |||
<http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. | <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. | |||
[avr-cryptolib] | [avr-cryptolib] | |||
Van der Laan, E., "AVR CRYPTOLIB", September 2015, | Van der Laan, E., "AVR CRYPTOLIB", September 2015, | |||
<http://www.emsign.nl/>. | <http://www.emsign.nl/>. | |||
[avrora] Titzer, Ben., "Avrora", September 2015, | [avrora] Titzer, Ben., "Avrora", September 2015, | |||
skipping to change at page 27, line 14 ¶ | skipping to change at page 28, line 20 ¶ | |||
[I-D.ietf-core-coap-pubsub] | [I-D.ietf-core-coap-pubsub] | |||
Koster, M., Keranen, A., and J. Jimenez, "Publish- | Koster, M., Keranen, A., and J. Jimenez, "Publish- | |||
Subscribe Broker for the Constrained Application Protocol | Subscribe Broker for the Constrained Application Protocol | |||
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in | (CoAP)", draft-ietf-core-coap-pubsub-02 (work in | |||
progress), July 2017. | progress), July 2017. | |||
[I-D.ietf-core-resource-directory] | [I-D.ietf-core-resource-directory] | |||
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. | Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. | |||
Amsuess, "CoRE Resource Directory", draft-ietf-core- | Amsuess, "CoRE Resource Directory", draft-ietf-core- | |||
resource-directory-11 (work in progress), July 2017. | resource-directory-12 (work in progress), October 2017. | |||
[I-D.ietf-core-senml] | [I-D.ietf-core-senml] | |||
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. | Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. | |||
Bormann, "Media Types for Sensor Measurement Lists | Bormann, "Media Types for Sensor Measurement Lists | |||
(SenML)", draft-ietf-core-senml-10 (work in progress), | (SenML)", draft-ietf-core-senml-12 (work in progress), | |||
July 2017. | December 2017. | |||
[I-D.irtf-t2trg-iot-seccons] | [I-D.irtf-t2trg-iot-seccons] | |||
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- | Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- | |||
the-Art and Challenges for the Internet of Things | the-Art and Challenges for the Internet of Things | |||
Security", draft-irtf-t2trg-iot-seccons-04 (work in | Security", draft-irtf-t2trg-iot-seccons-09 (work in | |||
progress), June 2017. | progress), December 2017. | |||
[I-D.moskowitz-hip-dex] | [I-D.moskowitz-hip-dex] | |||
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", | Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", | |||
draft-moskowitz-hip-dex-05 (work in progress), January | draft-moskowitz-hip-dex-05 (work in progress), January | |||
2016. | 2016. | |||
[I-D.sarikaya-t2trg-sbootstrapping] | [I-D.sarikaya-t2trg-sbootstrapping] | |||
Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT | Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT | |||
Bootstrapping: A Survey", draft-sarikaya-t2trg- | Bootstrapping: A Survey", draft-sarikaya-t2trg- | |||
sbootstrapping-03 (work in progress), February 2017. | sbootstrapping-03 (work in progress), February 2017. | |||
skipping to change at page 28, line 23 ¶ | skipping to change at page 29, line 32 ¶ | |||
June 2017, <http://infocenter.nordicsemi.com/pdf/ | June 2017, <http://infocenter.nordicsemi.com/pdf/ | |||
nRF52832_PS_v1.3.pdf>. | nRF52832_PS_v1.3.pdf>. | |||
[relic-toolkit] | [relic-toolkit] | |||
Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, | Aranha, D. and C. Gouv, "Relic Toolkit", September 2015, | |||
<http://code.google.com/p/relic-toolkit/>. | <http://code.google.com/p/relic-toolkit/>. | |||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |||
Levkowetz, Ed., "Extensible Authentication Protocol | Levkowetz, Ed., "Extensible Authentication Protocol | |||
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | |||
<http://www.rfc-editor.org/info/rfc3748>. | <https://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>. | <https://www.rfc-editor.org/info/rfc3972>. | |||
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, | ||||
"Randomness Requirements for Security", BCP 106, RFC 4086, | ||||
DOI 10.17487/RFC4086, June 2005, | ||||
<https://www.rfc-editor.org/info/rfc4086>. | ||||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
RFC 4303, DOI 10.17487/RFC4303, December 2005, | RFC 4303, DOI 10.17487/RFC4303, December 2005, | |||
<http://www.rfc-editor.org/info/rfc4303>. | <https://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, <https://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>. | <https://www.rfc-editor.org/info/rfc5246>. | |||
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec | [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec | |||
Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, | Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, | |||
February 2009, <http://www.rfc-editor.org/info/rfc5406>. | February 2009, <https://www.rfc-editor.org/info/rfc5406>. | |||
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, | |||
"Network Time Protocol Version 4: Protocol and Algorithms | "Network Time Protocol Version 4: Protocol and Algorithms | |||
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, | |||
<http://www.rfc-editor.org/info/rfc5905>. | <https://www.rfc-editor.org/info/rfc5905>. | |||
[RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) | [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) | |||
Immediate Carriage and Conveyance of Upper-Layer Protocol | Immediate Carriage and Conveyance of Upper-Layer Protocol | |||
Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, | Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, | |||
January 2011, <http://www.rfc-editor.org/info/rfc6078>. | January 2011, <https://www.rfc-editor.org/info/rfc6078>. | |||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
January 2012, <http://www.rfc-editor.org/info/rfc6347>. | January 2012, <https://www.rfc-editor.org/info/rfc6347>. | |||
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object | [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object | |||
Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, | Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, | |||
<http://www.rfc-editor.org/info/rfc6574>. | <https://www.rfc-editor.org/info/rfc6574>. | |||
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link | |||
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, | |||
<http://www.rfc-editor.org/info/rfc6690>. | <https://www.rfc-editor.org/info/rfc6690>. | |||
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
RFC 7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7230>. | <https://www.rfc-editor.org/info/rfc7230>. | |||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<http://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | |||
2014, <http://www.rfc-editor.org/info/rfc7296>. | 2014, <https://www.rfc-editor.org/info/rfc7296>. | |||
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. | [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. | |||
Henderson, "Host Identity Protocol Version 2 (HIPv2)", | Henderson, "Host Identity Protocol Version 2 (HIPv2)", | |||
RFC 7401, DOI 10.17487/RFC7401, April 2015, | RFC 7401, DOI 10.17487/RFC7401, April 2015, | |||
<http://www.rfc-editor.org/info/rfc7401>. | <https://www.rfc-editor.org/info/rfc7401>. | |||
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web | [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web | |||
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May | Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May | |||
2015, <http://www.rfc-editor.org/info/rfc7515>. | 2015, <https://www.rfc-editor.org/info/rfc7515>. | |||
[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, <https://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>. | <https://www.rfc-editor.org/info/rfc7815>. | |||
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital | |||
Signature Algorithm (EdDSA)", RFC 8032, | Signature Algorithm (EdDSA)", RFC 8032, | |||
DOI 10.17487/RFC8032, January 2017, | DOI 10.17487/RFC8032, January 2017, | |||
<http://www.rfc-editor.org/info/rfc8032>. | <https://www.rfc-editor.org/info/rfc8032>. | |||
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", | |||
RFC 8152, DOI 10.17487/RFC8152, July 2017, | RFC 8152, DOI 10.17487/RFC8152, July 2017, | |||
<http://www.rfc-editor.org/info/rfc8152>. | <https://www.rfc-editor.org/info/rfc8152>. | |||
[rsa-8bit] | [rsa-8bit] | |||
Gura, N., Patel, A., Wander, A., Eberle, H., and S. | Gura, N., Patel, A., Wander, A., Eberle, H., and S. | |||
Shantz, "Comparing Elliptic Curve Cryptography and RSA on | Shantz, "Comparing Elliptic Curve Cryptography and RSA on | |||
8-bit CPUs", 2010. | 8-bit CPUs", 2010. | |||
[rsa-high-speed] | [rsa-high-speed] | |||
Koc, C., "High-Speed RSA Implementation", November 1994, | Koc, C., "High-Speed RSA Implementation", November 1994, | |||
<http://cs.ucsb.edu/~koc/docs/r01.pdf>. | <http://cs.ucsb.edu/~koc/docs/r01.pdf>. | |||
End of changes. 63 change blocks. | ||||
96 lines changed or deleted | 168 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |