Topic: [C'EST SORTI] - Support BTChip francophone - page 2. (Read 11078 times)

sur tout Android, oui

nice, c'est bien ma doc est lisible 

Voici le 1er soft tiers à intégrer BTChip!

Fast Sign Verify 0.30 BTChip Edition 

Bon en fait, c'est une version très spéciale :

• Ce n'est pas une version officielle (pas de commit pour l'instant)
• C'est une version "alpha", pleins de messages d'erreurs et manque de "friendly", choix de code peu optimaux, freeze, ...
• Ne demande pas le rang d'adresse et utilise la 1ere (ne gère probablement que le mode HDW)
• Manque peut être des dépendances (usblib, pyUSB, ...), install complexe, pas de mode HID,...

Version Linux
untar et launch main.py
Nécessite Python 2.7, wxPython, libusb
Pour des informations plus détaillées pour installer FSV dans Linux, reportez vous à la page officielle.

Version Windows
Unzip et launch FSV.exe
Nécessite au pire libusb et éventuellement Zadig
En cas de problème, lire ici

Si un BTChip est connecté lorsque l'on clique sur SIGN, ca signe automatiquement le message dans le BTChip! Il suffit donc de connecter un BTChip, d'écrire un message et de cliquer sur "SIGN" ! (Un message de demande de PIN apparait, si le BTChip est bien reconnu)
Ca utilise la première adresse (0,0), ca ne demande pas encore laquelle prendre, ni ne gére un wallet standard.

A la fin, l'adresse publique est affichée. On peut faire "COPY ALL".   

La signature est conforme à BIP62 "Lower S".

Ce travail est surtout une étape pour intégrer dans Electrum, et fournir une bonne base en Python.

Merci du conseil.
J'incluais pyUSB et libusb dans les choses à gérer. Normalement en mettant les dll au bon endroit ca devrait le faire.

cool ! pour les drivers dans un futur assez proche, je basculerais par défaut en HID, ça devrait simplifier sous Windows (genre rien à faire) - et tu peux déjà tester dans ce mode avec un SET COMMUNICATION PROTOCOL

J'ai bien avancé pour intégrer BTChip dans FSV:
Je génére une signature complète (et valide) à partir de la clé.

Ce que je fais pour le bit de parité c'est vérifier la signature et si c'est pas bon c'est l'autre parité (et je revérifie pour etre sur.)
J'ai plus qu'à créer les boites de dialogues AdHoc (type "Enter PIN). Et à régler ce pb de "lower S" (le "plus dur" c’est de réencoder S en DER). Il y aura aussi peut être une partie de "user friendly install BTchip drivers" qui pourra te servir aussi.

ok, vu, malin pour accélérer, avec un peu de chance peut etre meme que ça pourra tenir, je savais que j'avais bien fait de ne pas valider la 1.4.6 



voilà, vais relire pour voir le niveau de nécessité. Sur le fond je suis d'accord, là le pauvre chip est juste ras la gueule (jusqu'à notre prochaine optimisation magique, en général on est assez doués pour déclencher un nouveau cycle quand la situation devient vraiment trop désespérée  )



en mode compressé (par défaut donc), GET WALLET PUBLIC KEY doit renvoyer le hash160 de la clé compressée (idem keyboard), et la clé publique non compressée. Sinon c'est qu'il y a un soucis.

Non, j'attendais tes réponses avant de continuer. Parceque justement la key recovery c'est plus compliqué qu'une lecture de bit ;P (pas de key recovery dans FSV à la signature). Faire une key recovery alors qu'à un moment on a la clé, c'est un peu bete, il suffit juste d'extraire un bit de yR à la signature (cf point suivant et pull-req Electrum)


SEC1-v2 §4.1.3 Signing Operations p45:
Optionally, output additional information needed to recover R efficiently from r.
The additional information needed to compute R can consist of the point R itself, in either compressed
or uncompressed form. However, since r provides considerable information about xR, it
is often sufficient to provide no extra information to determine xR. At worst, log2(h + 1) bits are
needed to find xR from r. In any case, information needed to recover yR can take the form of single
bit, or the full value of yR depending on whether compactness or speed is preferred.

C'est d'ailleurs ce qui est fait dans la signature de message Bitcoin, le header contient un flag de parité de yR (LSB du premier char, 27 ou 28 en std).
Ca permet de rendre déterministe (sans boucle) le recovery de yR et ensuite de Q (=s.R-e.G /r ). Sans cette information, il y a 2 yR possibles, il faudrait les tester jusqu'à matcher Q.
Dans une transaction Bitcoin, on a la clé publique entière, on vérifie autrement. Mais là on vérifie une self-signature, et le document SEC indique que dans ce cas (§4.1.6) : "Several candidate public keys can be recovered from a signature. At a small cost, the signer can generate the ECDSA signature in such a way that only one of the candidate public keys is viable, and such that the verifier has a very small additional cost of determining which is the correct public key."


