Better attestation and sealing?

[Dayeol Lee]

Hi,

I wanted to bring this up publicly, so that people can share some thoughts.

As people may already know, Keystone doesn't natively support some features that are available in Intel SGX.

One of the examples is data sealing, which allows storing secret data to unprotected non-volatile local storage.

Currently, the Keystone SM delegates all the decisions to enclave, such that the enclave itself can decide how to deal with sealing.

Intel SGX allows identity-based and author-based sealing, but those are limited to the local sealing.

https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing

Given that, what would be an advantage of having a native sealing mechanism in the SM?

Can we come up with a better attestation + sealing interface that is much simpler & useful than SGX?

One thing I want to address is to allow sharing of the sealing key across different platforms which is not natively supported by SGX.

Please comment any thoughts!

Dayeol

[Joman Chu]

Hi,

Long time lurker, first time caller.

Sealing allows me to bind data to the physical processor.  I primarily use this feature to as a place to store a long-term identity secret that I can confidently say only someone with physical access to the processor fuses can spoof (or someone with access to the fuse values).  Without this, I'd have to trust the processor manufacturer for identity every time I desire it.

Joman

--
You received this message because you are subscribed to the Google Groups "Keystone Enclave Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keystone-enclave-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/268b2de1-21bf-4831-9158-f16b1607bedf%40googlegroups.com.

[Jethro Beekman]

Hi Dayeol,

Besides sharing the sealing key between platforms, can you elaborate on which part of the SGX design you find less simple or useful than you'd want? I invite you to look at the more recent SGX DCAP design (as opposed to the older EPID).

The main issue I see w.r.t. attestation & Keystone is: who is going to be the root of trust?

I think sharing a sealing key between platforms shouldn't be handled at the architectural layer. You need to be able to define policies for which platforms may share information. To me, this seems better handled by some key distribution service that relies on remote attestation. Sealing should only be used for local long-term caching.

--
Jethro Beekman | Fortanix

> --
> You received this message because you are subscribed to the Google Groups "Keystone Enclave Forum" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to keystone-enclave-...@googlegroups.com <mailto:keystone-enclave-...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/268b2de1-21bf-4831-9158-f16b1607bedf%40googlegroups.com <https://groups.google.com/d/msgid/keystone-enclave-forum/268b2de1-21bf-4831-9158-f16b1607bedf%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Dayeol Lee]

Joman and Jethro,

Thanks for pointing that out.

I think I need to educate myself with the newer SGX attestation/sealing.

I agree that the platform (+SM) should only provide a minimum interface such as providing a local long-term key bound to the hardware secret (just like SGX sealing key).

I will try to write up a proposal.

Thanks!

Dayeol

To unsubscribe from this group and stop receiving emails from it, send an email to keystone-enclave-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/597df032-5921-fc5d-5fff-32c97c11cf74%40fortanix.com.

[Benedikt Kopf]

1 2 3 4 5 6 7 8

Hello, I wrote my bachelor's thesis about the creation of a sealing feature in Keystone. My mechanism is similar to the SGX implementation. I derive the sealing key from the private security monitor key, the hash of the enclave and an input, chosen by the user, to enable the derivation of multiple keys from one enclave. With that mechanism the sealing key is bound to the identity of the hardware, the security monitor and the enclave. This key can be used to seal data similar to the SGX sealing feature. I already implemented this feature in the security monitor (C and Rust) and created a pull request. Regards, Benedikt Kopf

[David William Kohlbrenner]

Thanks Benedikt! This seems really neat!

It'll take us a bit to look through the PRs and make comments/land things.

We'll handle discussion about the implementation on the github PRs and post to the list when things land.

(For reference, the PRs are:
https://github.com/keystone-enclave/riscv-pk/pull/68

https://github.com/keystone-enclave/keystone-runtime/pull/31

https://github.com/keystone-enclave/keystone-sdk/pull/49

https://github.com/keystone-enclave/keystone/pull/172

)

--

You received this message because you are subscribed to the Google Groups "Keystone Enclave Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keystone-enclave-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/keystone-enclave-forum/b3bdcc32-20f7-4a5f-adfd-5023f4181533%40googlegroups.com.