Embed Size (px)
Citation preview
Round Saving Bulletin-based Round Saving Bulletin-based Tripartite e-Lottery ProtocolTripartite e-Lottery Protocol
Dec. 18, 20012001140C&IS lab.
Ham Woo [email protected]
2
ContentsContents
1. Overview
2. Threats
3. Requirement
4. Pervious Work – KMHN00,GS98
5. Proposed scheme
6. Further Works
7. Reference
3
1.Overview1.Overview
Sports TOTO
England (Football Pools,1923), France (Loto Foot), Italia (TotoCalcio, TotoGoal), Japan(TOTO) etc.
Sports TOTOTarget 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
4
1.1. OverviewOverview
Real Ticket Image
5
2. 2. ThreatsThreats
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
6
3. 3. RequirementRequirement
Basic requirement Reduction of Computational complexity & communication data
Security requirement R1: Privacy
Prize-winner’s privacy should be maintained R2: Fairness
Every ticket has the same probability to win R3: Publicly verifiability
Valid winnings could be verified publicly R4: Reliability
Participants can verify lottery organizer’s misbehavior to update and add any data illegally
R5: Unforgeability Lottery ticket cannot tampered
R6: Timeliness A lottery should be terminated in the pre-defined period
R7: Traceability Anyone can decide who made an injustice
7
4. 4. Previous Work – GS98Previous Work – GS98
David M. Goldschlag, Stuart G. Stubblebine, IFCA 98 Drawing number type lottery based on delaying functiondelaying 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
8
4. 4. Previous Work – GS98Previous 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
Sequence number: to supervise server’s injustice(double issue, non-registration, etc) by audit query
Time Stamp: To verify that Critical purchase period and time is correct and registration was processed within the time
PaymentCertSeed CKc,,
Lc KCLLK CertTimeSegSeed ,,,
ClientClient Server
Server
9
4. 4. Previous Work – GS98Previous Work – GS98
Critical Purchase period It is published before a lottery game Delaying function cannot yield result within this period
Winning Entry Calculation
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
),...,,( 21 nP SSShh
All seed values within P
)(: phffunctionDelayingPh
WinningNumberWinningNumber
10
4. 4. Previous Work – KMHN00Previous Work – KMHN00
K.Kobayashi, H.Morita, M.Hakuta, T.Nakanowatari, IEICE 2000
Soccer lottery protocol Based on Bit commitment & Hash functionBit 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
11
4. 4. Previous Work – KMHN00Previous Work – KMHN00
Lottery Protocol : 3 main phases
UserUser
PromoterPromoter
ShopShop
SIDh1h2TLP
)1||(2)5
)||)((1)1
hSIDhh
TLPPIDhhh
MhTLP ,$1,)2
SID)3
*2,)6 hTLP
2)7 h
)||()9 nSLISig
MhSIDTLP ,$1,,)3n)8
)1||(2)4 hSIDhh )7
)4SigDigital)9
UserUser BankBank
)()1 PIDh
PID)2
Inquirty Protocol
Payment Protocol
(Off-line) prize)3
Database
Purchase Protocol
12
4. 4. Previous Work – KMHN00Previous 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 rules2) User sends TLP, h1, and fee (electronic money) for her betting3) User receives SID as a receipt and Shop transfer TLP, h1, $M and SID
together4) 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 & Shop6) User sends TLP and partial value of h2 (=h2*) to Promoter7) Promoter searches and extracts matching values with TLP & partial hash
value from database and send them to User
13
4. 4. Previous Work – KMHN00Previous 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
14
4. 4. Previous Work – KMHN00Previous Work – KMHN00
Problems No reliability, unforgeability: Promoter can find possible partial
combination of summation of TLP and h2. 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.
No reliability and unforgeability: Collusion of Promoter and Shop might be occurred to get manipulate total lottery number and information
Since Bank is dependent of promoter and her signature is simple summation of TLP and h2
No traceability When fault occurred, one can not trace who made a fault.
Inconvenience: Prize-payment by off-line 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
15
5. 5. Proposed scheme: notation & assumptionProposed scheme: notation & assumption Notation
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
nInformatio BettingLottery :
ecertificat splayer' :
ID sProvider'Lottery ID, sBank' ID, splayer' : ,,
payment electronic of values :
resultchain hash andresult hash th : ,
FunctionHashWayOneUniversal:
sheet)mark (n informatio betting:
key public andkey private sComponent':,
Bank:
organizer servicelottery:
player:
LBI
Cert
SPIDBIDPID
mPay
nHCH
Hash
M
PKSK
B
SP
P
P
m
nn
CC
16
5. 5. Proposed scheme Proposed scheme
1-6. Pre-Preparation Phase
2-6. Pre-Betting Phase
P BmSeed ,
P B
InfokHSeq
PayLBISeqHashH
P
PkmPP
,,,#
)||||#()1
BPP
P
SKEBIDkBIDHHashjSeqCert
Cert
,),||||(,,#
17
5. 5. Proposed schemeProposed scheme
3-6 Betting Phase
4-6 Closing Phase When the predetermined lottery operation period is over
PSP
ii
i PP
kmP CertPayLBISeq ,,,#
||1 0)||||()3
)2
)||||||()1
,,,#
0
HashKi
PkmPi
P
PkmPP
SPi
HCforHCPayLBIHashHCcompute
CertinEtimecurrentcheck
kPayBIDHHashCertinHcheck
SKTampHCiSeq
ii
i
iii
playerstotalnSKHCnHashDS SPnSP #)||(
18
5. 5. Proposed schemeProposed scheme
5-6 Winner Selection Phase When game is over, automatically selected
6-6 Claming of Winning
SP
B
)(,,,#
)(),,,(,#
'),,,()1
ListDSListlWinningPooSeq
PayDSPaykjSeq
iswinnerwprizePayLBIjListgenerate
SP
SPP
PP
kmP
i
wi
i
accountsPlayertowinnigdepositcorrectif
ListfromPayLBISeqHashHsjcompare
redemptionPay
ii
PkmPP
',
)||||#('?
19
5. 5. Proposed schemeProposed scheme
Communication
BP
SP
depositPayPRE :
generationPayCert,
Betting
replyandrequestPaymentPOST :
20
6. 6. Evaluation 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
21
7. Comparison7. Comparison
KMHN00 Proposed
General
Type Multiple choice Multiple choice
# of Components 4 3
Winning Payment Off-line On-line
# of Communications(I : Interactive, O: One-way)
(2I + 1O) * N + 1I + 1O +
1I (Off/Post) + (inquiry)2I*N + 1O (Pre) + 1I
(Post)
Security
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
StorageLottery provider (2Hash + LBI + SID) * N
(1Hash + LBI + Index)*N + (Hash chain)
Bank 1H + LBI of Winners 1H + Index
22
8. Conclusion8. 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
23
ReferencesReferences
[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.
