in Index   Prev   Next

RFC 8387

Practical Considerations and Implementation Experiences in Securing Smart Object Networks

Pages: 33
Part 2 of 2 – Pages 18 to 33
First   Prev   None

Top   ToC   RFC8387 - Page 18   prevText

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
Top   ToC   RFC8387 - Page 19
   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.
Top   ToC   RFC8387 - Page 20
   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.
Top   ToC   RFC8387 - Page 21

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).
Top   ToC   RFC8387 - Page 22
   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.
Top   ToC   RFC8387 - Page 23
   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-
Top   ToC   RFC8387 - Page 24
   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
Top   ToC   RFC8387 - Page 25
      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

   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

      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.
Top   ToC   RFC8387 - Page 26
      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.
Top   ToC   RFC8387 - Page 27

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", <>. [armecdsa] Tschofenig, H. and M. Pegourie-Gonnard, "Performance Investigations", March 2015, < slides-92-lwig-3.pdf>.
Top   ToC   RFC8387 - Page 28
              Das Labor, "AVR-Crypto-Lib", February 2014,

              "AVRCryptoLib", <>.

   [avrora]   Avora, "The AVR Simulation and Analysis Framework",

              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.

              Arkko, J. and A. Keranen, "CoAP Security Architecture",
              Work n Progress, draft-arkko-core-security-arch-00, July

              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.

              ARM Mbed, "FRDM-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

   [HIP-DEX]  Moskowitz, R., Ed. and R. Hummen, "HIP Diet EXchange
              (DEX)", Work in Progress, draft-ietf-hip-dex-06, December

   [huang]    Huang, C., "LOFT: Low-overhead freshness transmission in
              sensor networks", IEEE, DOI 10.1109/SUTC.2008.38, June
Top   ToC   RFC8387 - Page 29
              Sarikaya, B., Sethi, M., and A. Sangi, "Secure IoT
              Bootstrapping: A Survey", Work in Progress,
              draft-sarikaya-t2trg-sbootstrapping-03, February 2017.

              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.

              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.

              Inside Secure, "GUARD TLS Toolkit (formerly Matrix SSL)",

   [mbed]     ARM Mbed, "Mbed TLS",

              MicroNaCl, "The Networking and Cryptography library for
              microcontrollers", <>.

   [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",

   [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,
Top   ToC   RFC8387 - Page 30
   [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, <

              "relic", March 2017,

   [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,

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005,

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,

   [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, <>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5406]  Bellovin, S., "Guidelines for Specifying the Use of IPsec
              Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
              February 2009, <>.
Top   ToC   RFC8387 - Page 31
   [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,

   [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, <>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <>.

   [RFC6574]  Tschofenig, H. and J. Arkko, "Report from the Smart Object
              Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012,

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,

   [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,

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [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, <>.

   [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,

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <>.
Top   ToC   RFC8387 - Page 32
   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <>.

   [RFC7815]  Kivinen, T., "Minimal Internet Key Exchange Version 2
              (IKEv2) Initiator Implementation", RFC 7815,
              DOI 10.17487/RFC7815, March 2016,

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,

   [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.

              Koc, C., "High-Speed RSA Implementation", November 1994,

   [sec2ecc]  Certicom Research, "SEC 2: Recommended Elliptic Curve
              Domain Parameters", Version 2.0, January 2010.

   [stnucleo] STMicroelectronics, "NUCLEO-F091RC",

   [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, <>.

   [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,
Top   ToC   RFC8387 - Page 33


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: Jari Arkko Ericsson Jorvas 02420 Finland Email: Ari Keranen Ericsson Jorvas 02420 Finland Email: Heidi-Maria Back Nokia Helsinki 00181 Finland Email: