Thursday, 20 August 2015
|
Écrit par
Grégory Soutadé

Tout le monde connaît le Bitcoin, au moins de nom. Un truc obscure, monnaie virtuelle qui fonctionne en réseau, ou quelque chose comme ça...

Le Bitcoin en tant que monnaie virtuelle a beau être volatile, on ne peut s'empêcher de penser que son taux a fait fois 10 000 en quelques années (création en février 2009), et, peut-être regretter de ne pas s'y être intéressé avant.

Pour cet article, je laisserai de côté les questions morales de son utilisation, souvent liées à des activités frauduleuses.

Récemment, j'ai organisé une collecte de fond auprès des collègues de travail. En plus des traditionnels liquides, chèques, virements bancaires et Paypal, j'ai aussi proposé en l'air le Bitcoin.

J'ai donc cherché des outils pour manipuler cette devise et suit tombé sur Electrum. il s'agit d'un client (SPV) très complet qui a deux avantages majeurs :

  • Le portefeuille est en local
  • Il a une interface en ligne de commandes

C'est en voyant des termes barbares (UTXO, merkel root...), que j'ai commencé à me demander "Comment fonctionne réellement le Bitcoin ?". Je suis alors tombé sur le site bitcoin.org qui propose énormément de ressources sur cette crypto monnaie, et tout particulièrement la section "développeur" (en anglais uniquement) vraiment très bien expliquée. Je vais essayer de résumer les concepts clés à travers cet article. Tous les schémas proviennent de la page développeurs.

Bitcoin en interne

En plongeant des les détails techniques, on se rend compte que le Bitcoin est bien plus qu'une monnaie virtuelle. Nous avons affaire à un véritable système de transactions ! D'un point de vue théorique et mathématique, le système est très pur (extrêmement bien conçu). Pour autant, il n'y a rien de vraiment "neuf", mais c'est un assemblage très élégant de concepts modernes.

Comme je l'ai dit plus haut, le système Bitcoin est avant tout un système de transactions. On ne possède pas directement des bictoins, mais le droit d'utiliser le montant d'une transaction précédente. Comme illustré ci-dessous :

Propagation des transactions

Dans le schéma ci-dessus, il est question de satoshis, pour être au clair :

  • 1.0 = 1 bitcoin (BTC)
  • 1/100 (0.01) BTC = 1 bitcent (cBTC)
  • 1/1000 (0.001) BTC = 1 millibitcoin (mBTC)
  • 1/100000 (0.000001) BTC = 1 microbitcoin (uBTC, “bits”)
  • 1/10000000 (0.00000001) = 1 satoshi

1 Satoshi est donc un dix millionième bitcoin, c'est l'unité minimale.

L'utilisateur a donc à disposition des Unspent Transaction Outputs (UTXO). C'est-à-dire, des sorties de transactions non dépensées, donc non utilisées par des entrées de transactions suivantes.

Lors de la création d'une nouvelle transaction, il faut indiquer le(s) numéro(s) de(s) la sortie(s) précédente(s).

La phobie du concepteur (et des utilisateurs) étant la double dépense (double spent) : qu'un utilisateur dépense deux fois sa monnaie. C'est particulièrement vrai par le fait que les transactions ne sont intégrées au réseau de façon sûre qu'à partir de 10 minutes, avec la validation d'au moins un nœud (transaction valide à 75%). C'est l'effet P2P.

Pour éviter la double dépense, le réseau doit donc s'assurer que les sorties ne sont utilisées qu'une seule fois.

L'ensemble des transactions sont conservées à vie dans la "blockchain", une sorte de grand livre des comptes. On peut ainsi vérifier TOUTES les transactions depuis le bloc (genesis block).

Aperçu de la Blockchain

Cette blockchain est maintenue via un réseau pair à pair (peer-to-peer/P2P, comme bittorent) dans lequel des serveurs vérifient et insèrent les transactions. Mais, pour avoir le droit d'insérer des transactions, il faut fournir une preuve de travail. Preuve qui peut aussi rapporter des bitcoins (c'est le minage/mining) aussi appelée coinbase (transaction de base qui permet de créer des bitcoins).

La preuve de travail est simple : L'entête fait 80 octets, avec notamment 4 octets de libre. Pour avoir le droit d'insérer la transaction, il faut trouver une combinaison telle que le résultat de la fonction de hashage sha256 de l'entête soit inférieure à une valeur décidée par le réseau. Cette valeur est mise à jour tous les 2016 blocs. Pour schématiser :

SHA256(header) <= 00000000XXXXXXXXXXXXXXXXXXXXXXX.

