RFC 8387

Practical Considerations and Implementation Experiences in Securing Smart Object Networks

📅 published May 2018, from ietf

Practical Considerations and Implementation Experiences in Securing Smart Object Networks ✨

(part 1 of 10 🧩)

Okay bestie, here's the header tea 🫖. This is RFC 8387, published by the IETF in May 2018 🎀. The authors are M. Sethi, J. Arkko, and A. Keranen from Ericsson, plus H. Back from Nokia 🫶. It's Informational, so it isn't a Standards Track spec. It's here to share experiences, not lay down rules 🌸. The ISSN is 2070-1721. The header doesn't list any RFC it obsoletes or updates, so it isn't replacing or patching anything else 💅.

Abstract

Okay so this memo is all about the struggles of securing resource-constrained smart object devices 🧸, aka tiny gadgets without much power or memory 🥺. It describes a possible deployment model where those little devices sign message objects ✍️. It also talks about whether cryptographic libraries are actually available for them 📚, and shares some preliminary experiences using those libraries for message signing on constrained devices 🔐. Lastly, it covers the trade-offs between different kinds of security approaches 💖.

Status of This Memo

This document is not an Internet Standards Track specification, it's just published for info 🦋.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for the full story 👑.

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8387 💌.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 📜. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License 🫧.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Challenges  . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Proposed Deployment Model . . . . . . . . . . . . . . . . . .   6
  4.1.  Provisioning  . . . . . . . . . . . . . . . . . . . . . .   6
  4.2.  Protocol Architecture . . . . . . . . . . . . . . . . . .   9
5.  Code Availability . . . . . . . . . . . . . . . . . . . . . .  10
6.  Implementation Experiences  . . . . . . . . . . . . . . . . .  12
7.  Example Application . . . . . . . . . . . . . . . . . . . . .  18
8.  Design Trade-Offs . . . . . . . . . . . . . . . . . . . . . .  21
  8.1.  Feasibility . . . . . . . . . . . . . . . . . . . . . . .  21
  8.2.  Freshness . . . . . . . . . . . . . . . . . . . . . . . .  22
  8.3.  Layering  . . . . . . . . . . . . . . . . . . . . . . . .  24
  8.4.  Symmetric vs. Asymmetric Crypto . . . . . . . . . . . . .  26
9.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
10. Security Considerations . . . . . . . . . . . . . . . . . . .  27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
12. Informative References  . . . . . . . . . . . . . . . . . . .  27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  33
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1. Introduction ✨

Okay so this memo is about the challenges of securing smart object devices in constrained implementations and environments 🧸. In Section 3, we get into three specific challenges 🔑: the implementation difficulties you run into on resource-constrained platforms, the problem of provisioning keys, and making the choice of implementing security at the appropriate layer 🍰.

Section 4 talks about a potential deployment model for constrained environments 🌈. The model needs only a minimal amount of configuration, and we believe it's a natural fit with the typical communication practices in smart object networking environments 💜.

Section 5 covers the availability of cryptographic libraries 📚. Section 6 shares experiences implementing cryptography on resource-constrained devices using those libraries, including info about achievable code sizes and speeds on typical hardware 🧁. Section 7 describes an example proof-of-concept prototype implementation. It uses public-key cryptography on resource-constrained devices to provide end-to-end data authenticity and integrity protection 🔐.

Finally, Section 8 discusses trade-offs between different types of security approaches 👑.

The Constrained Application Protocol (CoAP) [RFC7252] is a lightweight protocol designed for machine-to-machine applications like smart energy and building automation ⚡. We use it as our example here, but the conclusions may apply to other similar protocols 🌸. The CoAP base specification [RFC7252] outlines how to use DTLS [RFC6347] and IPsec [RFC4303] to secure the protocol 🔒. DTLS can be applied with pairwise shared keys, raw public keys, or certificates 🗝️.

In every case, the security model is mutual authentication. So yes, there's some commonality with HTTP [RFC7230] when it comes to verifying the server identity, but in practice the models are pretty different 🙈. The use of IPsec with CoAP is described with regard to the protocol requirements, and it notes that lightweight implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) exist [RFC7815] ✨. However, the CoAP specification is silent on policy and the other stuff you normally need for interoperable use of IPsec in any environment [RFC5406] 💀.

[IoT-SECURITY] walks through the different stages in the life cycle of a smart object 🔄. Then it highlights the security threats for smart objects and the challenges you might face protecting against them 😬. It also looks at a bunch of security protocols: IKEv2/IPsec [RFC7296], TLS/SSL [RFC5246], DTLS [RFC6347], the Host Identity Protocol (HIP) [RFC7401], HIP Diet EXchange [HIP-DEX], a Protocol for Carrying Authentication for Network Access (PANA) [RFC5191], and the Extensible Authentication Protocol (EAP) [RFC3748] 🧚. Lastly, [IoT-BOOTSTRAPPING] discusses bootstrapping mechanisms for resource-constrained Internet of Things (IoT) devices 🥾.

[RFC6574] gives an overview of the security discussions at the March 2011 IAB workshop on smart objects 🍓. The workshop recommended more work on three things: developing suitable credential management mechanisms (maybe something like the Bluetooth pairing mechanism) 🔑, understanding how implementable standard security mechanisms are on resource-constrained devices 🛠️, and doing more research into lightweight cryptographic primitives 🧪.

[HIP-DEX] defines a lightweight version of the HIP protocol for low-power nodes 🔋. It uses a fixed set of algorithms, Elliptic Curve Cryptography (ECC), and it eliminates hash functions 🤏. The protocol still operates based on host identities and runs end-to-end between hosts, protecting all IP-layer communications 🛡️. [RFC6078] describes an extension of HIP that can send upper-layer protocol messages without running the usual HIP base exchange at all 🚀.