Ce sont les utilisateurs qui votent, pas toi  . Par contre, au niveau de la vérification je ne sais pas. C'est vérifié pour les nouvelles transactions au moins? Je crois qu'effectivement ce n'est pas vérifié pour les messages (sinon risque de répudier les anciens). En tout cas dans FSV, j'essaye de coller au plus près du standard (reference client master). BIP62 NewRule #1 indique: "We require that the S value inside ECDSA signatures is at most the curve order divided by 2 (essentially restricting this value to its lower half range)."
Tu devrais faire pareil, ca évite certains problèmes. D'un autre coté si c'est jamais vérifié, je ne vois même pas à quoi sert cette modification à la génération. Provisoirement, le retour en lower peut peut être fait dans le PC (le code existe dans FSV).


Ah OK, je pensais le DER plus simple. Autant pour moi... C'est bon alors, je vais juste devoir compléter un peu l'extraction de r et s.

Je récapitule pour bien comprendre:

• GET WALLET PUBLIC KEY retourne toujours la clé non-compr (même en mode compr)
• GET FIRMWARE VERSION permet de connaitre le mode compr or not
• Lors de l'écriture du message de confirmation (keyboard), la clé fournie est la clé selon le mode

(je me disais aussi, mince la clé get_pub_key et la clé fournie dans le message "keyboard" est différente.)

mais tu le pré-prépares pas bien pour la key recovery là non ?


un petit lien ? pour moi ils font une boucle (4.1.6 / 1.6)


