La solution de conservation de Google Cloud : pourquoi dit-on que la clé privée « n’apparaît jamais dans son intégralité » ?
Cette semaine, c’est le portefeuille chaud d’une plateforme d’échange qui a été vidé. La même semaine, je suis allé consulter un document produit de Google Cloud : Multi-party Compute (conservation par calcul multipartite), une solution dédiée aux clés privées utilisées pour signer des actifs numériques. Le principe tient en une phrase : on divise une clé en plusieurs fragments, on les conserve séparément et on ne les reconstitue pas non plus lors de la signature.
Voici, en quelques points, ce que dit le document officiel :
1. Le problème de l’ancienne méthode : conserver une clé privée complète dans un module matériel de sécurité crée un point de défaillance unique. La copier sur plusieurs machines et dans plusieurs régions améliore la disponibilité, mais chaque copie contient toujours la clé privée complète : cela revient à multiplier les portes que l’on peut forcer.
2. La méthode proposée : la signature à seuil (le document mentionne une extension renforcée du protocole DKLS23). Plusieurs participants indépendants génèrent et conservent chacun leur propre « fragment de clé ». Lors de la signature, ils calculent ensemble une signature valide, sans qu’aucun endroit ne reconstitue la clé privée complète.
3. Limites de sécurité : si le nombre de participants compromis est inférieur au seuil, il est impossible de falsifier une signature ou de reconstituer la clé privée. Même si quelques participants sont hors ligne ou définitivement endommagés, les autres peuvent toujours signer dès lors qu’ils sont assez nombreux pour atteindre le seuil.
4. Exemple (en substance, selon le document) : trois personnes de l’équipe financière détiennent chacune un fragment ; deux d’entre elles doivent être d’accord pour signer.
5. Compatibilité : la courbe secp256k1, utilisée par Bitcoin, Ethereum et les chaînes EVM ; Ed25519 (Solana) est indiqué comme « bientôt disponible ». Le produit est actuellement en préversion (Pre-GA).
Quelques précisions en toute franchise :
· Le document contient une remarque très honnête : les règles de transaction (par exemple les limites ou les listes d’autorisation) ne font que recommander « autoriser » ou « refuser ». Si suffisamment de signataires donnent leur accord, une transaction refusée par les règles peut tout de même être exécutée. Le seuil protège contre la compromission d’un seul endroit, pas contre le fait que suffisamment de personnes se fassent piéger ensemble.
· Diviser une clé ne signifie pas que l’argent est en sécurité. Si les signataires se font hameçonner ou si le processus d’approbation n’est qu’une formalité, un incident peut tout de même se produire.
· Le rapport technique complet sur l’origine exacte du vol de cette semaine n’a pas encore été publié. Je ne vais donc pas plaquer le MPC sur cet incident, ni prétendre que « l’utiliser empêche les vols ».
· Les particuliers n’ont pas besoin de services de conservation institutionnels, mais le principe reste valable : ne stockez pas votre phrase de récupération en un seul endroit, et ne la photographiez pas en entier pour la mettre dans le cloud.
Votre phrase de récupération est-elle actuellement « conservée en un seul exemplaire, à un seul endroit » ou « copiée en plusieurs exemplaires, à plusieurs endroits » ?
#MPC #钱包安全 #Vulgarisation
Cette semaine, c’est le portefeuille chaud d’une plateforme d’échange qui a été vidé. La même semaine, je suis allé consulter un document produit de Google Cloud : Multi-party Compute (conservation par calcul multipartite), une solution dédiée aux clés privées utilisées pour signer des actifs numériques. Le principe tient en une phrase : on divise une clé en plusieurs fragments, on les conserve séparément et on ne les reconstitue pas non plus lors de la signature.
Voici, en quelques points, ce que dit le document officiel :
1. Le problème de l’ancienne méthode : conserver une clé privée complète dans un module matériel de sécurité crée un point de défaillance unique. La copier sur plusieurs machines et dans plusieurs régions améliore la disponibilité, mais chaque copie contient toujours la clé privée complète : cela revient à multiplier les portes que l’on peut forcer.
2. La méthode proposée : la signature à seuil (le document mentionne une extension renforcée du protocole DKLS23). Plusieurs participants indépendants génèrent et conservent chacun leur propre « fragment de clé ». Lors de la signature, ils calculent ensemble une signature valide, sans qu’aucun endroit ne reconstitue la clé privée complète.
3. Limites de sécurité : si le nombre de participants compromis est inférieur au seuil, il est impossible de falsifier une signature ou de reconstituer la clé privée. Même si quelques participants sont hors ligne ou définitivement endommagés, les autres peuvent toujours signer dès lors qu’ils sont assez nombreux pour atteindre le seuil.
4. Exemple (en substance, selon le document) : trois personnes de l’équipe financière détiennent chacune un fragment ; deux d’entre elles doivent être d’accord pour signer.
5. Compatibilité : la courbe secp256k1, utilisée par Bitcoin, Ethereum et les chaînes EVM ; Ed25519 (Solana) est indiqué comme « bientôt disponible ». Le produit est actuellement en préversion (Pre-GA).
Quelques précisions en toute franchise :
· Le document contient une remarque très honnête : les règles de transaction (par exemple les limites ou les listes d’autorisation) ne font que recommander « autoriser » ou « refuser ». Si suffisamment de signataires donnent leur accord, une transaction refusée par les règles peut tout de même être exécutée. Le seuil protège contre la compromission d’un seul endroit, pas contre le fait que suffisamment de personnes se fassent piéger ensemble.
· Diviser une clé ne signifie pas que l’argent est en sécurité. Si les signataires se font hameçonner ou si le processus d’approbation n’est qu’une formalité, un incident peut tout de même se produire.
· Le rapport technique complet sur l’origine exacte du vol de cette semaine n’a pas encore été publié. Je ne vais donc pas plaquer le MPC sur cet incident, ni prétendre que « l’utiliser empêche les vols ».
· Les particuliers n’ont pas besoin de services de conservation institutionnels, mais le principe reste valable : ne stockez pas votre phrase de récupération en un seul endroit, et ne la photographiez pas en entier pour la mettre dans le cloud.
Votre phrase de récupération est-elle actuellement « conservée en un seul exemplaire, à un seul endroit » ou « copiée en plusieurs exemplaires, à plusieurs endroits » ?
#MPC #钱包安全 #Vulgarisation
