By web3ru research — 02 янв. 2026

Криптокошелек Tangem – доверять картам?

Tangem — аппаратный (self‑custody) криптокошелёк в форм‑факторе NFC‑карты. Исторически ключевая идея продукта — seedless‑модель: приватный ключ генерируется внутри защищённого чипа на карте и не выводится в виде seed‑фразы. Вместо бумажного бэкапа на 12/24 слова резервирование делается физически — через дополнительные карты в комплекте.

Позже Tangem добавил поддержку кошельков с seed‑фразой (генерация/импорт), но это отдельный режим с иной поверхностью риска — и именно в нём в 2024 году проявился один из наиболее заметных публичных инцидентов, связанный с логированием приватного ключа в приложении [10].

О компании и контексте доверия (не про "рекламу", а про проверяемые факты)

Tangem AG — швейцарская компания. По данным публичной реестровой информации, запись о компании в торговом реестре датируется 28.07.2017, а в 2025 году зафиксирован перенос юридического адреса (sitz) в Люцерн [1].

Публично обсуждаемые раунды финансирования включают:

инвестицию $15 млн от SBI Crypto Investment Ltd. (группа SBI) в январе 2019 года [2];
раунд $8 млн, заявленный Tangem как возглавленный Shima Capital (май 2023) [3].

Эти факты важны не как “гарантия безопасности”, а как часть контекста: наличие истории, инфраструктуры, партнёров и публичных следов снижает вероятность “одноразового” проекта — но само по себе не отменяет технических рисков.

Отдельно стоит отделять продукт Tangem Wallet (карты/кольцо) от Tangem Pay. Tangem описывает Tangem Pay как платёжный продукт с виртуальной Visa‑картой и упоминает прохождение “VISA payment system certification” перед стартом производства [17], а также публикует детали запуска/rollout в 2025 году [18][19]. Для модели доверия это означает: у компании есть направления, где появляется больше внешних контрагентов и регуляторных процессов (например, KYC), но это не является прямым доказательством безопасности именно карточного кошелька как хранилища приватных ключей.

Как устроен Tangem с картами: ключевая развилка в понимании

Три карты — это не "2‑из‑3" и не мультисиг

Комплект “2–3 карты” в базовой seedless‑модели Tangem — не схема разделения секрета (Shamir) и не модель “нужно две карты, чтобы потратить”. Это ближе к “несколько одинаковых ключей от одной двери”.

При создании кошелька ключ создаётся на одной карте и затем клонируется на 1–2 резервные карты через протокол взаимной аутентификации и шифрованный обмен, описанный Tangem как механизм “secure private key cloning / backup” [20]. В результате каждая карта становится полноценным подписывающим устройством: при наличии карты и успешной аутентификации по Access Code возможно подписание транзакций одной картой.

Практическое следствие: если посторонний получает одну карту и получает/подбирает её Access Code, этого достаточно для траты средств (по умолчанию не требуется “вторая карта”).

Что делает телефон

Телефон в этой модели — это:

интерфейс для формирования транзакции и отображения адресов/сумм;
канал отправки подписанной транзакции в сеть;
“экран доверия” (у карты нет дисплея, поэтому визуальная верификация полностью на стороне телефона).

Приватный ключ при этом остаётся в карте; подпись выполняет карта. Но отсутствие собственного экрана создаёт отдельный класс рисков (“blind signing”), о нём ниже.

Что значит "доверять аппаратному кошельку" в доказательном смысле

Проверка аппаратного кошелька обычно раскладывается на слои:

Железо (Secure Element): устойчивость к физическому извлечению ключа (side‑channel, fault‑injection, инвазивные атаки).
Прошивка устройства: отсутствие бэкдоров/недокументированных функций; контроль целостности; кто и как может обновлять.
Приложение/SDK: ошибки логирования, телеметрии, интеграций поддержки; корректность проверок подлинности; supply‑chain‑риски со стороны софта.
Производство и поставки: риск подмены/контрафакта.
Операционная безопасность: Access Code, хранение резервных карт, безопасность телефона, осторожность при подписании транзакций.

Tangem усиливает одни слои (secure element, отсутствие seed‑фразы в seedless‑режиме), но осознанно принимает компромиссы в других (нет экрана; прошивка не является полностью открытой; firmware не обновляется).

Доказательная база: что подтверждено независимыми и/или первичными источниками

Независимый аудит прошивки (Kudelski Security, 2018)

Kudelski Security (публикация от 6 августа 2018) описывает аудит исходного кода смарт‑карты Tangem и прямо заявляет:

