Introducción

Las wallets hardware como TREZOR ONE están diseñadas para proteger las claves incluso si alguien obtiene acceso físico al dispositivo. Aun así, en escenarios legítimos (pérdida de PIN, herencias digitales, peritajes o auditorías) es habitual preguntarse qué ocurre “por dentro” y por qué la recuperación del acceso es un proceso complejo.

Tratamos estos casos con un enfoque forense y legal, documentando cadena de custodia y valorando la viabilidad caso por caso, sin promesas irreales.

Montaje experimental

Mostramos un ejemplo del banco de pruebas utilizado en investigaciones de seguridad sobre TREZOR ONE:

  • Un multiplexor analógico para provocar variaciones de señal.
  • Un zócalo LQFP64 para el microcontrolador STM32.
  • Un adaptador USB‑UART FT232H para comunicación con el cargador interno.
  • Una placa FPGA Digilent Arty A7 utilizada para generar señales temporizadas.

Este tipo de instrumental no está al alcance del usuario medio y requiere formación en electrónica, microcontroladores y análisis de fallos físicos.

Niveles de protección (RDP) y Funcionamiento de la Memoria

El microcontrolador utilizado en TREZOR One implementa un sistema de seguridad basado en Readout Protection (RDP), un mecanismo diseñado para impedir la lectura directa de la memoria interna cuando el dispositivo cae en manos no autorizadas.

Este sistema se divide en tres niveles:

  • RDP nivel 2 (por defecto en TREZOR)
    Es el estado más restrictivo. En este modo no se permite leer ni la SRAM ni la memoria FLASH mediante interfaces de depuración o programación. Está pensado para proteger completamente los secretos criptográficos del dispositivo frente a ataques físicos.
  • RDP nivel 1
    En este nivel intermedio se autoriza el acceso a la memoria SRAM, pero la FLASH —donde se almacenan los datos críticos— continúa protegida.
  • RDP nivel 0
    Es el modo sin protección: permite leer tanto la SRAM como la FLASH desde interfaces de depuración como JTAG, SWD o UART.

Desde el punto de vista forense, esta jerarquía es fundamental porque las claves que permiten reconstruir el acceso al monedero se encuentran almacenadas en la FLASH, la única memoria no volátil del dispositivo.

Esto significa que, mientras el chip permanezca en RDP 2 o incluso en RDP 1, la información más sensible sigue inaccesible por métodos convencionales. Cualquier intento de recuperación avanzada pasa necesariamente por comprender cómo se comporta el microcontrolador durante el arranque y cómo aplica estos niveles de protección.

Esta arquitectura es precisamente lo que convierte a las hardware wallets en dispositivos muy resistentes frente a accesos no autorizados… y también lo que hace que los procesos de recuperación legítima sean extraordinariamente complejos y reservados a laboratorios especializados.

Secuencia de arranque: tres fases críticas

Para comprender por qué un dispositivo como TREZOR resulta tan difícil de analizar físicamente, es imprescindible entender su cadena de arranque (boot chain). Cada fase se ejecuta de forma estrictamente controlada y activa distintos mecanismos de seguridad.

1️⃣ BootROM: el primer código que se ejecuta

Nada más aplicar alimentación al dispositivo, el microcontrolador ejecuta el BootROM, un código almacenado en memoria ROM interna e inalterable.

Sus funciones principales son:

  • inicializar componentes básicos del chip,
  • leer los parámetros de configuración de seguridad,
  • aplicar los niveles de protección configurados,
  • y verificar la integridad del sistema antes de permitir que continúe la ejecución.

Esta etapa es crítica porque es aquí donde se evalúan opciones como el nivel RDP y otros bits de protección grabados en áreas especiales de la FLASH.

2️⃣ BootLoader: decisión entre firmware o modo de depuración

Si el arranque continúa sin errores, el siguiente bloque en ejecutarse es el BootLoader.

Este componente decide si:

  • cargar el firmware principal desde la FLASH,
  • o entrar en un modo especial de depuración a la espera de órdenes externas desde un host.

Sin embargo, en condiciones normales este modo de depuración está bloqueado cuando el dispositivo se encuentra en RDP nivel 2, que es la configuración por defecto en TREZOR.

Por ello, el flujo habitual consiste en:

  • comprobar nuevamente la integridad del sistema,
  • y, si todo es correcto, arrancar directamente el firmware de usuario desde la memoria FLASH.

3️⃣ Firmware: la aplicación del usuario

La última fase del arranque es la ejecución del firmware residente en la FLASH.

Se trata del software visible para el usuario final:

  • la interfaz gráfica,
  • la gestión del PIN,
  • las operaciones de firma de transacciones,
  • y la interacción con el ordenador o el móvil.

Es precisamente en esta capa donde se aplican las protecciones frente a intentos repetidos de acceso, borrados automáticos y demás mecanismos de defensa diseñados para evitar ataques por fuerza bruta desde el exterior.

