Andrey Lazutkin de Tangem defiende la simplicidad en las billeteras de

El marketing actual de las billeteras de hardware suele ir en una sola dirección: más funciones, más pantallas, más conectividad, más actualizaciones de firmware. Tangem apostó por lo contrario y construyó todo su producto bajo esa premisa.
 

No hay pantalla, ni batería, ni conectividad USB o Bluetooth, ni firmware actualizable, ni frase semilla que anotar. Para muchos en la comunidad de seguridad, esto puede parecer una lista de características esperadas en una billetera cripto; sin embargo, en realidad es una lista de funcionalidades omitidas deliberadamente.
 

Yellow Media conversó con el CTO de Tangem, Andrey Lazutkin, y profundizó justamente en ese enfoque. 

• ¿Qué sucede si el celular está comprometido? 
• ¿Por qué lanzar un firmware que nunca se puede actualizar? 
• ¿Qué protege a Tangem Ring de un ataque NFC en un tren lleno de gente? 
• ¿Y qué pasa cuando llegue la computación cuántica?

El problema de no tener pantalla: ¿y si el celular miente?

Un principio clave de las billeteras de hardware tradicionales es "Lo que ves es lo que firmas": una pantalla en el dispositivo que permite a los usuarios verificar los detalles de la transacción. Tangem no tiene pantalla y traslada toda la interfaz a un smartphone. 

Si un celular está comprometido por malware que altera lo que se muestra en pantalla, el usuario podría autorizar una transferencia NFC maliciosa sin saberlo. ¿Cómo previene tu arquitectura la manipulación de la interfaz en un dispositivo infectado?

Una pantalla por sí sola no es un modelo de seguridad. Es solo un componente. Pero los componentes generan riesgos. Cuanto más compleja es una billetera de hardware, más superficies de ataque tiene: lógica de pantalla, botones, firmware, mecanismos de actualización, USB, Bluetooth, baterías, drivers, analizadores y conexiones físicas. 

Internet está lleno de ejemplos donde las billeteras de hardware tradicionales fueron atacadas no porque se rompiera la criptografía, sino porque la complejidad de la implementación abrió una puerta.

Tangem parte de la filosofía opuesta: hacer el dispositivo de firma lo más simple posible. Sin pantalla, sin batería, sin USB, sin Bluetooth, sin firmware actualizable, sin sistema operativo complejo. La clave privada se genera y almacena dentro del chip seguro y nunca sale de la tarjeta. Esa simplicidad es una gran ventaja en seguridad.

El celular se usa solo como interfaz, pero ahí no residen las llaves. La app de Tangem también está fuertemente protegida: 

• verificaciones de integridad en tiempo de ejecución, 
• anti-debugging,
• anti-emulación, 
• detección de root y jailbreak, 
• almacenamiento cifrado,
• comunicación segura, 
• validación de certificados, 
• protección de WebView, 
• protección contra tapjacking, 
• manejo seguro de la entrada, 

Además, sumamos permisos mínimos, revisión de código, auditorías y controles de seguridad automatizados.
 

No vemos la seguridad como "pantalla o no pantalla". La analizamos en toda la arquitectura. Tangem minimiza la superficie de ataque en hardware y refuerza la capa móvil que prepara las transacciones. Esta estrategia ofrece a los usuarios una combinación potente: un dispositivo de firma simple y aislado, y una experiencia móvil moderna y segura.

En seguridad, la complejidad suele ser el enemigo. La ventaja de Tangem es que la tarjeta hace muy poco, pero cumple una función crítica de manera excelente: proteger la clave y firmar de forma segura.

Por qué la tarjeta nunca se puede actualizar

Tu firmware está grabado de fábrica y es inmutable: no se puede actualizar por aire, eliminando el riesgo de actualizaciones maliciosas. Pero si más adelante se detecta una vulnerabilidad crítica o un fallo criptográfico en ese lote de chips, el usuario no puede actualizar. ¿Por qué un chip completamente no actualizable es más seguro para la autocustodia a largo plazo que uno actualizable?

La capacidad de actualizar no es gratis. En una billetera de hardware, el mecanismo de actualización es también un mecanismo permanente de inyección de código.

Si una billetera puede recibir nuevo firmware después de salir de fábrica, entonces el usuario debe confiar en el proveedor para siempre: sus llaves de firma, sistema de compilación, canal de lanzamiento, servidores de actualización, empleados, procesos de seguridad y decisiones futuras de negocio. Incluso si todo está bien diseñado, esa infraestructura pasa a ser parte de la base de confianza.
 

Esto crea riesgos reales: servidores de actualización comprometidos, llaves de firma filtradas, empleados maliciosos, presión regulatoria, actualizaciones accidentales defectuosas o un cambio futuro de firmware que debilite el modelo de seguridad original.

La controversia de Ledger Recover lo dejó muy claro. El propio soporte de Ledger escribió en una publicación (luego eliminada): "Técnicamente, siempre ha sido posible crear un firmware que facilite la extracción de claves. Siempre has confiado en que Ledger no desplegaría ese firmware, lo supieras o no". Esa es justamente la suposición de confianza que Tangem elimina.
 

Tangem apuesta por la inmutabilidad. Nuestro firmware se graba durante la fabricación y no puede modificarse después. No hay actualización OTA, ni flasheo por USB, ni vía inalámbrica, ni forma de que Tangem envíe nuevo código a la tarjeta una vez que está en manos del usuario.

Sí, esto significa que no podemos actualizar un chip a distancia si se descubre una vulnerabilidad a nivel hardware en el futuro. Pero un dispositivo actualizable no elimina el riesgo; crea un riesgo diferente y permanente: la posibilidad de cambiar código crítico de seguridad más adelante.

Para la autocustodia a largo plazo, creemos que la raíz de confianza más segura es la inmutable. El dispositivo no debe depender de que el fabricante siga siendo confiable para siempre. La filosofía de Tangem es simple: la tarjeta debe proteger la clave, firmar de forma segura y nunca aceptar código nuevo.
 

La dependencia de las tiendas de aplicaciones

Tangem depende de su app complementaria; existe una dependencia estructural de canales de distribución centralizados como App Store de Apple y Google Play.

 Si un actor estatal o un atacante sofisticado comprometiera sus credenciales de desarrollador y publicara una actualización maliciosa antes de que su equipo lo detecte, ¿qué mecanismos nativos dentro del elemento seguro protegen los fondos del usuario?

Para que este escenario ocurra, un atacante tendría que comprometer nuestras credenciales de desarrollador, evadir la autenticación multifactor y los controles internos de acceso, superar el proceso de aprobación de lanzamientos, inyectar código malicioso en la versión oficial, pasar la revisión de Apple o Google, mantener la identidad oficial de la app, evitar la detección de malware en la plataforma y no ser detectado por nuestro equipo, sistemas de monitoreo ni la comunidad open-source.

No se trata de una sola vulnerabilidad. Es una cadena de fallos en varias capas de seguridad independientes. Y esto es exactamente a lo que me refiero cuando digo que la seguridad debe evaluarse como un sistema completo, no mirando solo una función aislada. 

En nuestra opinión, la probabilidad de que una cadena así tenga éxito es mucho menor que los riesgos creados por una arquitectura de billetera de hardware más compleja, especialmente una que depende de actualizaciones de firmware para mantenerse segura en el tiempo.
 

Los dispositivos más complejos requieren más interfaces, más firmware, más mecanismos de actualización, más componentes y más procesos de confianza. Cada una de esas capas crea superficies de ataque adicionales: ataques a la cadena de suministro, interfaces de depuración, bugs de firmware, actualizaciones maliciosas o comprometidas, filtraciones de llaves de firma, compromiso del sistema de compilación o presión del proveedor para cambiar el comportamiento del dispositivo después del envío.
 

