Isn't this highly similar to MIT's Sanctum from 2015, also open source and ignoring the hardware changes needed to make meaningful guarantees about sidechannel attack robustness? Useful if you want to avoid hardware mods, but the enclave model is not new.
https://eprint.iacr.org/2015/564.pdf and open source code via MIT license here: https://github.com/pwnall/sanctum
UC Berkeley to build open-source secure enclave using RISC-V
41–50 of 54 posts
Re: UC Berkeley to build open-source secure enclave using RISC-V
#42Isn't this highly similar to MIT's Sanctum from 2015, also open source and ignoring the hardware changes needed to make meaningful guarantees about sidechannel attack robustness? Useful if you want to avoid hardware mods, but the enclave model is not new. https://eprint.iacr.org/2015/564.pdf and open source code via MIT license here: https://github.com/pwnall/sanctum
Well its the next evolution by many of the same people.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#43Cool. HSMs are a notable step up from secure execution environments like TrustZone and SGX because they make side-channel attacks that take advantage of the shared hardware much more difficult. That said, the HSM itself becomes a target after a while. So the more stuff you off-load to your enclave, the larger the attack surface becomes, and now you moved your problem over. And I am further skeptical about how much th…
>But in a world where there are known, novel attacks against the integrity of microchips that would make it difficult to verify even in the presence of microscope images of a decapped chip, I'm not sure if this really gives us that much reassurance that the chip does what it says
I find myself saying this a lot lately but I really think that stuff like this is going to lead us to chip fabs being national strategic industries in the short/medium term future.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#44Earlier quoted context omitted.
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.
You might/should rotate the leaf keys regularly, but root keys are a massive pain to rotate (when you change a root key, you need to reprovision the corresponding cert onto every machine, as they're the root of trust for your PKI). You can buy a new HSM every 3 years to rotate those root keys, which fits fairly well into most organisation's decommissioning cycles.
Root keys are more of a pain to swap out, but AD does a pretty good job of handling the grunt work of distributing them across the organization. And the leaf keys should live on HSMs as well. You might be able to get by with a hardcoded root key if you're willing to accept the tradeoff, but that situation isn't going to work for the rest.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#45Plug alert: I am working with a company that's building a full representation of the Sanctum system using custom extensions of RISC-V (https://eprint.iacr.org/2015/564.pdf). There are critical features like root of trust key and entropy generation, and cache isolation that are missing from the vanilla RISC-V keystone approach. It offers a measure of security worth having but we're taking it all the way. We're working with MIT prof Srini Devadas. You can read more about it here if you're interested: https://medium.com/gradient-tech/announcing-gradient-crypto-...
Also we're hiring! https://www.gradient-tech.co/jobs
Re: UC Berkeley to build open-source secure enclave using RISC-V
#46Plug alert: I am working with a company that's building a full representation of the Sanctum system using custom extensions of RISC-V ( https://eprint.iacr.org/2015/564.pdf ). There are critical features like root of trust key and entropy generation, and cache isolation that are missing from the vanilla RISC-V keystone approach. It offers a measure of security worth having but we're taking it all the way. We're worki…
That's great - will it be open sourced in some way? SiFive demonstrated RISC-V secure boot using (closed) Rambus IP for the RoT.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#47Plug alert: I am working with a company that's building a full representation of the Sanctum system using custom extensions of RISC-V ( https://eprint.iacr.org/2015/564.pdf ). There are critical features like root of trust key and entropy generation, and cache isolation that are missing from the vanilla RISC-V keystone approach. It offers a measure of security worth having but we're taking it all the way. We're worki…
That's great - will it be open sourced in some way? SiFive demonstrated RISC-V secure boot using (closed) Rambus IP for the RoT.
Some version at least will be yes. RE: RoT + RISV-V, cache isolation appears missing here, so sidechannel attacks using cache timing and other methods still work
Re: UC Berkeley to build open-source secure enclave using RISC-V
#48Earlier quoted context omitted.
'LeifCarrotson didn't say "DRM", though it's kind of implied as a part. Third parties preventing device owner from operating the device is a cornerstone of information security, justified by observing that regular folks are very prone to selfpwning themselves if a little of social engineering is applied (+ it's hard in general to distinguish user-initiated actions from sofware-initiated ones). It's important to remem…
Also known as "authoritarianism", and the security community seems to be full of it. After all, isn't it more secure if the user can't do anything at all and the device controls the user? Let's not forget that DRM also goes beyond preventing consumption of media (although that is a big application) --- it can be, and is, also used to force users to accept unwanted behaviour of software. Win10's deeply embedded teleme…
> Also known as "authoritarianism", and the security community seems to be full of it.
This, exactly. Maybe that's déformation professionnelle of a kind.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#49Earlier quoted context omitted.
That's great - will it be open sourced in some way? SiFive demonstrated RISC-V secure boot using (closed) Rambus IP for the RoT.
Some version at least will be yes. RE: RoT + RISV-V, cache isolation appears missing here, so sidechannel attacks using cache timing and other methods still work
Awesome! It was unclear to me where the Rambus IP began and SiFive's core took over in the demo.
Keystone using existing RISC-V extensions is exciting to see, but it's frustrating that the Hack a Day article seems to confound where it begins and ends (at least today). The Keystone presentation notes that the RoT is derived from Sanctum and their docs indicate that you need to bring your own entropy and key storage, neither of which are made clear in the blog post.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#50I don't understand how this differentiates itself from ARM TrustZone.
You can already create a system with a dedicated HSM and run your own trusted operating system using the features of the processor. With Intel SGX you are somewhat stuck with using the HSM provided by Intel. With the BSD-licensing aren't we left in the same place as ARM processors, with the exception of producing a RISC-V processor being less expensive with regard to licensing?