…-solution

This implements enough of the CTAP1 protocol to complete transactions, albeit with hard-coded responses that don't pass cryptographic muster.

This changes the u2f implementation around somewhat, so it no longer hard-codes
lengths of some variable length fields. It moves the crypto functions out to their
own file, ahead of implementation.

Fix reading of config zone to get all 128 bytes, split initialisation into a helper function and initial (non-working) version of genkey.

This sets up slot configs, suspected bit packing errors causing this not to work. It also exposes the lock functions in Python. Be very careful.

This allows provisioning the 108A to the point that genkey can be called, and offers helper functions for some basic funtionality. These functions can easily brick your badge, so don't run them unless  you know what you're doing. The crypto outputs haven't been verified yet.

At this stage, the critical cryptographic functions of the U2F implementation are linked in. Unfortunately, it's not yet working, currently because the signature parameters aren't parsing correctly.

I'm somewhat concerned that the fido raw message formats document specifies that cryptographic signatures are over the input bytestring, rather than the SHA-256 of that bytestring. The 108A only allows signatures of 32-byte strings, so I've gone that way. I don't think that's the problem I'm seeing yet though, I think it's a more general problem parsing.

In addition, the code is currently hard-coded to use handle 1 for attestation and handle 6 for authentication. This is because only handle 6 is set up correctly on my main test device. Handle 1 will need the keys from keys/* loaded into it - I'm aware that it's silly to put a key in git, but in this case it's not part of the trust path and we have no way of distributing the key without exposing it unless we do it in person in 2024.

No work yet on setting up the UI.

…mber.

Co-authored-by: Skyler Mansfield <[email protected]>

…ility