You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of today most people do not use very sophisticated or meaningful policies for the KBS or AS.
With the introduction of EAR, we have a more clear framework for how these policies should work. Let's introduce some new policies and tests to really flesh this out.
First, we have a default EAR AS policy. This should generate a trust vector for each platform assuming that the guest is a coco podvm. Currently we have a basic version of this, but we should expand it to support all platforms and introduce a test that actually exercises it, preferably with real hw. I also want to change the logic of the policy a little bit to not use the min function.
The basic idea of the default policy is to map fields in the hw evidence to reference values. This allow us to calculate a few different trust claims which cover the hw, the configuration of the hw, and the binaries separately. This mapping captures the way that the TCB is measured. We could also create a policy for standard VMs, although there is a lot of variety in how these are measured.
We should also update the KBS policy. Currently we mainly use policies that allow all resources or deny all resources. We also have a policy that allows all resources as long as you aren't using the sample attester. These policies aren't really related to the content of the token.
We should create some more sophisticated policies that actually make sure the EAR token isn't contraindicated (this will probably mean populating some reference values for our tests). For testing we could also check that the EAR token has a valid hw and config but not worry about the binaries or something like that. Maybe we should also have examples of how a policy can check values in the init-data.
The text was updated successfully, but these errors were encountered:
As of today most people do not use very sophisticated or meaningful policies for the KBS or AS.
With the introduction of EAR, we have a more clear framework for how these policies should work. Let's introduce some new policies and tests to really flesh this out.
First, we have a default EAR AS policy. This should generate a trust vector for each platform assuming that the guest is a coco podvm. Currently we have a basic version of this, but we should expand it to support all platforms and introduce a test that actually exercises it, preferably with real hw. I also want to change the logic of the policy a little bit to not use the min function.
The basic idea of the default policy is to map fields in the hw evidence to reference values. This allow us to calculate a few different trust claims which cover the hw, the configuration of the hw, and the binaries separately. This mapping captures the way that the TCB is measured. We could also create a policy for standard VMs, although there is a lot of variety in how these are measured.
We should also update the KBS policy. Currently we mainly use policies that allow all resources or deny all resources. We also have a policy that allows all resources as long as you aren't using the sample attester. These policies aren't really related to the content of the token.
We should create some more sophisticated policies that actually make sure the EAR token isn't contraindicated (this will probably mean populating some reference values for our tests). For testing we could also check that the EAR token has a valid hw and config but not worry about the binaries or something like that. Maybe we should also have examples of how a policy can check values in the init-data.
The text was updated successfully, but these errors were encountered: