This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Failed to load latest commit information.
Intro ====== Anti Evil Maid is an implementation of a TPM-based dynamic (Intel TXT) trusted boot for dracut/initramfs-based OSes (Fedora, Qubes, etc.) with a primary goal to prevent Evil Maid attacks. In short, AEM relies on TPM and a feature found in Intel's vPro CPUs (TXT) to detect tampering of various boot components. For more information and discussion about potential attacks see: http://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html (Note that this article is somewhat outdated, e.g. AEM uses Intel TXT now.) Requirements and security notes ("before you start") ==================================================== * Only TPM version 1.2 is currently supported. It may be possible to configure your 2.0 TPM to emulate the 1.2 interface. * AEM is not compatible with (U)EFI boot. Legacy boot is required. * If you are using LUKS with LVM, you must encrypt the whole volume group instead of each volume, or else AEM will fail to boot. * You MUST set a TPM owner password * Unless you're installing AEM to internal disk, TPM SRK password SHOULD NOT be set (otherwise tboot will not be able to check whether critical parts of RAM were not altered during S3 sleep). Please be aware that by installing to internal disk and setting a TPM SRK password, your RAM WILL NOT be protected against tampering when your laptop is suspended, so make sure it is completely shut down any time an attacker might gain physical access. * When RAM tampering is detected on wake-up from S3 sleep, the default tboot policy only prints a warning into its log (`sudo txt-stat`) so even if you checked it immediately after each wake-up, the attacker might already have exfiltrated your login passphrase. Fix this by either using two-factor for desktop login (weak) or create stronger Launch Control Policy (LCP) and Verified Launch Policy (LCP) and write them into TPM NVRAM -- especially make sure that tboot will forcefully halt/reboot the platform if RAM tampering is detected. See tboot docs for more information (`/usr/share/doc/tboot`). Creating a small NVRAM area for tboot to write last error code might be a good idea for debugging crashes on S3 suspend/resume: `sudo tpmnv_defindex -i 0x20000002 -s 8 -pv 0 -rl 0x07 -wl 0x07 -p <ownerpw>` * Be aware that Intel TXT is vulnerable to System Management Mode (SMM) exploits like overwriting System Management Interrupt (SMI) handlers. Since SMM code is stored in platform firmware (BIOS) which usually is updatable (and thus can be overwritten by an attacker), it is quite an attractive target (and not just for the NSA). This can be fixed by integrating an SMI Transfer Monitor (STM) into the platform (but this, again, relies on the the same BIOS vendor who wrote a buggy SMM code to safely implement STM). Additionally, STM does not appear to be widely available yet (STM specification released mid-2015 by Intel). You can check whether your platform includes STM: `sudo txt-stat | grep -iA 1 stm` Seeing "stm: 0" and "stm_hash" being all zeros means you DO NOT have STM. Either way, BIOS is now part of your Trusted Computing Base (TCB) and you need to prevent attackers with physical access from modifying it. Good luck. Some hints: connect the write protect pin on BIOS flash chip to ground (prevents attacker from booting their own software which would bypass BIOS protections and overwrite it) and make sure physically accessing the chip will be tamper-evident by eg. covering the screws holding laptop body together in glitter and taking high-res photos, then examining before each use. * You might want to consider assessing the firmware security of your platform using an automated tool such as CHIPSEC: https://github.com/chipsec/chipsec * To recap -- you need to fully trust: * CPU (Intel, since we're depending on TXT) * sometimes over-optimizes for performance at the cost of security, see eg. Meltdown/Spectre, cache attacks against SGX enclaves, ... * TPM (various vendors) * few known attacks sniffing and injecting commands on the LPC bus; differential power analysis; buggy RSA key generation code * note that any potential TPM exploits (should) have no means of compromising your system directly -- a TPM under attacker's control can only be used to hide the fact that a compromise has occurred (ie. defeating the whole AEM feature) * BIOS (a few vendors) * it's full of holes! * that the attacker cannot get physically inside your laptop without you noticing (see the glitter hint above) Upgrading to AEM v4 =================== If you have an existing AEM installation, there are a few steps required after updating AEM packages to version >= 4.0 (available since Qubes R4). The easiest way to upgrade is to completely reset the TPM and start from scratch and re-create all existing AEM devices. Should you want to migrate without resetting the TPM (in case you're using it for something else besides Qubes AEM), you can manually replicate the steps taken in the TPM setup script (/usr/sbin/anti-evil-maid-tpm-setup). Note that you still need to re-create all provisioned AEM media afterwards. Otherwise, perform a TPM reset (via BIOS) and skip to the "Installation" section below. Installation ============= The instructions below assume Qubes OS. 1) Enable TPM in BIOS. Also enable TXT if there is an option for it. 2) Install and Verify TPM support under your OS/Dom0. a) Install anti-evil-maid packages (in Dom0 on Qubes). It will install all the required dependencies and tools. # qubes-dom0-update anti-evil-maid b) Verify kernel support for TPM: # cat /sys/class/tpm/tpm0/pcrs If you see something like this: PCR-00: 67 DC B4 8C AB 8D C7 9B 28 84 D9 15 69 DE 82 F2 F0 E1 2A D8 PCR-01: 11 75 9A 19 E5 BD E8 4E DA 1C 01 EC 53 87 FD 50 18 E1 94 1E PCR-02: 4B 43 98 82 65 04 E9 F4 14 78 26 F9 ED EA 92 91 6D FD AF D5 PCR-03: B2 A8 3B 0E BF 2F 83 74 29 9A 5B 2B DF C3 1E A9 55 AD 72 36 PCR-04: 93 33 4E 81 A6 9C 80 54 D6 87 C7 FD 76 7C 6F 4C 70 FC C6 73 (...) ... then your TPM is supported by your kernel. If your tpm has already been owned in the past, you can reset it by running tpm_clear -z, powering your computer off, and then resetting TPM in the BIOS (e.g.: TPM Authentication Reset). c) Initialize the TPM for use with AEM # anti-evil-maid-tpm-setup -z In case you want to install AEM to an internal disk, an SRK password must be set up in order for AEM to be secure. The SRK password can be set up by NOT passing the "-z" option to the above command. Should you not anticipate future need for internal AEM boot device and want to use external media only, use the "-z" option. If you later decide to provision AEM on the internal drive, create an SRK password first: # tpm_changeownerauth -s You will need to copy & paste the randomly-generated TPM owner password from the /var/lib/anti-evil-maid/tpm-owner-pw file. Existing AEM media will _not_ need to be re-sealed. 3) Setup Anti Evil Maid a) SINIT module You should download the SINIT module required for your system. Intel documented the required SINIT module depending on your CPU platform in: http://software.intel.com/en-us/articles/intel-trusted-execution-technology But DO NOT download the modules besides the SINIT/RACM from here. The download links provide old versions and broken binaries. You can then download the module and unzip it. All the modules could be downloaded from: https://cdrdv2.intel.com/v1/dl/getContent/630744?wapkw=intel%20txt%20sinit%20acm%20revocation%20 Find the module fitting to your platform and rename it to the names mentioned on the intel website link. Also, make sure you have the latest RACM update, if available (2nd & 3rd gen): https://software.intel.com/system/files/article/183305/intel-txt-sinit-acm-revocation-tools-guide-rev1-0_2.pdf It's possible to use 3rd gen SINIT/RACM on 2nd gen platforms. In fact, the only RACM available at the time of writing is for the 3rd gen, while the 2nd gen platforms were also affected by the buffer overflow bug in old SINIT version. Finally, you should retrieve the BIN file inside /boot in dom0. E.g., run from dom0: $ sudo -s # qvm-run --pass-io vm_name_containing_bin_file 'cat /home/user/path_to_sinit/name_of_sinit_file.BIN' > /boot/name_of_sinit_file.BIN NOTE: The SINIT files are digitally signed by Intel. While there is no easy way to verify their integrity after downloading (and after copying to Dom0), still, the operation of placing such a file into Dom0's /boot filesystem should be reasonably safe to do -- after all the file should not be processed by any software in Dom0, and only by the SENTER instruction of the processes, which, we hope, correctly verifies the signature before executing it... b) Create an Anti Evil Maid device: # anti-evil-maid-install -h Please note that each AEM device you provision should have a unique filesystem label suffix (use the '-s' option). You may safely re-use suffixes for destroyed devices. Installation directly onto a (truly) read-only media (such as a CD-R) is not supported. You can, however, copy the contents of an existing RW media onto RO media after the initial sealing takes place. Physical write-protect switches on USB sticks are fine (install AEM in RW mode, then flip the switch and proceed to use as RO media). Remember to always pull out the RO media when your text secret or TOTP code is displayed! Failing to do that will result in invalidation of freshness token in the TPM memory and the AEM media will fail to perform verified boot next time, falling back to non-AEM-protected mode. For example, to install on the internal boot partition (assuming that it is /dev/sda1): # anti-evil-maid-install /dev/sda1 Or better, create an external AEM boot device (in this case an SD card): # anti-evil-maid-install /dev/mmcblk0p1 Alternatively, a multi-factor authentication AEM boot device can be created, which provides additional protection against shoulder surfing and video surveillance -- with the above setups, if an attacker sees your disk encryption password as you're typing it then they can simply steal and decrypt your computer. Long story short, if you ever need to boot your AEM-protected computer in public or anywhere a camera may be hidden, this is the thing you want to use. However, this setup requires an external boot media (eg. USB stick or memory card) for maximum protection and owning a suitable two-factor authentication device supporting time-based one-time passwords (TOTP). There are apps available for Android/Apple smartphones (Google Authenticator, FreeOTP Authenticator) and Windows Phone (Microsoft Authenticator). You can also use a dedicated hardware token, either a reseedable one (letting the AEM installer generate a seed for you), or a manufacturer-seeded token (you will need to store the seed in /var/lib/anti-evil-maid/aem<suffix>/secret.otp in base32 format, then run the AEM installer). The command to set this all up is simple: # anti-evil-maid-install -m /dev/sdb1 This will automatically generate a TOTP seed and display it as a QR code for you to enroll on your 2FA device (if it doesn't have a camera, there's also text version for manual entry). Once a successful TOTP seed enrollment is verified (you need to enter the 6-digit code displayed on your 2FA device), a LUKS key file will be randomly generated and encrypted by a password of your choice (make sure you're not using this password for anything else). This key file will then get added to your encrypted drive's LUKS key slot. For more details, see the associated qubes-devel mailing list thread: https://groups.google.com/d/topic/qubes-devel/8cAjSyg1msM/discussion In case you would like to install multi-factor AEM on internal disk, beware that keyboard observation attacks cannot be prevented! Plus, you still need to have TPM SRK password set. The only advantage over plain static text secret is, of course, that there's not static secret **shown on the screen** to observe (ie. cover the keyboard while typing AEM passwords). If you've chosen to install AEM on an external device (and not the internal drive), you should then remove the internal boot partition from dom0's /etc/fstab, never mount it again in dom0, and never boot from it again, because an attacker might modify it to exploit GRUB or dom0 filesystem drivers. Note: If you choose to use a USB device (e.g., a flash drive) as your AEM device and you previously created a USB qube, then you may have to unhide your USB controller from dom0: 1. Open the file `/etc/default/grub` in dom0. 2. Find the line that begins with `GRUB_CMDLINE_LINUX`. 3. If present, remove `rd.qubes.hide_all_usb` from that line. 4. Save and close the file. 5. Run the command `grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. 6. Reboot. c) Create a secret text (note: it cannot be larger than 255 bytes): Note: This step is unnecessary if using the multi-factor auth setup, but can serve as a fallback option in case you ever find yourself temporarily not having access to your 2FA device (eg. smartphone or hardware TOTP token). # cat >/var/lib/anti-evil-maid/aem/secret.txt <<END My secret text has two lines END Note: You are saving this not-yet-sealed secret to your root filesystem without further encryption (besides that provided by LUKS). If an attacker somehow gains access to your decrypted filesystem data, e.g. by compelling you to reveal the LUKS passphrase, they can of course see these secrets. So they are probably not the right place to store your most intimate confessions. ;) 4) Reboot the system, choose one of the entries called "AEM Qubes". This will attempt to perform a "measured launch" using tboot and the SINIT module you downloaded, which records the Xen, kernel, and initrd versions used in PCRs 17-19 of the TPM for use in sealing and unsealing your secret. If the measured launch fails for any reason, tboot will fall back to a normal boot and AEM will not function. a) Enter your SRK password if prompted. You won't see your secret afterwards, because it hasn't been sealed yet (seeing a `Freshness token unsealing failed!` message here is expected). Enter your disk decryption passphrase anyway, right now you still trust your system. As the system continues booting, AEM will automatically seal your secret(s). You should see a line, or multiple lines, like this one: Sealed /var/lib/anti-evil-maid/aem/secret.txt using --pcr 13 --pcr 17 --pcr 18 --pcr 19 Debug output can be read using: $ journalctl -u anti-evil-maid-unseal -u anti-evil-maid-seal Note: The PCRs used to seal to can be changed in /etc/anti-evil-maid.conf -- though the defaults should work just fine. If you decide to change them and you want to reseal immediately, run anti-evil-maid-seal manually once. If you get a message that the "PCR sanity check failed" and you are sure you have saved the right SINIT blob in step 3.a, then check the tboot log for details. The easiest way to view it is to set "logging=vga vga_delay=10" on the "multiboot /tboot.gz" line in grub.cfg and reboot. Alternatively, run `sudo txt-stat` from dom0. For more information, see the tboot readme (/usr/share/doc/tboot/README on an installed system). b) If a chunk of your installed RAM seems to be missing after the reboot (which can be checked by running "xl info" in dom0), do the following: # echo 'export GRUB_CMDLINE_TBOOT=min_ram=0x2000000' >>/etc/default/grub # grub2-mkconfig -o /boot/grub2/grub.cfg Then go to step 4.a again. A discussion of this problem can be found at http://thread.gmane.org/gmane.comp.boot-loaders.tboot.devel/610/focus=611 and by searching for "min_ram" in the qubes mailing lists. c) Now, every time you boot your system (from your Anti Evil Maid stick) you should see your secret text or TOTP code displayed *before* you enter your LUKS disk encryption or key file passphrase. Xen/kernel/BIOS/firmware upgrades ================================== After Xen, kernel, BIOS, or firmware upgrades, you will need to reboot and enter your disk decryption passphrase even though you can't see your secret. Please note that you will see a `Freshness toekn unsealing failed!` error. It (along with your AEM secrets) will be resealed again automatically later in the boot process (see step 4.a). Some additional things that can cause AEM secrets and freshness token to fail to unseal (non-exhaustive list): * changing the LUKS header of the encrypted root partition * modifying the initrd (adding/removing files or just re-generating it) * changing kernel commandline parameters in GRUB What to do in case of compromise ================================ For a discussion of potential attacks against Anti Evil Maid, see the article referenced at the beginning. AEM media copied/stolen by an attacker -------------------------------------- If you have your system up and running or have an extra AEM media using which you can boot the system before the attacker can get to it: * `sudo -s` in dom0 * `. /usr/sbin/anti-evil-maid-lib` (note the dot at the beginning) * `revokefreshness <suffix>` (where `<suffix>` is the missing label suffix) In case you do not remember the used media label suffix, take a look at `/var/lib/anti-evil-maid/`. If the particular media had no special suffix set (i.e. if the subdirectory is just named `aem`), use `revokefreshness ""`. Alternatively, `resetfreshness` will wipe all freshness tokens from the TPM (thus invalidating all enrolled AEM media and forcing you to boot an unverified system). As a last resort, you can attempt to reset the TPM from BIOS (with similar effect to `resetfreshness`). Otherwise, it's game over. Someone saw my LUKS passphrase ------------------------------ You should've installed AEM in multi-factor mode. If you're fairly confident the attacker does not possess a bitwise copy of your encrypted Qubes OS drive, change the LUKS passphrase: * determine the path to LUKS-encrypted disk (usually /dev/sda2) * add a new password with `sudo cryptsetup luksAddKey <disk>` * remove old one with `sudo cryptsetup luksRemoveKey <disk>` As these actions will change the LUKS header, which is fed into one of the TPM PCRs upon each AEM boot, all the existing AEM media will get invalidated (ie. fall back to unverified boot). Beware that solid-state devices will most likely NOT overwrite the LUKS header, but rather write the new one into another memory cell (due to wear leveling algorithms designed to prolong SSD life). If you're worried about this and have recent-enough backups (as you always should), perform an ATA secure erase of the whole SSD using a live CD and then reinstall Qubes OS. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase Someone saw my text secret -------------------------- Again, if you're going to boot your Qubes OS in public places, using multi-factor AEM is strongly recommended. Assuming the attacker haven't yet had access to your computer (in order to install a compromised bootloader which will show the correct secret but record your LUKS passphrase), simply changing the text secret and re-creating affected AEM media (if you used same secret for multiple ones) will do. The text secrets are stored in `/var/lib/anti-evil-maid/aem<suffix>/secret.txt` Make sure to never trust the old text secret ever again! TODO: write up more scenarios and how to recover, best practices
No packages published