9 ms·

This NSA report is a wonderfully thorough guide to configuring UEFI Secure Boot, although it is another example of how unusable security tools can be. This conp

This NSA report is a wonderfully thorough guide to configuring UEFI Secure Boot, although it is another example of how unusable security tools can be. This conplexity was my motivation for writing the safeboot[1] scripts, which wrap all of the signing key management, TPM key sealing, and attestation into a hopefully easier to use package. 1: https://safeboot.dev/ https://safeboot.dev/

ComodoHacker 6y ago
Thank you! Please update your main page title, so a quick-made bookmark remains searchable when needed.
strstr 6y ago
It’s cool to see other uses of the TPM in the wild! My coworkers and I maintain go-tpm-tools[0] for trying to make using the tpm straightforward. [0] https://github.com/google/go-tpm-tools https://github.com/google/go-tpm-tools.
- mjg59 6y ago
  (additional plug) portions of which are used to enable github.com/google/go-attestation, which aims to make it practical for verification of system boot state in a heterogeneous environment and is now being actively used inside Google.
nextgens 6y ago
It's amazing that you disregard the most basic attack in your threat model (https://safeboot.dev/threats/ https://safeboot.dev/threats/): going after the TPM itself. TPMs are usually FIPS 140-2 L2: not something that's meant to be hardened against even basic hardware attacks. IMHO the TPM should be a required piece but not the only piece of the puzzle. If I loose my laptop, I don't want the goods to be protected exclusively by a key that's trivial to recover from it (stored in something that's not a secure-element). I've covered it in a talk I gave at 44con: https://www.youtube.com/watch?v=YZTWjLTz4AE https://www.youtube.com/watch?v=YZTWjLTz4AE tl;dr; Use the TPM (and potentially other technologies like SGX) as part of your KDF to strengthen PIN/passphrase that the user provides. This breaks the asymmetry of offline attacks (attacker will always be bound by TPM/SGX-speed). Do NOT give it the only key required to decrypt your data.
- vladvasiliu 6y ago
  The way I see it, safeboot is a bunch of scripts helping to set up solutions already available. I didn't look at it in details, but in one of the screenshots the system asks for a pin to unlock the disk. I agree that storing a full decryption key in the TPM may be risky. Even if the thread model should be considered (it may not be interesting for an attacker to go around doing this to Joe Random's laptop) it is something that users should be aware of.
- rocqua 6y ago
  It is very much news to me that key-recovery from the TPM is not supposed to be that hard. If that is the case, how does it strengthen a PIN? Any attacker wanting to find a decryption key could simply extract the key, and then brute-force the PIN outside of the TPM constraints, can't they?
  - nextgens 6y ago
    The PIN isn't required if you decap the TPM.
    - HelloNurse 6y ago
      Decapping doesn't count as a "basic hardware attack".
      - m0zg 6y ago
        For the NSA it does. :-)
        Avamander 6y ago
        If the NSA is in your threat model, you've lost the game.
        wolfgke 6y ago
        > If the NSA is in your threat model, you've lost the game. For example for cryptographic primitives, if you didn't include the NSA in your threat model, you did something deeply wrong in your modelling.
deleted 6y ago
[deleted]
codethief 6y ago
I've been following safeboot for a while and it looks really, really cool! One concern I've been having regarding a read-only root file system – an idea that I really like! – was how cumbersome software updates (say, through apt) and quick config changes (in /etc) must be. AFAIU I'd have to manually sign a new rootfs image every single time[0] which looks rather painful to me. I wish Linux distributions provided a clear separation between user-facing software & configs and system-internal stuff that one hardly ever has to touch: IMHO software & configs should by default get installed on a per-user basis and not require root. (And applications should also be sandboxed by default but I'm digressing…) [0] https://safeboot.dev/install/#root-filesystem-updates https://safeboot.dev/install/#root-filesystem-updates
- thudson 6y ago
  In practice it is a bit of a pain during the initial setup and package installation -- I was probably rebooting to recovery mode once a day or more to install some command line tool that I had forgotten about. Once the machine is configured then it is a more rare occurrence, although your usage might vary. Something that I'm not happy about is that the snaps all live on the writable /var since they want to do automatic updates all the time. This is problematic for a locked-down configuration and might recommend against a snap based distribution. Separating out the bootable bits from the rest of the packages might help, as would running more things in sandboxes. Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This is also useful for fleet management -- the new root filesystem, kernel, initrd, etc can arrive "behind the scenes" and on the next reboot is the one that is used. Since the PCRs can be predicated as well, the PCR policy can be signed and sent along with the upgrade to make it seamless.
  - codethief 6y ago
    > Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This sounds very nice and similar to Android's A/B partitions! > Since the PCRs can be predicated as well This may be a stupid question but… what are PCRs? Google yields "polymerase chain reaction" – a method used, among others, for detecting the coronavirus but I'm sure that's not it. :)

