summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* 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