Supply Chain Attacks: Limits of the Secure Element

Previous articles in this series examined attack categories against the secure element itself: fault injection, invasive chip analysis, and side-channel techniques. These are real threats, but they belong to a tier of attack that requires significant resources, specialized equipment, and individual targeting. Most users will never face them.
 

Supply chain attacks are different. They do not require a laboratory or physical access to a device. They do not need to defeat the secure element at all; they operate in the code layers that sit above the chip. A single successful supply chain attack can affect thousands or millions of users simultaneously. The economics make them significantly more attractive to a wider range of attackers than any hardware-level technique.

This article examines the supply chain risk in terms of software, using two documented incidents involving one of the most widely used hardware wallet manufacturers in the world.
 

The secure element is not the weakest link in a hardware wallet's security. For most users, in most real-world attacks, the software supply chain is the most vulnerable.

What a supply chain attack actually means

The term "supply chain attack" sounds abstract. In practice, it has a precise meaning: an attacker does not target the end user directly. Instead, they compromise something the end user trusts. It could be a software library, a firmware update mechanism, or a distribution channel.

In hardware wallets, the most relevant supply chain vectors are:

What makes these vectors dangerous is their scale. Compromising a dependency used by millions of users is fundamentally different from attacking one user's device. The attacker invests once and collects from everyone who touches the compromised component before it is detected and patched. 

The secure element provides no protection against any of these vectors because these attacks never require the chip to be breached. They operate upstream of it.

A supply chain attack does not pick the lock. It bribes the locksmith, copies the key, and puts the original back before anyone notices. The lock was never touched.

Case Study 1: The Ledger Connect Kit Attack (December 2023)

On December 14, 2023, a supply chain attack against Ledger's Connect Kit — a JavaScript library used by decentralized applications to interface with Ledger hardware wallets — resulted in between $484,000 and $600,000 in stolen assets. The attack lasted approximately five hours, with active fund draining concentrated in a roughly two-hour window. Dozens of major DeFi protocols were affected simultaneously.

How the attack was executed

Ledger's Connect Kit is an open-source JavaScript library published on npm (Node Package Manager) — the standard distribution channel for JavaScript code. Hundreds of decentralized applications integrated it to allow their users to connect Ledger hardware wallets to their interfaces.

Critically, Ledger distributed the library not just through npm's standard version-pinning mechanism but also via a CDN (Content Delivery Network) loader — a design that caused dependent applications to automatically pull the latest version of the library at runtime rather than a fixed, pinned version. This meant that the moment a new version appeared on npm, every application using the CDN loader would run it immediately, with no review and no safety buffer.

The attacker gained access to the npm publishing credentials of a former Ledger employee through a phishing attack. The former employee's access to Ledger's internal systems had been properly revoked during offboarding, but their npm API key had not. API keys bypass npm's two-factor authentication requirements, meaning the attacker needed only the key.

With publishing access obtained, the attacker pushed three malicious versions (1.1.5, 1.1.6, and 1.1.7) containing the Angel Drainer malware — a wallet-draining payload that crafted malicious transaction approval requests that, when signed by a user, transferred assets to the attacker's wallet. When the CDN loader automatically pulled the latest version, affected dApps began serving malicious code to their users within minutes of publication.

What the attack reveals

• The secure element was never involved. Ledger's hardware devices were not compromised. The attack operated entirely in the JavaScript layer of the browser-based interface. The chip did what it was designed to do: it signed transactions. The problem was that users were being tricked into asking it to sign the wrong ones.
• The attack surface was a dependency, not a product. Ledger's own codebase was not directly compromised. The vulnerability was in their publishing infrastructure for a library that other applications depended on.
• Offboarding failure created the entry point. The entire attack chain traced back to a single npm API key belonging to a former employee that was not revoked. A procedural gap in an offboarding checklist — not a cryptographic weakness, not a chip vulnerability — was the root cause.
• The CDN distribution model amplified the blast radius. Had all dependent applications pinned specific versions of the library rather than loading dynamically from a CDN, the attack would have been contained to applications that explicitly updated to the malicious versions.

Note: Ledger responded quickly, deploying a patched version within 40 minutes of the internal alert and coordinating with Tether to freeze the stolen funds. The point of this analysis is that the attack vector existed and was exploited.

Case Study 2: Ledger Recover and the Firmware Capability Revelation (May 2023)

Seven months before the Connect Kit incident, a different kind of supply chain concern emerged. This was not an active attack, but a disclosure that fundamentally reframed what users understood about their devices' capabilities.

In May 2023, Ledger announced Ledger Recover: an opt-in subscription service, priced at $9.99 per month, that allows users to back up their seed phrase by having the device encrypt it, split it into three fragments using Shamir Secret Sharing, and transmit those fragments to three custodians — Ledger, Coincover, and EscrowTech. The service was positioned as a recovery mechanism for users who lose or forget their seed phrase.

Cause for concern

The concern was not primarily about the Recover service itself. Ledger maintained clearly that the service was opt-in, that the seed phrase fragments were encrypted, that no single custodian could reconstruct the phrase alone, and that the process required explicit user consent on the device.

The concern was about what the service's existence proved about the device's underlying capabilities. Before the announcement, most Ledger users assumed the secure element was a one-way vault: private keys entered the chip and never left, in any form, under any circumstances.

Ledger had previously stated on social media that firmware updates could not extract the seed from the secure element. Ledger Recover demonstrated that this framing was incomplete. The firmware, via an update, could instruct the secure element to encrypt and transmit seed material over a network connection. As Ledger's former CEO and co-founder Éric Larchevêque later acknowledged, the previous statement was missing the caveat: "as long as you are trusting Ledger."

The structural issue the controversy exposed

The problem Ledger Recover revealed is architectural: upgradable firmware creates a category of trust that is not fully visible to most users. When Ledger ships a firmware update, it is signed with Ledger's private key, and the device verifies that signature before installing it. This is a secure boot: a meaningful defense against third-party firmware substitution.

The update mechanism is the channel, and the manufacturer's intentions determine what travels through it. Manufacturer intentions can change, be subject to legal compulsion, and are not always communicated to users in advance. This is not a Ledger-specific observation — it is the inherent architecture of any hardware wallet with upgradable firmware.

What you are trusting when using a device with upgradable firmware:

▲ Every layer must hold for the device to remain fully under the user's control

The alternative: immutable firmware

Some hardware wallets, like Tangem, use firmware that is burned into the device at manufacture and cannot be updated by anyone after the device leaves the factory. This approach makes a fundamentally different security trade-off.

The advantages are direct: the firmware supply chain attack surface is eliminated entirely. There is no update mechanism to compromise, no signing key to steal, no pipeline to poison. Whatever firmware was deployed at manufacture is what the device runs for its entire life. The manufacturer has no post-deployment control over the device's behavior.

Independent firmware audits by Kudelski Security (2018) and Riscure (2023) confirmed that Tangem's firmware contains no backdoors and that private keys are generated using a hardware random number generator. Both audits found no issues that would expose private key material.

Users of immutable devices must rely on initial audit quality and may need to replace hardware for major protocol changes.

Firmware Architecture Trade-offs

Final thoughts

The two incidents examined in this article did not require an attacker to break a secure element. They did not require laboratory equipment, side-channel analysis, or physical access to a device.

This is the core point. Supply chain and software risk are not theoretical. They scale naturally and efficiently to every user of every affected product simultaneously. They operate in layers that most users never inspect — through mechanisms that are either invisible or quietly assumed to be trustworthy.

Regardless of architecture, verify firmware authenticity on first setup. Immutable firmware removes one major class of risk — but user vigilance remains essential.