Suivant l’idée de @stephane d’avoir la mémoire uniquement sur la carte, j’ai trouvé une carte avec une mémoire sécurisé, configurable lorsqu’on flash l’EPROM, spécialement faite pour les fonction crypto.
Access to the user zones occurs only through the control logic built into the device. This logic is configurable through access
registers, key registers and keys programmed into the configuration memory during device personalization. Also implemented
in the control logic is a cryptographic engine for performing the various higher
-level security functions of the device.
oui mais non c’est une idée a oubliée, mémoire uniquement ça veut dire que ce n’est pas la carte qui génère la signature, hors la signature doit nécessairement être générée par la carte client !
EDIT : sauf dans le cas d’un tier de confiance centralisé bien sûr
le mifare_desfire est une carte déjà pas mal seule (et moins chère) : elle intègre des fonctions de crypto pas aussi évoluées que NaCL mais cela devrait suffire pour s’authentifier auprès d’un tiers (qui fait le paiement et renvoi la TX au terminal).
Voila qui devrait plaire à @elois
Par ailleurs, je pensais que la demande envoyée au tiers pourrait aussi etre signée par le terminal. Ainsi, celui-ci est identifiable par la suite.
Pour diminuer encore les risques de piratage (par un terminal bidouillé) l’utilisateur pourrait définir un montant max de transaction, pour un meme terminal. Ou encore avoir accès à son historique des paiements (et identification du terminal) afin de faciliter la détection des paiements frauduleux.
Tout cela me semble suffisant pour des paiements du quotidien (courses, etc.)
Oui, d’ailleurs avec @stephane on se voit ce we !
Après, moi j’ai pas pris le temps d’avancer sur ce sujet. On verra avec @stephane et on vous tiendras au courant.
(surtout que @PiNguyen a bien délirer sur des design de cartes. ca donne envie de bosser la dessus ! …désolé, je suis un “visuel”, pour qui le beau est une motivation. cf les petites animations/transitions dans Cesium )
Je suis désolé de faire mon rabat-joie, mais je me souviens avoir discuté sur un autre post que, vu les délais de la blocchain Duniter pour éviter les doubles transactions, il était peu envisageable d’attendre même 10 minutes à la boulangerie que la transaction soit validée (en encore, pour être sûr du coup 10 minutes c’est trop peu).
Surtout que le système n’impliquant pas de tiers, il n’y a pas d’assurance.
Il me semble bien plus réaliste de voir un système tiers être proposé, qui aura accès à un compte porte-feuille du payeur et qui gèrera les écritures en désynchronisé.
Les banques font ça aujourd’hui, mais comme elles l’intègrent à un pack “tenue de compte, création monétaire, gestion des crédits” c’est flou. Une structure tierce qui ne ferait que ça pourrait contribuer à un écosystème sain, en annonçant clairement ses tarifs.
Le coup des 10 minutes (ou des 1h pour de très grosses transactions) me paraît insurmontable, c’est pourquoi je préfère le rappeler avant que vous n’y passiez plus de temps. Dites-moi si je me trompe. Peut-être est-ce intégré à la V11 ?
Personnellement je suis pour un bloc par minute, mais c’est à discuter avec le reste de l’équipe. Les blocs quand à eux pourront contenir bien plus de transactions.
Même 1 minute (et il faut plusieurs blocks pour être sûr qu’on n’a pas lancé une double transaction et poussé un fork). Je ne suis pas sûr qu’on puisse travailler sur la même infra, si les 2 fonctions sont compatibles (sécurité/pérennité des transaction VS vitesse d’exécution).
1 minutes et 3 blocs de confirmation sont largements sûrs. Pour des paiements plus rapides, on pourra utiliser un Lightning Network : si l’ouverture du canal de paiement est en bloc et a plusieurs confirmations, les paiements sont instantanés et irréversibles même en cas de forks. Ca viendra surement un jour, mais ce n’est pas la priorité à l’heure actuelle.
J’ai mesuré à la boulangerie, le paiement se fait en 14 secondes. Si la transaction est prise immédiatement, 3 blocs représentent 12 fois plus (surtout qu’on a inventé le sans contact, peu sécurisé, pour gagner encore du temps).
Je ne connais pas les lightning Networks, mais ça semblerait effectivement beaucoup plus adapté.
