| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
The request and response structs for a command should not be bigger than
the buffer they are read from or written to. Therefore we add
assertions that enforce this property at compile time.
|
| |
|
|
|
|
|
|
| |
The Request and Response types have to have a size of 64 bytes.
Previously, we only verified this property by visual inspection.
Accidental changes to the size could lead to runtime errors. This patch
adds static assertions using the static_assertions crate to enforce this
property at compile time.
|
| |
|
|
|
| |
To increase type safety, we use references to (sized) arrays instead of
slices where possible.
|
| |
|
|
|
|
|
|
|
| |
Previously, we had the device::REQUEST_DATA_LEN constant for the size of
the raw data in the request, and the commands::COMMAND_LEN constant for
the size of the raw data in the response. This patch renames
commands::COMMAND_LEN to device::RESPONSE_DATA_LEN for consistency. It
also introduces the {Request,Response}Data type aliases for [u8;
{REQUEST,RESPONSE}_DATA_LEN].
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
By providing a custom Serialize implementation, we make sure that enum
variants are not mapped to their index, but to their discriminant. This
allows us to use serde when preparing the response packet.
|
| |
|
|
|
|
|
| |
The execute_raw method does not have to be part of the Command trait.
In order to simplify the Command trait and to make future changes
easier, we remove the execute_raw method and replace it with the execute
function.
|
| | |
|
| |
|
|
|
|
| |
Previously, we manually converted the request and response data from and
to byte slices. This patch adds the ssmarshal dependency that automates
the serialization and deserialization in the required format.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Previously, we used the ControlIn::accept method and copied the
generated buffer returned by HidDevice::report_descriptor to the buffer
provided by usb_device::UsbClass in get_report_descriptor. But it is
easier to directly pass the returned buffer to ControlIn::accept_with,
so we drop the get_report_descriptor method.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The HID standard requires an interrupt_in endpoint that can be used to
send unrequested data from the device to the driver. This patch adds
the interrupt_in endpoint, although there is no code that will ever
write to it.
|
| |
|
|
|
|
|
|
| |
We need several enums that map to a u8 value. This patch adds the
enum_u8 macro that automatically derives the From and TryFrom macros for
an enum to make these conversions easier.
As TryFrom is not stable yet, we add our own TryFrom trait.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
