Je parlais d’une carte intégrant une EEPROM I²C (en photo). Elle n’est pas conçue pour mettre une signature avec une lib de crypto car sa capacité est limité.
1 Like
Concernant cette histoire de carte de paiement, @max, as-tu chercher sur le forum. Je crois qu’on en a déjà parlé.
Je ne vois pas d’autres options que :
- avoir une carte gérée par un tiers : ce tiers délivre la carte, recoit les fonds, et effectue le paiement si les fond sont dispo. Sans doute la I2C conviendrait bien (de ce que j’en comprend).
- avoir une carte capable de faire la signature de la transaction (préparée par le terminal de paiement, qui lui à accès aux “sources” du portefeuille), sans communiquer la clé secrete à terminal de paiement. Je sais que cela existe, pour la crypto du BitCoin (moins évoluée que celle de Duniter). mais c’est vraiment les débuts… Par ailleurs, cette carte doit valoir très chère.
Bref, dans la 1ere solution, on fait comme avec les banques actuelles, la création monétaire en moins. Mais c’ets de loin la solution la plus simple à mon gout. Par ailleurs cela n’emp^eche pas d’avancer en parrallèle (dans les 10 prochaines années) sur la 2ème option.
1 Like
C’est vrai que c’est attirant d’utiliser un Raspberry Pi qui a un bus I²C natif et l’utilisation d’une carte avec EEPROM I²C pour s’en servir pour les transactions mais j’ai peur que la capacité de ce type de carte ne soit pas suffisante à moins de mettre une “signature” numérique couplée à un programme sur le Raspberry pi.
Si la carte est perdue, le propriétaire de celle-ci devra rapidement transférer tout ce qu’il a sur son compte sur un autre compte.
J’ai une clef et un programme qui me viennent à l’esprit:
-https://www.yubico.com/why-yubico/: une clef que j’utilise pour accéder à certains sites et avec un password que l’on doit mémoriser (je l’utilise sur cette page la: http://phpdomotics.net/)
-un programme sous android: OpenKeyChain
le site renvoit une erreur “Page not found”
De quoi parles tu ?
je comprends pas. Sous Android on sait déjà signer des trucs pour Duniter, non ?
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