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

4th IFIP International Conference on New Technologies, Mobility and Security (NTMS), 7 - 10 February 2011 in Paris - France

4th IFIP International Conference on New Technologies, Mobility and Security (NTMS), 7 - 10 February 2011 in Paris - France1

Fair and Abuse-free Contract Signing Protocol Supporting Fair License

Reselling

By

Tarek GaberPhD Candidate: School of Computer Science

The University of Manchester, Manchester, UK

NTMS’11, 7 - 10 February 2011, Paris - FranceNTMS’11, 7 - 10 February 2011, Paris - France25/10/14

Introduction

DRM (Digital Rights Management): Content owners

Persistent protection Prevent unauthorized access

Managing usage rights (i.e. license) E.g. expiration date, device restriction, etc.

Protect their monetary interests

Consumers Purchase licenses (from a License issuer (LI))

to access corresponding digital contents. But can NOT resell their licenses

NTMS’11, 7 - 10 February 2011, Paris - FranceNTMS’11, 7 - 10 February 2011, Paris - France

Reselling Deal (RD) Method[1]

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

Pre-official RD

Official-RD

RD done

Handling Misbehaviour of Alice•Prevent further reselling: Blacklist•Impose a charge

Send Alice’s license to Bob

[1] T. Gaber and N. Zhang 2010


Current Contract Signing Protocols

Introduction

Gradual-release protocols

Optimistic contract signing

25/10/14 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 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

Bob → Alice : Nothing or SignB (contract)


Bob → Alice :Not-fair

Non-abuse-

free

NothingSignA (contract)


25/10/14 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 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 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

SignA(A, [contract, NonceA] )SignB(B, [contract, NonceB] )

25/10/14 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 ContractSigned Contract

M3: XXX


Optimistic Contract Singing (3 of 3)

TTP is only involved if there is a problem Disadvantages

Performance bottleneck Decrease efficiency

Number of Message flow between TTP and signers Increase transaction cost Difficult to find

[2] Zhang, Wen, and Chen, 2008

Can we adopt one of the current optimistic protocols to sign the RD?


TTP and Reselling Deal (RD) Method[1]

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

Pre-official RD

Official-RD

RD done

Handling Misbehaviour of Alice•Prevent further reselling: Blacklist•Impose a charge

Send Alice’s license to Bob

[1] T. Gaber and N. Zhang 2010

TTP

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

[3] Chen, Kudla, and Paterson, 2004


CS Scheme Problems

Bob

1- ASignA (RD)

e-Book

Alice

3- ASignB (RD)

5-Keystone Ks

Ks, f=H

(Ks)

Where:

ASign is Ambiguous Signature

Ks is the Keystone

2- Verifies ASignA (RD)

4- Verifies ASignB (RD)

Only Alice controls the releasing of the keystone Ks. So, she can abuse Bob’s signature and/or compromise the fairness

X

NTMS’11, 7 - 10 February 2011, Paris - FranceNTMS’11, 7 - 10 February 2011, Paris - France

CS and our Protocol

25/10/14

Can we utilize the CS advantages (i.e. no TTP, and no restriction of computational power) and overcome its problems?

NTMS’11, 7 - 10 February 2011, Paris - FranceNTMS’11, 7 - 10 February 2011, Paris - France25/10/14 16

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

Fair and Abuse-free Contract Signing Protocol Supporting Fair License Reselling*

* Here after, it will be called Reselling Deal Signing (RDS) Protocol


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 (RPLic) 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 18

RDS Protocol Description A B

}||{3 (ks)EfMsgBPK=

Bv1 and Bv2

Av1 and Av2

Bv3

)}(RD||ASign{RDMsgAA ASignBASign=2

}|RP(RD){RD||ASignMsg LicA |1=

After successful verification, Alice gets signed RD:

After Msg1, Bob gets:

))(||( RDASignRDRD AASignA=

After successful verification, Bob gets signed RDRDS Protocol Verifications:

Bv1: Checking the correctness of RPLic

Bv2: Checking the correctness of ASignA(RD)

Bv3:Confirming that H1(ks) equals f which was provided in RPLic

Av1:Confirming that the same f is used in both ASignA and ASignB

Av1:Checking the correctness of ASignB

i.e. Verifying SignLI(Lic||f)

?modmod2 q) p)||RD) ( ( PKPK(gH f h fB

hA

sA

AA=+

?modmod2 q)) ( p)||RD ( PKPK(gH f hA

BBASign

fA

hB

sB =+

f in ASignA= f in ASignB?

H(ks) = f in RPLic?


RDS Protocol: Step 1

Step 1: Alice ambiguously signs the RD, she then sends it to Bob

RD

ASIGN algorithm

RD

ASignA(RD)

ƒ=H(ks), PKA,SKA , PKB

Unsigned RD Ambiguously signed RD with Alice


RDS Protocol : Step 2

Step 2.1: Bob verifies ASignA(RD)

AVERIFY algorithmRD

ASignA(RD)

PKA, PKB

Accept: Generate his ambiguous signature

Reject:Terminate the protocol

Ambiguously signed RD with Alice


RDS Protocol: Step 2 (Cont.)

ASIGN algorithm

ƒ=H(ks), PKB, SKB , PKA

RD

ASignA(RD)

= AASignRD

ASignB( )AA SignRD AA SignRD

The RD Ambiguously Signedwith 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

Step 3: Alice verifies ASignB( ), if the result is positive, Alice sends Bob ks which makes the two ambiguous signatures, ASignA(RD), ASignB( ), binding to Alice and Bob respectively

At this step, both Alice and Bob will have a signed RD bound to both of them

RDAASign

RDAASign

AVERIFY algorithm

PKA, PKB

Accept: Send ks to Bob

Reject:Terminate the protocol

ASignB( )AASignRD

AASignRD

The RD Ambiguously Signedwith Alice and Bob


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.

LI’s Role in the RDS protocol (1 of 2)


LI’s Role in the RDS protocol (2 of 2)

LIV1No payment

Payment is provided

LIV2

LIV3.1

LIV3.2

LIV4

Stopand

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

No buyer’s signature or it is not valid

No reseller’s signature or it is not valid

Buyer’s signature is valid

Reseller's signature is valid

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

Bob can send LI an RD activation request

without ks

RejectedNothing to

gain

Rejected


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


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 )


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


ThanksQuestions

Technology

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