5 ms·

How long before we have RISC V processors powering Linux PCs with no “Secure Enclave” that has root on your system? Also playing games on it would be nice.

KRAKRISMOTT 3y ago
You probably want a secure enclave as otherwise you won't have a good way to secure keystores. With Webauthn and keypasses becoming more widely adopted, not having a secure computation environment means you will be at risk of having your login data exfiltrated by random apps.
- deleted 3y ago
  [deleted]
- no_time 3y ago
  I’m more concerned about tech companies being more of a “superuser” on the machine I have paid for and own, than me. Stallman saw this coming decades ago. And I firmly believe he will be proven right in due time. https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html
  - goodpoint 3y ago
    Many people saw it coming even before Stallaman.
  - sys_64738 3y ago
    > I’m more concerned about tech companies being more of a “superuser” on the machine I have paid for and own, than me. Don't run Intel and AMD CPUs then!
    - thinkerswell 3y ago
      It would be nice to have a riscV option that doesn’t include these.
- phendrenad2 3y ago
  We have a secure computing environment, it's called process isolation and it's provided by the kernel.
  - samus 3y ago
    The isolation provided by the kennel is strictly more vulnerable than a TPM chip that can only interacted with via a communication protocol. Using the TPM, the hardware bootloader can verify that it boots only authorized, untainted kernel images. Without it, a chain of exploits can be used to taint the kernel boot image, thus effectively take over the machine. Even if an exploit chain succeeds in gaining root access, it's gone the next time the machine reboots. The crucial problem is that the IT industry is more concerned about using it to enforce DRM instead of educating users so they can use it to retain ownership of their services.
    - megous 3y ago
      So what's preventing chain of exploits from just using the TPM over communication protocol to do whatever it needs that requires said TPM to sign/attest to something?
      - samus 3y ago
        For the same reason a website can't ask the browser to simply install another root certificate into its truststore: a browser simply doesn't offer an interface to do that. The TPM itself does very little. It is simply used by the UEFI to verify that the digital signature of the OS image is valid, similarly to how a browser validates a server certificate using its own truststore. A possible attack vector to compromise that functionality would be to tamper with UEFI. Since it is firmware, the operating system simply doesn't have the capability to so. Even when doing firmware updates, the OS must ask the UEFI nicely to apply a new firmware image, which is similarly verified using a digital signature. All the above assume that there are no backdoors that allow an upper layer to compromise a lower layer.
        3y ago
- missjellyfish 3y ago
  That would probably be fine by me if and only if: a) the source code of the secure enclave is 100% open source b) I can compile my own version of it c) I can run my own version of it d) I face no reprecussions (i.e. services not working, DRM not working, ...) if I choose to do so. This is all fine and dandy for key storage purposes; you actually want all of these to guarantee that your keys are safe. But modern enclaves are primarily used for DRM, and this just doesn't work if I can just patch a way into my enclave to get the key if I really want to. So, I'd much rather have a system with no enclave which I can attach a HSM to than a secure "trust me bro" enclave. DRM was the original sin of computing, and nobody can convince me otherwise.
- rhn_mk1 3y ago
  Does the secure enclave need to be built into the main CPU though? A key store on a USB stick or on a TPM will never allow your keys to be exfiltrated, yet it's not part of the CPU, and it's even removable.
  - samus 3y ago
    Such devices are called FIDO keys. But they work only if the service you're accessing also supports it. I don't even know whether there is consumer hardware that supports an external TPM for boot image verification and hard drive decryption. A plain USB stick is not a secure place for a keystore as a compromised kernel could trivially copy it and send it somewhere else for cracking.
    - loup-vaillant 3y ago
      > Such devices are called FIDO keys. But they work only if the service you're accessing also supports it. That’s not quite true. The (web) service I’m accessing doesn’t communicate with my FIDO keys — there’s my browser in the middle. The service has no way to know whether my browser is talking with a hardware token or emulating one, and it is not privy to the details of how my browser communicates with my token. If my browser supports FIDO on the network end, and my hardware token on the other end, it works. Now I’m guessing right now only relatively mainstream stuff like Yubikeys are supported out of the box, but support for say, the TKey (https://tillitis.se/products/tkey/ https://tillitis.se/products/tkey/), is likely only a browser extension away.
      - deleted 3y ago
        [deleted]
      - jrockway 3y ago
        > The service has no way to know whether my browser is talking with a hardware token or emulating one It does. It can request that the key do attestation, which involves providing a certificate that proves who the manufacturer is.
- fsflover 3y ago
  The parent probably means Intel ME, not TPM. The latter can be based on FLOSS.
  - samus 3y ago
    The ME is simply a backdoor so that enterprise users can centrally manage their fleet. There's nothing really secure about it. It is probably still based on Minix and presumably full of security-relevant bugs.