[IPV6-LOWPAN-SEC] makes a comprehensive analysis of security issues related to IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) networks 📡. Its findings also apply more generally to all low-powered networks 🌙. Some of the issues it covers include the need to minimize the number of transmitted bits and simplify implementations 🫧, threats in smart object networking environments 👀, and how suitable 6LoWPAN security mechanisms, IPsec, and key management protocols are for these environments 💅.

3. Challenges ✨

okay so this section is about three challenges: 1) implementation difficulties, 2) practical provisioning problems, and 3) layering and communication models 🧚

First up, implementation difficulties. Everyone loves to talk about these when it comes to security for the Internet of Things 💅 The goal is to build devices that are resource-constrained, battery-operated, and cheap, so they end up with a limited protocol and application suite. Some typical limitations are running CoAP instead of HTTP, limited support for security mechanisms, limited processing power for long key lengths, and a sleep schedule that doesn't allow communication at all times, and so on 😭 On top of that, these devices usually have very limited support for configuration, which makes it hard to set up secrets and trust anchors. Lowkey a nightmare 💀

Now, the implementation difficulties are important, but they should not be overemphasized 🙈 It's important to pick the right security mechanisms and avoid duplicated or unnecessary functionality. But at the end of the day, if strong cryptographic security is needed, the implementations have to support that 🔥 It's also important for developers and product designers to figure out which security threats they want to tackle, plus the resulting security requirements, before picking the hardware. Honestly, development in the wild often happens in the wrong order 😩 Someone picks a platform with a resource-constrained microcontroller first, and then decides which security features can fit on it. The most lightweight algorithms and cryptographic primitives are useful, but they should not be the only thing you consider in the design and development 🎀 Interoperability matters too, and other parts of the system, like key management protocols or certificate formats, are often heavier to implement than the algorithms themselves.

The second challenge is practical provisioning problems 🌸 This is perhaps the most fundamental and difficult issue, and it's unfortunately often neglected in the design. There are several problems in provisioning and managing smart object networks:

  • Resource-constrained devices have no natural user interface for configuration, which would be required for installing shared secrets and other security-related parameters. Typically there's no keyboard or display, and there may not even be buttons to press. Some devices may only have one interface, the interface to the network. 😭
  • Manual configuration is rarely, if ever, possible, because the necessary skills are missing in typical installation environments (like family homes) 🏠
  • There may be a large number of devices. Configuration tasks that are fine for one device may become unacceptable with dozens or hundreds of devices 💀
  • 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 📡
  • Network configurations evolve over the lifetime of the devices, as additional devices are introduced or addresses change. Central nodes may also get more frequent updates than individual devices, like sensors embedded in building materials 🧱

So, given all of that, resource-constrained devices are often shipped with a single static identity. In many cases, it's a single raw public key 🔑 These long-term static identities make it easy to track the devices (and their owners) when they move. The static identities may also let an attacker track these devices across ownership changes. Not me getting chills 🥶

Last but not least, layering and communication models make it hard to straightforwardly use the most obvious security mechanisms 🦋 Smart object networks typically pass information through multiple participating nodes [CoAP-SENSORS], and end-to-end security for IP or transport layers may not fit these communication models very well. The main reasons for needing middleboxes come down to accommodating sleeping nodes, and enabling nodes that store or aggregate information 🍓

4. Proposed Deployment Model 💜

okay so [CoAP-SECURITY] says the provisioning model is the driver of what kind of security architecture is useful 🧠 This section quickly reintroduces that model so we can talk about the different design alternatives later without getting lost 🫶

The proposed architecture is based on self-generated secure identities, which is giving CGAs vibes [RFC3972] or Host Identity Tags (HITs) [RFC7401]. So basically, we assume the following holds:

I = h(P|O)

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 optional other information. "|" (vertical bar) here denotes the concatenation operator ✨ Main character energy for the identity, no cap 👑

4.1. Provisioning ✨

okay so provisioning security credentials, shared secrets, and policy info is genuinely hard 😭, which is why the whole model is based only on the secure identities 💖. A typical network install means physically placing a bunch of devices and noting each one's identity. That list of short identifiers then gets fed to a central server as the list of authorized devices. After that, secure comms can start with the devices, at least for info flowing from the devices to the server, and that's exactly what sensor networks need 🌸.

This setup is a perfect fit for sensor networks, where info flows from tons of devices into a few servers. But it's not enough on its own for other kinds of apps. Take actuator apps, where a large number of devices need to take commands from somewhere else. There, you need to secure that the commands actually come from an authorized source 🔥.

This can be supported with some extra provisioning effort and optional pairing protocols 🦋. The basic provisioning approach still applies, but there also has to be something that tells the devices who the trusted server(s) are, and there are multiple ways to do that. One simple approach is to feed the identities of the trusted server(s) to the devices at installation time. You can do that through a separate user interface, a local connection (like USB), or the device's network interface for configuration. Same as with sensor networks, the config stays tiny: just one short identity value gets fed in, not both an identity and a certificate or shared secrets that have to stay confidential 🤏. An even simpler approach is for the devices in the device group to trust each other, so no configuration is needed at installation time 💅.

Once both parties who want to communicate know each other's expected cryptographic identity offline, secure communications can start. Or, various pairing schemes can be used instead. These can benefit from the already secure identifiers on the device side. For example, the server can send a pairing message to each device after its initial power-on and before it's been paired with anyone, encrypted with the device's public key. Now, here's the tea ☕: as with all pairing schemes that don't use a shared secret or the secure identity of both parties, there are some leftover vulnerabilities that may or may not be acceptable for the application in question. For example, lots of pairing methods based on "leap of faith" or "trust on first use" assume the attacker isn't present during the initial setup. So they're vulnerable to eavesdropping or man-in-the-middle (MitM) attacks 💀.

