UC Berkeley to build open-source secure enclave using RISC-V
1–10 of 54 posts
Re: UC Berkeley to build open-source secure enclave using RISC-V
#2> This is a game changer for security.
uh, no. it might be a game changer for open source, though. maybe.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#3> This is a game changer for security. uh, no. it might be a game changer for open source, though. maybe.
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.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#4> This is a game changer for security. uh, no. it might be a game changer for open source, though. maybe.
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.
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.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#5Tagged memory is the biggest game changer for security IMO. RISC-V has a proposal IIRC, but ARM has a product (ARMv8.5) that looks like it will really raise the bar.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#6[deleted]
Re: UC Berkeley to build open-source secure enclave using RISC-V
#7Technology cannot stop hackers but let authorized users if humans are still vulnerable to "You have a request from SexyMama69, enter your password to recieve video call" and other forms of social engineering.
Secure enclaves are only really useful at allowing people who don't own the device from preventing those who do own it from taking certain actions.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#8also addressing this Open-Source RISC-V Hardware And Security https://semiengineering.com/security-and-open-source-hardwar...
Re: UC Berkeley to build open-source secure enclave using RISC-V
#9Earlier quoted context omitted.
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.
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 amb…
Umm, I'm pretty sure it has that? Why would you make an HSM with a set of predefined unchangeable keys, that's retarded.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#10Earlier quoted context omitted.
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 amb…
Umm, I'm pretty sure it has that? Why would you make an HSM with a set of predefined unchangeable keys, that's retarded.
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.