Si revisas la historia de ataques a billeteras de hardware, el patrón es claro. La mayoría de los problemas reales no provienen de romper la criptografía, sino de la complejidad: errores de implementación, mecanismos de actualización, interfaces físicas, comportamiento del firmware, suposiciones en la cadena de suministro o interacciones inesperadas entre componentes.

Una actualización maliciosa desde la tienda de apps es un riesgo teórico. Pero requiere una cadena de fallos independientes antes de que el atacante llegue al usuario. Un código fuente permanentemente actualizable, en cambio, mantiene abierto un canal de actualización por diseño durante toda la vida útil del producto.

Este es el núcleo del modelo de seguridad de Tangem: minimizar el número de componentes de confianza, reducir la superficie de ataque y hacer que el dispositivo de firma sea inmutable.

Respaldo sin frase semilla vs. papel

La arquitectura sin frase semilla de Tangem mantiene la seguridad clonando la clave privada en tarjetas de respaldo al configurar. Así se elimina el punto único de falla de una frase semilla escrita, pero se crea una dependencia física: si pierdes tus tarjetas de respaldo, llegas a un muro de recuperación. ¿Cómo escala este respaldo solo hardware para herencias multigeneracionales o planificación patrimonial frente a los estándares tradicionales en papel BIP-39?

Cuando las personas compran una billetera de hardware, esperan que el dispositivo proteja sus claves privadas. Pero en muchas billeteras tradicionales, el dispositivo primero muestra la frase semilla al usuario y le devuelve la responsabilidad.
 

Desde ese momento, el eslabón más débil ya no es la billetera de hardware. Es la frase semilla: un papel, una placa metálica, un cajón, una caja fuerte, una foto que nunca se debería tomar o una frase que puede perderse, dañarse, copiarse, exponerse o ser robada.
 

La pérdida de acceso a claves privadas y frases de recuperación es una de las principales causas reales de pérdida permanente de cripto. Chainalysis estima que millones de bitcoins están perdidos para siempre. Los ataques de phishing también siguen apuntando directamente a las frases semilla, porque una vez expuesta, el precio o nivel de seguridad de la billetera de hardware ya no importa.
 

En el modelo tradicional, tienes una billetera de hardware y una frase semilla. Puedes hacer más copias de la frase, pero cada una aumenta el riesgo, ya que no están protegidas por hardware. El usuario debe inventar su propio sistema de seguridad.
 

Tangem ve las cosas de manera diferente: el respaldo también debe estar protegido por hardware. Por eso, en una configuración estándar de Tangem, los usuarios reciben tres tarjetas. Cada tarjeta es una billetera de hardware completa con elemento seguro, no solo un papel sin protección.
 

Para herencias o almacenamiento a largo plazo, los usuarios pueden quedarse con una tarjeta para uso diario, guardar otra en un lugar seguro y entregar otra a un familiar de confianza, abogado o como parte de un acuerdo de herencia. Si se pierden todas las tarjetas, no hay recuperación, pero eso es verdadera autocustodia. Lo que Tangem elimina es la parte más frágil del modelo tradicional: una frase semilla expuesta.
 

Si la clave privada es lo suficientemente importante para protegerla con una billetera de hardware, su respaldo también debe estar protegido por hardware. Eso es exactamente lo que hace Tangem.

¿Puede la simulación de transacciones ser 100% confiable?

El phishing en DeFi y la firma a ciegas siguen siendo las principales formas en que los usuarios pierden fondos en billeteras. Tu app integra simulación de transacciones y detección de estafas en dApps para mostrar a los usuarios lo que ejecutará un contrato. 

Pero, dada la naturaleza Turing-completa de los contratos inteligentes complejos y de múltiples saltos, ¿puede la simulación en el dispositivo ser 100% confiable? ¿O existe el riesgo de dar a los usuarios una falsa sensación de seguridad absoluta?

