On Wednesday, July 29, 2020 at 2:33:29 AM UTC-4, Qubes wrote: > > On 7/29/20 1:56 AM, ludwig...@gmail.com wrote: > > *What if it saves a spare set of encryption keys somewhere in its flash > for > > the "lawful investigator" to find?* > > > I am not aware of any proof to support this line of thinking. >
My position: if you have critical secrets, then your solution should be combining belt and suspenders, that is, you should apply layers of encryption with different keys and passwords. 1. First if your main drive supports it, enable hardware encryption. Even if you don't trust the device manufacturer (perhaps they, as posited aove "save a spare set of encryption keys somewhere in its flash"*), it is still an additional layer of protection. In particular, the password/pin should be different than password/pin used for LUKS in section #2 for separation of trust. This can also provide some boot drive tamper protection by at least a subset of attackers. alternate 1a. boot qubes off of a a SED SATA/NVME drive: implement using something like sedutil or even TCP Opal Class 0 encryption if your BIOS supports it (Class 0 leverages the TCG Opal SED engine using an ATA Password with some bits of security lost due to password filtering depending upon BIOS implementation) and you semi-trust the drive manufacturer. alternate 1b. boot qubes off of a USB drive with a hardware encryption bridge/enclosure and a pinpad password (very long is better, if supported). Again, you must semi-trust the manufacturer of the encryption engine, of course. 2. Set up qubes with a LUKS layer and a password (pretty much, the standard install) on the drive you have configured above. You must semi-trust the Qubes, LUKS and linux developers, of course (open source allows audit, so either do it yourself or...hope/verify someone else did). Password should be different than the hardware device password in #1 for separation of trust. Above are the basic belt and suspenders. Section #1 utilizes the hardware encryption you may already have and gives you a bonus of some additional protection against modification of the boot data on the drive. The TCG Opal Class 0 approach should not interfere with installation of AEM. Standard TCG Opal via sedutil requires additional custom work to support AEM. Section #2 gives you the more trusted layer of software encryption. Now for some additional soap-box comments, generally under the heading of Qubes currently != anti-forensics: 1. Disposable VMs do not promise any anti-forensics properties if your system is up and running (that is, the LUKS volume is mounted). Disposable VMs have a primary purpose which is* not* to "forget" information, but rather to prevent attacks inside a VM from being permanent (prevent foothold) and partition your data so that attacks within the disposable VMs cannot accessing your data. Typically**, the data used in a disposable VM remains on the storage device even after the VM is shutdown until that space is needed again to store something else. 2. Attaching devices to dom0 puts dom0 at risk. Even unmounted devices can be unintentionally automatically mounted or at least partition/volume scanned when running various toolkit-based executables such as thunar (xfce's file explorer equivalent) or anything else that invokes the xfce windowing toolkit components or similar in dom0. 3. Attaching devices to dom0 can pollute dom0 memory/storage with content from that device. For the above reasons, among others. 4. Fragments of VM sessions can end up in the dom0 or GUIVM user folder and/or system/application logs. E.g. one can find the window titles of domU VM windows (including disposable VMs or even VMs stored in secondary pools) stored in the dom0 main user's dot (hidden) directories. 5. Until very recent changes to the qubes thin pool driver (available in 4.1 only?), disposable VM's volatile volumes on LVM were always being stored in the primary pool. EVEN if the disposable VM and the disposable VM templates were stored in a secondary pool on a separately encrypted device. This behavior was surprising to many and I consider it a defect. Hope this is helpful, Brendan * Most SED/TCG OPAL drives can be fully rekeyed using one or more of the following ATA SANITIZE CRYPTO EXT, ATA SECURE ERASE ENHANCED, or a PSID REVERT. Some support all three invocations, some a subset. Some manufacturers go out of their way to *only* rekey (and not erase) when invoking the first two, so you can check to see your data is irrevocably scrambled after invocation. Ok, maybe you don't trust the drive manufacturer to not log all keys in the clear for entities they have relations with? Fine. But at least get in the practice of rekeying the drive a couple times before putting data on it that way if they're only storing the factory key, well...(takes off tin foil hat). ** Note that the Qubes thin volume storage driver will attempt to perform "opportunistic" anti-forensics, with no strong guarantee, when an lvm volume is removed by the drive. It does this by invoking a blkdiscard against the thin volume before removal when removal is invoked. If the user has enabled trim through the LUKS layer in dom0 (not a default setting, and setting choice depends upon your threat model)...and the physical storage device supports discard/trim, that encrypted data will be removed from the user-facing data interface on the drive (though may still linger for a while before the containing blocks are erased). In addition, if the physical drive supporting trim is a TCG Opal SED device that is well-behaved, an additional layer of obfuscation kicks in which is that the physical blocks are no longer mapped to the logical blocks, and since in most known implementations, the logical block number is part of the IV for the AES applied to the data on the physical block, now both the software *and* hardware level IVs are lost for that doubly encrypted data that is in the erase queue. But mostly, the opportunistic anti-forensics is about the discard/trim at the physical drive level: removing the blocks from the user-facing data interface plus queuing up the blocks to be erased in the primary erase queue at some future point. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/370ca35e-3c94-400e-9f2f-411f5c584407o%40googlegroups.com.
