In a nutshell, the useful fiction of computer-as-Von-Neumann-meaning doesn’t adequately reflect the reality of modern hardware. Not only does the CPU itself not fit that model (with things like speculative execution, sophisticated power and load management…), but the system as a whole is increasingly an amalgamation of different processors and address spaces.
> That exfiltration is one-time and it's quite hard to recover from.
Not quite true with Signal's double ratchet though, right? Because keys are routinely getting rolled, you have to continuously exfiltrate the new keys.
No I said signing keys. If you're doing MITM all the time because there's no alternative path to route ciphertexts, you get to generate all those double-ratchet keys. And then you have a separate ratchet for the other peer in the opposite direction.
Last time I checked, by default, WhatsApp features no fingerprint change warnings by default, so users will not even notice if you MITM them. The attack I described is for situations where the two users would enable non-blocking key change warnings and try to compare the fingerprints.
Not saying this attack happens by any means. Just that this is theoretically possible, and leaves the smallest trail. Which is why it helps that you can verify on Signal it's not exfiltrating your identity keys.
Ah right, I didn't think about just outright MitMing from the get-go. If WhatsApp doesn't show the user anything about fingerprints, then yeah, that's a real hole.
Yeah, that has societal cost too, to be sure. Which implies prima facie that such infra (roadways, high-frequency train lines) should be minimized. Since the throughout of mass transit is so much higher (iow, the societal cost per-user), mass transit is a better way to minimize those costs than cars.
I think you’re misattrubuting causation here. There are numerous factors that distinguish those two places. Chiefly, they are among the densest places in the world.
Generally speaking, cars are at odds with such extreme density, simply due to geometry (i.e. how much space driving requires); it’s super easy to saturate driving supply in such places.
Think of mass transit and driving as being in an equilibrium with each other. Depending on where the bottleneck is in driving supply, shifting driving demand to transit demand (via improved transit infrastructure) should most often improve driving.
Extreme density like the places you mentioned is challenging just because space is at such an extreme premium. I would argue (and I’m not alone here) that it’s especially challenging because driving is consistently underpriced; the fair value of driving there is likely far higher than the cost that drivers pay. In such circumstances, oversubscribed car infrastructure is the natural outcome.
PowerShell’s syntax Is just fine. Very few special characters, minimal escaping, easy to read. If you understand PowerShell semantics, the syntax comes quite naturally.
> If you try to install a different operating system, your computer will not boot.
That does not follow. That would only very specifically happen when all of these are true:
1. Secure Boot cannot be disabled
2. You cannot provision your own Secure Boot keys
3. Your desired operating system is not signed by the computer's trusted Secure Boot keys
"Starting in a verified state and stay[ing] trusted over time" sounds more like using measured boot. Which is basically its own thing and most certainly does not preclude booting whatever OS you choose.
Although if your comment was meant in a cynical way rather than approaching things technically, than I don't think my reply helps much.
AFAIU (I haven't looked much into it) shim basically exists so that MS signs the shim once (or only a few times when updated), which has the distro public key embedded, which does further verification of the chain (bootloader/kernel) which gets updated more frequently.
That's basically my understanding too. But since you can still boot any shim-supported distro, Secure Boot + shim practically gains you nothing. An adversary can simply boot their own own copy of shim with whatever OS they like.
I don't know all the ins and outs, but because of the Machine Owner Key (MOK) mechanism in shim, it should be possible to boot arbitrary OSes without MS signing anything.
Your step of removing the MS keys works of course :) Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS. Also I think that firmware updates can be problematic?
> Although I've heard that can be risky on various systems that need to load MS-signed EEPROMS
Yea, I bricked a Gigabyte board and still haven't been able to fix it. I just replaced it with an Asrock board and that has settings for what to do with option-rom when secureboot is enabled (always execute, always deny, allow execute, defer execute, deny execute and query user) and I have no clue what half of them specifically do (like, does "allow execute" only execute if a matching key exists and doesn't execute if it doesn't? and what is the difference between "always deny" and "deny execute"? and defer to when??). But I just set it to always execute and my problem is solved.
Immutable, signed systems do not intrinsically conflict with hackability. See this blog post of Lennart's[0] and systemd's ParticleOS meta-distro[1].
I do agree that these technologies can be abused. But system integrity is also a prerequisite for security; it's not like this is like Digital "Rights" Management, where it's unequivocally a bad thing that only advances evil interests. Like, Widevine should never have been made a thing in Firefox imo.
So I think what's most productive here is to build immutable, signable systems that can preserve user freedom, and then use social and political means to further guarantee those freedoms. For instance a requirement that owning a device means being able to provision your own keys. Bans on certain attestation schemes. Etc. (I empathize with anyone who would be cynical about those particular possibilities though.)
Standardizing that approach is one thing that the systemd project has been working on. They've built various components to help with that, including writing specifications (via the UAPI group) on how that should all fit together.
ParticleOS[0] gives a look at how this can all fit together, in case you want to see some of it in action.
In a nutshell, the useful fiction of computer-as-Von-Neumann-meaning doesn’t adequately reflect the reality of modern hardware. Not only does the CPU itself not fit that model (with things like speculative execution, sophisticated power and load management…), but the system as a whole is increasingly an amalgamation of different processors and address spaces.
reply