Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add small 1GB boot drive for Anti Evil Maid #1

Open
tasket opened this issue Dec 16, 2016 · 3 comments
Open

Add small 1GB boot drive for Anti Evil Maid #1

tasket opened this issue Dec 16, 2016 · 3 comments

Comments

@tasket
Copy link

tasket commented Dec 16, 2016

It would be nice to have a single device that could both isolate the keyboard and boot the machine via Qubes AEM.

@robertfisk
Copy link
Owner

From a purely practical perspective, this can be done for a modest per-unit price by adding a microSD socket to the USG, and connecting it to the downstream (device-side) embedded CPU. This will require another PCB revision with associated prototyping and stock management costs. It would also require extending the internal SPI-bus protocol to support two simultaneous device classes (mass-storage + something else). At the current rate of development this is likely to be 12+ months away :)

However! The security implications of this value-add feature should not be underestimated.

  1. Obviously there is now no security boundary between your keyboard and your AEM storage. A bad keyboard can attack the SD card's firmware, and potentially vice versa (I'm not sure whether the SD card protocol is sufficiently complex to facilitate an exploit, but USB certainly is).

  2. The killer issue IMO: The USG allows only one device to be active at any one time, specifically to block hidden device attacks. However, implementing microSD card support in the USG firmware means that any badUSB device can now pass through an additional mass storage device at any time. This blows a big hole through the "one active device" rule, and weakens the USG's security stance.

Even simply implementing this feature in an alternative firmware version will lead to reduced trust in the USG. The factory may load in the microSD-supporting fimrware by accident, and the user has no way to verify which firmware was installed without actually exploiting the USG themselves!

So I'm going to leave this issue open, but I will need to address the concerns above before implementing this feature.

@virtualguy
Copy link

How about two downstream microcontrollers, one as a mass storage device and another as the target USB device. Perhaps even on different SPI ports for a little more isolation.

@robertfisk
Copy link
Owner

Yes, it would require two downstream MCUs to do this securely. That way the uncompromised upstream MCU can differentiate between a bad keyboard, and legitimate mass storage / SD cards.

Of course this would significantly increase cost, and the PCB will not fit in the current plastic case. It would essentially be an entirely new product.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants