--- title: "Carteras frías: firma sin conexión, recuperación y controles operativos" description: "Aprenda cómo diseñar y verificar la custodia de billeteras frías a través de la generación de claves, identidad de la cartera, copias de seguridad, revisión de transacciones, firma fuera de línea, multisig, recuperación y respuesta a incidentes." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Carteras frías: firma sin conexión, recuperación y controles operativos > Solo para fines educativos; no es un consejo de inversión. Invertir puede resultar en pérdidas. ## Respuesta directa Una cartera fría es un sistema de custodia que mantiene el material de firma secreto y el paso decisivo de aprobación fuera de la exposición normal del software conectado a Internet. Los activos permanecen en la cadena de bloques; el sistema controla las claves u otra autoridad que puede autorizar cambios de estado. "Cartera fría" es una etiqueta operativa, no una clase de dispositivo definida por protocolo, y la frialdad es una propiedad del flujo de trabajo completo más que de una marca o tipo de conexión. Un firmante de hardware puede soportar almacenamiento en frío mientras esté conectado por USB porque la clave privada puede permanecer aislada, pero el flujo de trabajo es inseguro si el usuario firma un destino no verificado o una llamada de contrato opaca. Por el contrario, una computadora aislada de la red no es segura simplemente porque carezca de interfaz de red: la entropía comprometida, los medios de instalación, los analizadores de transacciones, los medios extraíbles, las copias de seguridad o las pantallas aún pueden vulnerar la frontera. El almacenamiento en frío reduce la exposición a la extracción remota de claves; no demuestra la intención de la transacción, la corrección del software, la recuperación, la privacidad ni la finalización. La copia de recuperación no es "solo una copia de seguridad." Un mnemónico, semilla en bruto, clave privada extendida o una participación de recuperación equivalente puede recrear la autoridad de gasto y, por lo tanto, necesita protección comparable a la de un firmante. También pueden ser necesarios una frase de contraseña, ruta de derivación, red, tipo de script, descriptor de cartera, orden de claves y política de umbral para recuperar las direcciones esperadas. Una cartera pública solo de observación normalmente no puede firmar, pero un `xpub` o descriptor puede revelar relaciones entre direcciones e historial de transacciones, y BIP-32 proporciona claves públicas extendidas con implicaciones de seguridad más fuertes que las claves públicas ordinarias. ## Cómo diseñar y verificar almacenamiento en frío ### 1. Definir la autoridad y el modelo de amenazas Registre la red exacta, el activo, la cuenta o la política de salida, los propietarios, los beneficiarios, la autoridad de recuperación, la frecuencia esperada de transacciones y la exposición operativa máxima. Identifique malware remoto, aplicaciones maliciosas, compromisos en la cadena de suministro, colusión interna, robo físico, coerción, incendio, inundación, pérdida, incapacidad y herencia como amenazas separadas. Decida qué debe permanecer en frío: una única clave privada, todas las claves en un umbral, un quórum de firmantes, una clave de autorización EIP-712 o un administrador capaz de cambiar el código de la cartera. ### 2. Inicializar entropía y software confiables Obtenga dispositivos y software a través de canales autenticados, inspeccione el estado de inicialización, verifique las versiones donde sea compatible y rechace cualquier mnemónico o secreto pre-generado suministrado en el empaque o por un asistente. Genere entropía en un entorno controlado y registre qué estándar e implementación la crearon. BIP-39 codifica `128` a `256` bits de entropía como un mnemónico y deriva una semilla `512-bit` del mnemónico más una frase de paso opcional; no es un estándar para convertir una frase memorable en una cartera segura. ### 3. Fijar la identidad reproducible de la cartera Antes de una financiación sustancial, registre la red, la huella digital maestra, el estándar de derivación y la ruta completa, el índice de la cuenta, el tipo de dirección o script, y las primeras direcciones de recepción verificadas. Para las políticas Bitcoin, conserve el descriptor de salida, la suma de verificación, los orígenes de las claves, el umbral, el número de firmantes, el orden de las claves y las ramas de cambio. Para cada firmante, confirme de manera independiente que su clave y la política mostrada sean las previstas. Trate un `xpub` como metadatos sensibles: puede derivar descendientes públicos no endurecidos, dañar la privacidad y, junto con una clave privada hija correspondiente no endurecida, exponer la clave privada extendida del padre bajo BIP-32. ### 4. Respaldar y probar la recuperación Protege cada entrada de recuperación requerida, incluyendo la mnemónica o las participaciones, la frase de contraseña opcional, el descriptor o la configuración de la cuenta inteligente, la ruta de derivación y las instrucciones de recuperación. No inventes un esquema dividiendo las palabras mnemónicas en fragmentos ad hoc; utiliza un umbral especificado o un diseño multisig cuando una sola copia no deba ser suficiente. Coloca las copias en dominios de falla genuinamente independientes y controla el acceso sin exponer su contenido. En un firmante de repuesto confiable o reinicializado, practica la restauración y compara la huella digital esperada, la política y la dirección de recepción antes de limpiar el entorno de prueba. ### 5. Construir y verificar la intención completa Un coordinador en línea puede obtener el estado de la cadena y construir una solicitud no firmada, pero no es confiable. Para un Bitcoin `PSBT`, verifique la red, cada entrada y la cantidad UTXO, la salida del destinatario, la cantidad, la tarifa, la tasa de tarifa, el tiempo de bloqueo, la política de sighash y si cada otra salida es un cambio autenticado. Para una transacción EVM, verifique `chainId`, `nonce`, `to`, `value`, el límite de gas, los límites de tarifa y `data` decodificado; para EIP-712, verifique el dominio, `chainId`, `verifyingContract`, los campos del mensaje, el nonce y el plazo cuando sea aplicable. EIP-712 estructura los datos y separa los dominios, pero el estándar explícitamente no proporciona protección contra replays por sí mismo. ### 6. Firmar a través de un límite de transferencia controlado Mueva únicamente la carga útil no firmada o parcialmente firmada requerida a través del QR, tarjeta, cable u otro canal aprobado. Los aislantes físicos y los códigos QR no hacen que los analizadores o medios sean confiables: el firmante debe analizar la carga útil, autenticar la política y el cambio, mostrar las consecuencias materiales y rechazar los campos no admitidos. En multisig, mantenga los firmantes, operadores, ubicaciones, proveedores y rutas de recuperación lo suficientemente independientes para coincidir con el modelo de amenazas; trate al coordinador como reemplazable e incapaz de cambiar la política sin ser notado. Compare la transacción o operación firmada con la intención aprobada antes de la transmisión. ### 7. Conciliar, mantener y preparar la migración Después de la transmisión, coincida el identificador de la transacción, la transacción incluida, las salidas o registros, la tarifa real, el cambio, el nonce de la cuenta, los permisos y los balances resultantes con la intención firmada, luego espere la finalización apropiada según la cadena y el caso de uso. Mantenga software compatible, rutas de firmware verificadas, copias de seguridad legibles, descriptores documentados y ejercicios periódicos de recuperación sin introducir secretos de producción en un dispositivo en línea. Si algún secreto de firma o recuperación puede estar expuesto, una cuenta simple de clave única no puede revocar esa clave: establezca una nueva autoridad, migre activos y roles, invalide los permisos restantes donde el protocolo lo permita y preserve un registro del incidente. ## Ejemplos resueltos ### Asignación y financiamiento por etapas Un plan de custodia limita la cartera de interacción en línea a `5%` de `100,000 units` de valor de activo: `100,000 × 5% = 5,000 units` caliente y `95,000 units` fría. El destino frío primero recibe una prueba `100-unit`, y la transferencia restante es `95,000 - 100 = 94,900 units`. Después de ambas transferencias, el objetivo del saldo frío es `100 + 94,900 = 95,000 units`; la pequeña prueba limita un error de configuración pero no valida firmas futuras ni la recuperación de respaldo. ### Bitcoin PSBT tarifa y cambio Un `PSBT` gasta entradas de `0.80 BTC` y `0.35 BTC`, sumando un total de `1.15 BTC`. Paga `1.00 BTC` al destinatario y estima `250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC`. Por lo tanto, el cambio autenticado debe ser `1.15 - 1.00 - 0.000020 = 0.149980 BTC`. Si el firmante no puede identificar esa salida de cambio a partir de su política registrada, no debería firmar incluso cuando el balance aritmético total coincida. ### Presupuesto máximo de EVM frente a la tarifa real Una cuenta EVM comienza con `5 ETH` y aprueba una transferencia de `1.2 ETH`. Un límite `30,000 gas` y una tarifa máxima `50 gwei` implican un presupuesto de tarifas de `30,000 × 50 gwei = 0.001500 ETH`. Si la transacción utiliza `21,000 gas` a un precio efectivo de `25 gwei`, la tarifa real es `21,000 × 25 gwei = 0.000525 ETH`, dejando `5 - 1.2 - 0.000525 = 3.799475 ETH`. El firmante debe revisar los topes de tarifa y `data`, no asumir que se cobrará el presupuesto máximo o que una interfaz que parece vacía demuestra una transferencia ordinaria. ### Resiliencia de dos de tres firmantes Una política `2-of-3` con firmantes `A`, `B` y `C` tiene `3` pares de firma válidos: `AB`, `AC` y `BC`. Si un firmante no está disponible, exactamente `1` par permanece; si un firmante está comprometido, ese firmante solo controla `0` pares válidos; si dos firmantes están comprometidos, ellos controlan `1` par válido y pueden gastar. Por lo tanto, el diseño tolera una pérdida o un compromiso aislado, no dos, y la recuperación aún requiere el descriptor correcto, los datos de derivación y el orden de las claves. ## Riesgos y fallos de revisión - **Red o política equivocadas:** restaurar una clave válida con la cadena, el tipo de dirección, el script, la cuenta o la política de cuenta inteligente incorrectos puede producir direcciones distintas o inutilizables. - **Entropía insuficiente:** una fuente predecible, una brainwallet o un generador comprometido puede hacer adivinable una clave aunque se mantenga fuera de línea. - **Secreto suministrado por terceros:** una frase mnemónica preimpresa, importada, fotografiada o entregada por un asistente puede estar ya bajo control del atacante. - **Exposición de la copia de seguridad:** papel, metal, copias en la nube, impresoras, cámaras, mensajería o documentos sucesorios pueden revelar toda la autoridad de gasto. - **Fallo de la frase de contraseña:** perder o escribir mal la frase de contraseña BIP-39 puede derivar otra cartera sin mostrar ningún error. - **Parámetros de derivación incompatibles:** omitir rutas, tipos de moneda, índices de cuenta o convenciones de la cartera puede ocultar activos que sí serían recuperables. - **Pérdida de configuración:** las claves multisig sin descriptor, umbral, tipo de script, origen y orden de claves quizá no reconstruyan la cartera financiada. - **Fuga de metadatos públicos:** un `xpub`, un descriptor, el inventario de direcciones o la base del coordinador pueden revelar saldos, vínculos y direcciones futuras. - **Compromiso de la cadena de suministro:** hardware, firmware, software, embalaje o canales de actualización alterados pueden sustituir entropía, direcciones o firmas. - **Sustitución por el host:** el coordinador conectado puede cambiar destinatario, importe, comisión, cambio, calldata, mensaje tipado o carga sin firmar. - **Pantalla insuficiente:** truncamiento, firma ciega, scripts incompatibles o decodificación incompleta pueden ocultar una autorización importante. - **Ataque a la dirección de cambio:** si el firmante no autentica el cambio contra la política, una transacción Bitcoin puede enviarlo a un atacante. - **Error de comisión o nonce:** comisiones excesivas, nonces EVM obsoletos, locktimes erróneos o modos sighash imprevistos pueden retrasar, sustituir o alterar la ejecución. - **Autoridad contractual persistente:** aprobaciones de tokens, permisos, módulos, delegados y llamadas administrativas pueden seguir vigentes tras la transacción visible. - **Ataque al canal de transferencia:** QR, USB, tarjetas, cables y formatos de parser pueden transportar cargas maliciosas o filtrar metadatos. - **Cuórum correlacionado:** firmantes colocados juntos, semillas compartidas o dependencia de un único proveedor, operador o lugar de recuperación reducen la independencia del umbral. - **Ataque físico:** robo, coacción, vigilancia, manipulación y descubrimiento de secretos siguen siendo posibles sin conexión a la red. - **Pérdida ambiental:** incendio, inundación, corrosión, degradación del soporte, bóvedas inaccesibles, muerte o incapacidad pueden volver inaccesible un secreto correcto. - **Degradación de compatibilidad:** firmware obsoleto, derivaciones o scripts no admitidos y migraciones sin documentar pueden impedir futuras recuperaciones o firmas. - **Respuesta incompleta al incidente:** consultar el saldo sin migrar claves, roles, aprobaciones y autoridad de recuperación puede dejar activo el compromiso original. ## Conceptos erróneos comunes ### ¿Tiene que permanecer un monedero frío físicamente desconectado para siempre? No. La propiedad de seguridad es que la autoridad secreta permanece aislada y la firma ocurre a través de un límite controlado y verificable. Un firmador de hardware conectado por cable puede preservar esa propiedad; una computadora desconectada de la red con una configuración comprometida o revisión de carga útil puede no hacerlo. ### ¿Se almacenan monedas dentro del dispositivo de hardware? No. El estado de la blockchain registra los activos. El dispositivo protege o utiliza la autoridad que puede firmar transacciones, y el material de recuperación compatible puede reproducir esa autoridad en otra implementación. ### ¿Es una copia de seguridad mnemónica menos sensible que el dispositivo de firma? No. Un mnemónico completo y la frase de contraseña requerida pueden recrear la cartera. Una copia de seguridad normalmente está inactiva, pero su compromiso puede ser tan decisivo como la extracción de la clave activa de firma. ### ¿El multisig elimina la necesidad de copias de seguridad y registros de configuración? No. Los umbrales reducen los puntos únicos de falla seleccionados, pero cada clave necesita un plan de recuperación y la política de la cartera o el descriptor debe ser reproducible. Demasiadas pocas claves supervivientes o una configuración perdida aún pueden bloquear los fondos. ### ¿Demuestra una prueba de transferencia exitosa que el sistema de almacenamiento en frío es seguro? No. Confirma un camino limitado en un momento dado. No prueba la calidad de la entropía, la confidencialidad de la copia de seguridad, la restauración, la decodificación de transacciones futuras, la independencia del quórum, las actualizaciones de software, la seguridad del contrato o la recuperación ante incidentes. ## Temas relacionados - [Cartera de hardware](/es/crypto/hardware-wallet/) - [Frase semilla](/es/crypto/seed-phrase/) - [Claves públicas y privadas](/es/crypto/public-private-key/) - [Cartera multifirma](/es/crypto/multisig-wallet/) - [Simulación de transacción](/es/crypto/transaction-simulation/) ## Fuentes - [Resumen de la Tecnología Blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (accedido: 2026-08-19) - [BIP 32: Carteras Determinísticas Jerárquicas](https://bips.dev/32/) - Propuestas de Mejora Bitcoin (accedido: 2026-08-19) - [BIP 39: Código mnemónico para generar claves determinísticas](https://bips.dev/39/) - Propuestas de Mejora Bitcoin (accedido: 2026-08-19) - [BIP 44: Jerarquía de Múltiples Cuentas para Carteras Determinísticas](https://bips.dev/44/) - Propuestas de Mejora Bitcoin (accedido: 2026-08-19) - [BIP 174: Formato de Transacción Bitcoin Parcialmente Firmada](https://bips.dev/174/) - Propuestas de Mejora Bitcoin (accedido: 2026-08-19) - [BIP 380: Operación General de Descriptores de Script de Salida](https://bips.dev/380/) - Propuestas de Mejora Bitcoin (accedido: 2026-08-19) - [BIP 129: Configuración Segura Multisig Bitcoin](https://bips.dev/129/) - Propuestas de Mejora Bitcoin (accedido: 2026-08-19) - [EIP-712: Hashing y Firma de Datos Estructurados Tipados](https://eips.ethereum.org/EIPS/eip-712) - Propuestas de Mejora Ethereum (accedido: 2026-08-19) Source: https://wiki.fcontext.com/es/crypto/cold-wallet/index.mdx