Hardware-Based Cryptographic Operations in Tangem: Why Private Keys Never Leave the Card

A user holding Bitcoin or Ethereum typically faces a familiar security trade-off: store private keys on internet-connected devices and accept malware risk, or use an offline hardware wallet and accept complexity. Tangem Wallet disrupts that binary by embedding cryptographic operations directly into a secure element chip no larger than a credit card, eliminating the need for batteries, cables, or screens while keeping keys offline. The architecture means that signing operations—the mathematical proof required to authorize transactions—happen inside the card itself. Private keys never export to the phone, never travel over Bluetooth, and never exist in the mobile app’s memory as complete cryptographic material.

This design choice reflects a fundamental principle in hardware security: if a private key is ever exposed to a general-purpose processor, an internet connection, or an operating system controlled by a user, the attack surface expands dramatically. Malware, memory dumps, clipboard access, and screen-capture vulnerabilities become relevant. Tangem’s approach is to keep the private key locked inside silicon and permit only the mathematical result—a signature—to leave the card. That result can be verified cryptographically without the key itself ever being known. Understanding how this protection actually works requires examining the secure element architecture, the communication protocol, and the specific operations performed at each stage.

The secure element chip as an isolated cryptographic engine

At the hardware level, a secure element is a specialized processor designed to perform sensitive operations in isolation from the main device CPU and operating system. In Tangem’s case, the secure element contains a dedicated cryptographic processor, tamper-resistant memory, and strict communication boundaries. When the mobile app sends a transaction to be signed, the secure element receives only the transaction data—the amounts, recipients, network parameters—not the private key. The chip then performs the signature operation internally using the key that is stored in its own protected memory region.

The tamper resistance is a critical layer. Secure elements are designed to detect and respond to attacks such as power analysis, electromagnetic probing, or attempts to physically access the silicon. If an attacker applies an unusual voltage, attempts to read memory at extreme temperatures, or tries to interrupt the cryptographic operation mid-execution, the secure element can erase sensitive data or stop responding. This is not absolute protection—sufficiently funded actors with laboratory equipment can sometimes extract keys—but it raises the bar far beyond casual malware or remote exploits. The design assumes that most attackers lack access to advanced physical equipment and that the cost of targeted extraction exceeds the value of a single card.

Tangem’s secure element also limits the operations it performs. It does not run a general-purpose operating system, does not interpret arbitrary code from the mobile app, and does not expose its memory contents. Instead, it implements a fixed set of commands: initialize a wallet, derive a public key, sign data with a specific curve and algorithm, or verify a signature. This narrowness is deliberate. A smaller code path is easier to audit, less likely to contain exploitable bugs, and reduces the surface for a malicious app to manipulate behavior. The mobile app cannot instruct the chip to export the key, perform a signing operation on different data than displayed, or weaken the cryptography being used.

How NFC communication restricts data exposure during signing

Tangem uses NFC (near-field communication) as its transport layer between the card and the mobile device. NFC operates over a short range—typically a few centimeters—and requires the card to be physically close to the phone during communication. This proximity constraint alone eliminates a class of remote attacks. An attacker cannot intercept the signing process over the internet or a local network; they must physically touch or closely approach the device while it is actively signing.

The NFC communication itself is not encrypted in a way that the mobile app controls. Instead, the secure element and the NFC interface implement their own protocol, with the chip verifying that commands come from an authorized source and that responses correspond to the operations requested. When a user initiates a transaction signature through the mobile app, the app sends only the transaction hash—a compact cryptographic fingerprint of the transaction—to the card, not the entire transaction. The secure element then signs this hash using the ECDSA (Elliptic Curve Digital Signature Algorithm) or EdDSA algorithm depending on the blockchain and key type.

This pattern is crucial: the secure element signs a hash that was already computed and verified by the mobile app before transmission. This means the app remains responsible for assembling the transaction correctly, ensuring that the amounts and recipients are correct, and that the transaction is addressed to the intended network. The secure element does not re-parse the transaction structure; it only guarantees that the signature on that hash was produced using the stored private key. The user therefore bears responsibility for verifying the transaction details on the phone screen before confirming the NFC tap.

One risk that NFC does not eliminate is transaction substitution between the screen and the signing step. If the mobile app is compromised by malware, the app could display one transaction while sending a different hash to the card for signature. The tangem wallet design assumes a user will verify the transaction details before tapping the card, meaning the phone remains a trusted display channel for human verification. This is not a flaw in the hardware design; it reflects the reality that hardware alone cannot prevent software from misbehaving. The card’s role is to bind the signature to the specific hash, not to re-verify the transaction’s semantic meaning.

Private key derivation and the isolation of cryptographic material

Tangem supports multiple cryptocurrencies on a single card by deriving separate keys for each blockchain using a standard called BIP32 (Hierarchical Deterministic Wallets). The card stores a master seed during initialization, then derives child keys on demand without exposing the master seed to the phone. Each cryptocurrency—Bitcoin, Ethereum, Litecoin, or an ERC-20 token—receives its own derived private key, computed deterministically inside the chip from the master seed.

The derivation process happens entirely within the secure element. The mobile app never learns the master seed, never learns the individual private keys, and never sees the intermediate calculations. Instead, the app sends a request to the secure element specifying the derivation path—a standardized sequence identifying which key to generate—and the chip returns only the corresponding public key. The public key is then used to construct addresses and verify signatures but cannot derive the private key.

This separation between the derivation and exposure of the public key is mathematically asymmetric. Given a public key and a signature, an observer cannot compute the private key or forge a signature. Given the private key, computing the public key is straightforward. By keeping the private key locked in the chip and only releasing the public key, Tangem ensures that an attacker who compromises the phone cannot compute the private key for any blockchain address.

The offline key storage benefit becomes clear at this level. The master seed is generated inside the chip during initialization and never travels to the phone, cloud, or any internet-connected device. If a user loses the physical card, the card can be replaced using a backup that was written to paper or stored offline during setup. Without that backup, no amount of phone data or digital records can reconstruct the private keys. This differs sharply from software wallets, where a master seed phrase is often typed, screenshot, or stored in cloud accounts.

Signature algorithm selection and blockchain compatibility

Different blockchains require different cryptographic algorithms. Bitcoin and Litecoin use ECDSA with the secp256k1 curve, Ethereum uses ECDSA with secp256k1 as well, while newer chains such as Solana use EdDSA (Edwards-curve Digital Signature Algorithm). The secure element must support multiple algorithms and correctly identify which algorithm to apply for each blockchain.

When a user initiates a transaction, the mobile app specifies not only the blockchain and the address but also the algorithm to be used. The secure element enforces this mapping: it will not, for example, sign a Bitcoin transaction using an Ethereum key derivation path, nor will it use the wrong algorithm. This rigidity prevents mistakes where a signature computed for one chain could be replayed on another chain or where the wrong algorithm could accidentally weaken the signature.

The hardware-based cryptographic operations within the chip include constant-time implementations of signature algorithms to prevent timing-based side-channel attacks. A timing attack observes how long a signing operation takes and infers information about the private key from variations in execution time. By ensuring that signature operations take the same amount of time regardless of the key value, the secure element eliminates this category of attack. Similar protections guard against power analysis attacks, where variations in electrical current consumption during signing could leak key information.

Tangem’s support for thousands of cryptocurrencies is therefore not a matter of storing thousands of keys. It is a matter of supporting the key derivation paths and signature algorithms that each network requires, all computed deterministically from a single stored master seed. The architecture remains constant regardless of how many blockchains are added.

Seedless backup and recovery without exposing the key

A traditional hardware wallet backup involves extracting or writing down the seed phrase—the master secret from which all keys derive. Tangem offers seedless backup options as an alternative. The backup can be stored on a second Tangem card, on a paper backup encrypted with a PIN, or through a backup service that stores encrypted key material. None of these methods expose the unencrypted master seed in a format that a user must memorize or write down manually.

The seedless approach works because the backup can be encrypted on the secure element before it leaves the card. The card encrypts the master seed using a key derived from a user’s PIN or a second factor, then stores that encrypted backup on the phone or externally. To restore from backup, a user provides the PIN, and the secure element decrypts the backup and reconstructs the master seed. The backup itself is not the seed; it is an encrypted container that only the card’s secure element can decrypt.

This design reduces one significant risk in hardware wallets: the exposure of the seed phrase during backup. If a user writes the seed on paper and stores it in a home safe, the paper itself is a vulnerability. If the user stores it on a phone or cloud service without encryption, any attacker gaining access to the phone can immediately extract all keys. Tangem’s encrypted backup shifts the burden to the PIN, which the user is responsible for remembering. Recovery requires both the encrypted backup and the correct PIN, making the attack substantially harder without requiring the user to manage a long random string.

