• Laser@feddit.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    3 days ago
    1. The spec allows changing keys by the user as far as I know
    2. I’m unaware of a proposal of a better concept that stops attacks at this layer
    • WhyJiffie@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 days ago

      well Android Verified Boot also allows changing keys! but like 15 niche phones implement that function out of thousands. out of which it is broken on several such thatit bricks the phone permanently. further, android hardware attestation can make use of AVB, but virtually no apps use it, every app doing such a verification depends on google play integrity, for which you can’t change keys and still pass the ckecks.

      google has already implemented on android what microsoft is only just dreaming of to pull off, despite preparing it since much earlier. I don’t know what they are waiting for, everyone knows there would be no negative consequences to them.

      • Laser@feddit.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 days ago

        These protections work at different layers and hence, you use both.

        First off, you can’t really encrypt the first boot loader by design, your UEFI needs something it can read and run. You need to protect this first boot stage somehow, and this is what Secure Boot is for; it verifies the signature of the payload it starts to protect it against tampering.