This is an "request for comments"-type PR to invite a discussion and iron out the details of the RSA library integration.

Context

We've discussed this with the Nitrokey team a while ago (around the end of 2021) and I took a stab at it, then it got paused for several months after this discussion we additionally had with @nickray. Recently @daringer suggested we move ahead anyway, probably in a form of an NK-specific temporary fork, while those TIPs are getting written/implemented. AFAIU this is driven by the desire to have an RSA implementation for NK3, so at least some working solution is valued higher than the ideal one we discussed in that Matrix chat.

Implemented now

RSA2K-PKCS_v1.5 signing/verification and the whole necessary set of helper traits (DeriveKey, etc) + tests for them, that work on a PC. I separately was able to run Trussed and the RSA lib's full set of tests on my nRF52832, but haven't yet tried both of them at once.

Caveats

The PR is still well WIP and has items to discuss (marked as TODO:alt3r-3go in the code). I've based the general approach on the miracl one (#12) and that proved to be quite useful, so kudos to @nickray for such a nice example. Due to one of the TODOs related to the test infra, tests need to be run one by one for now, at the bottom of this description I'm showing a simple script that can be used for that. I haven't included it into the code, but let me know if it's helpful until I close the TODO.

All comments, big and small, as well as suggestions on the TODOs are more than welcome.

Testing script

#!/bin/bash

set -e
set -x

clear && RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_sign_verify -- --nocapture --show-output
RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_generate -- --nocapture --show-output
RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_derive -- --nocapture --show-output
RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_exists -- --nocapture --show-output
RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_serialize -- --nocapture --show-output
RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_deserialize -- --nocapture --show-output
RUST_BACKTRACE=1 cargo test --test rsa2kpkcs rsa2kpkcs_sign_verify -- --nocapture --show-output

Draft solution for injecting any key material with the specified kind to the Trussed system. Such is required for Nitrokey Webcrypt and OpenPGP implementations.

Requesting for comments.

This modification changes the API by adding a new parameter to unsafe_inject_shared_key, and the name of the function does not seem to be apt for that as well . Ideas for improvements:

• add "imported" attribute to the key, allowing to identify it when used with security critical functions;
• use separate function in API to not break other clients' uses (revive unsafe_inject_key ?).

Quick use case example:

• https://github.com/Nitrokey/nitrokey-webcrypt-rust/blob/6d20c06a1833d496fd4e5c041e7fb8f248e9545a/src/lib/commands.rs#L810-L817

This PR follows what was discussed in https://github.com/trussed-dev/trussed/discussions/36.

There are two issues to solve:

• [ ] Migrations: Already created public keys will have the EXTRACTABLE flag off by default, when it should be set, otherwise it will not be possible to serialize them.
• [ ] What mechanism should be used to serialize a symmetric key?

This patch adds a virt feature and module with a virtual platform implementation. This platform uses a basic user interface implementation and RAM storage. It makes it easy to run tests without having to implement all required Trussed components. As the TrussedInterchange and the RAM storage cannot be used concurrently, a mutex is used to protect the platform.

This is based on the platform that was already used in Trussed’s tests (tests/card/mod.rs).

This PR depends on #28 because of lifetime issues.

This PR fixes key type confusions that could happen previously. Because many symmetric operations didn't check the Kind of the key they used, it was possible to use an ECC key for HMAC or AES.

This PR also prevents using Shared as a key unless it's been through DeriveKey. I don't think this breaks anything deployed (I checked for fido-authenticator.

I also find it weird that unsafe_inject_shared_secret yields a key of Kind::Shared IMO it should be Symmetric so that it can be used for symmetric cryptography. I feel like right now the distinction between Kind::Shared and Kind::Symmetric doesn't bring anything.

This PR runs cargo-fmt on trussed.

This creates conflicts with other branches but they can be solved with some bits of git magic. There is a rebased branch for #29 at here

In #38 [0], we restricted the operations for the hmacsha256 mechanism to symmetric and shared keys. This breaks fido-authenticator because it uses hmacsha256 derive_key on EC keys [1]. This patch relaxes the restrictions to allow all key kinds.

[0] https://github.com/trussed-dev/trussed/pull/38 [1] https://github.com/solokeys/fido-authenticator/issues/21

cc @sosthene-nitrokey: I can’t add you as a reviewer, but please have a look.

• patch solo2 using patch.crate-io after checkout
• don't patch nitrokey-3-firmware for now, as its current upstream uses Nitrokey's trussed git already, change back later
• checking out multiple repos failed with actions/checkout@v2 might be an issue with act, no problem or issue would keep it that way so it's locally testable

This patch adds the UiClient::wink method that triggers a visible or audible response of the device, allowing the user to identify it. This is for example needed to implement the CTAPHID wink command.

This method is similar to try_as_new_client except the resulting ClientImplementation owns the Service. This makes it 'static which is useful in many cases.

This required also implementing Syscall for Service (it was previously only implemented for &mut Service.

Awesome work on Trussed and Solo Keys. 😄

I cloned the repo and found the tests wouldn't build. I've made changes to fix this in the most obvious way, and verified that the tests are still passing on my machine.

This is a first, fully functional prototype for #32 - The following two PRs are required for this PR:

• basic multi backend functionality: https://github.com/trussed-dev/trussed/pull/41
• KeyStore consistency change: https://github.com/trussed-dev/trussed/pull/55

Example of a runner introducing multiple backends for Trussed: https://github.com/Nitrokey/nitrokey-3-firmware/tree/sw-auth

Example client app which demonstrates pin handling & policy enforcement for key access: https://github.com/daringer/playground-app/tree/sw-auth

more details will follow...

Based on the HmacSha256 implementation - the only difference is, that the result is stored as a P256 key, instead of a shared variant.

As discussed, it would be best in the future to introduce shared implementation across different combinations of hash and resulting key algorithms.

Requesting for comments / solution suggestions.

Improvement ideas:

• Provide a way to connect multiple mechanisms together, without copying the implementation like in this case.

Current downsides:

• supplied implementation is almost a verbatim copy of HmacSha256.

To do:

• [ ] change the algorithm to seed-based Ed25519 instead
• [ ] make sure the generated keys are correct - apply proper checks

This adds the structure to allow multiple service backends. Essentially the client now has the possibility to choose a order-of-dispatch in its ClientContext. This is an elementary step towards transparent hardware crypto devices like the se050.

• Extend ClientId to be a proper struct and call it make it a ClientContext (as the name suggests)
• Fix several concurrency issues during directory traversal using the ClientContext instead of a quasi-global
• extend all necessary components and reply_to dispatching based on client-chosen service backends

The miracl/core library is an option to provide implementations of a wider range of (non-core) algorithms in Trussed.

While the implementations are definitely "C translated to Rust", and likely not very speedy

• it's good to have a wide range of algorithms at least for testing purposes
• this can be a test-bed for how we want to implement "configurable algorithms with configurable backends".

Adding to solo2 in Trussed adds 14.9K code, 9.9K from miracl32.