From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 71887C013A for ; Sat, 13 Feb 2021 17:19:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 6AF3E85A84 for ; Sat, 13 Feb 2021 17:19:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_Z8XR9MvX7t for ; Sat, 13 Feb 2021 17:19:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lkcl.net (lkcl.net [217.147.94.29]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 7EBB985A00 for ; Sat, 13 Feb 2021 17:19:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lkcl.net; s=201607131; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version; bh=tNxI/eGlPnc5BvRplLFtNVjA2WPqFr+0JG7Bv+0BEcQ=; b=FfJwtf3LrnUj6J4DItoOXHnzTVN2I5nlfmsIqdFO3i3or4ZaKAz4RH0qGFzoa+5jcOXz4jAUYEpaLSr+fU+QlUzxgL9Kr8/f4BchGE0cTfSFS0Jlib+YKCUkm4NWrxxokHJAy4s3K7TFhSX3FqUYWEY5OpPAn82gaFU8H5C86Mo=; Received: from mail-lf1-f53.google.com ([209.85.167.53]) by lkcl.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1lAyZx-0003Kx-RP for bitcoin-dev@lists.linuxfoundation.org; Sat, 13 Feb 2021 17:19:33 +0000 Received: by mail-lf1-f53.google.com with SMTP id v24so4094852lfr.7 for ; Sat, 13 Feb 2021 09:19:18 -0800 (PST) X-Gm-Message-State: AOAM530eMi6bGiwy/qRePLnxlKUAMslKuqnT/txNcW2o9sXA3svbtl7Y e4A7qS857db4nI5XcT+R2jk6X9QwEH7YHNfD4B0= X-Google-Smtp-Source: ABdhPJzV2B/F2pFs5tUiamiln6RFuga77txnUF7v+lJxQt4/tSFnoK4UjhD5ngOsg/Tn8VhA+Ept/hjRnf1IF6vUrj0= X-Received: by 2002:a19:6748:: with SMTP id e8mr4427126lfj.224.1613236752713; Sat, 13 Feb 2021 09:19:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Luke Kenneth Casson Leighton Date: Sat, 13 Feb 2021 17:19:01 +0000 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj , Libre-Soc General Development Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 13 Feb 2021 18:07:49 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 17:19:37 -0000 (cc'ing over to libre-soc-dev) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018392.html On Thu, Feb 11, 2021 at 8:21 AM ZmnSCPxj wrote: > > i was stunned to learn that in a 28nm ASIC, 50% of it is repeater-buffers! > > Well, that surprises me as well. > [...] > So I suppose at some point something like that would occur and I should not actually be surprised. > (Maybe I am more surprised that it reached that level at that technology size, I would have thought 33% at 7nm.) it's about line-drive strength: lower geometries are even *less* able to line-drive long distances. > Another point to ponder is test modes. > In mass production you **need** test modes. > (Sure, an attacker can try targeted ESD at the `TESTMODE` flip-flop repeatedly, but this risks also flipping other scan flip-flops that contain the data that is being extracted, so this might be sufficient protection in practice.) if however the ASIC can be flipped into TESTMODE and yet it carries on otherwise working, an algorithm can be re-run and the exposed data will be clean. > If you are really going to open-source the hardware design then the layout > is also open and attackers can probably target specific chip area for ESD > pulse to try a flip-flop upset, so you need to be extra careful. this is extremely valuable advice. in the followup [1] you describe a gating method: this we have already deployed on a couple of places in case the Libre Cell Library (also being developed at the same time by Staf Verhaegen of Chips4Makers) causes errors: we do not want, for example, an error in a Cell Library to cause a permanent HI which locks us from being able to perform testing of other areas of the ASIC. the idea of being able to actually randomly flip bits inside an ASIC from outside is both hilarious and entirely news to me, yet it sounds to be exactly the kind of thing that would allow an attacker to compromise a hardware wallet. potentially destructively, mind, but compromise all the same. beyond even what the trezor team discovered [2] it makes it even more important that wallet ASICs be Libre/Open. l. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018412.html [2] https://blog.trezor.io/introducing-tropic-square-why-transparency-matters-a895dab12dd3