Electromagnetic Side-Channel Attacks on Trezor Devices: What Academic Research Reveals About Physical Security

A hardware wallet’s primary promise is isolation. Private keys remain on a dedicated device, never exposed to a connected computer or mobile phone. But isolation alone does not guarantee impermeability. Academic researchers have spent years investigating whether specialized equipment can extract cryptographic secrets from hardware by observing physical phenomena—electromagnetic emissions, power consumption variations, timing differences, and even acoustic vibrations. The question facing users and manufacturers is not whether such attacks exist in laboratory conditions, but which ones apply to real devices under realistic threat models, and whether commercial hardware wallets like Trezor effectively defend against the attacks that matter most.

Trezor devices occupy a specific position in this landscape. They employ multiple layers of defense: the separation of cryptographic operations onto a hardened microcontroller, the absence of sensitive data in volatile memory after use, firmware that has been audited publicly, and open-source code that permits independent verification. Yet no device is immune to all physical attacks. Understanding what academic papers have actually demonstrated—and what remains theoretical—requires careful reading of threat assumptions, attack preconditions, and the practical feasibility of exploiting a vulnerability against a typical user.

Side-channel attacks: The research categories and what they measure

Side-channel research refers to attacks that extract information not from the algorithm itself but from its physical implementation. When a microcontroller executes cryptographic code, it consumes varying amounts of electrical power, radiates electromagnetic fields, completes operations in different times depending on data values, and generates acoustic noise during memory operations. Each emission can leak information if an attacker has the right measurement equipment and sufficient samples.

Power analysis is the most studied category. Simple Power Analysis (SPA) observes power traces to distinguish between different operations—for example, detecting conditional branches in a cryptographic algorithm that should ideally be constant-time. Differential Power Analysis (DPA) collects many power traces from multiple cryptographic operations, each with a different input or secret value, then uses statistical methods to correlate power consumption patterns with predicted secret material. An attacker with access to the device, precise power measurement equipment, and hundreds or thousands of cryptographic operations can theoretically narrow down key candidates by observing which hypothetical secret values best match the observed power variance.

Electromagnetic (EM) analysis uses similar logic but measures the electromagnetic field radiated by the microcontroller rather than current flowing through a power supply. EM emissions can be picked up by a probe placed millimeters or centimeters from the device, depending on frequency and shielding. Academic papers have demonstrated EM attacks against various microcontrollers and embedded systems. The advantage over power analysis is that EM measurement may not require physically inserting a shunt into a power supply, making it potentially non-invasive.

Timing attacks exploit variations in how long cryptographic operations take. If a modular exponentiation or elliptic curve scalar multiplication executes in different times depending on the secret key or input, an attacker observing execution time from outside the device—or measuring via a side channel—can extract bits of the secret. Constant-time cryptography is the standard defense; the implementation must execute in identical time regardless of secret values or inputs.

What Trezor’s hardware design prevents

The Trezor device isolates cryptographic operations on a dedicated microcontroller separate from the communication interface. The main STM32 processor handles USB communication and user interaction, while sensitive operations occur on a separate secure element in recent Trezor models, or on a hardened portion of the main processor in earlier versions. This isolation means that an attacker observing USB traffic, power consumption at the USB port, or electromagnetic emissions from communication circuits cannot directly measure the power or EM signature of the actual cryptographic operation. The attacker would need physical access to the device internals.

Trezor also implements constant-time cryptography where feasible. Elliptic curve scalar multiplication, the operation that generates or verifies signatures and derives keys, should take the same number of CPU cycles regardless of the secret key value. Properly implemented constant-time code removes timing side channels from the operation itself. This does not mean timing attacks are completely impossible—the device must still receive a command, process it, and send a result, and each step has a detectable timing—but it eliminates the easiest class of timing leaks from the cryptographic algorithm.

Physical security measures also matter. The Trezor case is not particularly hardened against X-ray, solvent removal, or focused ion beam attacks, but those belong to the category of invasive attacks that require expensive equipment and typically destroy the device in the process. Against non-invasive attacks—EM measurement, power analysis via external probes, acoustic observation, or thermal imaging—the main defenses are distance, isolation, and the inherent noise of the device’s operation. The Trezor does not include electromagnetic shielding as a primary feature, but the separation of cryptographic circuits from external interfaces and the presence of other components consuming power simultaneously reduce the signal-to-noise ratio of any leaked information.

