Almacenamiento de claves criptográficas: Guía práctica para proteger claves privadas y frases semilla

Qué protege realmente el almacenamiento de claves criptográficas

El almacenamiento de claves criptográficas abarca dos secretos relacionados pero distintos. Una clave privada es un valor criptográfico que autoriza firmas para una dirección o validador específico. Una frase semilla (mnemónica) es un secreto raíz legible por humanos, normalmente de 12 o 24 palabras, del que se derivan muchas claves privadas mediante un estándar de cartera determinista como BIP32/BIP39/BIP44. Perder una clave privada supone perder una dirección; perder la frase semilla puede suponer perder todas las direcciones derivadas de ella.

Por lo tanto, el almacenamiento tiene tres objetivos, no uno: confidencialidad (nadie más puede leer o copiar el secreto), disponibilidad (usted puede seguir firmando o recuperando cuando lo necesite) e integridad (puede detectar manipulaciones o corrupción accidental). Un método que maximiza la confidencialidad pero destruye la disponibilidad, como una cartera cerebral memorizada, no es un buen sistema de almacenamiento. Un método que es conveniente pero filtra el secreto a malware es peor.

Este artículo está escrito para personas que custodian claves para sí mismas o para infraestructura: stakers, operadores de validadores, gestores de tesorería y desarrolladores que manejan claves de firma en canalizaciones de despliegue. Asume que ya comprende que quien posee la clave controla los fondos o la autoridad de firma.

• Clave privada: autoriza una dirección o identidad de validador.
• Frase semilla: secreto raíz que deriva muchas claves; respáldela con el mismo cuidado que los fondos que controla.
• Frase de contraseña (palabra opcional BIP39): un secreto adicional que cambia la cartera derivada; guárdela por separado de la semilla.
• Archivo keystore: una clave privada cifrada, útil para automatización pero solo tan fuerte como su contraseña y su host.

Modelo de amenazas antes de elegir un método de almacenamiento

No existe un método de almacenamiento de claves criptográficas universalmente mejor. Comience por enumerar las amenazas que se le aplican y el coste de cada fallo. Las amenazas comunes incluyen malware remoto y escáneres de portapapeles, phishing y software de cartera falso, robo físico o incendio doméstico, coacción, acceso de insiders en servidores compartidos, eliminación accidental y compromiso de la cadena de suministro de un dispositivo o paquete.

Para cada clave, anote: qué controla, con qué frecuencia debe firmar, quién más puede acceder al host y qué sucede si se pierde frente a si se filtra. Una clave de cartera en caliente que firma cada hora tiene un perfil de riesgo diferente al de una frase semilla en frío que nunca debería tocar una máquina conectada a la red. Este inventario es la base de todas las recomendaciones que siguen.

• Riesgo de filtración: malware, sincronización en la nube, capturas de pantalla, historial de shell, registros, variables de CI.
• Riesgo de pérdida: copia única, frase de contraseña olvidada, hardware averiado, papel ilegible.
• Riesgo físico: incendio, inundación, robo, descubrimiento por otros.
• Riesgo operativo: servidores compartidos, CI con privilegios excesivos, claves no rotadas.

El espectro de almacenamiento de caliente a frío

Los métodos de almacenamiento se sitúan en un espectro que va desde siempre en línea hasta completamente fuera de línea. El almacenamiento en caliente incluye carteras de navegador, carteras móviles, cuentas de exchange y claves en variables de entorno en un servidor. Es conveniente y necesario para firmas frecuentes, pero el secreto existe en una máquina conectada a la red y está expuesto a malware y errores de configuración. El almacenamiento templado incluye keystores cifrados en un host reforzado o gestión de claves en la nube respaldada por hardware. El almacenamiento en frío mantiene el secreto fuera de línea: carteras hardware, máquinas aisladas de la red (air-gapped) y copias de seguridad metálicas de frases semilla.

La regla práctica es adaptar el método a la frecuencia de firma y al valor. Las claves que firman con frecuencia pertenecen a un host reforzado con privilegios mínimos y monitorización; las claves que rara vez firman pertenecen a un entorno fuera de línea. Muchos operadores usan un híbrido: una clave en caliente con fondos limitados para operaciones diarias y una clave en frío o multifirma para la tesorería. Los estándares de cartera documentados definen cómo se derivan las claves, pero no prescriben cómo almacenarlas; eso es una decisión operativa.

• Caliente: rápido, expuesto a atacantes remotos; úselo solo para saldos limitados o roles de firma estrictamente delimitados.
• Templado: keystore cifrado o KMS en la nube; bueno para automatización cuando el acceso se audita.
• Frío: cartera hardware o dispositivo aislado; mejor para tenencias a largo plazo y secretos raíz.
• Multifirma: ningún dispositivo individual posee una clave completa; útil para tesorerías y control compartido.

Flujo de trabajo de copia de seguridad de frase semilla y metal