Esa es una excelente pregunta porque mencionaste la frase clave "seguridad absoluta".

La respuesta honesta es no. Ninguna billetera, motor de simulación, dispositivo de hardware o empresa de seguridad puede prometer seguridad absoluta. El entorno cripto es adverso. La seguridad no es una función mágica, sino un conjunto de capas que hacen que los ataques sean más difíciles, costosos y menos escalables.
 

Y a veces el punto más débil no es donde la gente espera. Hay casos confirmados públicamente en la industria donde datos de clientes de compras de billeteras de hardware quedaron expuestos. En esos casos, el problema no era necesariamente la criptografía ni el dispositivo en sí, sino el perímetro de seguridad más amplio alrededor del usuario: phishing, ingeniería social, contactos de soporte falsos, dispositivos de reemplazo falsos o presión dirigida.
 

En el ámbito DeFi, Tangem utiliza algunas de las capas de protección más avanzadas: simulación de transacciones, análisis de riesgo de contratos inteligentes, detección de dApps maliciosas, verificación de dominios, alertas ante comportamientos sospechosos y protección contra firmas a ciegas siempre que la transacción pueda ser decodificada y analizada.
 

¿Pero puede la simulación ser 100% confiable para cualquier contrato inteligente posible? No. Contratos inteligentes complejos, rutas múltiples, cambios en el estado on-chain, frontends maliciosos, dominios de phishing e ingeniería social implican que los usuarios aún deben verificar a dónde se conectan, qué están aprobando y si confían en la dApp.
 

Por eso nunca presentamos la simulación como protección absoluta. La presentamos como una capa de seguridad adicional que mejora drásticamente la visibilidad antes de firmar. Ayuda a los usuarios a entender lo que probablemente hará una transacción, detectar estafas antes y evitar aprobaciones a ciegas.

La mentalidad correcta es esta: Tangem protege la clave con hardware, reduce la superficie de ataque con una tarjeta simple e inmutable y suma protección DeFi moderna en la app. Pero los usuarios deben seguir usando dApps de confianza, verificar dominios, evitar transacciones apresuradas o bajo presión, tener cuidado con las aprobaciones y nunca tomar ningún sistema de alerta como sustituto del sentido común.

La seguridad absoluta no existe. La seguridad sólida proviene de defensas en capas, y así es exactamente como está construido Tangem.
 

Pagar gas en stablecoins sin perder el almacenamiento en frío

Recientemente lanzaron una función que permite a los usuarios pagar las comisiones de red en stablecoins como USDT o USDC en vez del token de gas nativo. Por detrás, esto normalmente requiere relayers de abstracción de cuentas o liquidez de terceros. 

¿Estas funciones de conveniencia introducen riesgos sutiles de contraparte o dependencias centralizadas en lo que debería ser un entorno de almacenamiento en frío?
 

Tangem utiliza EIP-7702 para Smart Gas en redes EVM compatibles. Esto permite a los usuarios pagar comisiones de red en ciertos tokens ERC-20 en vez de mantener el token de gas nativo. No cambia el modelo de custodia: la clave privada permanece dentro de la tarjeta Tangem, el usuario sigue firmando con la billetera de hardware y ningún tercero accede a las llaves.
 

App open-source, silicio cerrado

Tu app complementaria es completamente open source en GitHub, lo que sigue el principio comunitario de "No confíes, verifica". Pero el elemento seguro EAL6+ dentro de las tarjetas funciona sobre una arquitectura propietaria y cerrada desarrollada por los fabricantes de chips. 

¿Cómo concilias la filosofía open-source de DeFi con una base de hardware que requiere confiar en el diseño cerrado de una fundición corporativa?
 

El open source es importante, pero decir que cada capa de un producto de hardware seguro debe ser open-source es una forma simple de identificar a quien no comprende la seguridad de hardware.
 

