Monederos calientes y fríos: modelos de custodia de claves, límites de amenaza y flujos de verificación

Respuesta directa y alcance

Un monedero caliente es cualquier monedero cuyas claves privadas se guardan en software en una máquina conectada a Internet durante la firma, de modo que un proceso en línea puede acceder al material de la clave. Un monedero frío es cualquier monedero cuyas claves privadas se guardan en un entorno que está fuera de línea en el momento de la firma, y solo las transacciones o cargas firmadas cruzan el límite. La distinción se refiere al límite de la clave, no a si el producto se denomina aplicación, extensión de navegador, dispositivo hardware o trozo de papel.

Este artículo cubre el modelo de custodia, los límites de amenaza que crea cada modelo y formas reproducibles de verificar qué modelo está operando realmente. No recomienda proveedores de monederos específicos y no afirma ningún resultado de seguridad medido para OnFinality ni para ningún otro proveedor. Cuando un número sería útil, el artículo le proporciona un procedimiento para medirlo en su propia configuración en lugar de inventar un valor.

• Monedero caliente: clave accesible por un proceso conectado a Internet en el momento de la firma.
• Monedero frío: clave mantenida fuera de línea en el momento de la firma; solo las cargas cruzan el límite.
• Configuraciones tibias o híbridas: las claves están en línea pero la firma está condicionada por políticas, aprobación o un segundo factor.
• La etiqueta del producto no determina el modelo; el límite en tiempo de ejecución sí.

Supuestos y requisitos previos

Los procedimientos a continuación asumen que tiene un monedero de autocustodia donde usted controla el material de la clave, un terminal con curl y Python 3 disponibles, y acceso a un endpoint JSON-RPC para la red que utiliza. Reemplace RPC_URL con su propio endpoint; no pegue claves privadas reales en ningún comando de este artículo. Si necesita un endpoint gestionado para comprobaciones de solo lectura, consulte la guía de endpoints RPC multicadena y la guía de endpoints RPC para saber cómo se estructuran los endpoints.

También debe saber qué red e ID de cadena tiene como objetivo su monedero, porque un monedero apuntado a la cadena incorrecta puede parecer que funciona mientras firma transacciones para una red diferente. El directorio de redes enumera las redes compatibles si no está seguro de qué ID de cadena corresponde.

El modelo mental del límite de la clave

Piense en un monedero como tres partes separables: almacenamiento de claves, firma y difusión. En un monedero caliente, las tres pueden ejecutarse en el mismo proceso en línea. En un monedero frío, el almacenamiento de claves y la firma ocurren en un entorno fuera de línea, y solo la transacción firmada se lleva a una máquina en línea para su difusión. Esta separación es lo que cambia el modelo de amenaza: un atacante que compromete su máquina en línea generalmente puede acceder a una clave caliente, pero no debería poder acceder a una clave fría sin comprometer también el entorno fuera de línea o el paso de transferencia.

El límite es tan fuerte como su cruce más débil. Si fotografía una frase semilla, la escribe en un gestor de contraseñas en línea o firma en un dispositivo que alguna vez estuvo conectado a Internet mientras la clave estaba desbloqueada, efectivamente ha movido la clave a la zona caliente. Una prueba útil es preguntar: en el instante en que se firma una transacción, ¿puede un proceso conectado a Internet leer o usar la clave sin que un humano mueva físicamente los datos a través de un aislamiento de aire? Si la respuesta es sí, trate el monedero como caliente independientemente de su marketing.

• Almacenamiento de claves: dónde reside el material secreto en reposo.
• Firma: el proceso que convierte una transacción en una carga firmada.
• Difusión: el paso en línea que envía la carga a un nodo o endpoint RPC.
• Un modelo frío requiere que la firma ocurra sin que la clave sea accesible por la máquina de difusión.

Verificar qué modelo ejecuta realmente

Antes de confiar en una etiqueta, confirme los hechos en tiempo de ejecución. Las comprobaciones a continuación son de solo lectura y utilizan un endpoint de marcador de posición. Verifican la identidad de la cadena y el estado de la cuenta, que es la base para cualquier decisión de custodia; no prueban el aislamiento de claves por sí mismos, pero detectan el fallo común donde un monedero apunta a la red incorrecta o a una cuenta inesperada.

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"eth_getBalance","params":["0xYOUR_ADDRESS","latest"]}'

Un procedimiento reproducible de comprobación de exposición

Utilice el siguiente procedimiento para registrar, para cada monedero que opere, si el límite de la clave es caliente o frío en el momento de la firma. Ejecútelo una vez por monedero y almacene los resultados en una tabla. No invente valores; registre lo que observe.

La tabla a continuación es una plantilla. Complete cada fila a partir de su propia observación y mantenga la tabla con sus notas operativas para poder volver a ejecutar la comprobación después de cualquier cambio de configuración.

• Paso 1: Identifique el entorno de firma (teléfono, portátil, extensión de navegador, dispositivo hardware, máquina con aislamiento de aire).
• Paso 2: En el momento de la firma, registre si ese entorno tiene una conexión de red activa.
• Paso 3: Registre cómo llega la carga firmada al paso de difusión (mismo proceso, código QR, archivo USB, copia manual).
• Paso 4: Registre si el material de la clave alguna vez se escribió, fotografió o sincronizó en un sistema en línea.
• Paso 5: Clasifique el monedero como caliente, frío o híbrido según los pasos 2–4, no según el nombre del producto.

