4 ms·

> This is a game changer for security. uh, no. it might be a game changer for open source, though. maybe.

judge2020 8y ago
Ya, secure enclaves have been available for a while now (and for decades in the form of HSM's), but AFAIK none have been open source.
- cyphar 8y ago
  It should be noted (and this is one of the biggest concerns with open hardware) is that you often cannot change said hardware -- after all it's a physical object. But this means that if the hardware has keys baked into it which you cannot change, it can be rendered non-free even though you have the chip design. So while secure enclaves will be very useful for many things, and I am hoping we can get some even more ambitious uses of secure enclaves, I would be very wary if industry starts reinventing Intel's BootGuard with RISC-V (which has Intel's firmware keys burned into hardware -- rendering free firmware impossible to use on such platforms). All that's necessary is a way to enroll new keys, and when new keys are enrolled all the secure storage is wiped. This allows for free use of your own hardware, while also keeping secrets safe from attackers.
  - excalibur 8y ago
    Umm, I'm pretty sure it has that? Why would you make an HSM with a set of predefined unchangeable keys, that's retarded.
    - gmueckl 8y ago
      No, this is actually not retarded if you need to store program code externally and want to make sure that this code is unaltered. The XBox 360 early boot did this as an anti-piracy measure IIRC: a minimal on-chip program would load and verify the first couple of blocks of externally stored firmware before executing them.
      - excalibur 8y ago
        Yes, if you the manufacturer want to make sure that nobody but you can alter the data. If you're providing cryptographic hardware for somebody else, they're gonna want to set their own.
        deleted 8y ago
        [deleted]
        gmueckl 8y ago
        If you do this, you weaken your device against hostile tempering as well, don't you? The key update mechanism becomes part of the attack surface.
        excalibur 8y ago
        Yes, but if implemented in a secure manner the key update mechanism presents a smaller risk than that of a hardcoded key becoming known to an adversarial party.
        lclarkmichalek 8y ago
        In my experience, that's not usually a requirement. From an implementation perspective, you just say 'this certificate is the root' and trust it explicitly without needing access to the key on the HSM. From a security perspective, adding the ability to set your own key is a risk (adds RW storage to a previously immutable system, changes the model from 'no one ever sees the key' to 'no one ever sees the key as long as it was written correctly and any non hsm stored copy is deleted'), and doesn't really improve the security of the system - you trust the HSM manufacturer already, seeing as it's their hardware.
        excalibur 8y ago
        Clearly we run in different circles. In my experience keys need to be generated regularly and rotated on a predetermined schedule. Immutable systems are kind of the antithesis of that.
    - cyphar 8y ago
      As I mentioned, Intel BootGuard has firmware keys burned into the CPU so that only firmware signed by Intel can be used as a bootloader. This is done to avoid boot-kits, but results in users not being able to flash their own firmware on their devices (so CoreBoot cannot be used on OEM machines with newer Intel CPUs). Note that enclaves can be used for things other than HSMs, and could be used in far deeper parts of the stack than just as a HSM interface.

judge2020 8y ago

Ya, secure enclaves have been available for a while now (and for decades in the form of HSM's), but AFAIK none have been open source.

cyphar 8y ago
It should be noted (and this is one of the biggest concerns with open hardware) is that you often cannot change said hardware -- after all it's a physical object. But this means that if the hardware has keys baked into it which you cannot change, it can be rendered non-free even though you have the chip design. So while secure enclaves will be very useful for many things, and I am hoping we can get some even more ambitious uses of secure enclaves, I would be very wary if industry starts reinventing Intel's BootGuard with RISC-V (which has Intel's firmware keys burned into hardware -- rendering free firmware impossible to use on such platforms). All that's necessary is a way to enroll new keys, and when new keys are enrolled all the secure storage is wiped. This allows for free use of your own hardware, while also keeping secrets safe from attackers.
- excalibur 8y ago
  Umm, I'm pretty sure it has that? Why would you make an HSM with a set of predefined unchangeable keys, that's retarded.
  - gmueckl 8y ago
    No, this is actually not retarded if you need to store program code externally and want to make sure that this code is unaltered. The XBox 360 early boot did this as an anti-piracy measure IIRC: a minimal on-chip program would load and verify the first couple of blocks of externally stored firmware before executing them.
    - excalibur 8y ago
      Yes, if you the manufacturer want to make sure that nobody but you can alter the data. If you're providing cryptographic hardware for somebody else, they're gonna want to set their own.
      - deleted 8y ago
        [deleted]
      - gmueckl 8y ago
        If you do this, you weaken your device against hostile tempering as well, don't you? The key update mechanism becomes part of the attack surface.
        excalibur 8y ago
        Yes, but if implemented in a secure manner the key update mechanism presents a smaller risk than that of a hardcoded key becoming known to an adversarial party.
      - lclarkmichalek 8y ago
        In my experience, that's not usually a requirement. From an implementation perspective, you just say 'this certificate is the root' and trust it explicitly without needing access to the key on the HSM. From a security perspective, adding the ability to set your own key is a risk (adds RW storage to a previously immutable system, changes the model from 'no one ever sees the key' to 'no one ever sees the key as long as it was written correctly and any non hsm stored copy is deleted'), and doesn't really improve the security of the system - you trust the HSM manufacturer already, seeing as it's their hardware.
        excalibur 8y ago
        Clearly we run in different circles. In my experience keys need to be generated regularly and rotated on a predetermined schedule. Immutable systems are kind of the antithesis of that.
  - cyphar 8y ago
    As I mentioned, Intel BootGuard has firmware keys burned into the CPU so that only firmware signed by Intel can be used as a bootloader. This is done to avoid boot-kits, but results in users not being able to flash their own firmware on their devices (so CoreBoot cannot be used on OEM machines with newer Intel CPUs). Note that enclaves can be used for things other than HSMs, and could be used in far deeper parts of the stack than just as a HSM interface.