🔑 Wallets & Identité Décentralisée

Le Flux de Génération (Unidirectionnel)

C'est un processus mathématique à sens unique. Vous ne pouvez pas remonter la chaîne.

1. Clé Privée (Le Secret)

• Définition : C'est la seule chose qui soit vraiment secrète. C'est un **nombre aléatoire de 256 bits** (32 octets).
• Exemple (Hex) : `f8f8...a1c` (64 caractères).
• Analogie : C'est votre **Mot de Passe Maître** pour votre compte en banque.
• Règle : DOIT RESTER ABSOLUMENT SECRET. Celui qui la possède, possède vos fonds. Elle n'est jamais partagée, jamais diffusée sur le réseau.

▼

2. Clé Publique (Le Cadenas)

• Définition : La clé publique (512 bits / 64 octets) est **dérivée mathématiquement** de la clé privée via l'algorithme ECDSA.
• Propriété : C'est une **fonction à sens unique**. Il est trivial de calculer la Clé Publique à partir de la Clé Privée, mais il est **cryptographiquement impossible** de retrouver la Clé Privée à partir de la Clé Publique.
• Analogie : C'est un **cadenas ouvert**. Vous pouvez le distribuer à tout le monde. Les gens peuvent l'utiliser pour *vérifier* que vous êtes bien le propriétaire de la clé privée, ou pour chiffrer un message que vous seul pourrez ouvrir.

▼

3. Adresse Publique (L'IBAN)

• Définition : L'adresse Ethereum (celle que vous utilisez, ex: `0xd8...6045`) est une version *hachée* et *raccourcie* de la Clé Publique.
• Processus (Ethereum) :
  1. Prendre la Clé Publique (64 octets).
  2. La hacher avec l'algorithme **Keccak-256**.
  3. Prendre les **20 derniers octets (40 caractères)** de ce hash.
  4. Ajouter "0x" au début.
• Analogie : C'est votre **IBAN** ou votre "RIB". C'est l'identifiant que vous donnez publiquement pour *recevoir* des fonds. Il est sûr de la partager.

BIP-39 : La "Master Key" Mnémonique

**BIP-39 (Bitcoin Improvement Proposal 39)** est le standard utilisé par 99% des wallets (Metamask, Ledger, etc.) pour générer et sauvegarder votre clé maîtresse.

La "Seed Phrase" (12 ou 24 mots) n'est PAS votre clé privée. C'est une représentation "humainement lisible" d'un nombre aléatoire (l'entropie) qui est utilisé pour *générer* votre clé privée maîtresse.

Processus de Génération (BIP-39)

1. 1. Entropie : Le wallet génère un long nombre aléatoire (ex: 128 bits pour 12 mots, 256 bits pour 24 mots).
2. 2. Checksum : Il ajoute quelques bits de "checksum" (somme de contrôle) pour détecter les fautes de frappe.
3. 3. Conversion : Ce nombre binaire est découpé en groupes de 11 bits.
4. 4. Mappage (Liste de Mots) : Chaque groupe de 11 bits correspond à un numéro (de 0 à 2047). Le standard BIP-39 fournit une **liste de 2048 mots** (en anglais, français, etc.). Le wallet fait correspondre chaque numéro à un mot de la liste.
   (Ex: `00000000001` -> `abandon`, `11111111111` -> `zoo`).
5. 5. Phrase : Le résultat est votre "Seed Phrase" de 12/24 mots (ex: `abandon ability able...`).

Processus de Récupération (Inverse) :

