i've extracted the key parameters from the test suite and confirmed that
that the hash value is computed correctly on their side.
i've also confirmed that the hash value is computed correctly from
the locally computed key.
so what's gone wrong is the devired secret key doesn't match what's
on the other side.
possible issues could be either a PK serialization issue, or something
wrong in the DH exchange itself.
trying to debug why PIN authentication doesn't work. looks like
Cosekey conversion is fine, the data is arriving OK...but the
dh key exchange is not generated the expected shared secret.
Had two JSON entries with the same key, which meant you had
a 50/50 chance of a rebuild being triggered depending on which
entry was picked for the build. :-/
The OpenSK UX layer was completely gutted and re-written using
Xous-native idioms. There's a bit of ambiguity on what exactly
OpenSK meant to do with the one button and the LEDs, but for
Xous we want to show things like what you're signing for and
why.
For now, we just show the app hash during registration and signing,
but down the road that will need to be matched up against a
plaintext description of the application upon registration, so
users can have a client-side description of what they are approving.
At the moment, we're stuck at provisioning the attestation certificate
and key. The transaction goes through, but is rejected by the
test web site right now with not too much explanation of what went
wrong, but maybe the next step is to try and use the OpenSK
native tools to provision a set of keys onto the device to see
if that fixes it (instead of the current bodge of hard-coding
some manually extracted hex values into the database).
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>
the implementation uses an explicitly expanded key schedule for
every AES key, with separate enc/dec keys. This does save setting
up the key scheduler every time, but, it also breaks a lot of API
assumptions. Since we have the performance to afford the key
setup/teardown for every call, this commit basically turns
the key refs into actual slices of the key itself. This creates
a weird bit of code where you have an enc key being equated to
a dec key directly; those lines are left in to make it a bit easier
to diff against the original source.
But the high bit is that the original implementation, by expanding
the key scheduler, had to have a different enc and dec key schedule
(even tho they come from the same key) but this compacted form
makes them identical.
This commit also starts working in at converting the PersistentStore
to use the PDDB.
I think I basically understand the scope of the problem, and it's
mostly just some grunt recoding of the PersistentStore calls
to refer to PDDB entries by k/v names. The main thing I've done
so far is to recode the macro that creates the partitions in
OpenSK to just create string names for every item that needs
to be stored. These string names will be used to index into a dictionary
that is dedicated to the FIDO2 function.
