Recuperación de billeteras bajo autoridad 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 autoridad lo permite, en fondos protegidos por la agencia. 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 autoridad legal: las normas aplicables, 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 aspectos. La autoridad abarca el examen del material de claves y, si se prevé, el traslado de los fondos. El plan indica quién realiza la recuperación, quién la presencia bajo control dual y adónde se enviarán los fondos protegidos (véase la lección Protección 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, para que cada derivación, análisis y decisión se registre en el momento en que ocurre.

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 traslade primero los fondos.

De la frase mnemotécnica a las direcciones

La mayoría de las billeteras modernas siguen tres propuestas de mejora de Bitcoin, que muchas otras cadenas también utilizan.

BIP-39 convierte la entropía en palabras. A la entropía de 128 a 256 bits, en incrementos de 32, se le añade una suma de verificació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 indexa una palabra de una lista de 2.048 palabras, lo que da como resultado 12, 15, 18, 21 o 24 palabras. Luego, la frase, normalizada a Unicode NFKD, se transforma mediante PBKDF2 en una semilla de 512 bits, usando 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 mediante HMAC-SHA512 con "Bitcoin seed" como clave. Las claves secundarias pueden ser normales o endurecidas (índice 2^31 o superior, indicado con un apóstrofo o h). Una clave pública extendida permite a cualquiera derivar las claves públicas secundarias normales, lo que hace posibles las billeteras de solo lectura; BIP-32 también advierte que una clave pública extendida combinada con cualquier clave privada secundaria no endurecida revela la clave privada principal, por lo que los examinadores tratan las xpub como información confidencial.

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 (de recepción) y 1 para la cadena interna (de cambio). Los tipos de moneda están registrados 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. Las propuestas posteriores reutilizan la estructura con un número de propósito distinto 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 que una billetera está «vacía» cuando 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 una negación plausible. No hay ningún mensaje de error cuando la frase de contraseña es incorrecta: solo se obtiene una billetera distinta, normalmente vacía. Por lo tanto, un usuario puede mantener un pequeño saldo señuelo sin frase de contraseña y los fondos reales bajo una frase 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 los materiales del caso una frase de contraseña almacenada aparte de las palabras y preguntar al respecto conforme a las normas analizadas en la lección Registro e incautación de criptomonedas en el lugar de los hechos forman 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. Preparación. Se prepara un dispositivo dedicado para el examinador, recién instalado y que nunca haya contenido claves de otros casos, con la conexión de red desactivada. Se utiliza software de billetera o de derivación de código abierto cuya versión se verifique con el hash publicado, y se registran el nombre, la versión y el hash.
2. Comprobación de la frase. La suma de verificació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 la original bajo control dual. En una frase de 12 palabras, aproximadamente 1 de cada 16 secuencias aleatorias de palabras supera la suma de verificación, por lo que una suma válida respalda, pero no demuestra, que la transcripción sea correcta.
3. Derivación sin conexión de las claves públicas extendidas y las direcciones para todos los propósitos, cuentas y cadenas plausibles, con exportación únicamente de material público.
4. Comprobación de actividad en modo de solo lectura, preferiblemente mediante los propios nodos de la unidad. Consultar servidores de terceros revela las direcciones y la identidad de red de la unidad, lo que puede poner en riesgo la confidencialidad y, a través del operador del servidor, alertar a otras personas. Se analizan al menos 20 direcciones sin uso, hasta alcanzar el límite de brecha de BIP-44, y más cuando se sabe que el software de la billetera utiliza brechas mayores.
5. Protección de los fondos conforme al plan, trasladándolos a la billetera controlada por la agencia mediante control dual y una transacción de prueba. Nunca se deben enviar fondos de vuelta a través del dispositivo o el software del 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 usar una suma de verificación de BIP-39; las billeteras heredadas de Monero utilizan 25 palabras; las participaciones de Shamir de SLIP-39 requieren un número umbral de participaciones. Primero se identifica el estándar y luego se elige el software que lo implementa.

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

{
  "case": "CASE-0417",
  "recovery_id": "REC-002",
  "source_item": "CASE-0417-I-012 (placa metálica, sello TE-88213 abierto 2026-03-16T10:05Z)",
  "operator": "Examinador 2", "witness": "Examinador 4",
  "environment": "Dispositivo del examinador EX-07, sin conexión, 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 verificación válida",
  "passphrase": "vacía (no se encontró ninguna frase de contraseña en los materiales 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 de 4.21907 BTC en el bloque 940112",
  "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 sellado y con la hora en que se abrió el sello, identifica al operador y al testigo, especifica el entorno y el software verificado, indica el estándar, el supuesto sobre la frase de contraseña y cada ruta analizada, 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 el material de claves con una clave derivada de una contraseña del usuario. Si se desconoce la contraseña, la recuperación depende de encontrarla o recuperarla. En términos generales, la recuperación de contraseñas en laboratorios forenses utiliza contraseñas candidatas basadas en información del caso: contraseñas encontradas en otros dispositivos incautados, en administradores de contraseñas o en notas, proporcionadas durante entrevistas o deducidas a partir de patrones conocidos del usuario. Las herramientas validadas prueban las candidatas contra una copia del archivo de billetera, nunca contra el original. La configuración de derivación de claves de la billetera determina cuánto cuesta probar cada intento, por lo que el éxito nunca está garantizado; el esfuerzo, los datos de entrada y los resultados se registran como cualquier otro paso del examen. La autoridad para realizar este trabajo debe ser explícita.

Las billeteras de hardware son un caso distinto. Sus sistemas de protección mediante PIN y de borrado tras fallos hacen que la recuperación normalmente se realice mediante la copia de respaldo de la semilla, no desde el dispositivo. Los ataques físicos al hardware del dispositivo son una actividad especializada y específica de cada modelo, fuera del alcance de este curso.

Multisig, 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 cosignatario y la configuración exacta del script, que normalmente se registra como un descriptor de salida (la familia BIP-380). Una sola semilla de una billetera 2 de 3 no permite gastar por sí sola; el examinador debe buscar la configuración de la billetera o su archivo de respaldo, así como a los demás cosignatarios. Una billetera MPC o de umbral nunca forma una clave completa: las participaciones se encuentran en el dispositivo del usuario y con un proveedor u otra parte, por lo que una sola participación no basta y la recuperación suele realizarse mediante el proceso de recuperación propio del proveedor o un proceso legal dirigido a este (véase la lección 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 cuanto los fondos lleguen a un servicio (véase la lección Opciones de congelamiento e incautación).

Enfoque del examen: los cuatro requisitos previos para la recuperación (autoridad, plan, entorno aislado y registro); los parámetros de BIP-39 (de 128 a 256 bits, suma de verificación de ENT/32 bits, 2.048 palabras, PBKDF2-HMAC-SHA512 con 2.048 iteraciones y la sal "mnemonic" más la frase de contraseña, semilla de 512 bits); las claves endurecidas de BIP-32, las xpub de solo lectura y el riesgo de combinar una xpub con una clave privada secundaria; los niveles de ruta de BIP-44, los valores de cambio, los tipos de moneda SLIP-0044, el límite de brecha 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 da como resultado una billetera válida y vacía, y cómo expresar ese límite; la derivación sin conexión, las comprobaciones en modo de solo lectura mediante los propios nodos y los formatos que no son BIP-39; la recuperación de contraseñas en términos generales y la recuperación de billeteras de hardware mediante la semilla; los requisitos de multisig y MPC, y los próximos pasos cuando falla la recuperación.