KRAKRISMOTT 3y ago

You probably want a secure enclave as otherwise you won't have a good way to secure keystores. With Webauthn and keypasses becoming more widely adopted, not having a secure computation environment means you will be at risk of having your login data exfiltrated by random apps.

deleted 3y ago
[deleted]
no_time 3y ago
I’m more concerned about tech companies being more of a “superuser” on the machine I have paid for and own, than me. Stallman saw this coming decades ago. And I firmly believe he will be proven right in due time. https://www.gnu.org/philosophy/can-you-trust.en.html https://www.gnu.org/philosophy/can-you-trust.en.html
- goodpoint 3y ago
  Many people saw it coming even before Stallaman.
- sys_64738 3y ago
  > I’m more concerned about tech companies being more of a “superuser” on the machine I have paid for and own, than me. Don't run Intel and AMD CPUs then!
  - thinkerswell 3y ago
    It would be nice to have a riscV option that doesn’t include these.
phendrenad2 3y ago
We have a secure computing environment, it's called process isolation and it's provided by the kernel.
- samus 3y ago
  The isolation provided by the kennel is strictly more vulnerable than a TPM chip that can only interacted with via a communication protocol. Using the TPM, the hardware bootloader can verify that it boots only authorized, untainted kernel images. Without it, a chain of exploits can be used to taint the kernel boot image, thus effectively take over the machine. Even if an exploit chain succeeds in gaining root access, it's gone the next time the machine reboots. The crucial problem is that the IT industry is more concerned about using it to enforce DRM instead of educating users so they can use it to retain ownership of their services.
  - megous 3y ago
    So what's preventing chain of exploits from just using the TPM over communication protocol to do whatever it needs that requires said TPM to sign/attest to something?
    - samus 3y ago
      For the same reason a website can't ask the browser to simply install another root certificate into its truststore: a browser simply doesn't offer an interface to do that. The TPM itself does very little. It is simply used by the UEFI to verify that the digital signature of the OS image is valid, similarly to how a browser validates a server certificate using its own truststore. A possible attack vector to compromise that functionality would be to tamper with UEFI. Since it is firmware, the operating system simply doesn't have the capability to so. Even when doing firmware updates, the OS must ask the UEFI nicely to apply a new firmware image, which is similarly verified using a digital signature. All the above assume that there are no backdoors that allow an upper layer to compromise a lower layer.
      - 3y ago
missjellyfish 3y ago
That would probably be fine by me if and only if: a) the source code of the secure enclave is 100% open source b) I can compile my own version of it c) I can run my own version of it d) I face no reprecussions (i.e. services not working, DRM not working, ...) if I choose to do so. This is all fine and dandy for key storage purposes; you actually want all of these to guarantee that your keys are safe. But modern enclaves are primarily used for DRM, and this just doesn't work if I can just patch a way into my enclave to get the key if I really want to. So, I'd much rather have a system with no enclave which I can attach a HSM to than a secure "trust me bro" enclave. DRM was the original sin of computing, and nobody can convince me otherwise.
rhn_mk1 3y ago
Does the secure enclave need to be built into the main CPU though? A key store on a USB stick or on a TPM will never allow your keys to be exfiltrated, yet it's not part of the CPU, and it's even removable.
- samus 3y ago
  Such devices are called FIDO keys. But they work only if the service you're accessing also supports it. I don't even know whether there is consumer hardware that supports an external TPM for boot image verification and hard drive decryption. A plain USB stick is not a secure place for a keystore as a compromised kernel could trivially copy it and send it somewhere else for cracking.
  - loup-vaillant 3y ago
    > Such devices are called FIDO keys. But they work only if the service you're accessing also supports it. That’s not quite true. The (web) service I’m accessing doesn’t communicate with my FIDO keys — there’s my browser in the middle. The service has no way to know whether my browser is talking with a hardware token or emulating one, and it is not privy to the details of how my browser communicates with my token. If my browser supports FIDO on the network end, and my hardware token on the other end, it works. Now I’m guessing right now only relatively mainstream stuff like Yubikeys are supported out of the box, but support for say, the TKey (https://tillitis.se/products/tkey/ https://tillitis.se/products/tkey/), is likely only a browser extension away.
    - deleted 3y ago
      [deleted]
    - jrockway 3y ago
      > The service has no way to know whether my browser is talking with a hardware token or emulating one It does. It can request that the key do attestation, which involves providing a certificate that proves who the manufacturer is.
fsflover 3y ago
The parent probably means Intel ME, not TPM. The latter can be based on FLOSS.
- samus 3y ago
  The ME is simply a backdoor so that enterprise users can centrally manage their fleet. There's nothing really secure about it. It is probably still based on Minix and presumably full of security-relevant bugs.