Anyway, the secure identities help once again by keeping operations as simple as possible. Only identities need to be communicated to the devices, not certificates, shared secrets, or, e.g., IPsec policy rules 🙌.

Where necessary, the info collected at installation time can also include other application-relevant parameters, like the location or purpose of the devices 📍. That way, the server can know, for instance, that a particular device is the temperature sensor for the kitchen 🍓.

There are a few ways to collect the identity info at installation time 🎀. One simple but not completely secure method is printing the last few digits of the identity on a tiny device just a few millimeters across. Or, the packaging for the device can include the full identity (typically 32 hex digits), retrieved from the device at manufacturing time. The installation personnel can then read it with, for example, a bar code reader they carry around. (Quick reminder: the identities are not secret. The security of the system doesn't depend on the identity info staying hidden from others. The real owner of an identity can always prove ownership with the private key, which never leaves the device 🔐.) Last but not least, the device might use its wired network interface or proximity-based communications, like Near-Field Communications (NFC) or Radio-Frequency Identity (RFID) tags. These interfaces let the device identity be communicated securely to an information gathering device at installation time 🧚.

No matter how the info gets collected, this provisioning model keeps the effort needed to set up security super low 😭✨. Each device generates its own identity in a random, secure key-generation process 🔑. The identities are self-securing, meaning that if you know the identity of the peer you want to talk to, messages from that peer can be signed with the peer's private key, and it's trivial to verify the message came from the expected peer 🫶. You don't need to configure an identity and a certificate for that identity separately. You don't need to configure a group secret or a shared secret. You don't need to configure a trust anchor either. Plus, identities usually get collected anyway for application purposes (like figuring out which sensor is in which room), so under most circumstances there's basically no extra configuration effort for security provisioning 👑.

As we talked about in the previous section, long-term static identities mess with the privacy of the devices and their owners 🙈. So it's beneficial for devices to generate new identities at appropriate times in their life cycle, like after a factory reset or an ownership handover 🔄. In our proposed deployment model, then, the devices would generate a new asymmetric key pair and use the new public-key P' to generate the new identity I'. It's also desirable that these identities are only used during the provisioning stage. Once the device is operational, temporary identities (like dynamic IPv6 addresses) can be used for network communication protocols 🌈.

Groups of devices can be managed through single identifiers too 💜. In these deployment cases, you can configure the identity of an entire group of devices, instead of registering each device one by one. For instance, lots of installations use a kit of devices bought from the same manufacturer in one package 📦. It's easy to give a set like that an identity, like this:

Idev = h(Pdev|Potherdev1|Potherdev2|...|Potherdevn)

Igrp = h(Pdev1|Pdev2|...|Pdevm)

where Idev is the identity of an individual device, Pdev is the public key of that device, Potherdevi are the public keys of other devices in the group, n is all the devices in the group except the device with Pdev as its public key, and m is the total number of devices in the group. So basically, we can define the secure identity of the group (Igrp) as a hash of all the public keys of the devices in the group (Pdevi) 🧮.

The installation personnel can scan the identity of the group from the box the kit came in, and that identity can be stored in a server that's expected to receive info from the nodes 📸. Later, when the individual devices contact that server, they can prove they're part of the group, because they can reveal their own public key and the public keys of the other devices 🫡. Devices that don't belong to the kit can't claim to be in the group, because the group identity would change if any new keys were added to the identity of the group (Igrp). Not me trying to sneak into the group chat 🚫💅.

4.2. Protocol Architecture 🏗️

okay so, as we noted above, the starting point is that nodes self-generate secure identities, which then get communicated out of band to the peers that need to know which devices to trust 🤝. To make this model work in a protocol architecture, we also need to use these secure identities to implement secure messaging between the peers, explain how the system can respond to different types of attacks like replay attempts, and decide which protocol layer and endpoints the architecture should use 🧠.

The deployment itself works with a variety of design choices when it comes to layering and protocol mechanisms 🍰. [CoAP-SECURITY] was mostly focused on employing end-to-end data-object security as opposed to hop-by-hop security. But other approaches are possible too. For instance, HIP in its opportunistic mode could be used to implement largely the same functionality at the IP layer. However, it's our belief that the right layer for this solution is the application layer, and more specifically, the data formats transported in the payload part of CoAP ✨. This approach gives us the following benefits:

  • Ability for intermediaries to act as caches to support different sleep schedules, without the security model being impacted 😴.
  • Ability for intermediaries to be built to perform aggregation, filtering, storage, and other actions, again without impacting the security of the data being transmitted or stored 📦.
  • Ability to operate in the presence of traditional middleboxes, such as a protocol translators or even NATs (not that we recommend their use in these environments) 🙃.

Now, the catch: as we'll see later, link, network, and transport-layer solutions are more likely to benefit from sessions where the cost of expensive operations can be amortized over multiple data transmissions 💸. While this isn't impossible in data-object security solutions, it's generally not the typical arrangement 🥲.

5. Code Availability 💻✨

Okay so, for putting public-key crypto on tiny resource-constrained devices, we picked the Arduino Uno board [arduino-uno] as our test platform 🎀. It has an ATmega328 microcontroller, which is an 8-bit processor running at a clock speed of 16 MHz, with 2 kB of RAM and 32 kB of flash memory. I know, an 8-bit chip sounds kinda unexpected when cheaper and more energy-efficient 32-bit chips exist 🙈. But our whole goal was to see how public-key crypto performs on the most resource-constrained platforms out there, so it made sense. It's totally reasonable to expect better numbers from 32-bit microcontrollers 💜.

For picking which asymmetric crypto libraries to look at, we surveyed a bunch of code sources and did a first pass on how well each one fits the Arduino environment 🔍. Heads up though, these results are preliminary and could be thrown off in any direction by implementation bugs, configuration errors, or other mistakes 😭. Please double-check the numbers before you build anything important with them 🫶. We also didn't put any real effort into optimizing ROM usage beyond what the libraries already did for themselves, so treat those numbers as upper limits 🌸.

Here's the lineup of libraries we found:

  • AVRCryptoLib [avr-cryptolib]: This one gives you symmetric algorithms like AES, plus RSA for asymmetric stuff 🔐. Parts of it are written in AVR 8-bit assembly to shrink the size and boost performance ⚡.
  • Relic-toolkit [relic-toolkit]: Written entirely in C, and wow, it's giving flexible and customizable 👑. It covers RSA and ECC, but also pairing-based asymmetric crypto, Boneh-Lynn-Shacham signatures, and Boneh-Boyen short signatures 🦋. It has added support for curve25519 (for Elliptic Curve Diffie-Hellman key exchange) [RFC7748] and edwards25519 (for elliptic curve digital signatures) [RFC8032] 🌈. There's also an option to build only the components you need for your platform 💅.
  • TinyECC [tinyecc]: Designed for elliptic-curve public-key crypto on sensor networks 🧚. It's written in the nesC programming language [nesC], so it's built for TinyOS specifically 🍓. It can be ported to standard C, either with toolchains or by manually rewriting parts of the code 🛠️. It also has one of the smallest memory footprints of the elliptic curve libraries we surveyed so far 🥹.
  • Wiselib [wiselib]: A generic library for sensor networks with a wide variety of algorithms ✨. The stable version only has routing algorithms, but the test version adds cryptography, localization, topology management, and much more 🌟. It was designed to be easy to interface with operating systems like iSense and Contiki 💖. Since it's written entirely in C++ with a template-based model similar to Boost/CGAL, it can run on any platform directly without using the operating system interfaces at all 🙌. That's the approach we took to test it on the Arduino Uno 🎯.
  • MatrixSSL [matrix-ssl]: A low footprint implementation of several crypto algorithms, including RSA and ECC (ECC needs a commercial license) 💼. In its original form, the library takes about 50 kB of ROM and is intended for 32-bit platforms 🧸.

This list is definitely not exhaustive, and there are other crypto libraries out there that target resource-constrained devices 🌍.

There are also operating systems built specifically for resource-constrained devices 🖥️. These may include libraries and code for security. Hahm et al. [hahmos] surveyed these operating systems, so go check that out if you're curious 📚. The ARM Mbed OS [mbed] is one of them, and it provides various cryptographic primitives needed for SSL/TLS protocol implementation as well as X509 certificate handling 🔏. It gives developers an API with a minimal code footprint 🥰. It's intended for various ARM platforms, like ARM Cortex M0, ARM Cortex M0+, and ARM Cortex M3 💜.

6. Implementation Experiences 🧪💖

Okay, so while we were evaluating our experiences, we were especially interested in the signature generation operation 👀. That's because our example application, which we'll get to in Section 7, only needed signature generation on the resource-constrained platforms 🎯. We summarized the initial results of RSA private-key exponentiation performance using AVRCryptoLib [avr-crypto-lib] in Table 1 📊. Every result comes from a single run, since repeating the test didn't change the results (or only changed them minimally) 🤷‍♀️. The execution time for a 2048-bit key was inordinately long, which would be a major deterrent in real-world deployments 😭💀.

+--------------+------------------------+---------------------------+
| Key length   | Execution time (ms);   | Memory footprint (bytes); |
| (bits)       | key in RAM             | key in RAM                |
+--------------+------------------------+---------------------------+
| 2048         | 1587567                | 1280                      |
+--------------+------------------------+---------------------------+

            Table 1: RSA Private-Key Operation Performance

The code size was about 3.6 kB, and there's potential for further reduction 📉. It's also worth noting that the implementation does basic exponentiation and multiplication without any mathematical optimizations, like Montgomery multiplication or optimized squaring, as described in [rsa-high-speed] 🧐. We believe that with more RAM, 2048-bit operations could be done in way less time, as shown in [rsa-8bit] 🚀.

In Table 2, we present the results from manually porting TinyECC to the C99 standard and running the Elliptic Curve Digital Signature Algorithm (ECDSA) on the Arduino Uno board 🌸. TinyECC supports a variety of SEC-2-recommended elliptic curve domain parameters [sec2ecc] 🦋. The execution time and memory footprint are shown next to each curve parameter 💅. These results were obtained by turning on all the optimizations and using assembly code where it was available ✨.

The results from the ECDSA performance evaluation in the following tables also have a column with the approximate comparable RSA key length, as documented in [sec2ecc] 🎀. It's clearly observable that for similar security levels, elliptic curve public-key crypto outperforms RSA 👑🔥.

+-------------+---------------+-----------------+-------------------+
| Curve       | Execution     | Memory          | Comparable RSA    |
| parameters  | time (ms)     | footprint       | key length        |
|             |               | (bytes)         |                   |
+-------------+---------------+-----------------+-------------------+
| secp160k1   | 2228          | 892             | 1024              |
| secp160r1   | 2250          | 892             | 1024              |
| secp160r2   | 2467          | 892             | 1024              |
| secp192k1   | 3425          | 1008            | 1536              |
| secp192r1   | 3578          | 1008            | 1536              |
+-------------+---------------+-----------------+-------------------+

      Table 2: Performance of ECDSA Sign Operation with TinyECC

We also ran experiments with the assembly optimization removed, using a C-only form of the library 🧩. This gives us an idea of the performance TinyECC can achieve on any platform, no matter what kind of OS and assembly instruction set is available 🌈. The memory footprint stays the same with or without assembly code 🥳. The tables contain the maximum RAM used when all the possible optimizations are on 📈. However, if the RAM available is smaller, some optimizations can be turned off to reduce memory consumption accordingly 💡.

+-------------+---------------+-----------------+-------------------+
| Curve       | Execution     | Memory          | Comparable RSA    |
| parameters  | time (ms)     | footprint       | key length        |
|             |               | (bytes)         |                   |
+-------------+---------------+-----------------+-------------------+
| secp160k1   | 3795          | 892             | 1024              |
| secp160r1   | 3841          | 892             | 1024              |
| secp160r2   | 4118          | 892             | 1024              |
| secp192k1   | 6091          | 1008            | 1536              |
| secp192r1   | 6217          | 1008            | 1536              |
+-------------+---------------+-----------------+-------------------+

      Table 3: Performance of ECDSA Sign Operation with TinyECC
                     (No Assembly Optimizations)

Table 4 documents the performance of Wiselib 🌷. There were no optimizations that could be turned on or off, so we only have one set of results 🫶. By default, Wiselib only supports some of the standard SEC 2 elliptic curves, but it's easy to change the domain parameters and get results for all the 128-, 160-, and 192-bit SEC 2 elliptic curves 🛠️. The ROM size for all the experiments was less than 16 kB 💜.

+-------------+---------------+-----------------+-------------------+
| Curve       | Execution     | Memory          | Comparable RSA    |
| parameters  | time (ms)     | footprint       | key length        |
|             |               | (bytes)         |                   |
+-------------+---------------+-----------------+-------------------+
| secp160k1   | 10957         | 842             | 1024              |
| secp160r1   | 10972         | 842             | 1024              |
| secp160r2   | 10971         | 842             | 1024              |
| secp192k1   | 18814         | 952             | 1536              |
| secp192r1   | 18825         | 952             | 1536              |
+-------------+---------------+-----------------+-------------------+

       Table 4: Performance ECDSA Sign Operation with Wiselib

For testing the relic-toolkit, we used a different board, because it needed more RAM/ROM and we couldn't run experiments with it on the Arduino Uno 🙃. The Arduino Mega has the same 8-bit architecture as the Arduino Uno, but it has much larger RAM/ROM 🐣. We used the Arduino Mega for experimenting with the relic-toolkit 🎀. Again, it's important to mention that we used Arduino because it's a convenient prototyping platform 🧸. Our goal was to demonstrate the feasibility of the entire architecture with public-key crypto on an 8-bit microcontroller ✨. However, it's important to say that 32-bit microcontrollers are way more easily available, cheaper, and more power efficient 🔋. So real deployments are better off using 32-bit microcontrollers that let developers include the necessary crypto libraries 🫶. There's no good reason to choose platforms that don't have enough computing power to run the necessary crypto operations 🚫💅.

Okay so the relic-toolkit supports Koblitz curves over prime fields AND binary fields 🧚 but we only tested Koblitz curves over binary fields, bestie. We didn't run every curve in the library because this work isn't about crowning the fastest curve 👑 It's about proving that asymmetric crypto is possible on resource-constrained devices 🦋

The relic-toolkit results live in Tables 5 and 6 ✨ The first set was configured for high-speed performance with zero thought given to memory 🔥 The second set was configured for low memory usage, no matter how long each curve takes 🐢 By turning optimizations on and off, you can trade off memory against execution time, and that's giving flexibility 💅

+-----------------+--------------+----------------+-----------------+
| Curve           | Execution    | Memory         | Comparable RSA  |
| parameters      | time (ms)    | footprint      | key length      |
|                 |              | (bytes)        |                 |
+-----------------+--------------+----------------+-----------------+
| sect163k1       | 261          | 2804           | 1024            |
| (assembly math) |              |                |                 |
| sect163k1       | 932          | 2750           | 1024            |
| sect163r2       | 2243         | 2444           | 1024            |
| sect233k1       | 1736         | 3675           | 2048            |
| sect233r1       | 4471         | 3261           | 2048            |
+-----------------+--------------+----------------+-----------------+

          Table 5: Performance of ECDSA Sign Operation with
                        relic-toolkit (Fast)

+-----------------+--------------+----------------+-----------------+
| Curve           | Execution    | Memory         | Comparable RSA  |
| parameters      | time (ms)    | footprint      | key length      |
|                 |              | (bytes)        |                 |
+-----------------+--------------+----------------+-----------------+
| sect163k1       | 592          | 2087           | 1024            |
| (assembly math) |              |                |                 |
| sect163k1       | 2950         | 2215           | 1024            |
| sect163r2       | 3213         | 2071           | 1024            |
| sect233k1       | 6450         | 2935           | 2048            |
| sect233r1       | 6100         | 2737           | 2048            |
+-----------------+--------------+----------------+-----------------+

     Table 6: Performance of ECDSA Sign Operation with relic-toolkit
                              (Low Memory)

Now, a few important points about the elliptic curve measurements, and you need to read these, no skipping 🫶

  • Some boards (e.g., Arduino Uno) do not provide a hardware random number generator 😭 On those boards, getting cryptographic-quality randomness is a real challenge. Real-world deployments must rely on a hardware random number generator for cryptographic operations such as generating a public-private key pair. The Nordic nRF52832 board [nordic], for example, provides a hardware random number generator ✨ For a deep dive into requirements and best practices for cryptographic-quality randomness, check [RFC4086].
  • For measuring the memory footprint of all the ECC libraries, we used the Avrora simulator [avrora] 🌸 Only stack memory was counted, so RAM consumption was easy to track.

Tschofenig and Pegourie-Gonnard [armecdsa] also evaluated ECC performance on an ARM Coretex platform 💜 The ECDSA sign results in Table 7 come from a Freescale FRDM-KL25Z board [freescale], which has an ARM Cortex-M0+ 48MHz microcontroller with 128 kB of flash memory and 16 kB of RAM 🎀 The sliding window technique for efficient exponentiation was used with a window size of 2. All other optimizations were disabled for these measurements.

+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key       |
|                  |                     | length                   |
+------------------+---------------------+--------------------------+
| secp192r1        | 2165                | 1536                     |
| secp224r1        | 3014                | 2048                     |
| secp256r1        | 3649                | 2048                     |
+------------------+---------------------+--------------------------+

  Table 7: Performance of ECDSA Sign Operation with an ARM Mbed TLS
                  Stack on Freescale FRDM-KL25Z

Tschofenig and Pegourie-Gonnard [armecdsa] also measured an ST Nucleo F091 (STM32F091RCT6) board [stnucleo] 🍓 It has an ARM Cortex-M0 48 MHz microcontroller with 256 kB of flash memory and 32 kB of RAM. The ECDSA sign execution times for different curves are in Table 8. The sliding window technique for efficient exponentiation was used with a window size of 7, and fixed-point optimization plus NIST curve-specific optimizations were used for these measurements 💅

+------------------+---------------------+--------------------------+
| Curve parameters | Execution time (ms) | Comparable RSA key       |
|                  |                     | length                   |
+------------------+---------------------+--------------------------+
| secp192k1        | 291                 | 1536                     |
| secp192r1        | 225                 | 1536                     |
| secp224k1        | 375                 | 2048                     |
| secp224r1        | 307                 | 2048                     |
| secp256k1        | 486                 | 2048                     |
| secp256r1        | 459                 | 2048                     |
| secp384r1        | 811                 | 7680                     |
| secp521r1        | 1602                | 15360                    |
+------------------+---------------------+--------------------------+

Table 8: ECDSA Signature Performance with an ARM Mbed TLS Stack on ST
                    Nucleo F091 (STM32F091RCT6)

Finally, Tschofenig and Pegourie-Gonnard [armecdsa] also measured RAM consumption by calculating the heap used for the cryptographic operations, using a custom memory allocation handler 🧠 They did not measure the minimal stack memory consumption. Depending on the curve and which optimizations were enabled or disabled, the memory consumption for the ECDSA sign operation varied from 1500 bytes to 15000 bytes 📊

At the time of these measurements and this study, it was unclear which exact elliptic curve(s) the IETF community would select for resource-constrained devices 🤷‍♀️ But [RFC7748] defines two elliptic curves over prime fields (Curve25519 and Curve448) that offer a high level of practical security for Diffie-Hellman key exchange 🔐 There's also ongoing work to specify elliptic curve signature schemes with the Edwards-curve Digital Signature Algorithm (EdDSA). [RFC8032] specifies the recommended parameters for the edwards25519 and edwards448 curves. Of these, curve25519 (for Elliptic Curve Diffie-Hellman key exchange) and edwards25519 (for elliptic curve digital signatures) are especially suitable for resource-constrained devices 🦋

We found that the NaCl [nacl] and MicoNaCl [micronacl] libraries provide highly efficient implementations of Diffie-Hellman key exchange with curve25519 ✨ The results showed these libraries with curve25519 outperform other elliptic curves offering similar levels of security. Hutter and Schwabe [naclavr] also show that signing data with the curve Ed25519 from the NaCl library needs only 23216241 cycles on the same microcontroller we used for our evaluations (Arduino Mega ATmega2560). That corresponds to about 1451 milliseconds of execution time ⏱️ Compared with other curves and libraries offering a similar level of security (such as sect233r1 and sect233k1), this implementation far outperforms all the others 🏆 So it is recommended that the IETF community use these curves for protocol specification and implementations 💖

A summary of library flash memory use is in Table 9 🌈

   +------------------------+------------------------------------+
   | Library                | Flash memory footprint (kilobytes) |
   +------------------------+------------------------------------+
   | AVRCryptoLib           | 3.6                                |
   | Wiselib                | 16                                 |
   | TinyECC                | 18                                 |
   | Relic-toolkit          | 29                                 |
   | NaCl Ed25519 [naclavr] | 17-29                              |
   +------------------------+------------------------------------+

        Table 9: Summary of Library Flash Memory Consumption
All the measurements here are only an example to show that asymmetric-key cryptography (particularly digital signatures) is possible on resource-constrained devices. By no means are these numbers the final source for measurements, and some curves presented here may no longer be acceptable for real in-the-wild deployments 🙈 For example, Mosdorf et al. [mosdorf] and Liu et al. [tinyecc] also document the performance of ECDSA on similar resource-constrained devices 📚

7. Example Application 🎀

okay so we built an example app on the Arduino platform to play with public-key cryptography, data-object security, and an easy provisioning model 💖 It was originally made to test how to support communication with "always off" sensor nodes. These are battery-operated or energy-scavenging nodes that don't have enough power to stay on all the time 😭 So they wake up now and then, send their readings, and go back to sleep 🌙

There are a few ways to support sensors like this. [CoAP-SENSORS] was an early multicast-based approach. In the current application we switched to resource directories [CoRE-RD] and publish-subscribe brokers [CoAP-BROKER] instead ✨ The architecture idea is that sensors can delegate part of their role to a node in the network. That network node could be a local resource or something out on the Internet. With CoAP publish-subscribe brokers, the network node agrees to hold the web resources on the sensor's behalf while the sensor is asleep 🦋 The only job the sensor has is registering itself and periodically updating the readings. All queries from the rest of the world go to the broker, so the broker is giving main character energy 👑

We constructed a system with four entities:

  • Sensor: 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: a broker that holds resources on the sensor's behalf. The sensor registers itself to this node 🧚
  • Resource Directory: while it lives on the same node in our implementation, a resource directory is a logical function. It lets sensors and publish-subscribe brokers register resources in the directory, and applications can query those resources 💜
  • Application: a simple app that runs on a general purpose computer. It can retrieve both registrations from the resource directory and the most recent sensor readings from the publish-subscribe broker 💅

The security here relies on a secure-shell-like approach, and it's honestly so clean 🔥

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] 🔑

