Page MenuHome GnuPG

Design USB Protocol for (possible) new device
Open, WishlistPublic

Description

scdaemon uses CCID Class protocol.

It's defined by USB forum and the background is smartcard technology. The major problem (these days) is that the interaction is designed by the use case of smartcard and its data processing limitation. We can see OpenSSH larger data issue for its authentication.

Consider the hypothetical case of sending (larger) data from a host, calculating hash of data by a device, which returns the digest.
In CCID like protocol, whole data have to be sent to a device as a single object. There is no good way for a device to receive each chunk of data and process that each chunk at a time, and lastly send back the digest to a host (w/ CCID Protocol). Smartcard data-chaining could be used in this case, but it's in a different layer.

In future, it's good for new device to use Vendor Specific Class and Protocol to take advantage of (larger) data handling.

Perhaps, then, it's good to handle those devices by new <SOME-GOOD-NAME>d, in parallel to scdaemon and tpm2d.

Event Timeline

gniibe triaged this task as Wishlist priority.Jan 23 2023, 6:45 AM
gniibe created this task.

Some technical points:

  • Control endpoint is shared by different interfaces, so, it's better to avoid use of interface specific control request.
  • Use one bulk endpoint to receive request from a host.
  • Use one bulk endpoint to send reply to a host.
  • (Optionally) use one bulk endpoint to receive data (stream) from a host.
  • (Optionally) use one bulk endpoint to send data (stream) to a host.
  • the main loop of a device is like this:
    • loop:
      • receive URB (USB request block on host) from host (possibly, in multiple packets).
      • process that USB as a request, spawning a thread if needed,
        • assigning data-receive bulk endpoint and data-send bulk endpoint (like stdin/stdout in POSIX)
        • create a thread to process that request
        • register the thread ID to manage
      • or process immediately
      • send reply as URB (on host) (possibly, in multiple packets).
  • The data processing thread of a device is like:
    • (optionally) receive URB from host
    • process data (possibly takes time)
    • (optionally) send URB to host
  • Request commands should include canceling request