Physical Device Security: Border Crossings, Seizures, and Cold Boot Attacks

Software-based security assumes one critical precondition: that you control your device. The moment a device leaves your hands — at a border crossing, during a hotel stay, or as a result of theft — every software protection faces a fundamentally different threat environment. Physical access to a device changes what is possible for an attacker in ways that remote attacks cannot match. Understanding these threats and the practical mitigations against them is essential for anyone who travels with sensitive data or operates in environments where device seizure is a realistic possibility.

Why physical access changes everything

When an attacker has physical access to your device and unlimited time, they can attempt attacks that are impossible remotely: extracting data from memory chips directly, modifying the device's firmware, connecting hardware probes to debug interfaces, or forensically imaging the storage. Many of these attacks are expensive and require specialist equipment, but they are within the capability of law enforcement agencies, intelligence services, and well-resourced private actors.

Software protections are designed to resist attacks through software interfaces. They are not designed to resist a skilled technician with physical access and appropriate tools. This is not a failure of the software — it is a fundamental constraint of the threat model.

Border crossing risks

Border crossings represent a legally distinct environment in many jurisdictions. In the United States, border agents have broad authority to search electronic devices without a warrant and, depending on the situation, may attempt to compel device unlocking. Similar powers exist in the UK, Australia, Canada, and other countries. Even in jurisdictions with stronger constitutional protections, the practical reality at a border is that refusing to cooperate may result in prolonged detention, device seizure, or denial of entry.

The most reliable protection against border device search is not being in possession of sensitive data at the time of crossing. Practical approaches include: travelling with a factory-reset device, using a dedicated travel device with no sensitive data installed, or accessing sensitive data remotely after crossing (from secure infrastructure) rather than carrying it across.

Power-off vs. lock screen: a meaningful security distinction

Most people leave their phone at the lock screen when not in use. This is significantly less secure than a full power-off. When a device is powered off and full-disk encryption is in use, the encryption keys are not loaded in memory. The data on the storage is cryptographically protected and inaccessible without the decryption key.

When a device is locked but running, the encryption keys have already been derived from your PIN/password and loaded into memory so that the device can respond to notifications and run background processes. In this "After First Unlock" (AFU) state, forensic tools such as Cellebrite's UFED, used by law enforcement worldwide, have a higher probability of successful data extraction.

GrapheneOS includes an auto-reboot feature that automatically reboots the device after a configurable period of inactivity, returning it to the "Before First Unlock" (BFU) state where encryption keys are not in memory. This significantly narrows the window in which a seized, locked device is vulnerable to memory-based extraction.

Cold boot attacks

Cold boot attacks exploit a physical property of DRAM memory: data stored in RAM is not instantly lost when power is removed. In normal conditions, DRAM loses its state within milliseconds to a few seconds of power removal. However, at low temperatures — achieved with aerosol sprays or liquid nitrogen — DRAM retention can be extended for minutes or longer. An attacker who has access to a powered device can remove the RAM module, cool it rapidly, transfer it to another system, and read the encryption keys that were in memory.

Cold boot attacks are not theoretical. They have been demonstrated successfully against BitLocker, FileVault, and LUKS-encrypted systems. The practical difficulty is high — the attacker needs physical access, specialist equipment, and needs to act quickly — but for high-value targets, the attack is feasible.

Mitigations include: powering off devices completely when not actively using them (rather than locking), enabling automatic memory wiping on shutdown where the OS supports it (GrapheneOS supports this), and using devices where RAM is soldered directly to the board rather than removable (most modern phones).

Evil Maid attacks

An Evil Maid attack occurs when an attacker has brief physical access to an unattended device and modifies it — typically to install a hardware or software implant that captures credentials or data. The attacker leaves the device apparently unchanged, then returns later to collect what was captured.

The "evil maid" name comes from the hotel scenario: a device left in a hotel room while the owner is at a conference. The attack requires only minutes of access and a prepared payload.

Defences against Evil Maid attacks:

• Verified Boot: GrapheneOS implements strict Verified Boot, which cryptographically verifies the entire OS chain at startup. Any modification to the bootloader or OS will be detected and the device will refuse to boot (or display a warning). This prevents software-level Evil Maid attacks.
• LUKS with pre-boot authentication: On encrypted Linux laptops, requiring password entry before the OS boots (rather than at the login screen) means a modified bootloader cannot capture your password without being detected by Verified Boot.
• Tamper-evident seals: Physical stickers placed over device seams and ports that would break if the device were opened or disassembled. Not a cryptographic protection, but provides visual evidence of tampering.
• Never leave devices unattended: The simplest mitigation for the hotel scenario is to take your device with you or lock it in a safe that you have verified hasn't been opened.

Self-incrimination and password disclosure laws

The legal landscape on compelled password disclosure varies significantly by jurisdiction and is evolving. In the United States, courts have reached inconsistent conclusions on whether compelling password disclosure violates the Fifth Amendment. In the UK, Section 49 of the Regulation of Investigatory Powers Act (RIPA) allows authorities to compel disclosure of encryption keys with criminal penalties for refusal. Several other European countries have similar provisions.

In any legal context where you might be compelled to produce a password, "I don't know the password" is only a defence if it is true. Devices that are factory-reset, or data that is genuinely not in your possession, cannot be compelled from you. This is the strongest protection against legal compulsion: not having the data.

Practical travel protocol

For travel to or through jurisdictions with aggressive border search powers, or travel to higher-risk environments:

• Use a dedicated travel device, not your primary device, with only the data you genuinely need during travel.
• Power the device off completely before reaching the border, not just locking it.
• If carrying sensitive data is unavoidable, ensure the device is in BFU state (powered off) with strong encryption and a strong passphrase.
• Have a remote wipe mechanism configured so that devices can be wiped if seized.
• Keep sensitive data on remote infrastructure rather than the device where possible, accessed after crossing.

Norypt's custom devices are available with tamper-evident seals and remote wipe MDM pre-configured. For laptop security at border crossings and in high-risk travel, see Norypt encrypted laptops — configured with pre-boot authentication and verified boot so that physical tampering is detectable and encryption is enforced from the first moment of power-on.