Les avantages du protocole Pay-to-Contract

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 génère un couple clé privée/clé publique temporaire qui ne servira que pour cette transaction.

Le Marchand envoie au Client la Facture avec les informations suivantes :

• ordre
• prix total
• adresse paiement

La Facture est signée par le Marchand.

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)

L'Offre est signé par le Marchand avec la clé privée PrivM correspondant à la clé publique PubM.

Le Client envoie au Marchand le bon de commande rempli (Facture) avec les informations suivantes :

• quantité
• adresse livraison

Le Client calcule l'adresse de paiement en hashant la Facture et PubM qui vont donner un couple clé privée/clé publique intermédiaire. On dérive PubM avec la clé publique intermédiaire, ce qui permet d'obtenir une nouvelle clé publique PubD dont la clé privée PrivD ne peut être calculé qu'en dérivant PrivM avec le hash de la Facture et de PubM.

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

Propriété homomorphe des clés ECDSA

• 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

Implications

• 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

Vidéo explicative (simple) :  https://www.youtube.com/watch?v=qwyALGlG33Q