Wallets calientes vs frías: cómo la custodia de claves cambia tu modelo de amenazas

La respuesta directa: el límite de firma, no la categoría del dispositivo

Una wallet caliente de criptomonedas se diferencia de una fría por dónde existe la clave privada cuando se crea una firma. En una wallet caliente, la clave se carga en software que se ejecuta en un dispositivo conectado a Internet, por lo que cualquier proceso que pueda leer esa memoria, ese archivo de keystore o esa variable de entorno puede potencialmente firmar transacciones. En una wallet fría, la clave se mantiene en un dispositivo o medio que no es accesible por la red durante la operación normal, y cada firma requiere una transferencia deliberada de la transacción sin firmar al entorno de firma y del resultado firmado de vuelta.

Esa distinción importa más que la etiqueta de marketing. Una extensión de navegador, una aplicación móvil, un servicio de firma del lado del servidor y un dispositivo hardware pueden describirse todos como 'una wallet', pero colocan la clave en modelos de amenaza muy diferentes. La pregunta útil no es '¿esto es caliente o frío?' sino '¿qué puede alcanzar la clave y qué debe suceder antes de que exista una firma?'

• Caliente: el material de la clave está presente en software en línea durante la firma.
• Fría: el material de la clave permanece fuera de línea; solo las transacciones cruzan el límite.
• Templada o híbrida: las claves están en línea pero la firma requiere un paso de aprobación, lo que reduce la automatización pero no elimina la superficie de ataque remota.

Supuestos y alcance de esta guía

Este artículo asume que ya entiendes que una wallet almacena claves en lugar de monedas, y que las direcciones se derivan de claves públicas. Se centra en la autocustodia y la custodia operativa para desarrolladores y equipos de infraestructura, no en los saldos de cuentas de exchange. Los diagnósticos utilizan herramientas estándar: un shell, Node.js, Python y curl contra un endpoint RPC que tú controlas.

Cuando necesites un endpoint RPC concreto para leer el estado de la cadena durante estas comprobaciones, consulta la guía de endpoints RPC para obtener contexto y el Asistente RPC para una recomendación específica de proveedor. Esta página se mantiene en la metodología de custodia para que las comprobaciones sigan siendo válidas independientemente de la cadena o el proveedor que utilices.

Modelo mental: la clave nunca se mueve, la transacción sí

Piensa en la clave privada como un sello que solo existe en una habitación. Una wallet caliente mantiene el sello en una habitación con un puerto de red abierto. Una wallet fría mantiene el sello en una habitación sin cable de red, y pasas papel por una ranura. La blockchain solo ve el resultado estampado, por lo que la propiedad de seguridad proviene enteramente de controlar quién puede entrar en la habitación.

Este modelo explica varias confusiones comunes. La autenticación de dos factores en una wallet caliente protege la ruta de inicio de sesión o aprobación, pero si el malware puede leer el archivo de clave directamente, puede firmar sin tocar nunca el aviso de 2FA. A la inversa, un dispositivo hardware que está permanentemente conectado a una computadora en línea sigue siendo frío en el sentido de almacenamiento de claves, pero su botón de aprobación se convierte en el control crítico. El límite es el paso de firma, y cada decisión operativa debe evaluarse con respecto a él.

• Ubicación de la clave: memoria en línea, keystore cifrado, llavero del sistema operativo, elemento seguro o papel.
• Disparador de firma: automático, con contraseña, con 2FA o con botón físico.
• Radio de impacto: una clave, una cuenta o todo un árbol de wallet HD derivado de una sola semilla.

Diagnóstico 1: localizar el material de la clave en un host en ejecución

Antes de confiar en cualquier etiqueta, verifica dónde se encuentran realmente las claves en la máquina que firma. El siguiente procedimiento de shell enumera archivos y variables de entorno comunes que contienen claves. Ejecútalo en un host de staging, nunca pegues secretos reales en una terminal compartida y trata cualquier hallazgo como un problema a investigar.

