The Vulnerability Exposing Tangem Cards to Brute-Force Attacks

TL;DR

Ledger Donjon discovered a new online brute-force attack against Tangem cards that exploits vulnerabilities in their secure channel implementation leveraging a “tearing” technique. This allows attackers to bypass the card’s security delay mechanism after failed authentication attempts, enabling them to try approximately 2.5 passwords per second, significantly accelerating the time to crack passwords, especially weak ones. The vulnerabilities cannot be patched on existing cards because they’re not upgradable. Users are advised to use strong passwords (at least 8 characters with a mix of digits, letters, and symbols).

All findings have been disclosed responsibly with a delay of 90 days. Tangem assessment of the Donjon’s report concluded that it won’t be classified as a vulnerability. In their opinion, the proposed attack scenario does not pose a significant risk.

This article details the Donjon’s research process behind Tangem’s card security delay feature, examining its protection, introducing tearing attacks, and outlining our failed attempts as well as the discovery of the final vulnerability.

Tangem Password Brute-force Protection

The Tangem card includes a brute-force protection mechanism. After 6 incorrect password attempts, a security delay of 1 second is enforced before the next attempt is permitted. Each subsequent incorrect attempt further increases this delay by 1 second, up to a maximum of 45 seconds.

Consequently, trying all possible combinations for a Tangem card locked with a 4 digits PIN would take about 5 days. For a 6-digit PIN, this duration extends to approximately 520 days, and for an 8-digit PIN, it can reach up to approximately 143 years.

Given that the password must be composed of at least 4 alphanumeric characters, it makes the bruteforce significantly harder except if the user chooses a weak password (for instance a 4 digits PIN or a really common password such as “password”, “123456”, …).

This protection mechanism typically relies on an internal counter that tracks authentication failures. This counter, however, can be vulnerable to hardware attacks such as fault injection as well as simpler ones like tearing when the counter increment/decrement happens after the authentication failure.

What is a “Tearing” Attack?

A “tearing attack,” or “card tear-off attack,” exploits how embedded systems, like those in smart cards, behave when power is abruptly cut during an operation, preventing its completion. One of the goals can be to “tear” the card away from its power source before it can record an event, such as a failed authentication attempt. This basic attack is commonly tested on smart cards and secure elements.

It primarily affects the card’s flash memory or other non-volatile storage where crucial state information, like an authentication failure counter, is kept. If power is interrupted before the card can write the updated counter value to persistent memory, then the counter won’t be updated. This could therefore allow an attacker to make unlimited authentication attempts without triggering security delays or locking mechanisms, thus enabling password brute-force attacks that would otherwise be impossible.

The success of such an attack mostly depends on precise timing and understanding the device’s internal processing cycles.

These attacks are well-known within the contactless card security community. The Java Card platform, commonly used in NFC cards, includes built-in protections like atomic transactions to mitigate this kind of vulnerability. However, it is vital for the running applet to call the provided platform API. Failure to do so can leave a card vulnerable to such attacks.

For instance, one strategy to protect an authentication mechanism against tearing attacks involves increasing a failure counter prior to performing the verification and resetting this counter only upon successful authentication.

Vulnerability Discovery

During our evaluation, we started to take an interest in the security delay countermeasure. This interest stemmed from its frequent activation upon multiple errors, and also from the common practice in hardware wallets of erasing the user seed after three failed authentication attempts. Tangem cards cannot be erased without knowing the card password, making the security delay countermeasure the primary protection mechanism.

Security Delay Bypass

We used a Proxmark 3 rdv4 to determine when exactly the security delay related counter is updated. This was attempted by testing all possible tear-off timings.

For a given tear-off timing, if a security delay is triggered, it means that the security delay related counter was successfully updated by the card. On the other hand, if no security delay is triggered, it means that the card did not have time to update the counter.

The following diagram illustrates the frequency of security delay activations across five attempts, specifically after seven failed authentication attempts for a read wallet command sent to the card.

We’ve determined that if a card is powered off in under approximately 6700 μs after the command is sent, then no security delay will be activated. During our testing, we also found that this timing can vary up to 1000 μs depending on the card as well as its temperature.

