1. Multi-Vendor PayWord with Payment Approval Andrea Huszti University of Debrecen Debrecen, Hungary

2. Contents Micropayments vs. macropayments PayWord Security requirements Modeling modified PayWord Applied pi calculus, ProVerif Security analysis

3. Micropayments vs. macropayments Micropayments: consequence of Internet applications charge small amount (<$1 or <$10) one song, one article, on-line games etc. content and service providers Minimize financial costs

4. Micropayments vs. macropayments SSL – based e-payment: – Minimal transaction fee: 20-30 cents per purchases – 2-6% fee per purchases – Monthly fee – Installation fee (once) Cannot be used for micropayments Cost of disputes and charge backs: price + transaction fees + penalty (>$150 Payment Technologies for E-commerce) for the vendor in case of micropayments

5. Micropayments Our goal is to increase security level of PayWord, minimize disputes, charge backs or to avoid attacks that ruin the reputation of the vendor. Computational costs should be minimized ---> no public key cryptography Payment approval

6. PayWord - Preparation User (U) – Broker (B) relationship – U B : U, PKU – B U : Sign SKB (B,U,PKU,E,Inf) = C U (PayWord certificate) User (U) – Vendor (V) relationship – U: w n, w n-1, w n-2, …, w 1, w 0 - payword hash chain w i =H(w i+1 ) – U V: Sign SKU (V,C U, w 0,D) = M U

7. PayWord - Payments – U V: (w 1,1) – U V: (w 2,2) – U V: (w 3,3) … – U V: (w n,n)  Short term relationship  fast (no public key crypto)  off-line (no broker is on-line) Verification: H i (w i )=w 0 H i-j (w i )=w j if j<i (store w i )

8. PayWord – Pay-off Vendor (V) – Broker (B) relationship – V B: Sign SKU (V,C U, w 0,D), (w l,l) Security requirements – Secrecy of payment information – Unreusability (double-spending prevention) – Payment authorization – Payment approval

9. Multi-Vendor PayWord Semi-onlineOn-line databaseBlack list broker is on-line, whenever a customer changes vendors expensive each vendor has access a vendor reads and modifies data for every transaction expensive brokers maintain a list of users who did not pay for products, services do not prevent first violations M. Payeras-Capella, J. L. Ferrer-Gomila, L. Huguet-Rotger, LNCS, (2003) M. Hosseinkhani, E. Tarameshloo, M. Shajari, CIS (2010) C.T. Wang, C.C. Chang, C.H. Lin, ECR, (2002) H. Wang, J. Ma, J. Sun, ECS, (2009) Idea: PayWord certificate protects against double-spending

10. Multi-Vendor PayWord with Payment Approval Participants: User (U), Vendors (V 1, …,V j ), Broker (B) User: 1.Generates two random values: w n (=w j,k j ), v 2. w i,l = U can spend at most k i paywords at V i w j,k j,...,w j,0, w j-1,k j-1,...,w j-1,0, …,w 1,0 H(w i,l+1 ), if 0≤l<k i H(Enc v (w i+1,0 )), if l=k i

11. Multi-Vendor PayWord with Payment Approval: Preparation User Broker K random AEnc B (Sign U (K, hostU, hostB)), hostU n random BConnectstoU(hostU,hostB,K,n) Enc K (n,hostU) UAcceptsB(hostU,hostB,K,n) Enc K (CardInf, hostU, n, w j,0, hostV j, …,w 1,0, hostV 1 ) ValidCertificate(hostU,hostB,K,n) Sign B (hostB, hostU, E, I, w j,0, hostV j, …,w 1,0, hostV 1 ) BAcceptsU(hostU,hostB,K,n)

12. Payment authorization Guarantees a proof for the vendor, that there is sufficient fund on the user’s account. : 1.Broker authentication 2.Consumer authentication 3.Certificate Secure payment authorization is achieved, if the certificate is undeniable.

13. Secrecy of payment information Confidential payment information is not revealed for adversaries. Unreusability If the same coin is spent more than once, then the identity of the second spender should be detected.

