Announcement

Collapse
No announcement yet.

Measured Boot Support Is Heading To Coreboot

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Measured Boot Support Is Heading To Coreboot

    Phoronix: Measured Boot Support Is Heading To Coreboot

    Developers have been working on TPM-backed measured boot support with Coreboot. The patches are pending for upstream Coreboot to be able to offer this trusted boot integration...

    http://www.phoronix.com/scan.php?pag...-Boot-Coreboot

  • #2
    Originally posted by phoronix View Post
    for determining if the system is in a trustworthy state
    Trustworthy to who/whom? I'm pretty sure it's to the company delivering the system...

    The system should trust me, not any company.

    Comment


    • #3
      Originally posted by tildearrow View Post
      Trustworthy to who/whom? I'm pretty sure it's to the company delivering the system...
      To whoever cares for looking into these values and comparing them against whatever values they consider desirable.

      Originally posted by tildearrow View Post
      The system should trust me, not any company.
      This isn't about the system trusting anybody, but about somebody (e.g. you) trusting the system.

      Comment


      • #4
        also, it's not very useful for any serious security / trust, unless there is special dedicated hardware developped(*).

        the idea of this measured boot is to run non-signed/non-trusted code anyway, but give the possibility to check this later.

        except: not how are you going to check this in a non-trusted system (without dedicated hardware, that is)?
        the non-signed OS you're running might have been patched, so it always thinks the signature is legit.
        (in fact, some gaming console exploits work this way)

        once you boot a non-trusted OS, the OS it self can't be trusted for it's own checks, even if the measured boot records everything.

        ----
        (*) e.g.: new hardware where the TPM chip is directly wired to a led signalling signature failure. When the signature check fails, the signature storage chip immediately triggers the LED. even a patched OS would then not be able to hide its signature failure.

        same with other secure function: a signature check failure should trigger a special mode in thr signature chip, where it will subsequently refuse to use some critical keys for the current boot. (e.g.: will not sign your banking stuff until you reboot without tripping a sig failure).

        that's basically how some smartphones handle it (except it's irreversible).
        unlock the boot loader (so you can run your own unsigned custom rom) and phone fries its TA (the part of the flash holding a fw critical DRM keys).

        Comment


        • #5
          what i am saying is that
          Once booted, the operating system or other component can then compare the measured boot hashes/values against the "golden values" stored securely elsewhere for determining if the system is in a trustworthy state.
          this golden values snd their comparison should be entirely outside the booted OS.
          otherwise:
          - the OS might contain wrong golden values patched in
          - the OS might lie and provide bogus hashes that match the golden values, instead of relaying whatever coreboot measured.

          it is extremely important that this other component is not os dependent (hence my exemple of using the secure key storage chip)

          Comment


          • #6
            Originally posted by DrYak View Post
            also, it's not very useful for any serious security / trust, unless there is special dedicated hardware developped(*).
            Like a.. TPM chip?
            Originally posted by DrYak View Post
            (*) e.g.: new hardware where the TPM chip is directly wired to a led signalling signature failure. When the signature check fails, the signature storage chip immediately triggers the LED. even a patched OS would then not be able to hide its signature failure.
            Its true, that once compromised, you can replace pretty much everything. but you should be able to detect this atleast (https://en.wikipedia.org/wiki/Remote_attestation). Ie. you need some kit of software having some public keys from your unique TPM chip, it can then create request for that particular TPM chip and the running OS which cant be forged (realistically).

            The thing is that you would be able to boot your trusted OS, and it can detect whether it has been tampered with. Not that an untrusted OS will have any limitations.

            Comment


            • #7
              The thing is that you would be able to boot your trusted OS, and it can detect whether it has been tampered with.
              except if the tampered part is the part that does the detection (e.g. patching the code that requests the TPM chip).
              then you can't detect shit.

              basically, the only secure thing would be to rely on completely independent external stuff.

              e.g.: the small calculator shaped two-factor auth box that some European banks provide you.
              Even if you system is completely hosed, you're going to notice that the box doesn't say the same as the e-banking website on the screen.

              (hosed system: "please validate payment of 10€ to ebay seller". box "you are currently paying 10 million € to criminsl. Aprove?")

              Comment


              • #8
                Originally posted by DrYak View Post

                except if the tampered part is the part that does the detection (e.g. patching the code that requests the TPM chip).
                then you can't detect shit.
                Nope, the remote part can create an arbitrary amount of different challenges, you cant replicate them unless you pry out some keys from the remote part aswell.

                The way it works, is that you send data to the TPM chip and it will hash them. You wont be able to get the initial hash(es), but you get some derived hashes after sending in additional data.
                the remote end can indirectly verify steps from the boot process this way, and send additional challenges verifying the TPM chip hasn't been tampered with.

                Comment


                • #9
                  Originally posted by tildearrow View Post
                  Trustworthy to who/whom?
                  To whoever has setup all this crap. Considering that we are talking of Coreboot and Linux this can mean either a vendor, or the device owner if the device allows reflashing.

                  The system should trust me, not any company.
                  This is an anti-tampering system, meant to ensure that none goes and compromises the Linux kernel you store in an unencrypted partition to boot from.

                  Comment


                  • #10
                    Originally posted by pgeorgi View Post
                    This isn't about the system trusting anybody, but about somebody (e.g. you) trusting the system.
                    What nonsense. You're expecting a compromised system to honestly report its own measurement to you.

                    Spell out the attack model in detail and you'll realize this is all snake oil.

                    Trusted Crap like this only makes sense to people too feeble-minded to think it through and spell out the attack model.

                    Comment

                    Working...
                    X