Las copias de seguridad en papel no resisten el fuego, el agua ni el tiempo. Las copias de seguridad metálicas, como placas de acero estampadas o esquemas basados en arandelas, sobreviven a muchas amenazas físicas, pero introducen sus propios riesgos: la copia de seguridad puede ser encontrada y el proceso de estampado puede filtrar la frase a cámaras o transeúntes. Un flujo de trabajo defendible separa la generación, el registro, la verificación y la distribución.

Genere la semilla en un dispositivo fuera de línea de confianza, regístrela en metal, verifíquela restaurándola en un segundo dispositivo fuera de línea y almacene copias en ubicaciones seguras separadas. Nunca escriba la semilla en un ordenador conectado a la red para "comprobarla". Si usa una frase de contraseña BIP39, guárdela por separado de la semilla para que encontrar una no dé acceso a ambas. Registre solo lo necesario: muchos esquemas metálicos almacenan las primeras cuatro letras de cada palabra, lo cual es suficiente para las listas de palabras BIP39 pero debe probarse durante la restauración.

• Genere fuera de línea; nunca fotografíe ni capture la pantalla de la semilla.
• Estampe el metal en un espacio privado; limpie los restos y las herramientas.
• Verifique restaurando en un segundo dispositivo fuera de línea antes de mover fondos.
• Almacene al menos dos copias en ubicaciones separadas con control de acceso.
• Mantenga la frase de contraseña separada de la frase semilla.

Comprobación ejecutable: verificar un keystore sin exponer la clave

Para el almacenamiento templado, los keystores cifrados son comunes. El siguiente fragmento de Python descifra un keystore localmente e imprime solo la dirección derivada, nunca la clave privada. Ejecútelo en una máquina fuera de línea o de confianza, y nunca pegue un keystore real o una contraseña en un servicio en línea. Reemplace los marcadores de posición con su propia ruta de archivo y contraseña.

El resultado esperado de la verificación es una dirección impresa que coincida con la dirección que espera para esa clave. Si el descifrado falla, la contraseña o el archivo son incorrectos; si la dirección difiere, puede que esté viendo un keystore o una ruta de derivación diferentes. No proceda a firmar transacciones hasta que la dirección coincida con sus registros.

from eth_account import Account
import json, os

KEYSTORE_PATH = "keystore.json"
PASSWORD = os.environ["KEYSTORE_PASSWORD"]  # never hardcode

with open(KEYSTORE_PATH) as f:
    ks = json.load(f)

key = Account.decrypt(ks, PASSWORD)
acct = Account.from_key(key)
print("address:", acct.address)
# Do not print key.hex()

Comprobación ejecutable: confirmar que un endpoint RPC ve su dirección

Después de restaurar una clave o mover fondos, confirme que la dirección es visible en la cadena a través de un endpoint RPC de su confianza. La llamada curl a continuación consulta el saldo de una dirección en una red EVM. Use un RPC_URL de marcador de posición de su proveedor; no codifique un endpoint público en producción. Esta comprobación verifica la conectividad y el formato de la dirección, no la seguridad de la clave.

Resultado esperado: una respuesta JSON-RPC con un saldo en hexadecimal. Un saldo cero puede ser legítimo; un error generalmente significa una dirección mal formada, una cadena incorrecta o un endpoint inalcanzable. Para la selección de proveedores y recomendaciones de endpoints, consulte la guía de RPC Assistant sobre mejor API RPC de Ethereum y guía de endpoints RPC.

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

Multifirma y fragmentado de claves para claves de alto valor

Para tesorerías e infraestructura compartida, una sola clave es un único punto de fallo. Las carteras multifirma requieren firmas M-de-N, de modo que ningún dispositivo o persona posee una clave completa. Los esquemas de fragmentado de claves como el Secreto Compartido de Shamir dividen un secreto en fragmentos que deben recombinarse; son útiles para la distribución de copias de seguridad pero requieren una disciplina operativa cuidadosa porque los fragmentos pueden perderse o confundirse.

La multifirma suele ser más fácil de auditar y recuperar que el fragmentado ad hoc porque la política se aplica en la cadena o mediante una cartera conocida. El fragmentado es más adecuado para la copia de seguridad fuera de línea de un secreto raíz. En ambos casos, documente la política, pruebe la recuperación con una cantidad pequeña primero y almacene los fragmentos o dispositivos firmantes en ubicaciones separadas. Evite esquemas en los que una persona pueda reconstruir el secreto por sí sola a menos que sea un riesgo explícito y aceptado.

• Multifirma: política aplicada por contrato o cartera; buena para control compartido.
• Shamir: divide una semilla en fragmentos; bueno para copia de seguridad distribuida, más débil para firma diaria.
• Pruebe la recuperación antes de comprometer fondos significativos.
• Documente las identidades de los firmantes, las ubicaciones y los pasos de recuperación.

Higiene operativa para claves en servidores

