{{Header}}
{{Title|title=
Protection against Physical Attacks
}}
{{#seo:
|description=BIOS Password, Problematic Interfaces, Screen Lock, Virtual Consoles, Login Screen, Side Channel Attacks
|image=Protectionagainst234234234.jpg
}}
{{passwords_mininav}}
[[File:Protectionagainst234234234.jpg|thumb]]
{{intro|
BIOS Password, Problematic Interfaces, Screen Lock, Virtual Consoles, Login Screen, Side Channel Attacks
}}
= Introduction =
Physical attacks require adversaries to have direct access to a user's computer and cannot be conducted remotely. This section should be read in conjunction with the [[Full_Disk_Encryption|Full Disk Encryption]] and [[Encrypted_Images|Encrypted Images]] chapters.
= BIOS Password =
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = The instructions in this section refer to BIOS or legacy BIOS. Users with UEFI firmware should research specific instructions for their computer.
}}
The Basic Input/Output System (BIOS) is non-volatile firmware which performs hardware initialization during the computer's booting process after it is powered on. It also provides runtime services for operating systems and progams. BIOS in modern PCs initialize and test system hardware components, as well as loading a boot loader or operating system from a mass memory device. The Unified Extensible Firmware Interface (UEFI) is the successor to BIOS that was released in 2011. [https://en.wikipedia.org/wiki/BIOS]
All local settings are stored in BIOS, including power options, boot options and memory information. The BIOS menu allows the user to set and change a boot password for the computer upon startup. An administrator password can also be set to prevent others from changing BIOS settings. To set a BIOS boot password: [https://web.archive.org/web/20220803213740/https://www.techwalla.com/articles/how-to-change-the-administrator-password-in-bios] [https://web.archive.org/web/20210430031204/https://www.intowindows.com/how-to-set-bios-or-uefi-password-in-windows-10/]
* Turn on / restart the computer.
* Press the relevant key to access the BIOS menu. It is usually one of: Del, Esc, F2, F10, or F12.
* Navigate to the Security or Password section using the arrow keys.
* Search for an entry named "Password on boot" or similar.
* Enter the new, [[Passwords#Generating_Unbreakable_Passwords|strong password]].
* Save the changes made to BIOS settings. On most PCs, this is done by pressing Esc or F10 → Save and Exit. Check the bottom of the BIOS screen to be sure.
* Reboot the computer and confirm a password prompt now appears.
For greater security, a password should be set to access the BIOS menu itself. Search the Security or Password BIOS menu for "Set supervisor password", "User password", "System password", or something similar. [If the system has both a supervisor password and a user password, then set passwords for both.] Also, users may prefer to configure BIOS to only allow booting from HDD/SSD so the computer cannot be booted from CD-ROM or USB flash drives.
It should be noted that there are [https://www.technibble.com/how-to-bypass-or-remove-a-bios-password/ numerous] [https://www.instructables.com/How-to-Bypass-BIOS-Passwords/ methods] of [https://web.archive.org/web/20170511122202/https://www.askvg.com/how-to-reset-remove-bypass-a-bios-or-cmos-password/ bypassing, removing or resetting BIOS passwords], so this method will only prevent casual attempts to gain access.
= Cold Boot Attacks =
Check [[Cold Boot Attack Defense]] Section.
= Evil Maid Attack =
Check [[AEM|Anti Evil Maid]] Section.
= Problematic Interfaces =
There are a number of computer interfaces that pose the risk of a [https://en.wikipedia.org/wiki/DMA_attack direct memory access (DMA) attack]. Potentially exploitable interfaces include ExpressCard, PCMCIA, FireWire, PCI, PCI Express or Thunderbolt.
{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text = High-speed expansion ports allow attackers to penetrate computers and other peripherals because the connected devices have direct hardware access to enable maximum throughput.
}}
In practice, attached devices are permitted to read and write directly to memory, often without supervision of the operating system. This is in contrast to user-mode applications that are usually prevented from accessing memory locations that are not explicitly authorized by virtual memory controllers. [
https://en.wikipedia.org/wiki/DMA_attack
]
A successful DMA attack on an unattended, live computer allows the adversary to: [
https://louwrentius.com/firewire-the-forgotten-security-risk.html
] [
https://privatecore.com/resources-overview/physical-memory-attacks/index.html] [
https://web.archive.org/web/20170427144955/https://www.delaat.net/rp/2011-2012/p14/report.pdf
]
* Access sensitive cryptographic material in memory.
* Circumvent FDE.
* Inject executable code.
* Partially or fully read the memory address space.
* Read documents, files or other digital traces present in memory.
* Take control of the entire system, for example via the network.
* Unlock screensavers without a passphrase.
DMA attack software tools which mimic the [https://en.wikipedia.org/wiki/FinFisher#FinFireWire abilities of state-level adversaries] are even available on [https://github.com/carmaa/inception GitHub]! [
This is not an endorsement for the use of hacking tools.] Mitigating the threat of a DMA attack requires mostly physical security countermeasures; it is recommended to:
* Consider blocking or removing them completely.
* Disable them in BIOS or UEFI.
* Never allow unknown and potentially malicious devices to be inserted into these ports. [This is another reason why high-risk users should never leave their devices unattended.
]
* Securely configure these interfaces.
* Use [https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit IOMMU] technology if available, along with software which supports it, like Qubes. [
IOMMU maps device-visible virtual addresses to physical addresses. The security benefit is that devices that are passed through to guest virtualized machines -- AppVMs in Qubes -- are unable to access the host's physical memory. This makes DMA attacks against the host very difficult and can lead to memory corruption if attempted. Qubes OS automatically uses device passthrough to isolate USB controllers and network devices from the host, thus helping prevent these and other attacks. An IOMMU may also prevent DMA attacks from host devices (not passed through to a VM), although this is not necessarily guaranteed to work in all situations. See https://security.stackexchange.com/questions/176503/dma-attacks-despite-iommu-isolation
]
* Use Linux kernel options to disable DMA by Firewire devices. Package [[security-misc]] is installed by default and implements this, see also [https://github.com/{{project_name_short}}/security-misc#disables-and-blacklists-kernel-modules package description]).
= Screen Lock =
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = If a computer is left unattended, always lock the screen of the host or shut it down for greater safety.
}}
Locking the screen on the host prevents others from viewing or using the device. It is advisable to set the screen to lock after a certain period of inactivity, and a [[Passwords#Generating_Unbreakable_Passwords|strong password]] is recommended. Note that screen lockers provide [https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/ notoriously weak protection], so do not overestimate their effectiveness. [Attacks that have bypassed screen lockers on most platforms can easily be found online.]
To manually lock the screen: [https://www.isunshare.com/windows-10/3-ways-to-lock-windows-10-computer.html] [https://swissmacuser.ch/new-lock-screen-feature-in-macos-high-sierra/]
Linux
* Menu panel → Lock Screen.
* Shortcuts are specific to the desktop environment in use, for example, GNOME, KDE, Xfce and so on.
Recommendations:
* Do not enable Alt + Crtl + Backspace to kill the X Server. Do not disable DontZap in Xorg configuration. [
https://forums.whonix.org/t/screen-locker-in-security-can-we-disable-these-at-least-4-backdoors/8128
] [
[https://www.jwz.org/xscreensaver/faq.html Quote xscreensaver FAQ]:
]
Backdoor #1: Ctrl-Alt-Backspace
This keystroke kills the X server, and on some systems, leaves you at a text console. If the user launched X11 manually, that text console will still be logged in. [...]
= Sleep Mode =
Best avoided unless a screen lock is being used. See also above.
= Virtual Consoles =
* Do not forget to lockout from other [[Desktop#Virtual_Consoles|virtual consoles]] after use. [
[https://www.jwz.org/xscreensaver/faq.html Quote xscreensaver FAQ]:
]
Backdoor #2: Ctrl-Alt-F1 , Ctrl-Alt-F2 , etc.
These keystrokes will switch to a different virtual console, while leaving the console that X11 is running on locked. If you left a shell logged in on another virtual console, it is unprotected. So don’t leave yourself logged in on other consoles. You can disable VT switching globally and permanently by setting DontVTSwitch in your xorg.conf, but that might make your system harder to use.
= Login Screen =
[[File:Gui_login.png|thumb|graphical login screen (by login manager LightDM)]]
Host versus VMs:
* '''Host operating system:''' A login screen can be useful if the user wants to protect the login.
* '''VMs:''' It is not very useful to enable a login screen inside VMs. If the host operating system (OS) is ever compromised, then any VMs it hosts are also effectively compromised. Therefore, if anything, it is much better to lock the host screen. See also [[#Screen Lock|Screen Lock]].
Note:
* '''Login, yes:''' A login screen only protects the login.
* '''Encryption, no:''' A login screen does not provide [[Full_Disk_Encryption|Full Disk Encryption (FDE)]]!
A login screen can be provided by a login manager. For example, LightDM is the login manager used by default in {{project_name_short}}.
{{project_name_short}} is configured by default to autologin. Hence, no login screen will be shown by default.
To enable a login screen in {{project_name_short}}, it is required to disable autologin. For instructions on how to do that, see [[Desktop#Disable_Autologin|disable autologin]].
See also: [[Login]]
= Side Channel Attacks =
{{mbox
| type = notice
| image = [[File:Ambox_notice.png|40px|alt=Info]]
| text = {{project_name_short}} does not provide protection against most [https://en.wikipedia.org/wiki/Side-channel_attack side-channel attacks].
}}
Side-channel attacks are made possible by physical effects caused by cryptosystem operations (''on the side'') which provide extra information about system secrets like cryptographic keys, state information, or full/partial plaintexts. Wikipedia defines side-channel attacks as: [https://en.wikipedia.org/wiki/Side-channel_attack]
...any attack based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms (compare cryptanalysis). For example, timing information, power consumption, electromagnetic leaks or even sound can provide an extra source of information, which can be exploited to break the system.
Side-channels emerge because computation takes place on a non-ideal system, composed of transistors, wires, power supplies, memory, and peripherals. Component characteristics vary with the instructions and data that are processed, allowing measurable variance to be used by attackers. [http://rootlabs.com/articles/IEEE_SideChannelAttacks.pdf]
'''Table:''' ''Primary Side-channel Attack Classes''