zlacker

>>doener+(OP)
"Finally, we are going to require that Qubes-certified hardware does not have any built-in USB-connected microphones (e.g. as part of a USB-connected built-in camera) that cannot be easily physically disabled by the user, e.g. via a convenient mechanical switch. However, it should be noted that the majority of laptops on the market that we have seen satisfy this condition out of the box, because their built-in microphones are typically connected to the internal audio device, which itself is a PCIe type of device. This is important, because such PCIe audio devices are – by default – assigned to Qubes’ (trusted) dom0 and exposed through our carefully designed protocol only to select AppVMs when the user explicitly chooses to do so."

This made me download Qubes. Amazing project that seems to care.

>>HugoDa+bg
I personally would not trust any laptop with an internal microphone at all.

If a laptop does have an internal microphone, I just assume it is on and recording.

>>pmoria+pv
Does that mean you assume that all the firmware/devices on your laptop are compromised, or just the microphone?

>>raesen+Yw
CPU firmware is likely the worst type of compromise (see Intel ME). However, the issue is that private information can be gained by listening in on conversations near a laptop or by recording what the camera sees.

Keylogging isn't good either, but if you're using a password manager and/or 2FA then it's not really as big of an issue. It is an issue for your disk encryption passphrase, but I'm hoping that in the future we might be able to remedy that through some 2FA-like system[1]. If we seal disk encryption keys inside TPMs then we have to only come up with a sane security policy (which is obviously the hard part).

Disk controllers are similarly not an issue if you have full-disk encryption (though then your RAM is the weak point because it contains the keys). There was some work in the past about encrypted RAM but I doubt that is going to be a reality soon. The real concern is that a worrying array of devices plugged into your laptop can DMA your memory (USB 3.1, PCI, etc). iommu improves this slightly but from memory there is still some kernel work necessary to make the order in which devices load secure (if you load a device that supports DMA before iommu is loaded then you don't have iommu defences).

[1]: https://www.youtube.com/watch?v=ykG8TGZcfT8 "Beyond Anti-Evil Maid"

>>cyphar+9m1
If you input 2FA tokens using USB or keyboard on the same laptop there's almost no security improvement.

>>eeZah7+S62
I was referring to TOTP. Some 2FA doesn't protect against this, sure. But the whole point of TOTP is that the codes change over time, so having the current TOTP token is entirely useless. This is literally the threat model of TOTP. The only way of breaking it is to get the shared key (which a keylogger won't do, and you need to attack the TOTP device).

>>cyphar+e92
A TOTP code is valid for a minute - an attacker who could exfiltrate it fast enough could reuse it.

Of course, if you could do that you could probably compromise browser cookies anyway.

>>michae+qb2
Most services I use have 30 second TOTP codes, but if you're facing an attacker that can perform an on-demand replay attack in the same time it takes for GMail to load then you have much bigger problems (like hijacking browser sessions). Also, my response was in relation to saying that there was "no security improvement" which is simply not true.

I'm not sure we're discussing the same threat model here. If you're worried about long-term compromise then that race window is a much smaller concern than the fact that having a TOTP code makes it so that an attacker can't just keylog you and get the password at a later time.

Agreeing on threat models is the first step in any discussion about security. Does your threat model include being so badly owned that a keylogger on your machine can exfiltrate data so quickly that someone can replay your login session? Is that a reasonable threat model? Is it helpful to require that to be solved or otherwise not be considered good enough?