hardware wise, looks to be a usbc version of fomu.
Fomu could likely not fit USB logic as well as the security-related cores we have. That, and the fact that we don't want the attack surface of the USB firmware running in the same core that handles the KDF.
They are very different products for very different use cases.
i like the conceptual purity of fomu, but it does take quite a bit of work to get to the point of talking to it over usb.
Could you expand on what you mean by "take quite a bit of work". I thought Fomu came preconfigured?
I understand that for some people this is an agitating stance and question to ask, but it's after all a security-focused USB device meant to be plugged into users' computers.
According to the specification: It is effectively a USB PHY with a small microcontroller attached. Firmware updates are done through the plug but can't be done from a USB host due to special electrical requirements that USB can't satisfy. One of our greatest concerns regarding the CH552 is any remote code execution vulnerabilities in the firmware that would allow an attacker from the host to gain persistence and use that to traverse an airgap.
For what it's worth we have the same concerns for other dedicated USB chips as well. Many of them are in fact trivially upgradeable from the USB host. It should also be noted that while the lower layers of USB are easily designed in hardware logic, the upper layers would be quite expensive to do in logic. In other words, any USB IC that provides USB to UART or USB to SPI likely has a microcontroller in it.
In our case I would love to find a USB IC with OTP memory. Our security model would even allow remote code execution vulns. A compromised host can upload anything they want to the TKey anyway by design. It is attacker persistence that would get annoying.