[FlorianFranzen]

GENERATE ASYMMETRIC and the RSA arm of IMPORT ASYMMETRIC KEY used syscall!, so a trussed built without the requested mechanism (P-384 on a runner using default-mechanisms, or RSA without the RSA backend) panicked: no status word, pcscd blocked until a power cycle. Both now use try_syscall! and answer 6A80, as the app already does for an unknown algorithm byte. ECC import already handled this.

The virtual card has every mechanism, so the suite cannot hit the error path. Checked on an LPC55S69 without p384: the P-384 generate now answers 6A80 and the card keeps working.

[robin-nitrokey]

Which runner did you use to test it? A missing mechanism should be caught at compile time by the mechanism validation.

[FlorianFranzen]

I used the solo2 LPC55 runner, as I do not have any Nitrokey development hardware yet. It has no mechanism validation, so the first P-384 GENERATE panicked. Agreed that a runner with the right build check cannot get there, so I will propose the same check for solo2. Still probably does not hurt to be defensive about these kind of bugs.

And it is not the only runner with this issue. The usbip runner also has this problem, as it purposeful exempts P-384 to return an error at runtime. Tested at 3dd12e6 with --ccid: P-256 GENERATE works, P-384 GENERATE panics in generate_asymmetric_key (MechanismNotAvailable) and the device stops answering. With this PR it answers 6A80 and the card keeps working.

The red CI is the SELECT test with iso7816 0.2.2, fixed in #49.

[robin-nitrokey]

I see. I agree that we should avoid the panicking syscalls, I was just wondering how you hit the case and if there is a bug in the mechanism checks.

[sosthene-nitrokey]

Our OpenPGP implementation takes a different approach to this, it has a runtime config that can be used to disable/enable specific algorithms and features. This seems a better approach to me than making all syscalls fallible.