Diagnóstico ejecutable: comprobar una solicitud de firma antes de la difusión

Una forma práctica de reducir el riesgo del monedero caliente es inspeccionar una transacción antes de que se difunda. El fragmento de Python a continuación construye una llamada JSON-RPC mínima para estimar el gas y obtener el nonce de una dirección, lo que le permite confirmar que la transacción tiene como objetivo la cadena que espera. Utiliza solo marcadores de posición y no firma nada.

Ejecútelo contra su propio endpoint y compare el ID de cadena devuelto con la red que muestra su monedero. Una discrepancia es una señal fuerte de que el monedero está mal configurado y debe tratarse como inseguro hasta que se corrija.

import json, urllib.request

RPC_URL = "RPC_URL"
ADDRESS = "0xYOUR_ADDRESS"

def rpc(method, params):
    body = json.dumps({"jsonrpc": "2.0", "id": 1, "method": method, "params": params}).encode()
    req = urllib.request.Request(RPC_URL, data=body, headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=10) as resp:
        return json.loads(resp.read())

print("chainId:", rpc("eth_chainId", []))
print("nonce:", rpc("eth_getTransactionCount", [ADDRESS, "pending"]))
print("gasPrice:", rpc("eth_gasPrice", []))

Resultado de verificación esperado

Cuando las comprobaciones anteriores tienen éxito, debería ver un ID de cadena que coincida con la red que pretende usar, un nonce que aumenta solo cuando envía transacciones y un precio de gas que sea plausible para las condiciones actuales de la red. Si el ID de cadena difiere de lo que muestra su monedero, deténgase y corrija la configuración antes de firmar cualquier cosa. Si el nonce es inesperadamente alto, otro firmante puede estar usando la misma dirección, lo cual es una señal de alerta de custodia.

Para configuraciones frías, el resultado de la verificación también incluye un hecho observable por humanos: el entorno de firma no tenía conexión de red en el momento de la firma, y la carga cruzó el límite a través de un canal que usted puede describir. Si no puede describir ese canal, trate el monedero como caliente.

Solución de problemas de configuraciones incorrectas comunes

La mayoría de los fallos de custodia son fallos de configuración, no rupturas criptográficas. La lista a continuación cubre los patrones que con mayor frecuencia convierten un monedero nominalmente frío en uno caliente, o hacen que un monedero caliente firme en la cadena incorrecta.

Si un dispositivo hardware está conectado a una computadora en línea mientras su clave está desbloqueada, el límite se debilita durante la duración de esa sesión. Si una frase semilla se introdujo en una herramienta de recuperación en línea, la clave debe considerarse expuesta y rotarse. Si un monedero muestra un saldo en una red pero las transacciones fallan en otra, verifique el ID de cadena con el diagnóstico anterior antes de asumir un problema de nodo.

• Frase semilla escrita en un gestor de contraseñas en línea o nota en la nube: tratar como caliente y rotar.
• Dispositivo hardware dejado desbloqueado y conectado durante la navegación: límite debilitado.
• Monedero apuntado a un ID de cadena incorrecto: las transacciones pueden firmarse para una red no deseada.
• Dirección compartida entre múltiples firmantes: conflictos de nonce y custodia poco clara.
• Copia de seguridad almacenada sin cifrar en una unidad en red: el material de la clave es accesible en línea.

Limitaciones y compensaciones

La custodia en frío reduce la superficie de ataque en línea pero añade fricción operativa: cada transacción requiere un paso físico, y los dispositivos perdidos o dañados pueden significar una pérdida permanente si las copias de seguridad son inadecuadas. La custodia en caliente es conveniente y apropiada para pequeños saldos operativos, pero concentra el riesgo en la máquina en línea. Los modelos híbridos intentan equilibrar ambos manteniendo las claves en línea detrás de una política de aprobación, lo que reduce la exposición casual pero no elimina el límite en línea.

Ningún modelo de custodia elimina la necesidad de verificar lo que se firma. Un monedero frío que firma una carga maliciosa sigue siendo una pérdida. Combine el límite con la inspección de transacciones, listas de direcciones permitidas y conciliación periódica contra un endpoint de confianza. Para equipos que ejecutan infraestructura dedicada, las páginas del servicio de nodo dedicado y del servicio de API describen cómo encaja el acceso gestionado en una configuración operativa, y la página de precios de RPC explica cómo se mide el uso del endpoint.

Próximos pasos

Comience clasificando cada monedero que opere utilizando el procedimiento de comprobación de exposición, luego corrija cualquier monedero que esté etiquetado como frío pero falle la prueba de límite. Rote las claves que alguna vez estuvieron expuestas en línea y documente el canal de transferencia de cargas para cada configuración fría para que el límite sea auditable. Si necesita un endpoint confiable para las comprobaciones de solo lectura en este artículo, revise la guía de endpoints RPC multicadena y la guía de endpoints RPC, luego elija un endpoint que coincida con su red del directorio de redes. Para recomendaciones concretas de endpoints y proveedores, consulte a RPC Assistant en lugar de tratar este artículo como una lista de proveedores.