In the Certifier Framework for Confidential Computing, the policy key is the root of all policy decisions and is in the sole control of the "owner" of the security domain of a Confidential Computing program. In the case of "standalone" bilateral trust negotiation, each individual program generates its own policy key and makes trust decisions unilaterally. In this case each program has its own policy key generated at initialization and it possesses both the public and private versions of that key. This is limiting and has scalability and domain management drawbacks. Further, this requires the program to either constuct policy programatically or read it in requiring some mechanism (usually another embedded public key) to verify the policy.
Usually, the policy is administered by the Certifier Service and in this case, all participants in the policy domain root trust decisions on that public key. The private part of the policy key is associated with the Certifier Service. This relieves each Confidential Computing program client of managing policy but imposes the requirement that the Certifier Service verify that each Confidential Computing program client is using the correct policy key as a condition of issuing the "admission certificate."
There are several ways to do this.
-
The easiest is to embed the public portion of the policy in the client program thus making the policy part of the program measurement. Generally this is what we do. To do this, we include a policy key self-signed certificate in the initialized data of the program from which the key is extracted. This self-signed certificate is produced by the Certifier Service tools and provided to the Confidential Computing client programs before they are distributed and measured by the Service.
-
We may also provide a tool to write this certificate into a binary for the application at a known location. This would save the relatively minor overhead of relinking the application.
-
A second alternative (used in our earlier Cloudproxy prototype) is to read in the public policy (perhaps in the form of the self-signed certificate) and "extend" the program measurement with this key. Finally, we could include the policy key in the attestation to the Certifier Service. This means that the has provided to the Service which was "The authentication-key speaks-for the program" is augmented by "The authentication-key speaks-for the program using the named policy-key."
The latter two alternatives suggest adding one or two simple API calls to the Certifier Framework to do this but for now, we will use the first, and simplest, mechanism to provision the policy key.
In an earlier sample app, we construct policy programatically using files generated by the Certifier Service at security domain initialization. Generally, however, we expect people to generate policy declaratively using the utilities provided including:
- ./measurement_utility.exe
- ./make_unary_vse_clause.exe
- ./make_indirect_vse_clause.exe
- ./make_simple_vse_clause.exe
- ./make_signed_claim_from_vse_clause.exe
- ./package_claims.exe
- ./print_vse_clause.exe
- ./print_signed_claim.exe
- ./print_packaged_claims.exe
These are in the the utilities directory along with
the intialization tool cert_utility.exe, which is used to generate
the policy key and its self-signed certificate. That is done in the
current, simple_app, example.
The current example also illustrates the standard process of embedding the public policy key in the application image and running an end-to-end service.