ComodoHacker 6y ago

Thank you! Please update your main page title, so a quick-made bookmark remains searchable when needed.

strstr 6y ago

It’s cool to see other uses of the TPM in the wild! My coworkers and I maintain go-tpm-tools[0] for trying to make using the tpm straightforward. [0] https://github.com/google/go-tpm-tools https://github.com/google/go-tpm-tools.

mjg59 6y ago
(additional plug) portions of which are used to enable github.com/google/go-attestation, which aims to make it practical for verification of system boot state in a heterogeneous environment and is now being actively used inside Google.

nextgens 6y ago

It's amazing that you disregard the most basic attack in your threat model (https://safeboot.dev/threats/ https://safeboot.dev/threats/): going after the TPM itself. TPMs are usually FIPS 140-2 L2: not something that's meant to be hardened against even basic hardware attacks. IMHO the TPM should be a required piece but not the only piece of the puzzle. If I loose my laptop, I don't want the goods to be protected exclusively by a key that's trivial to recover from it (stored in something that's not a secure-element). I've covered it in a talk I gave at 44con: https://www.youtube.com/watch?v=YZTWjLTz4AE https://www.youtube.com/watch?v=YZTWjLTz4AE tl;dr; Use the TPM (and potentially other technologies like SGX) as part of your KDF to strengthen PIN/passphrase that the user provides. This breaks the asymmetry of offline attacks (attacker will always be bound by TPM/SGX-speed). Do NOT give it the only key required to decrypt your data.

vladvasiliu 6y ago
The way I see it, safeboot is a bunch of scripts helping to set up solutions already available. I didn't look at it in details, but in one of the screenshots the system asks for a pin to unlock the disk. I agree that storing a full decryption key in the TPM may be risky. Even if the thread model should be considered (it may not be interesting for an attacker to go around doing this to Joe Random's laptop) it is something that users should be aware of.
rocqua 6y ago
It is very much news to me that key-recovery from the TPM is not supposed to be that hard. If that is the case, how does it strengthen a PIN? Any attacker wanting to find a decryption key could simply extract the key, and then brute-force the PIN outside of the TPM constraints, can't they?
- nextgens 6y ago
  The PIN isn't required if you decap the TPM.
  - HelloNurse 6y ago
    Decapping doesn't count as a "basic hardware attack".
    - m0zg 6y ago
      For the NSA it does. :-)
      - Avamander 6y ago
        If the NSA is in your threat model, you've lost the game.
        wolfgke 6y ago
        > If the NSA is in your threat model, you've lost the game. For example for cryptographic primitives, if you didn't include the NSA in your threat model, you did something deeply wrong in your modelling.

deleted 6y ago

[deleted]

codethief 6y ago

I've been following safeboot for a while and it looks really, really cool! One concern I've been having regarding a read-only root file system – an idea that I really like! – was how cumbersome software updates (say, through apt) and quick config changes (in /etc) must be. AFAIU I'd have to manually sign a new rootfs image every single time[0] which looks rather painful to me. I wish Linux distributions provided a clear separation between user-facing software & configs and system-internal stuff that one hardly ever has to touch: IMHO software & configs should by default get installed on a per-user basis and not require root. (And applications should also be sandboxed by default but I'm digressing…) [0] https://safeboot.dev/install/#root-filesystem-updates https://safeboot.dev/install/#root-filesystem-updates

thudson 6y ago
In practice it is a bit of a pain during the initial setup and package installation -- I was probably rebooting to recovery mode once a day or more to install some command line tool that I had forgotten about. Once the machine is configured then it is a more rare occurrence, although your usage might vary. Something that I'm not happy about is that the snaps all live on the writable /var since they want to do automatic updates all the time. This is problematic for a locked-down configuration and might recommend against a snap based distribution. Separating out the bootable bits from the rest of the packages might help, as would running more things in sandboxes. Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This is also useful for fleet management -- the new root filesystem, kernel, initrd, etc can arrive "behind the scenes" and on the next reboot is the one that is used. Since the PCRs can be predicated as well, the PCR policy can be signed and sent along with the upgrade to make it seamless.
- codethief 6y ago
  > Another option that we're exploring is some lvm magic to create a snapshot, upgrade the snapshot, sign it, and then on the next reboot use it as the real root. This sounds very nice and similar to Android's A/B partitions! > Since the PCRs can be predicated as well This may be a stupid question but… what are PCRs? Google yields "polymerase chain reaction" – a method used, among others, for detecting the coronavirus but I'm sure that's not it. :)