| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
The data sent with Set_Report requests contains a CRC which we so far
ignored. This patch adds a Crc struct that uses the CRC peripheral to
calculate the CRC for some data and uses it to validate the CRC of the
received data.
|
| |
|
|
|
|
| |
Previously, we directly accessed the request data by indexing the buffer
containing the data. This patch introduces the Request struct which can
be deserialized from raw bytes using ssmarshal.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, we manually constructed the data to sent with a Get_Report
response. This patch introduces the Response struct which can be
serialized using ssmarshal.
As Serialize is only implemented for arrays with a length up to 32, we
have to use the serde-big-array crate for the data field. As the
command ID might not be recognized by us, we use a raw u8 value instead
of the CommandId enum.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors the command execution. A command is represented by
a struct implementing the Command trait. The enum_cmd macro is used to
generate a mapping from the CommandId enum to a Command instance and to
execute the command. The request and response data is manually
converted from and to raw byte slices.
As we do not have a standard library, we cannot create a Box<Command>
from a CommandId. Instead, we directly delegate the execute method to
the corresponding Command.
|
| |
|
|
|
|
| |
To avoid unnecessary allocations and to simplify the code, this patch
refactors Nitrokey::execute_command to write the data to a slice instead
of returning it as an array.
|
| |
|
|
|
|
|
| |
This patch adds a simple implementation for the command ReadSlotName
that provides access to the names of TOTP and HOTP slots. It returns
the name test for the first TOTP slot and the SlotNotProgrammed error
for all other slots.
|
| |
|
|
|
| |
For debugging purposes, we add a simple GetStatus implementation that
just reports the firmware version 0.1.
|
| |
|
|
|
|
|
| |
This patch changes the Get_Report handler in Nitrokey to extract the
command data from the buffer sent with the Set_Report request, to
execute a command based on this data and to write appropriate return
data back to the device.
|
| |
|
|
|
|
|
|
|
| |
This patch adds support for Get_Report and Set_Report requests to
HidClass. We parse the request metadata and the delegate the request
handling to the HidDevice.
Our HidDevice implementation, Nitrokey, stores the data sent with
Set_Report requests. The Get_Report handling is not implemented yet.
|
| |
|
|
|
|
|
|
|
|
|
| |
HID implementations must provide a HID and a Report descriptor. This
patch adds these descriptors. The Report descriptor is copied from the
Nitrokey Pro.
As the control_in implementation in usb-device only handles
GET_DESCRIPTOR requests on the device level, we have to change the
control_in method in HidClass to handle GET_DESCRIPTOR on interface
level (required for the Report descriptor).
|
| |
|
|
|
|
|
|
|
| |
The HID USB class needs device-specific information – currently, the
subclass and the protocol of the device, but also the report descriptors
and request handlers once we support these functions. Therefore, this
patch introduces the HidDevice trait that provides this data. It also
adds a Nitrokey struct that implements this trait for the Nitrokey Pro
device.
|
|
|
This patch adds the usb-device and stm32f103xx-usb crates that provide a
USB stack. It introduces the HidClass struct, a basic implementation of
the Human Interface Device (HID) USB class. Devices with that class are
recognized as HID devices with the specified vendor and product ID, but
do not provide the endpoints required for interaction.
|