аудит охватывал внутреннюю логику по исходному коду;
устойчивость к физическим атакам они не оценивали;
“не нашли бэкдора, вредоносных или подозрительных недокументированных функций”;
для фиксации проверенной версии они скомпилировали firmware v1.28 и сохранили “binary fingerprint”, который может использоваться хост‑приложениями для проверки целостности [4].

Сильная сторона — внешний (не Tangem) источник с чёткими формулировками. Ограничения — возраст аудита и то, что полный отчёт не опубликован (Kudelski объясняет это проприетарностью) [4].

Второй аудит (Riscure, 2023): известно только публичное резюме

Tangem публикует пост от 2 декабря 2023 о втором аудите, где утверждается, что Riscure:

изучала исходный код и архитектуру;
тестировала функциональность и команды, доступные через NFC‑интерфейс;
не выявила проблем, ведущих к раскрытию приватных ключей, и “не обнаружила бэкдоров” [5].

Важно: это публичное резюме со стороны Tangem, а не полный публичный отчёт Riscure. Доказательная ценность есть (сам факт привлечения лаборатории и описанный scope), но независимая перепроверка сообществом ограничена.

Сертификация Secure Element (Common Criteria / ANSSI) и корректная интерпретация “EAL”

Для класса угроз “попробуют физически извлечь ключ из чипа” важна сертификация микросхемы по Common Criteria. В публичных реестрах Common Criteria фигурирует сертификационный пакет Samsung с идентификатором ANSSI‑CC‑2024/15‑R01 [6][7][8].

Критичная точность формулировок:

сертификат относится к чипу/компоненту, а не к “кошельку целиком” [7][8];
в самом сертификате указано: EAL5 augmented для оценки TOE в целом и EAL6 augmented для ряда подчастей; в публичных пересказах это нередко сводят к короткой формуле “EAL6+” [7][8];
документы сертификации прямо подчёркивают, что сертификат не гарантирует отсутствие эксплуатируемых уязвимостей [7][8].

Даже с этими оговорками наличие высокоуровневой сертификации Secure Element — сильный аргумент именно для угроз класса “извлечение ключа физически”.

Необновляемая прошивка: меньше риск "вредоносного апдейта", но и меньше возможностей чинить железо

Tangem заявляет: firmware загружается в чип один раз и не может быть обновлена; это позиционируется как снижение риска подсовывания вредоносного обновления [9]. Та же особенность фигурирует и в отчёте Ledger Donjon как практическое ограничение: обнаруженные уязвимости “не могут быть пропатчены на существующих картах” из‑за неапгрейдности [13].

Эта архитектура действительно закрывает целый класс рисков (“вендор/злоумышленник подсунул обновление”), но открывает другой: если в прошивке обнаруживается фундаментальная ошибка, исправить её на уже выпущенных картах нельзя.

Приложение/SDK и прозрачность части софта

Tangem публикует часть клиентского кода (приложение/SDK) в виде открытых репозиториев на GitHub [22]. Tangem также указывает GitHub как один из официальных источников установки приложения наряду с App Store и Google Play [21].

Открытость клиентского кода помогает аудитировать логику формирования транзакций, сетевые взаимодействия и потенциальные утечки через логи/телеметрию. При этом открытость приложения/SDK не заменяет аудит прошивки карты.

Инциденты и уязвимости: что происходило и как это читать без истерики

Декабрь 2024: логирование приватного ключа в seed‑режиме (исправлено)

Tangem описывает инцидент так (пост 31 декабря 2024):

при активации кошелька с seed‑фразой (генерация или импорт) приватный ключ ошибочно попадал в логи мобильного приложения;
потенциальный риск возникал только при сочетании условий: (1) seed‑активация и (2) обращение в поддержку через приложение в течение 7 дней (период хранения логов) [10];
исправление выпущено в версиях приложения iOS 5.19.1 и Android 5.19.2;
Tangem заявляет, что логи/вложения, отправленные в поддержку, были удалены, и что “ключи не были скомпрометированы, средства не потеряны” [10].

Как интерпретировать:

это проблема уровня приложения/процессов поддержки, а не “ключ вытащили из Secure Element”;
это сильный аргумент, почему seed‑режим меняет риск‑профиль: при seed‑активации чувствительный материал появляется на стороне приложения хотя бы кратковременно (иначе логировать было бы нечего).

CVE‑2025‑27839: логическая ошибка в Android‑SDK при проверке подлинности (исправлено)

В NVD опубликована запись CVE‑2025‑27839: в Tangem SDK для Android до версии 5.18.3 описана ошибка логики “offline wallet attestation (genuineness check)”, при которой результат проверки мог быть проигнорирован на первом сканировании карты; NVD также отмечает, что эксплуатация могла быть невозможна [11].

