No.
I recommend using the original title: "RISC-V Will Stop Hackers Dead From Getting Into Your Computer"
Even though it's still very fallacious.
UC Berkeley to build open-source secure enclave using RISC-V
11–20 of 54 posts
Re: UC Berkeley to build open-source secure enclave using RISC-V
#12Earlier quoted context omitted.
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.
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.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#13Technology 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.
They're used for more than that, but I agree it's unfortunate that DRM is a major use case.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#14My guess is that this is true as an accident but once they have real market traction they honeymoon will be over since it is very likely that the tools and software will have substantial bugs early on, not even including hardware errata; one of the Intel/AMD/POWER strongpoints is that they have huge verification libraries that RISC V vendors will not have. A slightly different memory model will also expose issues that happen to work on x86.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#15Hardware Security Modules (HSMs) are in plentiful supply, they're not new and the OP seems to have swallowed a bit of the Apple KoolAid from the description of the M7 being 'revolutionary'.
This is simply another HSM implementation, and no, they don't stop hackers, there are plenty other exploits to go for.
(For one example hhttps://www.nxp.com/products/identification-and-security/sec...)
Re: UC Berkeley to build open-source secure enclave using RISC-V
#16Being a different platform means that hackers will have to adapt to it. That was the argument of the Macintosh it didn't get Windows viruses because it wasn't Windows.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#17Earlier quoted context omitted.
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.
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]
Re: UC Berkeley to build open-source secure enclave using RISC-V
#18Cool. 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 this improves on the status quo. Apple delivered a secure enclave that was essentially a blackbox. Google delivered one and is open sourcing the firmware at some point (apparently.) Now, this is going to give us an enclave with open source hardware. 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. And if it did, we would never know for sure that it is free of security-sensitive bugs.
I still think this is great. Again, step above SGX and TrustZone in my opinion. But, this article makes it sound like a panacea, which I don't think is the case.
(Case in point: people have successfully attacked devices secured with enclaves, including iPhones and I assume Pixel. Doesn't matter how bad ass your gate is if it isn't surrounded by an equally strong fence. These devices should keep encryption secrets secure, but they don't 'stop hackers.')
Re: UC Berkeley to build open-source secure enclave using RISC-V
#19Earlier 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.
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.
Re: UC Berkeley to build open-source secure enclave using RISC-V
#20No it will not.