So far I've told you about what a device descriptor is and more or less what an interface is. Let's examine another example (this I have made entirely out of my imagination, and I'm not really a gamer, so bare with me if you find it out-stretched :)). Suppose we a have a gamepad and a a racing wheel and we can connect these two devices with a common USB tranceiver. The gamepad is fine for most types of games, but for some racing games you would like the host communicating only with the wheel. So let's say there is a switch on the wheel, and when it's turned on the host will completely forget that there is a gamepad. How can we do that, i.e. how can we turn interfaces on and off? That's where a configuration descriptor comes in play.
Following the last post, we have plugged in a USB device to the host and the host has asked for the Device Descriptor through the Endpoint 0 (the control endpoint). We put on the Endpoint 0 a respond request for the device descriptor and we send the respective data. After that the host is asking as for a Configuration Descriptor with a GET CONFIGURATION DESCRIPTOR request. In this configuration descriptor we describe mostly things about our interfaces, how many are there, how many endpoints each interface has and stuff like that. The important thing here is that a device can switch between different configurations. Taking the gamepad example, when we turned on the switch, that could be a signal for the firmware that the user want to only use the wheel interface and forget about the gamepad. We could have written two configurations for the device, one which there is only the interface of the gamepad, and an alternate one where there is only the interface of the wheel. Again, this is only an example, I'm sure that someone could find a better implementation for this.
The host is requesting a configuration descriptor and some of you are thinking "since the host doesn't know yet the exact number of the interfaces (since they are not contained in the device descriptor but in the configuration descriptor which is just asking for), how can the host know how many bytes to expect?" And that's a pretty neat trick for the USB specification. In any GET request the host is putting on the control endpoint, besides others, how many bytes it's requesting. At first the host asks for only a limited amount of bytes from the configuration descriptor. One of them is the whole configuration descriptor size. So it gets a limited amount of bytes, gets informed about the whole size of the configuration descriptor, resets the device and when it's going to ask again for the configuration descriptor, this time it's going to get the whole one. Listed in there are all the interfaces that the device implements in *this* configuration. Nitrokey has already some of them implemented (like a keyboard HID interface and a CCID interface), and for our purposes we need a new HID interface for U2F.
HID actually stands for Human Interface Device. Of course an authentication token is only in some basic sense a human interface device, it only has a button on it which you have to press to authenticate. But the cool thing about the HID interface is that all major operating systems come with a driver pre-installed for HID, it's a simple interface, there is a lot of experience around these devices (think how many years we've been using keyboards and mices), and is communicating through interrupts, which guarantee correct timing and limited data usage. That's why I think FIDO decided to use the HID interface for implementing U2F, and personally I couldn't be more down with their decision.
I'd like to take some time and describe the U2F HID interface, but I guess that's a blog post of its own. Talk to you next week! :)
Following the last post, we have plugged in a USB device to the host and the host has asked for the Device Descriptor through the Endpoint 0 (the control endpoint). We put on the Endpoint 0 a respond request for the device descriptor and we send the respective data. After that the host is asking as for a Configuration Descriptor with a GET CONFIGURATION DESCRIPTOR request. In this configuration descriptor we describe mostly things about our interfaces, how many are there, how many endpoints each interface has and stuff like that. The important thing here is that a device can switch between different configurations. Taking the gamepad example, when we turned on the switch, that could be a signal for the firmware that the user want to only use the wheel interface and forget about the gamepad. We could have written two configurations for the device, one which there is only the interface of the gamepad, and an alternate one where there is only the interface of the wheel. Again, this is only an example, I'm sure that someone could find a better implementation for this.
The host is requesting a configuration descriptor and some of you are thinking "since the host doesn't know yet the exact number of the interfaces (since they are not contained in the device descriptor but in the configuration descriptor which is just asking for), how can the host know how many bytes to expect?" And that's a pretty neat trick for the USB specification. In any GET request the host is putting on the control endpoint, besides others, how many bytes it's requesting. At first the host asks for only a limited amount of bytes from the configuration descriptor. One of them is the whole configuration descriptor size. So it gets a limited amount of bytes, gets informed about the whole size of the configuration descriptor, resets the device and when it's going to ask again for the configuration descriptor, this time it's going to get the whole one. Listed in there are all the interfaces that the device implements in *this* configuration. Nitrokey has already some of them implemented (like a keyboard HID interface and a CCID interface), and for our purposes we need a new HID interface for U2F.
HID actually stands for Human Interface Device. Of course an authentication token is only in some basic sense a human interface device, it only has a button on it which you have to press to authenticate. But the cool thing about the HID interface is that all major operating systems come with a driver pre-installed for HID, it's a simple interface, there is a lot of experience around these devices (think how many years we've been using keyboards and mices), and is communicating through interrupts, which guarantee correct timing and limited data usage. That's why I think FIDO decided to use the HID interface for implementing U2F, and personally I couldn't be more down with their decision.
I'd like to take some time and describe the U2F HID interface, but I guess that's a blog post of its own. Talk to you next week! :)
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου