Phrases de récupération et clés privées

Source maître EN · P03-L01 · 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.

Un rapport de preuves doit expliquer une éventuelle exposition de secret sans créer une nouvelle exposition. Une capacité de récupération et une adresse publique jouent des rôles de sécurité différents.

Séparer les mécanismes d’accès

Une phrase mnémonique BIP-39 et une passphrase facultative permettent de dériver le matériau de seed [BIP39]. Ce ne sont pas des identifiants publics de compte. Un mot de passe local d’application protège une couche d’accès à l’application ; ce mécanisme diffère de la capacité de signature du protocole. Un changement de mot de passe ne permet pas d’établir que des éléments de récupération précédemment copiés ont perdu leur capacité. Aucune phrase mnémonique, clé ou valeur d’authentification n’est fournie ni demandée ici.

Consigner les catégories, jamais les valeurs secrètes

Les recommandations officielles de sécurité proscrivent le partage des clés privées, phrases de récupération et mots de passe [SECURITY]. Le cours exclut également les codes d’authentification, les captures contenant des éléments confidentiels et l’accès à distance. Une note de preuves utile peut nommer la catégorie demandée et conserver une description de la demande expurgée de toute donnée confidentielle. Elle ne doit pas reproduire les éléments dont l’exposition est en cause.

Le jeu de données utilise des fiches de catégories. R1 est un identifiant pédagogique non secret. R2 décrit une demande confidentielle sans fournir de valeur. R3 affirme qu’un changement de mot de passe local annule l’exposition des éléments de récupération. R4 est une déclaration fictive de divulgation. La lecture de ces fiches suffit pour évaluer les éléments nécessaires à chaque affirmation.

Préserver les étapes

Demandé, fourni et utilisé ensuite sont des propositions distinctes. Une invite affichée ne montre pas que la demande a été suivie. Une déclaration d’utilisateur ne prouve pas indépendamment un vol. Un enregistrement ultérieur de transaction, même disponible, aurait besoin de son propre réseau et contexte et ne pourrait pas, à lui seul, identifier un attaquant. Conservez ces étapes dans des lignes de preuves distinctes au lieu de les résumer par « piraté ».

Adapter la conclusion aux preuves fournies

OBSERVED désigne le texte ou la catégorie des fiches dans l’exercice. INFERRED désigne la distinction entre mécanismes selon le modèle indiqué. UNKNOWN couvre la divulgation réelle, l’accès au compte et les pertes, car aucun enregistrement de ce type n’est fourni. INSUFFICIENT EVIDENCE s’applique aux affirmations identifiant un véritable attaquant ou concluant à un vol à partir de la seule invite. Cet exercice entraîne à rédiger un rapport ; il ne demande jamais de démontrer une récupération, d’inspecter une sauvegarde réelle ou de déplacer des fonds.

• Matériau de seed : entrée confidentielle à partir de laquelle un système de portefeuille peut dériver des clés de signature.
• Clé privée : valeur confidentielle de signature pour un compte ou un rôle d’autorisation.
• Éléments de récupération : capacité confidentielle permettant de recréer l’accès à la signature.
• Identifiant public : identifiant d’enregistrement non secret.
• Mot de passe local : contrôle d’accès à l’application.
• Déclaration de divulgation : signalement d’une exposition, nécessitant sa propre provenance.

Fiches ILLUSTRATIVE expurgées ; aucun secret. R1 identifiant public SIM-TX-1. R2 « Le support demande des éléments de récupération », valeur [NOT PROVIDED]. R3 « Un changement de mot de passe d’application annule l’exposition des éléments de récupération ». R4 déclaration fictive d’utilisateur « J’ai fourni des éléments de récupération » ; aucun compte, enregistrement de perte ou horodatage réel fourni.

Voies distinctes pour les identifiants publics et les capacités confidentielles. R2 ne contient qu’une catégorie et un libellé de demande interdite. R3 est une affirmation sur un mécanisme, R4 une déclaration d’utilisateur. Ne générez jamais de mots de phrase de récupération, d’octets de clé ni de codes scannables.

Les catégories stipulées et l’existence de demandes et de déclarations de divulgation dans le jeu de données.

Une divulgation réelle, un vol, une identité humaine, la possibilité de récupération ou une maîtrise garantie de l’incident.

• Téléverser un secret comme preuve.
• Traiter une adresse publique comme une capacité de signature.
• Supposer qu’un changement de mot de passe d’application retire une capacité de récupération copiée.

Classez R1–R4 et rédigez une phrase sur l’incident expurgée de toute donnée confidentielle. Expliquez si R2 prouve que la demande a été suivie et si R3 établit la maîtrise de l’incident. Identifiez les preuves manquantes sans demander de valeurs confidentielles.

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.

• Utiliser uniquement des catégories.
• Séparer identifiants publics et capacités.
• Distinguer demande, signalement et utilisation.
• Exclure les captures et codes secrets.
• Limiter les affirmations sur les pertes et les identités.

Le traitement des preuves doit préserver les faits sans collecter de secrets. Un identifiant public, un mot de passe local et une capacité de récupération sont des objets distincts.

• Expliquer les limites de l’exposition des secrets et de la récupération sans saisir de véritables secrets
• Distinguer les identifiants publics de la capacité confidentielle de récupération.
• Distinguer une demande, une déclaration de divulgation et une utilisation observée.

P03-L02 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.

• [BIP39] Spécification BIP-39 du seed mnémonique — Dérivation de la phrase mnémonique vers le seed avec passphrase facultative ; n’authentifie pas le jeu de données.
• [SECURITY] Sécurité Ethereum et prévention des escroqueries — Confidentialité des secrets, vérification exacte des domaines et prudence envers l’assistance non officielle.

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.