Ledger Donjon публиковал разбор “genuine check bypass” для Android‑приложения Tangem (пост от 15 мая 2025), описывая риск в контексте поддельных/контрафактных карт и подчёркивая важность корректной проверки подлинности [12]. В этом кейсе указано, что исследователи получили bounty $15,000 [12].

Как интерпретировать:

это риск класса supply chain (“контрафактная карта + ошибка genuine‑check”);
это не “удалённый взлом легитимной карты”, но это практический довод покупать устройство из доверенного канала и держать приложение обновлённым.

Сентябрь 2025: Donjon‑отчёт про "tearing" и ускоренный brute‑force Access Code (спор о практичности, но класс угроз реален)

Ledger Donjon (пост 17 сентября 2025) описывает атаку, которая за счёт “tearing” позволяет обходить механизм задержек после неверных попыток ввода Access Code. В TL;DR заявляется порядок ~2.5 попытки/сек вместо медленного режима с задержками, и подчёркивается, что уязвимости не патчатся на существующих картах из‑за неапгрейдности firmware [13]. Там же приводится логика задержек: после 6 неверных попыток задержка растёт до максимума 45 секунд [13] — и это согласуется с описанием механизма Access Code у Tangem [15].

Tangem в ответном посте того же дня (17 сентября 2025) называет сценарий лабораторным и утверждает, что при длительной атаке будет происходить физическая деградация чипа, а фокус на “4‑значных PIN” вводит в заблуждение, поскольку Access Code может быть буквенно‑цифровым с символами [14].

Как интерпретировать аккуратно:

это атака с физическим доступом к карте и спецоборудованием, а не “взлом по интернету”;
практический риск резко растёт, если выбран слабый код (короткий цифровой PIN или популярные шаблоны);
при длинном буквенно‑цифровом коде пространство перебора становится огромным, а атака теряет смысл даже при ускорении;
из‑за необновляемой прошивки “железного патча” для уже выпущенных карт не будет; защита в реальности упирается в политику Access Code и пользовательскую дисциплину.

Главные аргументы критиков и что в них действительно по делу

Закрытая прошивка и неполные публичные отчёты

Kudelski публикует понятное резюме, но не публикует полный отчёт [4]. По аудиту Riscure публично доступно только резюме со стороны Tangem [5]. Это означает неизбежную “зону доверия” к вендору и аудиторам: сообщество не может воспроизвести проверку полностью.

Кошельки с дисплеем дают независимую от телефона/ПК верификацию суммы/адреса/сообщения на самом устройстве. У Tangem экрана нет, поэтому при компрометации телефона остаётся риск “показали одно — подписалось другое”, особенно в сложных DeFi‑подписях.

Открытость части клиентского кода помогает анализировать логику формирования транзакций, но не убирает фундаментальную проблему: подтверждение на стороне потенциально уязвимого устройства.

Seedless‑модель: минимизирует фишинг seed‑фразы, но усиливает риск "потерял всё физически"

Seedless убирает один из главных человеческих провалов в крипте — утечки/фишинг seed‑фразы. Цена — потеря всех карт в seedless‑режиме означает потерю доступа (восстанавливать нечего).

Дополнительное практическое ограничение: Tangem указывает, что после завершения бэкапа нельзя “добавить ещё одну карту” в уже существующий кошелёк; для добавления устройства требуется сброс и создание нового кошелька с последующим переносом средств [16]. Аналогичное ограничение описано и в техническом разборе механики бэкапа [20].

Необновляемая firmware: сильный плюс против "вредоносных апдейтов", но минус для будущих исправлений

Неапгрейдность закрывает вектор “обновлением подсунули бэкдор” [9], но делает некоторые классы уязвимостей “вечными” для уже выпущенных карт (пример — позиция Ledger о непатчимости в контексте tearing‑класса) [13].

Tangem vs Ledger / Trezor / SafePal / MetaMask: разные компромиссы, а не рейтинг "лучше/хуже"

