Re: [Secdispatch] EDHOC Summary

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 <secdispatch-bounces@ietf.org> On Behalf Of Benjamin Kaduk
Sent: Freitag, 19. April 2019 07:23
To: Blomqvist, Peter <Peter.Blomqvist@sony.com>
Cc: Richard Barnes <rlb@ipv.sx>; secdispatch@ietf.org
Subject: Re: [Secdispatch] EDHOC Summary

On Tue, Apr 09, 2019 at 07:23:47AM +0000, Blomqvist, Peter wrote:
> 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.

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
Secdispatch@ietf.org
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.