RFC 8387
Practical Considerations and Implementation Experiences in Securing Smart Object Networks
Pages: 33
Informational
Informational
Part 2 of 2 – Pages 18 to 33
7. Example Application
We developed an example application on the Arduino platform to use public-key cryptography, data-object security, and an easy provisioning model. Our application was originally developed to test different approaches to supporting communications to "always off" sensor nodes. These battery-operated or energy-scavenging nodes do not have enough power to stay on at all times. They wake up periodically and transmit their readings. Such sensor nodes can be supported in various ways. [CoAP-SENSORS] was an early multicast-based approach. In the current application, we have switched to using resource directories [CoRE-RD] and publish- subscribe brokers [CoAP-BROKER] instead. Architecturally, the idea is that sensors can delegate a part of their role to a node in the network. Such a network node could be either a local resource or something in the Internet. In the case of CoAP publish-subscribe brokers, the network node agrees to hold the web resources on behalf of the sensor, while the sensor is asleep. The only role that the sensor has is to register itself at the publish-subscribe broker and
periodically update the readings. All queries from the rest of the
world go to the publish-subscribe broker.
We constructed a system with four entities:
Sensor: This is an Arduino-based device that runs a CoAP publish-
subscribe broker client and relic-toolkit. Relic takes 29 kB of
flash memory, and the simple CoAP client takes roughly 3 kB.
Publish-Subscribe Broker: This is a publish-subscribe broker that
holds resources on the sensor's behalf. The sensor registers
itself to this node.
Resource Directory: While physically in the same node in our
implementation, a resource directory is a logical function that
allows sensors and publish-subscribe brokers to register resources
in the directory. These resources can be queried by applications.
Application: This is a simple application that runs on a general
purpose computer and can retrieve both registrations from the
resource directory and most recent sensor readings from the
publish-subscribe broker.
The security of this system relies on a secure-shell-like approach.
In Step 1, upon first boot, sensors generate keys and register
themselves in the publish-subscribe broker. Their public key is
submitted along with the registration as an attribute in the CoRE
Link Format data [RFC6690].
In Step 2, when the sensor makes a measurement, it sends an update to
the publish-subscribe broker and signs the message contents with a
JSON Object Signing and Encryption (JOSE) signature on the used JSON
[RFC7515] and Sensor Measurement List (SenML) payload [MT-SenML].
The sensor can also alternatively use CBOR Object Signing and
Encryption (COSE) [RFC8152] for signing the sensor measurement.
In Step 3, any other device in the network -- including the publish-
subscribe broker, resource directory, and the application -- can
check that the public key from the registration corresponds to the
private key used to make the signature in the data update.
Note that checks can be done at any time, and there is no need for
the sensor and the checking node to be awake at the same time. In
our implementation, the checking is done in the application node.
This demonstrates how it is possible to implement end-to-end security
even with the presence of assisting middleboxes.
To verify the feasibility of our architecture, we developed a proof-of-concept prototype. In our prototype, the sensor was implemented using the Arduino Ethernet shield over an Arduino Mega board. Our implementation uses the standard C99 programming language on the Arduino Mega board. In this prototype, the publish-subscribe broker and the Resource Directory (RD) reside on the same physical host. A 64-bit x86 Linux machine serves as the broker and the RD, while a similar but physically distinct 64-bit x86 Linux machine serves as the client that requests data from the sensor. We chose the Relic library version 0.3.1 for our sample prototype as it can be easily compiled for different bit-length processors. Therefore, we were able to use it on the 8-bit processor of the Arduino Mega, as well as on the 64-bit processor of the x86 client. We used ECDSA to sign and verify data updates with the standard sect163k1 curve parameters. While compiling Relic for our prototype, we used the fast configuration without any assembly optimizations. The gateway implements the CoAP base specification in the Java programming language and extends it to add support for publish- subscribe broker and Resource Directory Representational State Transfer (REST) interfaces. We also developed a minimalistic CoAP C-library for the Arduino sensor and for the client requesting data updates for a resource. The library has small RAM requirements and uses stack-based allocation only. It is interoperable with the Java implementation of CoAP running on the gateway. The location of the resource directory was configured into the smart object sensor by hardcoding the IP address. A real implementation based on this prototype would instead use the domain name system for obtaining the location of the resource directory. Our intention was to demonstrate that it is possible to implement the entire architecture with public-key cryptography on an 8-bit microcontroller. The stated values can be improved further by a considerable amount. For example, the flash memory and RAM consumption is relatively high because some of the Arduino libraries were used out of the box, and there are several functions that can be removed. Similarly, we used the fast version of the Relic library in the prototype instead of the low-memory version. However, it is important to note that this was only a research prototype to verify the feasibility of this architecture and, as stated elsewhere, most modern development boards have a 32-bit microcontroller since they are more economical and have better energy efficiency.
8. Design Trade-Offs
This section attempts to make some early conclusions regarding trade- offs in the design space, based on deployment considerations for various mechanisms and the relative ease or difficulty of implementing them. In particular, this analysis looks at layering, freshness, and the choice of symmetric vs. asymmetric cryptography.8.1. Feasibility
The first question is whether using cryptographic security and asymmetric cryptography in particular is feasible at all on resource- constrained devices. The numbers above give a mixed message. Clearly, an implementation of a significant cryptographic operation such as public-key signing can be done in a surprisingly small amount of code space. It could even be argued that our chosen prototype platform was unnecessarily restrictive in the amount of code space it allows: we chose this platform on purpose to demonstrate something that is as resource constrained and difficult as possible. A recent trend in microcontrollers is the introduction of 32-bit CPUs that are becoming cheaper and more easily available than 8-bit CPUs, in addition to being more easily programmable. The flash memory size is probably easier to grow than other parameters in microcontrollers. Flash memory size is not expected to be the most significant limiting factor. Before picking a platform, developers should also plan for firmware updates. This would essentially mean that the platform should at least have a flash memory size of the total code size * 2, plus some space for buffer. The situation is less clear with regards to the amount of CPU power needed to run the algorithms. The demonstrated speeds are sufficient for many applications. For instance, a sensor that wakes up every now and then can likely spend a fraction of a second, or even spend multiple seconds in some cases, for the computation of a signature for the message that it is about to send. Most applications that use protocols such as DTLS that use public-key cryptography only at the beginning of the session would also be fine with any of these execution times. Yet, with reasonably long key sizes, the execution times are in the seconds, dozens of seconds, or even longer. For some applications, this is too long. Nevertheless, these algorithms can successfully be employed in resource-constrained devices for the following reasons: o With the right selection of algorithms and libraries, the execution times can actually be very small (less than 500 ms).
o As discussed in [wiman], in general, the power requirements necessary to turn the radio on/off and sending or receiving messages are far bigger than those needed to execute cryptographic operations. While there are newer radios that significantly lower the energy consumption of sending and receiving messages, there is no good reason to choose platforms that do not provide sufficient computing power to run the necessary cryptographic operations. o Commercial libraries and the use of full potential for various optimizations will provide a better result than what we arrived at in this memo. o Using public-key cryptography only at the beginning of a session will reduce the per-packet processing times significantly. 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. However, it is 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 along with their signatures sent from the sensors to the publish- subscribe broker can be recorded and replayed by an eavesdropper. The publish-subscribe broker has no mechanism to distinguish previously received packets from those that are retransmitted by the sender or replayed by an eavesdropper. Therefore, it is essential for the smart objects to ensure that data updates include a freshness indicator. However, ensuring freshness on constrained devices can be non-trivial because of several reasons, which include: o Communication is mostly unidirectional to save energy. o Internal clocks might not be accurate and may be reset several times during the operational phase of the smart object. o Network time synchronization protocols such as the Network Time Protocol (NTP) [RFC5905] are resource intensive and therefore may be undesirable in many smart object networks.
There are several different methods that can be used in our architecture for replay protection. The selection of the appropriate choice depends on the actual deployment scenario. Including sequence numbers in signed messages can provide an effective method of replay protection. The publish-subscribe broker should verify the sequence number of each incoming message and accept it only if it is greater than the highest previously seen sequence number. The publish-subscribe broker drops any packet with a sequence number that has already been received or if the received sequence number is greater than the highest previously seen sequence number by an amount larger than the preset threshold. Sequence numbers can wrap around at their maximum value; therefore, it is essential to ensure that sequence numbers are sufficiently long. However, including long sequence numbers in packets can increase the network traffic originating from the sensor and can thus decrease its energy efficiency. To overcome the problem of long sequence numbers, we can use a scheme similar to that of Huang [huang], where the sender and receiver maintain and sign long sequence numbers of equal bit lengths, but they transmit only the least-significant bits. It is important for the smart object to write the sequence number into the permanent flash memory after each increment and before it is included in the message to be transmitted. This ensures that the sensor can obtain the last sequence number it had intended to send in case of a reset or a power failure. However, the sensor and the publish-subscribe broker can still end up in a discordant state where the sequence number received by the publish-subscribe broker exceeds the expected sequence number by an amount greater than the preset threshold. This may happen because of a prolonged network outage or if the publish-subscribe broker experiences a power failure for some reason. Therefore, it is essential for sensors that normally send Non-Confirmable data updates to send some Confirmable updates and resynchronize with the publish-subscribe broker if a reset message is received. The sensors resynchronize by sending a new registration message with the current sequence number. Although sequence numbers protect the system from replay attacks, a publish-subscribe broker has no mechanism to determine the time at which updates were created by the sensor. Moreover, if sequence numbers are the only freshness indicator used, a malicious eavesdropper can induce inordinate delays to the communication of signed updates by buffering messages. It may be important in certain smart object networks for sensors to send data updates that include timestamps to allow the publish-subscribe broker to determine the time when the update was created. For example, when the publish-
subscribe broker is collecting temperature data, it may be necessary to know when exactly the temperature measurement was made by the sensor. A simple solution to this problem is for the publish- subscribe broker to assume that the data object was created when it receives the update. In a relatively reliable network with low RTT, it can be acceptable to make such an assumption. However, most networks are susceptible to packet loss and hostile attacks making this assumption unsustainable. Depending on the hardware used by the smart objects, they may have access to accurate hardware clocks, which can be used to include timestamps in the signed updates. These timestamps are included in addition to sequence numbers. The clock time in the smart objects can be set by the manufacturer, or the current time can be communicated by the publish-subscribe broker during the registration phase. However, these approaches require the smart objects to either rely on the long-term accuracy of the clock set by the manufacturer or trust the publish-subscribe broker thereby increasing the potential vulnerability of the system. The smart objects could also obtain the current time from NTP, but this may consume additional energy and give rise to security issues discussed in [RFC5905]. The smart objects could also have access to a mobile network or the Global Positioning System (GPS), and they can be used obtain the current time. Finally, if the sensors need to coordinate their sleep cycles, or if the publish-subscribe broker computes an average or mean of updates collected from multiple smart objects, it is important for the network nodes to synchronize the time among them. This can be done by using existing synchronization schemes.8.3. Layering
It would be useful to select just one layer where security is provided at. Otherwise, a simple device needs to implement multiple security mechanisms. While some code can probably be shared across such implementations (like algorithms), it is likely that most of the code involving the actual protocol machinery cannot. Looking at the different layers, here are the choices and their implications: link layer: This is probably the most common solution today. The primary benefits of this choice of layer are that security services are commonly available (WLAN secrets, cellular SIM cards, etc.) and that their application protects the entire communications. The main drawback is that there is no security beyond the first hop. This can be problematic, e.g., in many devices that communicate to a server in the Internet. A smart home weighing scale, for instance, can support WLAN security, but without some
level of end-to-end security, it would be difficult to prevent
fraudulent data submissions to the servers.
Another drawback is that some commonly implemented link-layer
security designs use group secrets. This allows any device within
the local network (e.g., an infected laptop) to attack the
communications.
network layer: There are a number of solutions in this space and
many new ones and variations thereof being proposed: IPsec, PANA,
and so on. In general, these solutions have similar
characteristics to those in the transport layer: they work across
forwarding hops but only as far as to the next middlebox or
application entity. There is plenty of existing solutions and
designs.
Experience has shown that it is difficult to control IP-layer
entities from an application process. While this is theoretically
easy, in practice the necessary APIs do not exist. For instance,
most IPsec software has been built for the VPN use case and is
difficult or impossible to tweak to be used on a per-application
basis. As a result, the authors are not particularly enthusiastic
about recommending these solutions.
transport and application layer: This is another popular solution
along with link-layer designs. TLS with HTTP (HTTPS) and DTLS
with CoAP are examples of solutions in this space and have been
proven to work well. These solutions are typically easy to take
into use in an application, without assuming anything from the
underlying OS, and they are easy to control as needed by the
applications. The main drawback is that generally speaking, these
solutions only run as far as the next application level entity.
And even for this case, HTTPS can be made to work through proxies,
so this limit is not unsolvable. Another drawback is that attacks
on the link layer, network layer, and in some cases, transport
layer, cannot be protected against. However, if the upper layers
have been protected, such attacks can at most result in a denial
of service. Since denial of service can often be caused anyway,
it is not clear if this is a real drawback.
data-object layer: This solution does not protect any of the
protocol layers but protects individual data elements being sent.
It works particularly well when there are multiple application-
layer entities on the path of the data. Smart object networks are
likely to employ such entities for storage, filtering, aggregation
and other reasons, and as such, an end-to-end solution is the only
one that can protect the actual data.
The downside is that the lower layers are not protected. But
again, as long as the data is protected and checked upon every
time it passes through an application-level entity, it is not
clear that there are attacks beyond denial of service.
The main question mark is whether this type of a solution provides
sufficient advantages over the more commonly implemented transport
and application-layer solutions.
8.4. Symmetric vs. Asymmetric Crypto
The second trade-off that is worth discussing is the use of plain
asymmetric cryptographic mechanisms, plain symmetric cryptographic
mechanisms, or some mixture thereof.
Contrary to popular cryptographic community beliefs, a symmetric
cryptographic solution can be deployed in large scale. In fact, one
of the largest deployments of cryptographic security, the cellular
network authentication system, uses Subscriber Identification Module
(SIM) cards that are based on symmetric secrets. In contrast,
public-key systems have yet to show an ability to scale to hundreds
of millions of devices, let alone billions. But the authors do not
believe scaling is an important differentiator when comparing the
solutions.
As can be seen from Section 6, the time needed to calculate some of
the asymmetric cryptographic operations with reasonable key lengths
can be significant. There are two contrary observations that can be
made from this. First, recent wisdom indicates that computing power
on resource-constrained devices is far cheaper than transmission
power [wiman], and it keeps on becoming more efficient very quickly.
From this we can conclude that the sufficient CPU is or at least will
be easily available.
But the other observation is that when there are very costly
asymmetric operations, doing a key exchange followed by the use of
generated symmetric keys would make sense. This model works very
well for DTLS and other transport-layer solutions, but it works less
well for data-object security, particularly when the number of
communicating entities is not exactly two.
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 ECC outperforms RSA-based operations; 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 Developers should provide mechanisms for devices to generate new identities at appropriate times during their life cycle, for example, after a factory reset or an ownership handover. 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.11. IANA Considerations
This document has no IANA actions.12. Informative References
[arduino-uno] Arduino, "Arduino Uno REV3", <http://arduino.cc/en/Main/arduinoBoardUno>. [armecdsa] Tschofenig, H. and M. Pegourie-Gonnard, "Performance Investigations", March 2015, <https://www.ietf.org/proceedings/92/slides/ slides-92-lwig-3.pdf>.
[avr-crypto-lib] Das Labor, "AVR-Crypto-Lib", February 2014, <http://www.das-labor.org/wiki/AVR-Crypto-Lib/en>. [avr-cryptolib] "AVRCryptoLib", <http://www.emsign.nl/>. [avrora] Avora, "The AVR Simulation and Analysis Framework", <http://compilers.cs.ucla.edu/avrora/>. [CoAP-BROKER] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, March 2018. [CoAP-SECURITY] Arkko, J. and A. Keranen, "CoAP Security Architecture", Work n Progress, draft-arkko-core-security-arch-00, July 2011. [CoAP-SENSORS] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", Wok in Progress, draft-arkko-core-sleepy-sensors-01, July 2011. [CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-13, March 2018. [freescale] ARM Mbed, "FRDM-KL25Z", <https://developer.mbed.org/platforms/KL25Z/>. [hahmos] Hahm, O., Baccelli, E., Petersen, H., and N. Tsiftes, "Operating systems for low-end devices in the internet of things: a survey", IEEE Internet of Things Journal, Vol. 3, Issue 5, DOI 10.1109/JIOT.2015.2505901, October 2016. [HIP-DEX] Moskowitz, R., Ed. and R. Hummen, "HIP Diet EXchange (DEX)", Work in Progress, draft-ietf-hip-dex-06, December 2017. [huang] Huang, C., "LOFT: Low-overhead freshness transmission in sensor networks", IEEE, DOI 10.1109/SUTC.2008.38, June 2008.
[IoT-BOOTSTRAPPING] Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT Bootstrapping: A Survey", Work in Progress, draft-sarikaya-t2trg-sbootstrapping-03, February 2017. [IoT-SECURITY] Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-the-Art and Challenges for the Internet of Things Security", Work in Progress, draft-irtf-t2trg-iot-seccons-14, April 2018. [IPV6-LOWPAN-SEC] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. Laganier, "IPv6 over Low Power WPAN Security Analysis", Work in Progress, draft-daniel-6lowpan-security- analysis-05, March 2011. [matrix-ssl] Inside Secure, "GUARD TLS Toolkit (formerly Matrix SSL)", <http://www.matrixssl.org/>. [mbed] ARM Mbed, "Mbed TLS", <https://www.mbed.com/en/technologies/security/mbed-tls/>. [micronacl] MicroNaCl, "The Networking and Cryptography library for microcontrollers", <http://munacl.cryptojedi.org/>. [mosdorf] Mosdorf, M. and W. Zabolotny, "Implementation of elliptic curve cryptography for 8-bit and 32-bit embedded systems - time efficiency and power consumption analysis", Pomiary Automatyka Kontrola, 2010. [MT-SenML] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", Work in Progress, draft-ietf-core-senml-15, May 2018. [nacl] NaCl, "Networking and Cryptography library", <http://nacl.cr.yp.to/>. [naclavr] Hutter, M. and P. Schwabe, "NaCl on 8-Bit AVR Microcontrollers", International Conference on Cryptology in Africa, Computer Science, Vol. 7918, pp. 156-172, February 2013, <https://doi.org/10.1007/978-3-642-38553-7_9>.
[nesC] Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., and D. Culler, "The nesC language: A holistic approach to networked embedded systems", ACM SIGPLAN Notices, Vol. 38, Issue 5, DOI 10.1145/781131.781133, 2003. [nordic] Nordic Semiconductor, "nRF52832 Product Specification v1.3", March 2017, <http://infocenter.nordicsemi.com/pdf/ nRF52832_PS_v1.3.pdf>. [relic-toolkit] "relic", March 2017, <https://github.com/relic-toolkit/relic>. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <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)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>. [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <https://www.rfc-editor.org/info/rfc5191>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, February 2009, <https://www.rfc-editor.org/info/rfc5406>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>. [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, DOI 10.17487/RFC6078, January 2011, <https://www.rfc-editor.org/info/rfc6078>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, <https://www.rfc-editor.org/info/rfc6574>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>. [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015, <https://www.rfc-editor.org/info/rfc7401>. [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>. [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, <https://www.rfc-editor.org/info/rfc7815>. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>. [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>. [rsa-8bit] Gura, N., Patel, A., Wander, A., Eberle, H., and S. Shantz, "Comparing Elliptic Curve Cryptography and RSA on 8-bit CPUs", DOI 10.1007/978-3-540-28632-5_9, 2004. [rsa-high-speed] Koc, C., "High-Speed RSA Implementation", November 1994, <http://storage.jak-stik.ac.id/rsasecurity/tr201.pdf>. [sec2ecc] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, January 2010. [stnucleo] STMicroelectronics, "NUCLEO-F091RC", <http://www.st.com/en/evaluation-tools/ nucleo-f091rc.html/>. [tinyecc] Liu, A. and P. Nig, "TinyECC: A Configurable Library for Elliptic Curve Cryptography in Wireless Sensor Networks (Version 2.0)", NCSU College of Engineering, February 2011, <http://discovery.csc.ncsu.edu/software/TinyECC/>. [wiman] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Paulo, S., Carvalho, T., Naslund, M., and R. Gold, "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds", Proceedings of the 19th International Conference on Computer Communciations and Networks, DOI 10.1109/ICCCN.2010.5560028, 2010. [wiselib] "wiselib", February 2015, <https://github.com/ibr-alg/wiselib>.
Acknowledgments
The authors would like to thank Mats Naslund, Salvatore Loreto, Bob Moskowitz, Oscar Novo, Vlasios Tsiatsis, Daoyuan Li, Muhammad Waqas, Eric Rescorla, and Tero Kivinen for interesting discussions in this problem space. The authors would also like to thank Diego Aranha for helping with the relic-toolkit configurations and Tobias Baumgartner for helping with questions regarding wiselib. Tim Chown, Samita Chakrabarti, Christian Huitema, Dan Romascanu, Eric Vyncke, and Emmanuel Baccelli provided valuable comments that helped us improve this document.Authors' Addresses
Mohit Sethi Ericsson Jorvas 02420 Finland Email: mohit@piuha.net Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Heidi-Maria Back Nokia Helsinki 00181 Finland Email: heidi.back@nokia.com