HW crypto #18
-
Hi, |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
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 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
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. |
Beta Was this translation helpful? Give feedback.
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'scrypto-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).Reg…