14. Multi-Vendor PayWord with Payment Approval: Payments User Vendor i KV random s, hostV i s random V i AcceptsMU(hostU,hostV i ) V i ReadytoPurchase(hostU,hostV i ) Sign U (PwCert, D, s, AEnc V i (KV)) Enc KV (page l ) V i AcceptsPayment l (hostU,hostV i )UV i EndsPayment l (hostU,hostV i ) OrderInf l, MAC H(KV) (OrderInf l,w i,l,l) w i,l,l

15. Payment approval Generates a proof for the vendor that a consumer agrees to pay a certain amount of money for a particular product. 1.User authentication 2.Vendor authentication 3.Order information 4.Price information Secure payment approval is achieved, if the proof is undeniable. proof

16. Multi-Vendor PayWord with Payment Approval: Pay-off Vendor i Broker Sign U (PwCert, D, s, Enc V i (VK)), (w i,l,l), hostV i

17. Applied pi calculus Σ: a set of function symbols L,M,N, T,U,V ::= terms – a, b, c, … name – x, y, z variable – f(M 1 1, …,M l ) function application P,Q,R ::= processes – 0 null process – P|Q parallel composition – !P replication – νn.P name restriction (new) – if M = N then P else Q conditional – u(x).P message input – u.P message output A,B ::= extended processes – P plain process – A|B parallel composition – νu.A restriction – {M/x} active substitution

18. ProVerif for analyzing cryptographic protocols automatically handles input files encoded in applied pi we can formalize cryptographic primitives Proves: – Reachability  secrecy – Correspondence assertions  authenticity

19. Equation theory Fun H/1. – hash function Fun Mac/2. – Mac function Fun senc/2. – symmetric encryption Reduc sdec(senc(x,y),y)=x Fun pk/1. – keygeneration Fun penc/2. –asymmetric encryption Reduc pdec(penc(x,pk(y)),y)=x Fun sign/2. – digital signature with message recovery Reduc checksign(sign(m,k),pk(k))=m

20. ProVerif queries Reachability: – query attacker : m. Correspondance assertions: – F ==> H : if F holds, then H also holds – Important stages: events – query ev : a(x; y) ==> ev : b(y; z) – query evinj : a(x; y) ==> evinj : b(y; z)

21. Queries Payment Authorization: query evinj: ValidCeritficate (x,y,z,t) ==> evinj: BconnectstoU(x,y,z,t). query evinj: BacceptsU(x,y,z,t) ==>(evinj: UacceptsB(x,y,z,t) ) ==> evinj: BconnectstoU(x,y,z,t)). proof: Sign B (hostB, hostU, E, I, w j,0, hostV j, …,w 1,0, hostV 1 ) Secrecy of PI: query attacker:CardInf.

22. Multi-Vendor PayWord with Payment Approval: Preparation User Broker K random AEnc B (Sign U (K, hostU, hostB)), hostU n random BConnectstoU(hostU,hostB,K,n) Enc K (n,hostU) UAcceptsB(hostU,hostB,K,n) Enc K (CardInf, hostU, n, w j,0, hostV j, …,w 1,0, hostV 1 ) ValidCertificate(hostU,hostB,K,n) Sign B (hostB, hostU, E, I, w j,0, hostV j, …,w 1,0, hostV 1 ) BAcceptsU(hostU,hostB,K,n)

23. Queries Payment Approval: query evinj: V i AcceptsPayment(x,y) ==> evinj: V i ReadytoPurchase(x,y) query evinj: UV i EndsPayment(x,y) ==> evinj: V i AcceptsMU(x,y) proof: MAC H(KV) (OrderInf l,w i,l,l)

24. Multi-Vendor PayWord with Payment Approval: Payments User Vendor i KV random s, hostV i s random V i AcceptsMU(hostU,hostV i ) V i ReadytoPurchase(hostU,hostV i ) Sign U (PwCert, D, s, AEnc V i (KV)) Enc KV (page l ) V i AcceptsPayment l (hostU,hostV i )UV i EndsPayment l (hostU,hostV i ) OrderInf l, MAC H(KV) (OrderInf l,w i,l,l) w i,l,l

25. Thank you for your attention!