fdo-rs / fido-device-onboard-rs Goto Github PK

Right now, the default log level is unset.
We should make sure that this by default is set to info, so that informative things are logged.

The Nonce (and thus GUID) type assumes that the data always holds the invariant that it is exactly 16 bytes long.
This is checked by creation, but not by the Deserialize function.
So it is possible for a client to send an invalid length nonce or guid, and cause a panic! to our code.

At this moment, the client only ever uses the first URL returned in the TO1d data.
It should retry this with the different URLs retrieved from TO1d.

As the title says, for tracking purposes - building in RHEL is the target here to begin with

We should implement Encrypt-then-MAC cryptography.
This will require support for it to be added to the COSE library.

We should get a general Metadata layer on the Store, with capabilities to Query on the metadata values.
We can also make TTL a specific Metadata field.

The client does not do anything during the TO2 serviceinfo while it's processing.
At this moment, we don't have long-taking processes (yet), but this could change, so we should consider that.

We should support having a device credential where the information is either stored in a TPM NVIndex or a TPM key.

Because our integration tests just call out to the binaries, cargo doesn't know that we actually use their output.
This leads to cases where one makes a change to the system under test, and re-runs the integration test, but they still fail, because the user forgot to run cargo build.
We should figure out if it's possible to tell Rust that we use the binaries produced by the other builds.

I guess worst case we can just have the integration test common module run cargo build on start...

As a follow up of #70 we need to also ship some sort of fido-device-onboard-devel subpkg that contains libfdo_data.so (with both %version and %soversion I guess) plus a pkgconfig config (I think). Leving this out of #70 for now.

In the TO0 protocol, the to1d structure is sent without the COSE tag.
Now that the COSE crate supports it, this should be easy to fix.

Running the servers with systemd and having relative paths in configs (for things like the OV folder or sessions or keys) doesn't error out, we need to check that and mandate absolute paths

This is a follow-up from #80, where we add support for PEM encoded vouchers.
We should make sure to accept the PEM encoded version of vouchers anywhere we interact with users.

We should test our implementation against the Java implementation by FIDO themselves for every changes in this repo.

At this moment, the client just errors out locally when it encounters an error.
We should make it send the error back as per the spec.

In order to make sure that we encode exactly the same bytes on serialization as we did on deserialization, we should store the exact bytes that were used to store the tag and array size.
After this, it should be relatively easy to reproduce this.

At this moment, the client does not perform a check of the public key on the ownership voucher against the digest in the device credential.

We need to support PEM encoded ownership vouchers, both for writing and for reading.

Given that there's services and clients etc it probably makes sense considering integration into an auto fuzzing stack like OSS fuzz.
https://adalogics.com/blog/fuzzing-100-open-source-projects-with-oss-fuzz

At this moment, the client attempts TO1 once, with the very first client URL retrieved from the rendezvous info.
It should perform the constant retries on the different entries, taking the delays into account.

Right now we allow insecure and hash - root cert is another option which is there but not implemented

Right now, the Manufacturing Info string may contain newlines (for example with the Serial Number one).
This should be sanitized by the client (basically str.trim()).
The server should check that this string doesn't include whitespace or other "weird" characters.

We should implement a denylist, to ensure that if a distributor or manufacturer key gets stolen, we can stop trusting any devices that went through them.

For official interop events, we will need to support the interop dashboard protocol.
Whether this is compiled in can either be compile-time or run-time decided, with the URL and token for servers probably provided by a configuration variable.

The Owner Onboarding Service should perform TO0 regularly for the ownership vouchers under its control, to make sure that the owner doesn't have to do so manually.

At the moment, the owner tool only grabs the first rendezvous server that it finds in the voucher: https://github.com/fedora-iot/fido-device-onboard-rs/blob/main/owner-tool/src/main.rs#L813-L818

Add support for configuring dropins and allow them to override a base config (pretty much how systemd works). This makes it easier to upgrade a system (especially ostree) with a conf.d directory and 00-something.toml conf files.

#[derive(Debug, Deserialize)]
#[allow(clippy::upper_case_acronyms)]
enum RemoteTransport {
    TCP,
    TLS,
    HTTP,
    CoAP,
    HTTPS,
    CoAPS,
}

Fix the clippy warning and remember to compare against lowercase text from the configuration file when matching otherwise:

    .[0].transport: unknown variant HTTP`, expected one of Tcp, Tls, Http, CoAP, Https, CoAPS at line 2 column 14

Perhaps the trusted party for vouchers is not the first public key (manufacturer), but one of the intermediate owners.
We should verify the trusted_manufacturer_keys against all the certificates in the chain.

We should check all the log levels for sanity.

For interop dashboard integration, the client should receive its token via the fido_alliance:dev_conformance serviceinfo key.
After this is received, it should then trigger the dashboard API client (#90), and check in.

The URL should probably come from an environment variable.
I think that the client should only announce that it supports this module if that environment variable was found.

At this moment, the owner tool only uses keys (in der format) on the file system.
We should also add support for Parsec stored keys, so we can actually use keys that are for example in secure storage.

At this moment, the client ignores anything that's not a URL in the rendezvous info.
It should process e.g. the wifi setup and user input requesting.

If the to1d was not signed by the valid owner of the OV, we need to stop the full TO2 protocol.

We should check, now that we do our own KDF and no longer depend on Fedora/RHEL patches in OpenSSL, whether we can use the standard images for GitHub actions and devcontainer.
This would probably speed up CI and devcontainer building significantly.

Fedora/CentOS tests should arrive as part of Packit.

At this moment, we only use file-based keys for the servers.
We should consider also supporting keys stored by Parsec, to support many different key storage backends.

We should go over the code, and make sure to clean up any panic! and todo! macro calls throughout.

At this moment, we're just using the Rust native IP address encoding, while there's a very specific way of encoding IP addresses in the spec.

We should check for vouchers that include private keys, and if they do, try to extend them, and then re-parse.

When the Management API is available (#132), the integration test (to-tests) should make sure to use that during the TO test, instead of manually copying the Ownership Voucher into place.

For now, the parsing support only 1 OV at a time, when trying to parse a batch of OVs this won't work.

we can only use dns names today, ip addresses are defined in the spec and should be supported

Goal:
The mfg client checks whether the system has credentials in the TPM, if it does, it returns 0

Acceptance Criteria:
Check whether the device has active FDO credentials already

in libfdo_data, when we load an empty []byte - voucher isn't nil, we get panic (before the check)
https://github.com/Avielyo10/edge-api/blob/fdo-client/pkg/services/ownershipvoucher/ownershipvoucher.go#L20

After #107 gets merged, we should implement the Ownership Voucher management API in the owner onboarding server.

Today service info is part of the owner onboarding server configuration but since it's an higher level config for devices, it should be its own configuration

We should implement the OV mgmt API.

Some of the keys (specifically the Session one) may include a / (because it's base64-encoded), which doesn't work on a file system.
We should make sure we use urlsafe base64 for this (or just a string replace).

We should consider using UUID type 5 (namespace-name), with namespace given in config file, and name maybe hash of public key.
This would enable us to enforce some UUID scoping from untrusted mfg servers, to avoid an attack where someone creates an ownership voucher for a UUID of someone else's device, which would lead to a Denial of Service.

We should implement the Service Info API client.