The firmware itself also implements countermeasures. Code is designed to avoid branches on secret values, to use masking and randomization in some operations, and to minimize the time sensitive keys spend in RAM or processor registers. The open-source nature of Trezor’s codebase permits security researchers and users to audit these implementations, which has led to identified and patched vulnerabilities. This transparency is itself a form of security control: vulnerabilities discovered during audit can be fixed before widespread exploitation, and users can verify that the device they own runs the code they expect.

Academic studies that have targeted hardware wallets

Published research on hardware wallet side channels is surprisingly limited, which reflects both the practical difficulty of such attacks and the relative novelty of commercial hardware wallets. Some studies have examined Trezor or similar devices; most have focused on more general microcontroller security. A commonly cited line of research involves power analysis against ECDSA and EdDSA implementations on ARM Cortex-M processors, the same family used in some Trezor versions. These papers demonstrate that under ideal laboratory conditions—with precise measurement equipment, physical placement of probes, and hundreds or thousands of known cryptographic operations—the attacker can recover key material.

However, the practical applicability to a protected device like Trezor depends critically on several preconditions. First, the attacker must have physical access to the device and be able to place measurement probes within millimeters of specific components. Second, the attacker must know or be able to influence the input data and observe the corresponding output—a requirement that applies to many laboratory scenarios but is harder to satisfy in practice when the device is in the user’s possession and the private key is only used for signing. Third, the attacker must collect sufficient samples and have accurate models of the cryptographic algorithm and device behavior.

A 2019 study on power analysis against ECDSA on Cortex-M processors concluded that key recovery was theoretically possible but required certain conditions: a specific vulnerable implementation, a large number of traces, and absence of countermeasures. Trezor’s implementation includes mitigations such as randomization of scalar representation and other techniques designed to increase the difficulty. Another line of research examined EM side channels against embedded systems more broadly, with some demonstrations showing that EM probes could detect computation patterns; again, moving from detection to actual key recovery required precise knowledge of the algorithm and strong statistical correlation.

To understand Trezor’s actual position, readers can read more about the hardware specifications and then examine published Trezor security documentation and third-party security research. The company has been transparent about known vulnerabilities, published fixes, and the scope of its security model. Academic papers that mention Trezor by name are rare; most findings apply to microcontroller families or cryptographic algorithms rather than the specific device configuration and defenses.

The difference between laboratory attack and real-world threat

One of the most important distinctions in side-channel research is between proof-of-concept and practical exploitation. A laboratory attack might require a user to approve hundreds of signing operations while measurement equipment monitors the device, record power traces or EM emissions in a shielded environment, process the data with known algorithms, and perform statistical analysis to narrow the key space. That sequence is far removed from an attacker acquiring a Trezor device, operating it normally, and extracting the private key.

The threat model for a Trezor device assumes that the user controls the device and can detect physical tampering. If measurement probes must be attached, physical position adjusted, and data collected over hours or days, the user would likely notice. A more realistic threat involves scenarios where the attacker has legitimate access to the device for extended periods—a workplace IT environment, a family member, or a theft followed by recovery—but not enough time or access to set up side-channel measurement equipment. In those cases, the practical attacks are those that do not require specialized instrumentation: physical extraction of the secure element, replacing the firmware with malicious code, or social engineering to obtain the seed phrase.

Academic papers sometimes describe attacks that work in principle but face obstacles in practice. For example, an EM attack might require the attacker to position a probe within 5 millimeters of a specific component, collect 10,000 traces under tightly controlled conditions, and use computational power equivalent to hours of cluster processing to extract a single key bit. The same paper might also note that practical countermeasures—such as adding random noise, varying execution time, or physically isolating the sensitive circuit—can increase the requirements by orders of magnitude. Users should interpret such findings as evidence that the threat space is active and researchers are creative, not necessarily that existing devices are unsafe for ordinary use.

A hardware wallet security evaluation must therefore balance several considerations. The device should be resistant to the attacks most likely to be attempted by someone with plausible motive and access. It should degrade gracefully: if an attack partially succeeds, the damage should be limited. It should make defenses transparent, so users can understand what is being protected and how. And it should not create new vulnerabilities in its effort to prevent old ones. A device that is completely immune to side channels but allows malware to run on the host computer, or that stores recovery information insecurely, has a security gap elsewhere.

Recovery seed protection and the larger security perimeter

Private key storage on a Trezor hardware wallet protects against many attacks but not against seed phrase compromise. The seed—typically 12 or 24 words that deterministically generate all keys—is the master secret. If an attacker obtains the seed, no amount of hardware isolation matters. Academic research on side channels largely assumes the attacker does not already have the seed or private keys; if they do, the attack is not a side channel but a theft.

The Trezor requires the user to write down the seed during initial setup and store it physically. The device does not send the seed to the manufacturer, cloud storage, or a backup service. This puts the burden on the user: lose the seed, and funds are lost; expose the seed, and an attacker can recreate the wallet on any device. A sophisticated attacker who has already compromised the user’s computer or home network might photograph the seed during setup, intercept it if it is ever typed into an internet-connected device, or observe it through a compromised mobile phone camera. These attacks do not involve side channels but rather target the user’s operational security or compromise the devices in their environment.

Trezor’s design implicitly recognizes this boundary. The hardware wallet protects against attacks on the device itself, but security for the entire setup also requires the user to protect the seed, secure their computer, and use strong PINs and passphrases. A user who stores the seed in a cloud note, texts it to themselves, or writes it on a document stored on their laptop has negated the hardware wallet’s isolation. This is not a flaw in Trezor but a reflection of the truth that security is a system, not a single component.

Attacks that require firmware modification or invasive access

Some of the most dangerous attacks on a Trezor device do not involve side channels at all. A firmware replacement attack would install modified code that logs keystrokes, exfiltrates the seed during generation, or signs unauthorized transactions. An invasive attack might extract the secure element’s contents directly using specialized equipment such as a focused ion beam or X-ray tomography. These are not side-channel attacks; they are orthogonal threats that require different defenses.

Firmware security on Trezor relies on secure boot and code signing. The bootloader verifies that the main firmware has been signed by Satoshi Labs before allowing it to execute. If a user connects a Trezor to a computer and receives an unsigned or differently signed firmware, the device should reject it. The firmware source code is publicly available, so users can verify that the official signed version matches the published source. This prevents most casual firmware replacement but requires that the user actually verifies the signature and that the signing keys have not been compromised.

For invasive attacks involving direct extraction of cryptographic material from the secure element, the defense is typically the physical robustness of the component and the difficulty of attacking it without destroying the device. Trezor’s secure elements are commercial-grade components from manufacturers such as STMicroelectronics; they have some physical hardening but are not military-grade. An attacker with sufficient resources and motivation might succeed, but the cost and expertise required limit this threat to state-level adversaries or highly motivated criminals. For ordinary users, the more relevant threats are phishing, device theft with recovery seed compromise, and malware on the host computer.

What remains uncertain and the value of transparency

Despite academic research and industry scrutiny, several questions about hardware wallet physical security remain incompletely answered. The interaction between multiple countermeasures and their cumulative effect against realistic attackers is not fully quantified. The actual difficulty of performing a complete side-channel attack against a Trezor in the hands of a motivated attacker remains somewhat speculative, because published papers tend to focus on isolated components or theoretical scenarios rather than the complete system as deployed. And the emergence of new attack techniques—such as more sophisticated power or EM analysis methods, or attacks exploiting interactions between the main processor and secure element—may require periodic re-evaluation.

The most valuable response to this uncertainty is transparency. Trezor’s decision to publish source code, support independent security audits, and document known vulnerabilities and fixes creates an incentive for researchers to report problems rather than exploit them silently. Users can examine the code themselves or rely on published audits. When vulnerabilities are discovered, they can be patched, and the patch can be verified. This is not a guarantee of perfect security, but it is vastly better than a closed system where vulnerabilities might accumulate unknown.

A user should approach hardware wallet security with realistic expectations. A Trezor device protects private keys against many attacks that could compromise a software wallet on a general-purpose computer. It does not make the user immune to phishing, social engineering, or their own mistakes. It does not automatically make cryptocurrency transactions private, reversible, or protected against theft if the device itself is stolen. And it does not eliminate the need for good operational security: protecting the seed, securing the host computer, and verifying transaction details on the device’s screen before confirming. The hardware wallet is one layer of a security architecture, valuable but not sufficient by itself.