update qubes memory opsec

content/posts/qubes/index.md

@@ -280,6 +280,8 @@ If your file opens in an application other than the one you want, you'll need to
 6. Delete the file from the disposable Template (remember to empty the trash).  
 7. Shut down the disposable Template for the change to take effect. 
 
+## Sanitizing files
+
 You can also use disposables to "sanitize" an untrusted file, which means making it trusted. It does this by converting it to images in a disposable and wiping the metadata. For PDF files, right-click and select **Convert To Trusted PDF**, and for image files, right-click and select **Convert To Trusted Img**. See [the guide](https://forum.qubes-os.org/t/opening-all-files-in-disposable-qube/4674) to open all file types in a disposable by default. 
 
 # Whonix and Tor
@@ -471,22 +473,51 @@ Of the [community-recommended computers](https://forum.qubes-os.org/t/5560), the
 
 * **Root of trust**: Heads uses the [Trusted Platform Module (TPM)](https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/#tpm) to store secrets during the boot process — the Thinkpad X230 and T430 have TPM v1.1.  
 * **Blobs**: There are no binary blobs on these models after Heads is installed, except for the Intel Management Engine (which can be neutered) and the Ethernet blob (which can be generated). 
-* **Microcode updates**: Spectre and Meltdown [are mitigated by microcode updates for this generation of CPUs](https://forum.qubes-os.org/t/secure-hardware-for-qubes/19238/52) which are [installed by default on Qubes OS](https://www.whonix.org/wiki/Spectre_Meltdown#Qubes_2). Newer hardware uses CPUs with different extensions that are vulnerable to new attack vectors — the Ivy generation is not affected by these. 
+* **Microcode updates**: Spectre and Meltdown [are mitigated by microcode updates for this generation of CPUs](https://forum.qubes-os.org/t/secure-hardware-for-qubes/19238/52) which are [installed by default on Qubes OS](https://www.whonix.org/wiki/Spectre_Meltdown#Qubes_2). Some attacks target only newer CPUs, and the Ivy generation CPUs won't be vulnerable to these attacks. 
 
 Qubes OS also applies appropriate software mitigation to this class of attacks at the hypervisor level, including [disabling HyperThreading](https://www.qubes-os.org/news/2018/09/02/qsb-43/).
 
 # Appendix: OPSEC for Memory Use  
 
-To address "future not-yet-identified vulnerabilities of this kind" on older hardware that no longer receives microcode updates, the operational security (OPSEC) suggestion is to limit the presence of secrets in memory that could lead to leaks. Each running qube uses memory, and a compromised qube could use such vulnerabilities to read and exfiltrate memory used by other qubes. Disposables are reset after they are shut down, so we can assume that their compromise would likely be temporary. Perform sensitive operations in qubes without networking, and shut down secure qubes when not in use. Make sure to always be aware of which qubes are running simultaneously — it is best to only have trusted qubes alongside each other. 
+Each running qube uses memory, and a compromised qube could use CPU vulnerabilities to read and exfiltrate memory used by other qubes. To address "future not-yet-identified vulnerabilities of this kind", the operational security (OPSEC) suggestion is to limit the presence of things in memory that can be leaked by a compromised qube.
 
-* sys-usb: Disposable. Run only when needed, and shut down when finished. Restart after using an untrusted USB device. 
+Disposables are reset after they are shut down, so we can assume that their compromise would likely be temporary (for it to not be temporary, an adversary would need to escape from the virtual machine with a Xen exploit, before the disposable is shut down).  
-* sys-net: Disposable. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before compartmentalized activities that require high security.
-* [vault qube](/posts/qubes/#how-to-organize-your-qubes): 
-	* Instead of having only one vault qube that stores all files (as described above), you can compartmentalize by having different vault qubes dedicated to specific activities (i.e. `vault-personal`, `vault-project1`, etc.). This means that if a networked qube is compromised while working on project1, [intentional sniffing](https://www.qubes-os.org/doc/data-leaks/) will not have potential access to all files, but only to those files that are compartmentalized for project1.
-	* Configure KeePassXC to lock when it is unused: **Application Settings → Security → Timeouts**, enable **Lock databases after inactivity**. Configure [automatic clipboard wiping](https://www.qubes-os.org/doc/how-to-copy-and-paste-text/#automatic-clipboard-wiping), which is disabled by default. If you need a password when using an untrusted qube: 
-		* "Emergency pause" the untrusted qube(s), 
-		* start the necessary vault qube and open the KeePassXC database, 
-		* copy the credential to the global clipboard, 
-		* shut down the vault qube, 
-		* unpause the untrusted qube(s), and paste the credential  
 
+We call a qube "untrusted" when it is networked and thus might be compromised at some point, which usually corresponds to the qube's border being set to the color red. While it can be useful to distinguish levels of trust for networked qubes based on likely attack vectors (purple borders for semi-trusted, etc.), any networked qube should be considered untrusted on some level. Whenever possible, untrusted qubes should be disposable.
+
+## Principles 
+
+* Make sure to always be aware of which qubes are running simultaneously. When using an untrusted qube, do not simultaneously run any trusted qubes — **the only other qubes running should be sys qubes and other untrusted qubes**. In other words, while untrusted qubes are running there should be nothing sensitive in memory, because you are assuming that all memory could be leaked.  
+* Perform sensitive operations in trusted qubes (without networking), and shut down trusted qubes when they are not in use. The `vault` is considered a trusted qube. 
+
+## Sys qubes
+
+* sys-usb: Set as disposable during the post-installation. Run only when needed, and shut down when finished. Restart after using an untrusted USB device. 
+* sys-net: Set as disposable during the post-installation. Run only when needed, and shut down when finished. Shut down when performing sensitive operations in other qubes, if possible. Restart before compartmentalized activities that require high security.
+
+## If you need a password from KeePassXC
+
+While using an untrusted qube, you may need to have access to a password. We'll use the "Emergency pause" feature to neutralize the untrusted qube while opening the vault for the password. For instance, using the untrusted disposable qube `whonix-workstation-17-dvm`:
+
+* Using the Qubes Domains icon, "Emergency pause" the untrusted qube(s).
+* Start `vault`. Open KeePassXC and copy the required password to the global clipboard.  
+* Shutdown `vault`
+* Unpause the untrusted qube(s). You can now paste the password from the global clipboard. 
+
+## If you need a file from the vault
+
+While using an untrusted qube, you may need to copy a file from the vault. To avoid having the vault and untrusted qube running simultaneously, we'll use an intermediary offline disposable. For instance, using the untrusted disposable qube `whonix-workstation-17-dvm`:
+
+* Using the Qubes Domains icon, "Emergency pause" the untrusted qube(s).
+* Start `debian-12-offline-dvm` and `vault`. Copy the file from the vault to the disposable offline qube. 
+* Shutdown `vault`
+* Unpause the untrusted qube(s). You can now copy the file to it from the disposable offline qube. 
+
+## If you need to save a file to the vault
+
+You may also need to copy a file to the vault, so that it can be saved after the disposable is closed. Using the untrusted disposable qube `whonix-workstation-17-dvm`:
+
+* Start `debian-12-offline-dvm`.  
+* Copy the file to the disposable offline qube from the untrusted qube. 
+* When you are done using the untrusted qube, shut it down. 
+* Start `vault`. Copy the file from the disposable offline qube to the vault. [Sanitize it](/posts/qubes/#sanitizing-files) before opening. 

content/posts/router/index.md

@@ -111,3 +111,4 @@ For your VPN provider, we recommend either [Mullvad](https://www.privacyguides.o
 * Connect to the router via Wi-Fi with "Geologic-5G" or via ethernet to a LAN port. The network traffic from your laptop or phone now connects to a VPN, even though there is no VPN running on your laptop or phone.  
 	* In the case of Tails or Qubes-Whonix, this means that you now connect to the VPN *before* connecting to Tor, which is what we want. 
 * It's unnecessary to "double up" a VPN — if its running on your networking device, it doesn't need to be running on your phone or laptop, and vice-versa. This means that a phone or laptop running a VPN should disable it before connecting to Wi-Fi configured with a "VPN Kill Switch". 
+* Give visitors access to the Guest Wi-Fi so that their devices are on a compartmentalized part of the home network (a VLAN, or "virtual LAN"). Their traffic will still be routed through the VPN. 

content/posts/tails-best/index.md

@@ -154,7 +154,7 @@ Not everyone will need to apply all of the advice below. For example, if you're
 * **Use Wi-Fi that is unrelated to your identity**. We recommend this not only to protect against deanonymization, but also to protect against hacking. It is best to never use the dedicated Tails laptop on your home Wi-Fi. This makes the laptop much less accessible to a remote attacker than a laptop that is regularly connected to your home Wi-Fi. An attacker targeting you needs a starting point, and your home Wi-Fi is a pretty good one. 
 * **Remove the hard drive** — it's easier than it sounds. If you buy the laptop, you can ask the store to do it and potentially save some money. If you search on youtube for "remove hard drive" for your specific laptop model, there will probably be an instructional video. Make sure you remove the laptop battery and unplug the power cord first. We remove the hard drive to completely eliminate the hard drive firmware, which has been known to be [compromised by hackers](https://www.wired.com/2015/02/nsa-firmware-hacking/). A hard drive is part of the attack surface and it is unnecessary on a live system like Tails that runs from a USB. 
 * Consider **removing the Bluetooth interface, camera, and microphone** while you're at it, although this is more involved — you'll need the user manual for your laptop model. The camera can at least be "disabled" by putting a sticker over it. The microphone is often connected to the motherboard via a plug — in this case just unplug it. If this is not obvious, or if there is no connector because the cable is soldered directly to the motherboard, or if the connector is needed for other purposes, cut the microphone cable with a pair of pliers. The same method can be used to permanently disable the camera. It is also possible to use Tails on a dedicated "offline" computer by removing the network card as well. Some laptops have switches on the case that can be used to disable the wireless interfaces, but for an "offline" computer it is preferable to actually remove the network card.  
-* **Establish boot integrity by replacing the BIOS with [Heads](https://osresearch.net/)**. Security researchers [demonstrated an attack](https://www.youtube.com/watch?v=sNYsfUNegEA) on the BIOS firmware of a Tails user, allowing them to steal GPG keys and emails. Unfortunately, the BIOS cannot be removed like the hard drive. It is needed to turn on the laptop, so it must be replaced with [open-source](/glossary/#open-source) firmware. This is an advanced process because it requires opening the computer and using special tools. Most anarchists will not be able to do this themselves, but hopefully there is a trusted person in your networks who can set it up for you. The project is called Heads because it's the other side of Tails — where Tails secures software, Heads secures firmware. It has a similar purpose to the [Verified Boot](https://www.privacyguides.org/en/os/android-overview/#verified-boot) found in GrapheneOS, which establishes a full chain of trust from the hardware. Heads has [limited compatibility](https://osresearch.net/Prerequisites#supported-devices), so keep that in mind when buying your laptop if you plan to install it — we recommend the ThinkPad X230 because it's less involved to install than other models. The CPUs of this generation are capable of effectively removing the [Intel Management Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine#Assertions_that_ME_is_a_backdoor) when flashing Heads, but this is not the case with later generations of CPUs on newer computers. [Coreboot](https://www.coreboot.org/users.html), the project on which Heads is based, is compatible with a wider range of laptop models but it is inferior. Heads can be configured to [verify the integrity and authenticity of your Tails USB](https://osresearch.net/InstallingOS/#generic-os-installation), preventing it from booting if it has been tampered with. Heads protects against physical and remote classes of attacks on the BIOS firmware and the operating system software! If Heads ever detects tampering, you can get in touch with [Access Now’s Digital Security Helpline](https://accessnow.org/help).
+* **Establish boot integrity by replacing the BIOS with [Heads](https://osresearch.net/)**. Security researchers [demonstrated an attack](https://www.youtube.com/watch?v=sNYsfUNegEA) on the BIOS firmware of a Tails user, allowing them to steal GPG keys and emails. Unfortunately, the BIOS cannot be removed like the hard drive. It is needed to turn on the laptop, so it must be replaced with [open-source](/glossary/#open-source) firmware. This is an advanced process because it requires opening the computer and using special tools. Most anarchists will not be able to do this themselves, but hopefully there is a trusted person in your networks who can set it up for you. The project is called Heads because it's the other side of Tails — where Tails secures software, Heads secures firmware. It has a similar purpose to the [Verified Boot](https://www.privacyguides.org/en/os/android-overview/#verified-boot) found in GrapheneOS, which establishes a full chain of trust from the hardware. Heads has [limited compatibility](https://osresearch.net/Prerequisites#supported-devices), so keep that in mind when buying your laptop if you plan to install it — we recommend the ThinkPad X230 because it's less involved to install than other models. The CPUs of this generation are capable of effectively removing the [Intel Management Engine](https://en.wikipedia.org/wiki/Intel_Management_Engine#Assertions_that_ME_is_a_backdoor) when flashing Heads, but this is not the case with later generations of CPUs on newer computers. Heads can be configured to verify the integrity and authenticity of a Tails USB — [see the documentation](https://osresearch.net/InstallingOS/#generic-os-installation), preventing it from booting if it has been tampered with. Heads protects against physical and remote classes of attacks on the BIOS firmware and the operating system software! If Heads ever detects tampering, you can get in touch with [Access Now’s Digital Security Helpline](https://accessnow.org/help).
 
 * **Use USBs with secure firmware**, such as the [Kanguru FlashTrust](https://www.kanguru.com/products/kanguru-flashtrust-secure-firmware-usb-3-0-flash-drive), so that the USB will [stop working](https://www.kanguru.com/blogs/gurublog/15235873-prevent-badusb-usb-firmware-protection-from-kanguru) if the firmware is compromised. Kanguru has [retailers worldwide](https://www.kanguru.com/pages/where-to-buy), allowing you to buy them in person to avoid the risk of mail interception.