Version de recherche immuableVersion figée

Modèle des menaces de garde Bitcoin 1.0.0

Cette version permanente conserve la taxonomie, les relations, les sources et les textes publiés le 28 août 2026.

Version: 1.0.0
Publié: 28 août 2026
Dernière révision: 28 août 2026

Télécharger le JSON Télécharger le Markdown Ouvrir le modèle actuel

Cadre transparent

Ce que le modèle protège et suppose

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.

Public concerné

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.

Ni note ni 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 opérationnelles

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

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

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

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

Adresses, clés publiques étendues, soldes, historique des transactions, contreparties et liens de propriété.

Continuité opérationnelle

La capacité d’une personne autorisée à comprendre, maintenir, récupérer et transmettre le dispositif dans le temps.

Méthode

Définir, identifier, répondre et réviser

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.

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.

Schémas du modèle

Six couches opérationnelles examinées séparément

Le modèle sépare autorité de garde, sauvegardes, récupération, accès, vérification des transactions et continuité afin qu’une mesure forte ne masque pas une faiblesse ailleurs.

012 menaces

Autorité de garde

Qui peut autoriser une dépense et quelles parties ou quels éléments doivent rester disponibles et honnêtes.

022 menaces

Résilience des sauvegardes

Si le matériel de récupération survit à une perte tout en restant inaccessible aux personnes non autorisées.

032 menaces

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.

042 menaces

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.

052 menaces

Vérification des transactions

Si le signataire peut confirmer indépendamment ce qui sera autorisé avant qu’une transaction ne devienne irréversible.

062 menaces

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.

Chaque menace mène à une réponse et à un risque restant

Le résumé visuel provient des mêmes relations que les téléchargements. La liste textuelle fournit la même information sans dépendre de la couleur ou de la position.

Équivalent textuel du schéma de relations par catégorie

Autorité de garde: 2 menaces · 4 mesures
Résilience des sauvegardes: 2 menaces · 3 mesures
Préparation à la récupération: 2 menaces · 2 mesures
Protection des accès: 2 menaces · 5 mesures
Vérification des transactions: 2 menaces · 2 mesures
Continuité et transmission: 2 menaces · 3 mesures

Examinez les données

Matrice menaces, mesures, preuves et risques résiduels

La priorité indique dans quelle mesure la condition peut mener à une perte. Ce n’est ni une probabilité, ni une note de produit, ni un score personnel.