The recovery process still requires the secure element architecture. A compromised phone cannot decrypt the backup or reconstruct the seed without the PIN, and it cannot extract the PIN through observation because the secure element performs the decryption internally. If the phone’s software is malicious, it can attempt to guess the PIN, but the secure element enforces rate limiting and erasure policies—after a certain number of wrong attempts, the backup becomes inaccessible.

dApp connectivity and transaction validation flow

Tangem’s mobile app connects to decentralized applications through wallet protocols such as MetaMask’s wallet API for EVM chains and Solana’s wallet adapter. When a user interacts with a dApp—such as approving a token transfer, swapping liquidity, or interacting with a smart contract—the dApp sends a transaction request to the mobile app. The app then displays the transaction details and requests the user to confirm on the physical Tangem card.

This flow preserves the hardware security model even during dApp use. The dApp constructs a transaction and submits it to the wallet, but the wallet does not automatically sign. Instead, it displays the transaction details for the user to review on the phone screen, then requires the NFC tap to authorize the signature. The signing operation happens in the secure element, and the signature is returned to the dApp. The dApp never receives the private key or sees the signing operation in detail; it only receives a valid signature that it can broadcast to the blockchain.

The vulnerability in this flow is not the secure element or the NFC communication. It is the display of the transaction on the phone and the user’s interpretation of it. A malicious dApp could request a transaction with different terms than what the user expects, or a compromised phone could display false transaction details. The secure element cannot correct for these risks because it does not parse transactions; it only signs hashes. The user must therefore develop the habit of carefully reading the transaction details—the recipient address, the amount, the gas parameters, and the contract address—before confirming the tap.

Threat model and practical limitations

Tangem’s architecture protects strongly against malware on the phone, remote key extraction, and phishing attacks targeting the private key. It does not protect against a user who taps the card to sign the wrong transaction, shares the PIN, or loses the card and backup without security measures. The threat model assumes that the phone’s display is trustworthy for showing transaction details, that the user will verify the information before confirming, and that backups are stored securely.

Physical attacks on the card itself are possible but difficult. An attacker would need to physically access the card and apply specialized equipment to extract the secure element’s contents. The cost and expertise required are high enough that this attack is impractical for low-value targets. For very high-value holdings, more conservative approaches such as air-gapped signing or multi-signature schemes may be appropriate, even alongside a Tangem card.

The NFC communication is susceptible to jamming, where an attacker blocks the signal to prevent the card from being read. An attacker could also attempt to relay the NFC signal from a distance using specialized equipment, though this is technically difficult and not a practical concern for most users. The proximity requirement for NFC does eliminate many remote attack vectors that apply to software wallets or internet-connected signing services.

The mobile app itself remains a potential attack surface. If the app is compromised through a supply-chain attack, the app store, or a zero-day vulnerability, it could display false transaction information or attempt PIN guessing attacks against the backup. Users should download the Tangem mobile app only from official sources, keep it updated, and monitor permissions. The app cannot extract keys or sign transactions without NFC contact to the physical card, which mitigates the impact of app compromise.

Why hardware-based isolation matters for self-custody

The fundamental principle of a non-custodial hardware wallet is that the user alone holds the keys, and no service provider, company, or external party can access them. Tangem’s secure element architecture enforces this through hardware isolation rather than relying on user behavior or software permissions. Even if Tangem as a company wanted to extract your private keys, the secure element’s design would prevent them from doing so without physical possession of the card and laboratory equipment to extract the chip.

This contrasts with software wallets, where a compromised update, a malicious plugin, or even the wallet provider itself could theoretically have access to keys. It also contrasts with custodial services, where a company holds keys on your behalf and you rely on their security practices, their legal obligations, and their business continuity. A Tangem card makes self-custody concrete and verifiable: you hold the physical object, you control the PIN, and you maintain the backup. No private key ever exists outside the secure element unless you explicitly extract it during recovery, which you should do only offline and with extreme care.

The mobile-first design means that users do not need to purchase additional hardware—a separate computer, a USB cable, or a display—just to use the wallet. The card works with any NFC-capable smartphone, making it practical for everyday use while maintaining the security properties of a hardware wallet. This practicality is important because security systems that are too cumbersome tend to be abandoned or circumvented. A wallet that is convenient enough to use regularly is more likely to remain in use rather than being set aside in favor of a less secure but easier option.