Le protocole de base du PM

La spécification du protocole de base du Partage Marchand est volontairement minimale.

La version initiale du protocole comporte 6 types de requêtes.

Req-01:  Toutes les requêtes sont envoyées en HTTP de type «POST». Le premier caractère indique le type de requête et la suite est encodée en Base64_urlsafe (le caractère ‘+’ est remplacé par ‘-‘ et le caractère ‘/’ est remplacé par ‘_’). Le nom de la requête est suivi de son format avec chaque champ entre chevrons et la taille en octets entre crochets. La notation [a,b] indique que la longueur de la chaîne est de valeur entre a et b.

  1. Public-Key-Registration ‘@'<pub-key[132]> returns <status[1]>
  2. Intangible-Good-Registration &<hash-url[10]><src[9]><date[4]><f-value[7]><signature[132]> returns <status[1]>
  3. Local-Currency-Purchase ‘+'<currency[1]><date[4]><src[9]><dest[9]><price[3]><log[0,20]><signature[132]> returns <status[1]>
  4. Merchant-Sharing ‘*'<hash-url[10]><src[9]><date[4]><signature[132]> returns <enc-url[10]>|<error[1]>
  5. Get-Position ‘!'<hash-url[1,10]> returns <hash-url[10]>/<nb>
  6. Get-Ballance ‘?'<src[9]><options[1]> returns <balance>|<error>

Le nœud qui reçoit l’une des quatre premières requêtes doit mettre à jour son dictionnaire (base de donnée) local.

Req-02 La signature électronique est basée sur l’algorithme EC-DSA avec la courbe elliptique 521P. Chaque clé est générée localement en mode déconnecté de l’Internet. La sécurité de cette courbe est donc supérieure à celle utilisée par Bitcoin.

Req-03 Chaque signature porte sur le message (hashé), contenant la date et précédant la signature dans la chaîne de la requête (exclu le caractère de type de requête) et le signataire est celui d’identifiant <src>. Le nœud recevant une requête signée peut donc vérifier la signature. Deux requêtes avec la même date ne constituent pas deux achats différents.

Req-04 La clé privée n’est jamais transmise sur le réseau (même en SSL), elle doit être conservée chiffrée en AES 256 sur le téléphone portable de l’utilisateur, dans un fichier non accessible depuis le réseau et inaccessible depuis une autre application. Veiller en particulier au conditions des droits ‘root’ sur le système.

Req-05 L’identifiant <src> ou <dest> sont les 9 derniers octets de la clé publique. Si lors de la génération locale d’une clé, il y a collision avec un identifiant déjà connu, alors une nouvelle génération est requise. La date d’enregistrement de la clé publique discrimine un éventuel conflit entre deux identifiants identiques.

Req-06 La date <date> est la valeur ‘epoch’ avec un reset prévu en Janvier 2038.

Req-07 <hash-url> est le hashé avec ‘sha1’ de l’url publique complète du bien immatériel en vente (hors le préfixe «http://»). <enc-url> est la valeur chiffrée en EC-Elgamal avec la clé publique de l’acheteur du bien immatériel lui même (partie privée).

Req-08 <f-value> donne les valeurs statiques de la fonction-prix du bien immatériels; dans l’ordre:

  • \xi Paramètre de vitesse (7 bits); valeur divisée par 128 pour être normée (entre 0 et 1)
  • \epsilon Précision (4 bits); nombre de chiffres après la virgule
  • \mathcal{P}_1 Prix initial (18 bits) en ⊔
  • \mathcal{T}_{\infty} Revenu final escompté (27 bits) en ⊔

Req-09 <log> est un petit message optionnel de 20 octets maximum pouvant contenir la référence de facturation de l’achat ou tout autre indication à transmettre au vendeur. Le codage attendu est utf-8. Attention, ce message est inclus dans le message signés, donc non modifiable après signature.

Req-10 <price> est un prix maximum autorisé par l’acheteur, dans la monnaie locale. Pour l’€, le montant est exprimé en centimes et pour le $, il est exprimé en cents.

Req-11 <nb> est le numéro d’achat du bien immatériel. Il implique un prix maximum selon les paramètres statique du bien désiré. Utiliser la requête Post-Position pour avoir la valeur courante de <nb> et donc le prix courant du bien. Le message signé n’a pas besoin d’avoir la valeur <nb> ni le montant du prix du bien car il est impossible que ce prix augmente après l’achat (principe de remboursement du Partage Marchand).

Req-12 La requête Get-Balance en version « verbose » retourne les données pour éditer un relevé de compte à jour. En version courte, et appelée en interne par le nœud avec une valeur d’achat désirée, la requête retourne un « status » pour autoriser ou pas l’achat selon que le compte est provisionné ou pas. Par construction, un compte débiteur d’un particulier n’est pas possible.

Note-1 L’achat dans la monnaie locale est une version électronique du chèque classique qui indique la devise, l’émetteur, le destinataire, le montant, la signature et éventuellement une référence de facture. La requête d’achat (155 ou 157) octets binaires peu éventuellement être encodée dans un SMS. Aucune requête n’a besoin d’être chiffrée, elles transitent en clair sur le réseau.

Req-13 Attaques DOS. Les requêtes signées (déclaration de bien à vendre et achats) engagent leur auteur et donc sont peu abusives. La requête Get-Position est ré-dirigée vers le nœud principal hébergeant le bien. Ce serveur y répond très rapidement et peu refuser certains requêtes insistantes. La requête « Public-Key-Registration » est aussi un simple enregistrement ou une vérification d’existence dans la base locale, ce qui ne devrait jamais surcharger les nœuds.

La base de donnée locale (persistante) au nœud est de type clé-valeur. Nous suggérons d’utiliser une base de type Berkeley (par exemple GnuDB).

Nous donnons un exemple d’implémentation en Python ici.

Chaque nœud décide de prendre en charge ou pas un identifiant selon sa capacité et sa puissance. Il conserve donc toutes les transactions relatives aux identifiants adhérents au nœud et il renvoie à ses voisins les requêtes concernant les identifiants non pris en charge.

Une politique de répartition des prises en charge assure un compromis entre une nécessaire redondance de nœuds qui peuvent s’éteindre sans prévenir, et une optimisation de la sauvegarde pour minimiser le nombre de transactions transférées. La suite de la spécification portera sur l’architecture pair à pair et la synchronisation des nœuds.

Tout compte créé part avec un solde nul et suite à toute transaction, la somme des soldes reste nulle. Pour initier le système, il faut donc autoriser un certain type d’identifiants, nommés i-bank à avoir un solde négatif en deçà d’une limite. La qualification d’i-bank n’est obtenue auprès d’un seul agent, en charge de la sécurité du système. Cet organisme délivre contre la souscription d’un abonnement, un certificat de débit pour un montant donné et une durée (généralement 1 an, renouvelable). Les ibanks peuvent créditer le compte de leur clients contre l’opération inverse dans la monnaie locale sur leur compte de banque classique. Pour les conversions <->€ ou <->$ ou toute autre monnaie locale, une taxe est due et reversée par l’ibank à l’administration locale en charge de la monnaie locale.

Req-14 L’identifiant de l’organisme central en charge de la sécurité est «IbankVBixRIm». Dès sa création, chaque nœud conserve la clé publique racine:

AQTMiBfFFaDdokV0d7dPEeyURA_yUmMaXVaQm86YxciRuOpz5oSXdAh2r-6jxdj3cazLExL4B75-V3_hqtbuG_yI

Aeqq8dmyMTAZUZFBS0fCPK52TzZ6bEyo3H3QHzbk5geIepws4bi2se19WoyZ6xiWDk0COUXLvQAEIbankVBixRIm

Le certificat doit être vérifié (date/montant/signature) avant toute transaction d’une ibank vers un compte client.

Cette spécification se veut suffisante pour l’implémentation d’un nœud compatible et inter-opérable sur Internet.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s