Tangem (карты): ставка на Secure Element и seedless‑подход (в seedless‑режиме приватный ключ не выводится в приложение) — сильная защита от фишинга seed‑фразы и компрометации seed‑хранилищ. Компромиссы: отсутствие экрана, “физический бэкап картами” и зависимость безопасности от Access Code и гигиены телефона.
Классические hardware‑кошельки (Ledger/Trezor/SafePal): обычно используют seed‑фразу как базовый механизм восстановления; часто имеют экран для независимого подтверждения. Компромиссы зависят от вендора (открытость, архитектура secure element, история инцидентов, модель обновлений).
Software‑кошельки (MetaMask/OKX Wallet и др.): другой класс угроз: ключ хранится в среде, которая постоянно контактирует с интернетом и сторонними расширениями/приложениями. Аппаратные устройства (включая Tangem) обычно дают качественный выигрыш именно за счёт физической изоляции ключа — при условии, что подпись не превращается в “слепую” и что Access Code действительно стойкий.

Гигиена использования набора "3 карты" и план действий при инцидентах

Access Code: главный рычаг защиты в сценарии "карту нашли/украли"

Tangem допускает Access Code от 4 символов и описывает механизм задержек при ошибочных попытках (с ростом до 45 секунд) [15]. Исследования Ledger Donjon показывают, что при определённых сценариях взаимодействия “ускорение” может делать слабые коды существенно более уязвимыми при физическом доступе [13].

Практический вывод: короткий цифровой PIN — худший вариант. Длинный буквенно‑цифровой код со спецсимволами резко повышает стойкость к подбору, даже если предполагается ускорение попыток.

Разделение хранения: 1 карта "оперативная", 2 карты — в разных местах

Базовая дисциплина для 3‑картного набора:

одна карта — для повседневных операций;
две резервные — разнесены (не в одном кошельке/сейфе/сумке).

Цель — чтобы один инцидент (кража, пожар, потеря) не уничтожал все копии ключа.

Восстановление/сброс Access Code и почему важно не оставаться с одной картой

Tangem описывает возможность сброса Access Code при забытом коде как процесс, требующий наличия двух устройств из набора [15]. Потеря двух карт и забытый Access Code на последней карте — сценарий, в котором можно упереться в безвозвратную потерю доступа.

План при потере/краже одной карты

С учётом того, что:

любая одна карта потенциально достаточна для подписи при знании/подборе Access Code;
добавить “новую” карту в существующий кошелёк нельзя без пересоздания набора [16][20];
часть классов атак на Access Code обсуждается как непатчимая для уже выпущенных карт [13];

консервативный план выглядит так:

считать потерянную карту скомпрометированной по определению (как мера устранения неопределённости);
создать новый кошелёк (новый набор Tangem или другой hardware‑кошелёк);
перевести средства на новые адреса;
старый набор (оставшиеся карты) использовать только после полной инвентаризации того, какие активы и куда перенесены, либо не использовать вовсе.

Телефон как поверхность атаки (из‑за отсутствия экрана)

Практика снижения риска:

не рекомендуется использовать root/jailbreak‑устройства для “холодного” хранения;
для существенных сумм целесообразен выделенный смартфон без лишних приложений и расширений;
для активного DeFi часто выделяют отдельный “горячий” кошелёк под рискованные взаимодействия, а аппаратный кошелёк — под хранение.

Обновления приложения — часть безопасности, а не косметика

Инцидент с логами в seed‑режиме был исправлен обновлением приложения [10]. Уязвимость genuineness‑check в Android‑цепочке фигурирует как исправленная в релизах SDK/приложения [11][12]. Следовательно, регулярные обновления — реальная мера снижения риска.

Итог: что подкреплено лучше всего, а где остаётся "зона доверия"

Подкреплено лучше всего

независимое публичное резюме аудита Kudelski (2018) с заявлением об отсутствии бэкдоров/недокументированных функций в проверенной firmware и с описанием “fingerprint” проверенной сборки [4];
факт и публичное описание второго аудита Riscure (2023) (но без полного публичного отчёта) [5];
наличие публичной сертификации Secure Element по Common Criteria с идентификатором ANSSI‑CC‑2024/15‑R01 и оговорками о пределах сертификации [6][7][8];
документированная неапгрейдность firmware [9] (как плюс против вредоносных обновлений и как минус для “железных патчей”);
публичные инциденты уровня приложения/SDK и их исправления (Dec 2024, CVE‑2025‑27839) [10][11];
подтверждённый кейс bug bounty с выплатой $15,000 (в контексте genuine check bypass) [12].

Зона доверия и встроенные компромиссы

прошивка карты не является полностью открытой и публично воспроизводимо‑аудитируемой;
отсутствует независимый экран подтверждения (модель blind signing);
в seedless‑режиме восстановление при утрате всех карт отсутствует “по определению”;
неапгрейдность firmware означает, что часть классов проблем может быть решаема только через софт‑политику (например, требования к Access Code) и дисциплину пользователя [13][15].

