4 ms·

Just some small notes/nitpicks... >the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues. I he

by zxzax 5y ago

Just some small notes/nitpicks... >the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues. I hear this type of thing often but it's the wrong mindset to take when dealing with this stuff. Security holes in one part of the stack are not an excuse to avoid fixing security holes in other parts -- if you do that, you now have multiple security bugs that are going unfixed. >And the much lower complexity means many fewer places for security bugs to be accidentally introduced. This doesn't seem to make any sense, avoiding securing the boot process does not mean the boot process is any less complicated or somehow has less parts that can be compromised. TFA is just describing how to secure the parts that are already there. >They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway. I'm not sure how this is related, building a tamper-proof case seems to be outside of the scope of this. This seems to cover only the software parts.

michaelt 5y ago
> avoiding securing the boot process does not mean the boot process is any less complicated Of course it does: Not only does secure boot add an extra point of failure, it's a point of failure that's specifically designed to be highly sensitive, and to fail locked, and that hardly anyone in the kernel development community is testing with. > I'm not sure how this is related From a computer owner's point of view, the TPM's secure boot functionality exists only to protect against attackers with physical access to the device. After all, if a malicious attacker making a remote attack has the ability to replace your bootloader or reflash your BIOS, they've already got everything. In other words, secure boot is there to protect against an evil maid [1] removing your hard drive, replacing your bootloader with one that logs your full disk encryption password, then subsequently stealing your laptop and password at the same time. Or something of that ilk. However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide. A serious system - like the xbox's security system - (a) has the functionality on the CPU die, and (b) has the hardware for full speed RAM, bus and disk crypto, all with keys that are inaccessible to the OS. [1] https://en.wikipedia.org/wiki/Evil_maid_attack https://en.wikipedia.org/wiki/Evil_maid_attack
- zxzax 5y ago
  I don't understand what you mean extra point of failure. There is a boot process, you can't get rid of it because then you can't boot the machine. So you either secure it or you don't. I get the concern that the hardware implementation could contain bugs, and that's a real concern, but your system is not going to be less secure by having this -- at worst, it seems it can only be as insecure as it would be without it. >However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide. I don't think anyone is saying TPM or secure boot alone is going to prevent against such attacks. It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind.
  - salawat 5y ago
    Likely what they are referring to is how UEFI has greatly complicated the nature of a computer's boot process by essentially inserting a firmware runtime into what was a simpler to understand chain of POST->Hand off to program at address. I had issues wrapping my head around this as well with regards to things like Network Boot etc, where I could not for the life of me understand or justify a boot process having a runtime capable of doing all this extra cryptographic/network nonsense when all I bloody wanted was my OS, up, now. Not to get nostalgic, but that magical era for a user around Windows XP with a <5 second boot was just that; magic. I know all the oldtimers will come out of the woodwork with horror stories of competing, sloppily specified BIOS implementations, the pain of malware hiding in CMOS, the threat of rootkits, etc... And the admins will chime in with "How do you expect me to power on the thousands of servers in my datacenter without network access during boot"? Those are valid and real situations in isolation I can stomach. I cannot, however, stomach a boot process whereby a non-owner arranges things in a way where it is guaranteed that they get the final word in deciding how hardware you paid for is used, which requires the composition of those services.
  - michaelt 5y ago
    > It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind. xboxes and iphones don't need tamper-proof cases.

by zxzax 5y ago

michaelt 5y ago

> avoiding securing the boot process does not mean the boot process is any less complicated Of course it does: Not only does secure boot add an extra point of failure, it's a point of failure that's specifically designed to be highly sensitive, and to fail locked, and that hardly anyone in the kernel development community is testing with. > I'm not sure how this is related From a computer owner's point of view, the TPM's secure boot functionality exists only to protect against attackers with physical access to the device. After all, if a malicious attacker making a remote attack has the ability to replace your bootloader or reflash your BIOS, they've already got everything. In other words, secure boot is there to protect against an evil maid [1] removing your hard drive, replacing your bootloader with one that logs your full disk encryption password, then subsequently stealing your laptop and password at the same time. Or something of that ilk. However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide. A serious system - like the xbox's security system - (a) has the functionality on the CPU die, and (b) has the hardware for full speed RAM, bus and disk crypto, all with keys that are inaccessible to the OS. [1] https://en.wikipedia.org/wiki/Evil_maid_attack https://en.wikipedia.org/wiki/Evil_maid_attack

zxzax 5y ago
I don't understand what you mean extra point of failure. There is a boot process, you can't get rid of it because then you can't boot the machine. So you either secure it or you don't. I get the concern that the hardware implementation could contain bugs, and that's a real concern, but your system is not going to be less secure by having this -- at worst, it seems it can only be as insecure as it would be without it. >However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide. I don't think anyone is saying TPM or secure boot alone is going to prevent against such attacks. It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind.
- salawat 5y ago
  Likely what they are referring to is how UEFI has greatly complicated the nature of a computer's boot process by essentially inserting a firmware runtime into what was a simpler to understand chain of POST->Hand off to program at address. I had issues wrapping my head around this as well with regards to things like Network Boot etc, where I could not for the life of me understand or justify a boot process having a runtime capable of doing all this extra cryptographic/network nonsense when all I bloody wanted was my OS, up, now. Not to get nostalgic, but that magical era for a user around Windows XP with a <5 second boot was just that; magic. I know all the oldtimers will come out of the woodwork with horror stories of competing, sloppily specified BIOS implementations, the pain of malware hiding in CMOS, the threat of rootkits, etc... And the admins will chime in with "How do you expect me to power on the thousands of servers in my datacenter without network access during boot"? Those are valid and real situations in isolation I can stomach. I cannot, however, stomach a boot process whereby a non-owner arranges things in a way where it is guaranteed that they get the final word in deciding how hardware you paid for is used, which requires the composition of those services.
- michaelt 5y ago
  > It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind. xboxes and iphones don't need tamper-proof cases.