Esta cadena de arranque escalonada es uno de los pilares de la seguridad de TREZOR: cada fase hereda las restricciones de la anterior y solo permite avanzar si las comprobaciones se superan correctamente.

El papel crítico del BootROM y la investigación mediante fault injection

Dentro de la cadena de arranque del TREZOR One, el BootROM es la fase más sensible desde el punto de vista de la seguridad… y también la más interesante para investigadores y laboratorios forenses.

Durante su ejecución inicial, este código inmutable:

  • lee los parámetros de configuración de seguridad del microcontrolador,
  • consulta una región especial de la FLASH conocida como Option Bytes,
  • y aplica las políticas de protección establecidas antes de permitir que continúe el arranque.

Entre esos parámetros, el más relevante es el Readout Protection (RDP).

En los dispositivos TREZOR este valor se encuentra configurado por defecto en nivel 2, el estado más restrictivo. Una vez fijado oficialmente en ese nivel, el fabricante del microcontrolador no contempla mecanismos estándar para reducirlo a RDP 1 o RDP 0, lo que impide el acceso normal a interfaces de depuración y a la memoria interna.

Sin embargo, desde el ámbito académico y de investigación en hardware security se ha demostrado que, bajo condiciones muy concretas de laboratorio, es posible intentar alterar momentáneamente la lectura de estos parámetros durante el arranque mediante técnicas conocidas como fault injection.

Interfaces de depuración y comandos utilizados en laboratorio

Cuando, en un entorno controlado, se consigue que el microcontrolador arranque temporalmente en un nivel de protección inferior al previsto, el BootLoader habilita determinadas interfaces de servicio como UART, JTAG o SWD.

Estas interfaces están pensadas originalmente para fabricación y diagnóstico, pero en investigación de seguridad permiten interactuar con el chip a bajo nivel.

En el caso analizado, la comunicación se establece habitualmente por UART, ya que ofrece una sincronización suficientemente precisa para coordinar perturbaciones temporales durante la ejecución del firmware interno.

Lectura de memoria y control dinámico del RDP

Entre los comandos disponibles en ese modo restringido destaca uno destinado a lectura de memoria, conocido internamente como Read Memory.

Este comando verifica en cada invocación el nivel actual de protección RDP antes de permitir el acceso a una región concreta del mapa de memoria.

Aquí entra en juego un segundo momento crítico: mediante una nueva perturbación temporal durante esa comprobación, algunos estudios han demostrado que es posible inducir al sistema a comportarse como si se encontrara en un nivel inferior de protección, permitiendo así la lectura de regiones normalmente inaccesibles, como la memoria FLASH.

Si la perturbación no se produce en el instante adecuado, el sistema responde con un mensaje de error (NACK), indicando que la operación no está autorizada.
Cuando la sincronización es correcta, el comando devuelve una confirmación (ACK) y entrega el bloque solicitado.

Desde un punto de vista forense, uno de los mayores retos consiste precisamente en calcular y repetir de forma fiable ese intervalo temporal, midiendo cuánto tarda el microcontrolador en responder ante un intento fallido y ajustando la inyección de fallos hasta encontrar la ventana válida.

Volcado progresivo de la memoria FLASH

Las lecturas se realizan en bloques pequeños —habitualmente del orden de cientos de bytes—, por lo que el proceso completo implica repetir el ciclo miles de veces hasta reconstruir todo el contenido de la FLASH.

En términos conceptuales, el flujo de trabajo en laboratorio consiste en:

  • inducir el estado de protección reducido durante el arranque,
  • solicitar la lectura de una dirección concreta,
  • provocar la perturbación en la comprobación del nivel RDP,
  • almacenar el bloque recuperado,
  • avanzar a la siguiente región de memoria,
  • y reiniciar el proceso si alguna de las fases falla.

Dada la complejidad y la necesidad de precisión en microsegundos, este tipo de tareas suele apoyarse en automatización mediante scripts y hardware externo especializado, capaces de reiniciar el dispositivo, disparar los pulsos eléctricos y coordinar las lecturas de forma repetitiva.

Esta etapa es una de las más delicadas de todo el proceso: cualquier desviación en la temporización hace que el microcontrolador vuelva a su estado protegido y obligue a comenzar de nuevo.Es importante destacar que este script de automatización no es público: suele ser una herramienta interna del laboratorio, ajustada a su instrumentación, a su metodología de pruebas y a sus controles de trazabilidad. En un contexto pericial, además, forma parte del know-how y de la cadena de custodia del proceso.

Lectura de OTP y obtención del hardware salt

Además del volcado de la memoria no volátil principal, el análisis requiere extraer y procesar también la región OTP (One-Time Programmable) del microcontrolador. Esta zona contiene valores únicos grabados en fábrica y es donde se encuentra el material necesario para reconstruir el hardware salt, que actúa como componente esencial en la derivación de claves internas.

