Portefeuilles matériels et séparation des comptes

Source maître EN · P03-L06 · needs_review

Étude exclusivement hors ligne/en lecture seule. Ne fournissez jamais de secrets, de mots de passe ni de codes d’authentification. Aucune connexion de portefeuille, autorisation réelle, révocation en direct, signature de transaction, aucun transfert, fonds ou échange. Les visuels sont uniquement des spécifications.

Séparer les rôles de signature peut réduire l’autorité exposée au quotidien, mais le bénéfice dépend des capacités réelles et des dépendances partagées. Un appareil matériel ne constitue pas un verdict universel de sécurité.

Séparer les clés de l’action demandée

La documentation du fabricant décrit la signature à l’intérieur du matériel et la vérification sur un écran de confiance [HW]. Il s’agit d’une description de mécanisme, pas d’une preuve que chaque demande prise en charge est sûre ou entièrement intelligible. Conserver les clés dans un appareil ne supprime pas les conséquences d’une autorisation nuisible acceptée sciemment ou par erreur.

Concevoir les rôles sur papier

Le jeu de données utilise un rôle d’observation seule, un rôle d’interaction et un rôle de signature de réserve. Listez les tâches nécessaires à chacun : inspection publique, interaction avec une application ou autorisation occasionnelle. Ne supposez pas qu’un rôle peut faire quelque chose simplement parce que son écran affiche un solde. Aucun compte n’est créé et aucun fonds n’est déplacé dans cet exercice.

Comparez la conception A, où deux rôles de signature partagent une capacité de récupération, à la conception B, où le jeu de données stipule des capacités séparées. Séparer les libellés ou les adresses ne sépare pas nécessairement les domaines de défaillance. Si une capacité de récupération partagée est exposée, les deux rôles du jeu de données dépendent du même secret. BIP-39 explique un mécanisme de dérivation pour la récupération [BIP39] ; ce n’est pas une garantie sur la dérivation ou l’indépendance de chaque portefeuille.

Nommer les risques résiduels

Même dans la conception B, une invite non fiable peut demander au rôle d’interaction des permissions excessives. Le rôle de réserve peut lui aussi autoriser des effets nuisibles si l’examen échoue. La prise en charge de l’affichage, la provenance du firmware/logiciel, la manipulation physique et la gestion des sauvegardes confidentielles sont des dépendances distinctes. Le jeu de données ne fournit aucune évaluation d’un produit réel ou d’un firmware actuel.

Utilisez une matrice de dépendances plutôt qu’une affirmation de risque nul. Si la fiche ne précise pas si deux rôles partagent une capacité de récupération, indiquez UNKNOWN pour cette relation. Ne demandez jamais à l’apprenant de saisir une sauvegarde pour la déterminer. Une déclaration d’architecture expurgée de toute donnée confidentielle suffit pour l’exercice en classe.

Énoncer le bénéfice délimité

OBSERVED : lignes de rôles/capacités stipulées. INFERRED : effet de la dépendance partagée indiquée sur le modèle de séparation. UNKNOWN : appareils, sauvegardes et comportement opérationnel réels. INSUFFICIENT EVIDENCE : « le matériel garantit la sécurité ». La séparation est une conception de processus à évaluer sous des hypothèses, pas un conseil financier personnalisé ni une instruction de transférer des avoirs réels.

• Observation seule : rôle d’observation sans capacité de signature fournie.
• Rôle de signature : fonction d’autorisation délimitée par une capacité.
• Domaine de défaillance : dépendance partagée pouvant affecter plusieurs rôles.
• Écran de confiance : surface d’examen locale à l’appareil, avec ses propres limites de prise en charge.

Conceptions sur papier ILLUSTRATIVE. Rôles WATCH/INTERACT/RESERVE. WATCH ne dispose que de repères publics. Conception A : INTERACT et RESERVE utilisent le même substitut stipulé RECOVERY-CAP-A. Conception B : capacités substitutives distinctes CAP-B/C, aucun secret réel. Les deux incluent une étape d’examen sur l’appareil ; couverture du décodage/de l’affichage UNKNOWN. Aucun solde ni compte réel fourni.

Graphe des rôles de portefeuille avec arêtes typées affichage/autorisation/récupération partagée. La conception A partage un nœud de dépendance confidentielle ; la conception B le sépare par stipulation. Ajoutez aux deux les risques résiduels liés aux invites/à l’affichage/à la provenance, jamais de badge vert « sécurité garantie ».

Les affectations de rôles et les différences de dépendances partagées stipulées dans deux conceptions illustratives.

L’indépendance de comptes réels, l’immunité aux signatures nuisibles, un firmware sûr, une récupération correcte ou une protection garantie.

• Supposer que des adresses différentes impliquent des secrets indépendants.
• Supposer que le matériel empêche toute autorisation nuisible.
• Collecter des sauvegardes pour prouver la séparation architecturale.

Construisez une matrice de rôles/capacités pour A/B et listez trois risques restants. Évaluez ce que peut faire le rôle d’observation. Rédigez un énoncé de bénéfice délimité sans demander de secrets ni prescrire de transferts réels.

Remettez un tableau et une conclusion délimitée en utilisant uniquement le matériel hors ligne fourni. Répartition éditoriale du temps : étude 12 min, exercice 8 min, correction/quiz 10 min.

• Définir les tâches avant les libellés des rôles.
• Séparer affichage et autorisation.
• Consigner les dépendances partagées sans secrets.
• Lister les risques résiduels liés à l’examen/à la provenance.
• Garder les bénéfices conditionnels et hors ligne.

La séparation des rôles doit suivre les capacités et les dépendances. L’isolation matérielle étaye un mécanisme de sécurité précis tandis que les risques liés aux autorisations, aux sauvegardes et à l’interface restent présents.

• Concevoir un processus de séparation et énoncer ses risques résiduels
• Concevoir une séparation des rôles sans fournir d’identifiants d’accès.
• Identifier les risques restants liés aux autorisations, à la récupération et à l’interface.

P03-L07 après revue des prérequis et de la correction.

NONE dans le catalogue de référence. Les données hors ligne fournies suffisent ; aucun achat de produit ni aucune opération de portefeuille n’est requis.

• [HW] Documentation des portefeuilles matériels Trezor — Signature isolée dans l’appareil et écran de confiance ; explication du fabricant, pas garantie de sécurité.
• [BIP39] Spécification du seed mnémonique BIP-39 — Dérivation d’un seed à partir d’une phrase mnémonique avec passphrase facultative ; pas authentification du jeu de données.

La documentation explique les mécanismes. Les enregistrements historiques conservent leur classe de source déclarée. L’inspection d’une source ne constitue pas une acceptation éditoriale indépendante.