Fair and abuse free contract signing protocol supporting fair license reselling-ntms2011-paris-france-tarek gaber

1. Fair and Abuse-free Contract Signing Protocol Supporting Fair License Reselling By Tarek Gaber PhD Candidate: School of Computer Science The University of Manchester, Manchester, UK 4th IFIP International Conference on New Technologies, Mobility and 4th IFIP International Conference on New Technologies, Mobility and Security (NTMS), 7 - 10 February 2011 in Paris - Fran1ce Security (NTMS), 7 - 10 February 2011 in Paris - France

2. Introduction  DRM (Digital Rights Management):  Content owners  Consumers 25/10/14  Persistent protection  Prevent unauthorized access  Managing usage rights (i.e. license)  E.g. expiration date, device restriction, etc.  Protect their monetary interests  Purchase licenses (from a License issuer (LI)) to access corresponding digital contents.  But can NOT resell their licenses NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

3. Reselling Deal (RD) Method[1] RD Pre-official RD Official-RD Send Alice’s license to Bob NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee Reseller (Alice) Buyer (Bob) 1- Negotiation •Agree on deal terms and conditions` 2- Signing •Commit to RD terms and conditions 3- Submission •Submit a signed RD •Make payment License Issuer (LI) 4- Activation •Revoke Alice’s license •Send Bob’s payment to Alice • RD done Handling Misbehaviour of Alice •Prevent further reselling: Blacklist •Impose a charge [1] T. Gaber and N. Zhang 2010

4. Current Contract Signing Protocols  Introduction  Gradual-release protocols  Optimistic contract signing 25/10/14 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

5. Introduction: Contract Signing Protocol  Use digital signatures to sign a contract over a network (the Internet )  Special type of fair exchange protocols  Important for electronic commerce  Example: Naive Two-party protocol: Alice ® Bob : SignA (contract) Bob ® Alice : SignB (contract) 25/10/14 5

6. Introduction: Contract Signing Protocol  Problems:  Not fair: Bob has got Alice’s signature but Alice has not  Abuse: Bob gain some advantage by showing to Charlie that Bob has indeed signed the contract and he is in control of the protocol outcome Alice ® Bob : SignA (contract) Bob ® Alice : Not-fair NSiogtnhing A (contract) Alice ® Bob : SignA (contract) Bob ® Alice : Nothing or SignB (contract) Non-abuse-free 25/10/14 6

7. Properties of Contract Signing  Fairness  If A can get B’s signature, then B can get A’s signature and vice-versa  Non-repudiation  No signer can deny having participated in the protocol  Abuse-freeness (provable advantage)  No signer can prove to an external party that he has the power to choose the outcome of the protocol (terminate or successfully complete the protocol) 25/10/14 7

8. Gradual-release Protocols  Dividing signatures to N verifiable parts  Exchanging the signatures part-by-part  Disadvantages  Not practical  Involved entities should have equal computational power  Inefficient  Many messages flows  High computational cost  Make each part verifiable  Prove that each part is correct Can we adopt one of the Gradual-release Protocols to sign the RD? 25/10/14 8

9. Optimistic Contract Signing (1 of 3)  Signers (A and B) optimistically sign a contract themselves A SignA(A, [contract, hash(NonceA)] ) SignB(B, [contract, hash(NonceB)] ) NonceA NonceB B SignSign A(A, [contract, NonceA] ) B(B, [contract, NonceB] ) 25/10/14 9

10. Optimistic Contract Signing (2 of 3)  If there is a problem, a TTP is only involved (e.g. A does not send M3) A M1:SignA(A, [contract, hash(NonceA)] ) M2:Sign(B, [contract, hash(NonceB)] ) B TTP M1 +M2 Signed Contract M3: XXX Signed Contract 25/10/14 10

11. Optimistic Contract Singing (3 of 3)  TTP is only involved if there is a problem  Disadvantages  Performance bottleneck  Decrease efficiency  Increase transaction cost  Difficult to find Can we adopt one of the current optimistic protocols to sign the RD? 25/10/14  Number of Message flow between TTP and signers NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee [2] Zhang, Wen, and Chen, 2008

12. TTP and Reselling Deal (RD) Method[1] 25/10/14 RD Pre-official RD Official-RD Send Alice’s license to Bob NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee Reseller (Alice) Buyer (Bob) 1- Negotiation •Agree on deal terms and conditions` 2- Signing •Commit to RD terms and conditions 3- Submission •Submit a signed RD •Make payment License Issuer (LI) 4- Activation •Revoke Alice’s license •Send Bob’s payment to Alice • RD done Handling Misbehaviour of Alice •Prevent further reselling: Blacklist •Impose a charge TTP [1] T. Gaber and N. Zhang 2010 TTP Increasing LI’s workload

