Skip to content
This repository has been archived by the owner on May 21, 2024. It is now read-only.

Import of an initial root.json from filesystem #1553

Open
ricardosalveti opened this issue Feb 6, 2020 · 6 comments
Open

Import of an initial root.json from filesystem #1553

ricardosalveti opened this issue Feb 6, 2020 · 6 comments

Comments

@ricardosalveti
Copy link

ricardosalveti commented Feb 6, 2020

TUF spec suggests that the client must ship with a trusted root key for each configured repository (2.1.1 - https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#2-system-overview), and I was looking on how I could import a known root.json when first starting aktualizr, but it seems that this is not currently supported.

I know we can import a CA for the TLS communication, but I wanted the trust for the root key to happen before the device was even able to reach the remote side when running for the first time. This is just to avoid issues with the initial CA used, otherwise in case it gets hacked, new devices could end up fetching and using and invalid TUF root key as a consequence.

My idea is to create the image with the root.json in it, and configure aktualizr to import from that file when running for the first time. As I'm not so familiar with the codebase yet, I'm opening this bug to see if this is indeed not supported and if it would make sense to add support for it.

@mike-sul
Copy link
Collaborator

mike-sul commented Feb 7, 2020

Aktualizr follows the so-called Trust on first use (TOFU) concept at the moment, although, there is root.json in credentials.zip which can be used for your goal (currently it's used by the garage tools/garage-deploy, garage-push).

@pattivacek
Copy link
Collaborator

Glad to hear you're interested in this! We are as well. However, currently the credentials.zip only has the root metadata for the Image repository, and we hope to soon add the Director repository as well so that libaktualizr can import both directly and not have to rely on TOFU anymore.

@ricardosalveti
Copy link
Author

Glad to hear you're interested in this! We are as well. However, currently the credentials.zip only has the root metadata for the Image repository, and we hope to soon add the Director repository as well so that libaktualizr can import both directly and not have to rely on TOFU anymore.

Nice, good to know this is already on the roadmap then, happy to test and help reviewing if needed. Thanks!

@doanac
Copy link
Collaborator

doanac commented Nov 2, 2021

I was poking around at this today. I'm briefly looked at the spec and it didn't jump out to me. When we say "root.json", do we mean "1.root.json", $x.root.json, or 1.root.json->$x.root.json?

@doanac
Copy link
Collaborator

doanac commented Nov 3, 2021

I'm thinking you need 1.root.json. Looking briefly, I this might be a simple change:

Is that all we are missing?

@pattivacek
Copy link
Collaborator

I was poking around at this today. I'm briefly looked at the spec and it didn't jump out to me.

See https://uptane.github.io/uptane-standard/uptane-standard.html#rfc.section.5.4.1 and https://github.com/uptane/deployment-considerations/blob/master/ecus.md.

When we say "root.json", do we mean "1.root.json", $x.root.json, or 1.root.json->$x.root.json?

I would expect n.root.json. libaktualizr could copy that to root.json if necessary, but I don't know that it needs to. 1.root.json is of course fine as well, but on first run libaktualizr will have to fetch every individual version up to the latest, so you might as well start with the latest available at build-time. I could also imagine providing root.json and letting libaktualizr copy that to n.root.json.

Rereading the standard, I'm not sure why it requires the full set of metadata to be preinstalled, because if you have the Root, you can verify everything, and if it's been rotated, everything else that was preinstalled will be invalidated anyway. I've raised uptane/uptane-standard#220 to ask this question to the greater community.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants