| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text = Advanced adversaries already have specialized implant plug-ins which can [https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/ take over the computer's microphone] and record nearby conversations. <ref>
The implant is called CAPTIVATEAUDIENCE, while the webcam equivalent is called GUMFISH.
https://www.wired.com/2014/03/webcams-mics
It is recommended to check whether the computer or notebook has a microphone. Microphones are often built-in and go unnoticed. In most cases it is advisable to disable the microphone for security reasons. If {{project_name_workstation_long}} is ever compromised by malware, an adversary could eavesdrop through the microphone. <ref>One attack vector is the use of [https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/ spam emails which contain malware].
</ref> Similarly, keyboard acoustic side channel attacks can use the audio leakage from keyboard typing to infer the words up to a certain degree of accuracy. <ref>
https://fc16.ifca.ai/preproceedings/21_Anand.pdf
Researchers continue to improve the accuracy of various techniques and attack vectors like feature extraction and classification, keyboard geometry and triangulation.
Another eavesdropping risk concerns mechanical HDDs. Researchers have discovered that maliciously modified firmware is able to record Positional Error Signal (PES) data that registers minute disturbances in the platter with internal sensors; high-quality recordings of sounds like human speech could be reconstructed from this information. This attack has several limitations: <ref>
https://www.extremetech.com/electronics/287324-researchers-turn-hard-drives-into-covert-listening-devices
# An attacker needs to physically tamper with the targeted equipment. <ref>
One possible method is hardware interception during shipping.
# Sounds near the hard drive must be rather loud:
* To identify human speech a 75dB minimum level is necessary, which is equivalent to a noisy argument within a few feet of the HDD.
* To identify music that is playing, a 90dB level is required -- this is as loud as a lawnmower.
While the SSD alternative avoids this threat, it has the drawback of uncertainty when encrypted volume headers are deleted or encryption passphrases are changed.
Phones Smartphones Smartwatches Tablets and similar Devices
Above described risks also apply to touch screen devices like smartphones and tablets. <ref>
https://www.schneier.com/blog/archives/2019/04/recovering_smar.html
Joanna Rutkowska, security researcher, founder of Qubes OS, removed all microphones and cameras from her smartphone (iPhone) in year 2014 and posted a photo, see [https://twitter.com/rootkovska/status/547496843291410432 @rootkovska (on twitter.com)] ([https://nitter.net/rootkovska/status/547496843291410432 nitter]).
See also specifically [[Mobile_Phone_Security#Mobile_Devices_Hardware_Risks|Mobile Devices Hardware Risks]], [[Mobile_Phone_Security#Best_Practices|Mobiles Best Practices]] and generally [[Mobile Phone Security]].
* <u>speakers</u>: The attack paper [https://arxiv.org/ftp/arxiv/papers/1611/1611.07350.pdf SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit] does not apply to VMs. <ref>
The abstract notes: <blockquote>It's possible to manipulate the headphones (or earphones) connected to a computer, silently turning them into a pair of eavesdropping microphones – with software alone. The same is also true for some types of loudspeakers. This paper focuses on this threat in a cyber-security context. We present SPEAKE(a)R, a software that can covertly turn the headphones connected to a PC into a microphone. We present technical background and explain why most of today’s PCs and laptops are susceptible to this type of attack. We examine an attack scenario in which malware can use a computer as an eavesdropping device, even when a microphone is not present, muted, taped, or turned off. We measure the signal quality and the effective distance, and survey the defensive countermeasures.</blockquote>
</ref> While it might be possible to retask virtual sound devices with software too, the malware still cannot access the soundcard settings of the host unless there is a VM escape; QEMU developers have also concluded that no risk is posed to the host. It should be noted that virtual soundcards also have optional, half-duplex modes that make audio input impossible. <ref>
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04754.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04899.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04906.html
https://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg04904.html
* <u>HDDs</u>: Regarding the eavesdropping risk of mechanical HDDs, note that above mentioned attack does not apply to VMs where disk devices are emulated.
Disabling or Removing Microphones
For best security, external microphones should be unplugged. If the microphone is built-in and the user decides to disable it, there might be a BIOS option available. Suitably skilled users can also attempt to remove built-in microphones, although this is more difficult.
The drivers for the sound card can also be disabled, which prevents all output/input audio:
* Linux hosts: the names of the drivers can be found in <code>/proc/asound/modules</code>. To blacklist them, create a file in the <code>/etc/modprobe.d</code> folder containing <code>install (module) /bin/true</code>, for example <code>install snd_hda_intel /bin/true</code>.
* Windows hosts: the drivers can be disabled from the Device Manager.
The microphone can also be muted on Linux by running <code>alsamixer</code> and entering "M" on the microphone channel.
By default, microphones that are connected to the host are made available to virtual machines like {{project_name_long}} (except for [[KVM|{{project_name_long}} for KVM]] and [[Qubes|{{q_project_name_long}}]], see further below).Disabling microphones on the host as per above chapter would be more secure.
Select Use of Microphones
[[Multiple Whonix-Workstation|Multiple {{project_name_workstation_short}}]] should be used for:* Conducting {{whonix_wiki|text=Voice over IP (VoIP)
* Any other microphone use inside {{project_name_workstation_short}}.In this way, the microphone is used in select {{project_name_workstation_short}} and not all. The microphone should be unplugged after use.|text=Voice over IP (VoIP)
}} purposes, audio pass-through capability may need to be enabled for the respective hypervisor. The following section documents how to get audio working on [[Download|supported platforms]].
Expand for further information:
<div class="toccolours mw-collapsible mw-collapsed">
<div class="mw-collapsible-content">
[[KVM]] by default emulates a line-in/line-out in the virtual sound device, meaning microphone passthrough to guests is enabled if it is turned on for the host.
<div class="toccolours mw-collapsible mw-collapsed">
<div class="mw-collapsible-content">
[[VirtualBox]] has access to the host's microphone by default. Access can be disabled by either muting it on the host or alternatively <ref>From VirtualBox 5.2</ref> it is possible to enable/disable VM guest access to the host's microphone on the command line. <ref>https://www.virtualbox.org/ticket/12026</ref>
When the VM is stopped, run.
VBoxManage modifyvm <uuid{{!}}vmname> audioin offOr when the VM is up and running, use.
VBoxManage controlvm <uuid{{!}}vmname> audioin off<div class="toccolours mw-collapsible mw-collapsed">
<div class="mw-collapsible-content">
From Qubes R4, the desktop panel icon ("Q") is used to attach or detach microphones to select VMs: <ref>https://www.linuxjournal.com/content/whats-new-qubes-4</ref> <ref>Functionality is gradually being shifted from Qube Manager to standalone tools.</ref><code>Left-click "Q"</code> → <code>Assign the microphone to select VM</code>
or create an account