I have purchased recently a NitroKey Start. I have completed the installation and now have SC, E, and A keys stored on the device. I have also read through applications and forum pages but I am still in need for advise. Unfortunately, as a customer, I am struggling to get any value out of my NitroKey atm.
Assuming I have the NK device with the keys and a fresh Linux operating system installation (e.g. Ubuntu) - no keys in the GPG keyring yet! What I need to do in order to decrypt a GPG encrypted file using my NK? And vice versa how do I encrypt a file with GPG? What are the basic commands for this? Thanks.
gpg2 --sign --encrypt --recipient Bob@nitrokey.com file-to-encrypt.txt - sign and encrypt data for Bob;
gpg2 --encrypt --recipient me@altavista.com file-to-encrypt.txt - file encryption to myself only (does not require Nitrokey; requires public key of the recipient).
See gpg2 --help for details. On some systems the command is named just gpg.
Regarding the first setup on a fresh system, the main public key of the material stored on the Nitrokey has to be imported, as it keeps only the secret part. It can be done by:
importing the public key from the file - the latter could be created in the environment, where the keys were generated;
storing the file under own https address, which is placed on the smart card - this will allow the GnuPG to semi-automatically download the public key on use (see documentation).
Then simple gpg2 --card-status will make aware the environment about your secret key location.
Regarding general applications for the Nitrokey Start, please take a look at:
Thank you for your response. One of the pain points was the key import, and then there was a problem with the trust of the imported key. I got everything working now, and and I can give feedback: my customer journey was quite long and painful. Not sure what your target audience is but I see a lot of room for improving the Getting started part / tutorial. The Applications page contains a lot of really simple instructions, which in my experience did not work mostly.
At this point I cannot recommend using crypto-sticks, in general. They are complex to take into use and manage. However, this I assume is true for all hw manufacturers. Maybe my mind will change, when I do similar exercise with NitroKey HSM - if not going to test competitor’s product. Anyways thank you for your prompty responses here on the forum. Will post my journey as a series of blog posts later on.
Btw, I noticed that you can give a PIN of less that six (6) characters which causes signing to fail. Should I report this a bug or not: wasted one hour figuring out that the device accepts input that it cannot use. Highly appreciating your work, thanks for that!
Sorry about that. Could you list briefly which ones? We will be happy to test / correct where necessary.
Which documentation pages have you used?
I believe this is more a problem of the software using the devices, not the devices themselves. I think for the start GUI software dealing with the smart cards is more intuitive, than Linux command line. I mean here applications like Thunderbird, GPA, Kleopatra.
Similarly, with time some CLI wrappers were created, communicating with GnuPG and OpenSC for the user and hiding the more complex features. General UX is still an open problem unfortunately.
Btw, I noticed that you can give a PIN of less that six (6) characters which causes signing to fail.
I believe you wanted to say less than fourteen (14), unless you are using the KDF setting, which allows to use 8+ characters. Either way, this is a client application issue, and depends on which one have you used.
For the Nitrokey HSM, you might be interested in these articles:
Well, I wanted to accomplish the following things with my evaluation:
have a well though security design of how the keys are managed i.e. the whole life-cycle of keys from generation to backup and revocation e.g. what is the use case of your “average” customer.
installing NitroKey from scratch so that I know what I am doing and why
after installation, test NK assuming that another person/employee gets it and starts using it
the scope of the testing includes encrypting/decrypting a file, authenticating with SSH, and managing user’s passwords with pw manager. Really the simplest valuable things IMO.
I did not know enough about GPG when I started the evaluation, so it definitely made things harder. But looking back there is surprisingly many things to take into consideration. And while all situations cannot be covered I was definitely expecting a journey with less pain points. And I really do prefer using the CLI commands because both in good and bad the UI hides a lot of things which are crucial to see if the product is able to do things which are on the requirements list.
I am a sw professional too, so may I offer a thought: how about creating test automation similar to how web apps are being tested. The tests would simulate end-user’s actions and outcomes would reflect their success. Of course, it might be tricky to circumvent interactive mode and OS challenge modes, but overall you would simultaneously create documentation as code that users could use directly.
Currently, my PIN is six (6) digits long.
Thank you for the links, I already spent long time reading raymii’s site during my adventure with NK. I hope that whatever the HSM stick will be, that journey will be faster and more productive with that. For a HSM documentation I am pretty much going to do similar exercise as with the NK.
Testable documentation if it means a sequence of GPG commands, which allow to navigate fast through the simplest use cases.
General introduction might be a good idea, but it depends who your customers are. I would save time to make the testable documentation better e.g. explaining all used arguments and why they are there. Plus, adding commands which user can run to verify outcome. Same applies with GnuPG introduction
.
Best practises guide at least to the extent how your average customer is using them.
During the installation I had to go through multiple pages, and I can’t remember them. However, I am going to write a series of blog posts which contain some of the links, and also cover a lot of the issues I faced in the beginnig - of course they are opionated and fit for my needs.
How about having two tracks in the documentation: installation (exists now) and operation (kind of exists in the form of Applications page). The latter would assume that someone gives a fully installed key. For example, how different PINs work etc. could be explained clearly. Maybe even having a existing Nitrokey user in some public keyring to whom you can send test file (encrypted), and also a webapp that you can send your email address (after having a corresponding key in the keyserver) and then use your own key to decrypt it?