13. Concurrent Signatures (CS) Scheme[3]  A digital signature scheme:  Non-binding or ambiguous signatures exchange, and  Releasing secret key called a keystone  Concurrently full binding signatures  Either the two exchanged signatures become binding, or none becomes.  Advantages:  No TTP  No equivalent computational power 25/10/14 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee [3] Chen, Kudla, and Paterson, 2004

14. CS Scheme Problems 25/10/14 Bob 4- Verifies ASignB (RD) NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee 2- Verifies ASignA (RD) 1- ASign A (RD) e-Book Alice 3- ASign B (RD) 5-Keystone Ks Ks, f=H (Ks) Where: ASign is Ambiguous Signature Ks is the Keystone Only Alice controls the releasing of the keystone Ks. So, she can abuse Bob’s signature and/or compromise the fairness X

15. CS and our Protocol  Can we utilize the CS advantages (i.e. no TTP, and no restriction of computational power) and overcome its problems? 25/10/14 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

16. Fair and Abuse-free Contract Signing Protocol Supporting Fair License Reselling*  Design considerations of the RDS protocol:  Fairness  Either both signers get a signed contract or none gets anything useful  Abuse-freeness  Inability to prove to an outside entity that a signer is able to control the output of a protocol.  Non-repudiation  No party could deny having generated his signature (NOO: Non-repudiation of Origin)  No party could deny having received a signature from the other signer (NOR: Non-repudiation of Receipt)  No dedicated TTP * Here after, it will be called Reselling Deal Signing (RDS) Protocol 25/10/14 16 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

17. RDS Protocol Assumptions  License Issuer (LI)  Trustworthy, issues licenses, and facilitates license reselling. It is already there in existing license distribution infrastructure  Reselling Permission of a license (R PLic)  It is issued with a resalable license  It is of the from [Lic||f||SignLI(Lic||f)], where f is the hash value of the keystone ks  Each license is issued with a unique ks  Channels are resilient, authenticated, and protected  Each entity has got a public/private key pair 25/10/14 17 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

18. RDS Protocol Description A B Msg1= {RD||ASignA(RD)||RPLic } Msg {RD ||ASign (RD )} 2 = ASignA B ASignA Msg3 { f || E (ks)} = PKB RDASignA (RD|| ASignA (RD)) = Bv1 and Bv2 Av1 and Av2 Bv3 After successful verification, Alice gets signed RD: After Msg1, Bob gets: After successful verification, RDS Protocol Verifications: Bob gets signed RD Bv1: Checking the correctness of RPi.e. Verifying Sign(Lic||f) Lic LIBv2: Checking the correctness h A + f = H2(of g s ASignA PK h A f A (RD) PK B ( mod p)||RD) ( mod q)? ABv3:Confirming that H(ks) equals H(f ks) which = was f in RPprovided ? Licin RP1Lic Av1:Confirming that the same f is used in both ASignand ASignA B Av1:Checking the correctness of ASignB 25/10/14 18 h f H2(g B PK B PK ( mod p)||RD ASign ) ( mod q)? A f A h B s B + = f in ASignA= f in ASignB?

19. RDS Protocol: Step 1 RD Unsigned RD Ambiguously signed RD 25/10/14 ASIGN algorithm Step 1: Alice ambiguously signs the RD, she then sends it to Bob NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee RD ASignA(RD) ƒ=H(ks), PKA,SKA , PKB with Alice

