Replies: 5 comments 8 replies
-
|
I'm unsure what exactly you want to do in your use case. But generally you would want to use the Intel DCAP libraries. Gramine uses them like this, if you're interested in the source code: gramine/tools/sgx/ra-tls/ra_tls_verify_dcap.c Lines 126 to 260 in a60dcf7 The two important Intel DCAP libraries APIs are:
You can check their documentation if you want to know more: https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_SGX_ECDSA_QuoteLibReference_DCAP_API.pdf The Intel DCAP library is called Line 257 in a60dcf7 IIRC, this DCAP library is part of the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for precisely pinpointing the code responsible for the quote verification in the RA-TLS protocol. implementation. That's very helpful!
I just want to verify the quote (whatever that precisely means under the hood) to make sure I'm talking to the legitimate enclave that is running the code I expect it to run. What do I need to do to verify that (assuming I want to use that low level API with I think I need to better understand how this works under the hood, as I assumed it all ultimately came down to checking the ECDSA signature. At least that's how I understood it after reading https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#platform-provisioning - specifically this part:
However, I expect there may be more to it, as there is more to the SGX quote structure than just a signature. BTW, can you please clarify if that gramine/tools/sgx/ra-tls/ra_tls_verify_dcap.c Line 127 in a60dcf7 can be constructed from the string I'm printing in here: https://github.com/pbeza/gramine-attestation-demo/blob/3a6e959f2a8c6ff8041ab9bd3b6f25b77cd71259/src/main.rs#L33 ? Is it essentially the same thing? |
Beta Was this translation helpful? Give feedback.
-
(Sorry if my reply may be a bit unclear, I'm writing off the top of my head. Some things may be slightly wrong or with wrong terminology. Please ask if something is unclear.) Broadly speaking, there are two things we want to know as part of attestation:
Applying this to the Intel SGX terminology, we map these two things like this:
RA-TLS abstracts away these two verifications, leaving only a bunch of environment variables (and a C callback if required) tweakable by the user of RA-TLS. You can of course build your own verifier instead of RA-TLS. So, at the programming level, the two above things map like this:
This should be all the steps required for SGX quote verification.
Yes, that's why Gramine (and RA-TLS) outsources this verification part to the Intel DCAP libraries -- the exact verification steps are quite complicated. For example, the DCAP SGX quote actually embeds the whole certificate chain rooted at Intel PCS (or well, at least that's the case in my deployments).
Yes, it is the same thing. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @dimakuv, I work with Patryk but on different field - basically what i'll try to do is, to verify the 'sgx proof' on-chain - via Solidity so therefore i'd like to ask some high-level questions. What i'm thinking is, to do the remote attestation verification off-chain, and once it is verified, then the sgx instance shall be identified by it's ECDSA pub. key (-> ethereum address). In my understanding, attestation is basically proving the identity (and trustworthiness of a machine) to a verifier. -> This can be done by diff. ways, but only need to be done at setup (with this proposed solution of mine) ? So something, high-level like: OR Attestation necessary each and every time there is a new computation ? If former then i'd just not do attestation verification on-chain, simply done once at setup, if latter (maybe because that instance can make itself 'malicious' on the go(?if this is possible?)), then yes, we need to figure out something. |
Beta Was this translation helpful? Give feedback.
-
|
Dear @adaki2004, Yes, your understanding is correct, and your explanations look good to me. Just don't forget that you must tie the ECDSA pub key to the identity of the SGX enclave, as reported by the SGX quote. In other words, the SGX quote must bare some evidence that it was indeed generated in the SGX enclave that runs with this particular ECDSA pub key. In RA-TLS (and it's the main feature of RA-TLS), we bind the SGX quote with the ephemeral keypair created inside of the SGX enclave that is used to sign a self-signed X.509 certificate. The diagram shows how it is done: https://gramine.readthedocs.io/en/stable/attestation.html#mid-level-ra-tls-interface If you haven't yet, also read our RA-TLS whitepaper: https://arxiv.org/abs/1801.05863 (Gramine and RA-TLS are not unique in this solution. In fact, all SGX frameworks/runtimes use a variation of this scheme.)
There is another catch which is the SGX-attestation validity period. Imagine that your SGX enclave runs for several weeks non-stop. If you generated only one ECDSA key, and use its public part for authentication for several weeks, then the SGX enclave (or the underlying hardware) could be hi-jacked, secrets -- including the private ECDSA key -- could be stolen, and the SGX enclave is compromised. So typically people also add a rather-small validity period for the attestation token (in your case, the attestation token = ECDSA pub key). For example, Microsoft Azure Attestation sets this period to 8 hours: https://learn.microsoft.com/en-us/azure/attestation/faq#how-long-is-an-attestation-token-valid- TLDR: Your approach looks correct, but be aware of the aforementioned caveats. |
Beta Was this translation helpful? Give feedback.
-
@dimakuv What's the best way to tie the ECDSA pub key to the identity of the SGX enclave, as reported by the SGX quote? Is putting the public key in |
Beta Was this translation helpful? Give feedback.
-
Yes. In fact that's what all SGX projects/frameworks do that I've seen. See our diagram here: https://gramine.readthedocs.io/en/stable/attestation.html#mid-level-ra-tls-interface. Check out the Also, you can read Intel's whitepaper on this: https://github.com/cloud-security-research/sgx-ra-tls/blob/master/whitepaper.pdf |
Beta Was this translation helpful? Give feedback.
-
|
Dear @dimakuv,
Regarding this, our initial plan is/was to always use another ECDSA key for signing the data to avoid side-channel attacks. So like this:
Would it work without expiry then ? Or we shall take other extra measures ? |
Beta Was this translation helpful? Give feedback.
-
I'm unclear on this part. Didn't you want to avoid re-generating the SGX proof/ECDSA key on every request? Or you have two types of requests: the off-chain attestation-validation requests and the on-chain computation requests? (Sorry, I have no idea what all this stuff is :)) If you do have these two types of requests, and you will re-generate the SGX proof (quote) and the ECDSA key on only the first types of requests (and not on the second ones), then yes, your scheme works. Again, the requests to provide the SGX proof should happen frequently enough. They can't happen once in a month. |
Beta Was this translation helpful? Give feedback.
-
No, in (my :) ) term SGX proof is a signature. We need this quite frequently. So how the instance works: it does some 'in house' computations, and will sign the outcome of this computation with it's active ECDSA private key.
Basically, yes!
And the verification of that 2nd outcome (signed data) happens on-chain. And as you suggested, throwing away the old ECDSA key pair, and using a new one by design, to avoid attack vectors. I do not know the exact frequency but it shall happen more frequently than once a month. Is it a working concept against (most possible or all) attack vectors ? Shall we still count on attestation expiry in this case as well ? (Given the known fact that we can be sure that only this instance can sign and generate a new ECDSA key-pair, so the fact itself can give us trust.. OR anyways, we need to keep expiry in our mind ?) |
Beta Was this translation helpful? Give feedback.
-
It's up to you honestly. I would at least have some hard requirement that the frequency of regenerating the ECDSA keypair is capped at X. For example, at least once a week such an attestation-validation request will be sent, so the validity period of your ECDSA pubkey is capped at 7 days. The validity periods themselves vary wildly. Check what validity periods X.509 certificates have these days, this will give you a rough idea what people consider a "safe enough" period of time. |
Beta Was this translation helpful? Give feedback.
-
|
@dimakuv, do you perhaps have some minimal example of RA-TLS implemented in Rust (instead of |
Beta Was this translation helpful? Give feedback.
-
No, we don't have such an example. |
Beta Was this translation helpful? Give feedback.
-
I've prepared a simple demo repository that prints the SGX quote by reading
/dev/attestation/quote(I'm usingDCAPattestation). It seems to work fine because it prints a quote (at least that's what I think, since it prints a random string of bytes; see below). Now: how can I verify that SGX quote? Is that quote all I need to provide to the SGX DCAP verifier? I know Intel provides a reference verifier implementation, but it is very poorly documented and difficult to use for me. Maybe you have some tips that will help me verify the quote?In case you want to try out my demo:
Process the manifest file (BTW: does it generate
MRENCLAVEat this point?)Sign the manifest file:
Run the app printing the SGX quote:
BTW, the demo above was inspired by the Gramine sample code: https://github.com/gramineproject/gramine/blob/master/CI-Examples/python/scripts/sgx-quote.py I just reimplemented it in Rust.
BTW2, quote from your docs:
but still seeking your help with that :)
Beta Was this translation helpful? Give feedback.
All reactions