aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Wait until encrypted volume is opened/closedDaniel Mueller2017-04-09
| | | | | | | | | Until now we treated any response but "ok" and "idle" to the encrypted volume opening command as an error and reported it. However, the opening process is a potentially long running and it is very likely that the nitrokey reports a couple of "busy" messages. This change implements the logic to wait until the nitrokey either reports an error or a successful open.
* Add 'clear' commandDaniel Mueller2017-04-09
| | | | | | | | | | We currently unconditionally use gpg-agent to enter the PIN to use when opening the encrypted volume. The agent has the advantage of caching the password for us so that subsequent invocations against the same cache entry can be served without user interaction. For various reasons, however, it can be desirable to have the ability to remove this entry from the cache. This change introduces a new command 'clear' that achieves precisely this task.
* Detect wrong password during 'open' commandDaniel Mueller2017-04-09
| | | | | | | | | | When a wrong password is entered when attempting to open the encrypted volume the nitrokey will report that in the form of an error. In such a case we should retry the operation after asking the user for the corrected password. This change implements this logic. Note that because we use gpg-agent for the PIN inquiry and because it caches passwords by default we must make sure to clear the cache before retrying.
* Add 'status' commandDaniel Mueller2017-04-09
| | | | | | | | | | | The nitrokey supports a status command that instructs it to report details about itself. This data includes general useful information such as the current version of the firmware being installed along with more contextual bits such as the number of remaining retries for the user and admin PINs or whether the different volumes (unencrypted, encrypted, hidden) are writable. This change introduces the 'status' command line option that can be used to retrieve this information from the nitrokey and to display it.
* Do not check CRCDaniel Mueller2017-04-08
| | | | | | | | | | The nitrokey embeds a wrong CRC code into the response for certain commands. When closing the encrypted volume, for example, the CRC code never matches the actual report data. This problem is tracked by issue 32: https://github.com/Nitrokey/nitrokey-storage-firmware/issues/32 To work around this problem for now we unfortunately have to ignore the result of the CRC check. This change adjusts the code to do that.
* Introduce transmit function subsuming send and receiveDaniel Mueller2017-04-08
| | | | | | | | | The send a report, wait for some time, and receive a response pattern is used in many places already and more are to come. In fact, no send should ever happen without the wait for a response. To that end, this change introduces a new 'transmit' function that performs the exactly this task: send a report and return the response to it.
* Retry send/receive on failureDaniel Mueller2017-04-08
| | | | | | | | | | It is possible that sending or receiving a feature report fails. Such failures can have multiple reasons, including transient problems. In the case of such a transient failure we should retry the operation. This change accomplishes this feat by retrying a send in case of a failure up to a maximum of three times, with a small wait in between. It also introduces the logic or receiving a response (which is not yet evaluated fully).
* Receive command responsesDaniel Mueller2017-03-30
| | | | | | | | | By just sending a command to the nitrokey alone we have no idea of what actually happened on the side of the nitrokey. A command could simply be invalid in the current context or the stick could be busy or in a failure state. In order to determine the success of an operation, this change adds the logic to retrieve the response from the nitrokey as well.
* Use macros for generating commandsDaniel Mueller2017-03-29
| | | | | | | | Commands to the nitrokey all must follow a similar pattern in that they all require to have a constructor (i.e., a new() method) and need to implement the AsRef trait for byte slices. For we require more commands in the future, this change introduces macros that simplify creation of command objects.
* Send HID feature report to open/close the encrypted volumeDaniel Mueller2017-03-28
| | | | | | | With this change we assemble a HID feature report and send it to the nitrokey device. Feature reports are the objects used for sending commands to the nitrokey. We create two different reports for opening and closing of the encrypted volume.
* Update hid crate to version 0.4.0Daniel Mueller2017-03-27
| | | | | | | | The 'hid' crate got a couple of bug fixes, at least one of which we require in order to retrieve HID feature reports correctly. This patch imports the new state and bumps up the library version used. Import subrepo hid/:hid at 52b47d78c17b876194e4b4a1c0c8ae8adfb3d39c
* Add pinentry moduleDaniel Mueller2017-03-27
| | | | | | | | | | | | | | | | We do not want to roll our own infrastructure for entering a password (or PIN) securely, as there are existing providers of such functionality. gpg-agent, which uses pinentry for this very purpose, is such a program and we can safely assume to be present because we use it with the smartcard part of the nitrokey. This change introduces a new module, pinentry.rs, that provides the means to invoke gpg-agent to ask the user for a PIN and to parse the result. Using gpg-agent like this has two advantages that other solutions do not necessarily provide: first, because we use gpg-agent anyway it's pinentry configuration is as the user desires it and, hence, the integration appears seamless. And second, the agent caches pass phrases which alleviates the need for repeated entry should the credential be required again.
* Discover and open nictrokey using libhidapiDaniel Mueller2017-03-26
| | | | | | | | | | | This change uses the 'hid' crate to discover and open the Nitrokey Storage device. 'hid' is a wrapper around libhidapi (its libusb back-end in particular). Being a command line application some sort of parameter handling needs to happen. The approach we take is very simple for now to minimize the number of dependencies: we just compare the first argument against the expected ones and raise an error if no match was found. Because we only have positional arguments right now this is all we need.
* Import subrepo hid/:hid at 3ac1005fe3e874bef850ab733fe1a09bc36b91c5Daniel Mueller2017-03-26
|
* Import subrepo hidapi-sys/:hidapi-sys at ↵Daniel Mueller2017-03-26
| | | | ec441b2751dcbbcd053800b6901672c999651584
* Import subrepo libc/:libc at 05a2d197356ef253dfd985166576619ac9b6947fDaniel Mueller2017-03-26
|
* Import subrepo gcc/:gcc at cf1f00bc038a0df769e14bb85480ab9c12eae08dDaniel Mueller2017-03-26
|
* Import subrepo pkg-config/:pkg-config at ↵Daniel Mueller2017-03-26
| | | | a493b0d7c93df68c94d1bad2a1f419389e52c0f5
* Add basic scaffoldingDaniel Mueller2017-03-03
| | | | | | | | | This change adds the basic scaffolding for the nitrocli application. The scaffolding was created using the following command: $ cargo new --bin nitrocli The application aims at providing a command line interface for the Nitrokey Storage device.
* Create new repository for nitrocliDaniel Mueller2017-03-03