Step 2: when the sensor makes a measurement, it sends an update to the publish-subscribe broker and signs the message contents. It uses a JSON Object Signing and Encryption (JOSE) signature on the JSON [RFC7515] and Sensor Measurement List (SenML) payload [MT-SenML]. The sensor can also use CBOR Object Signing and Encryption (COSE) [RFC8152] to sign the sensor measurement instead ✍️

Step 3: any other device in the network can check that the public key from the registration matches the private key that made the signature in the data update. That includes the publish-subscribe broker, the resource directory, and the application 🕵️‍♀️

Checks can be done at any time, and the sensor and the checking node don't need to be awake at the same time 🌸 In our implementation, the checking happens on the application node. This shows how you can implement end-to-end security even when there are assisting middleboxes in the path 🫶

To check that our architecture is feasible, we built a proof-of-concept prototype 🧪 The sensor was implemented using the Arduino Ethernet shield over an Arduino Mega board. The implementation uses the standard C99 programming language on the Arduino Mega board. In this prototype, the publish-subscribe broker and the Resource Directory (RD) live on the same physical host. A 64-bit x86 Linux machine acts as the broker and the RD, and a similar but physically separate 64-bit x86 Linux machine acts as the client that requests data from the sensor 🖥️

We picked the Relic library version 0.3.1 for the sample prototype because it can be compiled easily for different bit-length processors. That meant we could use it on the 8-bit processor of the Arduino Mega and on the 64-bit processor of the x86 client, which is so iconic 🦋 We used ECDSA to sign and verify data updates with the standard sect163k1 curve parameters. When we compiled Relic for the prototype, we used the fast configuration without any assembly optimizations ⚙️

