And what good is the phone when 3 switches are off? You think that people buy a phone with a "mic killswitch" expects to have to turn off practically everything including internet to make sure that their mics aren't snooped on?
Does that really sound like a functioning "killswitch"?
On a long enough timeline he'll probably cite this comment chain as proof you were unable to respond to his concerns, like everyone else who's ever tried.
Oh he's already done that when I explained to him how stuff like PureBoot has circular logic and doesn't actually work on Qubes forum already.
Unfortunately he will just ignore every single counter argument ever made and blindly believe these companies because their marketing material has "freedom" and "FOSS" in it.
On Qubes forum, you had replies from far more knowledgeable people than me. You never could answer to them. You only talk about the lack of security of Pureboot and never showed the code breaking it. "Talk is cheap, show me the code".
I did reply to them plenty of times. Here you go doing the exact same thing again - ignoring 100% of what's being said, then claiming "no one can respond".
> You only talk about the lack of security of Pureboot and never showed the code breaking it.
If you think a piece of code is needed to understand why it's a joke, then I don't even understand what is wrong with you. LMAO. The whole thing is conceptually botched, and they pretty much admitted as much.
1. Boot block performs measurements of itself, its settings and everything down the chain for attestation.
2. There's nothing protecting the boot block.
3. A malicious boot block can lie about measurements.
4. If the goal is to defend against an attacker who tampers with the BIOS chip - then it fails at doing so miserably because an attacker can just use a boot block that lies about the measurements.
Seriously, what good is showing you the code if you don't even conceptually understand how the thing works?
You know, there is a famous saying: A farmer does not need to know how to lay eggs to know whether an egg is good or bad. In our case, the egg is already rotten from the get-go. This is not a "Ohhh something has such bad code I can attack it using XYZ method, wait and see!" situation. This is a situation where "Your logic doesn't even make any sense to begin with."
Perhaps, just perhaps, you can benefit from just spending 5 minutes thinking a bit about how the whole thing actually works at a very high level and read what I said above.
Thank you for your kind advice, but I prefer to trust a developer of Heads and many Qubes contributors instead of a loud Internet commenter criticizing everything and everyone.
The developer of Heads admitted that if someone tampers with the boot block and falsifies the measurements Heads cannot protect the device right on the Qubes forum. Why won't you listen to him then? Is he not trustworthy enough for you?
@TommyTran732, you are going to a great length to downplay everything about devices/companies promoting freedom, including Librem 5, Purism, and laptops with Heads. And you are promoting proprietary staff instead. This looks like trolling or astroturfing. For observers, here is the actual quote from the heads developer, not in the (incorrect) interpretation of TommyTran732:
As I pointed before @TommyTran732 and to anyone thinking compromising measured boot is trivial, I layed down the tooling for anyone wanting to further protection / prove measured boot not enough to understand and break it once and for all under WiP: introspection - replicate TPM PCRs measurements directly from measured content (TCPA/TPM Event log) by tlaurion · Pull Request #1568 · linuxboot/heads · GitHub
Just use it for the bad to faster the development of something good/better.
Yeah, why are you selectively reading? This is after he admitted what I said was true. His only contention is that he thinks it's hard to know what the PCR values should be to fake, so he calls that "security". You are being extra ordinarily disingenuous here.
> The goal of Heads is to bring reasonably trustworthy firmware on reasonably open platforms to boot reasonably secure OS, enforcing best effort user controlled atteststion, compartmentalization and prevention. Never is it written anywhere that the firmware is tampering resistant or tampering proof: we lack open source implementation in hardware to have root of trust in hardware. Heads is best approach on what is available, the anchor of trust being in the bootblock, not in hardware. The chain of trust lies there. Of course an evil maid could craft a firmware that would lie about its measurements in the bootblock, raminit, romstage and the payload. But as today, no PoC has even been made public, showing it being actoinnable, and by nature of TPM extend operations is nothing easy to realize, while possible.
I am just gonna highlight the critical part here one more time, since I sent you the same thing before and you didn't read:
> *Of course an evil maid could craft a firmware that would lie about its measurements in the bootblock, raminit, romstage and the payload.*
Yeah, I wouldn't call heads "best approach on what is available" and I do think Boot Guard is better, but at least he is honest about the actual mechanism and the very obvious attack vector.
Qubes team never criticized Purism laptops for their lack of security. At least I didn't see that. They criticized other things, which may be important for some and less important for others. The phone is off-topic on the Qubes forum, so its security was never thoroughly discussed.
Does that really sound like a functioning "killswitch"?