@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
ca c’est ma capacité a partir en sucette quand j’envisage trop de possibilité
sinon je viens de tomber la dessus:
http://www.scopus.fr/pages/les_badges_a_contact.html
ok, on se fixe le samedi, 14h ? Soit en conf, soit de visu (chez moi en Mayenne ?)
OK pour 14h.
En cherchant un peu je suis tombé sur cette carte : https://vimeo.com/145770131
Le site officiel est ici : https://card.mycelium.com/
@nay4 la vidéo va te plaire ^^
En fait je me dit qu’un cryptage meme plus faible que celui de Dunitrer pourrait faire l’affaire, en passant par un tiers qui réalise ensuite la transaction.
@stephane je suis tombé aussi sur ca : https://cryptojedi.org/papers/avrnacl-20130220.pdf
@kimamila
le voila le MCU a integrer a la carte 
oui ici : https://cryptojedi.org/crypto/#avrnacl
mais les micro-controlleurs associés (ATmega2560) ont l’air couteux à mettre en oeuvre sur une carte… (@stephane tu confirmes ?) …les cours d’électronique me paraissent très très loin !
il faut acheter massivement ou etre pret a faire le voyage en chine =)
non, je veux dire qu’il faut tout une carte autour (alim, etc.). Donc on oublie ;(
alors la question a te poser , t’es prêt a mettre combien pour 1 carte ?
Pourquoi ne pas se baser sur un Raspberry Pi pour faire le lecteur et une carte avec mémoire pour “sauvegarder” les données cryptées du wallet ou autre? Cela permettrai aussi de se servir du Raspberry pi comme nœud si le possédant est membre. Ce n’est qu’une idée.
tu veux dire une carte qui embarque le micro-controlleur ? ou juste une mémoire ?
juste une mémoire, moins cher.
Une carte à puce avec mémoire connecté à un Raspberry Pi. Le contenu de la mémoire étant chiffré.
Voir si cela est possible mais c’est un système qui ne serait pas trop cher pour le commerçant.
dixit les avertissements soulignés que l’on entrevois avec elois,
les petits malins qui vont modifié leur “lecteur” peuvent :
- sniffer la ligne
- integrer des composants logiciels pour recup les données
EDIT: et pour le commercant une solution peut etre encore moins cher, onion omega plutot que rpi
https://onion.io/
RE: voir encore moins cher:
.https://getchip.com/
RE-RE: et la je suis au bout du bout:
.ESP8266 Wi-Fi SoC | Espressif Systems
a 2e le compo - 4e la board… je crois pas que l’on puisse faire moins…apres c’est cadeaux
si l’ESP8266 est capable de faire tourner NACL
je penche sur cette solution pour le coté carte de crédit.
et un chip ou onion pour le coté TPE.
ESP8266EX integrates Tensilica L106 32-bit micro controller (MCU) which features extra low power consumption and 16-bit RSIC, reaching a maximum clock speed of 160 MHz. With the Real Time Operation System (RTOS) enabled and Wi-Fi stack