veraison / corim

CoRIM and CoMID manipulation library and CLI

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!

corim's Issues

merge the lint targets into one

We need to merge the "extra" lint target into the "normal" one as we've have done for other packages.
All lint errors must be addressed, either changing the code or suppressing them (when there's a good reason to do so).

increase test coverage for CoTS

Carl's #62 has added CoTS support. Test coverage is below the current threshold and therefore cannot be merged directly into main.

This issue tracks the development of additional tests in the CoTS area.

BUG: “cocli corim sign” tool does not work with a key curve P-384

“cocli corim sign” tool does not work with a key curve P-384. It throws below error:

Error: error loading signing key from ec-p384.jwk: unknown elliptic curve {0xc00007e400}

The ec-p384.jwk file is as below:
{
"kty": "EC",
"d": "XiZ_ZEDMw3Hr9BjNc_4qbNxMG6VpkFHTN3KcdT1UlOc51pFwS1t6Yg_aFYJTGMBf",
"use": "sig",
"crv": "P-384",
"x": "Ay-c_vlONI_FNQn4PNHXwEswuoxOTqOEHNIQbSKv5OnC_KBLwAbg5uBQRHCRmFnu",
"y": "mJpRrG-ex0R08heh1qm-osCH7SSTKC1Bjx1SrFpUQZCiYQXdPLIokC0DGRAMYq41",
"alg": "ES384"
}

Extend Eat to have the additional claims in EatCWTClaim

Currently ConciseTaStore depends on EatCWTClaim where EatCWTClaim had four additional fields needed in this context. The four additional fields are named: HardwareModelLabel, HardwareVersionScheme, SoftwareNameLabel, SoftwareVersionScheme.

The original Eat{} situated in veraison/eat, should be extended to include these four additional fields and EatCWTClaim should be made obsolete. This will result in ConciseTaStore depending on the original Eat{} object in veraison/eat

Remove CoMID package depedency on CoSWID for any identifiers

Current code reflects inside CoMID package:

type TagIdentity struct {
TagID swid.TagID cbor:"0,keyasint" json:"id"

---

This is not required, as such and needs tidy up!

update `cocli` docs to reflect CoTS support

When done, bump the patch number (i.e., release v1.1.1)

Cleanup Unsigned CoRIM Container

Unsigned CoRIM has a profile field to set a specific implementation of CoRIM/CoMID using a Profile.

This github issue tracks the introduction of profile.

Correct PSA CoRIM Template to include only 1 profile

The corim-full.json template currently uses two different profiles. This needs to be change to a single profile (ie. http://arm.com/psa/iot/1) as two profiles are no longer supported.

document the cocli template format

There has to be clear documentation around the template format used by:

• CoRIM
• Meta
• CoMID
• (Co)SWID

Visual Synopsis of the Available Commands diagram should appear sooner

The cocli readme has a synopsis diagram that should appear sooner (near the top) of the readme.

Add Concise Evidence support

https://github.com/TrustedComputingGroup/concise-evidence is based on CoRIM.

The structure of Concise Evidence is directly symmetric to the CoRIM structure (as it reuses the CoRIM CDDL definitions).
Corresponding Appraisal Procedures for Evidence can be boiled down to a minimum set of code that has to be implemented and would match the appraisal guidance that will come with CoRIM's default profile (DICE), PSA Endorsements, and future profiles.

Adding Concise Evidence support seems to be a quite low hanging fruit and provides an convenient alternative option to EAT in cases where Attester composition becomes a bit more complex.

Suggest a better name for CoCli

CoCli should be renamed!

Add interface to allow user provided extensions

Problem Statement:

Present Implementation of Base CoRIM and CoMID has PSA specific types embedded into the base types.
One example is the Environment Type which has a Class Identifier object inside it.
One type of Class Identifier is the PSA Specific Implementation ID, which is PSA specific.
The issue it raises it:

1. Now any external library user uses the Class ID object will get the PSA specific Implementation ID as part of
   the library implementation, which is not required.

2. Any new user of CoRIM, CoMID library, if they have their own ID types, will eventually pollute the library with their own types.

Solution

1. Create Generic Objects (like Class types) which has ONLY the base types (like OID and UUID).
2. Provide mechanism for adding dynamic types from the caller with API's for:

a. Registration
b. Validator
c. Getter and Setter.
d. JSON and CBOR encoder and decoder

Additional context

None

Cocli tool visual representation needs cocli corim submit sub command

Cocli README.md

Section: Visual Synopsis of the Available Commands
does not depict cocli corim submit sub command

Need to enhance the picture to reflect this addition

create a picture of the cocli processing pipeline

create a picture of the cocli processing pipeline

Add CI support for forked repositories for corim

Add necessary support that the repositories forked from corim can trigger automatic CI

Add CoSWID template

It would be useful to have a CoSWID JSON template representing the structure of CoSWID. This template can be used in a future extension of the cocli tool that can manipulate CoSWIDs

Restructuring the documentation of CoCli

I am suggesting to make two changes to the documentation here:
https://github.com/veraison/corim/tree/main/cocli

1. Provide a high-level description upfront. A simplified version of this figure will do it: https://github.com/veraison/corim/tree/main/cocli#visual-synopsis-of-the-available-commands
2. In the command line examples use the data from the data directory. Currently, the command line examples use fictitious file names.

#99 goes into this direction

Could owner give some requirements before build ? I have no idea where to start

1. OS
2. tool list need to intall before run this
3. how to build

Add command line interface

Add a CLI that can be used to:

• create CoMIDs from a (JSON?) template
• create (unsigned) CoRIMs from a template and the file-system location of child CoMIDs and CoSWIDs
• validate CoMID
• validate CoRIM
• sign CoRIMs
• verify CoRIMs
• display CoRIMs content (as JSON)
• display CoMIDs content (as JSON)
• save CoMIDs and CoSWIDs embedded in a CoRIM to a directory as separate files

Create Meaningful semantics for svn and min-svn tag in json

Enhance Unit Tests coverage for internal CoMID Elements

The following structure elements within CoMID does not have Unit tests:

1. uuid.go
2. svn.go
3. ueid.go
4. rawvalue.go
5. instance.go
6. group.go

add support for tagged OID to `$measured-element-type-choice`'s

$measured-element-type-choice should also support tagged OIDs.

`cocli corim display` should be able to process unsigned CoRIMs too

If I try to use cocli to display an unsigned CoRIM:

> cocli corim display -f my-unsigned-corim.cbor -v

I get: "Error: error decoding signed CoRIM from my-unsigned-corim.cbor: failed CBOR decoding for COSE-Sign1 signed CoRIM: cbor: cannot unmarshal map into Go value of type cbor.RawTag"

Introduce Unit tests for MKey PSA refval-id and UUID

Introduce Unit tests for MKey PSA refval-id and UUID
Currently Marshal/UnMarshal, JSON/CBOR Negative tests and also specific Positive unit tests are missing from the CoRIM Repository!

This issue tracks the lack of tests!

is key-id mandatory?

Track the outcome of the discussion around this issue: ietf-rats/ietf-corim-cddl#131 and adjust code accordingly. At the moment, the implementation does not treat key-id as mandatory.

Is CoRIM appropriate for TDX and SEV-SNP?

Hi y'all, I've been looking into CoRIM as a way we might endorse guest firmware for a confidential VM in a way that is usable across both TDX and SEV-SNP, hopefully more technologies in the future. I haven't seen anyone publicly say we should use CoRIM for VM firmware, but it seems the closest standard.

My understanding is that TCG RIM and IETF CoRIM come from the physical machine attestation space, and not virtual machine attestation. I don't see CoMID being useful for CVMs for instance, since guests will be able to request certificates directly from the hardware in their TCB in the future. We're then left with CoRIM as a wrapper for a singular CoSWID for the guest firmware, plus the CoRIM's security version number.

SEV-SNP already has the IDBlock to attest to the fact that the firmware is signed by the party, and has a certain security version number. TDX doesn't have anything similar, but we could use MROWNER to at least indicate the firmware vendor for where a user could download a certificate, named by the MRTD value.

So I'm left with a bit of a struggle with the weight of this format as compared to, say, just generating a throw-away public key and signing an X.509 certificate with information we want about firmware in an x509v3 extension. Basically we'd just have the firmware measurement and the security version number. That format could work very simply in existing code ecosystems that don't already support a new RFC like COSE. It's kind of against NIST SP 800-155 section 3.2.2.4's call for an open standard for firmware integrity, but with publication of the format, it might be open enough.

Update operational flags to the new format

The operational flags type is not a bit-mask anymore. See ietf-rats/ietf-corim-cddl#175 for the details.

Cocli Tool: Introduce CCA Template for CoRIM

This issue tracks the introduction of CCA CoRIM Template file
under: https://github.com/veraison/corim/tree/main/cocli/data/templates

In addition to this this issue also corrects one bug in the CCA CoMID Ref Val Template

Provide a minimal implementation that allows provisioning PSA endorsements

A minimalist implementation of CoRIM / CoMID that can be used to ship PSA endorsements.

In particular, we need CBOR encoding and decoding, JSON encoding to ease creation of CoRIM/CoMID by humans.

Obviously, also all the PSA extension points and enough API surface to make it easy to extract PSA endorsements from CoRIM/CoMID.

Bug: cocli corim display

cocli corim display on a signed corim creates a json and prints "Meta:" and "CoRIM:" in https://github.com/veraison/corim/blob/main/cocli/cmd/corimDisplay.go#L88 and later.

This causes a problem when parsing the JSON file output through python or command line, and appears to be a non-conforming JSON.
Can you confirm this is a bug? and perhaps fix it?

Similarly cocli comid display also outputs the file name with >> at the top of the JSON file and makes it difficult to parse.

raw-value has been redefined as extensible

Another spec change that needs to be reflected in the implementation:

• ietf-rats/ietf-corim-cddl#125

Enhance coverage of CoRIM repo to 84.4%

Once PR #34 is submitted, the coverage is increased to 84.4.

Now so this issue tracks the change to be made in the ci file.

Validate binary MAC and IP addresses

The Valid method for the Measurement type has this comment:

// TODO(tho) MAC addr & friends

We need to check whether this still applies, and in that case provide validation code for MAC and IP addresses.

`cocli`'s default config file should be `${HOME}/.cocli`

Currently the default config file is ${HOME}/.cli. We should make it ${HOME}/.cocli

Factor out common code

Factor out common code in a corim/common package

Originally posted by @thomas-fossati in #7 (comment)

Correct the bug in the help output of all cocli commands

During cocli corim submit command testing a major bug is seen in the help output of all the comid and corim cocli commands.

The Long help output indicates command as cli, whereas the actual command is cocli.
Example:
cli comid create --template=t1.json
--template=t2.json
--template-dir=templates

Should be corrected to:
cocli comid create --template=t1.json
--template=t2.json
--template-dir=templates

Pull in spec updates

These two changes need to be reflected in the implementation:

• ietf-rats/ietf-corim-cddl#129
• ietf-rats/ietf-corim-cddl#130

CCA "config ID" is not an identifier

Two notes on the current implementation of CCA config claim:

• Semantically, this claim is not an identifier, it's just a dump of the config register that describes the CCA features.
• The type should be bytes rather than string (see §A7.2.3.2.5 of the RMM spec).

Add a `submit` subcommand to `cocli`

Add a submit sub-command to corim command in cocli that uses veraison/apiclient to supply a CoRIM to the provisioning interface of the verifier.

Something like:

cocli corim submit \
    --corim-file <CoRIM file> \
    --api-server <URI of the endorsement API server> \
    --media-type <media type associated with CoRIM file> 

add support for tagged integer type to $class-id-type-choice

Align Class-id to reflect the correct CDDL Schema as per:

https://github.com/ietf-rats/ietf-corim-cddl/blob/main/concise-mid-tag.cddl

UUID MKey should handle the (special) nil value

The IMkeyFactory requires every implementation to

// [...] accept nil as one of the inputs, and return the Zero value for
// implemented type.

Currently, the UUID implementation does not handle nil, which results in unmarshalling errors.

Interfaces for adding binary CoMID and CoSWIDs

Add new interfaces for adding raw CoMID and CoSWIDs to an UnsignedCorim.

There should be a knob to control the validation on the supplied CBOR. Default should probably be "on".

top-level README should clearly describe the content of the repo

$title

CoRIM need to upgrade dependent jwx package to a newer version

CoRIM uses jwx package.

https://lestrrat-go/jwx package needs to be upgraded from v.1.2.x to
https://lestrrat-go/jwx/v2 v2.x to be compatible with veraison/services and other repositories.

Bug: Missing 'name' field in CoMID measurement-values-map

Mval struct does not contain the ‘name’ field in it.
TCG document ([https://trustedcomputinggroup.org/wp-content/uploads/TCG-Endorsement-Architecture-for-Devices-r38_5May22.pdf] "section 5.5.3.1.12 measurement-values-map" lists the fields to be kept in measurement-values-map. It contains "name" field. Same is not reflected in [https://github.com/veraison/corim/blob/9a7830b4a3c319a5e0d5f14c986c828f8417a158/comid/measurement.go#L166]

Due to this, cocli does not support/add the name field while generating comid.cbor even if we manually add a name field in comid.json.

Add tagged-int-type into CoRIM

This issue tracks the addition of introducing tagged-int-type into the comid code base.

One specific type of class identifier is tagged integer.

Define CCA Specific Tagged values for Reference Values and Class Variables

At the moment, CCA Endorsements uses psa.implID and psa.refvalID for constructing JSON Endorsements.

Need to define new tag code points for their equivalent CCA representations, so that supply chain could model the
cca.implID & cca.refvalID for the same!

Create a New Release for `CoRIM` package

This issue tracks the following:

1. Create a new release V1.2.1 for the CoRIM Package
2. Modify existing cocli templates to align with the new release
3. Verify it works with the latest on veraison/services

add support for COSE signed CoRIM

add data types & APIs to support signed-corim (i.e., COSE-Sign1 around unsigned-corim-map)