Tangem не выглядит “игрушкой”: у проекта есть независимые аудиторские следы и серьёзный упор на Secure Element. Но это и не “абсолютная крепость”: безопасность здесь строится на конкретных компромиссах, и главный практический риск при утрате карты смещается в сторону стойкости Access Code и качества “экрана доверия” (телефона).

Источники

[1] Tangem AG — реестровая информация (дата регистрации, изменения и перенос в Luzern)
https://www.moneyhouse.ch/en/company/tangem-ag-14771977121

[2] PRNewswire (21 Jan 2019) — Tangem raises $15M from SBI Crypto Investment Ltd.
https://www.prnewswire.com/news-releases/tangem-raises-15m-from-sbi-for-the-industrial-adoption-of-blockchain-enabled-smart-cards-300781293.html

[3] Tangem Blog (2 May 2023) — Investment round led by Shima Capital ($8M)
https://tangem.com/en/blog/post/tangem-successfully-closes-investment-round-fueled-by-shima-capital/

[4] Kudelski Security (6 Aug 2018) — Audit of Tangem's smartcard wallet code (v1.28 fingerprint, no backdoor claim, scope limits)
https://kudelskisecurity.com/research/audit-of-tangems-smartcard-wallet-code

[5] Tangem Blog (2 Dec 2023) — Tangem Wallet Riscure audit (публичное резюме от Tangem)
https://tangem.com/en/blog/post/tangem-wallet-riscure-audit/

[6] Common Criteria certificate summary (ANSSI‑CC‑2024/15‑R01) — sec‑certs
https://sec-certs.org/cc/1a1da97fccd26feb/

[7] Common Criteria portal — ANSSI certificate PDF (Certificat‑CC‑2024_15‑R01fr.pdf)
https://www.commoncriteriaportal.org/nfs/ccpfiles/files/epfiles/Certificat-CC-2024_15-R01fr.pdf

[8] Common Criteria portal — ANSSI certification report PDF (ANSSI‑CC‑2024_15‑R01fr.pdf)
https://www.commoncriteriaportal.org/nfs/ccpfiles/files/epfiles/ANSSI-CC-2024_15-R01fr.pdf

[9] Tangem Help Center — Firmware & Authenticity (firmware загружается один раз и не обновляется)
https://tangem.com/en/help-center/security/firmware-authenticity/

[10] Tangem Blog (31 Dec 2024) — Log issue in seed‑phrase activation (условия, версии фикса)
https://tangem.com/en/blog/post/tangem-resolves-log-issue/

[11] NVD (NIST) — CVE‑2025‑27839 (Android SDK, attestation logic flow, fixed before 5.18.3)
https://nvd.nist.gov/vuln/detail/CVE-2025-27839

[12] Ledger Donjon (15 May 2025) — Tangem Genuine Check Bypass on Android Application (включая bounty $15,000)
https://www.ledger.com/tangem-genuine-check-bypass-on-android-application

[13] Ledger Donjon (17 Sep 2025) — Brute‑force attack / tearing technique
https://www.ledger.com/blog-brute-force-attack-tangem

[14] Tangem Blog (17 Sep 2025) — Response to Donjon report (позиция Tangem о практичности)
https://tangem.com/en/blog/post/donjon-report/

[15] Tangem Help Center — All about access code (правила, сброс, задержки при ошибках)
https://tangem.com/en/help-center/security/all-about-access-code/

[16] Tangem Help Center — Wallet creation issues (backup можно сделать один раз; добавление устройства требует reset)
https://tangem.com/en/help-center/troubleshooting/wallet-creation-issues/

[17] Tangem Blog (20 Sep 2024) — Tangem Pay Explained: VISA x Tangem AMA
https://tangem.com/en/blog/post/tangem-pay-visa/

[18] Tangem Blog (5 Nov 2025) — Tangem Pay: Launch details
https://tangem.com/en/blog/post/about-tangem-pay/

[19] The Paypers (11 Nov 2025) — Tangem Pay gradual launch (внешний обзор, включая KYC)
https://thepaypers.com/crypto-web3-and-cbdc/news/tangem-pay-to-start-its-gradual-launch

[20] Tangem Blog (19 Dec 2025) — How Tangem Wallet backs up private keys (клон приватного ключа на backup‑карты; один бэкап)
https://tangem.com/en/blog/post/how-tangem-wallet-backs-up-private-keys/

[21] Tangem Help Center — Getting started (официальные источники установки приложения: App Store / Google Play / GitHub)
https://tangem.com/en/help-center/getting-started/

[22] GitHub — Tangem (репозитории приложения/SDK)
https://github.com/tangem