20. RDS Protocol : Step 2 RD ASignA(RD) 25/10/14 PKA, PKB AVERIFY algorithm Step 2.1: Bob verifies ASignA(RD) NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee Accept: Generate his ambiguous signature Reject: Terminate the protocol Ambiguously signed RD with Alice

21. RDS Protocol: Step 2 (Cont.) RD ASignA(RD) = ASignA RD 25/10/14 ASIGN algorithm ƒ=H(ks), PKB, SKB , PKA NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee ASignB( ) AARRDD iiggnnSSAA The RD Ambiguously Signed with Alice and Bob The RD ambiguously signed with Alice Step 2.2: Bob ambiguously signs the RD ambiguously signed by Alice, he then sends it to Alice again

22. RDS Protocol: Step 3 PKA, PKB ASignA RD Step 3: Alice verifies ASign( RD BASignA ), if the result is positive, Alice sends Bob ks which makes the two ambiguous signatures, ASign(RD), ASign( ), ABbinding to Alice and Bob respectively At this step, both Alice and Bob will have a signed RD bound to both of them 25/10/14 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee RD ASignA AVERIFY algorithm Accept: Send ks to Bob Reject: Terminate the protocol ASignB( ) ASignA RD The RD Ambiguously Signed with Alice and Bob

23. LI’s Role in the RDS protocol (1 of 2)  NOT involved in the RDS protocol itself  ONLY involved during the reselling process.  In case, ks is not released during RDS and Bob sends LI an RD activation request (i.e. initiating the reselling process), LI sends Bob the license Lic and the ks. 25/10/14 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

24. LI’s Role in the RDS protocol (2 of 2) Submitted RD Buyer’s signature is valid Reseller's signature is valid 25/10/14 LIV1 No buyer’s signature or it is not valid No reseller’s signature or it is not valid NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee No payment Payment is provided LIV2 LIV3.1 LIV3.2 LIV4 Stop and terminate the protocol run Payment is enough Payment is not enough Non-resalable (i.e. ks is not valid) Resalable Resold (i.e. ks is already released) Not resold yet LIV5 Accept and activate the submitted RD Legitimacy check

25. RDS Protocol Analysis (1 of 3)  Fairness  Alice and Bob behave properly  Fairness is achieved  Alice behaves improperly  Not sending Msg3 to Bob  Sending Bob wrong ks in Msg3  Sending an incomplete RD activation request to LI  Bob behaves improperly  Not sending Msg2  Sending an incomplete RD activation request to LI 25/10/14 25 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee Bob can send LI an RD activation request without ks Rejecte Nothing to d gain Rejecte d

26. RDS Protocol Analysis (2 of 3 )  Non-Repudiation  NOO of the signatures is achieved when:  Ks is released either by Alice or by LI  NOR of the signatures  Receiving Msg2 means that Alice has got NOR of ASignA  Receiving Msg3 (i.e. ks) means that Bob has got NOR of ASignB  Msg2 is not sent to Alice and Bob has sent LI an RD activation request, Alice and Bob will receive ASignB (NOR of ASignA) and ks (NOR of ASignB), respectively 25/10/14 26 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

27. RDS Protocol Analysis (3 of 3)  Abuse-Free  Bob can not abuse ASignA  ASignA is ambiguous  Alice can not abuse ASignB  ASignB consists of ASignA, this means that if Bob is binding to the RD then Alice is also binding to it (i.e. the protocol outcome has already been determined ) 25/10/14 27 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

28. Contribution and Future Work  To support fair license reselling, RDS protocol has been designed without using a dedicated TTP, thus reducing an additional computational cost.  The CS scheme and the current license distribution infrastructure (LI) has been integrated to achieve the RDS protocol properties.  The RDS protocol provides fairness, abuse-freeness and non-repudiation  The RDS protocol could be used in reselling both a digital license and an access permission  We are going to formally verify the RDS protocol 25/10/14 28 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee

29. Thanks Questions 25/10/14 29 NTMS’11, 7 - 10 February NTMS’11, 7 - 10 February 22001111,, PPaarrisis - - F Frraannccee