[csmuk]

I'm not sure it should be allowable.

WiFi firmware can in theory allow passive monitoring and forwarding of data. This is because the WiFi card is a small self-contained embedded system.

The CPU microcode (and arguably architecture) is more difficult to modify but it's possible that the microcode for an AES round opcode could be intentionally flawed. Enough press is around not to have to explain this.

USB is the one I find interesting. Anything (webcam/keyboard/mouse) could arbitrarily register itself as an HID device and inject data into your OS.

The whole systems architecture is a mess.

I'm not suggesting we go back to discrete wire-wrapped PDP11's but something needs to be done by putting security and privacy first. That means starting again as where we are isn't good.

[bri3d]

I do agree that it probably shouldn't be allowable; even minor pieces like webcam firmware have proven very important (see the Apple webcam firmware with no light story from a few days ago).

Plus without the requirement to release firmware for co-processors, some full machines with the potential for DMA and all sorts of nefarious concepts can exist that nobody even notices (SMC, WiFi, Bluetooth, "fan managers" and so on).

With that being said no modern CPU vendor would even think about open-sourcing their CPU microcode especially, so the FSF are stuck between a rock and a hard place. With a true "every single thing open" requirement in place, the only general purpose PC made in the last ten years or so that could hope to come close to passing would be a Chinese MIPS laptop.

[hackmiester]

Can I get a link to that webcam firmware story? I read a little bit about it, but I was looking for a more technical look into why it would be possible to enable a camera with no LED.

I always thought the sensor power was connected also to the LED, to prevent exactly that type of hackery.

[jholman]

bluekitten, who appears to be hellbanned for no reason at all, gave this link:

http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/18...

[zanny]

I don't consider a computer properly open unless (if I had the available fab tech) I could replicate every part by spec and program everything with blueprints and documentation without breaking any bullcrap trademark or patent without just reproducing the parts verbatim (IE, using novel circuit printing, re-implement the hardware of the computer itself with no barriers and complete information, I am lenient on having short-term no direct replication proceedings, though I think those are still dumb).

The fact that seems so impossible I believe is one of the reasons our IP and information sharing ideologies are so completely fucked right now.

[weland]

> WiFi firmware can in theory allow passive monitoring and forwarding of data. This is because the WiFi card is a small self-contained embedded system.

On the other hand, it would typically be detectable and would generally fail to work without significant intervention from the software on the computer. The same goes with the webcam. Theoretically, it could keep its activity LED shut down and snoop you without you knowing it, but how is it going to send data over to No Such Agency?

This is probably not sufficient for high-security matters, of course, but it is IMO good enough to ensure the privacy of a user who doesn't do anything illegal. Working past the security you get simply from running open-source software (at least as far as the peripherals are concerned) is expensive, risky and potentially intrusive enough that it isn't worth doing unless you're trying to tap into a drug dealer's computer. In which case yes, you should be thinking about something else.

> I'm not suggesting we go back to discrete wire-wrapped PDP11's but something needs to be done by putting security and privacy first. That means starting again as where we are isn't good.

More vitality in the open hardware movement would be great. This isn't meant as a way of criticizing its members; if asshole engineers like me would do something about it instead of blabbing on HN, things would probably be better.

[EthanHeilman]

I'm not sure it would require 'intervention from the software on the computer', by which I think you mean, the software running on the CPU. For instance it does not seem beyond the realm of possibility that firmware in your webcam could communicate over the PCI bus with firmware in your ethernet card to transmit video.

Note also that while the software running on your CPU might be beyond reproach (you carefully read every javascript file before you execute it right?), the microcode running on your cpu can do just about anything.

[weland]

> For instance it does not seem beyond the realm of possibility that firmware in your webcam could communicate over the PCI bus with firmware in your ethernet card to transmit video.

IMHO, it does. The PCI bus isn't something that gets shared on a whim. The functionality you need for this would have to be built in the BIOS.

[robryk]

> ...but it's possible that the microcode for an AES round opcode could be intentionally flawed

I guess that you mean that it'd still give correct output, but somehow leak the key (incorrect output seems simple to detect, unless it happens for a very small set of keys, and then it seems mostly useless).

I wonder: what ways of leaking the key off the machine would you expect? I (but I'm probably not devious enough) don't see ones that aren't overly complex and don't require additional compromised peripherals. Do you?

[duskwuff]

Timing. Perhaps a malicious microcode could introduce key-dependent delays into AES encryption/decryption? That's a pretty long shot, though; given my understanding of modern CPUs it's unlikely to be possible.

[nitrogen]

Another hypothetical attack: the AES instructions could be modified to store plain text and/or keys in cache, with a specific set of innocuous opcodes and register values triggering a readout of the data. This would allow one VM on a physical server to steal keys or data from another VM on the same server.

It seems unlikely, though, due to the probability that an adversary that controls both CPU microcode and VM placement probably has access to the hypervisor.