This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
We're trying to bring the AES version up so we can do CBC
(required for FIDO2) but unfortunately the aes-gcm-siv crate
is locked to an outdated version of AES, and this is blocking
on a type that is missing in the `block-ciphers` crate.
For now, we're using a patched version of aes-gcm-siv from
rozbb's repo, which allows us to move forward, but this needs
to be reverted once a new version of the official crate is patched.
Also note here that we have:
- Run all the AES test vectors and confirmed the pass for both
hw and sw
- Updated the benchmark numbers for the new AES implementation
This is in a bid to gain CBC crate compatibility which requires
at least an AES 0.8 API level.
It breaks a lot of stuff, which is fixed in the next commit.
A lot of packages are depending on 0.6 api, which requires a crate
that has OS specific TRNG calls. This patch keeps the 0.5 calls
inside the TRNG crate as direct API calls, and migrates to support
a 0.6 api to a patched version of getrandom that supports Xous.
*everoyne* is relying on rand_core, a later version, that uses
a "getrandom" thing that tries to make the call for random
number generators generic.
I mean, it's kind of cool, but, it's also sort of a libc
non-pure-rust nightmare because basically it always delegates
to a C-style API for a variety of platforms.
Next step is to see if we can't...patch...getrandom to point
to a much simplified, xous-only version that is 100% pure Rust.
is_efuse_secured() comes from rootkeys, but we don't want
to expose the full rootkeys API to the world.
PDDB already has an approved capability for accessing rootkeys,
so this single API is passed through via the PDDB object here,
allowing other procesess to query it.
is_efuse_secured() comes from rootkeys, but we don't want
to expose the full rootkeys API to the world.
PDDB already has an approved capability for accessing rootkeys,
so this single API is passed through via the PDDB object here,
allowing other procesess to query it.
The vault app is the beginning of a multi-purpose authentication vault.
It will feature:
1. FIDO2 authentication
2. TOTP authenticators
3. Password storage to PDDB with auto-typing via keyboard HID
This is the first step on a very very long journey.
alright. the composite device problem is solved. The bigger issue I'm
mulling is if I should try to port the Google OpenSK FIDO2 stack into
Xous, or if I should just do a limited U2F implementation.
Poking around at the OpenSK stuff...porting looks possible, but, it's
going to be vendoring in all of the source from the OpenSK project. So
it'll be tough to apply patches if they happen; on the other hand, the
OpenSK implementation is FIDO2 certified, and the stable branch hasn't
moved since Nov 2021.
The main downsides of the OpenSK implementation are:
- it uses nightly. I think it can be stripped out, though; I haven't
seen a "good reason" for it yet, it's mostly because Tock uses
nightly. There's only one alarming use of it and it's in the crypto
crates but those will be stripped out because....
- the crypto libraries are in fact not suitable for use. I dug into
them and they definitely need to be gutted and replaced with the
community-blessed crypto libraries and APIs. which is one big reason
why once this goes into Xous land it doesn't go back easily into
OpenSK land -- they actually have slightly different crypto
APIs. more modern ones, to be fair, but, they haven't been reviewed.
- the implementation has "too many features"...for example, I don't
think we'll ever realistically do authenticator attestation as it
requires signing NDAs and provisioning secret keys that we can't
share with users. But that code is there, and we'll either have to
gut or bodge it.
The plusses are:
- it's FIDO2 certified. So, at least the protocol stack is probably
complete and fully implemented, which means for features we don't
use today I can just leave hooks or dummy values there for a fast
migration path.
- Looks like they aren't changing things too fast in the dev
branch...so this probably is not like riding a greased pig
- Looks like a couple of paid professionals wrote the code...better
than what we have going on here
- I think I see a path to carve out their "persistent store" and glom
it into the PDDB; a path to adapt their crypto traits into
Xous-native traits; and a path to connect their CTAP protocol engine
to the Xous HID server. So it seems feasible. But they baked in some
bad API assumptions deeply enough that they are one-way streets I
think to get these ports done.
I'm going to sleep on this, but I'm leaning toward trying to pull in
the OpenSK code because even tho it is a bit painful it probably gets
a bigger feature scope and so far it looks like I wouldn't be changing
any protocol-level stuff for the port, I would just be monkeying
around with the internal storage, crypto, and USB implementations, so
ideally the end result is we get a certified FIDO2 protocol engine for
the effort.
I think the main concern I have going in this direction is I don't see
a way to do this and simultaneously be able to absorb upstream patches
into this vendored code, because their API assumptions are too
different. Any bug fixes or patches would have to be manually applied
and merged. But maybe that's not such a big deal...?
Issue #159 may be caused by queueing a connection to respond to when
the timer expires, but if the timer expires twice then it tries to
respond to a null connection id.
And if it goes to suspend in the same millisecond as it services the
condvar, then it'll reissue the interrupt when it comes back from
suspend.
remaps keys based on the assumed keymap based on the user's
preference for the keyboard layout on the device.
So far, only dvorak and QWERTY are supported.
