HW crypto

[arturkow2000]

Hi,
We would like to use HW cryptography in our project. Do you plan to add support for it or maybe add RSA support (as we cannot use ED25519 in our project)? We are eager to contribute but do not know what the plans are for this project. Could you give some pointers?

[nickray]

Hi,

First on topic of RSA: this will definitely be needed short to mid-term anyway. Generally, we've tried to stick with RustCrypto wherever possible, but for asymmetric algorithms we've had to "roll our own", given the second goal to stick with "pure Rust" implementations (with an exception for assembly in the inner loop): P256, 25519. The current situation is that RustCrypto RSA is not no_std, mainly due to the BigInt implementation. Tony's crypto-bigint should fix this in the mid term. Independently (and predating crypto-bigint), I worked on a Cortex-M4 implementation https://github.com/ycrypto/rsa-cortex-m4, which is "done" except for prime generation (but not tested nor audited).

Regarding HW crypto: There is an ongoing project (out of TU Berlin) to use the NXP SE050 secure element as crypto backend (in combination with an NXP LPC55S69). The approach we are planning to follow is to lift the

pub fn reply_to(&mut self, client_id: PathBuf, request: &Request) -> Result<Reply, Error> 

method out of service.rs, add a parameter to specify the backend, and then have the Trussed service further dispatch to the appropriate backend, which would implement a subset of the Request/Reply RPC.

This is connected to #19, as we'll need an ergonomic way to specify what all should be compiled + offered to client Trussed apps. Besides allowing HW backends, it should also allow easily switching out SW backends (e.g. from my favoured "pure Rust" approach to say a wrapped MIRACL).

Also related is a further plan (once the basic request -> backend dispatch exists) to implement some core user/admin authentication functionality in Trussed. Namely, it's traditional to have a "user PIN" that must be entered to use certain keys, or have an "admin PIN" ("security officer") to administer the device settings. First, it would be convenient to have this by default, so apps can use it vs. implementing themselves (in the way that e.g. PIV allows delegation to an "ambient" system's PIN). Second, if the keys are protected on a secure element, then it also makes sense for the corresponding PIN to be protected by the secure element; implying that apps should not directly manipulate or control PINs and authentication status, so Trussed service would have to do it.

[alt3r-3go]

@nickray, one minor note - RSA lib actually does no_std just fine, I've been able to compile and run their test suite and my own test app on nRF52832. It does require alloc though and the only working allocator for M4 requires nightly Rust (last I checked several months ago), otherwise it does work.

Speaking of that library, in communication with Jan and the Nitrokey team, I've been (slowly, lack of time, alas) working on integrating it into Trussed and while there's still quite a set of TODOs to handle, I'll probably be sending a [WIP] PR in the nearest week or two to start the official discussion going.

[nickray]

We should discuss this if that is your plan, as alloc is not acceptable in Trussed, at least not in default/mainstream backend -- we won't be using nightly Rust. I think your efforts would be better spent porting prime number generation to https://github.com/ycrypto/rsa-cortex-m4 (which should be not that hard). Of course, Nitrokey can do as they wish in this regard :)

[arturkow2000]

Won't it be better to port RustCrypto RSA to heapless? There is already some discussion about that RustCrypto/RSA#51.

[nickray]

Yes, I hope that happens eventually.

[alt3r-3go]

@nickray, ok, thanks for the reply and to avoid hijacking this Discussion any more, I've started a thread in Trussed Matrix chat, I guess that's a better place (or please let me know).