The gateway implements the CoAP base specification in the Java programming language. It also extends that spec to add support for the publish-subscribe broker and Resource Directory Representational State Transfer (REST) interfaces 🌈 We also built a minimalistic CoAP C library for the Arduino sensor and for the client that requests data updates for a resource. It has small RAM requirements and uses stack-based allocation only. It's interoperable with the Java CoAP implementation 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 to find the resource directory 🌐

Our goal was to show that the entire architecture can run with public-key cryptography on an 8-bit microcontroller 💪 The numbers we measured can be improved a lot. For example, flash memory and RAM use are relatively high because some Arduino libraries were used out of the box, and several functions could be removed. We also used the fast version of the Relic library in the prototype instead of the low-memory version. Still, it's important to note that this was only a research prototype to verify feasibility. 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 tries to draw some early conclusions about the trade-offs in the design space. It's based on deployment considerations for various mechanisms and on how easy or hard they are to implement. The analysis looks at layering, freshness, and the choice between symmetric and asymmetric cryptography 🧠

8.1. Feasibility 🔍

The first question is whether cryptographic security, and asymmetric cryptography in particular, is feasible at all on resource-constrained devices. The numbers above give a mixed message 🥲 On one hand, a significant cryptographic operation like 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 about code space. We picked this platform on purpose to show something as resource constrained and difficult as possible 💅

