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

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

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

Reselling Deal (RD) Method[1]
RD
Pre-official RD
Official-RD
Send Alice’s license to Bob
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

Current Contract Signing Protocols
 Introduction
 Gradual-release protocols
 Optimistic contract signing
25/10/14

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

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
Bob ® Alice :
Not-fair
NSiogtnhing A (contract)
Bob ® Alice : Nothing or SignB (contract)
Non-abuse-free
25/10/14 6

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

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

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

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

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
[2] Zhang, Wen, and Chen, 2008

TTP and Reselling Deal (RD) Method[1]
25/10/14
RD
Pre-official RD
Official-RD
Send Alice’s license to Bob
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

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
[3] Chen, Kudla, and Paterson, 2004

CS Scheme Problems
25/10/14
Bob
4- Verifies
ASignB (RD)
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

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

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

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

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?

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
RD
ASignA(RD)
ƒ=H(ks), PKA,SKA , PKB
with Alice

RDS Protocol : Step 2
RD
ASignA(RD)
25/10/14
PKA, PKB
AVERIFY algorithm
Step 2.1: Bob verifies ASignA(RD)
Accept:
Generate his ambiguous signature
Reject:
Terminate the protocol
Ambiguously signed RD
with Alice

RDS Protocol: Step 2 (Cont.)
RD
ASignA(RD)
= ASignA RD
25/10/14
ASIGN algorithm
ƒ=H(ks), PKB, SKB , PKA
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

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
RD ASignA
AVERIFY algorithm
Accept:
Send ks to Bob
Reject:
Terminate the protocol
ASignB( ) ASignA RD
The RD Ambiguously Signed
with Alice and Bob

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

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
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

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
Bob can send LI an
RD activation request
without ks
Rejecte
Nothing to d
gain
Rejecte
d

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

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

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

Thanks
Questions
25/10/14 29

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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (10)

More from Tarek Gaber

More from Tarek Gaber (15)

Recently uploaded

Recently uploaded (20)

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

Editor's Notes