aktualizr
aktualizr copied to clipboard
Import of an initial root.json from filesystem
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.
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).
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.
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!
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?
I'm thinking you need 1.root.json. Looking briefly, I this might be a simple change:
- Add
INvStorage::readTrustedRoot
usesImportConfig::trusted_tuf_root_path
as source - Change https://github.com/uptane/aktualizr/blob/48ba984b32f7906a6e75659c830a5b0d6ef8355e/src/libaktualizr/uptane/uptanerepository.cc#L68 to see if this file exists. If so, load it, rather than hit the server.
Is that all we are missing?
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 https://github.com/uptane/uptane-standard/issues/220 to ask this question to the greater community.