A recent trend in microcontrollers is 32-bit CPUs getting cheaper and easier to get than 8-bit CPUs, and they're also easier to program ✨ Flash memory size is probably easier to grow than other parameters in microcontrollers, so it isn't expected to be the biggest limiting factor. Developers should also plan for firmware updates before picking a platform. That basically means the platform should have at least total code size * 2 of flash memory, plus some space for buffer 📦

The CPU power needed for the algorithms is less clear 🤔 The demonstrated speeds are fine for many applications. For instance, a sensor that wakes up every now and then can probably spend a fraction of a second, or even several seconds in some cases, computing a signature for the message it's about to send ⏱️ Most applications that use protocols like DTLS, which only use public-key cryptography at the start of the session, would also be fine with any of these execution times 🦋

Still, with reasonably long key sizes, the execution times are in the seconds, dozens of seconds, or even longer. For some applications, that's too long 😩 Even so, these algorithms can be successfully used on resource-constrained devices for the following reasons:

  • With the right selection of algorithms and libraries, the execution times can actually be very small (less than 500 ms). 🏃‍♀️
  • As discussed in [wiman], the power needed to turn the radio on or off and to send or receive messages is generally far bigger than what's needed to run cryptographic operations. Newer radios significantly lower the energy use of sending and receiving messages, but there's no good reason to pick platforms that don't have enough computing power for the necessary cryptographic operations 📡
  • Commercial libraries and full use of the various optimizations will give a better result than what we reached in this memo 🚀
  • Using public-key cryptography only at the beginning of a session will reduce the per-packet processing times significantly 💜

