Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

AR4SI mappings folder #52

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

AR4SI mappings folder #52

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1806b71
verbatim copy (modulo translation into markdown) of the Google Docs d…
thomas-fossati May 23, 2024
8234130
address review comments
thomas-fossati Sep 5, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@
## Data Models

* [Attestation Results](datamodels/attestation-results/README.md)
* [AR4SI Mappings](ar4si/README.md)

## Musings

Expand Down
9 changes: 9 additions & 0 deletions ar4si/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Attestation Results for Secure Interactions (AR4SI) Mappings

[Section 2.3.4 of draft-ietf-rats-ar4si](https://www.ietf.org/archive/id/draft-ietf-rats-ar4si-06.html#section-2.3) describes the Trustworthiness Claims and their supported enumerations.

This folder contains the AR4SI mappings used by the attestation schemes supported by Veraison.

Each scheme is documented in a separate file:

* [Arm CCA](arm-cca.md)
91 changes: 91 additions & 0 deletions ar4si/arm-cca.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
# Platform

|Bucket|Notes|Claims|Applicability|
| --- | --- | --- | --- |
|Catch-all||VERIFIER_MALFUNCTION|any unexpected exceptions during the appraisal/verification flow|
|||NO_CLAIM|This MAY be the value for the buckets that are not applicable (i.e., those marked as “N.A.”), if they are included.|
|||UNEXPECTED_EVIDENCE|On failures coming from the token decoder|
|||CRYPTO_VALIDATION_FAILED|On failures coming from the Platform token verifier (excluding Realm binding, which is captured in the Realm part)|
|Instance identity||TRUSTWORTHY_INSTANCE|verification using CPAK is successful and Implementation ID is known (implicitly, from the fact that ref-values associated to it exist)|
|||UNTRUSTWORTHY_INSTANCE|If the verifier has a notion of known-bad CPAK, then verification using CPAK that is successful but CPAK is known-bad can assert this claim.|
|||UNRECOGNIZED_INSTANCE|No CPAK found corresponding to the Instance ID or Implementation ID is not known (i.e., there are no ref-values associated to it.)|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add a clarification Glossary in the end to expand fully what it means to be CPAK ..?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are talking of a single acronym, adding a glossary is a tad overkill :-)

I'll expand CPAK inline.

|Config|Two notions of config in CCA may apply: (a) the “System Properties” captured in the Platform “config” claim, (b) the firmware and/or hardware configuration file that can be specified by certain boot loader stages. Those end up in sw-components entries of type “*_CONFIG”|APPROVED_CONFIG|TBD[^1] decide on what semantics we want to map here.|
|||NO_CONFIG_VULNS|ditto|
|||UNAVAIL_CONFIG_ELEMS|ditto|
|||UNSAFE_CONFIG|ditto|
|||UNSUPPORTABLE_CONFIG|ditto|
|Executables|This conflates boot and run-time and makes disentangling “partial match” situations impossible.|APPROVED_BOOT|If all sw-component claims have been verified|
|||APPROVED_RUNTIME|N.A.|
|||CONTRAINDICATED_RUNTIME|N.A.|
|||UNRECOGNIZED_RUNTIME|N.A.|
|||UNSAFE_RUNTIME|N.A.|
|File system||APPROVED_FILES|N.A.|
|||UNRECOGNIZED_FILES|N.A.|
|||CONTRAINDICATED_FILES|N.A.|
|Hardware (and Firmware)||CONTRAINDICATED_HARDWARE (genuine HW/FW but contraindicated)|TRUSTWORTHY_INSTANCE && some sw-component claims are known-bad|
|||UNRECOGNIZED_HARDWARE (unrecognised HW/FW)|TRUSTWORTHY_INSTANCE && some sw-component claims couldn’t be found|
|||GENUINE_HARDWARE (genuine HW/FW)|Same as (TRUSTWORTHY_INSTANCE && APPROVED_BOOT)|
||Not clear what is the difference between this and CONTRAINDICATED_HARDWARE?|UNSAFE_HARDWARE (genuine HW/SW but known sec vulns)|TBD (see note)|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not clear what is the difference between this and CONTRAINDICATED_HARDWARE?

