5 ms·

If an "act of aggression" would happen, I would have no recourse against it. But that is besides the fact that these acts of aggression for locking down system

If an "act of aggression" would happen, I would have no recourse against it. But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry. That is not surprising if you look at the economic interests of involved parties. On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies. The primary vector of malware isn't near boot, it is quite exotic these days. Maybe not rare, but not the primary attack for usual targets. But that is also irrelevant if I could just spoof any attestation. Just give me the option. Shouldn't be too much of a request, no? One prediction is that there will be classes of devices. Trusted and untrusted. We already see that happening. This is not desirable for security and in the interest of users. That especially includes journalists and activists. For security it isn't enough to wait for aggression, you also have to look at a larger picture. Some people argued HDCP is to shield against eavesdropping. And it if is in the interest of security, you would need to propose very foundational security arguments. As it is exposing your security state to third parties is an additional threat itself.

rollcat 4y ago
> If an "act of aggression" would happen, I would have no recourse against it. You have the same recourse as you've always had. Vote with your wallet, don't buy the hardware. I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? > But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry. Can you please link me some articles/references? This is relevant to my interests, I would like to actually see something that backs up the counter-argument. > On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies. I'm aware I'm stretching things, but the stance "Secure Boot = attack on computing freedom" is quite regularly stretched to argue against many other hardware security features, such as TPM or Secure Enclave. If my laptop is stolen, confidentiality of all my data is only as good as my passphrase. Am I paranoid enough to employ a complex, unique, zxcvbn-proof passphrase? Hell no. I would much rather use four random dictionary words, and let the TPM throttle cracking attempts. (Yes, I know LUKS offers KDF, with a number of iterations picked to reasonably throttle cracking attempts on today's hardware. I would still rather see the cracking stopped dead after 10 attempts, and this physically requires dedicated hardware.) It's 2023, Thinkpads have been shipping with TPMs for over a decade, and I still can't easily utilise a TPM to keep the FDE decryption key - is it because the TPM genuinely does not offer tangible improvement over plain LUKS, or is it because it was being actively pushed back against in the free software community, and nobody bothered to integrate the functionality? Repeat this for GPG/SSH/FIDO keys, I am expected to buy a dongle that I can lose, and plug it into a USB port - but can't sensibly utilise the hardware that has been soldered onto my motherboard, which was designed with that explicit purpose? Please correct me if I'm wrong, but all I'm seeing is a pattern of: "dedicated security hardware = attack on freedom", with pushbacks at any attempts to utilise such hardware for the benefit of the user. > The primary vector of malware isn't near boot, it is quite exotic these days. APTs / evil maid never stopped being a thing. Security isn't about what's unlikely, it's about the entire chain. Maybe your targeted attack requires a key logger to remain dormant/undetected until a particular moment in time, six months from now, and the best way to hide it is by paravirtualising your kernel. We've seen attacks way more sophisticated than that (stuxnet). > But that is also irrelevant if I could just spoof any attestation. I agree 100%, attestation is just layers of bullshit. But I still want my device to ring an alarm if an APT is suspected.
- PinkSheep 4y ago
  > Can you please link me some articles/references? Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/ https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co... So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited. > > But that is besides the fact that these acts of aggression A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-739441450 https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-... Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do. My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell. > Vote with your wallet, don't buy the hardware. > ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers). > I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality? I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.) > Security isn't about what's unlikely, it's about the entire chain. ... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).
  - rollcat 4y ago

rollcat 4y ago

> If an "act of aggression" would happen, I would have no recourse against it. You have the same recourse as you've always had. Vote with your wallet, don't buy the hardware. I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? > But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry. Can you please link me some articles/references? This is relevant to my interests, I would like to actually see something that backs up the counter-argument. > On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies. I'm aware I'm stretching things, but the stance "Secure Boot = attack on computing freedom" is quite regularly stretched to argue against many other hardware security features, such as TPM or Secure Enclave. If my laptop is stolen, confidentiality of all my data is only as good as my passphrase. Am I paranoid enough to employ a complex, unique, zxcvbn-proof passphrase? Hell no. I would much rather use four random dictionary words, and let the TPM throttle cracking attempts. (Yes, I know LUKS offers KDF, with a number of iterations picked to reasonably throttle cracking attempts on today's hardware. I would still rather see the cracking stopped dead after 10 attempts, and this physically requires dedicated hardware.) It's 2023, Thinkpads have been shipping with TPMs for over a decade, and I still can't easily utilise a TPM to keep the FDE decryption key - is it because the TPM genuinely does not offer tangible improvement over plain LUKS, or is it because it was being actively pushed back against in the free software community, and nobody bothered to integrate the functionality? Repeat this for GPG/SSH/FIDO keys, I am expected to buy a dongle that I can lose, and plug it into a USB port - but can't sensibly utilise the hardware that has been soldered onto my motherboard, which was designed with that explicit purpose? Please correct me if I'm wrong, but all I'm seeing is a pattern of: "dedicated security hardware = attack on freedom", with pushbacks at any attempts to utilise such hardware for the benefit of the user. > The primary vector of malware isn't near boot, it is quite exotic these days. APTs / evil maid never stopped being a thing. Security isn't about what's unlikely, it's about the entire chain. Maybe your targeted attack requires a key logger to remain dormant/undetected until a particular moment in time, six months from now, and the best way to hide it is by paravirtualising your kernel. We've seen attacks way more sophisticated than that (stuxnet). > But that is also irrelevant if I could just spoof any attestation. I agree 100%, attestation is just layers of bullshit. But I still want my device to ring an alarm if an APT is suspected.

PinkSheep 4y ago
> Can you please link me some articles/references? Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/ https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co... So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited. > > But that is besides the fact that these acts of aggression A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-739441450 https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-... Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do. My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell. > Vote with your wallet, don't buy the hardware. > ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers). > I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality? I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.) > Security isn't about what's unlikely, it's about the entire chain. ... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).
- rollcat 4y ago