fdo-rs / fido-device-onboard-rs Goto Github PK
View Code? Open in Web Editor NEWAn implementation of the FIDO Device Onboard (FDO) spec written in Rust.
License: BSD 3-Clause "New" or "Revised" License
An implementation of the FIDO Device Onboard (FDO) spec written in Rust.
License: BSD 3-Clause "New" or "Revised" License
Right now we allow insecure
and hash
- root cert is another option which is there but not implemented
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.
We should support having a device credential where the information is either stored in a TPM NVIndex or a TPM key.
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.
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.
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.
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
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
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).
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.
we can only use dns names today, ip addresses are defined in the spec and should be supported
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.
After #107 gets merged, we should implement the Ownership Voucher management API in the owner onboarding server.
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
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.
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 should implement Encrypt-then-MAC cryptography.
This will require support for it to be added to the COSE library.
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...
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
We should implement the Service Info API client.
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.
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.
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.
We should check for vouchers that include private keys, and if they do, try to extend them, and then re-parse.
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.
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 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.
If the to1d was not signed by the valid owner of the OV, we need to stop the full TO2 protocol.
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.
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.
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.
As the title says, for tracking purposes - building in RHEL is the target here to begin with
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
We should implement the OV mgmt API.
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.
#[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
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.
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.
For now, the parsing support only 1 OV at a time, when trying to parse a batch of OVs this won't work.
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.
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
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 check all the log levels for sanity.
We need to support PEM encoded ownership vouchers, both for writing and for reading.
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.
We should go over the code, and make sure to clean up any panic!
and todo!
macro calls throughout.
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.
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.
We should test our implementation against the Java implementation by FIDO themselves for every changes in this repo.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.