-
Notifications
You must be signed in to change notification settings - Fork 83
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
token: implement EAR token generation
This commit allows the AS to issue EAR tokens with the help of the rust-ear crate. EAR tokens require particular claims. This creates a binding between the AS policy and the EAR token. Specifically, the policy engine must return an EAR appraisal. The policy engine is still generic. Multiple policy engines could be implemented as long as they create an appraisal. Token generation is no longer generic. Since the policy engine, will always return an appraisal, we must generate an EAR token. This commit removes the simple token issuer and replaces the TokenProvider trait with a struct. The KBS will still be able to validate many different tokens, but this commit changes the AS to only issue EAR tokens. There are a few other changes, including that the policy engine no longer takes multiple policies. For now, we only evaluate the first policy in the policy list, but future commits will change this convention so that we only ever think about one policy for the attestation service (until we introduce support for validating multiple devices at once). This commit also slightly changes how we handle init-data by adding the init_data_claims and runtime_data_claims to the flattened claims when the init_data and report_data fields are part of the tcb_claims returned by the verifier. This surfaces the json init_data and report_data to the AS and KBS policy engines and includes them in the EAR token. Note that this will increase the size of the token and that some complex init_data values might break out JSON flattening code. Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
- Loading branch information
Showing
10 changed files
with
349 additions
and
494 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
104 changes: 21 additions & 83 deletions
104
attestation-service/src/policy_engine/opa/default_policy.rego
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,93 +1,31 @@ | ||
# Attestation Service Default Policy | ||
# | ||
# The function of this policy is to adopt the default policy when no custom policy | ||
# is provided in the attestation request of Attestation Service. | ||
# | ||
# - The input data required by this default policy is a set of key value pairs: | ||
# | ||
# { | ||
# "sample1": "112233", | ||
# "sample2": "332211", | ||
# ... | ||
# } | ||
# | ||
# - The format of reference data required by this default policy is defined as follows: | ||
# | ||
# { | ||
# "reference": { | ||
# "sample1": ["112233", "223311"], | ||
# "sample2": "332211", | ||
# "sample3": [], | ||
# ... | ||
# } | ||
# } | ||
# | ||
# If the default policy is used for verification, the reference meeting the above format | ||
# needs to be provided in the attestation request, otherwise the Attestation Service will | ||
# automatically generate a reference data meeting the above format. | ||
package policy | ||
import rego.v1 | ||
|
||
import future.keywords.every | ||
# For the `executables` trust claim, the value 33 stands for | ||
# "Runtime memory includes executables, scripts, files, and/or | ||
# objects which are not recognized." | ||
default executables := 33 | ||
|
||
default allow = false | ||
# For the `hardware` trust claim, the value 97 stands for | ||
# "A Verifier does not recognize an Attester's hardware or | ||
# firmware, but it should be recognized." | ||
default hardware := 97 | ||
|
||
allow { | ||
every k, v in input { | ||
# `judge_field`: Traverse each key value pair in the input and make policy judgments on it. | ||
# | ||
# For each key value pair: | ||
# * If there isn't a corresponding key in the reference: | ||
# It is considered that the current key value pair has passed the verification. | ||
# * If there is a corresponding key in the reference: | ||
# Call `match_value` to further judge the value in input with the value in reference. | ||
judge_field(k, v) | ||
} | ||
} | ||
|
||
judge_field(input_key, input_value) { | ||
has_key(data.reference, input_key) | ||
reference_value := data.reference[input_key] | ||
|
||
# `match_value`: judge the value in input with the value in reference. | ||
# | ||
# * If the type of reference value is not array: | ||
# Judge whether input value and reference value are equal。 | ||
# * If the type of reference value is array: | ||
# Call `array_include` to further judge the input value with the values in the array. | ||
match_value(reference_value, input_value) | ||
} | ||
|
||
judge_field(input_key, input_value) { | ||
not has_key(data.reference, input_key) | ||
} | ||
# For the `executables` trust claim, the value 3 stands for | ||
# "Only a recognized genuine set of approved executables have | ||
# been loaded during the boot process." | ||
executables := 3 if { | ||
input.launch_digest in data.reference.launch_digest | ||
|
||
match_value(reference_value, input_value) { | ||
not is_array(reference_value) | ||
input_value == reference_value | ||
} | ||
|
||
match_value(reference_value, input_value) { | ||
is_array(reference_value) | ||
# For the `hardware` trust claim, the value 2 stands for | ||
# "An Attester has passed its hardware and/or firmware | ||
# verifications needed to demonstrate that these are genuine/ | ||
# supported. | ||
hardware := 2 if { | ||
input.productId in data.reference.productId | ||
|
||
# `array_include`: judge the input value with the values in the array. | ||
# | ||
# * If the reference value array is empty: | ||
# It is considered that the current input value has passed the verification. | ||
# * If the reference value array is not empty: | ||
# Judge whether there is a value equal to input value in the reference value array. | ||
array_include(reference_value, input_value) | ||
} | ||
|
||
array_include(reference_value_array, input_value) { | ||
reference_value_array == [] | ||
} | ||
|
||
array_include(reference_value_array, input_value) { | ||
reference_value_array != [] | ||
some i | ||
reference_value_array[i] == input_value | ||
} | ||
input.svn in data.reference.svn | ||
|
||
has_key(m, k) { | ||
_ = m[k] | ||
} |
Oops, something went wrong.