I have a complicated security onion with multiple points an attacker would have to get through. The only issue is my computer does not have enough USB ports for all of the devices I need to connect. Does anyone know if there is a USB hub that’s secure enough?
Ideally, I’m looking for one that has addressed, this and I can open easily to verify the hardware is correct. Tried with another hub, and broke it in the process.
I have never heard of a USB hub that can address the inherent insecurity of USB devices. That’s why Qubes isolates the USB controller from other VMs. At best, a USB hub just gives you more ports to connect devices the same PCI controller. At worst, they could harm your system. Ultimately, they only increase the probability of compromise.
It’s good that you have multilayered security but that could all be for naught if you start mixing multiple USB devices on the same controller and they have access to networked VMs or dom0.
You’re better off with more USB PCI controllers under the hood than with adding more ports to the same controller. The latter just increases your attack surface. The former allows you to compartmentalize device functionality in separate VMs.
It depends what your needs are, and what your definition of “secure” is…
If you answered no to any of these, maybe you should reconsider your security model… 
I read this article, and I don’t know how much I agree with the phrase “This firmware itself isn’t actually a normal piece of software that your computer has access to.” in the article…
(It actually is a piece of software that your computer has access to!)
I’m all for simplification and paraphrasing, but if it turns the content into something that’s completely untrue, then I don’t know how comfortable I am with it… 
"When you connect it to your computer, it could send keyboard-press actions to the computer as if someone sitting at the computer were typing the keys. "
Yes, I have a rubber ducky that I use to rickroll people. (Disable their keyboard, open Rick Astley - Never Gonna Give You Up, and turn the volume to 100%). Don’t worry, I fix their computer afterwards…
“A connected device could function as a USB Ethernet adapter and route traffic over malicious servers.”
Yes, that’s true, which is why you should be wary of any USB flash drives with a big blue CAT6 cable extending from them and out the window down the street! 
No, but seriously, this is a real thing, and is a problem if your computer has been configured to automatically interface with these devices. Unlike other OSes that are built around convenience above security, Qubes OS doesn’t do this by default, so it’s somewhat mitigated.
" A modified storage device could function as a boot device when it detects the computer is booting, and the computer would then boot from USB, loading a piece of malware (known as a rootkit) that would then boot the real operating system, running underneath it."
This is a real thing. The solution is to unplug devices you don’t know from your USB ports when you boot
As @necker said, much of what you’re conmcerned about is at the software level, namely Qubes OS. Thankfully, the devs have done an amazing job at mitigating these threats.
Take the USB hub to an airport, security checkpoint, or freight hub and ask for a copy of the X-Ray image, maybe?
All you are likely to see are CHIPS ON A PCB. Unless some evil person has stuck additional components inside the case with duct tape, it’s highly unlikely that you won’t be able to tell unless you run current through the chips and read them… 
I’m trying to help you put everything in perspective, so that you can better understand the threats, and therefore be better prepared for them (and in turn, hopefully less stressed).
The highest security solutions for USB hubs that I am aware of involve physically locking down all USB ports except one and then physically locking the hub to a single port. Authorized USB devices are then attached to the hub and an admin key is inserted to register the devices. Once it’s set up, all other devices are blocked from the computer. Security is based on limiting access to known devices - not blocking malicious code per se. The registered devices could be malicious. All that matters is that they are registered.
Firmware exploits and BadUSB can be mitigated witth secure firmware (ala Ironkey, Kanguru, etc). Physical write protect switches can offer some peace of mind as well.
Of course, this discussion isnt complete without mentioning KillerUSB. They look like a USB sticks but are loaded with capicitors and designed to blow up your USB port. 
not just that, it can fried your motherboard and possibly your ssd too
Makes a great Christmas present
I saw something that locks the devices in, awhile back. I’m mostly worried about there being extra components on the board. Though couldn’t I mitigate that by only letting VMs access specific IP addresses before connecting a device?
Some college student went to prison for doing that in his university library. Filmed and upload himself to YouTube doing it. Took out about ten computers.
Take a look at https://www.usbcondom.org/. I don’t know if they have a USB hub but they are at least trying to mitigate all these USB security issues. At one point there was a USB Condom available on Amazon but they are now out of stock and have no idea when they will be back in stock.
Certainly a USB hub protected in this way might be useful, but then any adversary could simply unplug it and then use the now empty USB port to do their dirty deed. If you find a hub you might then need to glue it in place or find a way to lock out the USB port while the machine is unattended.
You will need to define exactly what threat model you are wanting to mitigate.
The USBcondom v1 USBCondom v1 | USBCondom is available on Amazon (sold as “USB data blockers”). v2 just adds a switch. v3 blocks killerUSB attacks - which is interesting, but probably not necessary for most people. But with all versions, once you allow data to pass, the same USB security risks apply.
Since this is in the discussion area, I’m not responding with solutions. Just hope to further the discussion.
Possibly relevant information about BadUSB in hub firmware can be found at Hubs - BadUSB Exposure - SRLabs Open Source Projects
IIUC some USB2 hubs based on some Terminus chips (as well as at least one Genesys Logic based hub) may have less of an attack surface. Does anyone know more?
This also stood out to me.
“If the hub is reprogrammable (which is often the case for USB3.0 hubs), this allows persistent infection of the main board even if the BIOS/UEFI is protected against unauthorized/unsigned upgrades.”
This is a difficult challenge to address but I understand your concern. How were you planning to identify extra components? Anyone have a good way of dealing with this concern?
Based on this it appears restricting interaction (via hardware) with known devices has some propenents too. Anyone have experience with an Armadillo?
Wholeheartedly agree @necker
Thanks for the link. I don’t have any experience with the Armadillo but it looks interesting. My only concern would be a false sense of security - especially with USB keyboards. It’s supposed to “detect” keystroke bots, but what’s to stop a malicious keyboard from outputting destructive terminal commands with the same timing and cadence of a human?
sudo rm -rf /
is enough to ruin an afternoon. But there are also countless other commands that could be destructive. Does the USB firewall stop all of them? Seems unlikely. But even if so, how many of your own legit commands does it have to block before you remove the firewall out of frustration?
I do like the concept of serializing and firewalling untrusted drives. And it certainly seems possible to filter certain types of input but at the end of the day, it seems like it’s either going to miss something or become too restrictive to use (the classic inverse proportional relationship between "security vs convenience.
I still think a disposable VM that is isolated from other machines and networks is the best way to handle untrusted USB devices - but I suppose there could be a place for occasional use of a USB firewall + an isolated disposable VM.
Then build a USB hub yourself (unless you have a schematic diagram of your hardware and are comfortable with cross-referencing it).
It’ll be very difficult (but also very educational) if you don’t have the schematics…
Yeah, you could do that.
That’s more or less what sys-usb does if it detects a USB keyboard or pointer device.
This might be nit picking but are you sure about that? I have a USB hardware password key that acts as a keyboard and autofills login info and other security stuff. When I plug it into sys-usb, it’s ready to go. I can freely use it and configure it inside of sys-usb and attach it to my domU qube of choice . The only administrative mitigation of keyboard and mouse connectivity is within dom0… but that blocks all USB access to dom0, not just input devices.
Nitpicking is what provides the most accurate information 
That is AWESOME!
I meant in terms of not allowing direct access to dom0. When I plug in a USB keyboard, I get a dialogue box that requires me to approve the new USB keyboard using the existing keyboard.
So…why does my Qubes OS behave differently? Maybe I have something differently configured?
Apologies for any confusion or ambiguity. I will happily correct anything, for the benefit of anyone who may come across this thread. Don’t want anyone getting misinformation. We already have enough of that already 
It’s considered best practice to hide all USB devices from dom0. But if you use an external USB keyboard, you can’t do that (or else you won’t be able to login and execute commands in a dom0 terminal).
If you don’t use an external keyboard, consider the following (which should be configured already if you have the default sys-usb VM.
or via Tor:
Agreed.
Also fully agree.
But I don’t use an external USB keyboard. I use a built-in keyboard on a laptop which thankfully has the internal keyboard and trackpad on their own USB bus, allowing me to allocate only that bus to dom0, and the remaining 3 buses to sys-net-usb.
I guess I don’t have the default sys-usb, as I had to tinker with it to get it to work properly.
I guess that explains why mine is different. My apologies.
what did you mean?
If you use an external USB keyboard, it needs to be connected to dom0 or there won’t be anyway to type in dom0… so it’s not ideal to use external USB keyboards.
i thought that usb keyboard keystroke are transferred to dom0 from sys-usb using some kind of qubes protocol, not passing the usb keyboard itself (only after login)