[Presentation] Rekor tamper-resist ledgar

lumjjb commented 3 years ago

Title: What is the title of your presentation?

Introduction to Rekor project

Speakers: Who will be presenting this? List names/github IDs of presenters.

@lukehinds @dlorenc @bobcallaway

Description: Describe in a short paragraph what the presentation is about.

https://github.com/projectrekor/rekor-server

Rekor's goals are to provide an immutable tamper resistant ledger of metadata generated within a software project or supply chain. Rekor would enable software maintainers and build systems to submit signed digests to an immutable record. Other parties can then query said metadata to enable them to make informed decisions on trust and nonrepudiation of an object's lifecycle, based on signed metadata stored within a tamper proof binary (merkle) tree.

Time: How long will the presentation take? (estimate)

40 mins

Availability: What is the availability times of the speakers to present the topic? Meeting times are listed on the landing page.

Aiming for sometime in January

TO DO

[x] SIG Representative - @lumjjb
[x] Schedule date - 1/20/2020

lukehinds commented 3 years ago

Server and code are consolidated into this repo now: https://github.com/projectrekor/rekor

joshuagl commented 3 years ago

I'd like to understand how Rekor compares to/differs from https://github.com/transparencylog/tl ?

lukehinds commented 3 years ago

I'd like to understand how Rekor compares to/differs from https://github.com/transparencylog/tl ?

Sorry for late reply.

We spoke a fair amount with Brandon Philips about his project and the direction we both had planned..

With transparencylog/tl the key capture points are the URL and an associated artefact (digest). It provides a wget / curl style tool to both retrieve the artefact , perform a look up in the TL and check its digest. For rekor we don't have a specific use case, we are a backend as such with an open API - we record configurable manifests / provenance data and make this data easily used by application developers (so an app like transparencylog/tl could be an app that uses rekor) - more on this later.

So further to the above rekor provides what we term plug-able types (provenance layouts). Users can then create their own provenance formats to capture what is important to them . The only requirement that we have is everything sent to rekor is somehow signed, so this way we have non-repudiation. Example layouts could be in-toto, sbom , OCI etc (Santiago from in-toto is seeking to collaborate with us and is advising post-grads to work on rekor)

{
    "type": "my_type",
    "version": "0.1",
    "spec": "https://github.com/example/specs/my_spec.txt",
    "body": {
        "URL": "https://example/release/my_release.tar.gz",
        "SHA": "83jfj8we89903uhejw88…",
        "PublicKey": {
            "type": "minisign",
            "version": "v1",
            "body": {
                "signature": "foo"
            }
        },
        "Signature": "SIGNATURE",
        "ExtraData": {
            "type": "my-extra-data",
            "version": "bar",
            "body": {
                "build-system": "foo",
                "compiler-version": "bar"
            }
        }
   }
}

body would allow someone to set their own provenance fields - rekor would then map this to a plug-able type which can then extract the version and the body and make entries into the transparency log.

So key to this, is that Rekor itself does not drive a specific use case like transparencylog/tl. It seeks to make it easier to implement a running transparency log and extend it to work with the data they feel needs capturing. The project provides an openapi making it relatively simple to interface with a transparency log without having to code inclusion proofs, signed tree heads yada, yada. They can just call simple rekor apis (add, get, verify etc).

A running log can then be openly used by other systems as a source of truth...

To give one of few examples, someone could create a website (like haveibeenpwned.com) - where users can submit their public key and email address. This site can then monitor a log(s) for entries of signed "things" - if they see a registered user's public key appear in the t-log, the site emails the user. The user then may well just delete the email "meh, I just made a release of acme project, tell me something I don't know!", however there may be instances where they have not signed a certain artefact, which could then be indicative of a stolen key. Another example, an ex maintainer(s) key(s), aka might pop up and sign a release and perform a targeted attack. This is similar in a way to certificate transparency, signed certificates are logged to the certificate transparency log and Google , Facebook etc monitor for instances of certs being signed against their domain(s).

So with rekor, it is not trying to be an attestor or arbiter of trust - it's just a point of truth so to say. There is also no concept of good entries or bad entries (in fact bad entries are useful). So rekor does not seek to be a system like TUF or notary as such, it''s a transparent immutable data hub that other systems can monitor and make useful to them. Its also built upon a TL which is been put through its paces already (google/trillian), so the path to being production grade is substantially reduced.

lukehinds commented 3 years ago

One thing I should point out, we are not seeking inclusion into the CNCF (although its not been out ruled), we are more wanting to talk with SMEs in the open source community to gather feedback and foster discussions around possible collaboration.

lumjjb commented 3 years ago

@lukehinds how does January 13 or 20th sound?

lukehinds commented 3 years ago