Verificación esperada: en una configuración correctamente fría, el host de firma no debería mostrar archivos de clave privada de larga duración ni variables de entorno que contengan claves. En una configuración caliente, deberías encontrar exactamente el keystore o almacén de secretos que pretendías, con permisos restrictivos.

# List likely key-bearing files (adjust paths to your stack)
find / -maxdepth 6 \( -name '*.pem' -o -name 'keystore*' -o -name 'id_rsa' -o -name '*.key' \) \
  -type f 2>/dev/null | head -50

# Show environment variables whose names suggest secrets
env | grep -Ei 'private|secret|mnemonic|seed|key' | sed 's/=.*/=<redacted>/'

# Check permissions on a known keystore
stat -c '%a %U:%G %n' /path/to/keystore.json 2>/dev/null

Diagnóstico 2: demostrar el límite de firma con una transacción de prueba

Un límite de firma solo es real si puedes demostrarlo. El siguiente fragmento de Node.js construye y firma una transacción localmente, luego imprime la dirección recuperada para que puedas confirmar qué clave produjo la firma. Ejecútalo en un entorno aislado con una clave desechable. Si el mismo script puede ejecutarse sin supervisión en un servidor expuesto a Internet, ese servidor es un entorno de firma caliente independientemente de cómo el proveedor llame al producto.

Verificación esperada: la dirección recuperada coincide con la dirección que esperas para esa clave. Si no coincide, tu fuente de clave o ruta de derivación es incorrecta, y cualquier suposición de custodia construida sobre ella no es válida.

// npm i ethers
import { Wallet, Transaction } from 'ethers';

const PRIVATE_KEY = process.env.PRIVATE_KEY; // throwaway key only
const wallet = new Wallet(PRIVATE_KEY);

const tx = Transaction.from({
  to: '0x0000000000000000000000000000000000000000',
  value: 0n,
  chainId: 1,
  nonce: 0,
  gasLimit: 21000n,
  maxFeePerGas: 1000000000n,
  maxPriorityFeePerGas: 1000000000n,
  type: 2
});

const signed = await wallet.signTransaction(tx);
const recovered = Transaction.from(signed).from;
console.log('signer address:', recovered);
console.log('expected     :', wallet.address);

Diagnóstico 3: confirmar qué puede ver la red

La cadena en sí nunca revela si una firma provino de una wallet caliente o fría. Lo que revela es la dirección, el nonce y la transacción. Puedes usar una llamada RPC para confirmar que una transacción transmitida se originó desde la dirección que esperas, que es la única evidencia en cadena disponible.

Verificación esperada: el campo from en la transacción devuelta coincide con tu dirección de firma. Una discrepancia significa que la transacción fue firmada por una clave diferente a la que asumiste, que es exactamente el tipo de fallo de custodia que estas comprobaciones están diseñadas para detectar.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getTransactionByHash",
    "params": ["0xYOUR_TX_HASH"]
  }' | python3 -m json.tool

Tabla de resultados: registrar hallazgos de custodia

Registra cada comprobación en una tabla para que los hallazgos sean comparables entre hosts y a lo largo del tiempo. No inventes valores; completa la tabla con tus propias ejecuciones. Una estructura de ejemplo completada se ve así, con filas de marcador de posición que reemplazas con la salida observada.

El valor de la tabla no es la fila individual sino el patrón entre filas. Un host que pasa las comprobaciones de archivos y permisos pero falla la recuperación del firmante tiene un problema de configuración, no de custodia. Un host que pasa la recuperación pero expone un archivo de clave tiene un problema de custodia que ninguna cantidad de firma correcta solucionará.

Solución de problemas comunes de custodia

La mayoría de los incidentes entre caliente y frío caen en un pequeño número de patrones. Revísalos en orden, porque un síntoma posterior a menudo enmascara una causa anterior.

• Discrepancia en la recuperación del firmante: verifica la ruta de derivación y el ID de cadena antes de asumir un compromiso de clave; una ruta incorrecta produce una firma válida desde la dirección equivocada.
• Archivo de clave legible por otros usuarios: corrige los permisos primero, luego rota la clave, porque la exposición puede haber ocurrido ya.
• 2FA habilitado pero la firma sigue siendo automática: la puerta de aprobación está en la interfaz de usuario, no en la ruta de firma; mueve la clave detrás de un límite que la automatización no pueda alcanzar.
• Dispositivo hardware siempre conectado: la clave está fuera de línea, pero el botón de aprobación es ahora el único control; verifica que el botón requiera presencia física y no pueda ser programado.
• Frase semilla almacenada digitalmente 'como respaldo': esto colapsa una wallet fría en una caliente, porque el respaldo ahora es accesible por el mismo malware que la clave caliente.

Limitaciones y compensaciones de cada modelo

El almacenamiento en frío no es gratuito. Cada transacción requiere un paso manual, lo que lo hace inadecuado para operaciones de alta frecuencia, creación de mercado automatizada o liquidación del lado del servidor. También introduce nuevos modos de fallo: dispositivos perdidos, respaldos dañados y fatiga de aprobación que lleva a los operadores a omitir el mismo control que proporciona la seguridad. Una wallet fría que nunca se prueba es un pasivo, no un activo.

Las wallets calientes no son automáticamente inseguras. Una wallet caliente con una clave de alcance limitado, un saldo bajo, aislamiento estricto de procesos y monitoreo puede ser una herramienta operativa adecuada. El error es usar una wallet caliente para tenencias a largo plazo o para claves cuyo compromiso movería más valor del que estás dispuesto a perder. La pregunta correcta no es qué modelo es mejor sino qué valor pertenece detrás de qué límite.

Para los equipos que ejecutan su propia infraestructura, la misma lógica se aplica a las operaciones de nodo. Un nodo dedicado te da control sobre la superficie RPC con la que hablan tus servicios de firma, lo que reduce la exposición a caídas de endpoints compartidos y comportamientos inesperados. Revisa los precios de RPC y las redes compatibles antes de comprometerte con una topología.

Combinar custodia caliente y fría sin engañarte a ti mismo

El patrón práctico es la custodia por niveles: un saldo caliente pequeño para operaciones diarias, una reserva fría para tenencias a largo plazo y una política documentada para mover valor entre ellos. La política debe especificar quién puede aprobar una transferencia, qué evidencia se requiere y cómo se verifica el dispositivo frío antes de cada uso. Sin esa política, los niveles son solo etiquetas.

Una prueba útil es preguntar qué podría hacer un atacante con ejecución remota de código en tu host de firma. Si la respuesta es 'mover el saldo caliente', tu límite está funcionando. Si la respuesta es 'derivar la semilla y drenar todo', tienes una wallet caliente con el nombre de una fría. Ejecuta los diagnósticos anteriores después de cada cambio en la infraestructura de firma, y trata cualquier nuevo archivo o variable de entorno que contenga claves como un cambio de límite que requiere revisión.

• Mantén los saldos calientes dimensionados según la necesidad operativa, no según la comodidad.
• Verifica los dispositivos fríos con una pequeña transacción de prueba antes de confiar en ellos para transferencias grandes.
• Documenta la ruta de aprobación y pruébala, incluido el caso de fallo en el que el dispositivo no está disponible.
• Monitorea los hosts de firma en busca de nuevo material de claves y solicitudes de firma salientes inesperadas.

Próximos pasos para desarrolladores y operadores

Comienza ejecutando los tres diagnósticos en un host de staging y completando la tabla de resultados con tus propias observaciones. Luego asigna cada clave de tu sistema a un límite y a una pérdida máxima aceptable. Donde una clave exceda ese umbral, muévela detrás de un límite frío o con aprobación; donde no lo haga, documenta por qué el modelo caliente es aceptable.

Para la capa RPC de la que dependen tus servicios de firma, usa la descripción general del servicio API para entender qué proporciona un endpoint gestionado, y consulta el Asistente RPC para una elección concreta de proveedor en lugar de adivinar. Si estás construyendo infraestructura de wallet o firma más amplia, la guía de endpoints RPC multicadena cubre cómo interactúa la topología de endpoints con la custodia de claves en diferentes redes.