Luke Kenneth Casson Leighton [ARCHIVE] on Nostr: š Original date posted:2021-02-13 š Original message:(cc'ing over to ...
š
Original date posted:2021-02-13
š Original message:(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 <ZmnSCPxj at protonmail.com> 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
š Original message:(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 <ZmnSCPxj at protonmail.com> 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