- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Team,
I am in the process of setting up the Intel SGX DCAP Attestation infrastructure for test purposes.
While reading about the Registration Authority Service I got some doubts,
1. Registration Authority Service is hosted and maintained by Intel
2. From the DCAP Multipackage Registration document,
- Registration Service Authentication Key(RSAK) that the registration authority service uses to sign authorizations to add new packages to the platform and its self-signed Registration Server ID structure
- Registration Service Encryption Key (RSEK) is a 3072-bit RSA key used to encrypt/decrypt the platform keys.
- Platform Key is a 128-bit key that is the foundation of the provisioning
key derivations in a processor. Multi-package
platforms negotiate platform keys in the field. They
are delivered to the registration authority service
encrypted with the RSAK.
3. From my understanding, Platform Key should not be exposed outside CPU Packages. In Multipackage Platform each CPU package seals the platform key using the unique HW key. The common Platform Key is then used to derive the Provisioning Key, Sealing Key etc by the different CPU packages in the platform.
Questions,
1. Why are platform keys shared with external Registration Service by encrypting using the RSAK?
2. After receiving the RSAK public key encrypted Platform Keys, will the platform keys be decrypted to their plain text format in Intel SGX Registration Authority Service? and then encrypted by RSEK?
3. What is the purpose of exposing the Platform Keys to the external service? Am I missing anything? or Is there any misinformation in the documentation?
Reference document link: https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_SGX_DCAP_Multipackage_SW.pdf
Thanks
Anandakumar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anandakumar,
Platform Keys are not encrypted using the RSAK. Platform keys are encrypted and decrypted using RSEK (as you noted above as well).
The SGX Registration Service supports two mechanisms for registering a platform - direct and indirect registration. In direct registration, the platform manifests, which contain shared platform keys encrypted using RSEK, are sent directly to the Registration Service's register API. Note that when using direct registration, you are giving permission to store the encrypted platform keys in the Registration Service database. Also, platform keys alone are not enough to unseal enclave data, so your data is essentially still secure even when the encrypted platform keys are sent to the Registration Service.
The alternative is indirect registration, where the platform manifest is not sent directly to the Registration Service. The platform manifest is input and a PCK certificate is generated and the Registration Service only uses the encrypted platform keys long enough to generate a PCK certificate and does not store them permanently. If you are concerned about the platform manifest being permanently stored in the Registration Service, indirect registration is the better option. See the DCAP document section 2.3 for more information on this, as it answers a lot of your questions.
I hope this information is helpful, reach out if you have any more questions.
Sincerely,
Sahira
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello!
Any updates on this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anandakumar,
I am looking into this and will get back to you when I have more information
Sincerely,
Sahira
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anandakumar,
Platform Keys are not encrypted using the RSAK. Platform keys are encrypted and decrypted using RSEK (as you noted above as well).
The SGX Registration Service supports two mechanisms for registering a platform - direct and indirect registration. In direct registration, the platform manifests, which contain shared platform keys encrypted using RSEK, are sent directly to the Registration Service's register API. Note that when using direct registration, you are giving permission to store the encrypted platform keys in the Registration Service database. Also, platform keys alone are not enough to unseal enclave data, so your data is essentially still secure even when the encrypted platform keys are sent to the Registration Service.
The alternative is indirect registration, where the platform manifest is not sent directly to the Registration Service. The platform manifest is input and a PCK certificate is generated and the Registration Service only uses the encrypted platform keys long enough to generate a PCK certificate and does not store them permanently. If you are concerned about the platform manifest being permanently stored in the Registration Service, indirect registration is the better option. See the DCAP document section 2.3 for more information on this, as it answers a lot of your questions.
I hope this information is helpful, reach out if you have any more questions.
Sincerely,
Sahira
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Sahira_Intel ,
Thanks for the reply.
"Also, platform keys alone are not enough to unseal enclave data, so your data is essentially still secure even when the encrypted platform keys are sent to the Registration Service."
In single package systems, the HW Root seal key and Root provisioning key are used for deriving various subsets of keys in the enclave operations. In that, Root provisioning keys alone are stored at Intel servers backed by some HSMs.
But, in multi-package systems, the platform key generated during the initial platform establishment will be used for deriving both the seal and provisioning subkeys. Please Correct me if I am wrong.
My question here is,
By exposing the Platform keys to the Intel Server, technically we are sharing the source of seal keys with Intel servers. This is not the case in single-package systems, Where Root Seal key will not be available at Intel Servers at any time.
Please explain what is the need of sharing the platform key with Intel, why can't we just share the platform key hash for verification/registration?
Thanks,
Anand
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anand,
A correction to your above statement:
In multi-package systems, the platform provisioning root keys and platform root seal keys are generated during the initial platform establishment. Only the platform provisioning root keys are sent to the registration server. The platform root seal keys are only available to the platform and are used in deriving the seal keys.
Sincerely,
Sahira
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page