Vélo Chain

Système de marquage crypté pour chaque vélo détectable par phone

💼 porté par

Discuter sur le chat

Système de marquage crypté pour chaque vélo détectable par phone. Il peut être généré unitairement par une app en ligne sécurisée. Le double cryptage qui contient des informations :

• la couleur du vélo
• le département et la ville
• le code du propriétaire
• le numéro du vélo

La Forme du cryptage : "4tG_b03v" ou "BçK55lZn"... inspiré d'une techno de cryptage-image créée par la NSA à laquelle s’ajoute une key supplémentaire pour aléatoiriser l'ordre des valeurs à décrypter. Ça devrait en toute sécurité (sans risque de doublons) couvrir 10 milliards de vélos à travers le monde. Ce marquage crypto est à fabriquer et fixer sur cadenas à code ... Le code graphique crypté (carrés noirs sur fond clair)

Organisations utilisatrices ou intéressées pour utiliser la ressource :

Contributeur(s) :

Tags : Cryptographie, cadenas

Catégories : Logiciel, Matériel

Thème : Blockchain, Vélo et Mobilités Actives, Logiciel Libre, Collectivité

Référent :

Défi auquel répond la ressource : Améliorer les solutions et développer de nouvelles solutions de mobilités pour tous

Personnes clés à solliciter :

Autre commun proche : Solutions de vélos partagés et recyclés, Partageons plus de vélo

Richesse recherchée :

Compétences recherchées :

Communauté d'intérêt : Communauté Vélo et Mobilités Actives

Type de licence :

Conditions Générales d’Utilisation (CGU) :

Niveau de développement : Idée

Lien vers l’outil de gestion des actions :

Lien vers l’outil de partage de fichiers :

Besoins :

Prochaines étapes :

Documentation des expérimentations :

Autres informations

Liste des acteurs qui utilisent ou souhaitent utiliser ce commun : aucun pour le moment

Liste des CR d’atelier en lien avec ce commun :

Acteurs identifiés :

• PROJET (le projet global),
• USER (utlisateur),
• ASSOC (propriétaire du vélo : assoc ou perso)
• VILLE (commune partenaire)

Avantages :

• social (création de structures associatives recyclage)
• économique (vélos libre-service pas chers, financement des associations propriétaires des vélos, économie solidaire et circulaire)
• environnemental (moins de voitures en ville)
• santé publique (air meilleure qualité, exercice physique)

Cas d’usage :

1. un utilisateur qui a besoin d'un vélo trouve le plus proche géolocalisé sur une map (là où le dernier utilisateur l'a laissé)
2. il flashe le code avec son phone
3. le vélo est libéré (cadenas ouvert)
4. un protocole blockchain IoT initie la transaction
5. l'utilisateur va où il veut. Quand il s'arrête il referme le cadenas et signale sa position via son phone
6. le protocole valide la transaction, actualise la map et verse un certain montant en cryptomonnaie (token) du wallet utilisateur vers wallet propriétaire du vélo et vers l'utilisateur pour le "remercier" d'avoir géolocalisé et fermé le cadenas (on lui rend une consigne)

Problèmes à résoudre :

• fabriquer des marquages cryptés solides, insensibles aux UV, à la pluie, non-modifiables, faciles à fixer et peu chers à produire : par ex (voir avec fablabs) une 1ere couche de plastique blanc de 4cm sur 3 puis 2e couche de carrés noirs : une petite imprimante 3D premier prix devrait être capable de faire ça. Chaque marquage étant individualisé, je peux créer une interface d'inscription du vélo par son propriétaire qui produise le fichier STL pour piloter l'imprimante.
• mettre en place un process contraignant l'utilisateur à passer par son phone pour libérer et refermer le vélo. Un cadenas connecté coûte trop cher. Tant qu'on est dans du militantisme l'utilisateur joue le jeu (conscience de l'enjeu social, environnemental, etc) mais sitôt qu'on touche un public plus large il y a risque de fraude, vol, refus de perdre du temps à geolocaliser en fin de course et donc de payer l'usage, etc.

