Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

Tim Hollebeek <tim.hollebeek@digicert.com> Fri, 12 April 2019 19:38 UTC

Return-Path: <tim.hollebeek@digicert.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E238B12081E for <spasm@ietfa.amsl.com>; Fri, 12 Apr 2019 12:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level:
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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=digicert.com header.b=Mmtv5UGs; dkim=pass (1024-bit key) header.d=digicert.com header.b=njMx7v9y
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 reo-S7jJOWxg for <spasm@ietfa.amsl.com>; Fri, 12 Apr 2019 12:38:05 -0700 (PDT)
Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36621200D5 for <spasm@ietf.org>; Fri, 12 Apr 2019 12:38:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1555097883; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5ax9Fgc+Qf5RGbSU6N1uu94u6Y425znEiOiXC/iKtFs=; b=Mmtv5UGsFxzuVkc3vcLsm4FK6FZ940I74qilzDfbpZBeBEpQU8hcORIqZmKAKYj2us9CJGLSY4NA6rILyXE/AjiWVYi82s3Frox/qYylJ6F43U0L46txy8BmBpoLL75eAJvKrU81tN/NhVNeB7UCDvqGlIC3vdCJj1E1gShiT7E=
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2052.outbound.protection.outlook.com [104.47.36.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-245-9v-oAzlUMRKwa_2SpCa5lg-1; Fri, 12 Apr 2019 15:38:02 -0400
X-MC-Unique: 9v-oAzlUMRKwa_2SpCa5lg-1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5ax9Fgc+Qf5RGbSU6N1uu94u6Y425znEiOiXC/iKtFs=; b=njMx7v9yMkNsfByWOpumfjWlvzlH1OcK3XGb51HRKvOxiulozek95FKLxWTVsa9lxEUqcWF9r/OdC4ef6gcmhSnhorTtWovVZitu+S4ZcEdZQS3kTJl0lsO9rwIu4LNsh4w8jShQCxTJ4k9nXyqFKNyQChcFC5FgGUpQkUNcoy8=
Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1841.namprd14.prod.outlook.com (10.171.177.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.15; Fri, 12 Apr 2019 19:37:58 +0000
Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::294e:1bc:bb2b:e728]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::294e:1bc:bb2b:e728%6]) with mapi id 15.20.1771.019; Fri, 12 Apr 2019 19:37:58 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Russ Housley <housley@vigilsec.com>, Quynh Dang <quynh.dang@nist.gov>
CC: SPASM <spasm@ietf.org>, Daniel Van Geest <Daniel.VanGeest@isara.com>, Jim Schaad <ietf@augustcellars.com>, Scott Fluhrer <sfluhrer@cisco.com>
Thread-Topic: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
Thread-Index: AQHU49VXx21KHECH1UWEyX+/NMZuuKYd5ZWAgAAMQQCAABNAAIAABCUAgAAMzgCAATq3gIADHWwAgAAIcwCAADZ0AIAWWabw
Date: Fri, 12 Apr 2019 19:37:57 +0000
Message-ID: <BN6PR14MB1106DEAD46D50AE6511B877583280@BN6PR14MB1106.namprd14.prod.outlook.com>
References: <BN6PR14MB1106140408FFB08553DEAE98835F0@BN6PR14MB1106.namprd14.prod.outlook.com> <D6AB5830-C69A-44CA-BD63-9B64F92C032E@vigilsec.com> <BN8PR09MB3604C9C7C8609430A58FD99EF35F0@BN8PR09MB3604.namprd09.prod.outlook.com> <afb437b0d9e14a8097947a25d8422286@XCH-RTP-006.cisco.com> <BN8PR09MB3604324EF9D5BF4E9061F1B4F35F0@BN8PR09MB3604.namprd09.prod.outlook.com> <048d01d4e3e6$625b4980$2711dc80$@augustcellars.com> <026b333ae64b45abb031a537366512df@XCH-RTP-006.cisco.com> <04c001d4e3ee$dc6a1b90$953e52b0$@augustcellars.com> <880932bf30944ec7a7883c99a42af9c3@XCH-RTP-006.cisco.com> <2783B663-BB48-48CA-B44C-1C269C9B2059@isara.com> <BN8PR09MB3604CDF09ED9CBAFE374A0AFF35A0@BN8PR09MB3604.namprd09.prod.outlook.com> <0967202E-7A00-4042-AB5F-210FAAE0792F@vigilsec.com>
In-Reply-To: <0967202E-7A00-4042-AB5F-210FAAE0792F@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com;
x-originating-ip: [98.111.253.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e1b699a5-b770-4421-0939-08d6bf7e5dcf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:BN6PR14MB1841;
x-ms-traffictypediagnostic: BN6PR14MB1841:
x-microsoft-antispam-prvs: <BN6PR14MB1841622933062C954D5637F983280@BN6PR14MB1841.namprd14.prod.outlook.com>
x-forefront-prvs: 0005B05917
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(376002)(346002)(396003)(53754006)(199004)(189003)(44832011)(86362001)(316002)(236005)(476003)(606006)(99286004)(478600001)(966005)(66066001)(110136005)(14454004)(7696005)(53546011)(97736004)(6506007)(76176011)(229853002)(26005)(186003)(54906003)(446003)(33656002)(99936001)(71200400001)(2906002)(102836004)(71190400001)(53936002)(11346002)(81156014)(486006)(93886005)(5660300002)(106356001)(52536014)(105586002)(53946003)(9686003)(256004)(3846002)(54896002)(14444005)(7736002)(8676002)(68736007)(6436002)(6246003)(4326008)(55016002)(6306002)(6116002)(25786009)(8936002)(790700001)(81166006)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1841; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Y91/541A5BxeBzoBxpwlxnz0MQ/NhS7od/NTyJp+uP6l4aO0xew9L/JamfjEwVqcefNS2ot19wQZjeCQAWBRKUlMEiwOLWwrrd6Hj6oJZhcL9qHhu1tmzHcT4rnHO3q8gKCA43tulNBsBQ88L92nvSWd0RjqhcnQ1NBmo4XxDynniJ13E7n+tMqiBj50i7PXYF9qFKW87+wn80xLGp9ppbZlVeyDrxIINp6X907O/sBV8W8Mlz3HN80JSUDAk88FED6768AQbSkEF6t3n5Ku/2bFm3i0bYFLcAjMYjgAW3vns8SrHIKt3muKgz9OeXmtTYNkIQAgB1ms0DoAKrK7/RtIrrJhFCZQe8fVLJhwk+14Nk+GDck+PV++glEcPYxeefpWYzFRVur1Ah2k5pD2sxB+ij7Xc78nL1GFE/hf9QQ=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0022_01D4F145.AFD9C8F0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e1b699a5-b770-4421-0939-08d6bf7e5dcf
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 19:37:57.7705 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1841
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/_U8snVsjn4Am1FD89lIezBPhi_M>
Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 19:38:10 -0000

I agree with Russ.

 

-Tim

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Friday, March 29, 2019 10:19 AM
To: Quynh Dang <quynh.dang@nist.gov>
Cc: SPASM <spasm@ietf.org>; Daniel Van Geest <Daniel.VanGeest@isara.com>; Jim Schaad <ietf@augustcellars.com>; Scott Fluhrer <sfluhrer@cisco.com>
Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

I do not agree that this fault-injection attack leads to a SHOULD for single-level trees.

 

Russ 





On Mar 29, 2019, at 7:04 AM, Dang, Quynh (Fed) <quynh.dang@nist.gov <mailto:quynh.dang@nist.gov> > wrote:

 

Hi all,

 

I suggest to add that "When key generation time is not a problem for a single-level tree which provides the desired number of OTS private keys a user has, then the single-tree HBS is a preferred option over the alternative multi-level tree HBSs which provide the same (or close ) number as the desired number of the OTS private keys. 

 

Multi-level tree HBSs are insecure under fault-injection attack, see "reference to the paper".  Therefore, single-level tree HBSs should be used."

 

Some text guidance for defenses against the attack is needed. I am not a right person to provide such text.

 

Regards,

Quynh. 

  _____  

From: Daniel Van Geest < <mailto:Daniel.VanGeest@isara.com> Daniel.VanGeest@isara.com>
Sent: Friday, March 29, 2019 6:34:00 AM
To: Scott Fluhrer (sfluhrer); Jim Schaad; Dang, Quynh (Fed); 'SPASM'
Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

This is an interesting discussion.  Is there anything anyone would like added to draft-vangeest-x509-hash-sigs as a result?  Also note that anything that could be added here would also apply to cms-hash-sigs since HSS supports multiple level trees.

 

Daniel

 

On 2019-03-27, 7:00 AM, "Spasm on behalf of Scott Fluhrer (sfluhrer)" < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org on behalf of  <mailto:sfluhrer@cisco.com> sfluhrer@cisco.com> wrote:

 

 

From: Jim Schaad < <mailto:ietf@augustcellars.com> ietf@augustcellars.com> 
Sent: Tuesday, March 26, 2019 12:14 PM
To: Scott Fluhrer (sfluhrer) < <mailto:sfluhrer@cisco.com> sfluhrer@cisco.com>; 'Dang, Quynh (Fed)' < <mailto:quynh.dang=40nist.gov@dmarc.ietf.org> quynh.dang=40nist.gov@dmarc.ietf.org>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>
Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

I understand that, but again there are some trade-offs of memory vs time.  All of the simple tree saving algorithms I have thought of can occasionally require the generation of a large portion of the tree depending on what boundaries one is crossing in the tree, this means that the signing time is not constant.  One can also make gains by doing some pre-computation of expected trees as one goes along.  When you have a tree of trees, one can get lots of speed up by saving the signature for all but the bottom most tree so that only that tree needs to have portions regenerated until you move to a new sub-tree.

 

Again, there are better algorithms known; as an example to the fractal method I gave a link to before, if we have a H=25 tree (circa 32 million leaf nodes), we can perform a walk by storing a maximum of 158 Merkle node values, and for each signature, performing 6 leaf public key recomputations per signature (not counting the OTS signature generation and a handful of hash computations while we combine Merkle nodes).  For this algorithm, it always has the current authentication path entirely in memory; the entire computation done is performing pre-computation so we’re set up for the next authentication path.

The BDS algorithm works even better if you have minimal storage for internal Merkle nodes; see  <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-old.cdc.informatik.tu-darmstadt.de%2Freports%2Freports%2FBDS08.pdf&data=02%7C01%7Cquynh.dang%40nist.gov%7Cf6277e7102074843afe408d6b4321776%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636894524568586678&sdata=cFt0M7zVFWiJbwQCZXbNEBC0ds1SK6zo2uglvXcviHY%3D&reserved=0> https://www-old.cdc.informatik.tu-darmstadt.de/reports/reports/BDS08.pdf              

 

All of these are space/time trade-offs and one needs to understand what the extremes are on both ends before one says that a huge single tree is better or worse than a lot of small trees, even if the number of levels that are created are the same.

 

Jim

 

 

From: Scott Fluhrer (sfluhrer) < <mailto:sfluhrer@cisco.com> sfluhrer@cisco.com> 
Sent: Tuesday, March 26, 2019 4:28 PM
To: Jim Schaad < <mailto:ietf@augustcellars.com> ietf@augustcellars.com>; 'Dang, Quynh (Fed)' < <mailto:quynh.dang=40nist.gov@dmarc.ietf.org> quynh.dang=40nist.gov@dmarc.ietf.org>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>
Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

Actually, there are algorithms that are able to generate the next authentication path by storing a comparatively small part of the tree, and using only a relatively small number of leaf node evaluations..  For example,  <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.szydlo.com%2Ffractal-jmls.pdf&data=02%7C01%7Cquynh.dang%40nist.gov%7Cf6277e7102074843afe408d6b4321776%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636894524568596697&sdata=krnCaCoGSCwG%2FXDYPPnijwnp6toouFB82F88Q20H158%3D&reserved=0> http://www.szydlo.com/fractal-jmls.pdf

 

From: Jim Schaad < <mailto:ietf@augustcellars.com> ietf@augustcellars.com> 
Sent: Tuesday, March 26, 2019 11:13 AM
To: 'Dang, Quynh (Fed)' < <mailto:quynh.dang=40nist.gov@dmarc.ietf.org> quynh.dang=40nist.gov@dmarc.ietf.org>; Scott Fluhrer (sfluhrer) < <mailto:sfluhrer@cisco.com> sfluhrer@cisco.com>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>
Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

There is one other factor to compare in terms of how big the tree is.  For a very large tree, if you do not have the resources to keep the entire private key set (or a large subset of it) then you get into the situation where you regenerate the entire private key tree for each and every signature.  This is part of the trade off between small key size and fast signature generation/usage of time.

 

Jim

 

 

From: Spasm < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org> On Behalf Of Dang, Quynh (Fed)
Sent: Tuesday, March 26, 2019 3:04 PM
To: Scott Fluhrer (sfluhrer) < <mailto:sfluhrer@cisco.com> sfluhrer@cisco.com>; SPASM < <mailto:spasm@ietf.org> spasm@ietf.org>
Subject: Re: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

The only downside of 1 level tree is its key generation time comparing to multi-level trees. In situations ( such as a code signing application) where 1, 2 or 3 etc... hours of a key generation time is not a problem, then using a big 1 level tree seems better than using a multi-level tree. 

 

Therefore,  some bigger height numbers for 1-level tree may be desired.

 

Quynh. 


  _____  


From: Scott Fluhrer (sfluhrer) < <mailto:sfluhrer@cisco.com> sfluhrer@cisco.com>
Sent: Tuesday, March 26, 2019 9:20:05 AM
To: Dang, Quynh (Fed); SPASM
Subject: RE: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

Irom: Spasm < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org> On Behalf Of Dang, Quynh (Fed)
Sent: Tuesday, March 26, 2019 9:11 AM
To: SPASM < <mailto:spasm@ietf.org> spasm@ietf.org>
Subject: [lamps] Side-channel attack on multi-level trees and key generation of LMS.

 

Hi all,

 

Here is the attack I mentioned at the meeting today:  <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2018%2F674%2F20180713%3A140821&data=02%7C01%7Cquynh.dang%40nist.gov%7Cf6277e7102074843afe408d6b4321776%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636894524568596697&sdata=xsTRh1kObIT8W%2Bt8EWUSRZdEjIC9mDwWiJbdCRK5Zbk%3D&reserved=0> https://eprint.iacr.org/2018/674/20180713:140821.

 

This is a fault attack (that is, you try to make the signer miscompute something, and then use the miscomputed signature); a signer implementation could implement protections against this (of course, those protections are not free).

 

I just looked at the LMS's draft, the single tree with height 25 ( 2^25 signatures)  takes only 1..5 hours.

 

Clarification on this:

*         The test used 15 cores (and so it used a total of circa 1 core-day)

*         This was done with a W=8 parameter set.  This makes the signature shorter (1936 bytes in this case), however it does increase the key generation time; a W=4 parameter set would approximately double the signature size, while decreasing the key generation time by circa a factor of 8.

 

 

Regards,

Quynh. 

 

 

 

 

_______________________________________________
Spasm mailing list
 <mailto:Spasm@ietf.org> Spasm@ietf.org
 <https://www.ietf.org/mailman/listinfo/spasm> https://www.ietf.org/mailman/listinfo/spasm