Re: [Ace] EST over CoAP: Randomness

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 14 May 2019 16:41 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D293C120132 for <ace@ietfa.amsl.com>; Tue, 14 May 2019 09:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDX7tRS_WJfL for <ace@ietfa.amsl.com>; Tue, 14 May 2019 09:41:34 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10058.outbound.protection.outlook.com [40.107.1.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69228120120 for <ace@ietf.org>; Tue, 14 May 2019 09:41:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GaQi8DQ8BfBBwlreQgmt0a0zSzCYmTsy6zVfYCQFiOQ=; b=qk1S9tJ5MJmJ9SwMPUUsiRB4czkYmw1orkpWfHoto/daj/X7Z3oq2DDwWGpLMD2MAZU2yBFQQO8xlgTv+ugFm8XX2si0E1iwKu3ajChk1Iwnh0tI/vavCB2kUM7z4bfqNgBbsB282UP1s1VYKLVRO6/6d7maGG11pzLcbxLHq5g=
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4774.eurprd08.prod.outlook.com (20.179.45.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Tue, 14 May 2019 16:41:28 +0000
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1878.024; Tue, 14 May 2019 16:41:28 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EST over CoAP: Randomness
Thread-Index: AdUGcOnxX76zbRm2S2qe/nEWIh3V6AAamrQAAAw3WYAACv9EMADO5pcw
Date: Tue, 14 May 2019 16:41:28 +0000
Message-ID: <DBBPR08MB45392B28B2B1DD0D56A9BB16FA080@DBBPR08MB4539.eurprd08.prod.outlook.com>
References: <DBBPR08MB45393CDF71E7DB02F6C6938CFA330@DBBPR08MB4539.eurprd08.prod.outlook.com> <MWHPR11MB18386309CD27A19485A6B204C90C0@MWHPR11MB1838.namprd11.prod.outlook.com> <DBBPR08MB4539CB2F66FB6DB66E30776FFA0C0@DBBPR08MB4539.eurprd08.prod.outlook.com> <MWHPR11MB18389FB713EB9DEDDC75BA99C90C0@MWHPR11MB1838.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB18389FB713EB9DEDDC75BA99C90C0@MWHPR11MB1838.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [96.64.251.237]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 89b70cba-f328-4cce-57ea-08d6d88b033d
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:DBBPR08MB4774;
x-ms-traffictypediagnostic: DBBPR08MB4774:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DBBPR08MB477451DD8A0EFF1EC72064FEFA080@DBBPR08MB4774.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(366004)(376002)(346002)(40434004)(189003)(199004)(53754006)(13464003)(236005)(6116002)(72206003)(54896002)(3846002)(790700001)(6306002)(110136005)(68736007)(25786009)(9686003)(14444005)(52536014)(5660300002)(256004)(5024004)(229853002)(86362001)(76116006)(66446008)(73956011)(2906002)(66556008)(66476007)(66946007)(316002)(33656002)(55016002)(64756008)(2501003)(6436002)(486006)(478600001)(6506007)(966005)(102836004)(53546011)(476003)(186003)(14454004)(74316002)(26005)(8936002)(606006)(53936002)(99286004)(81156014)(81166006)(8676002)(66066001)(71200400001)(11346002)(6246003)(76176011)(446003)(71190400001)(7696005)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4774; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OTdfB837X/5RWdfnzcHO+Gc3zQyoNgzowh3qrEKAw4dYpUI/tl30Btjf5ccp/q0ANg68BhRSFRwqaJfuaWzUiZmNaQCnsClnZ4/f6bC9yh/b1CAWm2dQOexqaZR4BZOBlY0FO/Ka6RNrDNQmkq1GzFSuP65j8BPssUMpwfeA0awMlzLWGM1qtjnTgb0Ny2DaaaEiHxSwueNfXjHK/hazhLeCAeug29wLmk+mEp0P/GMbUf9Ru+jAzI9Wwjh5jj/RebnJ/xTfDuoqonIwyVUq3LJPZ3tMrQlaZw9eqnTZiP+WM/QlTB4cnxxPTo+Ssoek+fq3fhz0J33Qur4oN8YT8TnT1wRGMTFXP1BM5wQ6LgBU03HDOwMueUdxVQb27X2aH/IvvBda8xzUYbqFebdFLVpZ1AzghQdPqbFr25RAe6c=
Content-Type: multipart/alternative; boundary="_000_DBBPR08MB45392B28B2B1DD0D56A9BB16FA080DBBPR08MB4539eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 89b70cba-f328-4cce-57ea-08d6d88b033d
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 16:41:28.5609 (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: DBBPR08MB4774
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/r_lP7lyWT2-5Ge8MGN3dpP6Bimo>
Subject: Re: [Ace] EST over CoAP: Randomness
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2019 16:41:39 -0000

Your text updates look good to me, Panos.

Thanks.
Hannes

From: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Sent: Freitag, 10. Mai 2019 13:06
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Hannes,

> Hence, I believe it would be better to first shorten the following paragraph to a single line:

Note that this paragraph was added from feedback in the review process just to motivate server-side keygen. Given that your proposed text below practically moves the points made in this paragraph in the Sec considerations section, I am all for shortening the paragraph. I was thinking something close to what you wrote, but just to keep a couple of phrases as motivation about the feature without creating an inaccurate sense of security:
~~~~~~~~~~
5.8.  Server-side Key Generation

  In scenarios where it is desirable that the server obtains access to the private key the server-side
  key generation should be used. Such scenarios could be when it is considered more secure to
  generate at the server a long-lived random private key that identifies the client or when the
  resources spent to generate a random private key at the client are considered scarce.
~~~~~~~~~~

> In the security consideration section I would add a new section somewhere that talks about the random number generation.

I like your text. I will add it  with minor changes in orange.
~~~~~~~~~~
   Modern security protocols require random numbers to be available during
   the protocol run, for example for nonces, ephemeral EC Diffie-Hellman key
   generation. This capability to generate random numbers is also needed
   when the constrained device generates the private key (that corresponds
   to the public key enrolled in the CSR). When server-side key generation is
   used, the constrained device depends on the server to generate the
   private key randomly, but it still needs locally generated random numbers
   for use in security protocols, such as DTLS.

   It is important to note that sources contributing to the randomness
   pool used to generate random numbers on laptops or desktop PCs
   are not available on many constrained devices, such as mouse
   movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, as pointed out in [PsQs].  Other
   sources have to be used or dedicated hardware has to be added.
   Selecting hardware for an IoT device that is capable of producing
   high-quality random numbers is therefore important.
~~~~~~~~~~

I hope it makes sense.

Panos


-----Original Message-----
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>>
Sent: Friday, May 10, 2019 4:58 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com<mailto:pkampana@cisco.com>>; ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Panos,

I had argued earlier that this feature shouldn't be in the draft but it seems that I will not get there.

Hence, I believe it would be better to first shorten the following paragraph to a single line:

FROM:

"
5.8.  Server-side Key Generation

   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has also shown that low-resource
   endpoints sometimes generate numbers which could allow someone to
   decrypt the communication or guess the private key and impersonate as
   the device [PsQs] [RSAorig].  Additionally, random number key
   generation is costly, thus energy draining. Even though the random
   numbers that constitute the identity/cert do not get generated often,
   an endpoint may not want to spend time and energy generating
   keypairs, and just ask for one from the server.

   In these scenarios, server-side key generation can be used.
   ....
"

TO:

"
5.8.  Server-side Key Generation

  In scenarios where it is desirable that the server obtains access to the private key the server-side
  key generation should be used.
  ....
"

In the security consideration section I would add a new section somewhere that talks about the random number generation.

"
Random Number Generation

   Modern security protocol require random numbers to be available during
   the protocol run, for example for nonces, ephemeral Diffie-Hellman key
   generation. When the private key is generated by the IoT device then
   the capability to generate random numbers is also needed. When server-
   side key generation is used then the IoT device still needs random numbers
   for use in security protocols, such as DTLS.

   It is important to note that sources contributing to the randomness
   pool on laptops or desktop PCs are not available on many IoT devices,
   such as mouse movement, timing of keystrokes, air turbulence on the
   movement of hard drive heads, as pointed out in [PsQs].  Other
   sources have to be found or dedicated hardware has to be added.
   Selecting hardware for an IoT device that is capable of producing
   high-quality random numbers is therefore important.
"

Does this make sense?

Ciao
Hannes

PS: Note that I omitted the reference to RSA because ECC is so much more popular in the IoT space that there is no point in dealing with RSA these days.




-----Original Message-----
From: Panos Kampanakis (pkampana) <pkampana@cisco.com<mailto:pkampana@cisco.com>>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>>; ace@ietf.org<mailto:ace@ietf.org>
Subject: RE: [Ace] EST over CoAP: Randomness

Thanks Hannes.
Before I try to address it, can you help me understand what you are proposing. To amend this paragraph maybe?

-----Original Message-----
From: Ace <ace-bounces@ietf.org<mailto:ace-bounces@ietf.org>> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: [Ace] EST over CoAP: Randomness

Hi all,

I am still a bit unhappy about this paragraph:

"
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has also shown that low-resource
   endpoints sometimes generate numbers which could allow someone to
   decrypt the communication or guess the private key and impersonate as
   the device [PsQs] [RSAorig].  Additionally, random number key
   generation is costly, thus energy draining.
"

If you get hardware that does not have a hardware-based RNG then you are in trouble. The main security protocols we look into do not work without a source of randomness. Hence, getting the certificate & private key from the server will not get you too far.

I believe we should encourage developers to pick the correct hardware for the task rather than making them believe we have come up with solutions that allow them to get away without a hardware-based RNG.

I also do not believe the statement that random number key generation is costly. Can you give me some number?

The references to [PsQs] [RSAorig] are IMHO also not appropriate because they are conveying a different message (at least that's my understanding from reading them). The message is that you have to be careful with designing and using a random number generator on embedded systems because the sources of entropy may just not be there (like keyboards, harddisk drive, processing scheduling, etc.).

Ciao
Hannes

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.

_______________________________________________
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace
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.

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.