• USER s'inscrit il paye en gros le prix d'un vélo recyclé (sans jeu de mot :-) ) à PROJET, mettons 50 euros. Il accède donc à tous les vélos dans toutes les villes partenaires, son compte est créé et son wallet (porte-monnaie virtuel) crédité de 500 tokens (1 token = 0.10 euros)
• USER prend un vélo, il flashe le code sur son phone et reçoit en retour le numéro du cadenas : son wallet est débité de 500 tokens (vidé complètement : séquestre de précaution/garantie) au profit du wallet PROJET
  • si il ne "rend" pas le vélo alors on considère qu'il l'a acheté... le lendemain, PROJET reverse ces 500 tokens de USER à ASSOC qui du coup est payée pour son travail
  • si il le rend (flashe à la dépose) PROJET lui rend 500 tokens moins sa course : pour une valeur par ex de 0.20 cents/heure (2 tokens) on lui reverse 498 tokens sur son wallet.

problème n°1

Le USER connaît le code cadenas et peut donc réutiliser le vélo aussi souvent qu'il veut : il fait une première course pour 10 cents, géoloc/referme le vélo, puis réouvre le cadenas et roule désormais gratuitement.

solution prob 1

• avec un nombre suffisant de vélos et de demandes, un autre utilisateur ayant besoin du vélo précédemment refermé et géolocalisé à un certain endroit ne le trouvera pas. Le compte wallet de USER-tricheur est vidé au profit de ASSOC. Si un autre utilisateur retrouve le vélo en ville, l'ouvre et l'utilise, le vélo est instantanément réintroduit dans le système (à condition que USER-tricheur n'ait pas pu changer le code du cadenas)
• si USER-tricheur avait bcp de tokens et c'est bénéf pour ASSOC qui touche ses tokens alors que le vélo existe toujours et peut encore rapporter des tokens par d'autres USERs ultérieurs.

problème n° 2

Au bout d'un certain nombre de courses son wallet sera vide... un jour il ne pourra plus prendre de vélo puisqu'on ne pourra plus rien prélever.

Solution prob 2 :

• USER doit pouvoir récupérer de nouveaux tokens pour pouvoir continuer à utiliser le système. Soit il rachète pour 50 euros de tokens à PROJET (option 1), soit on procède autrement :
• VILLE a intérêt à ce que le système fonctionne (moins de voitures, de prob de santé, création emplois recycleur de vélos, etc), donc :
• VILLE crée un compte en euros dans le PROJET (équivalent subvention) de disons 20 000 euros/an... donc 200 000 tokens
• quand USER rend le vélo (flash+géoloc) il est ***payé*** pour le faire (ou on peut débiter beaucoup lors de l'ouverture du cadenas et rendre quasiment la totalité à la fermeture, une sorte de consigne c'est ça la séquestre évoquée + haut) : quand son wallet atteint par ex 300 tokens, PROJET lui en verse 200 pour recompléter. PROJET peut ainsi refinancer les USERs les plus actifs avec une réserve potentielle de 1000 recharges/an.
• soit un mix des deux : USER rachète 100 tokens (10 euros) et PROJET en prélève 100 dans le wallet de VILLE et les reverse à USER. Le refinancement de PROJET passe à 2000 recharges/an pour une subvention VILLE de 20 000 euros/an. Si la subv est de 50 000 on a 5000 recharges/an/commune. Avec 10 communes on a 50 000 recharges/an globales.

Compléments :

• En cas de panne/crevaison, le vélo est localisé et une alerte via phone envoyée à ASSOC pour aller le réparer (descriptif rapide par USER par cases à cocher sur interface phone)
• Tous les xx temps ASSOC récupère/change en euros ses tokens auprès de PROJET
• ASSOC peut aussi être une entreprise qui loue des vélos, un particulier qui met son ou ses vélos en location (protocole pour qu'il puisse les réutiliser à titre privé : retrait momentané du système, dégéolocalisation, etc)
• quel contrôle de l'état général des vélos ?
• prévoir partenariat avec un organisme bancaire ? ou alors PROJET joue ce rôle via son compte bancaire ?
• positionner le code marquage sur le vélo et non sur le cadenas (mettre le cadenas encodé sur un vélo délabré est trop évident)
• paiement en token à la durée ? au kilométrage ? un mix des deux ?
• dispositif de fixation du code sur le cadre du vélo permettant de détecter si ça a été arraché (vélo volé au dispositif) ... veiller à ce que le code soit simple à flasher par un phone sans complication ni contorsion.
• photo du vélo affichée sur le phone USER sur la map (le trouver facilement) et en même temps que réception du code cadenas (vérification visuelle que c'est bien le même)
• éviter d'associer le code cadenas au code crypté du vélo : changement de cadenas possible... En revanche possibilité d'intégrer dans les datas stockées dans un block décrivant le vélo son n°de cadenas (à réactualiser par ASSOC pour éviter probs ultérieurs)

Technos :

blockchain privée orientée IoT à transaction rapide et cryptomonnaie interne type beAchain inscriptions de USER, ASSOC préalables sur interfaces dédiées analyse des codes-vélos par clé privée-publique transactions/sequestre de wallet à wallet cryptées de bout en bout interfaces dédiées selon usages : inscrire un nouveau vélo, ouvrir/refermer un vélo, signaler un prob sur le vélo, sa disparition, code arraché, code incompatible avec photo, etc)

Crypto :

ID vélo sur 16 chiffres : 5 (clé indicielle publique de sécurité) 12 (département) 03 (ville) 00348 (propriétaire) 1812 (n°du vélo) 3 (couleur) : "512030034818123" = exemple cryptage (selon clé indicielle) : "ëB4_uCn2" ID user sur 16 chiffres : 85 (clé privée) 1485806500 (date inscription) 3285 (N° inscription : aléatoire) : "8514858065003285" = exemple cryptage (selon clé privée) : "Un8k)BeV" block vélo dans la chain sur 30 chiffres en clé publique : 38.457812 + 07.325498 (géoloc actuelle) 1478912458 (date de dépôt à cet endroit) 3254 (cheksum ISO 39616 (protocole sécurité bancaire IBAN) du dernier USER/ID) : cryptage public (sur la map tout le monde peut savoir où et quand mais pas qui...) : "F[n09vZaj55ué-N" Transaction type : "Un8k)BeVëB4_uCn2F[n09vZaj55ué-N" == USER 8514858065003285 demande à utiliser le vélo 512030034818123 dont les datas de localisation/date/dernier USER sont 384578120732549814789124583254. On vérifie que USER ID et checksum donnent bien 1. Si oui on explore le wallet/block USER pour séquestrer son contenu et enclencher le cycle (dans tous les sens du terme !)

Avancement POC outil numérique :

Les codes cryptés (pour le moment générés manuellement en images) sont reconnus et décryptés. Ils sont contrastés (photo USER initiale ne le sera probablement pas assez), redressés (USER ne photographiera pas forcément droit) et inversés si besoin (USER peut tenir son tél horizontalement dans les 2 sens) avant analyse/décryptage. Restera à gérer la question de la courbure du cadre si marquage gravé sur un tube du cadre + perspective possible. Le process actuel de reconnaissance de codes non-optimisé (des tas de calculs et d'informations de contrôle inutiles) prend environ 0.6 à 0.7 seconde. Je voudrais tomber à 0.3-0.4 sec.

Expérimentations

• Identifier quelques villes / lancer un appel à candidature auprès des associations type Choisir et villes comme Strasbourg
• Financement / Développement : coût développement entre 3 et 10 000 grand maximum, plus probablement autour de 4 ou 5... à préciser selon nature exacte du projet finalisé.
• système technique de gravage ?