Systeme transaction / discussion

modules
application
electronique
device

#63

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.

D’après la doc page 8 :blush:

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.

Qu’en pensez-vous ?


#64

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 :slight_smile:


#65

euh, tu ne t’égars pas ? (peux tu venir sur le salon pour en discuter)


#66

j’ai trouvé une carte bien cool qui intègre du OpenPGP + mifare_desfire.

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 :wink:

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.)

EDIT: la vidéo sur la carte MIFARE DESfire v2 : https://www.youtube.com/watch?v=IflNvd3AWAs#action=share
Ca me semble tout bon


#67

Voici un fournisseur de la MIFARE DESfire : http://www.hitools-access.com/format-carte-57/desf_ev2_4k_ca-carte-mifare-desfire-123776.html : moins de 2€ l’unité
Site officiel ici : https://www.mifare.net/en/


#69

Je suis disponible (je t’ai laissé un MP)


#70

Bonjour,

J’aimerais contribuer sur ce service par carte à puce.
Vous avez poursuivi le travail ailleurs ?


#71

@kimamila @stephane j’espère que vous êtes toujours en vie ^^’


#72

Je crois que @Max aussi était sur le coup :slight_smile:


#73

Oui, d’ailleurs avec @stephane on se voit ce we ! :slight_smile:
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 :slight_smile: )


#74

@kimamila, @stephane we fructueux ? :wink:

Si vous avez du code ou de la doc à partager, je suis preneur :smiley:


#75

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 ?


#76

C’est de loin la solution la plus simple, je suis d’accord avec toi : créer un service économique tiers qui fait des paiements sur demande.

Historiquement, je crois qu’on appelle cela une banque. Ce n’est pas un gros mot, juste un métier.


#77

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.


#78

Bonjour,
Nous n’avons pas discuté de cela ce weekend.
De mon coté, je n’ai pas beaucoup avancé et @Max semble avoir bien avancé sur un système.


#79

@Max je peux voir où t’en es ?


#80

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).


#81

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.


#82

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é.


#83

En même temps à la boulangerie, ya un intermédiaire qui prend un % sur la transaction… :wink:

Et ça c’est réalisable dès maintenant, de lancer un service de paiement instantanné qui se rémunère à la transaction ! Pas besoin des LN :slight_smile: