Init RA Solutions

There are two Init-RA solutions provided, GRPC-RATLS and AECS.

With these two solutions, two customized init are provided. Thus users don’t need modify the init by themselves. Users only need fill in some fields in the template init_ra_conf.json

AECS Init-RA

AECS is a short name of Attestation based Enclave Configuration Service. Basically, part of its function is acting as a remote attestation based key management service.

Occlum provides a way to embed the AECS client function in Occlum Init process by simply running occlum new occlum_instance --init-ra aecs to initiate an Occlum instance.

Then, users can modify the template init_ra_conf.json in oclcum_instance accordingly.

{
    "kms_server": "localhost:19527",
    "kms_keys": [
        {
            "key": "demo_key",
            "path": "/etc/demo_key",
            "service": "service"
        }
    ],
    "ua_env_pccs_url": "",
    "ra_config": {
        "ua_ias_url": "https://api.trustedservices.intel.com/sgx/dev/attestation/v4",
        "ua_ias_spid": "",
        "ua_ias_apk_key": "",
        "ua_dcap_lib_path": "",
        "ua_dcap_pccs_url": "",
        "ua_uas_url": "",
        "ua_uas_app_key": "",
        "ua_uas_app_secret": "",
        "ua_policy_str_tee_platform": "",
        "ua_policy_hex_platform_hw_version": "",
        "ua_policy_hex_platform_sw_version": "",
        "ua_policy_hex_secure_flags": "",
        "ua_policy_hex_platform_measurement": "",
        "ua_policy_hex_boot_measurement": "",
        "ua_policy_str_tee_identity": "",
        "ua_policy_hex_ta_measurement": "",
        "ua_policy_hex_ta_dyn_measurement": "",
        "ua_policy_hex_signer": "",
        "ua_policy_hex_prod_id": "",
        "ua_policy_str_min_isvsvn": "",
        "ua_policy_hex_user_data": "",
        "ua_policy_bool_debug_disabled": "",
        "ua_policy_hex_hash_or_pem_pubkey": "",
        "ua_policy_hex_nonce": "",
        "ua_policy_hex_spid": ""
    }
}

The json file specifies:

  • The URL of the KMS server (AECS).

“kms_server” in the json file, which can be overwritten by environment value OCCLUM_INIT_RA_KMS_SERVER when running.

  • The secrets users need aquire and where to put.

“kms_keys” part. It can define multiple keys to be aquired from KMS server (AECS), and the paths to save the keys. This part should align with the keys injected into KMS server (AECS).

  • The PCCS URL.

“ua_env_pccs_url”. It should be the same with the "pccs_url" in the file /etc/sgx_default_qcnl.conf. It also could be overwritten by environment value UA_ENV_PCCS_URL when running.

  • The measurement of the KMS server (AECS) to be trusted.

“ra_config” part defines the information of the KMS server (AECS) to be trusted. Users could ignore this part if “kms_server” is guaranted to be trusted. Otherwise, some fields, ususally ua_policy_* measurements, are expected correspoding values – RA measurement values from the correct KMS server (AECS).

There is a demo init_aecs_client for reference.

GRPC-RATLS Init-RA

It is based on a GRPC-RATLS implementation.

Occlum provides a way to embed the AECS client function in Occlum Init process by simply running occlum new occlum_instance --init-ra grpc_ratls to initiate an Occlum instance.

Then, users can modify the template init_ra_conf.json in oclcum_instance accordingly.

{
    "kms_server": "localhost:50051",
    "kms_keys": [
        {
            "key": "demo_key",
            "path": "/etc/demo_key"
        }
    ],
    "ra_config": {
        "verify_mr_enclave" : "off",
        "verify_mr_signer" : "off",
        "verify_isv_prod_id" : "off",
        "verify_isv_svn" : "off",
        "verify_config_svn" : "off",
        "verify_enclave_debuggable" : "off",
        "sgx_mrs": [
            {
                "mr_enclave" : "",
                "mr_signer" : "",
                "isv_prod_id" : 0,
                "isv_svn" : 0,
                "config_svn" : 0,
                "debuggable" : true
            }
        ]
    }
}

The json file specifies:

  • The URL of the KMS server (GRPC RA Server).

“kms_server” in the json file, which can be overwritten by environment value OCCLUM_INIT_RA_KMS_SERVER when running.

  • The secrets users need aquire and where to put.

“kms_keys” part. It can define multiple keys to be aquired from KMS server (GRPC RA Server), and the paths to save the keys. This part should align with the keys injected into KMS server (GRPC RA Server).

  • The measurement of the KMS server (GRPC RA Server) to be trusted.

“ra_config” part defines the information of the KMS server (GRPC RA Server) to be trusted. Users could ignore this part if “kms_server” is guaranted to be trusted. Otherwise, some fields are expected correspoding values – RA measurement values from the correct KMS server (GRPC RA Server).

Details please refer to the demo init_ra_flow.