Final presentation

Round Saving Bulletin-based
Tripartite e-Lottery Protocol
Dec. 18, 2001
2001140
C&IS lab.
Ham Woo Seok
[email protected]
Contents
1. Overview
2. Threats
3. Requirement
4. Pervious Work –
KMHN00,GS98
5. Proposed scheme
6. Further Works
7. Reference
2
1.Overview
 Sports TOTO

 Sports TOTO
Target
Soccer (K-league), Basket ball
Publisher
Seoul Olympic Sports Promotion Foundation(SOSPF)
Consignee
Tigerpools Korea
Game type
Result-based (1X2)
Rate
1,000 won per an unit (maximum 96 units)
Available
Up to 10 minutes before game
Restriction
Less then 100,000 won a person /Over 19 years old
Annual Issue
Less than 90 times
Prize
50% of the amount of sold tickets
If no winner, winning pool is rolled over to the next lottery
Sequence
Fill out the ticket  present ticket with money to vender receive
a receipt
England (Football Pools,1923), France (Loto Foot), Italia (TotoCalcio, TotoGoal),
Japan(TOTO) etc.
3
1. Overview
 Real Ticket Image
4
2. Threats
 Ticket Information manipulation
 Altering, Insertion, Deletion
 Promoter’s misbehaviors
 Wrong winning computation, No payment of prize, etc
 Collusion of lottery components
 User, Lottery organizer, Financial facility, Vendor, Audit authorities etc.
 Phantom vendors
 Receive claims and disappear
 Denial of service
 Hindrance of normal operation, penalization of server, etc
 Disputes
 Winner arguments, refund etc
5
3. Requirement
 Basic requirement
 Reduction of Computational complexity & communication data
 Security requirement
 R1: Privacy


R2: Fairness


Lottery ticket cannot tampered
R6: Timeliness


Participants can verify lottery organizer’s misbehavior to update and add any
data illegally
R5: Unforgeability


Valid winnings could be verified publicly
R4: Reliability


Every ticket has the same probability to win
R3: Publicly verifiability


Prize-winner’s privacy should be maintained
A lottery should be terminated in the pre-defined period
R7: Traceability

Anyone can decide who made an injustice
6
4. Previous Work – GS98
 David M. Goldschlag, Stuart G. Stubblebine, IFCA 98
 Drawing number type lottery based on delaying function
 Delaying function



Function F is moderately hard to compute given a minimum operation time P,
and probability that function is computable is arbitrarily small
F preserves the information of its inputs. No information leakage
e.g) large number of rounds of DES in OFB mode
 Notation
 L, C : Lottery server, Client respectively
 [X]K : Keyed one way hash function
 CertC : Certification of client C
 Seq : Sequence number of lottery ticket
 Time: Time stamp
 Seed: betting information
 P : critical purchase period
 L : the total number of sold tickets
7
4. Previous Work – GS98
 Phases

Registration




To make a certain collusion which can control lottery impossible,
identification is needed
Mapping between client and client agent by certification
For anonymous, use bind certificate or lottery service own certificate
Purchase
Seed Kc , CertC , Payment
Client



Seed  K , Seg L , TimeL , CertC
c
K
Server
L
Sequence number: to supervise server’s injustice(double issue, nonregistration, etc) by audit query
Time Stamp: To verify that Critical purchase period and time is
correct and registration was processed within the time
8
4. Previous Work – GS98

Critical Purchase period



It is published before a lottery game
Delaying function cannot yield result within this period
Winning Entry Calculation
hP  h(S1, S2 ,..., Sn )
hP
Delaying function : f (h p )
Winning
Number
All seed values within P
 Problems
 Only applicable to simple lottery such as number based one
 Winning verification time is too long



Needed the same time as total game period
Insider in server can forge or alter betting information
Attacking method computationally, information-theoretically on current
cryptosystem is rapidly improving
9
4. Previous Work – KMHN00
 K.Kobayashi, H.Morita, M.Hakuta, T.Nakanowatari, IEICE 2000
 Soccer lottery protocol Based on Bit commitment & Hash function
 Notation
 h: hash function
 h*: partial information of hash value
 TLP: Target Lottery Pattern (=mark sheet)
 PID: Personal Identification information
 SID: Shop Identification
 n: total ticket number sold by a shop
 SLI: Concatenation of SID, Lottery number, n)
 || : concatenation
 Sig: Digital signature
 $M: Electronic money
