@TommyTran732 everything is in nuance and nothing in this world is static. If bootguard was once thought as a good idea by some, it was proven to not be. I would love to see references from Purism saying tampering prevention for Pureboot, since the protections offered are the ones of Heads which Pureboot is a fork, and Heads is about tampering evidence, nothing more unless marketing speech messups written by people not understanding technology.
@TommyTran732 I do not appreciate direct attacks, as all human beings. I do my best under Heads, most of my work having been unpaid and Heads as of today is a story of contributionnism from a lot of experts, enterprises, security enthusiasts and privacy conscious which bootguard is incompatible in basic philosophy principles.
You keep looping around the fact that nothing protects the bootblock and you are right, unless WP pin of SPI is soldered to GND of the motherboard. There would be no problem there if bootblock code itself was not changing, but its not the case, so some adapters were made; some funded work has happened to push forward partial region write protection with flashrom, but yet again, the partial region being under SPI chip WP requires the bootblock to not change. So some adaptrs were created to permit a switch on/off the WP to GND. But that doesn’t get traction because people are afraid of soldering, where some adapters got more traction then others for workstations where SPI chips can be replaced with embedded adapter. But that again doesn’t prevent physical access tampering, leving BootGuard to be the only fused, OTP solution which most experts would advise against, still you refuse to discuss with those experts and continue to claim that because the bootblock could lie about its own measurement and other coreboot parts measurements, then the bootblock itself is not trustworthy.
You denied the fact that to get the firmware version itself, you need physical access to the machine. Then rrefused to even go Heads way of testing this without requiring hardware, doing the PoC on qemu platforms that today, require absolutely no hardware outside of your own machine to tinker with, since qemu support now enforces vTPM and canokey (OpenPGP smartcard) so that you could turn your hypothetic exploit into reality for whatever reason that is yours.
The reality of Heads is that having the public key of the user alone to inject into a reproducible version of the flashed firmware is not enough to produce a firmware that would pass attestation. The public key was imported into firmware and injected as the keyring inside of CBFS, and that CBFS file is measured both by the bootblock as part of the payload region under measured boot, and by Heads extended security policies. I don’t deny the theoretical possibility of someone being able to tamper with the bootblock, that is not the flaw in your reasoning, on that you are right and always was. The flaw in your reasoning is that to be able to fake measurements, you need physical access to the recovery shell or unlocked powered on machine to pull out at least the logs of cbmem to get the TPM extended PCR measurements from TCPA/TPM event cbmem log, not the final ones stored in TPM PCR as result of multiple extend operations. You seem to miss how things work. To get to the final measurements of the TPM, you need to access from unlocked machine again exposed TPM filesystem under /sys. But you won’t get the specific measurements of neither the bootblock there nor any parts needed to extend the TPM event log to arrive to that final measurement, and you cannot simply inject the final desired value into a TPM. Basically, to succeed in your task, you would absolutely need a flash dump of the actual firmware to get imported pub keyring and trustdb state, as it was constructed at Factory reset/re-ownership of the machine and the ROM actually on SPI flash, and to get that, you would also need root privileges or access to Heads recovery shell, which is now guarded optionally under authentication with USB Security dongle. You would have to inject static measurements of the measured parts themselves and modify API calls inside of coreboot with hardcoded values for each of them, then modify Heads scripts to also do the same thing with hashes of parts measured to arrive to the same result. Let’s say you have capabilities to do that; its not just about modifying the bootblock here, but measuring calls for each of the parts involved who do the calls for PCR extend operations. Of course you could get access to the needed firmware parts measured by opening the machine itself, and get a physical backup of the firmware, but then again you are against Blink comparison and checking for physical intrusion. So ok, someone can take a physical backup of SPI chip and start the work of hardcoding hashes in all parts doing read+hash of regions and hardcode those values bypassing read+hash functions, injecting static values, but definitely not a trivial task to repeat for all possible versions of Heads out there with no release since rolling and reproducible builds, where again public key of user is not enough but firmware backup needed to reinject keyring+trustdb+config.user overrides. And then again, you are against keeping the zip file you would have flashed on a seperate USB thumb drive or under /boot (detached signed, trusted) you keep with you at all time and use if you left your laptop behind so that you could flash internally that firmware image that would produce the same remote attestatied state. But yet again you distrust internal flashing and flashrom binary there to be trustworthy and telling that it could also lie to you… Basically you distrust everything not bootguard, but then refuse to look at bootguard successful attacks that actually completely bypassed its security premises, multiple times, with multiple PoC and story repeating itself mostly every years since its inception, with TOCTU attacks, S3 attacks, most of things discovered and whislteblowed to the public by FOSS developers which tries to create alternatives and implore people to distrust Bootguard while showing its flaws to be at least improved upon, which you choose to celebrate in this thread instead. I don’t understand your reasoning. You choose what you trust by faith here. Nothing else, really. You prefer to trust others then your opsec. You choose… That may be ok for you from your own theoretical background and understandings of buying something new because you accept to lease your machine and rights, but we cannot mix everything like that.
And on that, I would repeat. If I was to hack your laptop @TommyTran732, I would place an implant on your keyboard wires to capture key presses and then access your encrypted content. I would install that implant once, and come back tomorrow and steal your laptop. Bootguard won’t prevent this. Heads won’t prevent this. Nail polish can prevent this. Proper opsec can prevent this. Blinded faith won’t save you of everything. And believing Bootguard is good is also denial driven, research and each black hat /red team conferences in the past proved this technology should die, but we don’t have anything better, therefore opsec is the sole savior in all cases until we build something better where transfer of ownership is possible and does not prevent improving the ecosystem, with UEFI supply chain being really problematic in the closed source ecosystem which you also prefer to close your eyes upon, voluntarily or not, i’m not sure.
This discussion is flawed since its beginning.
If Purism had broken advertisement in the past, were the first to be certified with QubesOS while changing their hardware platform without renegociating/breaking the certification, the people working at Purism are not the same as back then, and actually Purism contributed to the whole ecosystem in a way that benefited all of it.
I don’t understand nor acknowledge the validity of most of the content of this thread, therefore I limit my participation in it. This conversation is not helpful for anybody. Its not even constructive. In my opinion some valid points were raised, but this is not the place for them, while my intention is not to censor anyone.
But as FOSS users/contributors, those comments/discussions should turn into actionnable issues so that the problems raised are actually worked on and eventually fixed or enticing collaboration so all eyes are looking at the ideal we want tot attain, not throw who attempts in the dirt forever. To me all of this is as good as a living room conversation with too much booze involved, thinking that that conversation alone will change anything of what happens outside of that room. It won’t.
@TommyTran732 your energy and criticisms are valid in some aspects, but I repeat, not here, not the way you actually do it. At best, you are harming the whole ecosystem instead of bettering it. That’s a choice of yours you can revisit and change at any moment, at your will and convenience. Choose to work for something, not against something. Are you working for Bootguard? It looks like it. Not doing a choice is also doing a choice. And all we do is choose at every moment. I choose where I invest my energy and time to try to change the things i’m against with something i’m for. I wish everyone would do the same, because they could also make that choice and the difference needed. Status quo is not an option. And celebrating a flawed and dying technology should not be part of the options. Not owning the keys should not be an option. Easing owner control/transfer and developing alternatives should be the priority, in the hope that this will get collaboration and traction into replacing this OTP idea which was wrongly implemented at inception and keeps going because of discourses like this one promoting status quo with ideas like “I have enough money to buy a new laptop if keys are leaked” or “I follow the news so everyone should” ideas, where not a single MSI product has been recalled and AFAIK, MSI is in pretty good financial health, not even being publicly ashamed for not protecting their private keys properly outside of network accessible computers, and all journalists I contacted don’t know why they are not bankrupt today. So… Let me ask you. Do you think we are aware of all leaked private keys @TommyTran732 ? Is this denial by choice? Is this denial convenient at best to believe what you believe based on faith and good will?