Il est prévu que l'insertion de 2016 blocs dure environ deux semaines. Si ce n'est pas le cas, la difficulté pour insérer les blocs est augmentée ou diminuée consensuellement.

Si un attaquant veut modifier une transaction, il doit détenir 51% de la puissance de calcul du réseau afin de la faire accepter aux autres pairs.

Qui dit travail, dit récompense. Les serveurs qui insèrent vos transactions dans la blockchain s'assurent de la validité de celles-ci. En échange, l'utilisateur paie des frais de transaction (fees). Ces frais sont variables d'un serveur à l'autre, le minimum étant 10 000 satoshis. Au final, ce système peut rapporter pas mal aux serveurs en place.

On notera l'utilisation d'un arbre de Merkle pour la partie données. Le principe est le suivant : La valeur du niveau n est la valeur du hash de ses descendants de niveau n+1, jusqu'à la racine (merkle root).

La partie de données peut contenir de une à n transactions (groupées par bloc/block). Empaqueter un ensemble de transactions permet de mutualiser l'entête, donc de réduire le travail à fournir.

Description d'une transaction

Mais, si on regarde d'encore plus près, on se rend compte à quel point le Bitcoin est un système fascinant. En effet, une transaction est composée d'un index (pour l'identifier dans un bloc de la blockchain), d'un locktime, des indexes des transactions d'entrée et d'un script !

Le langage utilisé est un dérivé du Forth, un langage de programmation à pile. Il détermine les conditions pour lesquelles la transaction est valide. Le montant est la somme de toutes les entrées et peut être divisé en plusieurs sorties.

Le script lui-même contient les clés publiques, les signatures et demande (le plus souvent) à ce que 1 à n signatures soient présentent et valides. Ce script doit être approuvé par le receveur.

La durée de verrouillage (locktime) est la durée durant laquelle la transaction ne peut être intégrée à la blockchain. Si l'émetteur change d'avis avant la durée du lock, il peut envoyer une transaction d'annulation (qui utilisent les mêmes entrées et donc rend caduque la transaction précédente qui n'a pas encore été insérée, quitte à se retourner ses propres bitcoins).

Côté signature, Bitcoin utilise les courbes elliptiques 256 bits ainsi que du SHA256. Les données (notamment les clés) étant présentées en base 58 pour être "plus" facilement lisibles.

Dans le cas où le montant des entrées (inputs) est supérieur à celui des sorties (outputs), la différence est encaissée par le serveur au titre de frais de transaction. Si le montant total des entrées (indivisible) est largement supérieur à que l'on souhaite dépenser, on va ajouter une transaction supplémentaire vers notre propre portefeuille pour encaisser le surplus. L'adresse de réception est dans ce cas dénommée adresse de "change" (change address).

Cas d'utilisation

La souplesse du système (malléabilité des transactions/transaction malleability) amène à plusieurs cas d'utilisations.

Le cas le plus classique est la transaction simple : le script contient la clé publique de l'émetteur, sa signature et demande la vérification de ces deux éléments.

Là où ça devient drôle, c'est dans le cas de signatures multiples.

Le contrat "d'escrow" par exemple. Il s'agit d'un type de contrat qui implique deux acteurs et un arbitre. Pour qu'il soit valide, il faut deux signatures. En cas de conflit, les deux acteurs se tournent vers l'arbitre. Celui-ci propose une solution (remboursement à hauteur de X%) et émet une transaction qui doit être signée par au moins un des deux acteurs (en plus de sa propre signature).

Autre exemple qui implique un verrouillage : le micro paiement à la tâche. Bob veut payer 100 satoshis à Alice (correspondant à 100% de ses objectifs). Il crée alors deux transactions. La première contient les 100 satoshis à destination d'Alice et la seconde utilise la sortie de la première (le compte d'Alice) et retourne les satoshis à Bob avec une durée de verrouillage de 24h. Ell aura comme numéro de séquence 1.

En fin de journée, Alice fait signer à Bob un "bon" (bond) comme quoi elle n'a réalisée que 70% du travail. Elle va donc créer une transaction qui va rembourser Bob de 30 satoshis (en utilisant la sortie de la première transaction) avec un numéro de séquence > 1. Une fois signée par Bob, elle pourra l'envoyer au réseau (broadcast). Il faudra bien sûr l'envoyer avant la réalisation de la seconde transaction (plus le temps de traitement). Si tout se passe bien, la second transaction (numéro de séquence 1) ne sera plus valide.

Entre temps, Alice peut envoyer à Bob plusieurs bons (en incrémentant le numéro de séquence), sans les émettre sur le réseau. C'est un exemple de transaction "privées" (non émise).

Dernier exemple : pour brouiller les pistes quant au traçage des bitcoins, plusieurs personnes peuvent créer une transaction à signature multiple dans laquelle ils vont provisionner à valeur égale une certaine somme. La sortie sera mélangée et redistribuée à chacun d'entre eux (à parts égales). C'est ce qu'on appelle le CoinJoin.

Anonymité du Bitcoin

Contrairement à ce que l'on pense, le Bitcoin n'est pas anonyme, puisque toutes les transactions sont enregistrées à vie dans la blockchain. Du coup, si on arrive à associer une adresse à une personne, on a accès à toutes ses transactions. Pour pallier à cela, il est recommandé d'utiliser une adresse publique différente lors de chaque transaction.

Gestion des clés

Dérivation de la clé maître

Le portefeuille (wallet) qui stocke les Bitcoin contient une clé maître générée à partir d'une graine (seed). La clé maître génère elle-même n sous clés (publiques et privées). Les propriétés des courbes elliptiques permettant, en effet, de tout dériver à partir de la graine (Il est donc important de bien la protéger !).

Ceux qui ne comprennent pas la notion de clé publique/privée pourront jeter un œil sur l'articule Wikipedia consacré à la cryptographie asymétrique. Globalement, la clé privée permet de signer une transaction et sa correspondante publique permet de vérifier la signature. On diffuse la publique et on garde secrètement la privée.

La valeur du porte-monnaie sera donc celle de la somme de toutes les transactions de sortie non dépensées (UTXO) de toutes les sous-clé publiques.

Sécurité du Bitcoin

Bitcoin est utilisée comme monnaie virtuelle, on n'en voit jamais la couleur. Finalement, ce n'est pas si différent de nos comptes bancaires directement crédités par l'employeur et débités via des cartes bancaires. Néanmoins, après le casse du siècle sur le site Mt. Gox où des centaines de milliers de bitcoins ont disparus, on peut se poser la question de la sécurité.

Il existe plein de services sur Internet qui disent tout gérer pour vous. Votre portefeuille se retrouve en ligne, et on y accède via un compte. Si le serveur se fait pirater, tout est perdu !

La solution originale est d'exécuter sur sa machine les utilitaires bitcoin et bitcoind afin de gérer à 100% son installation (et accessoirement se passer de frais de transactions). Un peu lourd quand on connaît la taille actuelle de la blockchain (plus de 37GB)...

L'alternative qui a été développée est un gestionnaire de portefeuille qui utilise le Simplified Payment Verification (SPV) ou encore Vérification Simple des Paiements. Electrum fait partie de ceux-ci. Cette alternative offre l'avantage d'avoir un portefeuille en local sur la machine, mais d'utiliser un serveur distant pour l'insertion des transactions. Il ne va télécharger que quelques morceaux de la blockchain lorsqu'il devra vérifier une transaction. Reste éventuellement le problème de la synchronisation entre plusieurs périphériques (ordinateurs, tablettes, smartphones...)