10
4. Previous Work – KMHN00
 Lottery Protocol : 3 main phases
Database TLP
h2
h1
SID
7)
Promoter
4) h 2  h( SID || h1)
4)
9) Digital Sig
Purchase Protocol
Inquirty Protocol
6) TLP , h 2 *
7) h 2
8) n
3) TLP , SID, h1,$M
9) Sig ( SLI || n)
2) TLP , h1,$M
User
1) h1  h(h( PID) || TLP )
Shop
3) SID
5) h2  h( SID || h1)
1) h( PID)
Payment Protocol
(Off-line)
User
2) PID
Bank
3) prize
11
4. Previous Work – KMHN00
 Details
 Purchase protocol
1) User computes hash value h1 with the concatenation of hashed PID, TLP
 Hashed PID: If original PID used, an malicious insider in bank can
impersonate prize winners. Also, PID includes a random number to hide
PID itself.
 TLP: it is generated by User according to specific rules
2) User sends TLP, h1, and fee (electronic money) for her betting
3) User receives SID as a receipt and Shop transfer TLP, h1, $M and SID
together
4) Promoter yields h2 using SID and h1 and store TLP, h2, h1, SID

Inquiry protocol (To verify her betting information is registered)
5) User calculates h2
 h2: prevent information difference between Promotor & Shop
6) User sends TLP and partial value of h2 (=h2*) to Promoter
7) Promoter searches and extracts matching values with TLP & partial hash
value from database and send them to User
12
4. Previous Work – KMHN00

After closing (To detect the promoter’s injustice to update the database
illegally)
8) Promoter notifies Shop the number of lottery tickets which are from Shop
9) Shop confirms the number, if right, she generates signature with SID, lottery
number and n. and Promoter generates digital signature on all TLPs and h2s

Payment protocol (Off-line operation)
1) Winner sends her hash value of PID
2) She visits the Bank(financial facility) and presents her real ID in person
3) If correct, Bank delivers a prize to her
13
4. Previous Work – KMHN00
 Problems
 No reliability, unforgeability: Promoter can find possible partial
combination of summation of TLP and h2.


No reliability and unforgeability: Collusion of Promoter and Shop might
be occurred to get manipulate total lottery number and information


When fault occurred, one can not trace who made a fault.
Inconvenience: Prize-payment by off-line


Since Bank is dependent of promoter and her signature is simple summation
of TLP and h2
No traceability


she can alter some information which does not match to one from shop after
closing the period, since there is no relationship between promotor and shop
after bidding end.
In case of small prize, User feel inconvenience
No privacy: PID can not be secret information

Since all bidder know the type of PID, a fake winner is able to prove herself
as a prize winner
14
5. Proposed scheme: notation & assumption
 Notation
P : player
SP : lottery service organizer
B : Bank
SK C , PK C : Component' s private key and public key
M : betting informatio n ( mark sheet)
Hash : Universal One  Way Hash Function
H n , HC n : n th hash result and hash chain result
Pay m : m values of electronic payment
PID, BID, SPID : player's ID, Bank' s ID, Lottery Provider's ID
Cert P : player's certificate
LBI : Lottery Betting Informatio n
 Assumption





Lottery ticket is generated by Users themselves along with pre-defined rules
Lottery Organizer allows only allied Banks
Operation period is chosen considering transaction time among every components
User and Bank communication is secure (ex, SSL, Public key system)
Certification is effective in this lottery only
15
5. Proposed scheme
 1-6. Pre-Preparation Phase
Seed, m
P
B
 2-6. Pre-Betting Phase
1) H P  Hash ( Seq # || LBI P || PaymP  k )
Seq # , H P , k , Info
P
B
Cert P
Cert P  Seq # , j , Hash( H P || BID || k ), BID, ESK B
16
5. Proposed scheme
 3-6 Betting Phase
Seq # , LBI Pi , PaymPi k , Cert Pi
P
Seq # , i, HCi , Tamp SK SP
S
P
1) check H in Cert Pi  Hash( H Pi || BID || Pay mPi k || k )
2) check current time  E in Cert Pi
3) compute HCi  Hash( LBI Pi || Pay mPi k || HCi 1 )
for HC K 0  0| Hash|
 4-6 Closing Phase
 When the predetermined lottery operation period is over
