Skip to main content

Practical Considerations and Implementation Experiences in Securing Smart Object Networks


(Suresh Krishnan)
(Terry Manderson)

No Objection

(Adam Roach)
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)

Note: This ballot was opened for revision 05 and is now closed.

Warren Kumari
Comment (2018-02-21 for -05) Unknown
I enjoyed this document and liked the fact that it contains actual data and research.
I do somewhat agree with the "the tone of this is researchy", but I'm also more than fine with that for an Informational document.

"The workshop recommended that additional work is needed in developing suitable credential management mechanisms " 
 -- I suspect that this is incorrect - I think it is "The workshop recommended that additional work should be undertaken in" or "The workshop discovered that additional work is needed in..."

The wording of:
"In any case, as with sensor networks the amount of configuration information is minimized: just one short identity value needs to be fed in.  Not both an identity and certificate.  Not shared secrets that must be kept confidential." feels odd. Perhaps "... to be fed in (not both an identity and certificate or shared secrets that must be kept confidential)" would flow better?

"For example, leap-of-faith or trust-on-first-use based pairing methods assume that the attacker is not present during the initial setup and are vulnerable to eavesdropping or man-in-the-middle (MitM) attacks."
 - this is ambiguous, it could be read that this assumes that the attacker is not present and that the attacker is vulnerable to evesdropping. This is a minor issue and can be ignored. 

Section 4.1: "Each device generates its own identity in a random, secure key generation process."  - I think it would be useful to reinforce here that it is hard for new devices to have enough entropy to make good randomness. You do mention this further in the document - perhaps point at that?

Section 6:  Implementation Experiences
Generating an RSA 2048 bit key took  1587567ms -- I think it would be useful to mention that this is ~26 minutes ( 1587567 is many digits, and is hard to grock without conversion) 

We decided to use the Arduino Mega which has the same 8-bit architecture like the Arduino Uno but has a much larger RAM/ROM for testing relic-toolkit.
 -- somewhat ambiguous. This could be read that the Mega was designed to have more RAM/ROM specifically for testing relic-toolkit. This can also be ignored.
(well these are all comments, so technically they can all be ignored, but this more than most :-))

For instance, a sensor that wakes up every
   now and then can likely spend a fraction of a second for the
   computation of a signature for the message that it is about to send.
   Or even spend multiple seconds in some cases.
-- I'd suggest joining this into one sentence. 

It is important for the smart object to write the sequence number into the permanent flash memory after each increment
 -- it may be worth noting that many flash technologies have very limited write cycles, and so this may not be practical.

9. Summary
   This document makes several security recommendations based on our
   implementation experience.  We summarize some of the important ones
   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.

While very true, it isn't really a security recommendation.
Alexey Melnikov Former IESG member
Yes (2018-02-21 for -05) Unknown
A good piece of work, even if a bit "researchy" at times.
Ben Campbell Former IESG member
Yes (2018-02-21 for -05) Unknown
I'm balloting "yes", because I think this is interesting and useful material. But, as others have mentioned, it's confusing that this appears to be a working group document, but it seems to be about the authors' personal design and experimentations.

Otherwise, I just have a few editorial comments:

§2, first paragraph, third sentence: Missing article before "CoAP base specification".

§4.1, paragraph 4: "Once both peers...": What peers? Does this use the term "peer" for the server?

§4.1, last _word_: missing article before Igrp.

§4.2: "While this is not impossible in data object security
   solutions either, it is not the typical arrangement either."
I suspect the first "either" was not intended.

§5: "It is written in nesC programming language..." missing article before "nesC".
Kathleen Moriarty Former IESG member
Yes (2018-02-21 for -05) Unknown
Thank you for your research work supporting this document and for a well written draft.  

A agree with Spencers comments on scaling from DDoS attacks and with Warren's comments.

I only caught one other typo that I didn't see mentioned in another review.  Section 7:
   These battery-operated or energy scavenging nodes do
   not have enough power to be stay on at all times.
Spencer Dawkins Former IESG member
Yes (2018-02-19 for -05) Unknown
I'm a little confused to read 

  Section 4 discusses a deployment model that the authors are
   considering for constrained environments. 

in a working group draft. Is the working group proposing this?

The Introduction skips over Section 7, which could make sense for an Example, but will likely mystify readers. 

Looking at this text, 

  o  There may be a large number of devices.  Configuration tasks that
      may be acceptable when performed for one device may become
      unacceptable with dozens or hundreds of devices.

I think recent DDOS attacks have shown that many more than "hundreds of "owned" Things can cooperate to cause problems. ("It's worse than you think")


   Temporary identities (such as IPv6 addresses)
   can be used for network communication protocols once the device is

be qualified? I'm thinking that some IPv6 addressing practices would not qualify as "temporary identities". 

I wasn't sure what 

   64-bit x86 linux machine serves as the broker and the RD, while a
   similar but physically different 64-bit x86 linux machine serves as
   the client that requests data from the sensor.

meant by "physically different". I was guessing "similar but physically distinct", but I'm guessing.
Suresh Krishnan Former IESG member
Yes (for -05) Unknown

Terry Manderson Former IESG member
Yes (for -05) Unknown

Adam Roach Former IESG member
No Objection
No Objection (for -05) Unknown

Alissa Cooper Former IESG member
No Objection
No Objection (for -05) Unknown

Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Unknown

