Simulation :

La carte G1 pour l'acheteur ("BCG1" Buyer Card G1)et un module de réception pour le vendeur ("SMG1" Seller Module G1)

BCG1 est le pendant de la carte bleue utilisée aujourd'hui.SMG1 est le pendant du terminal pour le commerçant.

-Dans quel contexte ?-Pourquoi ?-Pourqui ?-Comment ?

De nos jours, il est possible d'effectuer des transactions avec des cartes bleues auprès des commerçants.Deux utilisations possibles:

1) Insertion physique de la carte dans le terminal, puis authentification avec un code à 4 chiffres.

2) Paiement sans contact en champ proche. Aucune action requise de la part de l'acheteur.La carte bleue utilise la technologie sans fil NFC pour le paiement sans contact.

BCG1SMG1

Un système monnetaire tel que G1 basé sur le numérique doit-il recourir à l'utilisation de papier ?

Quelle est l'utilité d'une telle mise en oeuvre ?

Peut-on voir + large que le cadre « client » / « commercant » ?

Quelles peuvent être les réticences relativent à celui qui utilise la carte bleue ?

Comment se présente en pratique BCG1 ? SMG1 ?

Quelles sont les contraintes techniques ?-Quelle liaison physique ?-Quel protocole de communication ?-Quelles sont les motivations du choix :

- des composants ?- du protocole ?- de la procédure ?

-Est-ce que c’est sécurisé ?

Quels sont les risques liés à cet usage ?

Quelles sont les coûts d’une telle infrastructure ?

Quelle est l'utilité d'une telle mise en oeuvre ?

Pour  l’utilisateur de BCG1 :-possède sa clé pour effectuer une transaction à tout moment

-pas d'usage de papier.pas d’impression de billet - d'usage de codebar / QR code etc ...

-pas d'usage de smartphone..Au regard de ceux qui n'ont pas :

-les moyens d'acheter un smartphone-l'envie d'utiliser un smartphone.-confiance dans l'OS - le logiciel / les équipes de dev.

 Pour le commerçant qui dispose de SMG1 :-transfert de monnaie sur un "portefeuille entreprise"

.evite le transfert sur un "portefeuille particulier" d’un salarié

Peut-on voir + large que le cadre « client » / « commerçant » ?

=> Penser client comme consommateur d’un bien ou d’un service rendu par le commerçant  /  prestataire .

=> Penser patient ayant besoin de soins. Carte vitale.

=> Penser transfert de la monnaie sur le compte de son fils / sa grand-mère / d’un ami.

Une configuration envisagée pour une preuve de concept :

Mise en œuvre pratique :

NB : je ne fais pas , par la suite, la distinction clé privé / clé publique.

A partir de maintenant, pour la suite des explications et justifier le choix d’implémentation, je vais considérer BCG1/SMG1 comme système :

Avec contact physique entre les deux modules-protocole  => I2C

Et la nécessité d’utiliser un code PIN-3 tentatives de validations-code à N chiffres :

-mini  = 4 ou plus ?-maxi = ?

Ceci en parallèle avec l’usage quotidien de la carte bleue décrit auparavant :

«  Insertion physique de la carte dans le terminal, puis authentification avec un code à 4 chiffres. »

Mise en œuvre pratique :

Bob achète des gâteaux dans le magasin de Maurice.

A) Bob initialise sa carte BCG1 au moyen d’un ordinateur, de chez lui ou une personne de confiance / un établissement de confiance.

.il utilise sa clé

.il utilise un code PIN, personnel, que lui seul connaît.

B) Maurice fait le paramétrage de SMG1.il utilise la clé de son portefeuille entreprise.

C) Bob se rend chez Maurice et souhaite effectuer une transaction.Maurice prend la carte BCG1 de BOB est la connecte a SMG1.Il saisit l’information concernant le montant de la transaction.Bob saisit son code PIN.La Transaction se termine. Elle échoue ou elle est validée.

Un processus courant pour les utilisateurs de carte bleue. 

Pourquoi utiliser le protocole I2C pour communiquer entre BCG1 et SMG1 ?

Considérations + techniques :

l’utilisation logiciel :.le Kernel et son implémentation :

https://www.kernel.org/doc/Documentation/i2c/i2c-protocolVoir les modules i2c-dev

.des fonctions présentes pour les dév C / C++https://www.kernel.org/doc/Documentation/i2c/dev-interface

.des modules pour utiliser avec Python / JS / etc...

