# Modelo abierto de amenazas para la custodia de Bitcoin de BitcoinSafe
Un marco público para examinar cómo los fallos operativos y los ataques pueden provocar gastos no autorizados, pérdida de capacidad de recuperación, exposición de privacidad o fallos de continuidad. Cada amenaza se vincula con controles, pruebas esperadas y riesgo restante.
- **Versión:** 1.0.0
- **Publicado:** 2026-08-28
- **Última revisión:** 2026-08-28
## Audiencia
Personas que gestionan su propia custodia de Bitcoin, educadores que explican la autocustodia y desarrolladores que necesitan identificadores públicos estables para sus guías. El modelo no se adapta a una persona, saldo, jurisdicción o adversario concretos.
## Metodología
El modelo sigue una secuencia de alcance, amenaza, respuesta y revisión. Las prioridades describen hasta qué punto una condición puede conducir directamente a una pérdida; no estiman probabilidades. Los controles reducen vías de fallo concretas, pero nunca certifican que una cartera o configuración sea segura.
### Límite de certificación
Esta publicación es un marco de razonamiento, no una puntuación de seguridad, auditoría, garantía, recomendación de producto ni certificación. La documentación pública puede estar incompleta, las implementaciones pueden contener fallos y los controles bien aplicados siguen dejando riesgo residual.
## Supuestos
### La autoridad de gasto depende de las claves y la política válidas
Quien pueda satisfacer la política de la cartera puede autorizar un gasto. Perder todas las vías de recuperación válidas puede volver inaccesibles los fondos aunque la red Bitcoin siga funcionando.
### Los dispositivos y servicios de uso general pueden fallar o ser comprometidos
Los teléfonos, ordenadores, sesiones del navegador, cuentas en la nube, plataformas, coordinadores y canales de comunicación se consideran falibles, no fiables por defecto.
### El error humano forma parte del entorno operativo
El modelo incluye errores al manejar copias, recuperar, revisar transacciones, controlar accesos, documentar y transferir responsabilidades. No presupone un operador perfectamente formado.
### Solo las pruebas verificables respaldan una afirmación publicada
Un control se documenta solo hasta el nivel respaldado por especificaciones públicas, documentación del proveedor, registros reproducibles o una revisión identificada. La ausencia de un problema divulgado no demuestra seguridad.
## Activos protegidos
- **Autoridad de gasto** (`asset-spending-authority`): Claves privadas, dispositivos de firma, contraseñas adicionales, políticas y componentes de quórum que pueden autorizar una transacción.
- **Capacidad de recuperación** (`asset-recovery-capability`): Copias, metadatos de la cartera, información de derivación, instrucciones y procedimientos probados necesarios para restaurar el acceso.
- **Intención de la transacción** (`asset-transaction-intent`): El destinatario, importe, comisión, cambio, entradas y política de firma previstos para un gasto.
- **Privacidad y metadatos de la cartera** (`asset-privacy-metadata`): Direcciones, claves públicas extendidas, saldos, historial de transacciones, contrapartes y relaciones de propiedad.
- **Continuidad operativa** (`asset-operational-continuity`): La capacidad de una persona autorizada para entender, mantener, recuperar y transferir la configuración con el tiempo.
## Lenguaje de prioridad
- **Atención alta** (`high`): La condición descrita puede permitir directamente un gasto no autorizado o una pérdida permanente de acceso. La etiqueta no estima la probabilidad del suceso.
- **Importante** (`important`): La condición puede impedir la recuperación, debilitar la verificación o dificultar considerablemente la contención de otro fallo.
- **Depende del contexto** (`contextual`): La consecuencia depende mucho del modelo de custodia, el valor en riesgo, el adversario, la jurisdicción o la frecuencia de uso. Aun así exige una decisión explícita.
## Categorías de amenazas y relaciones
### Autoridad de custodia
Quién puede autorizar gastos y qué partes o componentes deben seguir disponibles y actuar correctamente.
#### Un proveedor controla el retiro o la firma
- **ID:** `threat-custody-provider-control`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Una plataforma, custodio, cartera alojada o servicio de políticas puede retrasar, rechazar, redirigir o perder la capacidad de autorizar un retiro.
- **Por qué importa:** El operador no posee todas las claves necesarias para gastar. La solvencia, los controles de cuenta, la política, la jurisdicción y la disponibilidad del proveedor forman parte del límite de custodia.
- **Mitigaciones:** [Documenta el límite de custodia](#mitigation-define-custody-boundary), [Usa acceso resistente al phishing cuando esté disponible](#mitigation-phishing-resistant-access)
- **Pruebas esperadas:** [Pruebas del límite de custodia](#evidence-custody-boundary), [Pruebas de control de acceso](#evidence-access-controls)
- **Riesgos residuales:** [Siguen existiendo dependencias de custodia](#residual-custody), [Un acceso fuerte no protege todas las dependencias](#residual-access)
#### Se roba o copia suficiente autoridad de firma
- **ID:** `threat-custody-signer-compromise`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Un atacante obtiene una clave privada, frase de recuperación, contraseña adicional, dispositivo de firma o suficientes componentes para cumplir la política.
- **Por qué importa:** Bitcoin valida la autorización, no la identidad ni la intención de quien presenta una firma válida. La separación solo ayuda mientras el umbral de la política siga sin comprometerse.
- **Mitigaciones:** [Aísla suficiente autoridad de firma](#mitigation-isolate-signing-keys), [Separa los secretos de las instrucciones y entre sí](#mitigation-separate-secret-material)
- **Pruebas esperadas:** [Pruebas del límite de custodia](#evidence-custody-boundary), [Pruebas de las copias](#evidence-backup-check)
- **Riesgos residuales:** [Siguen existiendo dependencias de custodia](#residual-custody), [Disponibilidad y secreto siguen en tensión](#residual-backup)
### Resiliencia de las copias
Si el material de recuperación sobrevive a una pérdida y permanece fuera del alcance de personas no autorizadas.
#### El material de recuperación falta o no se puede leer
- **ID:** `threat-backup-unavailable`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Pérdida, incendio, agua, corrosión, eliminación accidental, fallo de memoria o una única ubicación compartida destruyen todas las copias utilizables.
- **Por qué importa:** La recuperación de una cartera determinista depende de conservar la semilla o las claves necesarias. Una copia no verificada puede fallar solo cuando ya no exista el dispositivo.
- **Mitigaciones:** [Mantén copias verificadas entre límites de fallo](#mitigation-redundant-offline-backups), [Ensaya la recuperación antes de una emergencia](#mitigation-rehearse-recovery)
- **Pruebas esperadas:** [Pruebas de las copias](#evidence-backup-check), [Pruebas de recuperación](#evidence-recovery-rehearsal)
- **Riesgos residuales:** [Disponibilidad y secreto siguen en tensión](#residual-backup), [Un ensayo pasado no garantiza una recuperación futura](#residual-recovery)
#### Una copia expone secretos de firma
- **ID:** `threat-backup-secret-exposure`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Las palabras de recuperación, claves privadas o contraseñas adicionales aparecen en una foto, nube, ordenador común, nota compartida o lugar accesible para otra persona.
- **Por qué importa:** Una semilla determinista puede derivar las claves privadas de la cartera. La redundancia mejora la disponibilidad, pero crea más copias que deben protegerse.
- **Mitigaciones:** [Separa los secretos de las instrucciones y entre sí](#mitigation-separate-secret-material), [Mantén copias verificadas entre límites de fallo](#mitigation-redundant-offline-backups)
- **Pruebas esperadas:** [Pruebas de las copias](#evidence-backup-check)
- **Riesgos residuales:** [Disponibilidad y secreto siguen en tensión](#residual-backup)
### Preparación para la recuperación
Si las claves, el contexto de la cartera, las herramientas y el procedimiento pueden restaurar la cartera antes de una emergencia.
#### El procedimiento de recuperación no se ha ensayado
- **ID:** `threat-recovery-not-rehearsed`
- **Lenguaje de prioridad:** `important`
- **Escenario:** Al perder o romperse el dispositivo, el operador descubre una palabra incorrecta, una contraseña olvidada, una cartera incompatible, un firmante ausente o un procedimiento que no puede completar.
- **Por qué importa:** Tener una copia no demuestra que pueda reconstruirse la cartera completa. Un ensayo controlado puede revelar fallos de procedimiento y compatibilidad antes de depender de la recuperación.
- **Mitigaciones:** [Ensaya la recuperación antes de una emergencia](#mitigation-rehearse-recovery), [Conserva el contexto no secreto de la cartera](#mitigation-preserve-wallet-context)
- **Pruebas esperadas:** [Pruebas de recuperación](#evidence-recovery-rehearsal)
- **Riesgos residuales:** [Un ensayo pasado no garantiza una recuperación futura](#residual-recovery)
#### Las claves sobreviven, pero falta el contexto de la cartera
- **ID:** `threat-recovery-wallet-context-missing`
- **Lenguaje de prioridad:** `important`
- **Escenario:** La recuperación conserva la semilla o las claves, pero no el tipo de script, la ruta de derivación, el descriptor, la política de quórum, las claves de cofirmantes o el coordinador necesarios.
- **Por qué importa:** BIP 380 explica por qué las claves privadas por sí solas pueden no bastar para reconstruir los scripts y rutas usados, sobre todo con políticas no predeterminadas o multifirma.
- **Mitigaciones:** [Conserva el contexto no secreto de la cartera](#mitigation-preserve-wallet-context), [Ensaya la recuperación antes de una emergencia](#mitigation-rehearse-recovery)
- **Pruebas esperadas:** [Pruebas de recuperación](#evidence-recovery-rehearsal)
- **Riesgos residuales:** [Un ensayo pasado no garantiza una recuperación futura](#residual-recovery), [Disponibilidad y secreto siguen en tensión](#residual-backup)
### Protección de acceso
Cómo resisten la apropiación o el compromiso las cuentas de proveedores, los dispositivos, el software y las interfaces de firma.
#### Una cuenta de proveedor es apropiada por un atacante
- **ID:** `threat-access-provider-account-takeover`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Phishing, reutilización de contraseñas, robo de sesión, recuperación débil o correo comprometido permiten controlar una plataforma, cartera alojada, copia en la nube o cuenta de comunicación.
- **Por qué importa:** Los controles de cuenta pueden formar parte de la custodia, la confidencialidad de las copias o la continuidad. Según NIST, los códigos de un solo uso introducidos manualmente no resisten el phishing.
- **Mitigaciones:** [Usa acceso resistente al phishing cuando esté disponible](#mitigation-phishing-resistant-access), [Documenta el límite de custodia](#mitigation-define-custody-boundary)
- **Pruebas esperadas:** [Pruebas de control de acceso](#evidence-access-controls), [Pruebas del límite de custodia](#evidence-custody-boundary)
- **Riesgos residuales:** [Un acceso fuerte no protege todas las dependencias](#residual-access), [Siguen existiendo dependencias de custodia](#residual-custody)
#### El entorno de firma está comprometido
- **ID:** `threat-access-signing-environment-compromise`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Malware, una actualización maliciosa, acceso remoto, una aplicación falsa o un dispositivo modificado intentan exponer claves o alterar datos de transacciones.
- **Por qué importa:** Separar la firma del equipo conectado reduce oportunidades de extraer claves, pero el firmante, el canal de transferencia, el firmware y la revisión siguen siendo límites de confianza.
- **Mitigaciones:** [Reduce la confianza en el entorno conectado de firma](#mitigation-harden-signing-environment), [Aísla suficiente autoridad de firma](#mitigation-isolate-signing-keys), [Verifica la intención en una pantalla independiente](#mitigation-verify-on-trusted-display)
- **Pruebas esperadas:** [Pruebas de control de acceso](#evidence-access-controls), [Pruebas de verificación de transacciones](#evidence-transaction-verification)
- **Riesgos residuales:** [Un acceso fuerte no protege todas las dependencias](#residual-access), [La verificación aún puede fallar en la persona o la pantalla](#residual-transaction)
### Verificación de transacciones
Si el firmante puede confirmar de forma independiente qué autoriza antes de que una transacción sea irreversible.
#### Se sustituye el destino o el importe
- **ID:** `threat-transaction-destination-substitution`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Un equipo, portapapeles, código QR, solicitud de pago o coordinador comprometido presenta datos distintos de la intención del operador.
- **Por qué importa:** Una firma válida autoriza la transacción realmente presentada. La revisión independiente debe abarcar destino, importe, comisión y cambio mediante un canal o pantalla de confianza.
- **Mitigaciones:** [Verifica la intención en una pantalla independiente](#mitigation-verify-on-trusted-display), [Separa creación, firma y difusión cuando sea útil](#mitigation-separate-transaction-roles)
- **Pruebas esperadas:** [Pruebas de verificación de transacciones](#evidence-transaction-verification)
- **Riesgos residuales:** [La verificación aún puede fallar en la persona o la pantalla](#residual-transaction)
#### El firmante no tiene contexto suficiente para verificar el gasto
- **ID:** `threat-transaction-incomplete-signing-context`
- **Lenguaje de prioridad:** `important`
- **Escenario:** El dispositivo o la persona que firma no puede identificar con fiabilidad entradas, cambio, comisiones, política de la cartera o modificaciones de otro sistema.
- **Por qué importa:** PSBT normaliza el intercambio de datos entre funciones, pero el formato por sí solo no demuestra que el firmante haya mostrado o comprobado todos los campos relevantes.
- **Mitigaciones:** [Separa creación, firma y difusión cuando sea útil](#mitigation-separate-transaction-roles), [Verifica la intención en una pantalla independiente](#mitigation-verify-on-trusted-display)
- **Pruebas esperadas:** [Pruebas de verificación de transacciones](#evidence-transaction-verification)
- **Riesgos residuales:** [La verificación aún puede fallar en la persona o la pantalla](#residual-transaction)
### Continuidad y sucesión
Si un sucesor autorizado puede localizar la información no secreta adecuada y seguir un proceso probado sin reunir todos los secretos.
#### El único operador informado no está disponible
- **ID:** `threat-continuity-operator-unavailability`
- **Lenguaje de prioridad:** `important`
- **Escenario:** Fallecimiento, incapacidad, viaje, coacción, conflicto o pérdida de contacto impiden que los sucesores autorizados localicen la cartera o entiendan la recuperación.
- **Por qué importa:** El material técnico no comunica autoridad legal, funciones, ubicaciones, dependencias ni orden de actuación. La continuidad exige procedimientos documentados y ensayados.
- **Mitigaciones:** [Documenta funciones, dependencias y lugares sin anotar secretos](#mitigation-document-continuity-roles), [Ensaya el traspaso de continuidad](#mitigation-rehearse-continuity)
- **Pruebas esperadas:** [Pruebas de continuidad](#evidence-continuity-rehearsal)
- **Riesgos residuales:** [La sucesión combina incertidumbre técnica y legal](#residual-continuity), [Un ensayo pasado no garantiza una recuperación futura](#residual-recovery)
#### Un documento de continuidad concentra todos los secretos
- **ID:** `threat-continuity-secret-concentration`
- **Lenguaje de prioridad:** `high`
- **Escenario:** Un documento, caja fuerte, abogado, familiar o cuenta digital contiene material e instrucciones suficientes para gastar sin otro control independiente.
- **Por qué importa:** La continuidad puede mejorar la disponibilidad y debilitar la confidencialidad. Un traspaso útil explica funciones y ubicaciones sin convertir un único registro en autoridad completa de gasto.
- **Mitigaciones:** [Documenta funciones, dependencias y lugares sin anotar secretos](#mitigation-document-continuity-roles), [Separa los secretos de las instrucciones y entre sí](#mitigation-separate-secret-material), [Ensaya el traspaso de continuidad](#mitigation-rehearse-continuity)
- **Pruebas esperadas:** [Pruebas de continuidad](#evidence-continuity-rehearsal), [Pruebas de las copias](#evidence-backup-check)
- **Riesgos residuales:** [La sucesión combina incertidumbre técnica y legal](#residual-continuity), [Disponibilidad y secreto siguen en tensión](#residual-backup)
## Mitigaciones
### Documenta el límite de custodia
- **ID:** `mitigation-define-custody-boundary`
- **Acción:** Identifica cada persona, proveedor, dispositivo, clave, política y proceso que puede autorizar o bloquear un gasto. Decide qué dependencias son aceptables antes de mover fondos importantes.
- **Limitación:** La documentación hace visibles las dependencias; no elimina riesgos del proveedor, legales, de solvencia o de implementación.
### Aísla suficiente autoridad de firma
- **ID:** `mitigation-isolate-signing-keys`
- **Acción:** Mantén las claves privadas fuera de dispositivos conectados cuando el modelo lo permita. En carteras con quórum, separa firmantes para que un solo compromiso no cumpla la política.
- **Limitación:** El aislamiento añade pasos de transferencia, actualización, verificación y recuperación. No demuestra que el firmante o el firmware sean fiables.
### Mantén copias verificadas entre límites de fallo
- **ID:** `mitigation-redundant-offline-backups`
- **Acción:** Guarda el material necesario en más de un lugar protegido cuando el escenario lo justifique. Comprueba legibilidad, integridad y acceso sin exponer el secreto en línea.
- **Limitación:** Cada copia adicional amplía el problema de confidencialidad y control de acceso. La separación geográfica también puede complicar la recuperación.
### Separa los secretos de las instrucciones y entre sí
- **ID:** `mitigation-separate-secret-material`
- **Acción:** No pongas semilla, contraseña adicional, PIN y procedimiento completo en un único documento o cuenta en línea. Usa límites de acceso distintos acordes con la política.
- **Limitación:** La separación puede provocar bloqueo si no se documentan las dependencias o si una persona autorizada no puede reunir las partes necesarias.
### Ensaya la recuperación antes de una emergencia
- **ID:** `mitigation-rehearse-recovery`
- **Acción:** Usa un procedimiento controlado, un dispositivo de repuesto o reiniciado y una cartera de prueba sin valor cuando corresponda. Confirma cartera, política, direcciones y firma sin introducir secretos en un equipo no fiable.
- **Limitación:** Un ensayo solo prueba la vía comprobada en ese momento. El software, los dispositivos, las personas, los lugares y la documentación pueden cambiar.
### Conserva el contexto no secreto de la cartera
- **ID:** `mitigation-preserve-wallet-context`
- **Acción:** Registra tipo de cartera, política de script, derivación, huellas maestras, quórum, requisitos del coordinador y software probado sin reunirlos con todos los secretos.
- **Limitación:** Los descriptores y claves públicas extendidas pueden exponer direcciones e historial. Trátalos como información sensible aunque no permitan gastar por sí solos.
### Usa acceso resistente al phishing cuando esté disponible
- **ID:** `mitigation-phishing-resistant-access`
- **Acción:** Protege cuentas de proveedor, correo y nube con credenciales únicas y un autenticador criptográfico vinculado al dominio real cuando sea compatible. Revisa también las vías de recuperación.
- **Limitación:** La autenticación fuerte no resuelve insolvencia, empleados maliciosos, equipos comprometidos ni procesos de retiro defectuosos.
### Reduce la confianza en el entorno conectado de firma
- **ID:** `mitigation-harden-signing-environment`
- **Acción:** Usa software mantenido de fuentes autenticadas, limita acceso remoto y aplicaciones innecesarias, aísla claves cuando proceda y conserva una vía independiente para verificar la intención.
- **Limitación:** El endurecimiento reduce la exposición, pero no demuestra que todas las dependencias, actualizaciones, bibliotecas o dispositivos estén libres de fallos.
### Verifica la intención en una pantalla independiente
- **ID:** `mitigation-verify-on-trusted-display`
- **Acción:** Antes de firmar, compara destinatario, importe, comisión, cambio, red y política con la intención original en un firmante o canal que no dependa solo del equipo creador.
- **Limitación:** Una pantalla puede omitir campos, mostrar datos confusos o estar comprometida. La verificación depende de la referencia independiente y de la revisión del operador.
### Separa creación, firma y difusión cuando sea útil
- **ID:** `mitigation-separate-transaction-roles`
- **Acción:** Usa un formato estándar como PSBT cuando cooperen varios sistemas o firmantes. Exige que cada firmante valide la política y los campos relevantes antes de firmar.
- **Limitación:** Separar funciones aumenta coordinación y tratamiento de metadatos. PSBT puede contener información sensible y no obliga al dispositivo a mostrar cada campo relevante.
### Documenta funciones, dependencias y lugares sin anotar secretos
- **ID:** `mitigation-document-continuity-roles`
- **Acción:** Registra quién debe actuar, qué documentos no secretos existen, dónde están los materiales separados, qué profesionales o proveedores intervienen y cómo se verifica la autoridad. Mantén los secretos fuera.
- **Limitación:** La documentación operativa no es un plan sucesorio y puede no crear autoridad legal. El asesoramiento jurídico y fiscal depende de la jurisdicción.
### Ensaya el traspaso de continuidad
- **ID:** `mitigation-rehearse-continuity`
- **Acción:** Haz que una persona autorizada explique o simule el proceso con documentos no secretos. Confirma contactos, lugares, dependencias, destino de dispositivos y vías de escalado con fecha.
- **Limitación:** Un ensayo puede exponer relaciones sensibles y quedar obsoleto tras cambios familiares, legales, de proveedor, dispositivo o cartera.
## Pruebas esperadas
### Pruebas del límite de custodia
Un inventario actualizado de firmantes, proveedores, políticas, vías de recuperación y dependencias que pueden bloquear. El marketing por sí solo no demuestra control.
### Pruebas de las copias
Una comprobación fechada de que el material existe, sigue legible, está separado según los límites previstos y no se ha introducido en un sistema no fiable.
### Pruebas de recuperación
Un registro fechado de la vía probada, identificación de cartera, herramientas, política reconstruida, problemas y correcciones. No debe contener el secreto.
### Pruebas de control de acceso
Métodos documentados de recuperación de cuentas, tipo de autenticador, procedencia de dispositivos y software, proceso de actualización y eliminación de accesos antiguos.
### Pruebas de verificación de transacciones
Un procedimiento repetible que identifica qué campos revisa cada firmante, la fuente independiente de la intención, la validación de la política y cuándo se permite difundir.
### Pruebas de continuidad
Un inventario fechado y no secreto de funciones y lugares, responsable de cada seguimiento, registro del ensayo y revisión tras cambios familiares, legales, de proveedor o cartera.
## Riesgos residuales
### Siguen existiendo dependencias de custodia
Claves, dispositivos, personas, proveedores y políticas pueden fallar juntos o actuar de forma distinta a la documentación. Más independencia suele añadir complejidad.
### Disponibilidad y secreto siguen en tensión
Más copias pueden sobrevivir a más pérdidas, pero crean más oportunidades de descubrimiento, coacción, mal manejo o registros obsoletos.
### Un ensayo pasado no garantiza una recuperación futura
Dispositivos, compatibilidad, personas, memoria, documentación y estado de la cartera pueden cambiar después de una prueba correcta.
### Un acceso fuerte no protege todas las dependencias
Equipos, soporte, personal del servicio, firmware, acceso físico y cadena de suministro del software siguen siendo posibles vías de fallo.
### La verificación aún puede fallar en la persona o la pantalla
Un firmante puede omitir información importante, la referencia puede estar comprometida o el operador puede aprobar datos confusos o inesperados.
### La sucesión combina incertidumbre técnica y legal
Un traspaso técnicamente correcto puede entrar en conflicto con la ley, los impuestos, la familia, las reglas del proveedor o la voluntad actual del propietario.
## Exclusiones
- **Riesgo de mercado y precio:** El modelo no predice precio, liquidez, tratamiento fiscal ni la conveniencia de mantener bitcoin.
- **Consenso y seguridad de la red Bitcoin:** Los fallos de consenso, ataques de minería, defectos del protocolo y particiones de red quedan fuera de este modelo operativo.
- **Certificación o clasificación de productos:** El modelo no certifica carteras físicas o de software, plataformas, custodios, servicios multifirma ni proveedores de recuperación.
- **Determinación de riesgo personalizada:** Ninguna prioridad tiene en cuenta el saldo, habilidades, adversarios, ubicación, familia o frecuencia de uso del lector.
- **Asesoramiento jurídico, fiscal y sucesorio:** Los controles de continuidad solo describen operaciones. No crean autoridad legal ni sustituyen asesoramiento cualificado en la jurisdicción correspondiente.
## Fuentes
- [NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments](https://doi.org/10.6028/NIST.SP.800-30r1) — National Institute of Standards and Technology. Se usa para alcance, supuestos, fuentes de amenaza, incertidumbre y revisión. BitcoinSafe no copia las escalas de probabilidad de NIST.
- [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) — OWASP Foundation. Se usa para la secuencia de alcance, identificación, respuesta y revisión, y para documentar mitigaciones prácticas.
- [Bitcoin Developer Guide: Wallets](https://developer.bitcoin.org/devguide/wallets.html) — Bitcoin Developer Documentation. Se usa para separar distribución de claves, firma y red, y para explicar la función de las claves privadas en el gasto.
- [BIP 32: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) — Bitcoin Improvement Proposals. Se usa para la derivación determinista y las consecuencias de exponer o perder el material raíz.
- [BIP 39: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) — Bitcoin Improvement Proposals. Se usa solo para describir material mnemónico y contraseña adicional. El modelo no afirma que BIP 39 sea obligatorio para toda cartera.
- [BIP 174: Partially Signed Bitcoin Transaction Format](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) — Bitcoin Improvement Proposals. Se usa para separar funciones de transacción, firma sin conexión, datos del firmante y límites de metadatos PSBT.
- [BIP 380: Output Script Descriptors General Operation](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) — Bitcoin Improvement Proposals. Se usa para explicar la importancia del tipo de script, rutas, claves y suma de comprobación del descriptor además de las claves privadas.
- [Bitcoin Core Offline Signing Tutorial](https://github.com/bitcoin/bitcoin/blob/master/doc/offline-signing-tutorial.md) — Bitcoin Core. Se usa para el objetivo de seguridad y el límite operativo documentados de la firma PSBT sin conexión.
- [Bitcoin Core External Signer Documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/external-signer.md) — Bitcoin Core. Se usa para comprobaciones de identidad del firmante externo, coincidencia de descriptores y visualización de direcciones.
- [NIST SP 800-63B-4: Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html) — National Institute of Standards and Technology. Se usa para resistencia al phishing, vinculación al verificador, controles de autenticadores y límites de códigos introducidos manualmente.
- [#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) — Cybersecurity and Infrastructure Security Agency. Se usa para la práctica general de copias sin conexión y pruebas periódicas de restauración. La recuperación de Bitcoin añade requisitos de secreto.
- [NIST SP 800-34 Rev. 1: Contingency Planning Guide](https://doi.org/10.6028/NIST.SP.800-34r1) — National Institute of Standards and Technology. Se usa para funciones, recuperación, pruebas, validación, material externo y registros fechados. Es una guía general, no asesoramiento específico de Bitcoin.
- [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) — Creative Commons. Define las condiciones de reutilización del texto y los datos de investigación incluidos.
- [Semantic Versioning 2.0.0](https://semver.org/) — Semantic Versioning. Define la versión inmutable y las reglas de versiones mayores, menores y de parche usadas por el modelo.
## Historial de versiones
- **1.0.0 (2026-08-28):** Primera versión pública con seis categorías, 12 amenazas, 12 mitigaciones, pruebas esperadas, riesgos residuales, correspondencias con la evaluación y recursos traducidos.
## Cita y reutilización
BitcoinSafe, "Modelo abierto de amenazas para la custodia de Bitcoin de BitcoinSafe," version 1.0.0, 2026-08-28, https://www.bitcoinsafe.com/es/research/bitcoin-threat-model/1.0.0.
El texto, la taxonomía, los datos de relaciones y los archivos de investigación generados del modelo se publican con licencia CC BY 4.0. El código de la aplicación y el resto del sitio quedan fuera de este aviso.
- [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
- [CITATION.cff](/research/bitcoin-threat-model/1.0.0/CITATION.cff)
- [Repository source](https://github.com/kevinkinnett/bitcoinsafe/tree/main/public/research/bitcoin-threat-model/1.0.0)
- [Corrections](https://github.com/kevinkinnett/bitcoinsafe/issues)