So coding goes well, we are at a point were we have some decisions to make with my mentor about the actual implementation and still there are some issues in the firmware that are hard to understand. In this post I decided to take some time and continue with the description of my project, and explaining the U2F interface is crucial around this.
As I've said, getting the Nitrokey to work with U2F means that we have to implement a new USB interface. This is an HID interface and is described in the FIDO specifications. In my experience though, if someone wants to understand the U2F HID specification, I would advice them to have a good understanding of basic USB requests and the HID specification.
At first comes the interface descriptor, which for the case of U2F the most significant parts are these
bNumEndpoints 2 One IN and one OUT endpoint
bInterfaceClass 0x03 HID
bInterfaceSubClass 0x00 No interface subclass
bInterfaceProtocol 0x00 No interface protocol
The interface has two endpoints, that means a buffer were data would be put to be processed in an OUT request, and a buffer where we will store our response. Each endpoint is 64-byte size, which is the largest size for a USB 2.0 device. Of course sometimes the data that we will receive or the ones that we are going to put will be larger than 64-bytes. To deal with this, there are two types of packages, initialization packages and continuation packages. If the whole messages is larger that 64-bytes, and that actually means (64-7) bytes of payload data, we have to split the response in one initialization package and more continuation packages. The init package holds the U2F command the byte-count, which are quite useful to us. When the whole message is received, then we can process the message and put our response in the IN endpoint.
The structure of these data is described in what is called a Report Descriptor. A report descriptor which bytes (or bits) form a logical entity and describe a particular value, and we assign maximum and minimum values for them. I don't want to get into details here since someone can find a lot of information about the report descriptors with a web search, but I want to state this: The report descriptor is actually a very important part in U2F. The device discovery is made through the FIDO usage page (which is actually 0xf1do in hex :)), which is contained in the report descriptor.
Around this time I'm trying to see how these requests are actually processed in the firmware. This involves a lot of overhead and it's a tough job, but it gets interesting as I move forward. See you around!
As I've said, getting the Nitrokey to work with U2F means that we have to implement a new USB interface. This is an HID interface and is described in the FIDO specifications. In my experience though, if someone wants to understand the U2F HID specification, I would advice them to have a good understanding of basic USB requests and the HID specification.
At first comes the interface descriptor, which for the case of U2F the most significant parts are these
bNumEndpoints 2 One IN and one OUT endpoint
bInterfaceClass 0x03 HID
bInterfaceSubClass 0x00 No interface subclass
bInterfaceProtocol 0x00 No interface protocol
The interface has two endpoints, that means a buffer were data would be put to be processed in an OUT request, and a buffer where we will store our response. Each endpoint is 64-byte size, which is the largest size for a USB 2.0 device. Of course sometimes the data that we will receive or the ones that we are going to put will be larger than 64-bytes. To deal with this, there are two types of packages, initialization packages and continuation packages. If the whole messages is larger that 64-bytes, and that actually means (64-7) bytes of payload data, we have to split the response in one initialization package and more continuation packages. The init package holds the U2F command the byte-count, which are quite useful to us. When the whole message is received, then we can process the message and put our response in the IN endpoint.
The structure of these data is described in what is called a Report Descriptor. A report descriptor which bytes (or bits) form a logical entity and describe a particular value, and we assign maximum and minimum values for them. I don't want to get into details here since someone can find a lot of information about the report descriptors with a web search, but I want to state this: The report descriptor is actually a very important part in U2F. The device discovery is made through the FIDO usage page (which is actually 0xf1do in hex :)), which is contained in the report descriptor.
Around this time I'm trying to see how these requests are actually processed in the firmware. This involves a lot of overhead and it's a tough job, but it gets interesting as I move forward. See you around!
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου