Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UC Berkeley to build open-source secure enclave using RISC-V

hackaday.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: UC Berkeley to build open-source secure enclave using RISC-V

#21

Post by TeMPOraL »

yoklov wrote: post #13
LeifCarrotson wrote: post #7

Technology 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.

'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 remember that legit security needs and user freedoms start to be in conflict pretty much as soon as the device in question gets connected to the Internet.

Re: UC Berkeley to build open-source secure enclave using RISC-V

#22

Post by srcmap »

TickleSteve wrote: post #15

Hardware 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 h https://www.nxp.com/products/identification-and-security/sec... )

I was brainwashed by the "Security Now" podcast --- I will trust the HSM that is open to any security researchers to do extensively study/review more than typical "security by obscurity" implementations.

Re: UC Berkeley to build open-source secure enclave using RISC-V

#23

Post by gmueckl »

excalibur wrote: post #12
gmueckl wrote: post #10

Earlier 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.

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.

Re: UC Berkeley to build open-source secure enclave using RISC-V

#24

Post by excalibur »

gmueckl wrote: post #23
excalibur wrote: post #12

Earlier quoted context omitted.

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.

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.

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.

Re: UC Berkeley to build open-source secure enclave using RISC-V

#25

Post by anonymousDan »

jchw wrote: post #18

Cool. 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…

HSMs have been around for donkey's years. SGX is interesting because now you can run e.g. a whole database inside an enclave on commodity CPUs with competitive performance.

Re: UC Berkeley to build open-source secure enclave using RISC-V

#28

Post by wyldfire »

anonymousDan wrote: post #27
wyldfire wrote: post #5

Tagged 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.

Can you point me to some resources on this?

ARM: https://community.arm.com/processors/b/blog/posts/arm-a-prof...

RISC-V: https://www.lowrisc.org/docs/tagged-memory-v0.1/tags/

You can think of this feature like a hardware ASan. Instead of using ASan as a design tool, you could use it as a security feature.

Capitalizing on this feature requires compiler and C lib changes. I'd bet that the support should be available in popular open source compilers before ARM ships.

Re: UC Berkeley to build open-source secure enclave using RISC-V

#29

Post by mtgx »

anonymousDan wrote: post #25
jchw wrote: post #18

Cool. 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…

HSMs have been around for donkey's years. SGX is interesting because now you can run e.g. a whole database inside an enclave on commodity CPUs with competitive performance.

Arm has already announced crypto-processors, which I assume aren't very expensive. Every chip maker could use one as an HSM now.

https://developer.arm.com/products/system-ip/security-ip/cry...

https://developer.arm.com/products/system-ip/security-ip/cry...

Re: UC Berkeley to build open-source secure enclave using RISC-V

#30

Post by lclarkmichalek »

excalibur wrote: post #12
gmueckl wrote: post #10

Earlier 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.

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.
Post reply on HN