En un elemento seguro, el firmware cerrado de bajo nivel y los internos del chip cerrados no son un defecto. Son parte del modelo de protección. Estos chips están diseñados para resistir ataques físicos e invasivos: inyección de fallos, análisis de canal lateral, sondas, glitching, ataques láser y otras técnicas de laboratorio. Publicar información detallada sobre el comportamiento interno del firmware, la disposición de la memoria, sensores, contramedidas o lógica de detección de fallos no haría más seguros a los usuarios, sino que daría a los atacantes un mejor mapa.
 

Esto no es una ingenua "seguridad por oscuridad". La seguridad de hardware seria se basa en protección por capas: elementos seguros certificados, conjuntos de comandos limitados, auditorías independientes, firmware inmutable y superficie de ataque mínima. 

Pero también significa no exponer detalles de implementación de bajo nivel que faciliten ataques físicos.

Y seamos honestos: incluso cuando alguien afirma tener "firmware open-source", el chip seguro en sí no es completamente abierto. Contiene lógica de hardware, ROM, microcódigo, contramedidas propietarias, procesos de fabricación y mecanismos de seguridad física que los usuarios no pueden inspeccionar ni reproducir de forma realista. 

Así que pretender que un consumidor puede verificar completamente toda la raíz de confianza hardware solo porque se publica parte del firmware es engañoso.

Nuestro modelo de seguridad es "cerrar donde la divulgación ayudaría a atacantes, evaluar de forma independiente donde se requiere confianza y mantenerlo lo más minimalista posible".

Llevando el hardware al público: Tangem Ring

A medida que Tangem expande su hardware más allá de las tarjetas hacia wearables de consumo como Tangem Ring, el dispositivo pasa directamente al espacio público. ¿Qué medidas técnicas protegen al usuario frente a un adversario que use un lector NFC amplificado en un entorno lleno de gente para intentar handshakes no autorizados o ataques de fuerza bruta al código de acceso?

Primero, NFC significa comunicación de campo cercano. Está diseñado para funcionar a distancias muy cortas, así que la idea de un "lector amplificado" interactuando silenciosamente con un anillo en el dedo de alguien en un lugar concurrido no es un escenario de ataque realista en la vida diaria.

Además, hay un punto práctico: Tangem Ring está diseñado para parecerse a un wearable común, similar a anillos de pago u otros accesorios de consumo. Un atacante primero tendría que identificar que la persona lleva una billetera de hardware cripto, y no solo un anillo normal.

Pero incluso si alguien intentara interactuar con el anillo vía NFC, eso no le daría acceso a la billetera. Tangem Ring, igual que las tarjetas Tangem, está protegido por un código de acceso definido por el usuario. Sin ese código, un atacante no puede autorizar operaciones en la billetera.

La fuerza bruta tampoco es un camino viable. El dispositivo protege contra intentos repetidos de contraseña: tras intentos incorrectos, el tiempo de espera entre intentos aumenta, haciendo inviable el descifrado automatizado.

Así que el modelo de seguridad es simple: la proximidad NFC por sí sola no basta, la presencia física por sí sola no basta y adivinar el código de acceso no es un ataque realista. Los usuarios pueden llevar Tangem Ring en público con tranquilidad.

Regulación y el núcleo de autocustodia

Los reguladores globales están intensificando los marcos sobre "billeteras no alojadas" y el control obligatorio de destinos de transacciones. Como CTO, ¿estás diseñando la infraestructura para resistir posibles demandas futuras de cumplimiento integrado o KYC dentro de apps de autocustodia, o el software está construido para ser completamente inmodificable sin importar los cambios regulatorios?
 

Primero, es importante separar la arquitectura del dispositivo de la capa regulatoria.

