Support for OTPs on the Nitrokey Pro?

[robinkrahl]

I’m about to write a command-line tool to generate one-time passwords on my Nitrokey Pro. I already wrote a Rust binding for libnitrokey (crate nitrokey). Before I create yet another Nitrokey CLI tool: Would you be interested in pull requests adding support for one-time password using libnitrokey? (I’m not keen on dealing with the raw hidapi communication, so that would not be an option for me.)

[d-e-s-o]

Hi Robin. In general the answer is yes, I am open to and interested in combining efforts. My main worry is that we cannot have both: raw hidapi style communication as well as integration with libnitrokey. It appears nitrokey would not quite be capable of backing the existing functionality as it stands. Do you plan on adding support to the point that nitrocli could fully migrate over?

[robinkrahl]

Good to hear! I’m happy to extend the nitrokey crate, but as I do not have a Nitrokey Storage, I cannot test anything related to it. Would you be willing to run the tests?

As far as I see, you are using these commands in nitrocli:

• EnableEncryptedVolume (0x20)
• DisableEncryptedVolume (0x21)
• GetDeviceStatus (0x2E)

The first two correspond directly to NK_unlock_encrypted_volume and NK_lock_encrypted_volume in libnitrokey. I can easily add these to the nitrokey crate. GetDeviceStatus is more problematic. While the C++ API provides access to the complete status, the C API only provides access to a string version (NK_get_status_storage_as_string). We can get the firmware version and the retry counts from other sources (already available in the nitrokey crate), but not the volume and SD card information.

So I am going to add support for enabling and disabling encrypted volumes to the nitrokey-rs, and I’ll prepare a patch for libnitrokey to add the full device status to the C API.

[jans23]

@robinkrahl In case you are interested in adding full support for Nitrokey Storage, we would be glad to donate you a device.

[robinkrahl]

@jans23 That would be great! I can’t make promises regarding the timeline, but I’m definitely interested in porting all libnitrokey features to Rust and, eventually and if applicable, to a command-line application.

[d-e-s-o]

Would you be willing to run the tests?

Sure. I am in a similar boat. I don't have a Nitrokey Pro and my storage device contains actual data, so I have to be careful. But we'll figure something out.

[jans23]

@d-e-s-o Please write us an email in case you need more hardware.

[d-e-s-o]

@jans23 Sure, thanks for the offer! Right now I am good as I have no new developments in the pipeline. So if Robin is fully covered for his testing that may be enough. I'll see how straightforward the code looks and whether I can get enough coverage with my existing hardware :-)

[robinkrahl]

I finally finished the work I started this summer and ported the existing nitrocli commands to libnitrokey. The code is available in the wip/libnitrokey branch of my fork. Now I’ll continue to add more commands.

@d-e-s-o

1. How would you like to receive code contributions – Github pull requests, link to code via mail, patches via mail, something else?
2. We should discuss how to structure the new code. Should I open issues for these discussions, or do you want to discuss via mail?

[d-e-s-o]

I finally finished the work I started this summer and ported the existing nitrocli commands to libnitrokey. The code is available in the wip/libnitrokey branch of my fork. Now I’ll continue to add more commands.

That is great news @robinkrahl ! Thanks for working on this. I'll have a look hopefully later today to get a better impression of where you are, by Wednesday at the latest.

1. How would you like to receive code contributions – Github pull requests, link to code via mail, patches via mail, something else?

We can keep everything on Github. Pull request on the platform should be fine.

2. We should discuss how to structure the new code. Should I open issues for these discussions, or do you want to discuss via mail?

Same here. Opening issues should be fine!

[d-e-s-o]

OTP support got merged! Thanks for implementing this feature @robinkrahl . I believe that justifies a new release. I will probably bump to 0.2 to pay tribute to the significant changes that went into this version: the change to using the nitrokey crate, the switch to using argparse, and the implementation of OTPs. I'll wait for my new device, though, in order to run a final round of tests.

[robinkrahl]

Could you wait some days before releasing the next version? Implementing the remaining commands listed in #4 should be rather easy now. In any case, we have to update the readme and the man page before releasing a new version.

[d-e-s-o]

Could you wait some days before releasing the next version?

Sure. I don't want to cram too much into a release and rather release once more, but I also don't want to block progress.