je vote que non (et que je n'ai pas forcément la place pour corriger, après si le client officiel le vérifie, faudra probablement que je trouve la place )


c'est codé comme spécifié dans la partie "DER encoding" de BIP 62

"R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required."

donc je ne vois pas le hic.


ça rejoint ta question d'après, si tu as fait un setup normal (sans mode 'uncompressed keys'), tous les calculs internes sont réalisés à partir de la version compressée de la clé. Quand on fait un GET WALLET PUBLIC KEY, le dongle renvoie toujours la version non compressée, par contre, histoire de pouvoir rejouer les calculs / vérifier plus rapidement la signature. Donc pour savoir si tu es dans ce mode là ou pas, GET FIRMWARE VERSION effectivement.


oui, plaisir d'offrir (en attendant la clé de Mycelium ...)


pas de bol, le sample a été écrit au mauvais moment  
meme si statistiquement parlant j'avais plus de chances de tomber sur eux

Pour les compressed addresses, c'est un flag dans get_version ? "Using compressed keys : Yes" ?

J'ai pas mal avancé depuis hier soir. Un grand merci pour avoir ajouté pas mal de choses dans l'API. J'ai essayé les signatures de messages, et fait mon propre squelette de signature. j'ai pas mals de petites questions (évidement  )  

Voici un de mes sample-dev-early-PoC qui permet de donner un message complet signé (PGP style)
http://pastebin.com/K0Rc9WFQ

- Le dongle pourra t-il fournir une information de parité de yR, comme expliqué dans SEC1-v2? Ca évite de refaire tout un tas de calculs try & guess pour trouver un simple bit.

- S est-il fourni dans le "lower part" du champ de Z(n), comme le spécifie la "norme Bitcoin" ? Cela réduit la malléabilité des signatures. Par exemple dans FSV c'est le cas à la génération, mais pas encore à la vérification (pour bien respecter RFC1958 §3.9 LOL)

- Dans ton exemple de test de signature, r (xR) est donné sur 33 bits avec le premier byte à x00. Est-ce là la parité de yR (x00 / x01) ?
Ca ne respecte pas la norme DER (ITU X690), on doit minimiser la longueur utilisée, dont pas de leading zero. Alors d'accord, tu n'évoques uniquement ASN-1 et pas DER dans ta doc, Mais ca me semble "suspect'" ou une "mauvaise pratique".
Et normalement dans SEC1 si un point est compressé, il commence par "02 ou "03" (OK, r = xR n'est pas un vecteur/point mais un scalaire, enfin la composante sur "x")

- Comment savoir si la pub key est compressée à partir de l’adresse bitcoin "hash160"? Le BTChip fonctionne t-il toujours avec des adresses compressé? (parceque bon, j'ai bien galéré en me demandant ou je m'étais planté avant de voir que c'est simplement l'adresse publique qui est donné 'compressée') Ca semble être un paramètre à l'init du dongle, mais peut on avoir cette info par la suite (~ get setup)?


En parcourant la datasheet du composant de la clé, j'ai vu qu'il y avait un TRNG, accessible via ton API. J'ai aussi créé un petit script python de création d'adresse dont la source est un dongle. C'est cool parceque je cherchait un dongle entropy key TRNG pour m'amuser et BTChip permet de le faire.  


PS: Dans le prochain test vector, tu pourras mettre:
"Faouzi Lamdaoui, conseiller de Hollande, soupconne de fraude fiscale" (ici)  

Plus d'APIs et de tests pour les fans du serpent : https://github.com/btchip/btchip-python

Oui, 4E et la key recovery devraient faire ton bonheur - par contre en 1.4.5, toutes les clés demandent une confirmation second facteur, mais bon je pense que tu vas t'en rendre compte assez vite 

J'ai bien regardé la doc des fonctions: pour l'instant, je pense rapidement implémenter la signature des messages dans FastSignVerify avec le BTChip (0x4E). Ca a l'air assez simple, et ca sera un bon début.

voilà, merci, j'aime bien les samples



ouais quelque part à partir de mi Juillet ça devrait etre jouable pour moi



mais ça va super bien marcher quand ça va sortir, et j'ai vachement moins de pre-order que BFL aussi 

Yep, sur teuteur, je t'avais juste envoyé un petit soft car il y avait un ficher vide et rien de fonctionnel. Alors j'ai fait un tout petit soft de demo pour afficher la version. Puis j'ai fait un truc un peux plus élaboré qui est devenu BTChip-Test. ca me permet surtout de "prendre en main le bignou". (et d'aider d'autres avec ton API)
J'ai fait une petit maj à l'instant, les data send à la clé n'étaient pas bien pris en charge.
Tu as du voir aussi que j'ai essayé de bien documenter comment tout faire fonctionner ton API python sur PC. ca peut servir... (bref, tu peux le recopier/modifier dans ta page de ton API)


Ca , j'avais bien compris que si ya pas 9000 ya un pb, et donc il faut tout faire pour avoir 9000. Je comprends bien que tu ne peux pas documenter tous les codes d'erreur. Je trouve que la doc est pas mal quand meme (comparé à d'autre soft ;P)

Ouais enfin je ne suis pas du tout à l'aise avec BIP32, HDW, les transactions , le protocole Bitcoin. Je maitrise bien mieux ECC, DSA, FIPS186-3 , SEC2, ... (et python  ).
Dans un premier temps, je vais juste remplacer les fonctions sign() dans Electrum (ou FSV) , pour faire un PoC. J'aurais peut être besoin d'aide. Je propose une session cet été à la Maison du Bitcoin pour finaliser tout cela (il parait que c'est gratuit pour toi ^^).


Depuis le temps que tu m'annonces quelque chose, ca devient un serpent de mer cette histoire...  Je crois que c'est juste pour faire le teaser quand tu distribues des clés gratuites (et nous faire regretter notre absence , le cas échéant) 

re-merci pour les tests j'avais vu ça sur twitter, je vais linker sur mes liens refaits de la page dèv ce week-end


oui, c'est bien ça, elle n'est pas initialisée, et les status sont documentés n'importe comment, il faut que je refasse une passe, pour l'instant partir du principe que tout ce qui n'est pas "9000" est foireux c'est une bonne base

tu auras un status "8x" uniquement si tu as fait un "forward setup"


great


je suis toujours en train de revoir ça, avec un bon espoir pour le week-end à nouveau. mais normalement ça marche (c)

Salut, merci pour l'API Python. J'ai bien bossé dessus.

Voici d'ailleurs un petit exemple:
https://github.com/antonio-fr/BTChip-Test



Avec ma clé 1.4.5, j'ai un problème. Je pense qu'elle ne doit pas être initialisée. mais quand je fais un GET_MODE (0x24) je recois le code erreur N°6985
Ce numéro n'est pas documenté. Et la doc indique que la clé devrait plutot fournir le "flag" 0x80 dans son mode (avec le status 9000).
La doc explique en détails que le "flag" 0x80 indique que le "mask added if forward setup mode was used and the seed has not been redeemed yet".
Est-ce que ca veut dire que c'est seulement le cas quand quand la clé n'est qu'à moitié initialisée?
C'est pas très clair, à la première lecture j'avais compris que 0x80 indiquait une clé non-initialisé.
Voilà c'est pas un gros problème, mais je pense que tu pourrais ajouter "6985" dans les status de GET_MODE en indiquant que ca veut dire "not initialized" (si c'est le cas).

J'ai plus qu'à ajouter la prise en charge de BTChip dans FSV (voir dans ma signature) et Electrum !


Un dernier mot sur la MAJ du firmware. On peut utiliser les fonctions dédiées (0x42) décris en §16.4 et §17.3 pour MAJ. Peut être as-tu déjà un soft tout fait pour MAJ. Peux-tu donner un peu plus de détails pour procéder, et également les liens vers les binaires?

Thanks 

Je vais ajouter quelques exemples de l'utilisation de l'API JS sur github, ça manque dans le léger bazar de KryptoKit, et mettre le sample de signature-au-bon-format aussi.

Aussi j'attends avec impatience la migration de HID dans la mainline de Chrome (à priori pour bientot), qui permettra de se débarasser du problème des drivers sous Windows

Bon je confirme que j'aime bien ce produit : j'ai eu l'occasion de jouer plus en profondeur ce WE au hackathon avec un projet à base de BTChip(s) :-)

Pour info à l'aide de la lib JS, on faisait plusieurs opérations sur la chip depuis une page web :
 - check présente carte
 - initialisation de la carte avec un pin
 - unlock de la carte
 - récupération des adresses publiques
 - signature de message
etc..

Et cerise sur le gateaux, j'avais Nicaolas en face (btchip) ce qui est plutot pratique pour certaines sessions debug !