The boot loader can never be changed safely, it should be locked like phones
So, is SatoshiLabs signed firmware update capable of updating boot loader? No the boot loader doesn't need to be updated and shouldn't be Depends if it's ROM based, how many bootloader stages you have, it's definitely not that simple  |
|
|
|
nope, this is a "concern" for USB host devices (i.e devices in which you plug USB thingies). nothing really new here anyway, USB is complicated, news at 11 (for more impressive reports look up facedancer, psgroove, ...) |
|
|
|
|
Tout ce qui a besoin de sécurité et d'une preuve du consentement de l'utilisateur qu'on ne peut pas avoir sur un appareil que l'on ne controle pas :
- Remplacement du mot de passe par une signature (type BitID & friends)
- Signature de mail et autres documents
- Chiffrement de messages confidentiels pour usages divers (mail, SMS, messagerie instantanée ...)
- Paiements peer to peer
La plateforme prévoit depuis le départ la séparation de la sécurité (carte à puce) de la présentation / preuve du consentement (terminal), et le multi applicatif.
|
|
|
|
Concernant l'adhésion à Bitcoin France, c'est sur que ce n'est pas bon pour l'association d'avoir des scammers comme membres.
d'un autre coté, on peut avoir l'ambition de vouloir rivaliser avec la Bitcoin Foundation aussi  |
|
|
|
A priori les Français seront plus à l'aise avec une carte à puce et un terminal  Après le crowdfunding c'est un test aussi, c'est un truc qu'on a prévu de faire de toute façon depuis un moment, ça ira juste plus ou moins vite. |
|
|
|
Le projet est beau, sincèrement. Mais vraiment trop compliqué pour que ça puisse toucher le grand public.
ça tombe bien, l'idée c'est plus d'avoir un reference design pour quelque chose d'à la fois sécurisé (au sens de l'état de l'art) et open source après si des gens veulent le rendre plus simple à utiliser, c'est tout à leur honneur (et on le fera probablement aussi de notre coté) |
|
|
|
La rédaction de actubitcoin.fr
 |
|
|
|
got my two Trezor yesterday, quite impressive. I like the speed and the screen brightness, it's a cute portable lighthouse now time for some security tests |
|
|
|
|
et la qualité de l'aléa aussi
|
|
|
|
cool merci |
|
|
|
oui, à l'origine je voulais faire du P2SH, et puis là on s'est rendu compte que ça ne marchait ni sur Armory ni sur Kryptokit, donc on fait ça à l'ancienne, dommage. Mais merci les gens |
|
|
|
nice, c'est bien ma doc est lisible |
|
|
|
|
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
|
|
|
|
tu le pré-prépares pas bien pour la key recovery là non ? 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) - 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.
- Un petit lien ? pour moi ils font une boucle (4.1.6 / 1.6) 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." 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  - 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)
- 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) 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). 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  ) 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. 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. 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.
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.) 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. |
|
|
|
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/K0Rc9WFQUSER-DIR> testsig.py
-----BEGIN BITCOIN SIGNED MESSAGE-----
Campagne de Sarkozy : une double comptabilite chez Bygmalion
-----BEGIN SIGNATURE-----
17JusYNVXLPm3hBPzzRQkARYDMUBgRUMVc
H5oNKDkcBTWuwQd7u4ZhTI88OEo+mqGhJL+5zpZJGWt+Dvoa3AEKe93keE7phEHkAvk7PFCidgywndoHUB4CyB8=
-----END BITCOIN SIGNED MESSAGE-----
mais tu le pré-prépares pas bien pour la key recovery là non ? - 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.
un petit lien ? pour moi ils font une boucle (4.1.6 / 1.6) - 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)
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 ) - 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")
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. - 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)?
ç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. 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. oui, plaisir d'offrir (en attendant la clé de Mycelium ...) PS: Dans le prochain test vector, tu pourras mettre:
"Faouzi Lamdaoui, conseiller de Hollande, soupconne de fraude fiscale" (ici) pas de bol, le sample a été écrit au mauvais moment meme si statistiquement parlant j'avais plus de chances de tomber sur eux |
|
|
|
|
Show Posts
