Post B4JPLrdGwKvKsh3Hl2 by domi@donotsta.re
(DIR) More posts by domi@donotsta.re
(DIR) Post #B4JF2AZjnlDyIZMwQC by domi@donotsta.re
0 likes, 0 repeats
consider the following scenario: you want to verify if boot chain on device A has not been tampered with. This could be done through hashing kernel/initramfs or the EFI image, and presenting that hash to the user.However, nothing stops an adversary with physical access to the device from modifying the boot image, and making it display a static hash to fool the user.I thought how, given a trusted device B, this could be a challenge-response problem: enter parameters generated on device B (such as offset/length of the hashing area), get a hash back, verify if it matches the assumption. But again, this can be circumvented through keeping a copy of the original files and hashing them, while running adversary-modified code.Same thing with hashing the memory: the adversary can just store a memory dump and point to that.Is there a way to achieve trust in a scenario like this, without resorting to obscurity?
(DIR) Post #B4JFMaKbkdMByG1jbU by domi@donotsta.re
1 likes, 0 repeats
one possible option: given a USB mass storage device “C” which contains a trusted bootloader, the whole boot chain problem can be moved away from device A itself. Still, it requires implicit trust in some device, but I think it’s easier to trust a thumb drive that’s always on you, than a laptop which you may temporarily leave on a table while going to the bathroom.
(DIR) Post #B4JFcbyJQ68jgxExqy by alwayscurious@infosec.exchange
0 likes, 0 repeats
@domi What about TPM-based attestation?
(DIR) Post #B4JFcc8EpC50BjstKC by domi@donotsta.re
0 likes, 0 repeats
@alwayscurious it sucks
(DIR) Post #B4JGQMlCFZhYzdpYDQ by jn@boopsnoot.de
0 likes, 0 repeats
@domi i think this leads to be approach various google(-adjacent) devices have been taking over the past decade:- have a reasonably-immutable root-of-verification (first stage)- first stage loads and hashes second stage- if the second stage doesn't conform to some criteria that make it presumed safe (such as a signature from a known party), the first stage will display the hash for a set amount of time, possibly even requiring user interaction before continuing- user can trigger hard reboot
(DIR) Post #B4JGQNIAH04adtFsbQ by domi@donotsta.re
0 likes, 0 repeats
@jn as an end-user I can’t introduce an immutable root of trust that can’t be read (and thus, reverse-engineered and emulated :/)and all the included security devices rely on security by obscurity (or the attacker not having a sufficiently fast signal analyzer). google’s phones are a bit better because they have everything integrated into the SoC. On chromebooks… it’s a spiced up TPM. it governs BIOS flashing through regular means, but can be circumvented with a ch341a and 15 minutes time
(DIR) Post #B4JGWCpe4mM1wGhDPM by jomo@mstdn.io
0 likes, 0 repeats
@dominot sure if it meets your needs, but maybe https://attestation.app/about would be interesting to you.
(DIR) Post #B4JGWD1LNHiCWYAYds by domi@donotsta.re
0 likes, 0 repeats
@jomo it sucks! i don’t do android!
(DIR) Post #B4JGhAH5vMlFC1lDxg by alwayscurious@infosec.exchange
0 likes, 0 repeats
@domi In what ways?
(DIR) Post #B4JGhAPxOPqldVuIm8 by domi@donotsta.re
0 likes, 0 repeats
@alwayscurious https://hackaday.com/2024/02/06/beating-bitlocker-in-43-seconds/this has been known to be possible at least since 2019, with TPM1.
(DIR) Post #B4JGsTGHfhdPGVlyWO by mothcompute@merping.synth.download
0 likes, 0 repeats
@domi the usb option does leave the potential for a malicious usb driver or reader or such... admittedly secure boot does do a good job of ensuring a trusted boot chain its just also complicated by the fact that something like the psp doesnt implement such user key handling, its often implemented wrong, and its built on uefi which is extensive beyond reason
(DIR) Post #B4JGsTWah4g855OzwG by domi@donotsta.re
0 likes, 0 repeats
@mothcompute the problem with secureboot is that you can disable it in the bios and nobody can know. “but use a bios password” do you really think that an adversary can’t modify the nvram. or flash a new bios without the password? not a very strong root of trust
(DIR) Post #B4JGsbegSruDIVFZfE by mothcompute@merping.synth.download
1 likes, 0 repeats
@domi the psp/intel equivalent would be very trustable if it could load user keys directly just because its firmware is so much smaller and limited in scope, but doing that would mean ceding the entire firmware and system management mode to gamers online like that 'moth compute' everyones always blathering on about
(DIR) Post #B4JGzTMfgecRc06CjQ by coral@empty.cafe
0 likes, 0 repeats
@domi why is the ME not helping you here?
(DIR) Post #B4JGzTaUrFg6IsZFHU by domi@donotsta.re
0 likes, 0 repeats
@coral how could ME even help me here?a) there are computers without intel. i didn't specify the architecture, let alone the cpu vendorb) ME itself doesn't do much to the boot process
(DIR) Post #B4JH4RC1Bn6cK9U2t6 by mei@donotsta.re
1 likes, 0 repeats
@domi one option is what google pixels do: have code in ROM that cannot be tampered with, have it display the hash before booting. (in general the google pixel boot security is set up really nicely, having read grapheneos's docs on the topic)another option is what Intel TXT does... but that approach requires the CPU having some kind of hard-to-extract private key that it can use to sign statements of the form "i booted an image with hash X and that software wants to tell you Y"
(DIR) Post #B4JHF3AKrUjQzTkzcO by lanodan@queer.hacktivis.me
1 likes, 0 repeats
@domi Yeah in a way a truly dynamic/non-deterministic challenge which can be the payload that needs to be booted.Although I guess this relies on detecting if you're in a VM or not but I guess timing things out (which an external device can measure) could be a good indicator.
(DIR) Post #B4JHPr9nqkPMvqf1o8 by domi@donotsta.re
0 likes, 0 repeats
@lanodan yeah but then you get into performance vs energy efficient cores, downclocking on battery, etc.
(DIR) Post #B4JHUnkvvFvdpcO0AK by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@domi Yeah although does that apply for early boot?
(DIR) Post #B4JHWksZaaw5ULtJNA by dragoonaethis@mstdn.social
0 likes, 0 repeats
@domi isn't this exactly the job of the TPM? Each boot stage submits a hash of the next boot stage it's about to hand over control to, and you can ask the TPM for a signed proof of the system being in the expected state (boot hashes + time). Then that second trusted device needa to have a public key for the tested device's TPM and you can verify if it's the right thing even if the OS is compromised.
(DIR) Post #B4JHWl4crmZq5jWw9w by domi@donotsta.re
0 likes, 0 repeats
@dragoonaethis https://hackaday.com/2024/02/06/beating-bitlocker-in-43-seconds/i don’t believe there are versions of TPM that can be fully trusted
(DIR) Post #B4JHiWRB6qmAAmgk1Q by domi@donotsta.re
1 likes, 0 repeats
@lanodan yep! some of the downclocking is done by the firmware itself, not the OS. I can see a good dip in how fast my LUKS hash gets computed if i start my laptop on battery
(DIR) Post #B4JI2mrrjOPsvGpmzo by valpackett@social.treehouse.systems
0 likes, 0 repeats
@domi @alwayscurious this meme is only possible with the combo of a dTPM (which no one uses anymore) and an FDE setup based purely on measured boot with no passphrase involved
(DIR) Post #B4JI2n6kq2KHfRngCe by domi@donotsta.re
0 likes, 0 repeats
@valpackett @alwayscurious dTPM (which no one uses anymore):source: ?and an FDE setup based purely on measured boot with no passphrase involvedwe’re ignoring the bitlocker part here. the problem is that most of TPM’s security is relying on stuff like this.
(DIR) Post #B4JI6NOqMYhj5pyGDg by coral@empty.cafe
0 likes, 0 repeats
@domi i know you are sitting at the laptop in this sceniro, but i think this is still remote attestation. So a vendor feature designed to do that is a prerequisite.
(DIR) Post #B4JI6NaXf43tg7RbSC by domi@donotsta.re
0 likes, 0 repeats
@coral I don’t trust vendors which I cannot audit. it’s not “remote attestation”, i’m trying to figure out a way to attest it locally, as I wrote in my first post.
(DIR) Post #B4JI8QBQz4RIJ1fqS0 by jn@boopsnoot.de
1 likes, 0 repeats
@domi i don't think it needs to be non-readable or obscure, as long as it's either correct, or detachable (as in my other reply), and in either case non-writable. But i guess the "end-user" requirement rules out the modifications necessary for a detachable boot flash.TPMs, AFAIU, are only half the story anyway, because they can only maintain a running hash of whatever is sent to them from the instant of power-on, which is only useful with an immutable first stage / RoV that anchors the chain
(DIR) Post #B4JIeB9OPZkewsrW8O by domi@donotsta.re
0 likes, 0 repeats
@jn well, technically I’d be happy to introduce additional circuitry into an already-existing design. That would require a non-erasable ROM, and it still wouldn’t give me full certainty that my device hasn’t been tampered with.it’s security-by-complexity: with every additional measure, it’s harder to reduce all of them to return true;. but without being sure what code is actually running, some trust is neededat one point the device i’m operating would become a comical equivalent of a ship of theseus, “they replaced so much, it’s really just a keygrabber for your pleasure” BUT STILL
(DIR) Post #B4JIkewWYaJr5Nvut6 by coral@empty.cafe
0 likes, 0 repeats
@domi I think it’s remote attestation. You are interacting with the silicon to verify via communications channels (usb, video). The distance does not matter?
(DIR) Post #B4JIkf79v2pHcMuPSq by coral@empty.cafe
0 likes, 0 repeats
@domi but, yes. if you don't trust the CPU you probably have larger problems...!
(DIR) Post #B4JIkfIVErtsBYDT96 by domi@donotsta.re
0 likes, 0 repeats
@coral aside from phone SoCs, CPU isn’t the root of trust in any design :/ so it doesn’t matter if I trust it or not, imo
(DIR) Post #B4JJI1KSLaES4T2EIi by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@domi Heh, reminds me that this kind of problem often makes me feel like it's turtles-all-the-way-down. As in a way for some devices you could have the read-write¹ firmware being something externally pushed.¹As opposed to like truly baked-in firmware, where then various kinds of tamper-evidence can be used
(DIR) Post #B4JJmze0f0hfp6wxLE by MarkAssPandi@shrimpnet.gej.pet
0 likes, 0 repeats
@domi @mothcompute Idk how is it now but I remember how easy it was to restart bios password by removing the battery, no need to even modify nvram or flash anything, just poping the lil coin for a bit
(DIR) Post #B4JJmzphxW3qPOQIZk by domi@donotsta.re
0 likes, 0 repeats
@MarkAssPandi @mothcompute depends on the vendor, depends on user vs supervisor password (those are separate sometimes, and they get stored differently!) but this only supports my point
(DIR) Post #B4JL62XMEI9KFdU67M by MarkAssPandi@shrimpnet.gej.pet
1 likes, 0 repeats
@domi @mothcompute ye I was agreeing with u :3
(DIR) Post #B4JLFLbugTdY0r3NpI by jn@boopsnoot.de
1 likes, 0 repeats
@domi mask ROMs are too fucking expensive so that leaves flash. as i said, i've seen flash parts with persistent protection bits. finding out how robust they actually are requires a budget i'm not willing to spend.on the processor side of things, i've been assuming the somewhat unrealistic ideal case: no complex internal ROM, predictable boot flow from from one external memory device, compatibility with blobfree coreboot or similar
(DIR) Post #B4JLRvTj9aYEjLDrMG by mothcompute@merping.synth.download
0 likes, 0 repeats
@MarkAssPandi @domi that is not the same technology that would be used in uefi secure boot key handling, and is mostly a holdover from legacy x86 ipl configurations which have now been largely phased out; spi flash is now a standard if not compulsory part of the modern boot chain and should be available to the ipl and writable by firmware
(DIR) Post #B4JLRw2T4QLAT5TbVY by domi@donotsta.re
0 likes, 0 repeats
@mothcompute @MarkAssPandi well. the problem is that if it’s writable by the firmware, it is writable by me, a humble idiot with an SPI interface.most of the time it’s Fine because there are other parts checking if you didn’t dare to flash a modifed BIOS image. but the password area can’t be hashed like this, so it’s up for grabs…
(DIR) Post #B4JLtkk0fVXZXN6ijA by mothcompute@merping.synth.download
1 likes, 0 repeats
@domi @MarkAssPandi that does become a vendor problem, but i think generally speaking the psp and adjacent hardware is meant to protect against this by providing a package-local tpm api that would be usable to sign or encrypt efi variables and get around this problem that way. does anyone implement it correctly... well... ill let someone better informed answer that one
(DIR) Post #B4JM2lIhxOqjsZdJHU by domi@donotsta.re
0 likes, 0 repeats
@mothcompute @MarkAssPandi i don’t think i’m especially well-informed in this regard, but with what i’ve seen.. uh. don’t look there
(DIR) Post #B4JMjySauFZZ91rX84 by mothcompute@merping.synth.download
0 likes, 0 repeats
@domi @MarkAssPandi its surely possible to do correctly but whether insyde h2o or whatever the american megatrends uefi is called does so is another question entirely, and probably not even as important as what about lenovo
(DIR) Post #B4JNpYwEoCuRgJxN3I by wolf480pl@mstdn.io
0 likes, 0 repeats
@domi*looks at the Xbox One bootrom hack*In general, no.But it might be possible if your adversary has limited capabilities.
(DIR) Post #B4JNuilJiAJPb7JASO by domi@donotsta.re
1 likes, 0 repeats
@wolf480pl security by complexity!
(DIR) Post #B4JOgXhy74NvDLXrNo by toast@donotsta.re
1 likes, 0 repeats
@domi with sufficient motivation you should presume that an attacker with physical access can do anything, including lift “Secure Enclave” keys out and so on you can always sand down the traces and grab the data straight off the the signal, for example magnetized needle + steady hand etc if you look at things that way then the fundamental need to have trust be part of the process becomes obvious, so things like “just don’t run untrusted code” become more reasonable all of a sudden most approaches simply try to make it too much of a pain to be worth it (e.g. if you sand down the traces it’s gonna be rough to keep using the device long term after that)
(DIR) Post #B4JOrRNRzXdilT91Fo by IngaLovinde@embracing.space
0 likes, 0 repeats
@mei @domi and even then it depends on the threat model. E.g. a sufficiently motivated attacker might install a hardware keylogger (touchlogger?) on your pixel and get the password from it and then do anything with your phone.Or they might replace your pixel with a decoy that displays all the same things.
(DIR) Post #B4JOv6nWRoNG645XuK by wolf480pl@mstdn.io
0 likes, 0 repeats
@domiAt the end of the day someone with infinite money and a lot of time can replace your computer with an identical-looking one that is just a thin client connected wirelessly to a device that emulates and snoops all inputs and outputs to your real computer. So, what are the limitations of your attacker?
(DIR) Post #B4JOydFOG2CJbcnsbw by domi@donotsta.re
0 likes, 0 repeats
@toast my conclusions on the topic are very gloom and i’ll refrain from sharing them now :/
(DIR) Post #B4JPLrdGwKvKsh3Hl2 by domi@donotsta.re
0 likes, 0 repeats
@wolf480pl there are some limitations of our reality: not every place is connected equally, and despite what you may want to reply, my attacker can’t follow me everywhere. so i’m bound to find out if the logical extreme happens, probably the first time I do an impossible :deutschebaaa: delayed train changeover
(DIR) Post #B4JQ0zFhVxEaO1dT2u by wolf480pl@mstdn.io
2 likes, 0 repeats
@domiProbably.Also you're probably not enough of a high-value target to warrant a hardware implant, or an electron microscope.My point is, without specifying a threat model, the only answer you can get is "it's turtles all the way down", which is what most of the other subthreads ended up arriving at.
(DIR) Post #B4JQGJWuPBTLcUzclE by domi@donotsta.re
0 likes, 0 repeats
@wolf480pl well, it’s better to have a turtles response than to wonder if it’s really all turtles all by myself, like i’ve been doing for a couple years now. so despite how this thread concludes, I have some new perspectives.and yes, you’re correct that there’s some place where I should decide something is “secure enough”. but for the purposes of this thread, if I don’t exaggerate the problem endlessly, I won’t get the full picture I was yearning for.
(DIR) Post #B4JQk2fTf4PA0mAzUO by wolf480pl@mstdn.io
1 likes, 0 repeats
@domioh, in that case, I remembered one more turtle, lemme add it in the right subthread
(DIR) Post #B4JQu0PusxA7vTeI2C by erincandescent@erincandescent.net
0 likes, 0 repeats
@valpackett @domi @alwayscurious also only possible with Microsoft’s inexplicable continual failure to setup a fucking encrypted channel between the CPU and the TPM!
(DIR) Post #B4JQu0hdp3LAoRwRf6 by erincandescent@erincandescent.net
0 likes, 0 repeats
@valpackett @alwayscurious @domiThe TPM designers were not idiots and thought of this and the fact BitLocker still fucks this up is embarassing :(
(DIR) Post #B4JQu0ul2HpfT84v6e by domi@donotsta.re
0 likes, 0 repeats
@erincandescent @alwayscurious @valpackett like again, bitlocker aside (because I don’t use windows, and even outside of TPM it has some very weird design choices - check how it derives the keys, there’s at least one place where it truncates the key material without real purpose)if I decide to trust the TPM (which has firmware that I can’t inspect, so it’s inherently security-by-obscurity), then I actually need to trust the UEFI vendor, and my motherboard vendor to not fuck their part up. that involves a bunch of other parties, none of which are especially known for having secure products.the beginning of my thread is the clue to what I’m looking for: I’m considering whether it would be possible to create a better root of trust with tools available to an average hacker (so no custom silicon, sorry). The idea of TPM is sound (it’s the implementation that sucks), and doing attestation through it is likely the best “generic” solution to this problem. However, I wonder if I could improve things, somewhat.
(DIR) Post #B4JR2Gmdv1Yx0EDfXc by wolf480pl@mstdn.io
1 likes, 0 repeats
@domi@dragoonaethis there's a trick I heard of long time ago that might help with this, and with SPI flashers:- put ferromagnetic nail polish on the screws- randomize the arrangement of the glittery bits with a magnet- remember / photograph the arrangement of the glittery bits- check them every time before using device A
(DIR) Post #B4JRsjsoyKNeJP82Ii by wolf480pl@mstdn.io
1 likes, 0 repeats
@domishit: https://hoodiepony.medium.com/bypassing-the-glitter-nail-polish-tamper-evident-seal-25d6973d617d@dragoonaethis
(DIR) Post #B4JSAVoK23ZRsZV0Hg by erincandescent@erincandescent.net
0 likes, 0 repeats
@domi @alwayscurious @valpackett Yeah, and I think the TPM is unfortunately as close as you can get without custom hardware. Fundamentally you need some key in a HSM/Secure Enclave, and the entire boot process needs to be either controlled by or attested to said secure enclave. The best you can probably do is replacing your UEFI with CoreBoot or a similar firmware that’s better engineered (or start from a different base point: Chromebook hardware has a different, simpler root of trust mechanism; and Apple’s Secure Enclave is not bolted onto the side of an existing legacy boot process)
(DIR) Post #B4JSAVybPpnIOSJDJA by domi@donotsta.re
0 likes, 0 repeats
@erincandescent @alwayscurious @valpackett sadly, coreboot doesn’t help me with attesting that it didn’t get replaced with an identically behaving, but malicious payload. depthcharge (ChromeOS fw based on coreboot) did a little bit of a better job of checking stuff than edk2 (default modern payload for coreboot), but it’s still not resilient to an idiot with an SPI flasher (me)moving the attestation I proposed from early linux userspace to UEFI helps a bit, but still doesn’t fully close the trust gap
(DIR) Post #B4JSdNYFooIwf5kRkm by erincandescent@erincandescent.net
1 likes, 0 repeats
@domi @alwayscurious @valpackett hmm I would have thought that the CPU ROM based firmware would have attested the SPI flash but I guess I was being too hopeful about x86 security
(DIR) Post #B4JSdNoCrV45SZDBcO by evey@chaos.social
1 likes, 0 repeats
@erincandescent @domi @alwayscurious @valpackett It does, but finding platforms that actually have this enabled and properly setup is rare (especially for consumer devices ...) bootguard etc should be doing this.
(DIR) Post #B4JSp7gadFXMvlFNom by domi@donotsta.re
0 likes, 0 repeats
@evey @erincandescent @alwayscurious @valpackett bootguard situation is hilarious. Considering everything in this thread I should love it, but because it’s focused on giving vendors and not users control, I absolutely despise the damn thing. same with protections built into AMD PSP, although the situation is getting slightly better as of late.
(DIR) Post #B4JSpjISnOojZwFeUK by evey@chaos.social
1 likes, 0 repeats
@erincandescent @domi @alwayscurious @valpackett Similarly the whole shitshow about AMD fusing cpus to platforms, is a similar meganism, you can fuse keys in the CPU to only boot firmwares with that are signed with those keys.
(DIR) Post #B4JT7kaUjdwUnKHKAi by domi@donotsta.re
0 likes, 0 repeats
@evey @alwayscurious @erincandescent @valpackett all of this feels like an unstoppable force vs immovable object problem. it’s really hard to let the user have their freedom in running whatever they want, while preserving root of trust. Most of existing solutions compromise the earlier, or do a ridiculously bad job at the latter.I believe that with enough R&D it’s possible to have both, but it would require rethinking of the entire chain. Something that’s firmly out of the scope of this thread (I was thinking about “patching” the current situation, not throwing everything out and starting anew)
(DIR) Post #B4JUNLxCBtiGyutszQ by evey@chaos.social
0 likes, 0 repeats
@domi @erincandescent @alwayscurious @valpackett imo the whole push to more open firmwares is the solution so that users who *want* to do that can run there own firmwares and to this them selfs. But given from the hyperscalers the whole we want to have our own root of trust is a big requirement more and more vendors are offering this as a option at least.
(DIR) Post #B4JUNMO8ZjGQKTVOz2 by domi@donotsta.re
0 likes, 0 repeats
@evey @erincandescent @alwayscurious @valpackett i think there’s a disparity between what hyperscalers need and what end-users need. which is normal, we shouldn’t pretend there’s a one-size-fits-all solution
(DIR) Post #B4JVnf4xo24lmTdtia by jana@social.jsteuernagel.de
1 likes, 0 repeats
@domi Hmm, I don't know a lot about this, but it seems like the kind of thing that is addressed when you pair some hardware security token for attestation to FDE, to block disk unlock when something is not right.Secure Boot is used to verify the integrity of the boot chain and TPM PCR7 is bound to FDE. So if anything about the Secure Boot process or bootloader changes, PCR7 will be different an no automatic unlock will happen (I totally locked myself out of my homeserver once, because I installed 2 SSDs and that changed the PCR7...).So the root of trust is with the TPM module, which yeah, theoretically if one knew or observed the expected value of PCR7 that LUKS expects to unlock, one might be able to bypass that in a way to be able to supply your own value. Though with TPM modules now typically as part of the CPU, that sounds unlikely to me.Yet one could also use a FIDO token with LUKS, which requires some challenge there, but I have no idea about how that works at all.
(DIR) Post #B4Jfioj3VmfjnEiwjI by multisn8@mastodon.catgirl.cloud
1 likes, 0 repeats
@domi Nitrokey attempted the challenge-response idea you had: https://docs.nitrokey.com/nitropad-nitropc/secure-starting-proceduretheir impl is shallow and faking Heads' UI would suffice to fool the user (go through https://docs.nitrokey.com/nitropad-nitropc/heads/system-update and you get a feeling for why), might be useful as a reference though
(DIR) Post #B4JfjtFy9SDS8QdAC8 by multisn8@mastodon.catgirl.cloud
1 likes, 0 repeats
@domi that (plus secure boot for an additional chance of detecting tamper, plus a decoy OS to fool the on-ground agent into giving one the payload, plus physical intrusion markers via sealed screws (https://docs.nitrokey.com/nitropad-nitropc/sealed-hardware)) is the best possible approach on the generic PC, I believe.attack vectors that remain are firmware compromise via ports, software compromise via the net, social compromise and habit failure (not checking the screws before boot, not noticing a changed pattern on the seal)i've outlined some theoretical background and one possible scenario on my security-for-everyone talk on the interfug 2025, don't think it's of much use to you given you already have all the prerequisites
(DIR) Post #B4K3e9W9B8WpjIzjKS by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@wolf480pl @domi @dragoonaethis Yeah, I think the glitter thing is a fun hack but not that high to break, it's like avoiding cutting a "warranty void if broken" sticker.Tamper evidence that I'd have more trust in is basically RTC clock where when the box is opened the connection gets cut, either due to a thin wire or switch that's normally always pushed. (Seen that setup in commercial HSMs)
(DIR) Post #B4KGqRVHQp5eOKmPce by domi@donotsta.re
0 likes, 0 repeats
@zeichenreihe you’re not supposed to give me more scenarios where my assumptions break, you’re supposed to help me figure out ways to attest that the environment is sane :/i can think of all the bad things about this by myself, i don’t need help
(DIR) Post #B4KKmiI9TGTz7M7HJQ by j-g00da@donotsta.re
1 likes, 0 repeats
@domi hey that's me! I'm actually doing this. Wait what do you need that wrench for?
(DIR) Post #B4KKnVEHWRVAtXgNaC by domi@donotsta.re
0 likes, 0 repeats
@zeichenreihe you’re not clever / funny