1 / 25

Outline

An Efficient and Secure Event Signature (EASES) Protocol for Peer-to-Peer Massively Multiplayer Online Games Mo-Che Chan, Shun-Yun Hu and Jehn-Ruey Jiang Adaptive Computing and Networking Lab. National Central University. Outline. Background Related work NEO SEA The proposed scheme EASES

marjean
Télécharger la présentation

Outline

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Efficient and Secure Event Signature (EASES) Protocol for Peer-to-Peer Massively Multiplayer Online GamesMo-Che Chan, Shun-Yun Hu and Jehn-Ruey JiangAdaptive Computing and Networking Lab.National Central University

  2. Outline • Background • Related work • NEO • SEA • The proposed scheme • EASES • Evaluation • Conclusion

  3. Background - MMOG • Multiplayer online game • Massively multiplayer online game (MMOG)

  4. Background - architectures • Client-server

  5. Background - architectures • Server-cluster

  6. Background - architectures • Peer-to-peer (P2P) network • Efficiently maintain the topology • Virtual environment

  7. Background – game logic • In client-server and server-cluster • Server maintains game states • Users send event to server • Server sends information to player round time 7

  8. Background – cheat problem • Game logic is maintained by peers in P2P environments. • Some players may gain advantages unfairly.

  9. Background - commitment • Play the paper, scissors, rock game remotely without arbiter

  10. Background – hash function • Cryptographic hash function • Strength depends on the following infeasibilities • For any given hashed value, to find M or M’ • For any given message M, to find H(M) = H(M’) • To find any pair (M, M’) such that H(M) = H(M’) Hash function 010101110100

  11. Background - commitment • No one can get unfair advantages if the hash function is secure. H(Choice | Random) H(Choice | Random) Choice | Random Choice | Random First send H(Choice | Random) Then send (Choice | Random)

  12. Background – digital signature • Concept 010101000111010011001011 010011100110101000110101 011010111000110101010100 110100011010101010101001 010101010010101010101010 …….. 101001110100110010110110 101100110101000110101010 010111001011010101010011 010010110101010101010010 110110010101010101010111 …….. Signature algorithm A document To sign it A digital signature • No one can forge • Signer can’t repudiate that he executed the algorithm for this document • Authenticity of the document

  13. Background – digital signature • To sign a message To sign by sender’s private key Hash function message 0101…101 1011…110 message 1011…110

  14. Background – digital signature • To verify a signature message 1011…110 To inverse the signature by signer’s public key Hash function ? 0101…101 0101…101 To check they are the same or not

  15. Related work - NEO • Every updating message • Signing event updating message • Encrypting the signed message • After, send decrypting key Player i

  16. Related work - SEA • Every updating message • Signed hash value of event updating message • After, send the plain message Player i

  17. The problem that we observed • Digital signature algorithms are too slow. To sign the message digest Single Document Hash algorithm Signature algorithm To produce the message digest Original message Signature

  18. The objective • To efficiently sign many discrete messages Message 1 Message 2 …… Message n

  19. The proposed EASES • Initialization phase • Every player prepares the keys for signing. • Signing phase • Every player signs his messages. • Verification phase • Every receiver verifies the authenticity. • Re-initialization phase • Re-generate new signing keys.

  20. EASES – initialization phase …….. 1011…110

  21. EASES – signing & verification ……. Send out j-2 j-1 j j j+2 j+1 j-1 j j-2 j-3 j-2 j-1 ……. j j+1 j+2 j-3 j-2 j-1

  22. EASES – re-initialization phase • Re-execute initialization phase • A more efficient way • Reserve the last two keys …….. …….. 1011…110

  23. Evaluation - performance • Computational cost • Hash replaces signature function • Memory consumption • 1,000 * 192 bits = 24,000 bytes, when n = 1,000 • Bandwidth consumption • Length of Hash value is short than signature’s

  24. Evaluation - security • Unforgeability • No one can claim that he signed M, unless he show the OSK of M. • This requirement is secure if adopted cryptographic hash function is secure. • Verifiability • Hash function is public.

  25. Conclusion and discussion • EASES is proposed to sign many discrete messages at once efficiently • Security of EASES is as strong as those of traditional signature schemes • ESAES implies the commitment property

More Related