Recuperación de billeteras bajo autorización legal

Encontrar una frase semilla o un archivo de billetera no equivale a saber qué controla. La recuperación es el paso que convierte el material de claves en una lista documentada de direcciones, saldos e historial y, cuando la autorización lo permite, en fondos asegurados por el organismo. También es el paso en el que un examinador descuidado puede perder fondos, alertar a un sospechoso o producir un resultado que no se pueda repetir. Esta lección aborda la recuperación como un procedimiento forense realizado bajo autorización legal: los estándares implicados, el entorno, los límites y el registro que permite defender el resultado.

La recuperación como procedimiento forense

La recuperación solo debe comenzar cuando se hayan resuelto cuatro cuestiones. La autorización abarca el examen del material de claves y, si se prevé hacerlo, el movimiento de los fondos. El plan establece quién realiza la recuperación, quién actúa como testigo bajo control dual y adónde irán los fondos asegurados (véase la lección Aseguramiento de criptoactivos incautados). El entorno es un dispositivo aislado del examinador preparado para ese fin. Y el registro se abre antes de la primera acción, de modo que cada derivación, exploración y decisión quede registrada a medida que se realiza.

El objetivo es doble: establecer qué controla el material de claves, como evidencia, y eliminar el riesgo de que otra persona con una copia de las mismas claves mueva los fondos primero.

De la frase mnemónica a las direcciones

La mayoría de las billeteras modernas siguen tres propuestas de mejora de Bitcoin, que muchas otras cadenas reutilizan.

BIP-39 convierte la entropía en palabras. A una entropía de 128 a 256 bits, en incrementos de 32, se le añade una suma de comprobación de un bit por cada 32 bits de entropía, tomada de su hash SHA-256. Los bits combinados se dividen en grupos de 11 bits, cada uno de los cuales indica una palabra de una lista de 2.048 palabras, lo que da como resultado 12, 15, 18, 21 o 24 palabras. La frase, normalizada a Unicode NFKD, se transforma después mediante un proceso de estiramiento en una semilla de 512 bits con PBKDF2, utilizando HMAC-SHA512 y 2.048 iteraciones; la sal es la cadena "mnemonic" seguida de la frase de contraseña opcional.

BIP-32 deriva un árbol de claves a partir de esa semilla. La clave maestra se obtiene de HMAC-SHA512 utilizando "Bitcoin seed" como clave. Las claves hijas son normales o endurecidas (índice 2^31 o superior, escrito con un apóstrofo o h). Una clave pública extendida permite a cualquiera derivar las claves públicas hijas normales, lo que hace posibles las billeteras de solo observación; BIP-32 también advierte que una clave pública extendida combinada con cualquier clave privada hija no endurecida revela la clave privada de la que deriva, por lo que los examinadores tratan las xpub como información sensible.

BIP-44 fija la estructura del árbol: m / purpose' / coin_type' / account' / change / address_index. Los tres primeros niveles son endurecidos. El valor de cambio es 0 para la cadena externa (recepción) y 1 para la cadena interna (cambio). Los tipos de moneda se registran en SLIP-0044, por ejemplo, 0 para Bitcoin, 1 para todas las redes de prueba, 2 para Litecoin, 60 para Ether y 195 para Tron. Propuestas posteriores reutilizan la estructura con un número de propósito diferente para cada tipo de script:

La consecuencia forense es que una sola frase puede controlar fondos bajo varios propósitos, varias cuentas y varias cadenas a la vez. Las billeteras de Ethereum también difieren: algunas incrementan el índice de dirección (m/44'/60'/0'/0/n), mientras que otras incrementan la cuenta (m/44'/60'/n'/0/0). Una recuperación que compruebe una sola ruta puede informar de una billetera "vacía" que no lo está.

El problema de la frase de contraseña

La frase de contraseña de BIP-39 es el límite más importante de cualquier afirmación. Todas las frases de contraseña, incluida la vacía, producen una semilla válida y una billetera válida; BIP-39 presenta esto como negación plausible. No aparece ningún mensaje de error cuando la frase de contraseña es incorrecta, sino únicamente una billetera diferente, normalmente vacía. Por tanto, un usuario puede mantener un pequeño saldo señuelo sin frase de contraseña y los fondos reales bajo una secreta.

El examinador no puede demostrar que no exista una frase de contraseña. El hallazgo debe expresarse con precisión: "con una frase de contraseña vacía, las billeteras derivadas no mostraron actividad en las rutas y cadenas enumeradas", no "la billetera está vacía". Buscar en el material del caso una frase de contraseña almacenada por separado de las palabras, y preguntar por ella conforme a las reglas tratadas en la lección Registro e incautación de criptoactivos en el lugar de los hechos, forma parte del plan de recuperación.

Restauración en un dispositivo aislado del examinador

La secuencia general es la misma, independientemente del software utilizado:

1. Preparar un dispositivo dedicado del examinador, con el sistema recién instalado, que nunca haya contenido claves de otros casos y con la conexión de red deshabilitada. Utilizar software de billetera o de derivación de código abierto cuya versión se haya verificado frente a su hash publicado, y registrar el nombre, la versión y el hash.
2. Comprobar la frase. La suma de comprobación de BIP-39 detecta la mayoría de los errores de transcripción; una frase no válida se vuelve a examinar comparándola con el original bajo control dual. Para una frase de 12 palabras, aproximadamente una de cada 16 secuencias aleatorias de palabras supera la comprobación, por lo que una suma de comprobación válida respalda, pero no demuestra, que la transcripción sea correcta.
3. Derivar sin conexión las claves públicas extendidas y las direcciones para cada propósito, cuenta y cadena plausibles, y exportar únicamente material público.
4. Comprobar la actividad en modo de solo observación, preferiblemente consultando los nodos propios de la unidad. Consultar servidores de terceros revela las direcciones y la identidad de red de la unidad, lo que puede comprometer la confidencialidad y, a través de un operador del servidor, alertar a otras personas. Explorar al menos hasta el límite de separación de BIP-44 de 20 direcciones sin usar, y más allá cuando se sepa que el software de billetera utiliza separaciones mayores.
5. Asegurar los fondos conforme al plan, trasladándolos a la billetera controlada por el organismo con control dual y una transacción de prueba. Nunca enviar fondos de vuelta a través del dispositivo o software del propio sospechoso.

No todas las frases son BIP-39. Las semillas de Electrum codifican un número de versión en un hash de la frase en lugar de una suma de comprobación BIP-39; las billeteras antiguas de Monero utilizan 25 palabras; las partes de Shamir de SLIP-39 necesitan un número de partes que alcance el umbral. Identificar primero el estándar y después elegir un software que lo implemente.

El registro de recuperación recoge cada ejecución:

{
  "case": "CASE-0417",
  "recovery_id": "REC-002",
  "source_item": "CASE-0417-I-012 (placa metálica, precinto TE-88213 abierto 2026-03-16T10:05Z)",
  "operator": "Examinador 2", "witness": "Examinador 4",
  "environment": "Dispositivo del examinador EX-07, sin conexión, sistema reinstalado 2026-03-15",
  "software": "herramienta de derivación de código abierto v4.2.1, SHA-256 de la versión 9d0c…41ee",
  "phrase_standard": "BIP-39, 24 palabras, suma de comprobación válida",
  "passphrase": "vacía (no se encontró ninguna frase de contraseña en el material del caso)",
  "paths_scanned": ["m/44'/0'/0'", "m/49'/0'/0'", "m/84'/0'/0'..m/84'/0'/2'", "m/86'/0'/0'", "m/44'/60'/0'/0/0..19"],
  "gap_limit_used": 50,
  "activity_found": "m/84'/0'/0': 31 direcciones utilizadas, saldo 4.21907 BTC en el bloque 940912",
  "public_material_exported": "lista de xpub, SHA-256 b77a…0c3e",
  "funds_action": "Transferidos conforme a la orden OR-2026-118; véase el registro de transferencia TR-004"
}

