| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
This patch updates the static_assertions dependency to 1.1.0. This
bumps the minimum supported Rust version to 1.37.0. As the labels have
been removed in version 1.0.0, we can now call the assertion macros
without an additional label.
|
| |
|
|
|
|
|
|
|
|
| |
There are different ways to implement the CRC check: For testing, we
might want to calulate the CRC in the software. On STM32 MCUs, we want
to use the CRC peripheral.
This patch splits the struct Crc into the Crc trait and the Stm32Crc
struct implementing Crc using the CRC peripheral. The Nitrokey struct
can now accept any Crc implementation.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
