Microphones[edit]

Eavesdropping Risk[edit]

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 Whonix-Workstation ™ (anon-whonix) is ever compromised by malware, an adversary could eavesdrop through the microphone. ^[3] 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. ^{[4] [5]} This also applies to touch screen devices like smartphones and tablets. ^[6]

The attack paper SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit ^[archive] does not apply to VMs. ^[7] 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. ^{[8] [9] [10] [11]}

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: ^[12]

1. An attacker needs to physically tamper with the targeted equipment. ^[13]
2. 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.

Note that this attack does not apply to VMs where disk devices are emulated. While the SSD alternative avoids this threat, it has the drawback of uncertainty when encrypted volume headers are deleted or encryption passphrases are changed.

Voice Recognition[edit]

It is safe to assume that everyone has had an unencrypted phone call during their lifetime and that one of them has been recorded. Voiceprints allow a person to be identified from the specific characteristics (acoustics) of their voice and it is a useful biometric marker. ^[14] This means personal and unique voiceprints can be used to link non-anonymous and "anonymous" voice samples; a process called voice recognition and documented on the VoIP wiki page in the introduction chapter. ^[15]

Disabling or Removing Microphones[edit]

By default, microphones that are connected to the host are made available to virtual machines like Whonix-Workstation ™ (except for Whonix ™ KVM on Buster hosts and Qubes-Whonix ™, see further below).

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: the names of the drivers can be found in /proc/asound/modules. To blacklist them, create a file in the /etc/modprobe.d folder containing install (module) /bin/true, for example install snd_hda_intel /bin/true.
• Windows: the drivers can be disabled from the Device Manager.

The microphone can also be muted on Linux by running alsamixer and entering "M" on the microphone channel.

Select Use of Microphones[edit]

Multiple Whonix-Workstation ™ should be used for:

• Making Internet calls.
• Conducting Voice over IP (VoIP).
• Any other microphone use inside Whonix-Workstation ™ (anon-whonix).

In this way, the microphone is used in select Whonix-Workstation ™ and not all. The microphone should be unplugged after use.

For 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 supported platforms.

Expand for further information:

VBoxManage modifyvm <uuid|vmname> audioin off

VBoxManage controlvm <uuid|vmname> audioin off

Speakers[edit]

Profiling Threat[edit]

Newer methods of advertisement tracking can link multiple devices via ultrasound covert channels. This deanonymization technique works by playing a unique sound inaudible to human ears which is picked up by the microphones of untrusted devices. Watermarked audible sounds are equally dangerous, which means that hardware incapable of ultrasound is an ineffective protection. ^[20]

There are multiple ways inaudible beacons can be used for surveillance, including to de-anonymize users of the Tor network: ^[21]

• The first is media tracking: audio from the user's television may be detected by the microphone in the user's mobile device, allowing malicious actors to gain access to what the user is watching––particularly if it is salacious. Advertisers can similarly gain insight into what a user typically watches. In both scenarios, a user's real-world behavior is linked to their online identity and used for tracking.
• Another form of tracking permitted by ultrasonic tracking is cross-device tracking, which enables a user's profile to be connected across multiple devices based on proximity. This form of tracking, in linking different devices, can help advertisers show more targeted ads or open individuals to attacks by malicious actors.
• Location tracking is yet another privacy concern. Indeed, ultrasonic signals can convey location information via a location identifier, often placed in stores or businesses.
• Lastly, this new ultrasonic tracking poses a threat to users of Bitcoin and Tor because it de-anonymizes a user's information, since ultrasonic signals associate the user's mobile phone with the Bitcoin or Tor account.

Researchers have also demonstrated that air-gapped computers in the same room can exchange data via ultrasonic waves, whether they are equipped with earphones, headphones or passive speakers. Contrary to the expectations of most computer users, microphones are not required. In fact speaker-to-speaker communication was used to transmit data between computers up to nine meters away from one another. In the case of headphones, data could be exchanged up to a distance of three meters. ^[22]

It is also possible to issue hidden, ultrasonic voice commands with speech recognition systems like Siri or Google in order to control other systems. For example proof-of-concept attacks using "DolphinAttack" included activating Siri to initiate a FaceTime call on iPhone, manipulating the navigation system in an Audi vehicle, and activating Google Now to switch the phone to airplane mode. ^[23]

Interested readers are suggested to view the following demonstration videos:

• MOSQUITO: Jump air-gaps via speaker-to-speaker communication ^[archive]
• Your phone is LISTENING to you - ultrasonic cross-device tracking ^[archive]

Countermeasures[edit]

Countermeasures can be categorized into hardware and software considerations. ^{[22] [23]}

Obvious physical countermeasures include utilizing computers that are speaker-less (and preferably microphone-less). This may require physically removing speakers (and the beeper) which is very difficult. ^[24] Those at high risk should also avoid the use of headphones, earphones or simple earbuds because this eliminates the risk they can exploited by malware and converted into eavesdropping microphones or data exfiltration tools. If this is not feasible in the circumstances, then prefer always connecting headphones instead of using passive speakers.