En términos técnicos:

  • La hardware salt ocupa 44 bytes.
  • Normalmente se localiza dentro de los primeros 64 bytes del área OTP.
  • El tamaño total de OTP puede alcanzar hasta 528 bytes, dependiendo del microcontrolador y su configuración.

Una vez extraído el contenido OTP, el laboratorio calcula un hash criptográfico (por ejemplo, SHA-256) y lo combina con el salt dinámico recuperado desde la FLASH para construir el salt ensamblado, que se utiliza en las fases posteriores de verificación criptográfica.

Como se realiza el proceso de Fuerza Bruta Controlada.

El trezor internamente usa una combinación de llaves y claves, que aplicando distintos algoritmos de cifrado se descifran entre si  y ese resultado final comprueba si el PIN introducido es el correcto.

Trezor organiza su almacenamiento en “entries”, la entrie en la FLASH que guarda lo que necesitamos se encuentra con el “app-value” de 0 y el “key-value” de 2. Se puede localizar esta entrada ya que siempre comienza con los bytes “02 00 3C 00”. Esa entrada en total son 64 bytes. La idea es ir recorriendo todo el dumpeo de la flash hasta encontrar esa entrada comparando si los bytes son “02 00 3C 00”.

Una vez hemos localizado esa entrada, en su interior se encuentra:
-Salt (aleatoria cada booteo), primeros 4 bytes.
-EDEK (Encrypted Data Encrypted KEY) + ESAK (Encrypted Storage Authentication Key), siguientes 48 bytes.
-PVC (PIN Verification Code), últimos 8 bytes.

El siguiente paso es obtener la hardware salt real, eso se consigue aplicándole SHA256 a los bytes OTP que hemos leído anteriormente.

Para obtener la Assembled salt, que es la que usaremos para derivar las demás claves, le sumamos la Hardware Salt a la salt de la Flash.

Assembled salt = Hardware salt (SHA256(OTP)) + salt (FLASH).

A partir de ahora cada vez que me refiera a la salt, en realidad me refiero a la Assembled salt.

Lo siguiente sería añadirle un prefijo de “1” al PIN para hacerlo little endian, por ejemplo si el PIN es “7408” le añadimos un prefijo de “1” → “17408”, a este PIN lo llamaremos PIN-bytes.

Después obtenemos la DK, para ello aplicamos el algoritmo pbkdf2_hmac, con SHA256, a los PIN-Bytes y la salt.

Ahora tenemos que obtener el KEK y el KEIV.
El KEK son los primero 32 bytes de dk y el KEIV son los siguientes 12 bytes a partir de esos 32.

Solo faltaría obtener el DEK, para ello tenemos que descifrar el EDEK usando el KEK y el KEIV.
Aplicamos el algoritmo ChaCha20_Poly1305 al EDEK usando la key KEK y el nonce KEIV.

Por último comprobamos si todos los bytes del PVC está en orden en los bytes del TAG, de ser así, el pin que hemos probado sería correcto:

Una vez entendido el flujo de verificación, el enfoque en laboratorio consiste en probar de forma sistemática todas las combinaciones posibles dentro del espacio de búsqueda definido. Por ejemplo, si el PIN es numérico de 4 dígitos, el conjunto potencial abarca desde 0000 hasta 9999.

Para cada candidato, se reproduce offline la misma cadena criptográfica (derivación de claves + comprobación del valor de verificación) y se marca como válido únicamente aquel que supera la verificación interna. De esta forma, la comprobación se realiza sobre los datos extraídos, sin interactuar con el dispositivo en modo usuario y sin depender de límites de intentos del firmware.

Esto significa que la verificación del PIN se basa en procesos criptográficos, no en una comparación simple tipo “PIN correcto/incorrecto” guardado en memoria.

Fuerza bruta: el mito del “PIN de 4 dígitos”

Aunque un PIN parezca “corto”, el sistema está diseñado para que probarlo de forma masiva no sea inmediato, porque:

  • hay pasos de derivación que consumen recursos,
  • intervienen valores internos ligados al dispositivo,
  • y la validación final depende de verificaciones criptográficas.

Por eso, incluso con acceso a ciertos datos, hablar de “probar 0000–9999” como si fuese trivial suele ser una simplificación que no refleja la realidad de laboratorio.

Expectativas realistas y recomendaciones

  • ✅ La frase semilla (seed phrase) sigue siendo el mecanismo estándar y recomendado para recuperar fondos.
  • ❌ No existe un método universal, rápido y garantizado para “sacar el PIN” de una TREZOR.
  • ⚠️ La manipulación física avanzada implica riesgo real de pérdida total del dispositivo.

¿Has perdido el acceso a una wallet TREZOR?

Realizamos evaluaciones de viabilidad con enfoque forense:

  • autorización y documentación,
  • análisis técnico realista,
  • confidencialidad y trazabilidad.

👉 Solicita una evaluación inicial y te diremos qué opciones existen en tu caso concreto.