dimanche 13 août 2017

Bitcoin : récupérer ses bitcoins cash en toute sécurité

Lors du fork de bitcoin cash (BCH) toutes les transactions jamais effectuée sur bitcoin ont été dupliquées le jour du fork. Ainsi à chaque adresse bitcoin contenant des bitcoins précédemment au fork, correspond désormais une adresse avec le même montant de bitcoin cash. C’est en quelque sorte de l’argent gratuit.

Récupérer ses bitcoin cash consiste à lister toutes les adresses bitcoins que l’on possède qui contiennent des bitcoins, récupérer les clés privées de ces adresses, et les importer dans un portefeuille qui supporte bitcoin cash. Pour ma part j’ai utilisé Coinomi sur Android

La procédure la plus simple est donc:

  • Création d’un portefeuille bitcoin cash dans Coinomi
  • Export des clés privées bitcoin de son portefeuille actuel
  • Import de ses clés privées dans Coinomi

Le problème avec cette procédure c’est que l’on expose ses clés privée à Coinomi et au logiciel intermédiaire qu’on a dû ou pas ( selon son portefeuille d’origine ) utiliser pour exporter ses clés.

Donc pour se prémunir d’un vol on va auparavant déplacer tous ses bitcoins dans un autre portefeuille. Les clés privées que l’on passera à Coinomi ne contiendront donc plus que des BCH et plus de BTC.

La procédure plus longue mais sécurisée est donc:

  • Création d’un nouveau portefeuille bitcoin dans n’importe quel portefeuille
  • Transfert de l’intégralité de ses bitcoins sur ce nouveau portefeuille
  • Création d’un portefeuille bitcoin cash dans Coinomi
  • Export des clés privées bitcoin de son portefeuille actuel
  • Import de ses clés privées dans Coinomi

Comme expliqué dans le poste précédent la clé privée que la plupart des portefeuilles logiciels vous donne à sauvegarder est une clé racine qui sert à générer une infinité d’autres clés privées de manière déterministe. La clé privée ne contient pas de bitcoin en tant que tel, mais vous permet de regénérer les clés privées qui en contiennent. Ce processus est invisible lorsque l’on sauvegarde/restorate un portefeuille mais dans le cas de la récupération des bitcoin cash on va avoir besoin d’accéder à la liste complète des clés privée.

Pour générer ses clés privées à partir de la racine secrète j’ai utilisé ce script

Et les paramètres du script à utiliser selon votre portefeuille logiciel sont disponibles sur cette page.

Il faut ensuite importer chacune des clés privées générées dans le portefeuille BCH de Coinomi. On pourra ensuite décider de les conserver ou de les échanger contre des BTC par exemple.

Bitcoin : précision sur la sauvegarde de sa/ses clés privées

Quand on importe une clé privée d’un portefeuille logiciel à l’autre ou d’un portefeuille papier à un portefeuille logiciel on a exactement les mêmes bitcoins disponibles de chaque côté.

Ainsi que l’on ait accès au logiciel contenant cette clé privée, ou à la version papier, on a complètement accès aux bitcoins qui lui sont associés.

On peut créditer l’adresse publique de ce portefeuille qu’il soit logiciel ou papier.

A noter par contre; que si l’on dépense une partie des bitcoins avec le portefeuille électronique, le portefeuille papier sera complètement vidé de ses bitcoins, car lors d’un transaction une nouvelle adresse (couple clé publique / clé privée) est générée et c’est elle qui reçoit le solde restant de bitcoins. Ce processus est automatique et invisible sur le portefeuille logiciel, il est donc important de comprendre qu’après toute dépense le portefeuille papier équivalent devient caduque, il faut en régénérer un avec la dernière adresse en date.

Lorsque l’on parle de sauvegarder sa clé privé on parle le plus souvent de la clé privée du portefeuille, mais en réalité derrière on a plein de clés privées dérivables de cette clé racine. Toute transaction bitcoin génère un nouveau couple clé publique / clé privée. A toute adresse bitcoin est associé un de ces couples de clé. Ainsi on a théoriquement autant d’adresses privées que de transactions effectuées ce qui est très pénible à sauvegarder. C’est la qu’intervient les portefeuilles dits déterministes, qui permettent de générer une infinité de clés privée à partir d’une seule clé privée racine, elle même “facilement mémorisable” car encodée sous les forme d’une liste de mots courants:

ex: “arbre boire voyage repos soleil …"

Lorsque l’on change de portefeuille logiciel, on peut créer un nouveau portefeuille et transférer ses bitcoins de l’ancien au nouveau portefeuille. On aura alors plus aucune clé privée en commun avec le portefeuille précédent, il faudra sauvegarder la nouvelle clé racine.

Dans le cas où l’on stocke ses bitcoins sur une plateforme de trading, on a pas accès à ses clés privées. C’est l’exchange qui les possède. On est donc dépendant de la sécurité du site web.

mardi 13 décembre 2016

Flash de rom Android sous OSX avec Heimdall

Quand on est habitué au logiciel Odin sous Windows, l'utilisation de Heimdall peut sembler complexe de part nécessité de préciser quelle rom flasher sur quelle partition. Pour mieux comprendre ce qu'Heimdall attend de nous, on peut utiliser les commandes suivantes afin de lister le partitionnement du téléphone connecté:
heimdall download-pit --output file.pit
heimdall print-pit --file file.pit
Lorsque l'on télécharge une rom c'est en fait un zip de plusieurs fichiers mais Odin est capable de lire dans ce zip et de destiner le bon fichier à la bonne partition. Avec heimdall on doit décompresser et dépackager la rom afin d'obtenir la liste des fichiers de rom ( fichiers .img, .mbn, .bin ...)

On va ensuite associer chacun d'entre eux à la bonne partition en fonction de leur nom. En général c'est assez explicite. Exemple si dessous pour flasher un Samsung Note 3:
heimdall flash --RECOVERY recovery.img --SYSTEM system.img.ext4 --HIDDEN hidden.img.ext4 --BOOT boot.img --MODEM modem.bin --APNHLOS NON-HLOS.bin --ABOOT aboot.mbn --BOOT boot.img --TZ tz.mbn --RPM rpm.mbn --SBL1 sbl1.mbn --DBI sdi.mbn --CACHE cache.img.ext4

mardi 29 novembre 2016

Echanger des données via iCloud, dropbox ou équivalent de manière sécurisée entre iOS et OSX

Avec un service de stockage de données en ligne comme iCloud on a plusieurs niveaux de sécurité possible:

- Est ce que le transfert descendant ou montant est chiffré ?
- Est ce que les données sont stockées chiffréee ?
- Si les données sont chiffrées, qui possède la clé privée ?

Pour iCloud, comme beaucoup de services équivalents, les données sont chiffrées sur les serveurs du fournisseur de service mais sont déchiffrables par lui même. Cela protège contre un attaque externe mais pas contre la malhonnêteté de l'entreprise.

La solution à ce problème est le chiffrage local avant tout passage par internet ou PIE (Pre Internet Encryption).

Sur iOS on peut utiliser l'application Disk Decipher qui permet d'ouvrir un conteneur Truecrypt. Ainsi on pourra stocker des données de son PC dans ce conteneur Truecrypt, l'envoyer sur un iDevice (par iCloud ou transfert local) et réouvrir ce conteneur sur l'iDevice grâce à Disk Decipher.

Depuis l'abandon dans des circonstances ombrageuse du projet TrueCrypt on ne peut plus complètement faire confiance à ce logiciel mais son alternative VeraCrypt n'est pas encore supportée par Disk Decipher. D'après le siteofficiel ce sera le cas pour la version 2.0

En attendant il faut faire attention de bien créer le conteneur avec TrueCrypt et non VeraCrypt.

A noter qu'avec ce système on perd toute finesse dans l'upload des données sur iCloud. En effet le service n'étant pas capable de voir le contenu du conteneur TrueCrypt, il ne peut pas ne réuploader que les fichiers fraichement modifiés. Tout le conteneur doit être réuploadé même pour un seul caractère changé.


mercredi 17 août 2016

Création d'un disque USB bootable à partir d'un .iso sur OSX

De nombreux sites expliquent le processus mais beaucoup oublient l'étape de convertion ou font une erreur de syntax sur la commande dd. Donc voici un exemple testé avec GParted sur El Capitan
hdiutil convert -format UDRW -o gparted-live-0.26.1-5-i686.img gparted-live-0.26.1-5-i686.iso
diskutil list
diskutil partitionDisk /dev/disk3 1 "Free Space" "unused" "100%"
sudo dd if=~/gparted-live-0.26.1-5-i686.img.dmg of=/dev/rdisk3 bs=1m

