Subject: [Secdispatch] EDHOC Summary

From: "Blomqvist, Peter" <[email-masked]>
Date: Mon, 8 Apr 2019 15:23:34 +0000

I was requested to elaborate on our use-cases for EDHOC:
We believe that EDHOC  & OSCORE enables lightweight key exchange and E2E security for battery constrained devices
running over cellular IoT ( NB-IoT and/or Cat M1)

Best
Peter

---

From: Richard Barnes <[email-masked]>
Date: Mon, 8 Apr 2019 15:42:56 -0400

Hi Peter,

I think a little more elaboration might be helpful :)  What constraints are
these devices facing?  E.g., in terms of transports, code footprint.

Thanks,
--Richard

On Mon, Apr 8, 2019 at 11:23 AM Blomqvist, Peter <[email-masked]>
wrote:

> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: "Blomqvist, Peter" <[email-masked]>
Date: Tue, 9 Apr 2019 07:23:47 +0000

Hi Richard,

Code footprint is not extremely constrained, typically Cortex M4 or similar.

Battery however is constrained. Also data transport.

Optimistic marketing state that devices now can run 10 years on coin cells - adding security to such a battery budget is problematic to say the least.

5G massive IoT will add severe constrains on data volumes.

In such pessimistic scenarios data volumes could be limited to 200 bytes per day,
so a security overhead "as low as reasonably practicable" is critical.

Best

Peter

________________________________
Från: Richard Barnes <[email-masked]>
Skickat: den 8 april 2019 21:42
Till: Blomqvist, Peter
Kopia: [email-masked]
Ämne: Re: [Secdispatch] EDHOC Summary

Hi Peter,

I think a little more elaboration might be helpful :)  What constraints are these devices facing?  E.g., in terms of transports, code footprint.

Thanks,
--Richard

On Mon, Apr 8, 2019 at 11:23 AM Blomqvist, Peter <[email-masked]<mailto:[email-masked]>> wrote:
I was requested to elaborate on our use-cases for EDHOC:
We believe that EDHOC  & OSCORE enables lightweight key exchange and E2E security for battery constrained devices
running over cellular IoT ( NB-IoT and/or Cat M1)

Best
Peter
_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Apr 2019 10:43:09 +0200

On Apr 9, 2019, at 09:23, Blomqvist, Peter <[email-masked]> wrote:
> 200 bytes per day

Or 18.5 mbit/s (yes, millibits).

Millibit networks is one of the scenarios where ALARA(*) as a design objective does make sense — there is no hard design limit, but actual security will need to compete with less security, and ALARA helps actual security stay competitive.

Grüße, Carsten

(*) ALARA: “As low as reasonably achievable", a term stolen from nuclear engineering.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 19 Apr 2019 00:23:24 -0500

> Optimistic marketing state that devices now can run 10 years on coin cells - adding security to such a battery budget is problematic to say the least.

At one point I looked at the numbers in
https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
and tried to do some ballpark numbers on total power consumption for key
exchange over the lifetime of the device.  I don't have a great handle on
whether, say, 1000 mAh is plausible for the usable energy in a coin cell,
but IIRC at one rekeying event per month and some similar assumptions I
could get the lifetime energy consumption to be around 0.5% for the AKE.
Hopefully someone could replicate those numbers (I don't remember where I
put my notes) and comment on how much slack there is in the power budget
for this sort of thing.

-Ben

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 Apr 2019 07:37:51 +0000

Hi Ben,

The size of flash is not determined by the microcontroller. My favorite tool is the MCU finder from STM: https://www.st.com/en/development-tools/st-mcu-finder.html
You can get Cortex M0+ with 16, 32, 64, 128, and 192 kBytes.

Cortex M4 typically provide larger flash size options, including 256, 512, and 1024 Kbytes. The reason for the different flash size offerings is based on anticipated product use.

You can also attach off-chip flash to it. Depending on your firmware update strategy this may make sense.

Finally, in a product with a radio technology you will very often put the radio on a separate MCU. While it will cost you more (and will consume more energy) it will make the overall system more stable and easier to develop. Software development is also a cost factor. The stability aspect comes from the need of the link layer protocols to react in specific time windows. You definitely don't want your application code to negatively impact the response time of your radio stack.

Regarding battery lifetime it is really hard to say anything without knowing how the product really looks like. My co-workers tell me that the firmware update is one of the most energy-draining protocol activities. For example, a firmware update on a BLE-based device (without any advanced techniques like differential updates) consumes 50% of the coin-cell battery.

It is also a question of how many key exchanges your really need to run. You assume a full key exchange once per month. Given that we are just developing extensions like the CID the answer is that you don't necessarily need to make that many. Furthermore, there are concepts like session resumption that allow you to reduce the overhead in a subsequent handshake.

I once asked a co-worker, Peter Aldworth, to give a talk to the ACE group about selecting the appropriate hardware for an IoT product. I will did out the slides/recording because he also talked about energy efficiency.

As an engineer I would put all the effort into making the firmware update procedure more efficient because that's where you will gain a lot.
Also optimizing the actual data delivery is important. Optimizing SenML, for example, can lead to huge performance gains. A draft will follow on this topic...

Ciao
Hannes

-----Original Message-----
From: Secdispatch <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Freitag, 19. April 2019 07:23
To: Blomqvist, Peter <[email-masked]>
Cc: Richard Barnes <[email-masked]>; [email-masked]
Subject: Re: [Secdispatch] EDHOC Summary

At one point I looked at the numbers in
https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
and tried to do some ballpark numbers on total power consumption for key exchange over the lifetime of the device.  I don't have a great handle on whether, say, 1000 mAh is plausible for the usable energy in a coin cell, but IIRC at one rekeying event per month and some similar assumptions I could get the lifetime energy consumption to be around 0.5% for the AKE.
Hopefully someone could replicate those numbers (I don't remember where I put my notes) and comment on how much slack there is in the power budget for this sort of thing.

-Ben

_______________________________________________
Secdispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdispatch
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.