veraison / ear

Attestation Results for Secure Interaction (AR4SI) implementation

This is not the repo you're looking for

This repository is no longer in use. Various aspects of Veraison have been split into separate repositories.

If you're looking for the main Veraison services repository, you can find it here:

https://github.com/veraison/services

Please look into the the project overview on Veraison Organization for the description of how Veraison code is organized and where to look for specific things:

https://github.com/veraison

This repository is now archived!

ear's Issues

arc CLI Tool Enhancements

Now that the Veraison Extension for adding "key attestation" is introduced, the arc tool needs to be enhanced to see how a
new key can be introduced/encoded, decoded and used using the arc tool

fine-grained semantics of trust vector buckets

Add the ability to categorise the trust vector fields.

See https://www.ietf.org/archive/id/draft-ietf-rats-ar4si-03.html#section-2.3.4

add CLI

implement a CLI that allows manipulation of AR4SI tokens. Specifically:

• create
• pretty print
• verify
• sign

trustworthiness vectors colours not working

For example:

$ arc verify --alg ES256 --pkey data/pkey.json OK.jwt --color

on an xterm-256color terminal produces:

>> "OK.jwt" signature successfully verified using "data/pkey.json"
[claims-set]
{
  "ear.status": "affirming",
  "eat_profile": "tag:github.com/veraison/ar4si,2022-10-17",
  "ear.trustworthiness-vector": {
    "instance-identity": 2,
    "configuration": 2,
    "executables": 3,
    "file-system": 2,
    "hardware": 2,
    "runtime-opaque": 2,
    "storage-opaque": 2,
    "sourced-data": 2
  },
  "ear.raw-evidence": "3q2+7w==",
  "iat": 1666091373,
  "ear.appraisal-policy-id": "https://veraison.example/policy/1/60a0068d"
}
[trustworthiness vector]
Instance Identity [\033[42maffirming\033[0m]: recognized and not compromised
Configuration [\033[42maffirming\033[0m]: all recognized and approved
Executables [\033[42maffirming\033[0m]: recognized and approved boot-time
File System [\033[42maffirming\033[0m]: all recognized and approved
Hardware [\033[42maffirming\033[0m]: genuine
Runtime Opaque [\033[42maffirming\033[0m]: memory encryption
Storage Opaque [\033[42maffirming\033[0m]: encrypted secrets with HW-backed keys
Sourced Data [\033[42maffirming\033[0m]: from attesters in the affirming tier

Key attestation `akpub` setter/getter

In contrast to annotated-evidence and policy-claims, we know exactly the internal structure of the key-attestation extension, and therefore it makes sense to expose explicit get/set methods. e.g.:

func (o *AppraisalExtensions) SetKeyAttestation(pk any) error {/* ... */}
func (o AppraisalExtensions) GetKeyAttestation() (any, error) {/* ... */}

TEEP support

Context: TEEP draft

Add support TEEP claims as extensions to the base AttestationResult object.

See also veraison/docs#21

support for composite attesters

This issue tracks the implementation of the design that will be produced as a result of thomas-fossati/draft-ear#10

Embedded documentation out of sync

@THS-on noted that the example code in doc.go is out of sync.

JWT specific checks

We use JWS at the moment to work around the API limitations and be able to manipulate the claims set freely. That means we don't do anything "JWT specific" (e.g., adding mandatory or recommended headers, checking mandatory headers, etc.) We need to go through the relevant bits of RFC7519 and see if there's anything to add to Sign() and Verify().

error when verifying EAR due to raw evidence

Verification of EAR with raw evidence leads to the following error:
"Error: verifying signed EAR from my-ear.jwt: invalid values(s) for 'ear.raw-evidence'"

input claims: https://github.com/veraison/ear/blob/main/arc/data/ear-claims-tv-ok.json

docs

• add a docs.go file with example code
• add instructions on how to use the API
• add missing godoc comments

basic implementation

Implement:

• JSON serialisation
• JWT signing and verifying
• Veraison-specific extensions

EAT-ify

• Add mandatory eat_profile claim (+ mint a reasonable value)
• Reuse standard JWT claims as much as possible (e.g., use iat rather than timestamp)
• Explicit namespace for the claims we introduce (for example prefixing with ar4si., ar. or similar
• Align docs/datamodels/attestation-results

(The latter is a task in the veraison/docs repo.)

add CWT serialisation

As per discussion with @dthaler at the IETF hackathon.