4 ms·

Why can’t we have both? General-purpose computers for whatever-we-want, and single purpose devices from a trusted source which we can be more confident are unta

by taneq 5y ago

Why can’t we have both? General-purpose computers for whatever-we-want, and single purpose devices from a trusted source which we can be more confident are untampered with?

dmos62 5y ago
I've not thought this through extensively, but couldn't you just flash signed firmwares onto those "single-purpose trusted devices"? If they were open to flashing that is. What more to want from a security perspective? In-device protection from flashing? Sounds similar to security through obscurity. I'd prefer easy ways to check what a device is flashed with. Something like a checksum calculator device. Not sure if that's a reasonable idea.
- mjg59 5y ago
  There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system. That means it has to be impossible to simply re-flash them given physical access, unless you can detect that this has happened. That's what the trusted boot side of this is - it gives you an indication that that reflashing has occurred. Out of band firmware validation is a real thing (Google's Titan sits in between the firmware and the CPU and records what goes over the bus, and can attest to that later), but that's basically just moving who owns the root of trust, and if you don't trust your CPU vendor to properly record what firmware it executes you should ask whether you trust your CPU vendor to execute the instructions you give it. Pretty much every option we currently have is just in a slightly different part of the trade off space.
  - michaelt 5y ago
    > There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system. I looked into TPM stuff a few years ago, and it all seemed pretty useless to me. First of all, the entire key-protection house of cards relies on the assumption if you've booted the right OS, the keys can safely be unsealed. But the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues. Second of all, if you're worried about someone snatching your laptop or phone, full disk encryption where you type the password at boot gets you 99% of the protection with much less complexity. And the much lower complexity means many fewer places for security bugs to be accidentally introduced. Third, if you're worried about evil maid attacks where someone dismantles your laptop and messes with its internals without you knowing then gives it back to you, then the TPM isn't sufficient protection anyway. They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway. And fourth, the TPM doesn't have a dedicated hardware button (making it a shitty replacement for a U2F key) and doesn't have an independent clock (making it a shitty replacement for TOTP on your phone) so it's not even a good replacement for other security hardware. About the only use I can see for this stuff is if you're some huge multinational company, and you think even the authorised users of your computers can't be trusted.
    - 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
josefx 5y ago
Copyright owners will push for the later, maybe even take a page out off Googles Play store licensing and outright prohibit hardware manufacturers of even dreaming about producing a device that doesn't enforce their draconian requirements. So hardware manufacturers get the hard choice of either going for the general market that expects things to work or going for a tiny market that is happy with some of the most popular services not working by design.
- indigochill 5y ago
  > So hardware manufacturers get the hard choice of either going for the general market that expects things to work or going for a tiny market that is happy with some of the most popular services not working by design. Software is already here, particularly in social media (mastodon/SSB vs Facebook). That hardware eventually gets there seems to me an inevitability (arguably we're already at least partially there, as evidenced by the fact Purism/Pine64/etc exist). I still don't see it as a problem, though, because an individual can have different technical interfaces (devices, OSes, etc) for different purposes. Generally, I put my personal stuff on systems I understand/control. For some things, like watching TV, I'm okay with going to Netflix because that transaction is expected to be transitory. If Netflix disappears or declares themselves a new world order tomorrow, I can simply unsub and no harm done. Where things get problematic is when so much of someone's life is wrapped up in a mono-corporate cocoon (e.g. Amazon shipping things to your house and running your servers, or Google serving you search results + mail + maps).
  - josefx 5y ago
    > I can simply unsub and no harm done. But your TV manufacturer still wants to provide Netflix to other users and Netflix decided to require all their devices to run its trusted code if they want to provide Netflix to anyone, whether you in particular want it or not. So your choice is to trash your existing TV and track down a manufacturer that doesn't have any support for Netflix, Hulu, Youtube, Amazon Prime, etc. at all to buy a new TV that doesn't ignore your choice. With TVs you might be lucky since there is a large market for dump displays that avoid any TV related functionality anyway, of course there might be restrictions in the license between Netflix and the TV manufacturer to close that loophole too, maybe limiting sales of dumb displays to specific types of users.
pessimizer 5y ago
People will not willingly buy a locked-down device over an open device, all other things being equal. So general purpose devices will not be made available, so that locked-down devices will sell. edit: the only people who think that being locked-down is a feature are rationalizing technologists who indirectly profit from that arrangement. It's not even more secure. The methods used to control locked-down devices (namely constant network connections and cloud storage/control) are the most vulnerable attack surfaces we have, and the source of virtually all contemporary security disasters.
- freedomben 5y ago
  I sorely wish you were right, but the success of companies like Apple seem to indicate otherwise. I won't buy a locked-down device, but for every person like me there are thousands who don't care.
- lupire 5y ago
  This is a perfect example of survivor bias. OSes are secure now, so attacks that succeed attack the sxurit system.

by taneq 5y ago

Why can’t we have both? General-purpose computers for whatever-we-want, and single purpose devices from a trusted source which we can be more confident are untampered with?

dmos62 5y ago

I've not thought this through extensively, but couldn't you just flash signed firmwares onto those "single-purpose trusted devices"? If they were open to flashing that is. What more to want from a security perspective? In-device protection from flashing? Sounds similar to security through obscurity. I'd prefer easy ways to check what a device is flashed with. Something like a checksum calculator device. Not sure if that's a reasonable idea.

mjg59 5y ago
There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system. That means it has to be impossible to simply re-flash them given physical access, unless you can detect that this has happened. That's what the trusted boot side of this is - it gives you an indication that that reflashing has occurred. Out of band firmware validation is a real thing (Google's Titan sits in between the firmware and the CPU and records what goes over the bus, and can attest to that later), but that's basically just moving who owns the root of trust, and if you don't trust your CPU vendor to properly record what firmware it executes you should ask whether you trust your CPU vendor to execute the instructions you give it. Pretty much every option we currently have is just in a slightly different part of the trade off space.
- michaelt 5y ago
  > There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system. I looked into TPM stuff a few years ago, and it all seemed pretty useless to me. First of all, the entire key-protection house of cards relies on the assumption if you've booted the right OS, the keys can safely be unsealed. But the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues. Second of all, if you're worried about someone snatching your laptop or phone, full disk encryption where you type the password at boot gets you 99% of the protection with much less complexity. And the much lower complexity means many fewer places for security bugs to be accidentally introduced. Third, if you're worried about evil maid attacks where someone dismantles your laptop and messes with its internals without you knowing then gives it back to you, then the TPM isn't sufficient protection anyway. They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway. And fourth, the TPM doesn't have a dedicated hardware button (making it a shitty replacement for a U2F key) and doesn't have an independent clock (making it a shitty replacement for TOTP on your phone) so it's not even a good replacement for other security hardware. About the only use I can see for this stuff is if you're some huge multinational company, and you think even the authorised users of your computers can't be trusted.
  - 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