We didn't do an exhaustive performance evaluation of asymmetric key-pair generation on resource-constrained devices. We did note that it's possible for such devices to generate a new key pair 🔐 Since this would only happen in rare circumstances, like a factory reset or an ownership change, and because of 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

Okay bestie, let's talk about freshness 💅🔥. In the architecture as described so far, messages and their signatures that get sent from the sensors to the publish-subscribe broker can be recorded and replayed by an eavesdropper 😭. The broker has no way to tell a packet it already got apart from one that the sender retransmitted or that an eavesdropper replayed 🙈. So the smart objects really need to put a freshness indicator in every data update ✨. But ensuring freshness on constrained devices is not easy, and here's why 💀:

  • Communication is mostly unidirectional to save energy.
  • Internal clocks might not be accurate and may be reset several times during the operational phase of the smart object.
  • 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 methods that can be used for replay protection in our architecture 🌸. Which one you pick depends on the actual deployment scenario 🦋.

Including sequence numbers in signed messages is 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 broker drops any packet whose sequence number has already been received, or whose 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, so it is essential to make sure they are sufficiently long 🌈. The catch is that long sequence numbers in packets increase the network traffic coming from the sensor, which can decrease its energy efficiency 😩. To get around that, 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 only transmit the least-significant bits 🧚.

