Re: [Secdispatch] EDHOC Summary

Hannes Tschofenig <> Fri, 19 April 2019 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A0341200F7 for <>; Fri, 19 Apr 2019 00:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lY7t5FZYxQL6 for <>; Fri, 19 Apr 2019 00:37:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B68F01200E3 for <>; Fri, 19 Apr 2019 00:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B9d7DVJdOkYZp27AIVHcparD3QwAkljRSM/gMi+lnrk=; b=ZnOWTe1tOBwksmYLvdk4sB11xBr/Aw4N6PNFNqzDDTuXOaPhpes5nFsyJuHolgPYJEVT370UIVTYFm/H6bxRotQdMxu29y2q2zAbZ7Yr2ohGd8MSCV4mH2c6Gjpu7OYlSETYAVx5Uma7kiPNTl3iYn9qfgFPA/AkW1CppWkaOpY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.12; Fri, 19 Apr 2019 07:37:51 +0000
Received: from ([fe80::7025:fc8a:7d0a:cb91]) by ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1813.011; Fri, 19 Apr 2019 07:37:51 +0000
From: Hannes Tschofenig <>
To: Benjamin Kaduk <>, "Blomqvist, Peter" <>
CC: Richard Barnes <>, "" <>
Thread-Topic: [Secdispatch] EDHOC Summary
Thread-Index: AQHU9nALydCRJpj7+Eegv0GDPbsAqqZDEI4A
Date: Fri, 19 Apr 2019 07:37:51 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3256f57a-26b7-4620-d738-08d6c499edb1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3064;
x-ms-traffictypediagnostic: AM6PR08MB3064:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0012E6D357
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(136003)(366004)(40434004)(199004)(13464003)(189003)(316002)(71190400001)(74316002)(71200400001)(54906003)(53936002)(55016002)(6306002)(478600001)(7736002)(486006)(110136005)(305945005)(66446008)(64756008)(73956011)(66946007)(9686003)(4326008)(102836004)(229853002)(33656002)(14454004)(5660300002)(53546011)(6116002)(3846002)(81166006)(97736004)(93886005)(25786009)(476003)(11346002)(446003)(68736007)(81156014)(6436002)(8936002)(86362001)(72206003)(52536014)(2171002)(6506007)(5024004)(7696005)(14444005)(186003)(26005)(966005)(8676002)(76176011)(2906002)(66476007)(256004)(6246003)(66556008)(66066001)(76116006)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3064;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3tzUO7QRh8DmEGoO/QeF4+Z8qii+u1f5EzqEvYm8I696VMR5+hkCARbjDK8M3QSoWjStsQK1vE0fIR8BXtXMWORPRsDsY5WcoR3ZNn6ckgXVCG11d6tRpGKVelnvVtLCbdy6iiv6PIMsqhtpc81PtF2MHCHjqtZi4iYGSXdybfnl8eBAGYeiluE3WzOyE1sSFPPbgc0ZCQPWU+5Xlb+Mg+0TuOgEvxVzy/vdb4MJjnbBY7ZOTRfXsh3uDROMC/sB0CMVs2blCrAk48svPGzJv8y/aJ1zMkmRQgPY6zA+6lMnRcc5oGjwwRf7bf0UJgex0blHd46DLDwzcdaDYQaeU3KvN/FawTwGv8hOcw0Ai/L20SzPMpIM9ikflPN+McqNcVwrknH1Bpmq4NbTzE2UGmiHPP16HihiOxK3Nc7Evr4=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3256f57a-26b7-4620-d738-08d6c499edb1
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2019 07:37:51.5728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3064
Archived-At: <>
Subject: Re: [Secdispatch] EDHOC Summary
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Apr 2019 07:37:58 -0000

Hi Ben,

The size of flash is not determined by the microcontroller. My favorite tool is the MCU finder from STM:
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...


-----Original Message-----
From: Secdispatch <> On Behalf Of Benjamin Kaduk
Sent: Freitag, 19. April 2019 07:23
To: Blomqvist, Peter <>
Cc: Richard Barnes <>sx>;
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
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.


Secdispatch mailing list
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.