Isn't that what the TPM is supposed to provide in a verifiable way? Arm's TrustZone presumably provides layered-isolation to keys and signatures that can be verified all the way to the manufacturer. I'm guessing they might be the basis for TPM hardware implementation.
On Fri, Mar 28, 2025 at 9:56 AM ron minnich <rminn...@gmail.com> wrote: > > The relevance to plan 9: we have this thing we've used for about 30y now, > known to many of us as sdE0/nvram. > > IIUC, on the pre-x86 hardware, it really was a bit of NVRAM, the idea being > you had some bit of NVRAM on your system, hard to get to, which was a good > place to stash a key. > > X86 has always had the battery-backed CMOS memory, and it's always been too > small to hold anything useful, certainly not big enough for NVRAM, so I > always assumed that is why we ended up with sdE0/nvram. [Although, note, on > the LANL supercomputers, we did use a few bytes of CMOS to remember a node's > location on the source-routed Myrinet: not totally useless :-)] > > Creating a 512B partition on persistent storage to hold a secret key is, I > guess, what you do when you are on systems without a decent place to put it. > It never struck me as safe. > > I figure that at some point somebody is going to come in and show us a better > way to do it. Should that happen, it's good to be aware of just how real the > threats are. So I thought it would be nice to know, and possibly interesting > as well. > > > On Fri, Mar 28, 2025 at 8:06 AM <tlaro...@kergis.com> wrote: >> >> On Fri, Mar 28, 2025 at 07:04:05AM -0700, ron minnich wrote: >> > search for: keysight rp2350 hardware attacks >> > >> > (I'm done including links :-) >> > >> > Short form: it's getting easier by the day to put together glitching >> > hardware, for under $1000, and uncover those keys! >> >> [From the PR departement] This demonstrates once more: >> - That security relies first on simplicity (despite the >> conclusion, there is a mention about software too, i.e. compilers: >> "Due to an unlucky arrangement of instructions emitted by the >> compiler, injecting a fault which skips one out of two very specific >> instructions confuses the chip into rebooting to the hazardous boot >> type".); >> - That security has a cost and to maintain efficiency, >> strong security has to be done only once, and that it would >> be more secure for a task, verified, to execute once on a dedicated >> core than having to verify it at each running slot of time, having >> verified too that it had not been altered while sleeping and that the >> context on the core or the caches have not been "polluted" by a >> concurrent task. >> >> On the obvious side---it will probably not be a scoop to a lot of >> people---, I discovered, while working on the driver for the >> RTL 8125 and al. NICs, that there are instructions to allow >> to turn off the blinking led showing that there are network exchanges... >> >> All in all, trusting something that one doesn't build entirely (from >> hardware to software)---it may exhibit then errors but from involuntary >> faults---is, at best, naivety. >> -- >> Thierry Laronde <tlaronde +AT+ kergis +dot+ com> >> http://www.kergis.com/ >> http://kertex.kergis.com/ >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > > 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbd230a8f010208d8-Mfcf4c51e9b2d7efd1db76cf8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