En Tangem, la clave privada se genera y almacena dentro de la tarjeta. La tarjeta no sabe qué es KYC, no depende de un servidor de cumplimiento y no pide permiso a Tangem para firmar una transacción. Simplemente protege la clave y firma cuando el usuario lo autoriza.
 

El usuario puede interactuar con la tarjeta mediante la app oficial de Tangem, o técnicamente a través de herramientas y SDKs open-source. Eso significa que Tangem no puede congelar la tarjeta a distancia, extraer la clave ni impedir que el usuario acceda a sus fondos a nivel hardware.
 

Ahora, respecto a la regulación, creo que es importante ser realistas. Forzar a las billeteras de autocustodia a integrar mecanismos de control directamente en la capa de firma sería la herramienta equivocada. Hay muchas billeteras gratuitas, open-source, forks y soluciones underground. Si los reguladores alejan a los usuarios de productos auditados y seguros, muchos simplemente migrarán a alternativas menos transparentes y menos seguras. Eso aumentaría las pérdidas, estafas y actividad en la sombra, no las reduciría.
 

Lo que ya vemos a nivel global es una tendencia distinta: los reguladores se enfocan en los puntos donde el cripto toca servicios regulados; exchanges, on-ramps, off-ramps, productos de pago e intermediarios financieros. Ahí es donde suelen aplicar KYC, AML, controles de sanciones y obligaciones de reporte.
 

Si ciertas jurisdicciones requieren flujos de cumplimiento legal para servicios específicos, Tangem puede ayudar a los usuarios a mantenerse en regla al usar esos servicios. Pero eso es muy distinto a decir que la billetera de hardware en sí deba convertirse en un dispositivo con permisos.
 

Nuestra posición es simple: Tangem puede facilitar el acceso regulado a servicios, pero el núcleo de autocustodia debe seguir siendo autocustodia. La tarjeta protege la clave. El usuario controla los fondos. Tangem no posee los activos, no controla la clave privada y no tiene un interruptor remoto para decidir si el usuario puede firmar.
 

La cuestión cuántica

La gran mayoría de las billeteras de hardware, incluida Tangem, depende de la criptografía de curva elíptica estándar ECDSA o Ed25519. Con el avance de la computación cuántica, ¿qué tan vulnerable es el silicio con firmware fijo ante una eventual decriptación cuántica, y cuál es la hoja de ruta para migrar las tarjetas físicas existentes a criptografía post-cuántica?
 

La transición a criptografía post-cuántica debe comenzar a nivel de protocolo blockchain.

Las billeteras de hardware no definen qué algoritmos de firma aceptan Bitcoin, Ethereum, Solana u otras redes. Primero, las blockchains deben adoptar estándares criptográficos resistentes a la computación cuántica. Solo después de eso estos algoritmos podrán implementarse en billeteras, elementos seguros y dispositivos de firma.
 

Hoy no existe un camino universalmente aceptado ni un solo algoritmo post-cuántico adoptado por las principales blockchains para la firma de transacciones cotidianas. La industria sigue investigando, probando y debatiendo el enfoque correcto.
 

Tangem trabaja activamente en esta dirección, pero el desafío es mucho mayor que solo las billeteras de hardware. La misma transición impactará tarjetas bancarias, SIM, elementos seguros, documentos de identidad, dispositivos IoT y muchos otros sistemas críticos de seguridad.

En los próximos años, esperamos una fuerte aceleración en la criptografía post-cuántica, soporte de chips seguros y estándares a nivel blockchain. Cuando las redes estén listas para soportar estos algoritmos, Tangem evolucionará junto a ellas.

El punto clave es simple: la migración post-cuántica es una transición a nivel ecosistema; primero blockchains, luego billeteras de hardware.

El hilo conductor en cada respuesta es el mismo argumento que Tangem sostiene desde el primer día: la seguridad es una propiedad de todo el sistema, no de una sola función. Menos piezas móviles, menos cosas en las que confiar, menos puntos de falla y un trabajo crítico hecho de forma excelente.