Skip to content
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

Open
wants to merge 32 commits into
base: master
Choose a base branch
from

Conversation

HCastano
Copy link
Collaborator

@HCastano HCastano commented Oct 21, 2024

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 and
Account 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 hardware
has changed, so a quote from a new TSS account ID is expected.

@HCastano HCastano mentioned this pull request Oct 23, 2024
Comment on lines 139 to 140
let mut pck_seeder = StdRng::from_seed(tss_public_key.0);
let pck = tdx_quote::SigningKey::random(&mut pck_seeder);
Copy link
Collaborator Author

@HCastano HCastano Oct 28, 2024

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Contributor

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.

@HCastano HCastano added the Bump `transaction_version` A change which affects how existing extrinsics are created (e.g parameter changes) label Nov 4, 2024
@HCastano HCastano marked this pull request as ready for review November 4, 2024 21:26
Copy link
Contributor

@ameba23 ameba23 left a 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,
Copy link
Contributor

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
Copy link
Contributor

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(
Copy link
Contributor

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>()?
Copy link
Contributor

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>,
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bump `transaction_version` A change which affects how existing extrinsics are created (e.g parameter changes)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants