-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add quote guards to ServerInfo
related extrinsics
#1123
base: master
Are you sure you want to change the base?
Conversation
Doesn't work yet though, but this is at least a good checkpoint
Faling to verify the PCK though...
crates/client/src/tests.rs
Outdated
let mut pck_seeder = StdRng::from_seed(tss_public_key.0); | ||
let pck = tdx_quote::SigningKey::random(&mut pck_seeder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ameba23 sorry since this test is a bit of a mess right now, but do you have any idea why the PCK verification might be failing? Should I be using a different input than the tss_public_key
for the seeder?
I've commented out the line in the Attestation crate where this fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so in this case we're using the old PCK for quote verification. I thought the PCK was a fixed thing, but since it's probably tied to the hardware it does need to change then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry i somehow missed this.
Yes the idea was to use tss account id as the seed.
I guess with change_endpoint
its pretty likely that the hardware is changing so PCK would also change (unless the hardware is moving to a different internet connection). Not sure about change_threshold_account
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With change_endpoint
we don't necessarily need to be changing the hardware. Maybe we're just putting our existing node behind a FQDN, or behind a load balancer.
With change_threshold_account
if we make the change to generate the TSS account ID in the enclave then this would very likely indicate that the hardware has also changed.
That said, what if in the second case we just spin up a second instance of entropy-tss
on the same hardware. This would result in a different account_id
and x25519_public_key
, but would it have a different PCK? I'm not familiar enough to know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, what if in the second case we just spin up a second instance of entropy-tss on the same hardware. This would result in a different account_id and x25519_public_key, but would it have a different PCK? I'm not familiar enough to know.
In my understanding PCK would be the same but the 'attestation key' should change. A quote contains two signatures: the quote data is signed with the attestation key, and the attestation public key is signed with the PCK. I chose not to store the attestation public key on chain, because we can already see from the quote itself that it has been endorsed by the PCK - so the PCK is the thing we are interested in.
But this does mean that there can be several TSS nodes associated with the same PCK. I can't think of a reason why this would be a problem but worth being aware of.
It looks like if the TSS Account ID and X25519 public keys are changing then we're probably on different hardware so the PCK will also change. This also gets the client test for the extrisnic passing.
This matches what `validate()` does and prevents us from having an invalid PCK become part of `ServerInfo`.
This reverts commit fe7aadd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🌟 Great
/// | ||
/// The quote format is specified in: | ||
/// https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf | ||
quote: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a followup:
Maybe we wanna have these be given as hex. I think otherwise they need to be given as [234, 1, 43...]
.
It will be easiest if we have them be given in whatever format the TSS server gives them to the operator in the quote generation endpoint, which doesn't yet exist. So probably we can fix this once it does exist.
@@ -36,7 +42,33 @@ async fn test_change_endpoint() { | |||
let api = get_api(&substrate_context.node_proc.ws_url).await.unwrap(); | |||
let rpc = get_rpc(&substrate_context.node_proc.ws_url).await.unwrap(); | |||
|
|||
let result = change_endpoint(&api, &rpc, one.into(), "new_endpoint".to_string()).await.unwrap(); | |||
// By using this `Alice` account we can skip the `request_attestation` step since this is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok, i was thinking we were going to ditch having the pending attestation set at genesis because it wasn't used anymore
attestee = ?attestee.public(), | ||
) | ||
)] | ||
pub async fn request_attestation( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For followup: If this is going to also be called by entropy-tss
, which i think we probably will want to when we add a generate quote endpoint - it will need to go in a different module as stuff in this one is behind the full-client
feature flag.
let result = | ||
submit_transaction_with_pair(api, rpc, &attestee, &request_attestation, None).await?; | ||
let result_event = result | ||
.find_first::<entropy::attestation::events::AttestationIssued>()? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats nice that you can get the nonce like this - i didnt understand that from the last PR.
@@ -155,6 +160,13 @@ enum CliCommand { | |||
new_tss_account: String, | |||
/// New x25519 public key | |||
new_x25519_public_key: String, | |||
/// The new Provisioning Certification Key (PCK) certificate chain to be used for the TSS. | |||
new_pck_certificate_chain: Vec<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For followup: If given as strings, it probably makes sense for them to be PEM encoded as this is the standard for encoding x509 certificates as utf-8. This would mean adding a dependency to the test-cli to decode them. Otherwise we could have them be read in from files i guess.
We can probably leave this until we develop tooling for operators to be able to retrieve these certificates and see what makes most sense then.
This is one of the follow-ups to #1109, in which we will enforce that validators who want
to change certain info about their validator will need to pass an attestation check
first.
For the
change_endpoint()
extrinsic we assume that that the underlying hardware andAccount ID stay the same, so a quote from the existing TSS Account ID is expected.
For the
change_threshold_accounts()
extrinsic we assume that the underlying hardwarehas changed, so a quote from a new TSS account ID is expected.