Re: [Ace] EST over CoAP: Randomness

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Fri, 10 May 2019 08:57 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 600471201B7 for <ace@ietfa.amsl.com>; Fri, 10 May 2019 01:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: 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 pfIoqUjpZdsU for <ace@ietfa.amsl.com>; Fri, 10 May 2019 01:57:41 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9351201CC for <ace@ietf.org>; Fri, 10 May 2019 01:57:41 -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=Ly5UvIaQPXiFJ8qBjqmZSeO6chcV2cM5g8roMwHcS7Q=; b=BuAjnZAOPS0rgdwm2yO08rGlDBhs8I1cj8m11Hmuw6eerbehmb58PdBwOp6yoU5STc3vmVuKQ3Ay6cWel0vx2AaMhfIqqpCIjNMtWUoA96OahXJs1H7TH5Hfbr0+FZab/MDv23B5/WJKWZ/4NqVGPNbrYkpbKS/c5eFyKpMXmbY=
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4741.eurprd08.prod.outlook.com (10.255.79.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Fri, 10 May 2019 08:57:38 +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.022; Fri, 10 May 2019 08:57:38 +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/nEWIh3V6AAamrQAAAw3WYA=
Date: Fri, 10 May 2019 08:57:38 +0000
Message-ID: <DBBPR08MB4539CB2F66FB6DB66E30776FFA0C0@DBBPR08MB4539.eurprd08.prod.outlook.com>
References: <DBBPR08MB45393CDF71E7DB02F6C6938CFA330@DBBPR08MB4539.eurprd08.prod.outlook.com> <MWHPR11MB18386309CD27A19485A6B204C90C0@MWHPR11MB1838.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB18386309CD27A19485A6B204C90C0@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: [80.92.123.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 98c83e2f-e1ea-4d69-30a8-08d6d5258dd2
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:DBBPR08MB4741;
x-ms-traffictypediagnostic: DBBPR08MB4741:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DBBPR08MB47413FD8F6A44650002C87DAFA0C0@DBBPR08MB4741.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(136003)(366004)(39860400002)(40434004)(13464003)(53754006)(199004)(189003)(476003)(6436002)(478600001)(86362001)(72206003)(110136005)(966005)(53936002)(186003)(68736007)(11346002)(6116002)(486006)(446003)(66066001)(3846002)(74316002)(14444005)(71200400001)(5024004)(256004)(5660300002)(305945005)(71190400001)(8936002)(8676002)(55016002)(81166006)(81156014)(6306002)(6246003)(2501003)(9686003)(14454004)(316002)(33656002)(26005)(7736002)(2906002)(66556008)(64756008)(66446008)(73956011)(66946007)(6506007)(53546011)(76116006)(102836004)(52536014)(76176011)(66476007)(229853002)(7696005)(99286004)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4741; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: kQqfM0sLx31zz02Ivm+RJpTmumj+BayfspBzkpAaRYgni9DzIigK2CWBJCazJwroJ7OdyhD7CkWcKoKyesbW3K5LZ2WVAOIfqe5LMTlP52H5AZS2wQGwYGjjqww0LCtST5iZhdoQB/V3jsjGNmxFXtfUEpA/SSeTsy620/h0V1EXYfReC9t0hLwaW1JEL1RhDUEpB7LDqFDT4FKNMUzFyW04ekgL67Ro8djz/O9n4yKGq7yB3hhBbOkFWAKYNTvmC8vd8zhzPLvbBwQQaSVN5oi//hhA1o65tbG/1DHjF4TpAuz6us/xjJrnWBKYnHKrpYqY+7bu1FMTX3qVtpV8BYWQ2KTPrR7Rzs+jEzraBupi1HmciRAvX4Q+kd6OGaI3rnpMUc673ioM8hoOB7MCiPrcGJuXG/5HM7fIVeeZ/BE=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 98c83e2f-e1ea-4d69-30a8-08d6d5258dd2
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 08:57:38.8652 (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: DBBPR08MB4741
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/MRKo5scefSx63pHTxN2NvnrmFeA>
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: Fri, 10 May 2019 08:57:55 -0000

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>
Sent: Freitag, 10. Mai 2019 04:53
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>om>; 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> On Behalf Of Hannes Tschofenig
Sent: Thursday, May 09, 2019 10:43 AM
To: 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
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.