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

31–40 of 54 posts

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

#31

Post by userbinator »

TeMPOraL wrote: post #21
yoklov wrote: post #13

Earlier quoted context omitted.

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 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 telemetry is one example: It would be relatively easy to patch out if it weren't for the files being signed and "protected" by "secure" boot, and the constant barrage of updates (not all of which are for fixing remote unattended attacks, IMHO the ones which are actually important.) The situation is much worse on mobile devices.

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

#32

Post by anonymousDan »

wyldfire wrote: post #28
anonymousDan wrote: post #27

Earlier quoted context omitted.

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 sh…

Thanks, they look pretty interesting. Do you know what granularity the ARM tagging supports (e.g. byte level)? Would be interesting to see performance numbers - although I guess the hw is not available yet?

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

#33

Post by MaxBarraclough »

mtgx wrote: post #29
anonymousDan wrote: post #25

Earlier quoted context omitted.

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

So the chip-maker would have their hardware protect the permanent secret key, and use ARM's coprocessor to do the cryptographic heavy-lifting? Sounds reasonable.

Is that the first high-level crypto coprocessor then? I'm surprised it's taken this long.

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

#34

Post by excalibur »

lclarkmichalek wrote: post #30
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.

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…

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.

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

#35

Post by wyldfire »

anonymousDan wrote: post #32
wyldfire wrote: post #28

Earlier quoted context omitted.

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 sh…

Thanks, they look pretty interesting. Do you know what granularity the ARM tagging supports (e.g. byte level)? Would be interesting to see performance numbers - although I guess the hw is not available yet?

IIRC the ARM tagging would protect ~8 (maybe 16?) byte regions. More info on this is at [1] [2] -- note that some of this discusses a software-only approach (with likely higher performance impact).

I think the majority of performance cost for HW Asan will come from the additional bits stored to memory, but it was "modest" ([1] https://arxiv.org/abs/1802.09517

[2] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizer...

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

#36

Post by blitmap »

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…

I am probably very uninformed, but I was hoping we might see the kernel + userland running entirely from a secure enclave. As I understood, this would make cold boot attacks more difficult? I'm sure it's like using a sledgehammer to close a narrow attack surface, though. From a performance point of view it's probably not a great exchange.

At minimum I'd want full-disk encryption programs (veracrypt) and biometric authentication services running from an enclave. Lenovo does this for their fingerprint reader.

It would be cool to have the facilities to say "everything run by this user runs in the enclave", but I think the argument is the same as FDE - don't invite the possibility of a leak by selective encryption. All or nothing.

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

#37

Post by jchw »

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.

I always thought the purported advantage of SGX was being able to run important bits of code with ensured integrity, using attestation, even on an unsecure machine. If you ran a whole database in SGX or TrustZone, you just open yourself up to traditional security vulnerabilities alongside the usual side channel attacks you can do against them.

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

#38

Post by anonymousDan »

jchw wrote: post #37
anonymousDan wrote: post #25

Earlier quoted context omitted.

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.

I always thought the purported advantage of SGX was being able to run important bits of code with ensured integrity, using attestation, even on an unsecure machine. If you ran a whole database in SGX or TrustZone, you just open yourself up to traditional security vulnerabilities alongside the usual side channel attacks you can do against them.

Well yes, but I AFAIK remote attestation for specialized security processors has been around for a while. You are of course right that you still have a large attack surface + side channels etc. But at least you can't just snoop on the RAM.

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

#39

Post by lclarkmichalek »

excalibur wrote: post #34
lclarkmichalek wrote: post #30

Earlier quoted context omitted.

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…

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.

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

#40

Post by jki275 »

blitmap wrote: post #36
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…

I am probably very uninformed, but I was hoping we might see the kernel + userland running entirely from a secure enclave. As I understood, this would make cold boot attacks more difficult? I'm sure it's like using a sledgehammer to close a narrow attack surface, though. From a performance point of view it's probably not a great exchange. At minimum I'd want full-disk encryption programs (veracrypt) and biometric aut…

That's very restrictive in terms of general purpose computing. It makes a lot of sense in some other cases though.
Post reply on HN