l’utilisation physique :.les ports vidéo disposent de broches I2C 

VGA / DVI / HDMI

.les cartes « mini pc » de 1er prix disposent de connectivité I2CRaspberry PI / BeagleBlackBone / Onion Omega2 / Intel Edison…

.les micro-contrôleurs disposent de broches I2C

https://www.kernel.org/doc/Documentation/i2c/i2c-protocolhttps://www.kernel.org/doc/Documentation/i2c/dev-interface

Protocole envisagé : 

Le protocole I2C fonctionne sur 2 canaux :> le signal d’horloge SCL> le signal de donnée SDA

2 conducteurs électrique de la même manière que l’USB qui lui dispose de deux canaux d’informations :> D+> D-

Alors pourquoi utiliser le protocole

I2C plutôt que l’USB ?

L’implémentation physique.Le coût des composants.

Ainsi BCG1 peut se réduire à 

1 seul composant :

1 EEPROM* *https://fr.wikipedia.org/wiki/Electrically-erasable_programmable_read-only_memory

rien de neuf dans l’espace...X)

https://fr.wikipedia.org/wiki/Electrically-erasable_programmable_read-only_memory

Et comment je connecte BCG1 à un appareil hôte ?A la façon d’une clé USB, sauf que c’est sur des broches différentes, tant bien même que l’on peut réaliser ce schéma électrique avec une connectique usb. Pourquoi pas ? =) 

> 2 canaux d’informations (SCL / SDA)> 2 canaux d’alimentations électrique (+5V / GND)

-dont dispose l’appareil Hôte, ici un RPI (CPU ARM)La tension électrique ici est arbitraire, cela peut être 3.3V, 1.8V etc..Il sera nécessaire de vérifier cette compatibilité entre l’EEPROM et l’Hôte.

+5V

GND

SCL

SDA

Une différence notable usb / i2c :

La reconnaissance d’un device usb est effectué par l’OS (hôte)Le kernel détecte si un device vient de se connecter

Dev driver - kernel :https://www.kernel.org/doc/html/v4.12/driver-api/usb/writing_usb_driver.htmlDev - userspace :http://libusb.info/https://github.com/libusb/libusb

Problème de sécu lié à cette capacité, entre autres:https://hakshop.com/products/usb-rubber-ducky-deluxe

A contrarioLa communication via i2c est instanciée par l’hôte,L’hôte effectue un appel sur la ligne à l’adresse du composant

https://www.kernel.org/doc/Documentation/i2c/Module kernel i2c-dev$>modprobe i2c-dev

https://www.kernel.org/doc/html/v4.12/driver-api/usb/writing_usb_driver.htmlhttp://libusb.info/https://github.com/libusb/libusbhttps://hakshop.com/products/usb-rubber-ducky-deluxehttps://www.kernel.org/doc/Documentation/i2c/

Quelle est l’information enregistrée sur BCG1 ?C’est le résultat de la fonction de hash(clé , PIN).

Des amateurs pour définir une fonction au top !?

Ici un exemple très simpliste de sa définition pour les amateurs de code...

Fonction dont le résultat (storedkey) est transféré sur l’eeprom

Définie dans le programme d’initialisation de BCG1.

Fonction pour décoder la clé provenant de l’eeprom

 Définie dans le programme hôte 

de SMG1.

Dans le contexte du partage et de la transparence se pose le problème de la publication d’une telle fonction. 

Sachant que le code pin est d’une longueur indéterminé:-min  = 4 ?-max  = ?

Et qu’il n’y a pas de problème « technique » quant à ce que son détenteur utilise N chiffres (6, 8, 12, 42).  Si ce n’est sa propre capacité de mémorisation. 

Supposons un attaquant qui dispose de : 1) accès physique à l’eeprom et l’information hashé

.obtenus par Perte / Vol  / Commerçant mal intentionné 

2) accès physique au CPU/MCU et la fonction pour décrypter.dispositif qui peut etre verrouiller pour un « module / TPE » commerçant 

3) compétences techniques pour shunter le systeme.enregistrer les données / détourner la connexion, etc...

et fait une attaque « brute-force », soit :Tester TOUTES les combinaisons de chiffres.

Et ainsi effectuer autant de requêtespour espérer qu’il y est 1 solution qui valide une transaction.

Des mathématiciens pour décrire la difficulté à laquelle est confronté l’attaquant ?

A partir de la, qu’est ce que l’on peut mettre en œuvre pour contrer ce type d’attaque ?