Las claves del lado del servidor son la fuente más común de pérdidas evitables. Nunca confirme claves en git, nunca las pegue en chats o tickets y nunca las deje en el historial de shell. Use un gestor de secretos o un keystore cifrado, restrinja los permisos de archivo y ejecute procesos de firma con el mínimo privilegio necesario. Rote las claves cuando el personal se marche o se reconstruya un host.

Para operadores de validadores y nodos, separe la clave de firma del host que enfrenta Internet donde el protocolo lo permita. Monitorice solicitudes de firma inesperadas y mantenga una copia de seguridad fuera de línea de la clave del validador y su contraseña. Si ejecuta infraestructura dedicada, revise las opciones de nodo dedicado y mantenga el material de claves fuera de los servidores de aplicaciones de propósito general. Para la configuración específica de la red, consulte el directorio de redes.

• Use variables de entorno o un gestor de secretos, no archivos fuente.
• Establezca permisos de archivo restrictivos y evite cuentas compartidas.
• Rote las claves ante cambios de personal y reconstrucciones de hosts.
• Registre eventos de firma sin registrar secretos.

Procedimiento de verificación y monitorización

El almacenamiento no está terminado hasta que lo haya verificado. Cree una comprobación repetible: restaure desde la copia de seguridad en un dispositivo fuera de línea, confirme la dirección derivada y confirme la visibilidad en la cadena a través de un endpoint RPC de confianza. Registre la fecha, el método y el resultado en un registro privado. Repita periódicamente y después de cualquier cambio en la custodia.

Una tabla de resultados simple ayuda a realizar un seguimiento de las comprobaciones sin almacenar secretos. Rellénela con sus propias observaciones; no copie números de nadie más. La siguiente tabla es una plantilla, no datos medidos.

• | Comprobación | Método | Resultado esperado | Fecha |
• | Restauración de semilla | Dispositivo fuera de línea | La dirección coincide con los registros | (su fecha) |
• | Legibilidad de la copia metálica | Inspección visual | Todas las palabras legibles | (su fecha) |
• | Descifrado del keystore | Script fuera de línea | Dirección esperada impresa | (su fecha) |
• | Visibilidad en la cadena | Consulta de saldo RPC | La dirección devuelve respuesta | (su fecha) |

Solución de problemas comunes de almacenamiento

La mayoría de los incidentes de almacenamiento de claves siguen unos pocos patrones. Una frase semilla que se restaura a una dirección diferente generalmente significa una frase de contraseña incorrecta, una ruta de derivación diferente o una palabra mal leída. Un keystore que no se descifra generalmente significa una contraseña incorrecta o un archivo corrupto; mantenga una copia de seguridad fuera de línea sin cifrar de la semilla si el keystore es la única copia. Una copia de seguridad metálica ilegible generalmente significa un estampado deficiente o corrosión; inspecciónela y rehágala antes de necesitarla.

Si sospecha una filtración, trate la clave como comprometida de inmediato: mueva los fondos a una nueva clave, rote las claves del validador donde el protocolo lo permita y revoque las aprobaciones. No reutilice una semilla filtrada incluso si los fondos aún no han sido tomados. Para problemas de endpoint o conectividad durante la verificación, consulte la guía relevante de RPC Assistant en lugar de asumir que la clave es incorrecta.

• Dirección incorrecta tras la restauración: verifique la frase de contraseña, la ruta de derivación y el orden de las palabras.
• Fallo del keystore: verifique la contraseña, la integridad del archivo y la versión del cliente.
• Copia de seguridad ilegible: rehaga la copia metálica y verifique de nuevo.
• Sospecha de filtración: mueva fondos, rote claves, revoque aprobaciones.

Limitaciones, compensaciones y próximos pasos

Cada método de almacenamiento intercambia conveniencia por riesgo. El almacenamiento en frío reduce la superficie de ataque remota pero aumenta la probabilidad de pérdida por frases de contraseña olvidadas o copias de seguridad dañadas. La multifirma reduce el fallo de punto único pero añade complejidad de coordinación y recuperación. La gestión de claves en la nube mejora la auditabilidad pero depende de la seguridad del proveedor y de sus controles de acceso. No existe una opción de riesgo cero; el objetivo es hacer visibles y recuperables los modos de fallo.

Como siguiente paso, inventaríe sus claves, asigne a cada una un nivel de almacenamiento y ejecute el procedimiento de verificación anterior con una pequeña cantidad de prueba. Si opera nodos o validadores, revise servicio API y precios de RPC para separar la fiabilidad del endpoint de la custodia de claves, y mantenga las claves de firma en infraestructura que usted controle. Para opciones de endpoints específicas del proveedor, use RPC Assistant en lugar de incrustar un único proveedor en su plan de gestión de claves.

• Inventaríe las claves y asigne niveles caliente, templado o frío.
• Pruebe la recuperación antes de mover valor significativo.
• Documente la política y revísela tras cambios de personal o infraestructura.
• Mantenga la selección de endpoints separada de las decisiones de custodia de claves.