21 ms·

While I find this post and the ideas presented very interesting on the technical level, work in that direction ("remote attestation", making devices "tamper-pro

by c0l0 5y ago

While I find this post and the ideas presented very interesting on the technical level, work in that direction ("remote attestation", making devices "tamper-proof") tends to give me a dystopian vibe - foreshadowing a world where there's no hardware left you can hack, build and flash your own firmware onto: Complete tivoization, to re-use lingo from when the GPLv3 was drafted. With that, really neutering all the benefits Free Software provides. What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect?

mjg59 5y ago
You're not wrong, but unfortunately those of us on the side of free software aren't the ones driving most technology decisions. This technology already exists, and if people want to use it to lock us out of our own hardware, they can already use it to do so. Right now we're partially saved by remote attestation on x86 systems just being too complicated (and, basically, too privacy violating) to deployed in a way that could be used against users, but this is basically what things like Safetynet on Android are doing right now. When the proprietary software industry is already using technology, I don't think we benefit by refusing to touch it ourselves. We can use this tech to lock down devices that are better off locked down, and where we're not violating user freedom in the process. We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect. Refusing to do the good things isn't going to slow down the spread of the bad things.
- lmm 5y ago
  Development work is expensive. A cheap turnkey way of building a locked-down, remote-attesting distribution is going to make the bad things cheaper and more common. I'm sure proprietary developers would get there eventually, but this is one class of software where I think publishing a stable, bug-free implementation that anyone can use does more harm than good.
  - zxzax 5y ago
    How? You can use this to secure your own devices from tampering. Lots of (cheap) devices are already locked down like this, would it really help to deprive yourself of the capability to secure your own devices too?
    - lupire 5y ago
      Many people want contradictory things and loudly ignore the contradictions.
  - viraptor 5y ago
    It's been already done many times. You can lock down your own machine from scratch in a couple of days with no prior knowledge. There's really nothing to hide and all elements of it are useful in their own right.
- caspper69 5y ago
  Yes, and you only need this at the root hypervisor level, once peripherals can be abstracted in a new way (maybe DMA at a different privilege level, certain hardware features would be required). I am not super mad if I have to run my custom kernel in a VM. It substantially reduces the surface area exposed.
- floatboth 5y ago
  Heh, Safetynet is consistently fooled by Magisk's hide-root option, so is it really doing that?
  - no_time 5y ago
    Yeah, on devices without hardware attestation. Which is now the new normal on all phones sold. When the software route inevitably gets disabled and you can no longer fool google into believing you dont have hardware attestation you are done for good.
- userbinator 5y ago
  I am completely against any form of this technology, just like DRM, because it breaks the concept of physical ownership. We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect. This argument is often-made and I hate it because it advocates destroying the freedom of many just for the needs of a tiny minority --- and if a nation-state is going after you, it's pretty much game over unless you can create your own hardware. Refusing to do the good things isn't going to slow down the spread of the bad things. Maybe to you it's a good thing, but to many of us, that is the equivalent of giving Big Tech the noose and saying "don't put it around my neck!" (The saddest part is how many will happily work in these noose-factories, either oblivious to or convinced that what they're doing is "good".)
  - zxzax 5y ago
    >it breaks the concept of physical ownership. Am I missing something? This seems to be incorrect, this is explicitly a case where you, the hardware owner, controls the signing keys. It's nothing like DRM, that is a case where an outside person controls the keys.
    - josephcsible 5y ago
      The problem is now that this exists and is easy to set up, it's easy for the manufacturer to make a device where they're in control of the keys forever instead of the eventual owner gaining control.
      - zxzax 5y ago
        So don't buy that device? Those devices already exist, that doesn't prevent you from buying other devices where you control the keys. If manufacturing an unlocked device becomes unprofitable and stops happening everywhere, then we can talk about what to do, but I don't think the existence of secure boot on Linux is going to make much of a difference either way.
        salawat 5y ago
- Teknoman117 5y ago
  I personally don't dislike the concepts of trusted computing. As much as I love to tinker with things, the last thing I want is some data appliance being remotely exploitable. I think all the devices that provide more security by being heavily locked down should basically have a tinker switch. If you really want to write your own firmware for your phone or your dishwasher, flip it to tinker mode which locks you (maybe permanently) out of the software it shipped it and let you flash whatever on to it. The manufacturer gets to waive all responsibility for your safety (digital, physical, etc.) from that point onward. Bonus points if it just blows away the keys to the onboard software so you can use the security mechanisms for your own code.
  - dTal 5y ago
    That's still very consumer-hostile. How am I supposed to write a replacement firmware for my dishwasher if I have to brick it first? I have dishes to wash! I'm not gonna buy a second dishwasher for development purposes. Why can't I test it against the native firmware? (And by the way - remotely exploitable dishwashers? What the heck is the world coming to?)
    - Teknoman117 5y ago
      I was just thinking of the extremely litigation happy culture in the US. We literally have thousands of highway signs in cities saying that if you were in an accident, call us and we'll sue the person who rear ended you. All I imagine is someone running their own firmware on an appliance, doing some unseen damage, and then reverting to the onboard firmware and getting hurt. It would be a field day for lawyers. I completely agree that this sucks and it's the same reason robotics has proceeded at a snail's pace. God forbid making a Roomba with a more powerful vacuum, what if it ran over someone's toe.
deleted 5y ago
[deleted]
stevenhuang 5y ago
While the use case of secure boot is often anti consumer/end-user, there are many applications that make sense to have attestation (yubikey type embedded projects, etc) Without free software implementations of secure boot et al. all this would just happen behind closed doors. At least with this the field progresses and you'll have the tools to secure your own applications when the right project comes. > What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect? Well, it'll be more difficult to get pwned, for one.
t0mas88 5y ago
I think the technology itself is great to have in the open source sphere. There are many valid reasons to want to have a system that is both open source AND cryptographically proven to run exactly the software you think it runs. For example voting machines should be done in this way. Open source software such that outsiders are able to verify + a secure boot process such that anyone can verify that the machine is really running the code it is supposed to run. Of course we should all still be very careful of what we accept in terms of control of our hardware. And I agree with you that things are not moving in the right direction there, with locked ecosystems everywhere.
- stefan_ 5y ago
  But nothing here is cryptographically proven. Remote attestation ala Intel SGX is an opaque black box that comes down to trusting Intel. I think most people would prefer no voting machine software at all, seeing how most people can not "verify that the machine is really running the code it is supposed to run" but can indeed verify a paper ballot. And of course signing a huge code bundle is the farthest possible thing from "run exactly the software you think it runs". Console manufacturers keep learning that. You really wanted to run that WebKit version that turned out to instead be a generic code execution widget? Think again.
  - mjg59 5y ago
    TPM-based remote attestation doesn't involve SGX at all. If Boot Guard is enabled then you're trusting the ACM to perform its measurements correctly, but that's a not overly large amount of code that can be disassembled and verified.
  - t0mas88 5y ago
    Sure, you can prefer paper ballots, but that's just one example. The reason I bring it up is that one of the benefits of open source that is often mentioned is the ability to verify that it does what you think it's doing. Doesn't matter whether it's a voting machine, a self driving system or an ATM or whatever. It's still good for open source to have the capability to do this kind of proving in cases where you want it.
ReptileMan 5y ago
The question with secure boot is who has the keys. As long as that's the end user it is awesome.
- Ieghaehia9 5y ago
  Which is why every trusted computing platform with free software on it should have an owner override. (The total count of such platforms is, as far as I know, unfortunately zero.)
  - mjg59 5y ago
    Pretty much every x86 system with a TPM and UEFI Secure Boot can have the secure boot keys swapped out by the owner.
    - ok123456 5y ago
      I recently went to write a kernel module on my Ubuntu system, only to discover the boot loader now defaulted to "secure boot" nonsense and I couldn't insmod a non-signed module. I tried to simply disable "secure boot" in the BIOS settings and then the boot loader just did absolutely nothing. Hot fucking garbage. Apparently, if you have "secure boot" available during the install it will use "secure boot" without any way to opt-out.
      - tzs 5y ago
        Did you try disabling it in shim-signed instead of the BIOS (method 2 on this page [1])? I'd expect that to be more consistent and/or reliable since BIOS quality can vary a lot from vendor to vendor. You might also try signing the kernel module yourself (the manual method at the bottom of that page)? [1] https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS
        ok123456 5y ago
        I don't want to do any of that. I just want to insmod a module like I've been doing since 1995.
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.
nextlevelwizard 5y ago
Being able to verify that your program runs on authenticated firmware does not mean you can't modify the firmware or the software running or replace it with something else. It just means that you can be sure no one else has tampered with your device. To me it seems very silly to not follow this line of thought just because someone in the future might use it lock out hackers. This is like leaving bugs unfixed because someone might have a use for it.
- nebulous1 5y ago
  The user being able to verify things isn't the issue, the issue is somebody else being able to verify things, perhaps even requiring verification. This can even be extended (and already has been) to where binaries can be supplied in encrypted form and run on a processor that never reveals the unencrypted code to its user.
  - nextlevelwizard 5y ago
    Who cares? Then you just wont hack that device
an_opabinia 5y ago
> Complete tivoization Ironically TiVo is long gone from living rooms. The iPhone is locked down, consumers buy 5.5 Android phones for every 1 iPhone. But rich users buy iPhones, and they also buy software, so...
NovemberWhiskey 5y ago
I know this is going to be an unpopular opinion, but if a service provider wants to support only specific clients which have a rigorously-managed supply chain of their hardware/software, then that's up to them.
- c01n 5y ago
  I buy a computer I own that computer there should be no strings attached.
  - NovemberWhiskey 5y ago
    Yes; sure. But you don't own (for example) Netflix. So Netflix can exclude you if you use your computer in certain ways, right? i.e. if you refuse to use a secure boot infrastructure and do remote attestation of the trust chain to Netflix, they can refuse to provide you service - obviously based on the assumption that this was all made clear to when you signed up.
    - salawat 5y ago
      The 'ole "they're a private business, they can do what they want" defense. I try not to whip that out because it's all fun and cool til they do somethimg you don"t like.

by c0l0 5y ago

mjg59 5y ago

You're not wrong, but unfortunately those of us on the side of free software aren't the ones driving most technology decisions. This technology already exists, and if people want to use it to lock us out of our own hardware, they can already use it to do so. Right now we're partially saved by remote attestation on x86 systems just being too complicated (and, basically, too privacy violating) to deployed in a way that could be used against users, but this is basically what things like Safetynet on Android are doing right now. When the proprietary software industry is already using technology, I don't think we benefit by refusing to touch it ourselves. We can use this tech to lock down devices that are better off locked down, and where we're not violating user freedom in the process. We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect. Refusing to do the good things isn't going to slow down the spread of the bad things.

lmm 5y ago
Development work is expensive. A cheap turnkey way of building a locked-down, remote-attesting distribution is going to make the bad things cheaper and more common. I'm sure proprietary developers would get there eventually, but this is one class of software where I think publishing a stable, bug-free implementation that anyone can use does more harm than good.
- zxzax 5y ago
  How? You can use this to secure your own devices from tampering. Lots of (cheap) devices are already locked down like this, would it really help to deprive yourself of the capability to secure your own devices too?
  - lupire 5y ago
    Many people want contradictory things and loudly ignore the contradictions.
- viraptor 5y ago
  It's been already done many times. You can lock down your own machine from scratch in a couple of days with no prior knowledge. There's really nothing to hide and all elements of it are useful in their own right.
caspper69 5y ago
Yes, and you only need this at the root hypervisor level, once peripherals can be abstracted in a new way (maybe DMA at a different privilege level, certain hardware features would be required). I am not super mad if I have to run my custom kernel in a VM. It substantially reduces the surface area exposed.
floatboth 5y ago
Heh, Safetynet is consistently fooled by Magisk's hide-root option, so is it really doing that?
- no_time 5y ago
  Yeah, on devices without hardware attestation. Which is now the new normal on all phones sold. When the software route inevitably gets disabled and you can no longer fool google into believing you dont have hardware attestation you are done for good.
userbinator 5y ago
I am completely against any form of this technology, just like DRM, because it breaks the concept of physical ownership. We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect. This argument is often-made and I hate it because it advocates destroying the freedom of many just for the needs of a tiny minority --- and if a nation-state is going after you, it's pretty much game over unless you can create your own hardware. Refusing to do the good things isn't going to slow down the spread of the bad things. Maybe to you it's a good thing, but to many of us, that is the equivalent of giving Big Tech the noose and saying "don't put it around my neck!" (The saddest part is how many will happily work in these noose-factories, either oblivious to or convinced that what they're doing is "good".)
- zxzax 5y ago
  >it breaks the concept of physical ownership. Am I missing something? This seems to be incorrect, this is explicitly a case where you, the hardware owner, controls the signing keys. It's nothing like DRM, that is a case where an outside person controls the keys.
  - josephcsible 5y ago
    The problem is now that this exists and is easy to set up, it's easy for the manufacturer to make a device where they're in control of the keys forever instead of the eventual owner gaining control.
    - zxzax 5y ago
      So don't buy that device? Those devices already exist, that doesn't prevent you from buying other devices where you control the keys. If manufacturing an unlocked device becomes unprofitable and stops happening everywhere, then we can talk about what to do, but I don't think the existence of secure boot on Linux is going to make much of a difference either way.
      - salawat 5y ago
Teknoman117 5y ago
I personally don't dislike the concepts of trusted computing. As much as I love to tinker with things, the last thing I want is some data appliance being remotely exploitable. I think all the devices that provide more security by being heavily locked down should basically have a tinker switch. If you really want to write your own firmware for your phone or your dishwasher, flip it to tinker mode which locks you (maybe permanently) out of the software it shipped it and let you flash whatever on to it. The manufacturer gets to waive all responsibility for your safety (digital, physical, etc.) from that point onward. Bonus points if it just blows away the keys to the onboard software so you can use the security mechanisms for your own code.
- dTal 5y ago
  That's still very consumer-hostile. How am I supposed to write a replacement firmware for my dishwasher if I have to brick it first? I have dishes to wash! I'm not gonna buy a second dishwasher for development purposes. Why can't I test it against the native firmware? (And by the way - remotely exploitable dishwashers? What the heck is the world coming to?)
  - Teknoman117 5y ago
    I was just thinking of the extremely litigation happy culture in the US. We literally have thousands of highway signs in cities saying that if you were in an accident, call us and we'll sue the person who rear ended you. All I imagine is someone running their own firmware on an appliance, doing some unseen damage, and then reverting to the onboard firmware and getting hurt. It would be a field day for lawyers. I completely agree that this sucks and it's the same reason robotics has proceeded at a snail's pace. God forbid making a Roomba with a more powerful vacuum, what if it ran over someone's toe.

deleted 5y ago

[deleted]

stevenhuang 5y ago

While the use case of secure boot is often anti consumer/end-user, there are many applications that make sense to have attestation (yubikey type embedded projects, etc) Without free software implementations of secure boot et al. all this would just happen behind closed doors. At least with this the field progresses and you'll have the tools to secure your own applications when the right project comes. > What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect? Well, it'll be more difficult to get pwned, for one.

t0mas88 5y ago

I think the technology itself is great to have in the open source sphere. There are many valid reasons to want to have a system that is both open source AND cryptographically proven to run exactly the software you think it runs. For example voting machines should be done in this way. Open source software such that outsiders are able to verify + a secure boot process such that anyone can verify that the machine is really running the code it is supposed to run. Of course we should all still be very careful of what we accept in terms of control of our hardware. And I agree with you that things are not moving in the right direction there, with locked ecosystems everywhere.

stefan_ 5y ago
But nothing here is cryptographically proven. Remote attestation ala Intel SGX is an opaque black box that comes down to trusting Intel. I think most people would prefer no voting machine software at all, seeing how most people can not "verify that the machine is really running the code it is supposed to run" but can indeed verify a paper ballot. And of course signing a huge code bundle is the farthest possible thing from "run exactly the software you think it runs". Console manufacturers keep learning that. You really wanted to run that WebKit version that turned out to instead be a generic code execution widget? Think again.
- mjg59 5y ago
  TPM-based remote attestation doesn't involve SGX at all. If Boot Guard is enabled then you're trusting the ACM to perform its measurements correctly, but that's a not overly large amount of code that can be disassembled and verified.
- t0mas88 5y ago
  Sure, you can prefer paper ballots, but that's just one example. The reason I bring it up is that one of the benefits of open source that is often mentioned is the ability to verify that it does what you think it's doing. Doesn't matter whether it's a voting machine, a self driving system or an ATM or whatever. It's still good for open source to have the capability to do this kind of proving in cases where you want it.

ReptileMan 5y ago

The question with secure boot is who has the keys. As long as that's the end user it is awesome.

Ieghaehia9 5y ago
Which is why every trusted computing platform with free software on it should have an owner override. (The total count of such platforms is, as far as I know, unfortunately zero.)
- mjg59 5y ago
  Pretty much every x86 system with a TPM and UEFI Secure Boot can have the secure boot keys swapped out by the owner.
  - ok123456 5y ago
    I recently went to write a kernel module on my Ubuntu system, only to discover the boot loader now defaulted to "secure boot" nonsense and I couldn't insmod a non-signed module. I tried to simply disable "secure boot" in the BIOS settings and then the boot loader just did absolutely nothing. Hot fucking garbage. Apparently, if you have "secure boot" available during the install it will use "secure boot" without any way to opt-out.
    - tzs 5y ago
      Did you try disabling it in shim-signed instead of the BIOS (method 2 on this page [1])? I'd expect that to be more consistent and/or reliable since BIOS quality can vary a lot from vendor to vendor. You might also try signing the kernel module yourself (the manual method at the bottom of that page)? [1] https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS
      - ok123456 5y ago
        I don't want to do any of that. I just want to insmod a module like I've been doing since 1995.

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.

nextlevelwizard 5y ago

Being able to verify that your program runs on authenticated firmware does not mean you can't modify the firmware or the software running or replace it with something else. It just means that you can be sure no one else has tampered with your device. To me it seems very silly to not follow this line of thought just because someone in the future might use it lock out hackers. This is like leaving bugs unfixed because someone might have a use for it.

nebulous1 5y ago
The user being able to verify things isn't the issue, the issue is somebody else being able to verify things, perhaps even requiring verification. This can even be extended (and already has been) to where binaries can be supplied in encrypted form and run on a processor that never reveals the unencrypted code to its user.
- nextlevelwizard 5y ago
  Who cares? Then you just wont hack that device

an_opabinia 5y ago

> Complete tivoization Ironically TiVo is long gone from living rooms. The iPhone is locked down, consumers buy 5.5 Android phones for every 1 iPhone. But rich users buy iPhones, and they also buy software, so...

NovemberWhiskey 5y ago

I know this is going to be an unpopular opinion, but if a service provider wants to support only specific clients which have a rigorously-managed supply chain of their hardware/software, then that's up to them.

c01n 5y ago
I buy a computer I own that computer there should be no strings attached.
- NovemberWhiskey 5y ago
  Yes; sure. But you don't own (for example) Netflix. So Netflix can exclude you if you use your computer in certain ways, right? i.e. if you refuse to use a secure boot infrastructure and do remote attestation of the trust chain to Netflix, they can refuse to provide you service - obviously based on the assumption that this was all made clear to when you signed up.
  - salawat 5y ago
    The 'ole "they're a private business, they can do what they want" defense. I try not to whip that out because it's all fun and cool til they do somethimg you don"t like.