El registro vincula la ejecución con el elemento de origen precintado y con el momento en que se abrió el precinto, identifica al operador y al testigo, identifica el entorno y el software verificado, indica el estándar, el supuesto sobre la frase de contraseña y cada ruta explorada, y presenta el resultado con una altura de bloque para que cualquiera pueda volver a comprobar el saldo más adelante.

Archivos de billetera cifrados y recuperación de contraseñas

Los archivos de billetera en computadoras y teléfonos suelen cifrar su material de claves con una clave derivada de una contraseña de usuario. Si la contraseña se desconoce, la recuperación depende de encontrarla o recuperarla. En términos generales, la recuperación de contraseñas en los laboratorios forenses utiliza contraseñas candidatas elaboradas a partir de la información del caso: contraseñas encontradas en otros lugares de los dispositivos incautados, en gestores de contraseñas o notas, proporcionadas durante entrevistas o que siguen los patrones conocidos del usuario. Las herramientas validadas prueban las candidatas en una copia del archivo de billetera, nunca en el original. Los parámetros de derivación de claves de la billetera determinan el costo de cada intento, por lo que el éxito nunca está garantizado, y el esfuerzo, los datos de entrada y los resultados se registran como en cualquier otro paso del examen. La autorización para este trabajo debe ser explícita.

Las billeteras de hardware son un caso diferente. Su protección mediante PIN y sus diseños de borrado tras intentos fallidos hacen que la recuperación normalmente se realice mediante la copia de seguridad de la semilla, no a través del dispositivo. Los ataques físicos al hardware del dispositivo son una actividad especializada y específica de cada modelo que queda fuera del alcance de este curso.

Multifirma, MPC y cuándo no es posible la recuperación

Una billetera multifirma necesita M de N claves para gastar, pero recuperarla también requiere la clave pública extendida de cada cofirmante y la configuración exacta del script, normalmente registrada como un descriptor de salida (la familia BIP-380). Una sola semilla de una billetera de 2 de 3 no permite por sí sola disponer de ningún fondo; el examinador debe buscar la configuración o el archivo de copia de seguridad de la billetera y a los demás cofirmantes. Una billetera MPC o de umbral nunca forma una clave completa: las partes se encuentran en el dispositivo del usuario y en manos de un proveedor u otra parte, por lo que una sola parte no basta y la recuperación suele realizarse mediante el proceso de recuperación del propio proveedor o mediante un procedimiento legal dirigido a este (véase la lección de IDFE-DA Tecnologías de gestión de claves).

Cuando la recuperación falla, el trabajo no se desperdicia. El material público sigue permitiendo atribuir direcciones, respalda el rastreo y permite solicitar el congelamiento en el momento en que los fondos lleguen a un servicio (véase la lección Opciones de congelamiento e incautación).

Enfoque del examen: las cuatro condiciones previas para la recuperación (autorización, plan, entorno aislado, registro); parámetros de BIP-39 (128 a 256 bits, suma de comprobación de ENT/32 bits, 2.048 palabras, PBKDF2-HMAC-SHA512 con 2.048 iteraciones y sal "mnemonic" más la frase de contraseña, semilla de 512 bits); claves endurecidas de BIP-32, xpub de solo observación y el riesgo de combinar una xpub con una clave privada hija; niveles de ruta de BIP-44, valores de cambio, tipos de moneda de SLIP-0044, el límite de separación de 20 y los propósitos 44, 49, 84 y 86 con sus tipos de dirección; por qué una frase de contraseña incorrecta genera una billetera vacía válida y cómo expresar ese límite; derivación sin conexión, comprobaciones de solo observación mediante nodos propios y formatos distintos de BIP-39; recuperación de contraseñas en términos generales y recuperación de billeteras de hardware mediante la semilla; requisitos de multifirma y MPC y siguientes pasos cuando la recuperación falla.