However, Java Card platforms typically offer authentication APIs designed to resist such attacks. This suggests with a high probability that the password verification occurs after the tearing timing in the blue area, ensuring the trigger counter is correctly updated before authentication. To ascertain whether the implementation adheres to best security practices or is susceptible to tearing, we need to verify if we can determine the correctness of the entered password before the tear-off period, in the orange area, thereby avoiding a security delay.

Since the authentication as well as the security delay counter update both precede the response, we are tearing off the card before receiving our command’s response. Therefore, we aim to identify a discernible difference before the tearing occurs, in the orange area of the diagram, that either indicates a successful or an unsuccessful authentication.

Card Electromagnetic Emissions Analysis

We opted to measure the electromagnetic field emitted by the chip during command processing, as it is quite difficult to acquire the power consumption of contactless cards.

Since the card’s communication requires a magnetic field strong enough to energize it, we’ve opted to externalize the card antenna. This approach ensures the protection of our signal amplifier and minimizes noise from the reader’s field, focusing solely on the chip’s electromagnetic emissions. To achieve this, we can either cut into the plastic with a scalpel or use a dremel. Afterward, we detach the card antenna and solder our own onto the two pads using a thin wire that replicates the card’s shape.

Note: at this point we can also remove the thin metal panel to see the silicium making this sample ready for laser fault injection.

On the picture below, you can see the global setup we used for this attack as well as an EM (electromagnetic) trace on the oscilloscope with the tear-off happening at the very end:

Now, we can acquire thousands of traces and try to distinguish a correct from an incorrect authentication attempt while tearing-off the card to avoid getting any security delay.

Our attempt to attack the authentication of the “read wallet” command was unsuccessful, but we still had other ideas to try. Given the lack of source code access and persistent noise from the reader field, we cannot definitively confirm the vulnerability of the implementation to such an attack, although this does not appear to be the case.

Not So Secure Channel

During our evaluation, we came across a secure channel implementation. The goal of such a secure channel is to guarantee that data exchanged between the smartphone and the card (for instance the card’s password) cannot be sniffed by anyone nearby.

Although a secure channel is implemented on both the application and the card, it is never activated. This is regrettable, as we successfully enabled it by altering a single boolean value in the smartphone application.

However, there is one important detail regarding the secure channel implementation: the encryption key is derived from the user’s password. This means that by brute-forcing the secure channel’s encryption key, we can brute-force the user’s password.

While diving into this feature, we identified the following issues with the card secure channel implementation:

• It is susceptible to tearing, allowing the attacker to power off the card before error management occurs if the card fails to decrypt data due to an incorrect password. Consequently, the security delay is never triggered.
• When processing an encrypted command, the card’s electromagnetic emissions vary based on the correctness of the password (used for commands encryption), enabling differentiation between correct and incorrect passwords before tear-off occurs.

It is regrettable that an attack is made possible by a security feature that Tangem is not using.

Vulnerability Exploitation

To exploit these vulnerabilities in the secure channel implementation, we used exactly the same techniques as mentioned during our failed attempt on the access code authentication when sending a “read wallet” command.

First, we determined the maximum tear-off timing before triggering a security delay when using a secure channel with the incorrect card’s password. To do that, we followed the same steps as described in the Security Delay Bypass section.

Then, we acquired electromagnetic traces of commands sent over the secure channels established with either correct or incorrect passwords, using the setup described in the Card Electromagnetic Emissions Analysis section.

In the previous diagram, each color (green, blue, orange, red, purple) represents the trace of one execution. The traces are still very noisy (we don’t see any pattern indicating what the chip could be doing at a specific time). However, we can clearly see that at some point (see “Area of interest”), the chip is doing much less work, thus reducing the electromagnetic emissions. Especially, when we successfully exchange a command over the secure channel (meaning that we found the correct card’s password), we can see lots of peaks compared to the traces of failed secure channels.

Thanks to the tearing attack, we can now distinguish successful secure channel exchanges from unsuccessful ones without triggering security delays. If the card decrypts our secure command, the password we tried is correct. We can repeat this with different passwords, limited only by the card’s processing time.

The estimated cost for this attack setup is under $5,000 (as a high-end oscilloscope is unnecessary).

