# Modèle ouvert des menaces de garde Bitcoin de BitcoinSafe
Un cadre public pour examiner comment des erreurs opérationnelles ou des attaques peuvent entraîner une dépense non autorisée, une perte de capacité de récupération, une atteinte à la vie privée ou une rupture de continuité. Chaque menace est reliée à des mesures, des preuves attendues et un risque restant.
- **Version:** 1.0.0
- **Publié:** 2026-08-28
- **Dernière révision:** 2026-08-28
## Public
Personnes qui gèrent leur propre garde Bitcoin, formateurs en auto-garde et développeurs qui ont besoin d’identifiants publics stables. Le modèle n’est pas adapté à une personne, un montant, une juridiction ou un adversaire précis.
## Méthode
Le modèle suit une séquence périmètre, menace, réponse et révision. Les priorités indiquent dans quelle mesure une condition peut mener directement à une perte ; elles n’estiment pas une probabilité. Les mesures réduisent des scénarios précis sans jamais certifier qu’un portefeuille ou un dispositif est sûr.
### Limite de certification
Cette publication est un cadre de raisonnement, pas une note de sécurité, un audit, une garantie, une recommandation de produit ni une certification. La documentation publique peut être incomplète, les mises en œuvre peuvent comporter des défauts et des mesures bien appliquées laissent toujours un risque résiduel.
## Hypothèses
### Le pouvoir de dépense dépend des clés et de la politique valides
Une partie capable de satisfaire la politique du portefeuille peut autoriser une dépense. La perte de toutes les voies de récupération valides peut rendre les fonds inaccessibles même si le réseau Bitcoin continue de fonctionner.
### Les appareils et services généralistes peuvent tomber en panne ou être compromis
Les téléphones, ordinateurs, sessions de navigateur, comptes en ligne, plateformes, coordinateurs et canaux de communication sont considérés comme faillibles, pas fiables par défaut.
### L’erreur humaine fait partie de l’environnement opérationnel
Le modèle inclut les erreurs de sauvegarde, récupération, vérification des transactions, contrôle des accès, documentation et transmission. Il ne suppose pas un opérateur parfaitement formé.
### Seules des preuves vérifiables étayent une affirmation publiée
Une mesure n’est décrite qu’au niveau étayé par des spécifications publiques, la documentation du fournisseur, des éléments reproductibles ou une révision identifiée. L’absence de problème publié ne prouve pas la sécurité.
## Actifs protégés
- **Pouvoir de dépense** (`asset-spending-authority`): Clés privées, appareils de signature, phrases secrètes supplémentaires, politiques et éléments de quorum capables d’autoriser une transaction.
- **Capacité de récupération** (`asset-recovery-capability`): Sauvegardes, métadonnées du portefeuille, informations de dérivation, consignes et procédures testées nécessaires pour rétablir l’accès.
- **Intention de transaction** (`asset-transaction-intent`): Le destinataire, le montant, les frais, la monnaie rendue, les entrées et la politique de signature prévus.
- **Vie privée et métadonnées du portefeuille** (`asset-privacy-metadata`): Adresses, clés publiques étendues, soldes, historique des transactions, contreparties et liens de propriété.
- **Continuité opérationnelle** (`asset-operational-continuity`): La capacité d’une personne autorisée à comprendre, maintenir, récupérer et transmettre le dispositif dans le temps.
## Niveaux de priorité
- **Attention élevée** (`high`): La condition décrite peut directement permettre une dépense non autorisée ou une perte définitive d’accès. Cette mention n’estime pas la probabilité de l’événement.
- **Important** (`important`): La condition peut bloquer la récupération, affaiblir la vérification ou rendre un autre incident nettement plus difficile à contenir.
- **Selon le contexte** (`contextual`): La conséquence dépend fortement du modèle de garde, de la valeur exposée, de l’adversaire, de la juridiction ou de la fréquence d’utilisation. Une décision explicite reste nécessaire.
## Catégories de menaces et relations
### Autorité de garde
Qui peut autoriser une dépense et quelles parties ou quels éléments doivent rester disponibles et honnêtes.
#### Un prestataire contrôle le retrait ou la signature
- **ID:** `threat-custody-provider-control`
- **Niveaux de priorité:** `high`
- **Scénario:** Une plateforme, un dépositaire, un portefeuille hébergé ou un service de politique peut retarder, refuser, détourner ou perdre la capacité d’autoriser un retrait.
- **Pourquoi cela compte:** L’opérateur ne détient pas toutes les clés nécessaires. La solvabilité, les contrôles de compte, les règles, la juridiction et la disponibilité du prestataire font partie du périmètre de garde.
- **Mesures:** [Documentez le périmètre de garde](#mitigation-define-custody-boundary), [Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible](#mitigation-phishing-resistant-access)
- **Preuves attendues:** [Preuves du périmètre de garde](#evidence-custody-boundary), [Preuves de contrôle d’accès](#evidence-access-controls)
- **Risques résiduels:** [Des dépendances de garde subsistent](#residual-custody), [Des accès renforcés ne sécurisent pas toutes les dépendances](#residual-access)
#### Une autorité de signature suffisante est volée ou copiée
- **ID:** `threat-custody-signer-compromise`
- **Niveaux de priorité:** `high`
- **Scénario:** Un attaquant obtient une clé privée, une phrase de récupération, une phrase secrète, un appareil de signature ou suffisamment d’éléments pour satisfaire la politique.
- **Pourquoi cela compte:** Bitcoin valide l’autorisation, pas l’identité ni l’intention de la personne qui présente une signature valide. La séparation n’aide que tant que le seuil de la politique n’est pas compromis.
- **Mesures:** [Isolez une autorité de signature suffisante](#mitigation-isolate-signing-keys), [Séparez les secrets des consignes et les uns des autres](#mitigation-separate-secret-material)
- **Preuves attendues:** [Preuves du périmètre de garde](#evidence-custody-boundary), [Preuves de sauvegarde](#evidence-backup-check)
- **Risques résiduels:** [Des dépendances de garde subsistent](#residual-custody), [Disponibilité et secret restent en tension](#residual-backup)
### Résilience des sauvegardes
Si le matériel de récupération survit à une perte tout en restant inaccessible aux personnes non autorisées.
#### Le matériel de récupération manque ou devient illisible
- **ID:** `threat-backup-unavailable`
- **Niveaux de priorité:** `high`
- **Scénario:** Perte, incendie, eau, corrosion, mise au rebut accidentelle, oubli ou lieu unique commun suppriment toutes les sauvegardes utilisables.
- **Pourquoi cela compte:** La récupération d’un portefeuille déterministe dépend de la conservation de la graine ou des clés nécessaires. Une sauvegarde non vérifiée peut échouer seulement après la perte de l’appareil.
- **Mesures:** [Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance](#mitigation-redundant-offline-backups), [Répétez la récupération avant une urgence](#mitigation-rehearse-recovery)
- **Preuves attendues:** [Preuves de sauvegarde](#evidence-backup-check), [Preuves de récupération](#evidence-recovery-rehearsal)
- **Risques résiduels:** [Disponibilité et secret restent en tension](#residual-backup), [Une ancienne répétition ne garantit pas une récupération future](#residual-recovery)
#### Une sauvegarde expose des secrets de signature
- **ID:** `threat-backup-secret-exposure`
- **Niveaux de priorité:** `high`
- **Scénario:** Des mots de récupération, clés privées ou phrases secrètes se retrouvent dans une photo, un document en ligne, un ordinateur ordinaire, une note partagée ou un lieu accessible à un tiers.
- **Pourquoi cela compte:** Une graine déterministe peut dériver les clés privées du portefeuille. La redondance améliore la disponibilité mais crée davantage de copies à protéger.
- **Mesures:** [Séparez les secrets des consignes et les uns des autres](#mitigation-separate-secret-material), [Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance](#mitigation-redundant-offline-backups)
- **Preuves attendues:** [Preuves de sauvegarde](#evidence-backup-check)
- **Risques résiduels:** [Disponibilité et secret restent en tension](#residual-backup)
### Préparation à la récupération
Si les clés, le contexte du portefeuille, les outils et la procédure permettent de restaurer le portefeuille avant une urgence.
#### La procédure de récupération n’a pas été répétée
- **ID:** `threat-recovery-not-rehearsed`
- **Niveaux de priorité:** `important`
- **Scénario:** Après la perte ou la panne d’un appareil, l’opérateur découvre un mot erroné, une phrase secrète oubliée, un portefeuille incompatible, un signataire absent ou une procédure impossible à terminer.
- **Pourquoi cela compte:** Posséder une sauvegarde ne prouve pas que le portefeuille complet peut être reconstruit. Une répétition contrôlée peut révéler les défauts de procédure et de compatibilité avant une urgence.
- **Mesures:** [Répétez la récupération avant une urgence](#mitigation-rehearse-recovery), [Conservez le contexte non secret du portefeuille](#mitigation-preserve-wallet-context)
- **Preuves attendues:** [Preuves de récupération](#evidence-recovery-rehearsal)
- **Risques résiduels:** [Une ancienne répétition ne garantit pas une récupération future](#residual-recovery)
#### Les clés subsistent mais le contexte du portefeuille manque
- **ID:** `threat-recovery-wallet-context-missing`
- **Niveaux de priorité:** `important`
- **Scénario:** La récupération conserve la graine ou les clés mais pas le type de script, le chemin de dérivation, le descripteur, la politique de quorum, les clés des cosignataires ou le coordinateur nécessaires.
- **Pourquoi cela compte:** Le BIP 380 explique pourquoi les clés privées seules peuvent ne pas suffire à reconstruire les scripts et chemins utilisés, notamment pour des politiques non standard ou multisignatures.
- **Mesures:** [Conservez le contexte non secret du portefeuille](#mitigation-preserve-wallet-context), [Répétez la récupération avant une urgence](#mitigation-rehearse-recovery)
- **Preuves attendues:** [Preuves de récupération](#evidence-recovery-rehearsal)
- **Risques résiduels:** [Une ancienne répétition ne garantit pas une récupération future](#residual-recovery), [Disponibilité et secret restent en tension](#residual-backup)
### Protection des accès
Comment les comptes de prestataires, appareils, logiciels et interfaces de signature résistent à la prise de contrôle ou à la compromission.
#### Un compte de prestataire est pris en contrôle
- **ID:** `threat-access-provider-account-takeover`
- **Niveaux de priorité:** `high`
- **Scénario:** Hameçonnage, réutilisation de mot de passe, vol de session, récupération faible ou messagerie compromise permettent de contrôler une plateforme, un portefeuille hébergé, une sauvegarde en ligne ou un compte de communication.
- **Pourquoi cela compte:** Les contrôles de compte peuvent faire partie de la garde, de la confidentialité des sauvegardes ou de la continuité. Selon le NIST, les codes à usage unique saisis manuellement ne résistent pas à l’hameçonnage.
- **Mesures:** [Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible](#mitigation-phishing-resistant-access), [Documentez le périmètre de garde](#mitigation-define-custody-boundary)
- **Preuves attendues:** [Preuves de contrôle d’accès](#evidence-access-controls), [Preuves du périmètre de garde](#evidence-custody-boundary)
- **Risques résiduels:** [Des accès renforcés ne sécurisent pas toutes les dépendances](#residual-access), [Des dépendances de garde subsistent](#residual-custody)
#### L’environnement de signature est compromis
- **ID:** `threat-access-signing-environment-compromise`
- **Niveaux de priorité:** `high`
- **Scénario:** Un logiciel malveillant, une mise à jour hostile, un accès à distance, une fausse application ou un appareil modifié tente d’exposer les clés ou de changer les données de transaction.
- **Pourquoi cela compte:** Séparer la signature de l’ordinateur connecté réduit les possibilités d’exfiltration des clés, mais le signataire, le canal de transfert, le micrologiciel et la vérification restent des limites de confiance.
- **Mesures:** [Réduisez la confiance accordée à l’environnement de signature connecté](#mitigation-harden-signing-environment), [Isolez une autorité de signature suffisante](#mitigation-isolate-signing-keys), [Vérifiez l’intention sur un écran indépendant](#mitigation-verify-on-trusted-display)
- **Preuves attendues:** [Preuves de contrôle d’accès](#evidence-access-controls), [Preuves de vérification des transactions](#evidence-transaction-verification)
- **Risques résiduels:** [Des accès renforcés ne sécurisent pas toutes les dépendances](#residual-access), [La vérification peut encore échouer au niveau humain ou de l’écran](#residual-transaction)
### Vérification des transactions
Si le signataire peut confirmer indépendamment ce qui sera autorisé avant qu’une transaction ne devienne irréversible.
#### La destination ou le montant est remplacé
- **ID:** `threat-transaction-destination-substitution`
- **Niveaux de priorité:** `high`
- **Scénario:** Un ordinateur, presse-papiers, code QR, ordre de paiement ou coordinateur compromis présente des données différentes de l’intention de l’opérateur.
- **Pourquoi cela compte:** Une signature valide autorise la transaction réellement présentée. La vérification indépendante doit couvrir destination, montant, frais et monnaie rendue sur un canal ou écran fiable.
- **Mesures:** [Vérifiez l’intention sur un écran indépendant](#mitigation-verify-on-trusted-display), [Séparez création, signature et diffusion lorsque c’est utile](#mitigation-separate-transaction-roles)
- **Preuves attendues:** [Preuves de vérification des transactions](#evidence-transaction-verification)
- **Risques résiduels:** [La vérification peut encore échouer au niveau humain ou de l’écran](#residual-transaction)
#### Le signataire manque de contexte pour vérifier la dépense
- **ID:** `threat-transaction-incomplete-signing-context`
- **Niveaux de priorité:** `important`
- **Scénario:** L’appareil ou la personne qui signe ne peut pas identifier de manière fiable les entrées, la monnaie rendue, les frais, la politique du portefeuille ou les modifications apportées par un autre système.
- **Pourquoi cela compte:** Le PSBT normalise l’échange de données entre rôles, mais le format seul ne prouve pas que le signataire a affiché ou vérifié tous les champs utiles.
- **Mesures:** [Séparez création, signature et diffusion lorsque c’est utile](#mitigation-separate-transaction-roles), [Vérifiez l’intention sur un écran indépendant](#mitigation-verify-on-trusted-display)
- **Preuves attendues:** [Preuves de vérification des transactions](#evidence-transaction-verification)
- **Risques résiduels:** [La vérification peut encore échouer au niveau humain ou de l’écran](#residual-transaction)
### Continuité et transmission
Si un successeur autorisé peut trouver les bonnes informations non secrètes et suivre un processus testé sans réunir tous les secrets.
#### Le seul opérateur informé n’est plus disponible
- **ID:** `threat-continuity-operator-unavailability`
- **Niveaux de priorité:** `important`
- **Scénario:** Décès, incapacité, voyage, contrainte, conflit ou perte de contact empêchent les successeurs autorisés de localiser le portefeuille ou de comprendre la récupération.
- **Pourquoi cela compte:** Le matériel technique ne communique pas l’autorité juridique, les rôles, les lieux, les dépendances ni l’ordre des opérations. La continuité exige des procédures documentées et répétées.
- **Mesures:** [Documentez rôles, dépendances et lieux sans inscrire les secrets](#mitigation-document-continuity-roles), [Répétez la transmission de continuité](#mitigation-rehearse-continuity)
- **Preuves attendues:** [Preuves de continuité](#evidence-continuity-rehearsal)
- **Risques résiduels:** [La transmission combine incertitudes techniques et juridiques](#residual-continuity), [Une ancienne répétition ne garantit pas une récupération future](#residual-recovery)
#### Un document de continuité concentre tous les secrets
- **ID:** `threat-continuity-secret-concentration`
- **Niveaux de priorité:** `high`
- **Scénario:** Un document, coffre, avocat, proche ou compte numérique contient assez de matériel et de consignes pour dépenser sans autre contrôle indépendant.
- **Pourquoi cela compte:** La continuité peut améliorer la disponibilité tout en affaiblissant la confidentialité. Une transmission utile explique les rôles et les lieux sans transformer un seul document en pouvoir de dépense complet.
- **Mesures:** [Documentez rôles, dépendances et lieux sans inscrire les secrets](#mitigation-document-continuity-roles), [Séparez les secrets des consignes et les uns des autres](#mitigation-separate-secret-material), [Répétez la transmission de continuité](#mitigation-rehearse-continuity)
- **Preuves attendues:** [Preuves de continuité](#evidence-continuity-rehearsal), [Preuves de sauvegarde](#evidence-backup-check)
- **Risques résiduels:** [La transmission combine incertitudes techniques et juridiques](#residual-continuity), [Disponibilité et secret restent en tension](#residual-backup)
## Mesures
### Documentez le périmètre de garde
- **ID:** `mitigation-define-custody-boundary`
- **Action:** Identifiez chaque personne, prestataire, appareil, clé, politique et procédure capable d’autoriser ou de bloquer une dépense. Décidez quelles dépendances sont acceptables avant de déplacer des fonds importants.
- **Limite:** La documentation rend les dépendances visibles ; elle ne supprime pas les risques liés au prestataire, au droit, à la solvabilité ou à la mise en œuvre.
### Isolez une autorité de signature suffisante
- **ID:** `mitigation-isolate-signing-keys`
- **Action:** Gardez les clés privées à l’écart des appareils ordinaires connectés lorsque le modèle le permet. Pour un quorum, séparez les signataires afin qu’une seule compromission ne satisfasse pas la politique.
- **Limite:** L’isolation ajoute des étapes de transfert, mise à jour, vérification et récupération. Elle ne prouve pas que le signataire ou le micrologiciel est fiable.
### Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance
- **ID:** `mitigation-redundant-offline-backups`
- **Action:** Conservez le matériel nécessaire dans plusieurs lieux protégés lorsque le scénario le justifie. Vérifiez lisibilité, intégrité et accès sans exposer le secret à un système en ligne.
- **Limite:** Chaque copie supplémentaire élargit le problème de confidentialité et de contrôle d’accès. La séparation géographique peut aussi compliquer la récupération.
### Séparez les secrets des consignes et les uns des autres
- **ID:** `mitigation-separate-secret-material`
- **Action:** Ne placez pas graine, phrase secrète, code PIN et procédure complète dans un même document ordinaire ou compte en ligne. Utilisez des limites d’accès distinctes adaptées à la politique.
- **Limite:** La séparation peut provoquer un blocage si les dépendances ne sont pas documentées ou si une personne autorisée ne peut pas réunir les éléments nécessaires.
### Répétez la récupération avant une urgence
- **ID:** `mitigation-rehearse-recovery`
- **Action:** Utilisez une procédure contrôlée, un appareil de secours ou réinitialisé et un portefeuille de test sans valeur si nécessaire. Confirmez le portefeuille, la politique, les adresses et la signature sans saisir de secret dans un appareil non fiable.
- **Limite:** Une répétition ne valide que le chemin testé à ce moment. Logiciels, appareils, personnes, lieux et documentation peuvent ensuite changer.
### Conservez le contexte non secret du portefeuille
- **ID:** `mitigation-preserve-wallet-context`
- **Action:** Consignez le type de portefeuille, la politique de script, la dérivation, les empreintes maîtres, le quorum, les besoins du coordinateur et le logiciel testé sans les réunir avec tous les secrets.
- **Limite:** Les descripteurs et clés publiques étendues peuvent exposer adresses et historique. Traitez-les comme sensibles même s’ils ne permettent pas de dépenser seuls.
### Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible
- **ID:** `mitigation-phishing-resistant-access`
- **Action:** Protégez les comptes de prestataire, messagerie et stockage avec des identifiants uniques et un authentificateur cryptographique lié au vrai domaine lorsque c’est possible. Examinez aussi les voies de récupération.
- **Limite:** Une authentification forte ne traite pas l’insolvabilité, les initiés malveillants, les terminaux compromis ni un processus de retrait défaillant.
### Réduisez la confiance accordée à l’environnement de signature connecté
- **ID:** `mitigation-harden-signing-environment`
- **Action:** Utilisez un logiciel maintenu provenant de sources authentifiées, limitez l’accès à distance et les applications inutiles, isolez les clés si nécessaire et gardez un moyen indépendant de vérifier l’intention.
- **Limite:** Le durcissement réduit l’exposition mais ne prouve pas que chaque dépendance, mise à jour, bibliothèque ou appareil est exempt de défaut.
### Vérifiez l’intention sur un écran indépendant
- **ID:** `mitigation-verify-on-trusted-display`
- **Action:** Avant de signer, comparez destinataire, montant, frais, monnaie rendue, réseau et politique avec l’intention d’origine sur un signataire ou canal indépendant de l’ordinateur créateur.
- **Limite:** Un écran peut omettre des champs, présenter des données confuses ou être compromis. La vérification dépend de la référence indépendante et de l’examen de l’opérateur.
### Séparez création, signature et diffusion lorsque c’est utile
- **ID:** `mitigation-separate-transaction-roles`
- **Action:** Utilisez un format standard tel que PSBT lorsque plusieurs systèmes ou signataires coopèrent. Exigez que chaque signataire valide la politique et les champs utiles avant de signer.
- **Limite:** La séparation des rôles augmente la coordination et la gestion des métadonnées. Un PSBT peut contenir des informations sensibles et n’oblige pas l’appareil à afficher chaque champ utile.
### Documentez rôles, dépendances et lieux sans inscrire les secrets
- **ID:** `mitigation-document-continuity-roles`
- **Action:** Consignez qui doit agir, quels documents non secrets existent, où se trouvent les éléments séparés, quels professionnels ou prestataires interviennent et comment l’autorité est vérifiée. Gardez les secrets hors du document.
- **Limite:** La documentation opérationnelle n’est pas un plan successoral et peut ne pas créer d’autorité juridique. Les conseils juridiques et fiscaux propres à la juridiction restent séparés.
### Répétez la transmission de continuité
- **ID:** `mitigation-rehearse-continuity`
- **Action:** Faites expliquer ou simuler le processus par une personne autorisée avec des documents non secrets. Confirmez contacts, lieux, dépendances, sort des appareils et voies d’escalade selon un calendrier daté.
- **Limite:** Une répétition peut exposer des relations sensibles et devenir obsolète après des changements familiaux, juridiques, de prestataire, d’appareil ou de portefeuille.
## Preuves attendues
### Preuves du périmètre de garde
Un inventaire à jour des signataires, prestataires, politiques, voies de récupération et dépendances bloquantes. Le marketing seul ne prouve pas le contrôle.
### Preuves de sauvegarde
Une vérification datée montrant que le matériel existe, reste lisible, est séparé selon les limites prévues et n’a pas été saisi dans un système non fiable.
### Preuves de récupération
Un compte rendu daté du chemin testé, de l’identité du portefeuille, des outils, de la politique reconstruite, des problèmes et corrections. Il ne doit pas contenir le secret.
### Preuves de contrôle d’accès
Méthodes documentées de récupération de compte, type d’authentificateur, provenance des appareils et logiciels, processus de mise à jour et suppression des anciens accès.
### Preuves de vérification des transactions
Une procédure répétable indiquant quels champs chaque signataire vérifie, la source indépendante de l’intention, la validation de la politique et le moment où la diffusion est autorisée.
### Preuves de continuité
Un inventaire daté et non secret des rôles et lieux, un responsable pour chaque suivi, un compte rendu de répétition et une révision après tout changement familial, juridique, de prestataire ou de portefeuille.
## Risques résiduels
### Des dépendances de garde subsistent
Clés, appareils, personnes, prestataires et politiques peuvent échouer ensemble ou agir autrement que prévu. Davantage d’indépendance ajoute souvent de la complexité.
### Disponibilité et secret restent en tension
Davantage de copies résistent à plus de pertes mais créent plus d’occasions de découverte, contrainte, mauvaise manipulation ou obsolescence.
### Une ancienne répétition ne garantit pas une récupération future
Appareils, compatibilité, personnes, mémoire, documentation et état du portefeuille peuvent changer après un test réussi.
### Des accès renforcés ne sécurisent pas toutes les dépendances
Terminaux, support, personnel du service, micrologiciel, accès physique et chaîne logicielle restent des voies de défaillance possibles.
### La vérification peut encore échouer au niveau humain ou de l’écran
Un signataire peut omettre une information importante, la référence peut être compromise ou l’opérateur peut approuver des données confuses ou inattendues.
### La transmission combine incertitudes techniques et juridiques
Une transmission techniquement correcte peut entrer en conflit avec le droit, la fiscalité, la famille, les règles du prestataire ou les volontés actuelles du propriétaire.
## Exclusions
- **Risque de marché et de prix:** Le modèle ne prévoit ni prix, ni liquidité, ni fiscalité, ni pertinence de détenir des bitcoins.
- **Consensus et sécurité du réseau Bitcoin:** Les défaillances de consensus, attaques minières, défauts de protocole et partitions réseau sont hors de ce modèle opérationnel.
- **Certification ou classement de produits:** Le modèle ne certifie aucun portefeuille matériel ou logiciel, plateforme, dépositaire, service multisignature ou prestataire de récupération.
- **Détermination personnalisée du risque:** Aucune priorité ne tient compte du montant, des compétences, des adversaires, du lieu, de la famille ou de la fréquence d’utilisation du lecteur.
- **Conseils juridiques, fiscaux et successoraux:** Les mesures de continuité décrivent seulement les opérations. Elles ne créent pas d’autorité juridique et ne remplacent pas un conseil qualifié dans la juridiction concernée.
## Sources
- [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. Utilisé pour le périmètre, les hypothèses, les sources de menace, l’incertitude et la révision. BitcoinSafe ne reprend pas les échelles de probabilité du NIST.
- [OWASP Threat Modeling Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) — OWASP Foundation. Utilisé pour la séquence périmètre, identification, réponse et révision ainsi que pour documenter des mesures applicables.
- [Bitcoin Developer Guide: Wallets](https://developer.bitcoin.org/devguide/wallets.html) — Bitcoin Developer Documentation. Utilisé pour séparer distribution des clés, signature et réseau, et pour expliquer le rôle des clés privées dans la dépense.
- [BIP 32: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) — Bitcoin Improvement Proposals. Utilisé pour la dérivation déterministe et les conséquences de l’exposition ou de la perte du matériel racine.
- [BIP 39: Mnemonic code for generating deterministic keys](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) — Bitcoin Improvement Proposals. Utilisé seulement pour décrire le matériel mnémonique et la phrase secrète facultative. Le modèle n’affirme pas que le BIP 39 est obligatoire pour tout portefeuille.
- [BIP 174: Partially Signed Bitcoin Transaction Format](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki) — Bitcoin Improvement Proposals. Utilisé pour séparer les rôles de transaction, signer hors ligne, définir les données du signataire et les limites des métadonnées PSBT.
- [BIP 380: Output Script Descriptors General Operation](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) — Bitcoin Improvement Proposals. Utilisé pour l’importance du type de script, des chemins, des clés et de la somme de contrôle du descripteur au-delà des seules clés privées.
- [Bitcoin Core Offline Signing Tutorial](https://github.com/bitcoin/bitcoin/blob/master/doc/offline-signing-tutorial.md) — Bitcoin Core. Utilisé pour l’objectif de sécurité et la limite opérationnelle documentés de la signature PSBT hors ligne.
- [Bitcoin Core External Signer Documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/external-signer.md) — Bitcoin Core. Utilisé pour les contrôles d’identité du signataire externe, la correspondance des descripteurs et l’affichage des adresses.
- [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. Utilisé pour la résistance à l’hameçonnage, la liaison au vérificateur, les contrôles d’authentificateur et les limites des codes saisis manuellement.
- [#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) — Cybersecurity and Infrastructure Security Agency. Utilisé pour la pratique générale des sauvegardes hors ligne et des tests réguliers de restauration. La récupération Bitcoin ajoute des contraintes de secret.
- [NIST SP 800-34 Rev. 1: Contingency Planning Guide](https://doi.org/10.6028/NIST.SP.800-34r1) — National Institute of Standards and Technology. Utilisé pour les rôles, la récupération, les tests, la validation, les éléments hors site et les dossiers datés. Il s’agit de recommandations générales, pas propres à Bitcoin.
- [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) — Creative Commons. Définit les conditions de réutilisation du texte et des données de recherche concernés.
- [Semantic Versioning 2.0.0](https://semver.org/) — Semantic Versioning. Définit les versions immuables et les règles de version majeure, mineure et corrective utilisées par ce modèle.
## Historique des versions
- **1.0.0 (2026-08-28):** Première version publique avec six catégories, 12 menaces, 12 mesures, preuves attendues, risques résiduels, correspondances avec l’évaluation et ressources traduites.
## Citation et réutilisation
BitcoinSafe, "Modèle ouvert des menaces de garde Bitcoin de BitcoinSafe," version 1.0.0, 2026-08-28, https://www.bitcoinsafe.com/fr/research/bitcoin-threat-model/1.0.0.
Le texte, la taxonomie, les relations et les fichiers de recherche générés du modèle sont sous licence CC BY 4.0. Le code de l’application et les autres contenus du site ne sont pas couverts par cet avis.
- [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)