CONTRAINDICATED == know exploits
UNSAFE == known vulns (but no know exploits confirmed)
?

Copy link
Contributor Author

@thomas-fossati thomas-fossati Sep 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for self: this needs corresponding signals in the x-refval.

|Sourced Data||CONTRAINDICATED_SOURCES|N.A.|
|||TRUSTED_SOURCES|N.A.|
|||UNTRUSTED_SOURCES|N.A.|
|Runtime opaque||ENCRYPTED_MEMORY_RUNTIME|Depends on the settings of the config claim? Or can it be assumed for any genuine RME?[^2]|
|||ISOLATED_MEMORY_RUNTIME|See above[^3]|
|||VISIBLE_MEMORY_RUNTIME|N.A.|
|(persistent) Storage opaque||HW_KEYS_ENCRYPTED_SECRETS|TBD|
|||SW_KEYS_ENCRYPTED_SECRETS|ditto|
|||UNENCRYPTED_SECRETS|ditto|

[^1]: SimonF: The Platform config definitely comes into play here as the context is that the host needs to be equipped for confidential operation and hence the RME extension needs to be shown as enabled.
To be detailed in analysis of the firmware contribution for 'config' contributions, there are those sw component entries that are config blobs rather than FW binaries which can need verification.
It could also be said that config also covers checks that certain FW items (roles?) are present e.g an RMM
ThomasF: I am having trouble understanding how the two semantics (i.e., boot loader(s) configuration vs ISA configuration) can co-exist with each other in the same TV claim. It looks like the intention of AR4SI config as currently specified ("A Verifier has appraised an Attester's configuration, and is able to make conclusions regarding the exposure of known vulnerabilities") is more naturally mapped to the former (i.e., boot loader's) than the latter - mostly because I wouldn't know how to "make conclusions regarding the exposure of known vulnerabilities" based on the platform's config claim alone.
SimonF: Agreed. I think the original doc misses the nuisance of HW configuration affecting this ability.
ThomasF: yeah, that's a "very" gray area. I was pondering whether making platform's config fall into the hardware.GENUINE_HARDWARE basket, but it's probably not a huge improvement.

[^2]: SimonF: This is a bit tricky because the presence & config of a Memory Protection Engine is Impdef. It should show up in the same sys properties that are used to show RME so we could note that it's profile capable. Remind me: is this setting bitwise or absolute - i.e. can we have both Encrypted + Isolated for this entry or does it have to be one or the other?
ThomasF: it's absolute: basically, ENCRYPTED absorbs ISOLATED

[^3]: SimonF: Any system known to be RME capable and configured can claim ISOLATED. We could just do this from platform config but potentially also ImplementationID
ThomasF: OK, so this can be implied if (tv.instance_identity == TRUSTWORTHY_INSTANCE) && (platform.config & RME_CAPABLE) ?

# Realm

|Bucket|Notes|Claims|Applicability|
| --- | --- | --- | --- |
|Catch-all||VERIFIER_MALFUNCTION|any unexpected exceptions during the appraisal/verification flow|
|||NO_CLAIM|This MAY be the value for the buckets that are not applicable (i.e., those marked as “N.A.”), if they are included. Alternatively, if platform appraisal fails flat, this can be the value that all Realm buckets are reset to (meaning: since platform is not successfully appraised, we cannot say anything about Realm integrity)|
|||UNEXPECTED_EVIDENCE|On failures coming from the Realm token decoder|
|||CRYPTO_VALIDATION_FAILED|on failures coming from the Realm token verifier (not including the binding to the Platform token, which is dealt with in the instance identity category as UNRECOGNIZED_INSTANCE)|
|Instance identity||TRUSTWORTHY_INSTANCE|If crypto verification (including chaining) completes correctly|
|||UNTRUSTWORTHY_INSTANCE|N.A.|
|||UNRECOGNIZED_INSTANCE|If crypto verification is OK but chaining fails|
|Config||APPROVED_CONFIG|N.A.|
|||NO_CONFIG_VULNS|N.A.|
|||UNAVAIL_CONFIG_ELEMS|N.A.|
|||UNSAFE_CONFIG|N.A.|
|||UNSUPPORTABLE_CONFIG|N.A.|
|Executables|It looks like an “UNRECOGNIZED_BOOT” is missing… but really the problem here is that this claim conflates run-time and boot-time.|APPROVED_BOOT|if RIM and PV (if provided) match|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the value of Executables field if RIM and PV do not match? Would the value ever be APPROVED_BOOT in paractice, if the value of the field depends on the subsequent evaluation of REM?

I agree, there should really be a spearate claim for "boot"...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the value of Executables field if RIM and PV do not match?

There is none at the moment. UNRECOGNIZED_BOOT would be it - if it existed.
OK, I will raise an issue in the AR4SI repo for that.
Until then, we have the negative codepoints space to use to define our new experimental semantics.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See ietf-rats-wg/draft-ietf-rats-ar4si#28

|||APPROVED_RUNTIME|if REM match|
|||CONTRAINDICATED_RUNTIME|If the verifier has a notion of known-bad REM values (alongside known-good) this can be set in case REM matches known-bad values|
|||UNRECOGNIZED_RUNTIME|If no REM ref-values match evidence|
||Not clear how this differs from CONTRAINDICATED_RUNTIME|UNSAFE_RUNTIME|(could be used as an alternative to CONTRAINDICATED_RUNTIME in the warning tier)|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As with hardware, know exploit vs know vuln?

|File system||APPROVED_FILES|N.A.|
|||UNRECOGNIZED_FILES|N.A.|
|||CONTRAINDICATED_FILES|N.A.|
|Hardware (and Firmware)||CONTRAINDICATED_HARDWARE|N.A.|
|||UNRECOGNIZED_HARDWARE|N.A.|
|||GENUINE_HARDWARE|N.A.|
|||UNSAFE_HARDWARE|N.A.|
|Sourced Data||CONTRAINDICATED_SOURCES|N.A.|
|||TRUSTED_SOURCES|N.A.|
|||UNTRUSTED_SOURCES|N.A.|
|Runtime opaque||ENCRYPTED_MEMORY_RUNTIME|If platform appraisal is successful, the value for this can be copied from platform|
|||ISOLATED_MEMORY_RUNTIME|ditto|
|||VISIBLE_MEMORY_RUNTIME|ditto|
|(persistent) Storage opaque||HW_KEYS_ENCRYPTED_SECRETS|TBD[^4]|
|||SW_KEYS_ENCRYPTED_SECRETS|ditto|
|||UNENCRYPTED_SECRETS|ditto|

[^4]: SimonF: The AR4SI spec has a slight config here: the intro says 'capable of encrypting persistent storage' but the values says that that this storage is specific to secrets. If we take the view this is just secrets centric then the presence of a HES should imply HW protection. If a mechanism for general persistent storage, then we're in Impdep territory.
ThomasF: For context, AR4SI references https://www.gsma.com/newsroom/wp-content/uploads/2012/03/omtpadvancedtrustedenvironmentomtptr1v11.pdf#page=53 which seems to have the mobile segment as primary scope, and a very specific idea of what "opaque storage" means (quite similar to PSA secure storage BTW). I may be off but it looks like the gist is the protection of user secrets rather than platform secrets? If so, what can be deduced from evidence about the feature being available to Realms? If it's IMPDEP then we could just say that this bucket is N.A. unless a verifier is intimate with the implementation.