Notez la différence entre le "/dev/disk3" et le "/dev/rdisk3" pour les deux dernières commandes.

Après l'éxécution de la dernière commande vous aurez un "the disk you inserted was not readable by this computer" ou l'équivalent en français mais ça n'empêche pas OSX de booter dessus suite à démarrage en appuyant sur ALT pour sélectionner le disque de montage.

Pour info si le disque bootable GParted n'est pas reconnu par OSX c'est qu'il est construit avec une partition EFI ( extention 0xEF ) lorsque l'on fait un "diskutil list". On peut quand même forcer son montage en faisant:
mkdir /Volumes/efi
sudo mount -t msdos /dev/disk3s2 /Volumes/efi/

jeudi 12 mai 2016

Automonter des partages Samba et NFS sous OSX (et le répertoire spécial /net)

Au lieu de manuellement rajouter des appels à mount_nfs dans son .bash_profile ou autres scripts lancés au démarrage on peut utiliser le système d'automounter autofs supporté par OSX.

Dans /etc/auto_master on va commencer par référencer deux nouveaux fichiers /etc/auto_nfs et /etc/auto_smb qui contiendront nos paramètres de connexion spécifiques au NFS et au Samba. #
# Automounter master map
#
+auto_master # Use directory service
/net -hosts -nobrowse,hidefromfinder,nosuid
/home auto_home -nobrowse,hidefromfinder
/Network/Servers -fstab
/- -static
/- auto_nfs -nosuid
/- auto_smb -nosuid
Ensuite on crée nous mêmes les fichiers /etc/auto_nfs et /etc/auto_smb ainsi que les répertoires de montage: mkdir /Users/myuser/nfs
mkdir /Users/myuser/smb

auto_nfs
/Users/myuser/nfs -fstype=nfs,noowners,nolockd,noresvport,hard,bg,intr,rw,tcp,nfc nfs://192.168.1.10/home/linuxuser/nfsshare

auto_smb
/Users/myuser/smb -fstype=smbfs,soft,noowners ://guest:@192.168.1.10/exchange
Au redémarrage on vérifie bien que les partages sont montés: mount

/dev/disk1 on / (hfs, NFS exported, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
map auto_nfs on /Users/myuser/nfs (autofs, nosuid, automounted, nobrowse)
192.168.1.10:/home/linuxuser/nfsshare on /Users/myuser/nfs (nfs, nodev, nosuid, automounted, noowners, nobrowse)
map auto_smb on /Users/myuser/smb (autofs, nosuid, automounted, nobrowse)
//guest:@192.168.1.10/exchange on /Users/myuser/smb (smbfs, nodev, nosuid, automounted, noowners, nobrowse)
Autre solution. Utiliser le répertoire spécial /net/

Si l'on a un serveur nfs sur 192.168.1.10 on peut automatiquement naviguer dedans par /net. ls /net renvoie vide mais si l'on fait /net/192.168.1.10/ on a accès aux répertoires partagés via NFS.

mardi 3 mai 2016

Partage NFS de Linux vers OSX

Avec la configuration présentée dans mon billet précédent si l'on essaie de monter le répertoire NFS Linux sous OSX on pourra lire son contenu mais on aura un "Permission denied" lors de la tentative d'écriture dans le répertoire. Ceci est du à la difference de UID/GID entre l'utilisateur Linux (typiquement 1000/1000) et l'utilisateur OSX (typiquement 501/20)

Pour rendre l'export Linux compatible avec un client OSX il faut utiliser les paramètres suivants dans /etc/exports
/home/linuxuser/nfsshare *(rw,sync,insecure,no_subtree_check,all_squash,anongid=65534,anonuid=65534)
Une fois exports modifié relancer avec:
sudo exportfs -ra L'option all_squash indique au serveur NFS d'exécuter toutes les requêtes distantes en tant qu'utilisateur anonyme. Les options anongid et anonuid spécifient l'identité de l'utilisateur anonyme (nobody,nogroup)

A noter que dans cet exemple j'ai utilisé l'utilisateur anonyme nobody mais on peut très bien "squasher" les connexions vers un autre utilisateur que nobody ( typiquement 1000/1000 ).