Benoît Claise Former IESG member
No Objection
No Objection (2018-02-21 for -05) Unknown
From Eric Vyncke, as OPS DIR reviewer:
This informational draft is about the challenges associated with securing resource-constrained smart object devices (such as those using CoAP).  It describes a possible deployment model and some preliminary experiences. It is part of a set of documents (draft- arkko-core-security-arch).

The challenges section includes many operational aspects: provisioning, scalability, ... The document proposes a simple system to generate the device identity based on its public key. 

The authors made some tests using 6 different crypto-libraries on Arduino 8-bit processors, this is the main part of the document. Finally, sections 7 and 8 describe a simple test application and some considerations about implementations.

So, a rather practical document.

*My only regret is that ‘key pair renewal’ is mentioned twice in the document (section 4.1 and 8.1) but without any detail... Key renewal is a big operational issue and it deserves more text or be explicitly cited as a non-goal in the abstract.*
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Unknown

Eric Rescorla Former IESG member
No Objection
No Objection (2018-02-22 for -05) Unknown
Review in context at:

   both parties, there are some remaining vulnerabilities that may or
   may not be acceptable for the application in question.  For example,
   leap-of-faith or trust-on-first-use based pairing methods assume that
This is not strictly correct. SAS is an example that requires neither of these.

   the attacker is not present during the initial setup and are
   vulnerable to eavesdropping or man-in-the-middle (MitM) attacks.
You might be interested in 
Secure In-Band Wireless Pairing
Shyamnath Gollakota, Nabeel Ahmed, Nikolai Zeldovich, and Dina Katabi
USENIX Security 2011, San Francisco, CA, August 2011.

   not completely secure method where the last few digits of the
   identity are printed on a tiny device just a few millimeters across.
   Alternatively, the packaging for the device may include the full
This is subject to trivial attacks no?

      Igrp = h(Pdev1|Pdev2|...|Pdevm)
1.Where do you use Idev?

This does work, I guess, but requires you to have the public keys of every device. Why not use a Merkle tree?

      filtering, storage and other actions, again without impacting the
      security of the data being transmitted or stored.
It's not clear from this text why these benefits obtain (caching especially). Is that because the data is in self-contained PDUs which can be interpreted even if there is transport/network level modification?

      different symmetric key algorithms such as AES, triple DES and
      SkipJack.  It provides RSA as an asymmetric key algorithm.  Parts
      of the library were written in AVR-8 bit assembly language to
Skipjack? 3DES? Back to the future!

      of a large variety of cryptographic algorithms.  This not only
      includes RSA and ECC, but also pairing based asymmetric
      cryptography, Boneh-Lynn-Schacham, Boneh-Boyen short signatures
It might be useful to know whether it's just the NIST curves or also X25519 and X448.

      based public key cryptography on sensor networks.  It is written
      in nesC programming language and as such is designed for specific
      use on TinyOS.  However, the library can be ported to standard C
What is the nesC programming language? Maybe a cite?

      implementation as well as X509 certificate handling.  The library
      provides an intuitive API for developer with a minimal code
      footprint.  It is intended for various ARM platforms such as ARM
"intuitive" seems a bit subjective.

   | 2048         |                1587567 |                     1,280 |
The time value would be easier to read if you used comma separators, as you did with memory footprint.

   In Table 2 we present the results obtained by manually porting
   TinyECC into C99 standard and running ECDSA signature algorithm on
   the Arduino Uno board.  TinyECC supports a variety of SEC 2
Nit: "the ECDSA"

   | secp192k1   |          3425 | 1008            |              1536 |
   | secp192r1   |          3578 | 1008            |              1536 |
Note: IETF's minimal size is 256-bit and we also wouldn't use any of the k1 curves probably.

Do you have a cite for the key length comparisons. Opinions vary a bit here. And I understood the consensus to be that 192-bit was rather stronger than 1536.

   | NIST K233       |         1736 | 3675           |            2048 |
   | NIST B233       |         4471 | 3261           |            2048 |
You should use the same naming convention as with the precious tables.

   that the IETF community uses these curves for protocol specification
   and implementations.
I'm confused by this statement. I would in fact expect X25519 to be faster, but your table 6 show Relic out performing this:

NIST B233 | 6100 | 2737 | 2048 |

   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
You should probably note that RSA key pair generation is very expensive compared to signing, whereas ECDSA key pair generation is quite cheap compared to signing (it is a fixed-base operation).

   Sequence numbers can wrap-around at their maximum value and,
   therefore, it is essential to ensure that sequence numbers are
Nit: no hyphen in wrap around because it' sbeing used as a verb.

      time it passes through an application level entity, it is not
      clear that there are attacks beyond denial-of-service.
This is very dependent on exactly how you build the data object protection protocol.

   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.
I don't believe about PKs not scaling is true at this point. Even if you don't count TLS, here are several widely used PK-based IM protocols.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-02-19 for -05) Unknown
This document reads more like a research paper (especially as it often talks about „the authors“ and „we“). While I would find it more appropriate to publish the experimentation report as a research paper or maybe some kind of extended technical report and only document the resulting recommendations in a short informational RFC, I don’t object to the publication as it was at least an interesting read. I guess the authors could consider to move some parts to the appendix (I guess sections 5-7 and maybe even some more text) but it’s probably not worth the effort.