Effectivement https://www.yubico.com/why-yubico/ j’ai mis ‘:’ à la fin, ça ne pouvais pas marcher!
ah ok, c’est pour communiquer avec la clé de d’authentification dont tu parles ?
Cela éviterai de se rappeler de la phrase secrète et du password…(je sais ce n’est pas bien 
) Le programme sous Android peux être couplé avec la clef Yubikey qui, sur certaine version, intègre le NFC.
2 Likes
et pour rebondir a ta question ici :
.Dev / transaction process / usage - #7 by kimamila
oui, que j’ai juste a executer une requete :
sur l’url mabanque.com/sendTX/
avec comme parametre source = KA ; destinataire =KB ; amount=M
executé a partir du MCU(microcontroleur) (soit => TPE) commercant.
c’est une solution cool a mettre en oeuvre avec un MCU pas cher. (cool du point de vu dév sur le MCU )
Maintenant ca demande du boulot coté “server de la banque” et deployer les logiciels — A new blockchain ? 
pas tant que cela à mon avis… on y penses depuis un bon moment ici en Mayenne.
Si Stéphane connait bien les protocoles et matériels associés ca serait d’une très grande aide !
Quand est-ce qu’on se (re) voit pour en parler ?? Es tu dispo en septembre pour notre réunion mensuelle ? (8 sept. matin) - éventuellement par téléphone ou visio
EDIT: tu as déjà du matériel pour tester, peut-etre ?
si tu délègues ta confiance à un tiers, as tu besoin que celle-ci utilise ensuite une blockchain ?
C’est a moi qu’est adressée la question ? je vais te répondre tout de même:
pour ma par, je ne peux pas te répondre maintenant -
dans tout les cas, je vous tiens au courant de mes avancées sur le forum =)
Non je n’ai pas de EEPROM encore pour tester, je ferais surement l’acquisition bientôt.
Comme il y a plusieurs cas a tester.
pour le coté carte bleue
usb ? pas usb ? i2c ? pas i2c?
ca va changer la donne pour l’usb, + de composants
bonne question ! oui-non non-oui NON !?
ca revient a ce que proposer @regisg
ici
.Website G1 payment integration - #20 by regisg
Je demandais à @stephane (qui n’habites pas si loin de chez moi) s’il était dispo, pour qu’on avance la dessus
Je connais le protocole I²C mais moins la Crypto. Qu’as tu en tête @kimamila? Enregistrer une signature sur la carte I²C avec EEPROM?
J’ai au moins une carte I²C (celle que j’ai photographiée). J’ai un lecteur qui est soudé sur un circuit imprimé que j’ai conçu mais qui est facilement utilisable. Je dois avoir une deuxième carte et un deuxième lecteur car normalement je prend toujours tout en double.
J’ai un Raspberry pi d’avance ou nous pouvons faire des essais. J’ai aussi des Arduinos.
Le vendredi 8 je ne suis pas disponible, le samedi 9 oui.
PS: J’ai fais une recherche rapide sur Internet pour me procurer d’autre cartes cependant le produit à l’air d’être obsolète 
Sinon authentification biometrique pour paré le vol/perte
reconnaissance par empreinte digitale =)
voir analyse sanguine avec une petite piqure sur le bout du doigt 
ca fera réfléchir les plus dépensiés !
(voir décharge électrique)
(avec une config de limite des dépenses tiens ? ref : post sur -tutorat/curatelle- >>>> acte de naissance p2p)
dans tout les cas, le module TPE-commercant peut être hacked
Edit: dit autrement, le TPE commerçant , c’est ton ordinateur / smartphone, et la situation telle qu’elle est c’est:
tu as un ami qui utilise ton ordinateur pour effectuer une transaction
@elois pour résoudre le cas d’un individus malveillant et sa capacité à trafiqué SMG1,
je te propose le document suivant (j’espere qu’il sera lisible - j’ai glisser l’image dans le message pour composer ce post)
soit dit en passant quand je regarde ma carte bleue et que je vois ca :
je me dis que la différence est mince
1 Like
@Max oui c’est ce que j’ai pensé ce matin la seule protection qui me semble efficace c’est une fragilité physique du matériel afin qu’il se dégrade de lui-même a chaque essai. Ainsi en cas d’attaque bruteforce la puce sera trop usée avant que l’attaquant est pu trouver le bon code PIN.
De toute façon les CB actuelles expirent au bout de 2, 3 ans, est il envisageable physiquement parlant de fabriquer une puce BCG1 qui s’use physiquement a chaque utilisation, de sorte a devenir totalement foutu en moyenne au bout de 1000 ou 10000 usages ?
Si c’est possible alors il suffit ensuite d’un code pin a 5 caractères dans la gamme A-Z1-9 et ça fait déjà 52 millions de codes pin possibles, si l’attaquant ne peut espérer en tester que qq dizaines de milliers dans le meilleur des cas alors là c’est satisfaisant niveau sécurité
EDIT : par contre niveau protocole c’est au terminal SMG1 de construire le document transaction, comme ça il transmet juste à la puce le hash du document et le code pin saisi, et la puce se contente de signer le document c’est plus simple et plus robuste
CAS A ] Dans la proposition de base dans le PDF
BCG1 = puce EEPROM
CAS B ] Dans cette derniere proposition
BCG1 = puce EEPROM + unité de traitement + accès wifi
Que l’on s’entende bien:
un attaquant qui va disposer de l’accès physique a l’EEPROM, connaissant la documentation technique, va pouvoir récuperer l’information stockée sur celle-ci. Il va pouvoir souder des cables sur le composant.
Le brute-force se situe une fois avoir récuperé cette information sur son ordinateur,
ainsi il va généré avec cette information et toutes les combinaisons de PIN possibles => les résultats en sortie qu’il devra soumettre au réseau.
Je ne trouvais plus de fournisseur…Merci.
1 Like
Dsl je ne comprend pas. Sur le dernier PDF join tu parle bien d’un processus traité par la puce BCG1 donc c’est le même cas. J’ai l’impression qu’il y a quiproquo. C’est quoi le cas A ?
Il y a plus simple, l’attaquant à juste besoin d’un lecteur 
(j’en ai retrouvé 3):
Ensuite la lecture se fait selon le protocole I²C. Il faut donc que le contenu de l’EEPROM soit chiffré.
1 Like
@elois, dans le pdf , le premier document que je t’ai transféré,
cas A => BCG1 = puce eeprom, c’est tout rien d’autres, c’est juste le composant où est stocké la data
Oui dans les deux cas, il y a possibilité de recup la data…
la data qui ELLE doit est chiffré comme le souligne stephane,
et qui doit avoir un lien avec un code PIN
En fait dans ce cas je ne comprend pas comment le paiement est possible.
Pour que le paiement est lieu il faut nécessairement que le terminal SMG1 est a la fin un document transaction complet et signé. Qui fait la signature ?
Soit c’est le terminal SMG1, mais dans ce cas un commerçant peu scrupuleux peut voler tout ses clients, ca ne vas pas.
Soit c’est la puce BCG1, mais dans ce cas elle doit recevoir en entrée : hashDocTx+codePin et renvoyée en sortie une signature en base64 sur 88 bit. Ce cas la pour toi c’est ton cas A ou ton cas B ?
B jean-pierre, la réponse B
Mon cas B, comme je dois faire un calcul avec le code PIN j’ utilise un micro-controleur (unité de traitement)
On va devoir se soumettre a un tiers de confiance, (re-re-re edit: quoique on va peut etre pouvoir s’en passer)
une nouvelle BANQUEG1 qui elle fera le document de transaction aupres du systeme Duniter
Edit: je te ferai d’autre document pour que ce soit + clair =)
RE-Edit: oui ca va vite devenir compliqué, j’ai encore des cas d’usage a “penser” , y en a encore sous la semelle
@elois , oublie la derniere image et les explications qui en découlent, elles sont justes, valables mais n’ont pas pour autant d’interet, j’envisageais 2 composants bien distinct sur un circuit imprimé : l’EEPROM pour stocké independamment des données du MCU.
Alors qu’on peut stocker en dur dans la mémoire ROM du MCU - id+password 
Sur cette image - module BCG1 - tu remplace le terme EEPROM par (ROM/RAM/EEPROM etc…peu importe en faite) qui est interne au composant MCU et sa fabrication.
le tout revient a voir la capacité pour le MCU de pouvoir faire le document de transaction.
A)recuperer l’url d’un noeud
1)recuperer le dernier block
2)recuperer les sources
3)composer le document
4)l’envoyé
et ca me fais penser a une chose…
https://forum.duniter.org/t/dev-transaction-process-usage/3078?u=max
Pourquoi tien tu absolument a faire compliqué quand on peut faire simple ?
La génération du document de transaction n’est pas une étape sensible, et donc elle peut sans problème être entièrement traitée par le terminal SMG1 
C’est seulement et uniquement la signature du hash sha256 du document de transaction qui doit nécessairement être effectuée par un composant possédé uniquement par le client :ce que tu nomme BCG1.
Il faut donc que ce composant possédé uniquement par le client, qui constitue sa “carte” soit capable de calculer la signature d’un hash sha256, et bien sur pour que ce soit sécurisé il faut que la fonction de calcul de cette signature soit chiffrée par le fameux code pin