Given the black-box nature of our analysis, pinpointing the exact root cause is challenging. The most plausible explanation is that it stems from the applet updating the authentication failure counter only after a decryption failure, allowing time for tearing and trace discrimination.

Impacts

Without robust password policies, users employing weak passwords face considerable risk, as they cannot rely on the security delay countermeasure.

It is important to note that this attack requires physical access to a Tangem card. While the setup cost is relatively low, making it accessible to a wider range of attackers, the need for physical proximity to the target card remains a prerequisite.

This vulnerability enables a brute-force rate of approximately 2.5 passwords per second, a significant increase from the usual security delay rate of 1 password every 45 seconds. This accelerates password brute-forcing by over a hundred times compared to relying on the security delay countermeasure. Further optimization and specialized hardware could enhance this brute-force rate.

Password format	With the attack	Without the attack
4 digits PIN	~1 hours	~5 days
6 digits PIN	~4.5 days	~520 days
8 digits PIN	~460 days	~143 years

Using this attack, we can significantly reduce the time required to crack a Tangem card’s password but it remains hard to brute-force a fully random 8 alphanumeric character password. However, it’s important to note that simple brute-forcing, which involves trying every single possible character combination, is rarely the primary attack vector in real-world scenarios. This is largely due to human behavior: users typically do not select truly random passwords because they need to be easily remembered.

Instead, attackers commonly employ “dictionary attacks.” These methods leverage pre-compiled lists of commonly used passwords, dictionary words, leaked passwords from previous breaches, or common patterns (e.g., “password123”, “qwerty”). By using such wordlists, attackers can perform an optimized brute-force which is likely to be far more efficient than a truly random brute-force for human-chosen passwords.

This vulnerability could allow an attacker to attempt one million common passwords in about 4.5 days. This significantly heightens the risk for users opting for weak or commonly used passwords, as the time required to compromise their card becomes significantly shorter than the estimates for perfectly random passwords. 

Remediation

During our responsible disclosure with Tangem, we made several recommendations to fix or mitigate the identified vulnerabilities.

Recommendations

Regarding the secure channel implementation, we believe that incrementing the failure counter before doing anything else and decrementing it after a successful authentication would fix the issue. However, it can’t be patched in existing products because Tangem cards are not upgradable. 

Therefore, we recommended enforcing an access policy within the Tangem app to require users to select robust passwords:

• At least 8 characters
• At least 1 digit, 1 letter, and 1 symbol
• Disallow weak passwords such as passw0rd!

Current users must be required to upgrade their passwords if they do not comply with this policy.

Particularly, given the unlimited authentication attempts, the password length should be chosen to match the time it would take to brute-force it with the time required to compromise ECDSA security. With conservative parameters:

• $5,000 computer achieving a speed of 100,000 ECDSA operations per second
• 2^128 operation needed to brute-force an 256 bits ECDSA key
• Passwords are made using random 95 english characters (including digits and symbols)

We estimate that a password of 8 characters or more is needed to achieve the same security level as the seed. The use of a supercomputer significantly increases the required password length.

If you’re a Tangem user, we recommend using a strong password (following the recommendations above) to significantly reduce chances of success of such an attack.

Timeline

Responsible disclosure started on Jun 12th, 2025.

• Jun 12, 2025 : A report detailing the reproduction of an online bruteforce attack against Tangem cards, along with a Proof-of-Concept video and possible mitigations, was initially disclosed to Tangem security team. Tangem promptly acknowledged this disclosure the same day.
• Jul 15, 2025 : First follow-up.
• Jul 18, 2025 : Tangem replied it took them time to reproduce the attack setup and that they should come with a full response at the end of July.
• Aug 19, 2025 : Second follow-up.
• Aug 20, 2025 : Tangem replied they were still reproducing and assessing and would come back with a full response before the end of responsible disclosure.
• Sep 8, 2025 : New followup sent to request a mitigation and communication alignment before publication.
• Sep 11, 2025 : Tangem responded with their assessment of our report, stating that the identified issues do not qualify as vulnerabilities. In their opinion, the proposed attack scenario didn’t pose a significant risk. They encouraged us to publish our work.
• Sep 16, 2025 :We thanked Tangem for their detailed response and announced our publication date.

---

Baptistin Boilot

Security Engineer