Le Bitcoin ayant un équivalent (volatile) en euros, il est important de bien stocker le portefeuille, de le dupliquer, et même de le chiffrer (même si la graine est sensée déjà l'être).

Conclusion

Le système Bitcoin est un projet extrêmement bien pensé et a sûrement été réfléchi et mûri pendant des années avant d'apparaître sur la toile. Sa conception est un véritable travail de chercheur !

Malgré ses 6 ans d'âge, l'engouement reste assez limité, clairement dû à la volatilité du cours. Et même s'il a fait des petits, ses concurrents tels que litecoin, peercoin, dogecoin... restent très méconnus et beaucoup moins utilisés.

La qualité de bitcoin.org est le reflet d'une communauté très active qui essaie de promouvoir l'utilisation de sa crypto monnaie. Un exemple de ce dynamisme est l'utilisation d'URL simplifiée bitcoin:// pour réaliser des transactions ou encore l'utilisation des Codes QR.

Le Bitcoin est-il une autre bulle qui explosera ? À voir. Le traçage de plus en plus systématique et important de la population l'amènera peut être à détrôner un jour le système bancaire classique...

Sunday, 09 August 2015
|
Écrit par
Grégory Soutadé

Now I have a Cubox (i2ex), I wanted to encrypt my backup disks. I followed this excellent tutorial. The cipher recommendation is aes-xts-plain64. So, I created formated disk, encrypt it, copy data from my computer and connect it to the Cubox.

But, I get this error :

cryptsetup --type luks open /dev/sda1 backup
Enter passphrase for /dev/sda1: 
No key available with this passphrase.

I tried a couple of times, use a keyfile. Nothing worked !! It made me crazy. After a bunch of search, I found that the current kernel in the Debian image from Igor Pečovnik is 3.14.14 and has issues with NEON AES implementation.

I cannot blacklist the module as it's builtin. The solution is to build a new module from the latest 3.14.49 kernel (maintained by Greg Kroah-Hartman). Ouf ! I increased cra_priority to be sure to use the new implementation.

Instructions

In the Cubox :

  • Install kernel headers (already here in the image)
  • Download the latest 3.14 kernel from kernel.org
  • Decompress it
  • Apply this patch
  • Compile
  • Install
  • Reboot

Commands :

patch -p1 < crypto.patch
cd linux-3.14.49/arch/arm/crypto/
make
sudo make install
sudo echo aes-arm-bs >> /etc/modules
reboot

If you just want to test :

insmod aes-arm-bs.ko

Precompiled version

A precompiled version is available here. To manually install it :

sudo cp aes-arm-bs.ko /lib/modules/3.14.14-cubox-i/extra/
sudo depmod
sudo echo aes-arm-bs >> /etc/modules

Or just

sudo make install
sudo echo aes-arm-bs >> /etc/modules
Tuesday, 04 August 2015
|
Écrit par
Grégory Soutadé

Gâteau anniversaire 5 ans

Déjà 5 ans ! Les nostalgiques diraient que le temps passe vite. C'est vrai. Il s'en est passé des choses depuis août 2010. Des bonnes, des moins bonnes, la vie quoi... 5 ans, c'est le début de la maturité, du moins pour le blog et les services associés !

Pour cet anniversaire, et parce que les conditions physiques le permettent, je me suis fait un petit cadeau : Déméter.

Quésako ? C'est mon nouveau serveur qui remplace désormais Cybelle. Comme je l'avais annoncé précédemment, il s'agit d'une Cubox i2ex (sans Wifi & bluetooth). On passe ainsi d'un arm11 1,2Ghz avec 512MB de mémoire à un double cortex A9 1Ghz et 1GB de mémoire. La différence ? Trois à quatre fois plus rapide (à la louche) pour une taille diminuée par deux ! C'est surtout visible pour toute la partie dynamique (recherche/forge...). Autre avantage : la Cubox chauffe moins. La fréquence n'est pas plus haute, mais l'architecture est plus optimisée (ARMv6 vs ARMv7), la mémoire plus importante et surtout plus rapide.

SheevaPlug vs Cubox

Point important indirectement lié au nouveau serveur : le temps de présence en ligne (uptime) est maintenant de 24h dans une journée ! Au revoir Orange et son changement d'IP qui nous grève d'une heure. Et bientôt, il y aura même de l'IPv6 (si SFR se décide à mettre à jour ses box Virgin...).

Je dois dire que la migration ne s'est pas faite sans douleur. L'avantage est que j'avais des configurations déjà toutes prêtes, mais, ne pas suivre la procédure d'installation depuis le début amène d'autres problèmes (oubli de modules, de paramètres...). J'ai eu la joie de replonger dans la configuration de postfix/dovecot... aïe ! Aujourd'hui tout semble stabilisé.

Rassurez-vous, Cybelle ne part pas au rebut ! Elle servira de serveur de secours distant en cas de défaillance de Déméter. D'ailleurs, un article est prévu pour parler des mécanismes mis en place à ce sujet.

Concernant le blog en lui même : moins d'articles, mais plus intéressants. Particulièrement tout ce qui tourne autour des liseuses Bookeen avec un jailbreak à la clé (ce qui a demandé pas mal de travail).

L’outil de statistique (iwla) arrive également à maturation. Pour autant, le passage à Debian 8 a fortement perturbé le mois de mai (merci logrotate et la nouvelle conf Apache). Il a donc été moyenné par rapport aux trois mois précédents.

Revenons aux statistiques pures avec les 10 articles les plus consultés (en gras, consultation principalement pour les images. Entre parenthèses, l'année de publication) :

Il y a beaucoup de visites qui se font sur la page d'accueil (donc non comptabilisées). Mais, avec 5 articles de moins d'un an dans le top 11, c'est vraiment pas mal. Le top 2 reste inchangé. Ces 11 articles représentent 27% des pages affichées (au moins).

Des chiffres, encore (entre parenthèses, les années précédentes) :

  • 34 articles publiés (49, 50, 60, 60)
  • 21 300 visites (25 000, 12 000, 18 000, 9 000)
  • 9 Go de données envoyées (5.5, 2.7, 2.5)
  • 23 000 pages affichées

Des chiffres plutôt stables (hormis le nombre d'articles), avec une moyenne de 58 visites par jour, ce qui est plutôt bien.

Quid de la suite ? Améliorer l'existant (passage en Python 3), une petite application de notes en vue et, dans l'idéal, refaire le style CSS du blog. Vu le temps disponible, ce sont des objectifs réalisables sur ... un an, à moins qu'il ne commence enfin à pleuvoir en continu durant trois/quatre mois :)

Thursday, 16 July 2015
|
Écrit par
Grégory Soutadé

Capture d'écran IWLA

Deuxième version d'IWLA, le clone d'AWSTATSl'analyseur de log web écrit en Python.

Qu'est ce qu'on trouve dans cette version ? Et bien ... tout. Cette version arrive au niveau d'AWSTATS en ce qui concerne mon usage, et même le dépasse !

Quelques fonctions non présentes dans AWSTATS :

  • (Meilleure) Détection des robots
  • Affichage des différences entre deux analyses
  • Ajout facile des ses propres moteurs de recherche
  • Traçage d'IP
  • Détection de lecteur de flux RSS
  • Support des fichiers de log compressés

Pour le reste, on retrouve toutes les briques de bases. Mon seul regret est de n'avoir pas encore mis en place les tests automatiques.

Monday, 06 July 2015
|
Écrit par
Grégory Soutadé

Bookeen doesn't provides any way to hack their e-ink e-readers. Nevertheless, after they introduce a secured update file format for the first Cybook serie, they come back to a "tar-like" format for their e-readers based on Allwiner platform (new Odyssey, Muse, Nolimbook...). With this format, they try to be closest to Android platform.

Be careful : handling all bookeen's readers is difficult because there is a lot of derived/customized readers available ! For this, Bookeen has its own server that checks for serial number to determine which update to serve. A special attention must be done with manipulating boot and bootloader images, it can bricks your e-reader !

This tutorial will only works with UNIX/Linux tools, I do not plan to do it for Windows.

So, let's start. An archive is commonly named CybUpdate.bin. In facts it's a .tar.bz2 file.

First, decompresse it :

mkdir decompressed
cd decompressed
tar -jxvf ../CybUpdate.bin

The following content should be created :

contents
bootloader.fex
boot.fex
rootfs.fex

I think that boot.fex and bootloader.fex are optional, but not sure. Two types of files are present :

  • contents that contains meta information
  • fex files

Contents has the following format :

<ident>|<filename>|<length>|<sha256sum>|<version>

idents are :

  • LOAD for bootloader
  • BOOT for boot partition
  • ROOT for rootfs

Fex extension is a generic one that actually is flash images in different format (vfat, ext...).

In bootloader.fex and rootfs.fex we have a file "/version" specifying the current version (allowing to do checks). Mounting bootloader and rootfs is quite easy :

mkdir root
sudo mount -t ext2 rootfs.fex root -o loop

mkdir bootloader
sudo mount -t vfat bootloader.fex bootloader -o loop

After doing modifications, just unmount the directory and the image is automatically generated ! (Don't forget to update contents metadata).

boot.fex is more complex, it has Android bootloader format. You have to use split_bootimg.pl to decompress it.

mkdir boot
cd boot
../split_bootimg.pl ../boot.fex
> Page size: 2048 (0x00000800)
> Kernel size: 10863524 (0x00a5c3a4)
> Ramdisk size: 2253456 (0x00226290)
> Second size: 0 (0x00000000)
> Board name: sun5i
> Command line: 
> Writing boot.fex-kernel ... complete.
> Writing boot.fex-ramdisk.gz ... complete.

Then we decompress ramdisk :

mkdir ramdisk_decompressed
cd ramdisk_decompressed
gzip -dc ../boot.fex-ramdisk.gz | cpio -i

You can re compress it with :

find | cpio -o | gzip -c > ../boot.fex-ramdisk.gz

Rebuilding boot is done with mkbootimg. Be careful to use the same parameters split_bootimg.pl displayed !

./mkbootimg.py --kernel boot.fex-kernel --ramdisk boot.fex-ramdisk.gz --pagesize 2048 --board sun5i -o ../boot.fex

As you see, there is nothing complicated here, but mistakes with boot/bootloader or init scripts can bricks your e-reader.

Have fun !

Dernier gif les joies du code Git push --force