Couche	Menace et scénario	Priorité	Mesures associées	Preuves attendues	Risque résiduel
Autorité de gardethreat-custody-provider-control	Un prestataire contrôle le retrait ou la signatureUne 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.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.	Attention élevée	Documentez le périmètre de garde; Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible	Preuves du périmètre de garde; Preuves de contrôle d’accès	Des dépendances de garde subsistent; Des accès renforcés ne sécurisent pas toutes les dépendances
Autorité de gardethreat-custody-signer-compromise	Une autorité de signature suffisante est volée ou copiéeUn 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.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.	Attention élevée	Isolez une autorité de signature suffisante; Séparez les secrets des consignes et les uns des autres	Preuves du périmètre de garde; Preuves de sauvegarde	Des dépendances de garde subsistent; Disponibilité et secret restent en tension
Résilience des sauvegardesthreat-backup-unavailable	Le matériel de récupération manque ou devient illisiblePerte, incendie, eau, corrosion, mise au rebut accidentelle, oubli ou lieu unique commun suppriment toutes les sauvegardes utilisables.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.	Attention élevée	Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance; Répétez la récupération avant une urgence	Preuves de sauvegarde; Preuves de récupération	Disponibilité et secret restent en tension; Une ancienne répétition ne garantit pas une récupération future
Résilience des sauvegardesthreat-backup-secret-exposure	Une sauvegarde expose des secrets de signatureDes 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.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.	Attention élevée	Séparez les secrets des consignes et les uns des autres; Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance	Preuves de sauvegarde	Disponibilité et secret restent en tension
Préparation à la récupérationthreat-recovery-not-rehearsed	La procédure de récupération n’a pas été répétéeAprè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.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.	Important	Répétez la récupération avant une urgence; Conservez le contexte non secret du portefeuille	Preuves de récupération	Une ancienne répétition ne garantit pas une récupération future
Préparation à la récupérationthreat-recovery-wallet-context-missing	Les clés subsistent mais le contexte du portefeuille manqueLa 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.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.	Important	Conservez le contexte non secret du portefeuille; Répétez la récupération avant une urgence	Preuves de récupération	Une ancienne répétition ne garantit pas une récupération future; Disponibilité et secret restent en tension
Protection des accèsthreat-access-provider-account-takeover	Un compte de prestataire est pris en contrôleHameç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.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.	Attention élevée	Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible; Documentez le périmètre de garde	Preuves de contrôle d’accès; Preuves du périmètre de garde	Des accès renforcés ne sécurisent pas toutes les dépendances; Des dépendances de garde subsistent
Protection des accèsthreat-access-signing-environment-compromise	L’environnement de signature est compromisUn 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.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.	Attention élevée	Réduisez la confiance accordée à l’environnement de signature connecté; Isolez une autorité de signature suffisante; Vérifiez l’intention sur un écran indépendant	Preuves de contrôle d’accès; Preuves de vérification des transactions	Des accès renforcés ne sécurisent pas toutes les dépendances; La vérification peut encore échouer au niveau humain ou de l’écran
Vérification des transactionsthreat-transaction-destination-substitution	La destination ou le montant est remplacé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.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.	Attention élevée	Vérifiez l’intention sur un écran indépendant; Séparez création, signature et diffusion lorsque c’est utile	Preuves de vérification des transactions	La vérification peut encore échouer au niveau humain ou de l’écran
Vérification des transactionsthreat-transaction-incomplete-signing-context	Le signataire manque de contexte pour vérifier la dépenseL’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.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.	Important	Séparez création, signature et diffusion lorsque c’est utile; Vérifiez l’intention sur un écran indépendant	Preuves de vérification des transactions	La vérification peut encore échouer au niveau humain ou de l’écran
Continuité et transmissionthreat-continuity-operator-unavailability	Le seul opérateur informé n’est plus disponibleDé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.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.	Important	Documentez rôles, dépendances et lieux sans inscrire les secrets; Répétez la transmission de continuité	Preuves de continuité	La transmission combine incertitudes techniques et juridiques; Une ancienne répétition ne garantit pas une récupération future
Continuité et transmissionthreat-continuity-secret-concentration	Un document de continuité concentre tous les secretsUn 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.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.	Attention élevée	Documentez rôles, dépendances et lieux sans inscrire les secrets; Séparez les secrets des consignes et les uns des autres; Répétez la transmission de continuité	Preuves de continuité; Preuves de sauvegarde	La transmission combine incertitudes techniques et juridiques; Disponibilité et secret restent en tension

Autorité de gardeAttention élevée

threat-custody-provider-control

Un prestataire contrôle le retrait ou la signature

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; Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible
Preuves attendues: Preuves du périmètre de garde; Preuves de contrôle d’accès
Risque résiduel: Des dépendances de garde subsistent; Des accès renforcés ne sécurisent pas toutes les dépendances

Autorité de gardeAttention élevée

threat-custody-signer-compromise

Une autorité de signature suffisante est volée ou copiée

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; Séparez les secrets des consignes et les uns des autres
Preuves attendues: Preuves du périmètre de garde; Preuves de sauvegarde
Risque résiduel: Des dépendances de garde subsistent; Disponibilité et secret restent en tension

Résilience des sauvegardesAttention élevée

threat-backup-unavailable

Le matériel de récupération manque ou devient illisible

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; Répétez la récupération avant une urgence
Preuves attendues: Preuves de sauvegarde; Preuves de récupération
Risque résiduel: Disponibilité et secret restent en tension; Une ancienne répétition ne garantit pas une récupération future

Résilience des sauvegardesAttention élevée

threat-backup-secret-exposure