Lorsque vous restaurez un wallet, vous entrez les 12 mots. Le wallet (connaissant la liste BIP-39) re-convertit les mots en numéros, ré-assemble le nombre binaire (l'entropie), vérifie le checksum, et obtient *exactement* le même point de départ aléatoire.

▼

Du Mot à la Clé (PBKDF2)

La Seed Phrase (ex: "chat montagne...") est ensuite passée dans une fonction de dérivation de clé (PBKDF2) avec un "sel" (salt) pour créer le **"Seed" binaire** (512 bits). C'est cette "Seed" qui est la racine de toutes vos clés.

1. Rôle de "Hot Wallet" (Gestionnaire de Clés)

Metamask est un **"Hot Wallet"** (portefeuille chaud) car les clés privées (dérivées de votre seed phrase) sont stockées sur votre appareil connecté à Internet (dans le stockage chiffré de votre navigateur).

• Génération : Il génère la Seed Phrase (BIP-39) et gère les comptes (BIP-44).
• Stockage : La seed phrase et les clés privées sont chiffrées avec un **Mot de Passe** que vous définissez.
• Point Clé : Ce "Mot de Passe" ne sert qu'à **déchiffrer/verrouiller** le stockage local de Metamask sur *cet ordinateur*. Ce n'est **PAS** votre backup. Si l'ordinateur est détruit, le mot de passe ne sert à rien. Seule la **Seed Phrase** de 12 mots peut restaurer le portefeuille.

2. Rôle de "Provider" (Injecteur EIP-1193)

Comme vu dans le guide Ethers.js, Metamask **injecte** un objet JavaScript `window.ethereum` dans chaque page web que vous visitez. Cet objet est le **Provider** (le pont de communication).

• `window.ethereum` agit comme un routeur.
• Il relaie les requêtes de "lecture" (ex: `eth_getBalance`) de la DApp vers un nœud RPC (par défaut, Metamask utilise Infura, mais l'utilisateur peut le changer pour son propre nœud).
• Il intercepte les requêtes "d'écriture" (ex: `eth_sendTransaction`).

3. Rôle de "Signer" (Interface de Sécurité)

C'est le rôle le plus important pour l'utilisateur. Metamask est le "gardien" qui empêche une DApp de voler vos fonds.

• Lorsqu'une DApp (via Ethers.js) appelle signer.sendTransaction(...), Metamask intercepte cet appel.
• Il **arrête** l'exécution et ouvre une **pop-up** (une interface utilisateur séparée, hors de portée de la DApp).
• Cette pop-up affiche une version *lisible* de la transaction (Montant, Destination, Frais de Gas estimés).
• La DApp est en pause. L'utilisateur (vous) doit **manuellement** cliquer sur "Confirmer" ou "Rejeter".
• Si "Confirmer", Metamask utilise la clé privée stockée pour signer la transaction, puis la renvoie à la DApp (qui la diffuse).
• Si "Rejeter", Metamask renvoie une erreur à la DApp (ex: `Error: "User rejected transaction"`).

Concept : Isolation de la Clé (Secure Element)

La philosophie d'un hardware wallet est : **"Faites confiance à l'appareil, ne faites confiance à rien d'autre."** Il part du principe que votre ordinateur (PC/Mac) est **déjà compromis** (infecté par un malware).

• Génération de Clé : Lorsque vous allumez un Ledger pour la première fois, la Seed Phrase (BIP-39) est générée *à l'intérieur* de l'appareil. Elle est affichée sur le petit écran de l'appareil. Elle n'apparaît **jamais** sur l'écran de votre ordinateur.
• Secure Element (SE) : La Clé Privée (dérivée de la seed) est stockée dans une puce cryptographique spécialisée (un "Secure Element" ou "SE"). C'est le même type de puce que dans une carte de crédit ou un passeport.
• Protection : Cette puce est conçue pour être inviolable. Il est (en théorie) impossible d'en extraire la clé privée, même avec un accès physique (elle s'autodétruira si on tente de l'ouvrir).

Le Flux de Connexion (v2.0)

WalletConnect agit comme un "téléphone" sécurisé entre la DApp et le Wallet Mobile.

1. 1. DApp (sur PC) : L'utilisateur clique sur "Connecter le Wallet" et choisit "WalletConnect". La DApp (via la bibliothèque WalletConnect) génère un QR code unique.
2. 2. Wallet (sur Mobile) : L'utilisateur ouvre son portefeuille (ex: Trust Wallet) et utilise la fonction "WalletConnect" pour scanner le QR code.
3. 3. Appairage (Pairing) : Le scan établit un **canal de communication chiffré de bout en bout (E2EE)** entre la DApp (PC) et le Wallet (Mobile).
   • Ce canal passe par un **"Bridge Server"** (serveur relais) public. Ce serveur ne fait que relayer des messages chiffrés ; il ne peut pas lire le contenu.
4. 4. Session : Le Wallet Mobile demande : "Autoriser 'monsite.com' à se connecter ?". L'utilisateur accepte. La DApp (PC) reçoit l'adresse du compte et est connectée.

Identité : Le Problème de l'Authentification

Problème : Comment un site web (Web2) peut-il "connecter" un utilisateur Web3 sans base de données d'utilisateurs ?

Ancienne Méthode (Dangereuse) : Le site demandait : "Signez ce message : 'Login'". L'utilisateur signait (via `personal_sign`). Le site vérifiait la signature et ouvrait une session.

Risque : Un site de phishing (ex: `faux-uniswap.com`) pouvait demander la même signature ("Login"). Si le hacker interceptait cette signature, il pouvait l'utiliser pour se connecter au *vrai* site (Uniswap) en votre nom (attaque par rejeu ou "replay attack").

La Solution : EIP-4361 (Sign-In with Ethereum - SIWE)

SIWE est un standard (EIP) qui définit un **format de message standardisé** pour l'authentification. Ce message inclut des informations qui le rendent unique à un seul site et à une seule session, empêchant les attaques par rejeu.

Le Flux SIWE (Authentification Web2/Web3)

1. 1. Frontend (React) : L'utilisateur clique "Login". Le frontend (via Ethers.js) demande à Metamask de signer un message **structuré** (défini par SIWE) :

   monsite.com wants you to sign in with your Ethereum account:
   0x123...abc (Votre Adresse)
   
   (Message lisible)
   URI: https://monsite.com
   Version: 1
   Chain ID: 1
   Nonce: kG8a...7z (Un code aléatoire unique généré par le serveur)
   Issued At: 2025-11-10T14:30:00Z
   

2. 2. Wallet (Metamask) : Affiche cette demande de signature claire. L'utilisateur voit que le `URI` et le `Nonce` sont corrects. Il signe.
3. 3. Backend (Serveur Web2) : Le Frontend envoie le (Message + Signature) au serveur (ex: Node.js).
4. 4. Vérification (Backend) : Le serveur :
   • Vérifie que la signature est valide pour ce message (prouvant que l'utilisateur est bien `0x123...abc`).
   • Vérifie que le `URI` est bien `https://monsite.com`.
   • Vérifie que le `Nonce` est bien celui qu'il a généré (empêche le rejeu).
5. 5. Session : Si tout est valide, le serveur Web2 génère un **Token de Session (JWT)** traditionnel et le renvoie au frontend. L'utilisateur est "logué" au sens Web2, mais authentifié au sens Web3.