Version compacte compliquée
L’idée c’est qu’à partir de la clé publique du marchand, le
client peut envoyer le paiement à une adresse qu’il sait que seul le marchand
pourra dépenser.
A partir de la clé publique du marchand, le client calcule
une nouvelle clé publique via un seed aléatoire et y transfère les fonds. Le
marchand dérive la clé privée associé au seed grâce à sa propre clé privée
grâce aux propriétés homomorphes de ECDSA.
L’avantage est que la clé privée du marchand peut être
gardée offline et que seuls le marchand et le client savent que l’adresse
utilisée correspond au marchand. On ne peut pas voir toutes les transactions du
marchand.
Mise en situation
Le marchand M vend des produits sur son site web.
Le client C achète des produits au marchand.
Le système de paiement P certifie le transfert de fonds entre M et C.
Le système de livraison L certifie la livraison des produits de M vers C.
Solution technique classique
Le Marchand met à disposition du Client des Offres qui contiennent les informations suivantes :
- description produit
- prix
Le Client envoie un Ordre au Marchand avec les informations suivantes :
- offre
- quantité
- adresse livraison
Le Marchand envoie au Client la Facture avec les informations suivantes :
- ordre
- prix total
- adresse paiement
Solution Pay-to-Contract
Le Marchand met à disposition du Client des bons de commandes (Offre) qui contiennent les informations suivantes :
- description produit
- prix
- base d'adresse de paiement (PubM)
Le Client envoie au Marchand le bon de commande rempli (Facture) avec les informations suivantes :
- quantité
- adresse livraison
Le Client envoie le paiement à l'adresse associée à PubD.
C'est cette transaction qui est le Contrat.
Avantages
Dans la solution classique, le Marchand doit garder sa clé privée online car il en aura besoin pour signer la Facture. Pour récupérer le paiement, le Marchand doit utiliser la clé privée temporaire qu'il a généré lors de l'émission de la facture et qui est gardée online donc vulnérable.
Le protocole Pay-To-Contract permet de garder la clé privée offline car le Marchand peut signer les Offres offline, et c'est le Client qui va signer le Contrat avec sa clé publique lors du paiement. Pour récupérer le paiement, le Marchand dérive la clé privée en offline, elle n'est donc pas vulnérable.
L'attaque qui consiste à remplacer l'adresse de paiement temporaire dans la facture émise par le Marchand pour que le Client envoie les fonds à une adresse malicieuse est de fait inapplicable.
Homomorphisme
Définition du couple clé privée/clé publique (s,P)
- N est un nombre premier fixe
- La clé privée s est un entier compris entre 0 et N-1
- La clé publique P=P(s) est fonction de s
- Soit les couples clé privée/clé publique (s,P) et (t,Q)
- Alors le couple clé privée/clé publique (s+t mod N,P+Q) est un couple valide
- Si la clé privée t est publiquement connu alors les clés publiques P et P+Q peuvent être signés par la clé privée s
Réflexions
Le protocole Pay-to-Contract impose un changement fonctionnel conséquent dans le workflow du site Marchand.
En effet, c'est le Client qui est à l'initiative du contrat de vente qui va être signé avec le Marchand.
Ce qui peut être un challenge au niveau légal, car le Marchand n'a pas implicitement/activement accepté le Contrat.
Mon opinion personnelle est que le Contrat n'est signé par le Marchand que lorsque la transaction à été dépensée.
Une amélioration envisageable serait de rajouter un Smart Contract dans la transaction qui dit que la somme peut être dépensée seulement par le Marchand pendant N jours et que passé ce délai, seul le Client peut la dépenser.
Cela permettrait au Marchand d'accepter explicitement le Contrat ou de le refuser, et ce sans avoir à faire de remboursement au Client.
Sources
Article de référence (compliqué) : http://arxiv.org/pdf/1212.3257v1.pdf