Une sauvegarde expose des secrets de signature

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; Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance
Preuves attendues: Preuves de sauvegarde
Risque résiduel: Disponibilité et secret restent en tension

Préparation à la récupérationImportant

threat-recovery-not-rehearsed

La procédure de récupération n’a pas été répétée

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; Conservez le contexte non secret du portefeuille
Preuves attendues: Preuves de récupération
Risque résiduel: Une ancienne répétition ne garantit pas une récupération future

Préparation à la récupérationImportant

threat-recovery-wallet-context-missing

Les clés subsistent mais le contexte du portefeuille manque

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; Répétez la récupération avant une urgence
Preuves attendues: Preuves de récupération
Risque résiduel: Une ancienne répétition ne garantit pas une récupération future; Disponibilité et secret restent en tension

Protection des accèsAttention élevée

threat-access-provider-account-takeover

Un compte de prestataire est pris en contrôle

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; Documentez le périmètre de garde
Preuves attendues: Preuves de contrôle d’accès; Preuves du périmètre de garde
Risque résiduel: Des accès renforcés ne sécurisent pas toutes les dépendances; Des dépendances de garde subsistent

Protection des accèsAttention élevée

threat-access-signing-environment-compromise

L’environnement de signature est compromis

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é; Isolez une autorité de signature suffisante; Vérifiez l’intention sur un écran indépendant
Preuves attendues: Preuves de contrôle d’accès; Preuves de vérification des transactions
Risque résiduel: Des accès renforcés ne sécurisent pas toutes les dépendances; La vérification peut encore échouer au niveau humain ou de l’écran

Vérification des transactionsAttention élevée

threat-transaction-destination-substitution

La destination ou le montant est remplacé

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; Séparez création, signature et diffusion lorsque c’est utile
Preuves attendues: Preuves de vérification des transactions
Risque résiduel: La vérification peut encore échouer au niveau humain ou de l’écran

Vérification des transactionsImportant

threat-transaction-incomplete-signing-context

Le signataire manque de contexte pour vérifier la dépense

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; Vérifiez l’intention sur un écran indépendant
Preuves attendues: Preuves de vérification des transactions
Risque résiduel: La vérification peut encore échouer au niveau humain ou de l’écran

Continuité et transmissionImportant

threat-continuity-operator-unavailability

Le seul opérateur informé n’est plus disponible

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; Répétez la transmission de continuité
Preuves attendues: Preuves de continuité
Risque résiduel: La transmission combine incertitudes techniques et juridiques; Une ancienne répétition ne garantit pas une récupération future

Continuité et transmissionAttention élevée

threat-continuity-secret-concentration

Un document de continuité concentre tous les secrets

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; Séparez les secrets des consignes et les uns des autres; Répétez la transmission de continuité
Preuves attendues: Preuves de continuité; Preuves de sauvegarde
Risque résiduel: La transmission combine incertitudes techniques et juridiques; Disponibilité et secret restent en tension

Mesures

Mesures associées

mitigation-define-custody-boundary

Documentez le périmètre de garde

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.

mitigation-isolate-signing-keys

Isolez une autorité de signature suffisante

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.

mitigation-redundant-offline-backups

Conservez des sauvegardes vérifiées au-delà d’un même point de défaillance

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.

mitigation-separate-secret-material

Séparez les secrets des consignes et les uns des autres

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.

mitigation-rehearse-recovery

Répétez la récupération avant une urgence

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.

mitigation-preserve-wallet-context

Conservez le contexte non secret du portefeuille

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.

mitigation-phishing-resistant-access

Utilisez un accès résistant à l’hameçonnage lorsqu’il est disponible

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.

mitigation-harden-signing-environment

Réduisez la confiance accordée à l’environnement de signature connecté

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.

mitigation-verify-on-trusted-display

Vérifiez l’intention sur un écran indépendant

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.

mitigation-separate-transaction-roles

Séparez création, signature et diffusion lorsque c’est utile

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.

mitigation-document-continuity-roles

Documentez rôles, dépendances et lieux sans inscrire les secrets

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.

