[RFC] Add SGX KSS (Key Separation and Sharing feature) support on Occlum

[qzheng527]

• Feature Name: Add SGX KSS (Key Separation and Sharing feature) support on Occlum
• Start Date: 2021-8-11

Summary

Starting from SGX2, there is a new Key Separation and Sharing feature which current Occlum doesn't support . This RFC gives a design proposal about supporting KSS on Occlum.

Motivation

The new Key Separation and Sharing feature gives user a chance to fill in some meaningful information to the enclave either in the signing or running stage.

Signning stage:

• ISVFAMILYID, 16 bytes
• ISVEXTPRODID, 16 bytes

Running stage:

• CONFIG ID, 64 bytes
• CONFIG SVN, 16 bits

All above information could be aquired from the DCAP generated quote in enclave.
Details can be found on the SGX_Developer_Reference
Thus with these user provided information binded with the enclave quote, different attestation and qualification solution can be implemented.

Guide-level explanation

To support the new KSS feature in Occlum, below changes are expected.

1. Add KSS signning stage information in template Occlum.json file.
2. When doing occlum build, the tool gen_internal_conf may check and add the KSS information to SGX signning xml file from Occlum.json file.
3. When doing occlum run, two new added arguments may be usedto pass CONFIG ID and CONFIG SVN to enclave.

Reference-level explanation

• Added KSS part in template Occlum.json.
  After occlum new, below Occlum.json may be generated.

--- a/etc/template/Occlum.json
+++ b/etc/template/Occlum.json
@@ -24,7 +24,12 @@
     "metadata": {
         "product_id": 0,
         "version_number": 0,
-        "debuggable": true
-        "debuggable": true
+        "debuggable": true,
+        "family_id": {
+            "high": "0x0",
+            "low": "0x0"
+        },
+        "ext_prod_id": {
+            "high": "0x0",
+            "low": "0x0"
+        }
     },

User can do the changes before occlum build.

The occlum tries to parse the string as 64bits hex integer.
For example, enable KSS and set demo IDs as below hex integer.

        "enable_kss": true,
        "family_id": {
            "high": "0x12345678aabbccdd",
            "low": "0x87654321ffeeccbb"
        },
        "ext_prod_id": {
            "high": "0x2244668811335577",
            "low": "0x1234567801020304"
        }

• Add argument "--config-id" to pass CONFIG ID
  It is expected that the user pass a base64 encoded result string for the CONFIG ID.
  Before creating SGX enclave in PAL, the base64 encoded string is decoded.
  If the decoded length is not bigger than 64, copy the decoded bytes to CONFIG ID field (64 bytes, padding the rest as 0 if the decoded length is smaller than 64). Otherwise, return error, not valid Occlum Config ID Base64 String.

For example, there is a 64 bytes binary file 64.bin.
Use below command to run.

occlum_instance# occlum run --config-id "`base64 64.bin`" /bin/dcap_test

• Add argument "--config-svn" to pass CONFIG SVN

occlum_instance# occlum  run --config-svn 0x12ab /bin/dcap_test

Unresolved questions

How to best utilize this new KSS feature in a practical and valuable scenario.

[guzongmin]

Should we use Base64 in the ConfigID file? Because most of the time, Occlum launcher get the ID from network.

[qzheng527]

Should we use Base64 in the ConfigID file? Because most of the time, Occlum launcher get the ID from network.

The problem of Base64 is it may generate longer (bytes) result data compared to the original data.
The Config ID in SGX has a fixed max length 64 bytes.
So if one provides a 64 bytes ID, after base64, its length may be longer than 64 bytes which couldn't be put into the SGX config ID field.

The current way uses the raw data from the CONFIG ID FILE, it is up to the user to decide which kind of data that want to fill in.
Base64 encoded data is also acceptable.
For example,

$ echo "Hello world, this is from Occlum team!" | base64 > conf

[qzheng527]

Should we use Base64 in the ConfigID file? Because most of the time, Occlum launcher get the ID from network.

The problem of Base64 is it may generate longer (bytes) result data compared to the original data.
The Config ID in SGX has a fixed max length 64 bytes.
So if one provides a 64 bytes ID, after base64, its length may be longer than 64 bytes which couldn't be put into the SGX config ID field.

The current way uses the raw data from the CONFIG ID FILE, it is up to the user to decide which kind of data that want to fill in.
Base64 encoded data is also acceptable.
For example,

$ echo "Hello world, this is from Occlum team!" | base64 > conf

Discussed with Zongmin, file is not a proper way in cloud native env to pass information.
Updated the RFC to use BASE64 string to pass CONFIG ID information.

[tatetian]

How to best utilize this new KSS feature in a practical and valuable scenario.

My fundamental concern about PR is whether it really explores the real value of the KSS feature. This RFC propose simply exposes Intel SGX SDK's KSS feature to the Occlum users. What if we choose an alternative approach where we leverage KSS in Occlum itself and provide high-level features that enabled by KSS to the end users?

Let me quote from a blog named Upcoming Intel SGX features explained.

This means a software vendor can have a single enclave binary that can be easily customized at enclave load time. A practical application of this is loading code at enclave runtime while maintaining the ability to separate payloads.

Wow. This could be very useful to Occlum. We can build and distribute a single pre-signed Occlum enclave binary and let the end users to attach their Occlum.json and Occlum FS image to their enclaves at runtime. This will accelerate the occlum build command and may have other benefits.

Additionally, a specific customization can be depended on for security purposes. As with all the SVNs, an enclave can recover secrets sealed by a key with the same configuration ID but a lower (and not a higher) configuration SVN.

Wow again. This configuration SVN can enable a newer version of Occlum binary that is upgraded with security patches or bug fixes to read the encrypted FS data generated by an older version of Occlum binary. This could save the day for some customers that uses Occlum in production.

The bottom line is that a RFC that proposes adding KSS support must give more intelligent advices on how to really use KSS and investigate all possible options that KSS may be integrated into Occlum, rather than simply exposing KSS to the end users.

[guzongmin]

I realized that the KSS feature would impact the RA quote struct. So if Occlum use any of them, then Occlum need to document what is the meaning of the value and how to check it. When Occlum has any update, the RA checker needs to update the validation logic. It would be a big effort for end-user. So I think we should leave all those KSS IDs to end-user.

Occlum do get benefit from the KSS feature, when we give the user some demos. For example, . But Occlum should not use KSS by default.

On the other hand, KSS is SGX V2 specific feature. Occlum should not depend on this feature by default before dropping the SGX V1 supporting.