josefx 5y ago

Copyright owners will push for the later, maybe even take a page out off Googles Play store licensing and outright prohibit hardware manufacturers of even dreaming about producing a device that doesn't enforce their draconian requirements. So hardware manufacturers get the hard choice of either going for the general market that expects things to work or going for a tiny market that is happy with some of the most popular services not working by design.

indigochill 5y ago
> So hardware manufacturers get the hard choice of either going for the general market that expects things to work or going for a tiny market that is happy with some of the most popular services not working by design. Software is already here, particularly in social media (mastodon/SSB vs Facebook). That hardware eventually gets there seems to me an inevitability (arguably we're already at least partially there, as evidenced by the fact Purism/Pine64/etc exist). I still don't see it as a problem, though, because an individual can have different technical interfaces (devices, OSes, etc) for different purposes. Generally, I put my personal stuff on systems I understand/control. For some things, like watching TV, I'm okay with going to Netflix because that transaction is expected to be transitory. If Netflix disappears or declares themselves a new world order tomorrow, I can simply unsub and no harm done. Where things get problematic is when so much of someone's life is wrapped up in a mono-corporate cocoon (e.g. Amazon shipping things to your house and running your servers, or Google serving you search results + mail + maps).
- josefx 5y ago
  > I can simply unsub and no harm done. But your TV manufacturer still wants to provide Netflix to other users and Netflix decided to require all their devices to run its trusted code if they want to provide Netflix to anyone, whether you in particular want it or not. So your choice is to trash your existing TV and track down a manufacturer that doesn't have any support for Netflix, Hulu, Youtube, Amazon Prime, etc. at all to buy a new TV that doesn't ignore your choice. With TVs you might be lucky since there is a large market for dump displays that avoid any TV related functionality anyway, of course there might be restrictions in the license between Netflix and the TV manufacturer to close that loophole too, maybe limiting sales of dumb displays to specific types of users.

pessimizer 5y ago

People will not willingly buy a locked-down device over an open device, all other things being equal. So general purpose devices will not be made available, so that locked-down devices will sell. edit: the only people who think that being locked-down is a feature are rationalizing technologists who indirectly profit from that arrangement. It's not even more secure. The methods used to control locked-down devices (namely constant network connections and cloud storage/control) are the most vulnerable attack surfaces we have, and the source of virtually all contemporary security disasters.

freedomben 5y ago
I sorely wish you were right, but the success of companies like Apple seem to indicate otherwise. I won't buy a locked-down device, but for every person like me there are thousands who don't care.
lupire 5y ago
This is a perfect example of survivor bias. OSes are secure now, so attacks that succeed attack the sxurit system.