Vérifier le checksum des binaires ?

Est-ce que il y a des moyens de contrôle décentralisable ?

Nouvelle blockchain ?

?...need help

Pour en revenir à Bob et Maurice [honnête et utilisateurs en toute confiance du systeme] :

Bob saisit son code pin, après N tentatives.

Que se passe-t-il si il échoue ?

A) détruire l’information sur l’eeprom-l’effacer / modifier-solution économique, évite d’acheter une nouvelle puce-Bob doit ré-initialiser sa puce

B) détruire le composant-une décharge électrique / surtension -solution non économique mais efficace =)

Quelles peuvent être les réticences relativent à celui qui possède et utilise la carte bleue ? Un chéquier ? Les billets ?Et le système lié à la carte vitale ?

Au détriment de la sécurité , est-ce un frein pour utiliser un tel système sachant que…

La carte bleue, si quelqu’un la possède, il peut faire des transactions par internet sans problème et débiter le compte. > Aucune compétences requises.

La carte bleue sans contact, un attaquant peut faire une transaction sans que l’on s’en rende compte. > Nécessite des compétences techniques.

...et dans ces cas, il faut se retourner auprès de sa banque…

Et le chéquier ? Et le billet papier ? … =)

C’est quoi le changement pour Bob et Maurice

● Bob doit se rendre auprès d’une personne / structure de confiance pour faire l’initialisation de BCG1 ou il a les compétences pour le faire lui même.

● Bob peut changer de code pin● Bob à une capacité + développée 

d’ intervenir en cas de perte ou de vol (sait accéder a son compte via internet)

● Maurice effectue des transactions comme à son habitude.

● Maurice peut contribuer à sécuriser la monnaie.

Les + pour l’utilisateur de BCG1:-1 seul composant-peut changer son code PIN :) -disponible sur soit a tout moment pour faire une transaction-pas d’alimentation électrique -pas d’usage d’autre appareils électronique-en cas de perte ou de vol , bloquer son compte lui même via internet

En terme de coût materiel pour l’utilisateur de BCG1 :-l’EEPROM-fabrication PCB-fabrication « boitier »

Les + pour le commerçant :-pas confronté aux faux billets / fausse monnaie-pas de transfert direct avec une autorité de contrôle si ce n’est blockchain Duniter-peut contribuer à sécuriser la monnaie G1, faire tourner un noeud

En terme de coût materiel pour un module SMG1 :-voir RPI, chip etc.(CPU -sys *nix / MCU -stack réseau) voir si il ne possède pas déjà d’ordinateur...-clavier / pavé numérique…-affichage écran, moniteur-ligne internet, prix de l’abonnement & box dont certains disposent déjà pour leur TPE 

Donc, j’en fais appel à ceux que cela intéresse de contribuer à cette mise en œuvre et d’établir une preuve de concept.

A ce titre, j’ai ma petite experience concernant le hardware, mettre en œuvre la communication i2c avec un CPU/MCU hôte, un clavier pour que les utilisateurs utilise le code PIN, proposer un écran d’affichage et la programmation qui va avec...

Les 2 points délicats pour moi en cet instant sont :-la requête pour effectuer une transaction dans le système Duniter

(je vais bien finir par y arriver…) (dev une nouvelle api ?)

-la sécurité

J’oubliais, pistes à étudier, le Protocole 1-wire,1 cable de donnée1 cable de masse1 cable d’alimentation ? Pour certains composant, pas nécessaire

https://www.kernel.org/doc/Documentation/w1/https://01.org/linuxgraphics/gfx-docs/drm/driver-api/w1.html________________________________________________

Et pour avoir une idée + PRECISE du coût – en tirant vers le bas –BCG1 :  -EEPROM : ~0,30€SMG1 : [ne diposant pas de nœud duniter, effectue une requete]

-MCU (stack wifi) : ~2€-Ecran oled : ~5€-Keypad : ~4€

Signé : Max

https://www.kernel.org/doc/Documentation/w1/https://01.org/linuxgraphics/gfx-docs/drm/driver-api/w1.html

Diapo 1Diapo 2Diapo 3Diapo 4Diapo 5Diapo 6Diapo 7Diapo 8Diapo 9Diapo 10Diapo 11Diapo 12Diapo 13Diapo 14Diapo 15Diapo 16Diapo 17Diapo 18Diapo 19Diapo 20Diapo 21Diapo 22Diapo 23Diapo 24