mitigation-rehearse-continuity

Répétez la transmission de continuité

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

Ce qu’une affirmation de contrôle devrait démontrer

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.

Risque résiduel

Ce qui subsiste après les mesures

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.

Limites

Ce que la version 1.0.0 n’évalue pas

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.

Base documentaire

Spécifications, normes et sources examinées

Les sources étayent des affirmations techniques ou de procédure précises. Les recommandations générales du NIST et de la CISA restent identifiées comme telles.

NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
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.
Consulté: 2026-08-28
OWASP Threat Modeling Cheat Sheet
OWASP Foundation
Utilisé pour la séquence périmètre, identification, réponse et révision ainsi que pour documenter des mesures applicables.
Consulté: 2026-08-28
Bitcoin Developer Guide: Wallets
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.
Consulté: 2026-08-28
BIP 32: Hierarchical Deterministic Wallets
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.
Consulté: 2026-08-28
BIP 39: Mnemonic code for generating deterministic keys
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.
Consulté: 2026-08-28
BIP 174: Partially Signed Bitcoin Transaction Format
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.
Consulté: 2026-08-28
BIP 380: Output Script Descriptors General Operation
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.
Consulté: 2026-08-28
Bitcoin Core Offline Signing Tutorial
Bitcoin Core
Utilisé pour l’objectif de sécurité et la limite opérationnelle documentés de la signature PSBT hors ligne.
Consulté: 2026-08-28
Bitcoin Core External Signer Documentation
Bitcoin Core
Utilisé pour les contrôles d’identité du signataire externe, la correspondance des descripteurs et l’affichage des adresses.
Consulté: 2026-08-28
NIST SP 800-63B-4: Authentication and Authenticator Management
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.
Consulté: 2026-08-28
#StopRansomware 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.
Consulté: 2026-08-28
NIST SP 800-34 Rev. 1: Contingency Planning Guide
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.
Consulté: 2026-08-28
Creative Commons Attribution 4.0 International
Creative Commons
Définit les conditions de réutilisation du texte et des données de recherche concernés.
Consulté: 2026-08-28
Semantic Versioning 2.0.0
Semantic Versioning
Définit les versions immuables et les règles de version majeure, mineure et corrective utilisées par ce modèle.
Consulté: 2026-08-28

Versions permanentes

Une correction crée une nouvelle version

Une version corrective modifie le texte ou les sources sans changer les catégories. Une version mineure ajoute des données compatibles. Une version majeure peut changer les hypothèses ou la taxonomie. Les anciens fichiers restent disponibles.

1.0.02026-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 licence

Réutilisez la recherche avec attribution

Le texte, la taxonomie, les relations et les fichiers générés sont sous licence CC BY 4.0. Le code et les autres contenus du site ne sont pas couverts.

Citation suggérée: Kinnett, Kevin. (2026). BitcoinSafe Open Bitcoin Custody Threat Model (Version 1.0.0). BitcoinSafe.
Creative Commons Attribution 4.0 International: 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.

Voir les fichiers sources sur GitHub Signaler une correction

Fichiers de recherche réutilisables

Utilisez les mêmes données que cette page

Les fichiers JSON et Markdown contiennent les mêmes identifiants et relations que la page. Une version publiée n’est jamais réécrite.

Télécharger le JSON Télécharger le Markdown Télécharger la citation Lire les conditions de réutilisation

L’impression s’exécute dans le navigateur sans envoyer de données du modèle ou de l’évaluation.

Appliquer le modèle

Utilisez le cadre sans envoyer vos réponses à BitcoinSafe

L’évaluation examine six pratiques dans votre navigateur. Elle ne demande ni mots de récupération, ni clés privées, ni adresses, ni soldes, ni fichiers de portefeuille.

Lancer l’évaluation privée Lancer la liste de vérification Lire « Bitcoin est-il sûr ? »Préparer la continuité opérationnelle

Ressources de sécurité associées

Utilisez la carte générale pour le contexte ou ouvrez le guide spécialisé le plus proche pour agir.