Bitcoin/Clés : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
m (Porte-clés)
m (Pages connexes)
 
(13 révisions intermédiaires par 3 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
  
==Clés==
 
  
* les paiements sont signés (grâce à de la [[cryptographie]] réputée incassable/infalsifiable)
+
==Clé publique==
* aucune nécessité de trimbaler le porte-monnaie. Il faut par contre avoir la clé d'accès à son adresse (compte). En fait, c'est la clé (privée) qui génère l'adresse.
 
  
* détenir des bitcoins, c'est posséder des clefs privées de compte publics.
+
La clé publique est calculée à partir de la clé privée en utilisant l’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm).
  
* il est parfaitement idiot (sauf pour de petites sommes) de stocker ses clés sur un site truc ou machin
+
* https://fr.wikipedia.org/wiki/Elliptic_curve_digital_signature_algorithm
** le site peut être piraté, du dehors ou du dedans (complicités internes, voire le patron) ... et on est dépouillé. Les arnaques se comptent par dizaines et sont régulières.
 
** pour des pirates, tant qu'à mener des attaques, autant attaquer des lieux où se trouvent des centaines de clés
 
** il est plus sûr de stocker ses clés sur du matériel personnel, par exemple du matériel déconnecté d'internet
 
  
* à chaque fois qu'une clé circule (sur un fil, dans l'ordi, ou via wifi) elle est potentiellement vulnérable
+
* https://www.miximum.fr/blog/tout-savoir-sur-les-adresses-bitcoin/
** en conséquence, c'est la réduction du nombre de transmission(s) qui doit être visée
 
 
 
* la clé publique et l'adresse bitcoin sont générées à partir de la clé privée
 
  
 
<br>
 
<br>
Ligne 31 : Ligne 23 :
  
 
La séquence est la suivante :  
 
La séquence est la suivante :  
* la clé privée est fabriquée n'importe comment. Prise éventuellement au hasard dans {0, 2^^64})
+
* la clé privée est fabriquée n'importe comment. Prise éventuellement au hasard dans {0, 2^^64}
 
* la clé publique est générée à partir de la clé privée (l'inverse est impossible)
 
* la clé publique est générée à partir de la clé privée (l'inverse est impossible)
 
* l'adresse est générée à partir de la clé publique (l'inverse est impossible)
 
* l'adresse est générée à partir de la clé publique (l'inverse est impossible)
 +
 +
Le protocole Bitcoin utilise la courbe <i>secp256k1</i> :
 +
* qui a priori n'est pas dans openssl
 +
* https://packages.debian.org/stretch/libsecp256k1-0
 +
  
 
Normalement, il y a infiniment peu de chances de se choisir une clé privée déjà existante.
 
Normalement, il y a infiniment peu de chances de se choisir une clé privée déjà existante.
 
(mais au pire, on peut vérifier si la clé publique (ou l'adresse) n'existe pas déjà)
 
(mais au pire, on peut vérifier si la clé publique (ou l'adresse) n'existe pas déjà)
 
<br>
 
 
==Clé privée==
 
 
<pre>
 
ex :
 
4300d94bef2ee84bd9d0781398fd96daf98e419e403adc41957fb679dfa1facd
 
0123456789012345678901234567890123456789012345678901234567890123
 
</pre>
 
 
64 chiffres hexadécimaux => 16⁶⁴ possibilités, 16⁶⁴ = 1.15⁷⁷
 
 
Tel quel, c'est assez spacieux pour y choisir sa clé sans qu'elle puisse être devinée.
 
 
Une clé privée sert :
 
* à chiffrer des messages (en l'occurrence des transactions)
 
* à générer une clé publique permettant le déchiffrage des messages/transactions
 
* à générer une adresse (n° de compte)
 
 
 
Problème : le propriétaire d'une telle clé va forcément chercher des astuces pour pouvoir <b>retrouver facilement</b> cette clé.
 
 
Et attention ici au sens de l'expression "retrouver facilement".
 
 
Si on traduit "retrouver facilement" par mémoriser facilement
 
... alors, par construction, on va forcément passer de l'espace immense de départ (1.15x10⁷⁷)
 
à un espace plus réduit ... et qui peut donc se prêter plus facilement à des tentatives d'explorations.
 
 
Si vous songez à prendre <b>un</b> mot du dictionnaire (eg dans un dico standard de 50.000 mots) avec un coup de sha256 par dessus;
 
vous passez d'un espace 1.15x10⁷⁷ à 5x10⁴.
 
C'est tout simplement 10⁷³ fois plus petit, et facilement explorable (et exploré) par ordinateur.
 
Et oui, des gens ont eu l'idée (et ça n'a pas été long) de passer tout le dictionnaire à la moulinette sha256,
 
et à défaut de disposer d'une fonction inverse de sha256,
 
ils disposent donc de cette fonction inverse sur un espace de départ certes petit ... mais peut-être pertinent (car quelques naïfs l'ont utilisé).
 
 
La clé publique et l'adresse sont déduites de la clé privée (par d'autres fonctions de [[hash]]) :
 
* Clé publique = f(clé privée) = clé privée * base point
 
* Adresse = g(clé publique)
 
* Adresse = g(f(clé privée)) = h(clé privée)
 
 
Ici aussi, des personnes ont appliqué la fonction h sur tout le dictionnaire,
 
et si une adresse présente dans la blockchain a le malheur d'appartenir à l'espace 5x10⁴ du dictionnaire,
 
il suffit de la comparer aux résultats stockés de h(dico) pour la cibler et retrouver instantanément la clé privée génératrice.
 
  
 
<br>
 
<br>
Ligne 94 : Ligne 47 :
 
* si vous stockez mal votre clé, idem
 
* si vous stockez mal votre clé, idem
  
Les techniques de [[cryptographie]] employées par bitcoin reposent sur la non-inversibilité de fonctions de [[hash]].
+
Les techniques de cryptographie employées par bitcoin reposent sur la non-inversibilité de fonctions de hash.
 
Employées "pleinement", ie comme il faut, ces techniques (open, auditées et maintenues par une large communauté) sont par elle-mêmes inviolables.
 
Employées "pleinement", ie comme il faut, ces techniques (open, auditées et maintenues par une large communauté) sont par elle-mêmes inviolables.
 
(C'est le fait que ces techniques soient open, auditées et maintenues par une large communauté, qui constitue la "garantie" offerte par bitcoin).
 
(C'est le fait que ces techniques soient open, auditées et maintenues par une large communauté, qui constitue la "garantie" offerte par bitcoin).
Ligne 151 : Ligne 104 :
  
 
==Pages connexes==
 
==Pages connexes==
* [[Cryptographie]]
 
 
* [[R-Project/Package digest]]
 
* [[R-Project/Package digest]]
* [[Hash]]
 
* [[Multisignature]]
 
  
 
<br>
 
<br>

Version actuelle datée du 19 août 2023 à 08:52


Clé publique

La clé publique est calculée à partir de la clé privée en utilisant l’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm).


Technique

  • exemple d'adresse :
1J3BnzUeHubrjdMuBjSPtpUy2wv7RchNyy
0123456789012345678901234567890123
  • Les adresses sont codées sur 34 caractères en base 58
  • (26 majuscules + 26 minuscules + 10 chiffres) = 62 - 4 caractères ambigus (i,I,o,O)

La séquence est la suivante :

  • la clé privée est fabriquée n'importe comment. Prise éventuellement au hasard dans {0, 2^^64}
  • la clé publique est générée à partir de la clé privée (l'inverse est impossible)
  • l'adresse est générée à partir de la clé publique (l'inverse est impossible)

Le protocole Bitcoin utilise la courbe secp256k1 :


Normalement, il y a infiniment peu de chances de se choisir une clé privée déjà existante. (mais au pire, on peut vérifier si la clé publique (ou l'adresse) n'existe pas déjà)


Sécurité

Quelques points à bien comprendre sont que, avec les monnaies électroniques (et pas juste les crypto-monnaies) :

  • les cambrioleurs peuvent s'atteler à leur travail de façon bien plus tranquille (un ordinateur + connexion internet)
  • une banque classique joue le rôle de tiers de confiance, mais aussi de gardienne de vos fonds. Avec le BTC, cette tierce partie a disparu, c'est à vous de vous occuper de la sécurité de vos fonds
  • vous pouvez bien sûr déléguer cette fonction ... mais il faut bien comprendre que cela vous renvoie quasi intégralement dans le schéma bancaire classique, avec le petit plus que les nouveaux intervenants n'ont pas du tout la fiabilité ni la réputation des banques classiques. Les cas de banquiers bitcoins partis avec la caisse sont nombreux !

Dans le cas du bitcoin, l'essentiel des considérations de sécurité portent sur la sécurité des clés.

  • si vous vous fabriquez une clé de mauvaise qualité ... vous en paierez le prix
  • si vous stockez mal votre clé, idem

Les techniques de cryptographie employées par bitcoin reposent sur la non-inversibilité de fonctions de hash. Employées "pleinement", ie comme il faut, ces techniques (open, auditées et maintenues par une large communauté) sont par elle-mêmes inviolables. (C'est le fait que ces techniques soient open, auditées et maintenues par une large communauté, qui constitue la "garantie" offerte par bitcoin).

Comprendre/connaître le minimum nécessaire concernant ces techniques n'est pas bien difficile.

L'utilisateur qui décide (consciemment ou pas) de ne pas utiliser ces techniques conformément à leur bonne utilisation, s'expose forcément à en subir le contrecoup. Une tronçonneuse, une voiture, un hachoir à légumes, sont aussi des objets techniques performants. Si vous les manipulez sans comprendre les rudiments de sécurité les concernant, vous vous exposez au danger.

Le "stockage à froid" semble la technique la plus sensée.


Porte-clés

On peut essayer d'empiler les niveaux de protection :

  • les clés ultimement stockées sur une clé usb. Il existe même des clés dédiées.
  • les clés éclatées en plusieurs morceaux, chaque morceau stocké sur un support différent
  • les adresses de comptes étant des adresses multisignature (une autre forme de la soluce ci-dessus)
  • les éventuelles connexions se faisant via un raspberry pi sous raspbian ou une distro plus secure, genre tail
  • toute combinaison des techniques ci-dessus


Il faut être conscient qu'aujourd'hui, il circule énormément de virus dont la fonction principale est d'explorer l'ordinateur où ils se trouvent à la recherche de fichiers contenant des clés privées puis d'exfiltrer les résultats vers les cybercambrioleurs à l'origine de ces virus.


Le stockage de clés sur support non connecté à internet est appelé stockage à froid. C'est le mode de stockage le plus recommandé, mais il n'est pas non plus invulnérable.

  • En effet, même si on manipule ses clés en étant déconnecté d'internet, rien n'empêche en théorie un virus adroit de recopier les clés sur un ordinateur hôte lors d'une insertion de la clé, et si l'ordinateur hôte est infecté, c'est lui qui se chargera d'une transmission via internet à la prochaine connection. Cela nécessite certes un virus sophistiqué, présent sur la clé USB et sur l'ordinateur hôte, et travaillant de manière synchronisé ... mais en théorie, c'est faisable.
  • même avec le stockage à froid, il peut y avoir des moments où l'ordinateur permettant une transaction sera à la fois connecté à internet, et les clés seront présentes. Idéalement ces moments ne devraient pas exister, mais à défaut de cet idéal, ce qu'on peut réaliser est de minimiser la durée de ces moments.


Le stockage à froid reste quand même ce qu'il y a de mieux. Au moins cela construit un sas entre les clés et internet. Les clés ne peuvent pas fuiter directement.


Liens


Pages connexes