It is important for the smart object to write the sequence number into permanent flash memory after each increment and before it is included in the message to be transmitted 💾. This way, the sensor can get back the last sequence number it intended to send after a reset or a power failure 🫶. Even so, the sensor and the publish-subscribe broker can still end up in a discordant state, where the sequence number the broker received 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 ⚡. So it is essential for sensors that normally send Non-Confirmable data updates to also send some Confirmable updates, and to 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 🎀.

Sequence numbers protect the system from replay attacks, but the publish-subscribe broker still has no way to determine the time at which the sensor created an update ⏰. Even worse, if sequence numbers are the only freshness indicator, a malicious eavesdropper can induce inordinate delays in the communication of signed updates by buffering messages 👀. So in certain smart object networks, it may be important for sensors to send data updates that include timestamps, so the broker can work out when each update was created 🕰️. For example, when the publish-subscribe broker is collecting temperature data, it may be necessary to know exactly when the sensor made the temperature measurement 🌡️. A simple solution is for the broker to assume the data object was created when it receives the update 🙃. In a relatively reliable network with low RTT, that assumption can be acceptable 👍. But most networks are susceptible to packet loss and hostile attacks, which makes 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, which increases the potential vulnerability of the system 😬. The smart objects could also get the current time from NTP, but this may consume additional energy and give rise to the security issues discussed in [RFC5905] 🥺. They could also have access to a mobile network or the Global Positioning System (GPS), and can use either one to 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 🎯. Otherwise, a simple device needs to implement multiple security mechanisms, which is a lot 😵‍💫. Some code can probably be shared across such implementations (like algorithms), but it is likely that most of the code involving the actual protocol machinery cannot be 🧩. Here are the choices at each layer and what they imply 👑:

  • link layer: This is probably the most common solution today 🌟. The primary benefits of this choice are that security services are commonly available (WLAN secrets, cellular SIM cards, etc.), and that protection applies to the entire communication 🔐.

The main drawback is that there is no security beyond the first hop 😱. This can be a problem, for example, in many devices that talk to a server on 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 are being proposed: IPsec, PANA, and so on 🌐. In general, these solutions have characteristics similar to those in the transport layer. They work across forwarding hops, but only as far as the next middlebox or application entity 🧭. There are 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 for use 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 they have been proven to work well 🏆. These solutions are typically easy to adopt 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 🚧. Even so, 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 the 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 that this is a real drawback 🤷‍♀️.
  • data-object layer: This solution does not protect any of the protocol layers, but it 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 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 solution provides sufficient advantages over the more commonly implemented transport and application-layer solutions ❓.

8.4. Symmetric vs. Asymmetric Crypto

The second trade-off worth discussing is whether to use plain asymmetric cryptographic mechanisms, plain symmetric cryptographic mechanisms, or some mixture of the two 🍓.

Contrary to popular cryptographic community beliefs, a symmetric cryptographic solution can be deployed at 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 that they can 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 getting more efficient very quickly 🚀. From this we can conclude that sufficient CPU is, or at least will be, easily available 💜.

But the other observation is that when asymmetric operations are very costly, 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 ✨

okay so this section is basically the group chat recap of everything we've been yapping about, and it's SO good 💅 the doc says it's making a few security recommendations based on the team's actual implementation experience, and here are the highlights:

  • Developers and product designers should choose the hardware after determining the security requirements for their application scenario. Figure out what security you need FIRST, then pick your chip. Don't do it backwards 🙈
  • ECC outperforms RSA-based operations; therefore, it is recommended for resource-constrained devices. ECC is the lowkey iconic choice for small devices 👑
  • Cryptographic-quality randomness is needed for many security protocols. Developers and vendors should ensure that the sufficient randomness is available for security critical tasks. Randomness is not optional, bestie 🎲✨
  • 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. The 32-bit chips are giving easy-to-find, budget-friendly, power-sipping energy 🔋💖
  • 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. Devices should be able to get a fresh identity when things change hands or get wiped 🧚
  • 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. Plan for updates now, or future you will be crying 😭 Flash should be at least total code size * 2, plus some buffer space 🌸

10. Security Considerations ✨

This entire memo deals with security issues. 🔐 Like, the whole thing is security, so yeah, it's serious business, bestie 💀

11. IANA Considerations 🎀

This document has no IANA actions. Nothing to register here, no registries to update, zero IANA paperwork 🦋

12. Informative References 📚

okay bestie, here are all the receipts 🧾✨ every draft, paper, library and RFC this doc leans on, listed exactly as they were cited so you can go check them yourself 🔍

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 💌

okay bestie, these are the four people who wrote this RFC, and they're all at Ericsson or Nokia in Finland 🇫🇮🧚 here's where you can find them, iykyk 💅

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

that's the whole crew, and they're the reason this spec exists 🫶✨

📦 where this page comes from