DS SP  Hash(n || HCn )SK SP
n  total # players
17
5. Proposed scheme
 5-6 Winner Selection Phase
 When game is over, automatically selected
 6-6 Claming of Winning
1) generate List ( j , LBI Pi , PaymPi k , prizePw )
w  winner ' s i
Seq # , ( j , k , Pay Pi ), DS SP ( Pay )
Seq # ,WinningPool , List , DS SP ( List )
S
P
B
Pay redemption
?
compare j ' s H P  Hash ( Seq # || LBI Pi || Pay mPi k ) from List
if correct, deposit winnig to Player ' s account
18
5. Proposed scheme
 Communication
PRE : Pay deposit
P
Betting
B
Cert, Pay generation
S
P
POST : Payment request and reply
19
6. Evaluation
 R1.Privacy
 All data which SP received looks random, No information related player’s identity
 R2.Fairness
 Independent ticket generation, No controlling in the sports game
 R3. Publicly verifiability
 The result is announced in public media
 R4. Reliability
 By Digital signature, Bulletin board , Hash chain
 R5. Unforgeability
 By Hash chain and Certificate
 R6. Timeliness
 Pre-determined period and Digital signature
 R7. Traceability
 By bank’s normal operation and data storing (semi-TTP), interactive protocol
20
7. Comparison
KMHN00
Proposed
Multiple choice
Multiple choice
# of Components
4
3
Winning Payment
Off-line
On-line
(2I + 1O) * N + 1I + 1O +
1I (Off/Post) +  (inquiry)
2I*N + 1O (Pre) + 1I
(Post)
R1. Privacy
Δ
O
R2. Fairness
O
O
R3.Publicly verifiability
O
O
R4. Reliability
X
O
R5. Unforgeability
X
O
R6. Timeliness
O
O
R7. Traceability
X
O
Lottery provider
(2Hash + LBI + SID) * N
(1Hash + LBI + Index)*N
+  (Hash chain)
1H + LBI of Winners
1H + Index
Type
General
# of Communications
(I : Interactive, O: One-way)
Security
Storage
Bank
21
8. Conclusion
 Proposed Round saving bulletin-board Tripartite electronic
lottery protocol
 Secure and practical protocol
 7 security requirements
 Low Communication loads and reduced storage
 No expensive computation
 Primitives: Hash chain & Pay (a variant of Payword)
 Bank as a semi-TTP
22
References







[ 1 ] D.M.goldschlag and S.G.Stubblebine, Publicly Verifiable Lotteries: Applications of
Delaying Functions, Proc.of Financial Cryptography 98, LNCS 1465, pp.214-226, 1998.
[2] Eyal Kushilevitz and Tal Rabin, Fair e-Lotteries and e-Casinos, CT-RSA2001, LNCS
2020, pp. 100-109, 2001.
[3] F.Bao, R.H.Deng and W.Mao, Efficient and practical fair exchange protocols with off-lint
TTP. Proc.of IEEE Symposium on Security and Privacy, pp.77-85, 1998.
[4] Jianying Zhou and Chunfu Tan, Playing Lottery on the Internet, ICICS2001, LNCS2229,
pp.189-201, 2001.
[5] K.Kobayashi, H.Morita, M.Hakuta, and T.Nakanowatari, An Electronic Soccer Lottery
System that Uses Bit Commitment, IEICE00, Vol.E83-D, pp.980-987, 2000.
[6] R.L.Rivest, Electronic Lottery Tickets as Micropayments, Proc.of Financial Cryptography
97, LNCS 1318, pp.307-314, 1998.
[7] R.L. Rivest and A. Shamir, PayWord and MicroMint: Two simple micropayment schemes,
International workshop on Security Protocols, LNCS 1189, pp.69-87, 1997.
[8] Ross Anderson, How to cheat at the lottery, Proc. of Computer Security Applications
Conference, 1999.
[9] available from www.tigerpools.co.kr .
[10] available from home.netscape.com/eng/ssl3.
23