Supporting Nitrokey FIDO2?

[jans23]

We are currently discussing adding support for Nitrokey FIDO2 into our software. The device uses a FIDO2 interface and therefore (the current) libnitrokey doesn't support it (yet). One option is to add support to libnitrokey. Another option is to introduce a separate library. Actually any 3rd party FIDO2 library may be good enough. But first of all I would like to understand if you are interested in adding support for Nitrokey FIDO2 to nitrocli.

[robinkrahl]

I’m generally open to add all Nitrokey functionalities to nitrocli that have use cases.

I’m not familiar with the FIDO2 protocol. From my understanding, FIDO2 focuses on authentication on the web. What would be nitrocli’s role in this process? Which use cases do you see?

Currently, Nitrokey devices provide either OpenPGP/OTP/PWS/… (= current nitrocli functionality) or FIDO2. Do you plan to have devices that can do both?

[szszszsz]

Great! FIDO2 could be used as a transport for own command interface too, so besides FIDO2 general features, we plan to use custom functionality.

1. Planned use cases for the Nitrokey App, which could apply here as well:
   A. Current:

   • FIDO2 - confirm genuity of the device;
   • FIDO2 life-cycle management - PIN change, factory reset;
   • FIDO2 - getter for hmac-secret;
   • firmware update (custom commands, done over FIDO2);

   B. Future (to be discussed):

   • ECC signing arbitrary data;
   • Nitrokey Webcrypt support;

2. Yes, at some point we plan to get the FIDO2 support to all Nitrokey products (except Nitrokey HSM I believe) - here is a roadmap.

[robinkrahl]

Thanks for the explanation! In that case, I think libnitrokey should at least list the FIDO2 devices and their capabilities. You don’t have to re-implement all functions in libnitrokey: If there are good (and portable) third-party implementations, it would be enough to return a handle that can be used with these implementations (serial number? USB port?). It could also make sense to create a separate library for the FIDO2 features if they are vendor-independent.

[d-e-s-o]

Thanks for bringing this topic up for discussion!

I agree that most of the functionality mentioned could have a place in nitrocli. It would be great if you kept us in the loop for high-level developments (or provide a channel for doing so).

---

Allow me to switch focus to an only tangentially related -- and yet of higher importance to me -- topic for a second. I see more and more issues (focusing on bugs, not feature requests) in libnitrokey, nitrokey-pro-firmware, and nitrokey-storage-firmware being opened but which haven't seen any progress from what I can tell. In the latter repository I am also counting four prio:high bugs on the first page alone (I am not entirely sure of the semantics of that label, but it suggests some importance to me, which in turn should warrant addressing them in a timely manner -- at least in my mental model).

My outsider's perspective (and expectation, quite frankly, being a consumer of your open source software for which I purchased a product) on this topic is that resources should be dedicated to address those over time, instead of focusing (increasingly?) on new features. I understand these probably aren't high profile business priorities that generate direct revenue. Yet, you are in a position that bug dumping grounds are more broadly visible than they are for closed source shops and buggy/unreliable foundations generally make for buggy/unreliable software built on top, which I don't think is in your interest. I am not saying it has happened yet, just pointing out a direction I believe to be seeing.

I am not actively following all the development so perhaps I am missing something, but that is the impression I got; if I have that impression chances are that more people have it or come to the same conclusion just scanning the issue lists or looking at the code. I personally am not eager to work around issues in the underlying firmware/supporting infrastructure indefinitely if no effort is being made to address them long term.

That's all I wanted to say in such an off-topic remark; thanks for reading :-)

[szszszsz]

@robinkrahl Makes sense, thank you for opinion!
@d-e-s-o Will try! I will keep in mind to CC you all the important tickets.
About channels in general: we can chat over Riot/Matrix or IRC channel (#nitrokey@freenode) as well, if you would like ask for anything.

As for the Nitrokey Storage, thank you for bringing that out. Indeed some issues are long overdue for this device, but it should not take too long these will be fixed - incidentally recently we have re-started working on the highest priority ones.
We have changed focus for some time to other projects to keep innovating and to extend the portfolio.
In general we want to be as much transparent as possible with the performance of our devices, and thus registering all the issues. The high priority ones are kept in mind to be fixed asap, with the respect to the current work plans and deadlines, to which we have committed.
Sorry for the libnitrokey delay by the way.

PS By my definition high priority tickets are issues making the device unreliable or blocking use of the main features (the label should have that description on it).

[d-e-s-o]

Sounds good, szszszsz. Is there anything else we should discuss here or can this issue be closed? I don't see any action being required.

[d-e-s-o]

Please reopen if something needs more attention.

[szszszsz]

Noted! Will make a separate ticket for Nitrokey FIDO2 integration once it will be added to the libnitrokey or its siblings.