Proposal: note/occurrence signing

[skelterjohn]

We should allow notes and occurrences to be signed. The server implementation should verify these signatures and reject if they are invalid. Notes can specify accepted keys, and occurrences attached to those notes must be signed with at least one of the accepted keys (and the server should reject the occurrence without one of the signatures).

Specifics

Notes and occurrences both get a top-level repeated string field signatures. The data to be signed will be the JSON string representation of the note or occurrence, minus the signatures field, with no indentation or newlines, and with object keys in alphabetical order. (perhaps use the proto bytes instead?)

Notes get a top-level accepted_keys field. Any occurrence attached to a note with an accepted_keys field must have a signature from at least one of the given keys - if the signature is not present in a new occurrence, the server will reject the occurrence.

Rationale

In the GoogleCloudPlatform-hosted version of Grafeas, the Container Analysis API, we rely on IAM permissions to assert sources of truth. For instance, the Container Analysis team asserts (and enforces via IAM) that the vulnerability notes in the "goog-vulnz" project can be relied upon.

We need something like that for Grafeas, and it would be very nice if that solution were general to any implementation without relying on an as-yet-unknown on-prem IAM service.

Management and distribution of private keys, while totally non-trivial, is a well-established problem with many acceptable solutions. By incorporating signing and occ-must-be-signed-by-note-key relationships into grafeas, we have a simple way to assert sources of truth, and management of keys is offloaded to some existing system.

Examples

Google publishes a public key GOOG_VULNZ_KEY through a trusted channel (eg, on a google.com website), and asserts that any vulnerability notes and occurrences will be signed with that key. Users of the hosted Grafeas service can download that key and verify that it is used to sign any vulnerability notes and occurrences.

An on-prem solution has a kubernetes deployment engine that writes deployment occurrences to their on-prem grafeas using a key that is kept within that agent. A policy enforcement agent can then verify any running deployments against the signed deployments in grafeas, and alert (or shut down) anything that doesn't have the right key signatures.

[lukebond]

Awesome. Would be great to see the implementation be sufficiently flexible to enable an integration with in-toto whereby in-toto can rely on the chain of signatures for layout verification.

[skelterjohn]

Since you mention in-toto, I should mention that this proposal is a partial step taken from discussions we have been having with the in-toto folks and a proposal they made to us for a fuller in-toto+Grafeas integration. We like the idea, and how it allows us to sidestep some of the trickier authorization questions we'd been having about on-prem Grafeas.

[SantiagoTorres]

I like this!

Notes and occurrences both get a top-level repeated string field signatures. The data to be signed will be the JSON string representation of the note or occurrence, minus the signatures field, with no indentation or newlines, and with object keys in alphabetical order. (perhaps use the proto bytes instead?)

I'd suggest using CanonicalJSON, as we do in the in-toto and TUF specifications, but anything would probably suffice.

[skelterjohn]

@SantiagoTorres thanks for taking a look. When we spoke last you mentioned something about downgrade attacks - since you don't mention it here does that mean it's not an actual concern with the strategy laid out?

[SantiagoTorres]

@SantiagoTorres thanks for taking a look. When we spoke last you mentioned something about downgrade attacks - since you don't mention it here does that mean it's not an actual concern with the strategy laid out?

yes, I'd like to add to this proposal a structure for the signature/public-key pair structures so as to avoid this.

It'd probably be good to add a list of allowed algorithms somewhere in the specification. Again, it'd be easy to copy over the in-toto/tuf suggested algorithms, as those have been reviewed in multiple security audits already...

[aysylu]

Hi @SantiagoTorres, could you please link the doc with the in-toto/tuf suggested algorithms? My search results are turning up empty.

[SantiagoTorres]

Hi, @aysylu, yes you can see them here

[bharathrajbk]

:+1: