In general it is inadvisable to provide potential adversaries with physical access to a device since they could remove the disk, reflash the BIOS and exfiltrate the TPM. Obviously the safest way to protect against evil maid attacks is to always have the device(s) in your possession. If this is not possible, then placing the device in a safe or lockbox might be feasible. Also consider possible scenarios where the device can be temporarily removed for inspection, like during airport security screening or by law enforcement personnel. Simpler measures that provide some protection include keeping firmware up-to-date and always shutting down unattended devices.
Various methods can be used to detect whether an unattended device has been potentially exposed or handled by nearby persons, including: <ref>
https://en.wikipedia.org/wiki/Evil_maid_attack#Detection</ref>
* [https://guardianproject.github.io/haven/ Haven Android application] <ref>
<blockquote>It is an Android application that leverages on-device sensors to provide monitoring and protection of physical areas. Haven turns any Android phone into a motion, sound, vibration and light detector, watching for unexpected guests and unwanted intruders.</blockquote> Event monitoring is transmitted to the user's smartphone.
* use of tamper-evident technology or low-cost solutions to detect tampering <ref>
Such as the use of glitter over screw holes.
If tampering is suspected, the device can be checked for possible malware. Unfortunately this is a difficult exercise and it may just be safer to discard the potentially compromised hardware.
To protect against compromise, it is recommended to utilize hardware with a TPM interface and to configure Anti Evil Maid (AEM) software. AEM authenticates the device to the user since it will only unlock if the correct password is entered and it determines no unauthorized code has been executed on the device. <ref>Root of trust systems like Intel's TXT technology are used for this purpose.</ref> This can avoid compromise as users are notified if any files in the <code>/boot</code> partition are modified; verification occurs before the password is entered. <ref>
https://github.com/unman/notes/blob/master/openBSD_as_netvm
It should be noted that AEM security is imperfect because it relies upon a closed source TPM. Further, in Intel's case SINIT binary modules are downloaded so that Intel Trusted Execution Technology (Intel TXT) can perform a measured and verified launch of an OS kernel. <ref>
https://reposcope.com/package/intel-SINIT
</ref> Although digitally signed, the download step is done without verification and the processor must then correctly verify it and perform initial steps like correct measurements of BIOS/firmware and system settings such as ACPI tables.
AEM has several other limitations: <ref>
Picture support may also have been deprecated.
* it authenticates the machine to the user (not the user to the machine)
* any BIOS changes require a reseal
* full trust is placed in the CPU and BIOS
* compatible with legacy boot only (incompatible with (U)EFI boot)
* a TPM owner password must be set
* incompatible with USB 3.0
Note that AEM has (time-based) one-time password support (OTP, TOTP; "google authenticator") ([[Two-factor authentication 2FA|2FA]]) which is a more secure configuration. It is also possible to use a USB device as the AEM device, but this has strengths and weaknesses: <ref>
[https://www.qubes-os.org/doc/anti-evil-maid/ Installing and Using Anti Evil Maid (AEM) with Qubes OS]: <blockquote>Qubes security guidelines dictate that USB devices should never be attached directly to dom0, since this can result in the entire system being compromised. However, in its default configuration, installing and using AEM requires attaching a USB drive (i.e., mass storage device) directly to dom0. (The other option is to install AEM to an internal disk. However, this carries significant security implications, as explained here.) This presents us with a classic security trade-off: each Qubes user must make a choice between protecting dom0 from a potentially malicious USB drive, on the one hand, and protecting the system from Evil Maid attacks, on the other hand.</blockquote>
* evil maid attacks are easier because BIOS settings do not need changing
* AEM on USB can be used as a keyfile (second factor), which provides a stronger yubikey
* in Qubes, hiding the USB from <code>dom0</code> is a more secure configuration; for example it avoids [https://acodez.in/badusb-attack/ BadUSB attacks]
Despite these limitations, {{q_project_name_long}} users who have a compatible TPM are recommended to install [https://www.qubes-os.org/doc/anti-evil-maid/ AEM] in <code>dom0</code>. Also refer to the [https://github.com/QubesOS/qubes-antievilmaid qubes-antievilmaid README] for further security notes and information on system requirements. Anti Evil Maid Alternatives
If AEM is unavailable, then weaker alternatives include:
* Utilizing a BIOS password since an attack requires removal of the disk. Note this protection can potentially be circumvented by a master/maintenance BIOS password that might exist.
* The <code>/boot</code> partition can also be placed on a USB; adversaries must then attack either the BIOS or USB-persistent modifications.
* A cryptographic hash can be calculated for the entire disk so an integrity hash can be recalculated at a later time. <ref>
This can detect if data has changed, but cannot protect against intentional tampering.
https://ctf101.org/forensics/what-is-disk-imaging/
</ref> An attacker would need to attack the BIOS in this case to avoid detection.
or create an account