Secure and Practical lottery protocol

1. ICE 615 Network Security Term project Progressive Report Secure and Practical lottery protocol Sep. 13, 2001 2001140 C&IS lab. Ham Woo Seok tarzan92@icu.ac.kr

2. Contents • Overview • Threats • Requirement • Pervious Work – KMHN00,GS98 • Proposed scheme • Further Works • Reference

3. Overview • Sports TOTO • Nationwide issue of tickets was launched Oct. 6 • England (Football Pools,1923), France (Loto Foot), Italia (TotoCalcio, TotoGoal), Japan(TOTO) etc.

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 • 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 • Anyone can detect injustice of lottery components • R5: Integrity • Lottery ticket cannot tampered • R6: Timeliness • A lottery should be terminated in the pre-defined period

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

7. TLP h2 h1 SID 4. Previous Work – KMHN00 • Lottery Protocol Promoter Soccer Lottery Protocol User Shop User Shop Payment Protocol (Off-line)

8. 4. Previous Work – KMHN00 • Details • Purchase protocol • 1) User computes hash value h1 with the concatenation of hashed PID and 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 as well • 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: protect 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 • 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 the 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

9. 4. Previous Work – KMHN00 • Problems • Prize-payment by off-line • In case of small prize, User feel inconvenience • PID can not be secret information • Even though using a random number with original PID, assumed that there are a number of winners, we can get more probability of hash collision • 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 • Collusion of Promoter and Shop might be occurred to get manipulate total lottery number and information

10. 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 • : Keyed one way hash function • : 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

11. 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 • 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 • Critical Purchase period • It is published before a lottery game • Delaying function cannot yield result within this period • Winning Entry Calculation Client Server Winning Number All seed values within P

12. 4. Previous Work – GS98 • 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

13. 5. Proposed scheme (tentative) • Notation

14. 5. Proposed scheme (tentative) LO U B

15. 5. Proposed scheme (tentative) • 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 in every components • Some details • Additional Information is depend on Bank’s requirement with which Bank can identify User • Payment is only paid when HU & Coupon are harmonized with stored data • Winning prize is given the account comes from secret sharing computation • Properties • User can trace all processes • Every process is handled in on-line • Amount of Communication data is low • It doesn’t need additional inquiry protocol • User can naturally check through his bank note • Requirement R1 is strongly guaranteed • The other requirements are efficiently satisfied

16. 6. Further Work • More communication data & computational complexity reduction • How to prevent Integrity of Message during transferring • Public key cryptosystem is necessary? • How to detect the total sold ticket number cheating by LO • Secret sharing is needed? Other methods? • Comparison with previous scheme

17. 7. Reference • Tigerpools Korea, http://www.tigerpools.co.kr • Korea online lottery system co.ltd., http://www.korealotto.co.kr • 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. • D.M.goldschlag, S.G.Stubblebine, Publicly Verifiable Lotteries: Applications of Delaying Functions, Proc.of Financial Cryptography 98, LNCS 1465, pp.214-226, 1998. • Ross Anderson, How to cheat at the lottery, Proc. of Computer Security Applications Conference, 1999. • Ronal L.Rivest, Electronic Lottery Tickets as Micropayments, Proc.of Financial Cryptography 97, LNCS 1318, pp.307-314, 1998. • A.Shamir, How to share a secret, CACM 22, pp.612-613, 1979.