It is also advisable to have (air-gapped) computers in strict physical isolation and not in close proximity to other computers or electronic devices. Other devices should always be considered potential eavesdropping, profiling or even data exfiltration threats. In the worst possible scenario, other devices may even be able to issue commands that affect functioning on the primary device used for anonymous activities (although research shows devices must be in close proximity; around one meter).

Software countermeasures include completely disabling audio hardware in the UEFI/BIOS settings. ^[25] The downside is audio hardware will be completely unusable. If possible, also disable the beeper in UEFI/BIOS settings.

Webcams[edit]

Webcams on infected machines can be used to take snapshots, record video or eavesdrop using the built-in microphone. Recent research ^[archive] reveals that even remote screen views can be accurately determined via webcams, due to "content-dependent acoustic leakage from LCD screens." ^[26]

Always check if the computer or notebook has a webcam; one might be built-in, but have gone unnoticed. Check the computer's datasheet and operating system hardware manager to be sure. It is recommended that (external) webcams are disabled or removed, unless there are immediate plans to use it inside Whonix-Workstation ™ (anon-whonix). Once a webcam session has finished, it should be disabled and preferably unplugged straight away.

If the webcam is built-in, check whether it can be disabled with a BIOS setting. Suitably skilled users can attempt to remove built-in webcams, although this may be difficult. As a stop-gap measure, the webcam can always be covered with thick adhesive tape or a cap, so long as it is opaque.

If a BIOS option is unavailable or it is impossible to physically disable the webcam, then the webcam drivers should be disabled:

• Linux: a file must be added to the /etc/modprobe.d folder that contains blacklist uvcvideo. This blacklists the webcam driver from loading.
• Windows: the webcam driver can be disabled from the Device Manager.

Wireless Input Devices[edit]

Avoid using wireless keyboards and mice because most send data unencrypted. Even if this was not the case, the robustness of the cryptography involved in proprietary products cannot be verified. A local adversary up to 100 meters away can sniff keystrokes and inject their own, allowing them to take over the machine.^{[27] [28]}

Advanced Threats[edit]

While most users are capable of minimizing the threats posed by microphones, speakers, webcams and wireless input devices, this presupposes that the underlying hardware has not itself been compromised. In recent years researchers have focused on the risks posed by hardware trojans, which involves (quote modified from original source to clarify): ^[29]

...malicious modification of the circuitry of an integrated circuit. A hardware Trojan is completely characterized by its physical representation and its behavior. The payload of an HT is the entire activity that the Trojan executes when it is triggered. In general, malicious Trojans try to bypass or disable the security fence of a system: It can leak confidential information by radio emission. HT's also could disable, derange or destroy the entire chip or components of it. Hardware Trojans may be introduced as hidden "Front-doors" that are unknowingly inserted during the design process of a computer chip in the schematic files. This can be done by compromising the machines of chip architect firms. This method is more difficult to detect than searching for extra malicious chips added during the manufacturing phase. Relying on pre-made application-specific integrated circuit (ASIC) semiconductor or intellectual property cores (IP Core) that have been purchased from a non-reputable source, or inserted internally by a rogue employee or state sponsored spying and espionage, exposes end consumers to supply chain attacks.

The implication is that virtually any purchased hardware, particularly from non-reputable sources, could have hardware trojans that might cause data/password leaks, allow remote attackers access and extraction of cryptographic keys. While physical inspection, destructive testing by comparing manufactured chips to a "golden chip", functional testing and built-in tests can help to identify hardware trojans, this is costly and only feasible for technically competent individuals or agencies. ^[30]

Recent research suggests that advanced hardware trojans may not be detectable by existing means if they are implemented below the gate level: ^[31]

Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against “golden chips”.

In this case researchers demonstrated that "Dopant-level hardware trojans" could break any key generated by Intel's secure RNG design while still passing the functional Intel testing procedure and the NIST random number test suite, as well as creating hidden side-channels to leak out secret keys from a side-channel resistant SBox implementation. While military, corporate and government entities are most likely to be targeted by stealthy hardware trojans, this illustrates that virtually no hardware is safe from determined and well-funded adversaries. It is also a cautionary tale against relying exclusively on any hardware RNG for generating secrets.

For most people the only practical countermeasure against hardware trojans is considering the manufacturing source of computer equipment. For example, it is inadvisable to purchase devices from Chinese original equipment manufacturers (OEMs) due to suggestions that manufacturing subcontractors previously added hardware trojans to server motherboards. ^{[32] [33]}

References[edit]

	100px
Fosshost	About Advertisements

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki

Follow:

Support:

Donate:

Priority Support | Investors | Professional Support

Whonix ™ | © ENCRYPTED SUPPORT LP | Freedom Software / Open Source (Why?)

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.