- Email: [email protected]
An efficient and secure event signature (EASES) protocol for peer-to-peer massively multiplayer online games
Computer Networks 52 (2008) 1838–1845
Contents lists available at ScienceDirect
Computer Networks journal homepage: www.elsevier.com/locate/comnet
An efficient and secure event signature (EASES) protocol for peer-to-peer massively multiplayer online games q Mo-Che Chan, Shun-Yun Hu, Jehn-Ruey Jiang * National Central University, Department of Computer Science and Information Engineering, No. 300, Jhongda Road, Chung-Li, Taiwan 32054, Taiwan, ROC
a r t i c l e
i n f o
Article history: Received 20 November 2007 Received in revised form 8 March 2008 Accepted 10 March 2008 Available online 18 March 2008 Responsible Editor: E. Ekici Keywords: MMOG Cheat-proof Peer-to-peer Hash-chain One-time signature
a b s t r a c t In recent years, massively multiplayer online games (MMOGs) have become very popular by providing more entertainment and sociability than single-player games. In order to prevent cheaters to gain unfair advantages in peer-to-peer (P2P)-based MMOGs, several cheatproof schemes have been proposed by using digital signatures. However, digital signatures generally require a large amount of computations and thus may not be practical for interactive real-time applications such as games. Based on the concept of one-time signature, we propose an efficient and secure event signature (EASES) protocol to efficiently sign discrete event messages with hash-chain keys. As most messages need only two hash operations to achieve non-repudiation and event commitment, usage of digital signatures is greatly reduced. We also describe a dynamic version of EASES that does not require the pre-production of hash-chain keys to reduce key preparation time and memory usage at the expense of a slight delay of message commitment. As shown by both analysis and experiments, the computation, memory, and bandwidth footprints of EASES are low, making it readily applicable to P2P-based MMOGs. Ó 2008 Elsevier B.V. All rights reserved.
1. Introduction Multiplayer online games are a rapidly growing segment of Internet applications in recent years. By providing more entertainment and sociability than single-player games, it is fast becoming a major form of digital entertainment. Earlier multiplayer games adopt client–server architectures where all players connect with the server to send and receive event updates. As it is hard for a single server to support a large number of concurrent players, server clusters were introduced later to enable massively multiplayer online games (MMOGs) where concurrent users may reach into the range of hundreds of thousands [1]. However, even if
q
This research was supported in part by the National Science Council (NSC) of the Republic of China (Taiwan) under the Grant NSC95-2221-E008-048-MY3. * Corresponding author. Tel.: +886 3 5426959. E-mail address: [email protected] (J.-R. Jiang). URL: http://www.csie.ncu.edu.tw/textsuperscript~jrjiang/ (J.-R. Jiang).
1389-1286/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2008.03.004
a server cluster provides better scalability than a single server, it still has limited scalability due to limited resources such as CPU and bandwidth at a given time. A number of recent peer-to-peer (P2P) virtual environment (VE) [2–9] research thus seek to further improve the scalability of existing MMOGs by utilizing the resources of participating player nodes (i.e., peers), and distributing the workload to all player nodes. Unlike earlier fully connected P2P systems where the number of connections grows quadratically with the number of players, these recent scalable P2P VEs provide better scalability by allowing players to exchange messages with only the neighboring players within their visibility range. Although P2P-based MMOGs may provide better scalability, by distributing server-side workload to clients, new issues such as maintaining consistency and ensuring fairness arise [2,10,11]. In server-based MMOGs, game states (e.g., user statuses, experience points, equipments, world items) are maintained and updated via game logic (i.e., game rules) executions on trusted servers. When a player
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
performs an action such as running, shooting, turning, etc., an event message is sent to the server, which subsequently processes the events and updates the game states. The server then periodically sends state updates to the affected players to synchronize their local copies of the game states with the server’s. Under such processing model, the server maintains all the information to ensure a global ordering for event executions and fair gameplay. However, when we turn to a P2P approach, game state maintenance and game logic execution could be distributed to individual players, creating opportunities for players to cheat. Cheating gives a player various advantages in multiplayer games. It is especially attractive as gaining valuable items or winning over others is central to the MMOG gameplay. Valuable virtual items can even be sold in exchange for real-world money, which increases the motivations to cheat. Cheat-prevention thus is a serious issue to game designers. Games may adopt cryptographic techniques to prevent cheating by concealing a player’s actions from others before submitting the final decisions [10]. In such countermeasures, a secure event update protocol is often used, and includes: 1. a commitment scheme to ensure that players do not change their actions after decisions are made and 2. a digital signature scheme to ensure that players cannot deny the actions they have done. If the commitments are digitally signed, we can also prevent impersonation and dodging [12,13]. Commitment and digital signatures together thus provide a fair environment for games even when players do not trust each other [12,13]. However, public-key cryptography has some time-consuming exponential operations when signing signatures, so a large amount of computation is required to sign and verify all event updates. We begin this research by considering the question: can the authentication and non-repudiation properties of digital signatures still be achieved, without incurring the heavy costs of signing messages continuously? In existing cryptography schemes, when a large document needs to be signed, a hash function can be used to reduce the computations. The document is first hashed into a much smaller digest, which is then signed to be a digital signature. The digest can be used to characterize the original document. As it is very hard to find another document that can produce the same digest, signing the digest can be seen as signing the original document. By using a digest, the computation time to sign a document can be greatly reduced. Unforgeability and verifiability are the two requirements for digital signatures that currently can only be achieved via public-key cryptography; together they provide the non-repudiation (i.e., undeniableness of user actions) of the signature. Two event update protocols [11,14] have been proposed to use digital signatures to sign every event update to avoid cheating in P2P-based MMOGs. However, both protocols may not be practical due to the excessive use of public-key cryptographic signatures. As shown in [15], digital signatures consume much more computation than hash functions and symmetric encryptions. Since the use of digital signatures is unavoidable to prevent users from denying their behaviors, our main concern is thus how to use digital signature only minimally while achieving the same cheat-proof properties. We
1839
propose an efficient and secure event signature (EASES) protocol to efficiently sign a sequence of event updates by using the hash-chain keys based on the concept of one-time signatures [16]. We further describe a dynamic version of EASES that does not require the pre-production of hashchain keys to reduce key preparation time and memory usage at the expense of an extra one-round delay of message commitment. We perform measurement experiments for EASES and compare the experimental results with those of existing digital signature-based approaches. As we will show, EASES has low computation and bandwidth costs, and is thus applicable to P2P-based MMOGs. In the following sections, we first review related work for cheat-proof mechanisms in Section 2 and present a message signing model in Section 3. We propose the EASES protocol in Section 4, and extend it to a dynamic version where the production of signature keys can be done dynamically in Section 5. We evaluate the security and performance of EASES in Section 6 and conclude the paper in Section 7.
2. Related work Several papers have investigated the types of cheats and security requirements of multiplayer games. Kirmse and Kirmse [17] present the security goals for online games in respect to the protection of sensitive information and the provision of fair play. Dickey et al. [11] shows that several types of cheats may occur when honest players’ actions are known in advance by cheaters, who can then respond unfairly to their advantages. Smed [18] describe considerations in multiplayer games such as the network resources, communication architectures, scalability and security. Yan [19] demonstrates several security requirements for online games via a simple client–server bridge game. Besides the above work, several cheat-proof mechanisms have also been proposed. Baughman and Levine [10] present the ‘‘lockstep” mechanism to solve the cheating problem. Based on the concept of bucket synchronization [20,21], their mechanism divides a game session into ‘‘time buckets” (i.e., time intervals, or ‘‘rounds”) for game state synchronization. In each round, a player first sends a cryptographically secure one-way hash value of its state update as a commitment, and then sends the plaintext update to reveal the commitment in the next round. This prevents any player from knowing other players’ actions ahead of time. Cronin et al. [22] further improve the performance of lockstep with ‘‘sliding pipeline” by sending out several updates in advance without waiting for acknowledgements from other players. GauthierDickey et al. propose the new event ordering (NEO) protocol [11] to improve the work of Baughman and Levine [10] and Cronin et al. [22]. NEO claims to prevent common protocol-level cheats with low latency. However, Corman et al. [14] later show that NEO cannot prevent all cheats as claimed, and present an improvement called secure event agreement (SEA) as a remedy. Since our work is mostly inspired by NEO and SEA, we detail the two protocols below.
1840
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
2.1. Description of NEO GauthierDickey et al. propose NEO to prevent cheating by digital signatures and a voting mechanism to compensate for packet loss [11]. NEO divides the time into fixedlength rounds, and every player sends an event update message in each round. The event update of NEO is described in formula (1), where U rA is the update from player A for round r, SA ð Þ is the signature function, f gK r represents A an encryption, K Ar1 is A’s key for the update from round r1 r 1, and V A is a bit vector for voting. The voting is used to form a consensus on whether a given player has sent an update within a round, in order to determine if that update should be accepted. When each player acts, an event update is first signed and encrypted before sending to other players. The event update and its signature are encrypted together as a commitment, which is revealed in the next round when the player sends the associated key. Players are obliged not to modify their actions after the commitments are sent (i.e., when they might have learned about others’ actions), as other players can verify an action by the associated commitment sent in the previous round. M rA ¼ fSA ðU rA ÞgK r ; A
K Ar1 ;
SA ðV Ar1 Þ:
ð1Þ
2.2. Description of SEA However, Corman et al. [14] show that NEO has some drawbacks (e.g., an attacker can replay updates for another player, or send different updates to different players) and thus propose the SEA protocol as an improvement. The event update message of SEA is described in formula (2), where H( ) is a hash function, U rA is the update from player A for round r, nr is a random value for round r, SessID is the session ID to prevent players from replaying this message in a different session, IDA is the unique identity of player r1 A, and VhA is the votes of updates received by player A in round r 1 that includes a hash of the updates (
r
CommitA ¼ HðU rA ; nr ; SessID; IDA Þ; r
r1
MrA ¼ SA ðCommitA ; U Ar1 ; VhA ; nr1 ; rÞ:
ð2Þ
Signing the entire message is used to authenticate the message creator, and the hash serves as the commitment of the update sent in the next round. In order to achieve better performance and avoid potential issues with key tampering and selection, the SEA protocol replaces encryption with a cryptographic hash function as the commitment method. When the commitment is done by encryption, the distribution, protection and selection of keys must be carefully considered, or problems would arise from poorly designed key management schemes. However, if the commitment is made via hash functions, the above key-related issues can be avoided. 3. Message signing model As public-key cryptosystem requires a large amount of computations. To improve the efficiency, we compute a message’s digest by a hash function before signing the
message. The information used in a digest signature protocol is described in the following equation: 8 the full message; > : Ssk ðHðMÞÞ the signature of the message digest: Although the digest signature protocol is efficient for signing one message, it cannot efficiently sign many discrete messages across different time periods (i.e., rounds) as required in a game scenario. We therefore need an efficient signature protocol usable under such an environment. The information used in the signature protocol is described in formula (4). The signature of each discrete message should be efficient to compute, capable to authenticate the message creator, and usable as a commitment for the next message. The protocol should also adapt to different networks such as fully connected or scalable P2P topologies, where the player can join and leave at any time. In the following section, we propose the EASES protocol to fulfill these requirements. 8 1 M ; . . . ; Mn the discrete messages > > > > > of rounds 1; . . . ; n; > < the digests of M1 ; . . . ; Mn ; HðM1 Þ; . . . ; HðMn Þ > > > > S1 ðHðM1 ÞÞ; . . . ; Sn ðHðMn ÞÞ the signatures of > > : message digests: ð4Þ 4. The EASES protocol EASES is based on the concept of one-time signature [16] that generates a series of hash-chain keys to achieve the same effects as the regular digest signature schemes. In a game scenario with n rounds and n signatures, only the first signature needs to be based on public-key cryptography (i.e., signed by the secret key), while others are based on the relationship between the hash-chain keys (i.e., signed by one-time signature keys). The computational cost is thus reduced dramatically. EASES has four phases: 1. every player generates a series of keys for signing event updates in the initialization phase after connection establishment; 2. every player signs his/ her event update in the signing phase; 3. after the event updates from other players are received, each player can verify these event updates in the verification phase; and 4. in the re-initialization phase, players can re-generate new signature keys when the keys have been used up. Relevant notations for the rest of our discussions are listed in Table 1. Table 1 Notations player i HðxÞ K ri Ssk ðxÞ U ri xjy x9y dri Di
The ith player in the game Hash operator with input message x One-time signature key of player i in the rth round A message x signed by secret key sk An event update of player i in the rth round Concatenation of message x and y To check if x equals to y Signature signed by player i ’s rth one-time signature key Signature signed by player i ’s secret key sk
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
4.1. Initialization phase Before starting the game, each player must first generate a series of one-time signature keys. The following key generation operation can be done before a user logins the game, or before the first event update is sent. 1. Each playeri first picks an unpredictable random number as the master key MK i to compute a series of n one-time signature keys, where n is a system parameter that specifies the maximum number of updates (i.e., rounds) in a session. Choosing larger n increases the costs to compute and store the keys, but may save computing time during the later update stage. 2. We begin the key generation with the last key, so the nth one-time signature key is computed by K ni ¼ HðMK i Þ. And for the other rth round, where r ¼ ðn 1Þ; . . . ; 0, the signature key is computed by K r1 ¼ HðK ri Þ. i After these one-time signature keys (i.e., a hash-chain keys) are generated, player i signs the first one-time signature key by its secret key to get the signature Di ¼ Ssk ðK 0i Þ. Note that keys are used in the reverse order of their production (i.e., the last key produced is the first key used in the game session and needs to be signed). See Fig. 1 for a schematic of the key production. 4.2. Signing phase In the rth round, playeri computes the signature of the event updates dri ¼ HðK ri jU ri Þ, where U ri is player i ’s rth event update. Playeri then sends the signature dri , the previous event update U r1 and its associated key K ir1 to other playi ers. The below equation shows the message sent by player i ( d1i ¼ HðK 1i jU 1i Þ; Di ; K 0i in the first round; dri ¼ HðK ri jU ri Þ; U ir1 ; K r1 i
in the subsequent rth round: ð5Þ
For instance, playeri sends out the message d1i ¼ HðK 1i jU 1i Þ; Di ; K 0i in the first round. In the second round, player i sends out d2i ¼ HðK 2i jU 2i Þ; U 1i ; K 1i . In a subsequent rth round, player i sends out dri ¼ HðK ri jU ri Þ; U ir1 , and K r1 . i 4.3. Verification phase On receiving messages from player i , each player verify the messages as follows:
1841
1. In the first round, each player receiving d1i ¼ HðK 1i jU 1i Þ; Di ; K 0i , verifies Di with player i ’s public-key and K 0i to see if the key K 0i is legitimate. 2. In the rth round, r ¼ 2; . . . ; n, each player receiving dri ; U ir1 ; K r1 verifies: i (a) K ir2 9HðK ir1 Þ to see if the signature key K ir1 is authentic (i.e., the signature key K ir2 was generated from K ir1 ). (b) dir1 9HðK r1 jU ir1 Þ to see if the update has been i tampered.
For example, in the second round, a player should verify K 0i 9HðK 1i Þ as well as d1i 9HðK 1i jU 1i Þ for player i . If the verification passes, then a player can be sure that the update is from player i and is not tampered. 4.4. Re-initialization phase The signature keys have to be re-generated when they are depleted for a session. One basic method is for players to start over from the initialization phase to generate and use new signature keys. However, a more efficient way is for playeri to perform the following actions in the nth and ðn þ 1Þth round. 1. In the nth round, playeri generates a series of new onetime signature keys NewK 0i ; . . . ; NewK ni with a new random number (i.e., a master key NewMK i ). In practice, player i can generate the keys in advance to avoid sudden computing load. Playeri signs (hashes) the new signature key NewK 0i with the key K ni to have dni ¼ HðK ni jU ni jNewK 0i Þ. Playeri then sends dni ; U n1 ; K n1 i to other players as usual. 2. In the ðn þ 1Þth round, playeri sends dnþ1 ¼ HðNewK 1i jU nþ1 Þ; U n ; K ni and NewK 0i to other i i players. 3. In the ðn þ 2Þth round, in addition to the regular message, playeri should also send the old master key MK i (i.e., the pre-image of K ni ). Besides the regular verifications, the receivers now should perform the following additional verifications. 1. On receiving dnþ1 ; U n ; K ni in the ðn þ 1Þth round, the i receiver should verify dni 9HðK ni jU ni jNewK 0i Þ to check the authenticity of NewK 0i . 2. In the ðn þ 2Þth round, the receiver should also verify K ni 9HðMK i Þ. If the above verifications pass, NewK 0i is authenticated to be sent by player i and the series of new keys NewK 0i ; . . . ; NewK ni can be used after the ðn þ 2Þth round according to the normal procedures. 4.5. Late joining
Fig. 1. Production rule for the one-time signature keys.
If the set of receivers is fixed during a game session, then player i only needs a single set of keys to sign updates. On the other hand, player i may need separate sets of keys for each player j if we allow a new players to join an on-going session.
1842
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
However, the cost to maintain separate key sets can be high. Below, we show two alternatives for player j to authenticate the key K ri when it joins an on-going session in the rth round without keeping separate key sets. 1. Re-send previous signature keys. Playeri sends Di ð¼ Ssk ðK 0i ÞÞ; K 0i ; . . . ; K ir1 to playerj along with dri ¼ HðK ri jU ri Þ. This is for player j to verify that K 0i ; . . . ; K ir1 is generated by player i . Player j can then authenticate K ri when it is sent in the ðr þ 1Þth round by checking K ir1 9HðK ri Þ. Playerj can also check dri 9HðK ri jU ri Þ to see if U ri sent in the ðr þ 1Þth round is tampered or not. 2. Encrypt last signature key. Playeri signs the key K ir1 by its secret key sk and sends the key K ir1 and the signature Ssk ðK r1 Þ along with dri ¼ HðK ri jU ri Þ. The signature i r1 Ssk ðK i Þ is for player j to authenticate K r1 . Again, i playerj can then check if K ri and U ri are correct in the next round given that K ir1 is already authenticated. 5. Dynamic EASES Dynamic EASES extends the ‘‘authentication via hashing” idea of the basic EASES but avoids the pre-generation of hash-chain keys. This helps to reduce memory usage. We achieve this by signing the messages without first preparing a series of hash-chain keys. The key point is to defer the revelation of committing key for two rounds. An adversary cannot intrude since he gets no knowledge about the committing key. As it is not necessary to initialize or re-initialize the hash-chain in the dynamic version, there are only two phases: signing and verification. 5.1. Signing phase When player i has to sign an update message U ri for playerj in round r, there are three cases to consider: 1. In the first round, player i picks an unpredictable random value K 1i , computes HðU 1i jK 1i Þ, and sends out the signed hash value Ssk ðHðU 1i jK 1i ÞÞ. 2. In the second round, playeri picks an unpredictable random value K 2i , computes HðU 2i jK 2i jK 1i Þ, and then sends out the signed hash value Ssk ðHðU 2i jK 2i jK 1i ÞÞ. 3. In subsequent rounds, player i generates an unpredictable random value K ri , computes HðU ri jK ri jK ir1 Þ and sends HðU ri jK ri jK ir1 Þ, K ir2 , U ir2 . The playeri ’s out-going messages are summarized in the following equation: 8 1 1 > in the first round; < Ssk ðHðU i jK i ÞÞ > :
Ssk ðHðU 2i jK 2i jK 1i ÞÞ
in the second round;
HðU ri jK ri jK ir1 Þ; K ir2 ; U ir2
in the subsequent rth round: ð6Þ
5.2. Verification phase Playerj performs the following actions to verify the authenticity of the received messages from player i . There are three cases to verify:
Fig. 2. Message signing structure of dynamic EASES.
1. In the first round, player j verifies the signature Ssk ðHðU 1i jK 1i ÞÞ by playeri ’s public-key and then keeps HðU 1i jK 1i Þ in the memory. 2. In the second round, playerj verifies the signature Ssk ðHðU 2i jK 2i jK 1i ÞÞ by player i ’s public-key and then keeps HðU 2i jK 2i jK 1i Þ in the memory. 3. In subsequent rounds, player j can reveal the commitment and check the authenticity of the messages received in the previous two rounds. In other words, the authenticity of U ir2 is checked in the rth round. To verify K ir2 ; U ir2 for the ðr 2Þth round, player j simply computes HðU ir2 jK ir2 jK r1 Þ. Note that in the 3rd i round, only HðU 1i jK 1i Þ (i.e., the signature obtained in the 1st round) needs to be computed. The full message exchange in dynamic EASES is shown in Fig. 2. Similar to the basic EASES, the player can ensure that the messages from previous rounds are correct by verifying the messages with hashing. The major difference between the dynamic and the basic EASES are: 1. Dynamic EASES needs two digital signature operations when initializing a new game session. 2. Hash-chain generation is no longer necessary in the dynamic version. 3. Dynamic EASES requires one more round than the basic EASES to reveal the plaintext of a message. For example, in the basic EASES, the receiver reveals the commitment of dri and confirms the authenticity of K ri by deciding whether K ir1 9HðK ri Þ after receiving U ri and K ri in the rth round. But in dynamic EASES, the player ensures that the message of the ðr 2Þth round is correct by verifying the message received in the rth round. 6. Evaluation 6.1. Applicability EASES can be used to sign many discrete messages efficiently and is suitable for both fully connected and scalable P2P topologies. In the former, player i sends the messages to all other players. In the latter, player i sends the messages to all players within its visibility range (often called area of interest or AOI). The concepts of EASES can be easily applied to NEO and SEA, and also to the sliding pipeline protocol [22] by utilizing multiple series of hash-chain keys. To prevent other attacks such as eavesdropping with network sniffers, authenticated key exchange protocol [23] can be used to encrypt data between two communication parties. Adding a counter to the message before encryption can also prevent modification and fabrication attacks. Besides, voting mechanism can be used to prevent an
1843
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
attacker from sending different updates to different players [14]. However, those topics are beyond our current scope. 6.2. Security analysis EASES supports message non-repudiation via commitments. The event update U ri is committed by K ri at round r and revealed in the next round. This property is based on EASES’ support of the two fundamental requirements for digital signatures: unforgeability and verifiability. Unforgeability means that no one can generate a legal signature for a specific message except the signer. Only the signer keeps the correct private key for generating a legal signature verifiable by the corresponding public-key. Verifiability means that everyone can verify whether a digital signature is legal. Below, we analyze EASES according to these two requirements. Unforgeability: In EASES, one cannot claim to have signed U ri and produced the signature dri unless K ri is presented. However, no one can show the signing key K ri for the current update U ri before the original signer reveals it. The cryptographic hash used by EASES also has the following secure properties: for any given hashed value, it is computationally infeasible to find its pre-image due to the one-way property of hash functions (i.e., for any given message x, it is computationally infeasible to find another message x0 such that HðxÞ ¼ Hðx0 Þ). Moreover, strong collision resistance exists in some hash functions, meaning that it is computationally infeasible to find any pair of ðx; yÞ such that HðxÞ ¼ HðyÞ, where x 6¼ y. EASES is unforgeable since it adopts a secure hash function that has the above properties. With unforgeability, non-repudiation can be achieved in EASES. Verifiability: Cryptographic hash function is a public standard that can be installed and executed on every player’s computer, so everyone can re-compute the hash value of a given signature key K ri and message U ri to verify if it equals the previously received signature by checking dri 9HðK ri jU ri Þ. Dynamic EASES: Both the basic and the dynamic version of EASES maintain their security under ‘‘lockstep” game environment (i.e., the players will only advance game rounds together, making the adversary unable to gain advantages via uneven information across rounds). We can especially appreciate this property by observing the dynamic version. In dynamic EASES, the first and the second messages can be undoubtedly authenticated by the sender’s public-key. In the third round, the player receives HðU 3i jK 3i jK 2i Þ; K 1i ; U ri , so the adversary must know K 2i in order to replace U 3i jK 3i and forge messages afterwards. However, K 2i will only be revealed in the fourth round. For example, the message U 3i whose commitment was received in the third round can be revealed and confirmed, when its committing keys K 2i and K 3i are received in the fourth and fifth round. K 2i cannot be forged because all K 2i keys that appear in rounds 2, 3 and 4 can be compared. Likewise, K 3i cannot be forged because all K 3i keys in rounds 3, 4 and 5 can be compared. The authenticity of message U 3i is thus ensured as K 2i ; K 3i are verifiable in the fourth and the fifth rounds.
6.3. Performance analysis and comparisons Computation cost: The major benefit of EASES is computational efficiency. There is at least one signature operation and one verification operation for each event update in the schemes such as NEO and SEA. In comparison, there are only two hash operations for each event update in EASES and one traditional signature operation during the initialization phase in EASES. The approximate CPU cycles for some cryptographic functions are listed in Table 2. Memory consumption: EASES requires a player to prepare a block of memory to store the list of one-time signature keys. The exact memory size depends on the hash value length and the chosen round size n. For example, if MD-5 is used and n ¼ 1000, then each player will need 1000 128 = 128,000 bits = 16,000 bytes of memory to store the one-time signature keys. Bandwidth consumption: Except for the first update, EASES needs to transfer the one-time signature for every event update, with the size of a hash value. This is much shorter than the size of traditional digital signatures. For example, SHA-1 uses 192 bits for each hash value, whereas 1024-RSA uses 1024 bits for each signature. EASES thus only needs a size about twice the hash value. We briefly compare EASES with NEO [11] and SEA [14], both of which adopt traditional digital signatures to sign updates in every round (see Table 3). NEO uses two signature operations, and SEA uses one. EASES replaces the signature by hash operations. NEO and SEA need one signature operation in each round. EASES needs one signature operation only for initialization of the one-time signature keys, and only hash operations are used afterwards. 6.4. Experimental results We perform simulation experiments on an Intel Pentium-4 3.4 GHz PC for evaluating the performances of the two versions of EASES and the digital signature-based
Table 2 Approximate CPU cycles for some cryptographic functions [14,15] Primitive type
Example
Clock cycles
Hash function Symmetric encryption Digital signature
SHA-1 AES RSA-PSS
15/byte +1040 25/byte +504 42,000,000
Table 3 The comparisons of NEO, SEA and EASES
NEO SEA Basic EASES Dynamic EASES
Message sizea
Memory space
Computation cost
1 ds + 1 en + 1 dk 1 ds 2 hashes
None
1 ds + 1 en
None n hash-chain keys None
1 ds + 1 hash 2 hashes
2 hashes
1 hash
ds: digital signature; en: encryption; and dk: decrypting key. a The actual game update message is excluded.
1844
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
schemes, which NEO and SEA rely on. We are mainly interested in the time required to commit event messages. We assume that the popular RSA OAEP (optimal asymmetric encryption padding) [24] signature protocol is adopted by NEO and SEA, and adopt the functions from the Crypto++ library [25] for RSA OAEP signing and verification in our evaluation. The hash algorithm SHA1 is used for EASES. We assume that the event update length is 70 bytes. The length of RSA key is 1024 bits. The number of game rounds are fixed at 1000. Both the scenarios where the number of concurrent players n changes and the new player arrival rate changes are evaluated, respectively. Fig. 3 shows the total CPU time spent by each player’s personal computer in 1000 rounds. In each round, one signing and n verifications are invoked for each participating player. The resulting growth in computing time is expected since CPU load grows heavier with more concurrent players. Even though Crypto++ uses low exponential public-key as default to help accelerate multiple verifications in a general signature protocol, EASES still performs better. Consider that new players join and depart constantly in a dynamic game environment, since authentication is not necessary for the departing player, the cost is caused mainly by player joining. There are about 500 to 4500 new players joining in realistic online games [26]. If each round is for one second, we can estimate that there are about 132–1245 new players joining the game in 1000 rounds. Simulation results on new player arrivals is presented in Fig. 4. We fix the total number of players at 100, and then measure how the arrival rate impacts the
Fig. 3. CPU time usage of RSA OAEP and EASES for each player in 1000 rounds.
Fig. 4. Effect of new player arrivals.
performance of EASES. From the figure, we can see that EASES still has better overall performance. 7. Conclusion In this paper, an efficient and secure event signature (EASES) protocol for P2P-based MMOGs is proposed. EASES supports the commitment property of digital signatures by using hash functions, and we show that it has the nonrepudiation property by possessing unforgeability and verifiability as traditional digital signatures do. Unlike existing schemes such as NEO and SEA that use digital signatures in every round of a game session, EASES uses a digital signature only during initialization and uses hash-chain keys in all subsequent rounds. To reduce memory usage, we also describe a dynamic version of EASES that removes the requirement of hash-chain key pre-production at the expense of an extra one-round delay of message commitment. As shown by analysis and measurement experiments, EASES thus requires much less computation and bandwidth than current signature protocols. The low resource requirement and adaptability to dynamically changing topologies make EASES quite applicable to P2Pbased MMOGs. References [1] B.S. Woodcock, An Analysis of MMOG Subscription Growth,, 2006. [2] B. Knutsson, H. Lu, W. Xu, B. Hopkins, Peer-to-peer support for massively multiplayer games, in: Proceedings of the IEEE Infocom, 2004. [3] C. GauthierDickey, V. Lo, D. Zappala, Using n-trees for scalable event ordering in peer-to-peer games, in: Proceedings of the International Workshop on Network and Operating Systems Support for Digital Audio and Video, ACM Press, New York, NY, USA, 2005, pp. 87–92. [4] J. Keller, G. Simon, Solipsis: a massively multi-participant virtual world, in: Proceedings of the PDPTA, 2003, pp. 262–268. [5] P. Morillo, W. Moncho, J.M. Orduna, J. Duato, Providing Full Awareness to Distributed Virtual Environments Based on Peer-ToPeer Architectures, vol.4035 (CGI’06), Springer LNCS, 2006, pp. 336– 347. [6] J. Lee, H. Lee, S. Ihm, T. Gim, J. Song, Apolo: ad-hoc peer-to-peer overlay network for massively multi-player online games, Tech. Rep., KAIST Technical Report, CS-TR-2005-248, December 2005. [7] S. Douglas, E. Tanin, A. Harwood, S. Karunasekera, Enabling massively multi-player online gaming applications on a p2p architecture, in: Proceedings of the IEEE International Conference on Information and Automation, 2005, pp. 7–12. [8] A. Bharambe, J. Pang, S. Seshan, Colyseus: a distributed architecture for multiplayer games, in: Proceedings of the ACM/USENIX NSDI, 2006. [9] S. Hu, J. Chen, T. Chen, VON: a scalable peer-to-peer network for virtual environments, IEEE Network 20 (4) (2006) 22–31. [10] N. Baughman, B. Levine, Cheat-proof playout for centralized and distributed online games, in: Proceedings of the IEEE Infocom, 2001. [11] C. Dickey, D. Zappala, V. Lo, J. Marr, Low latency and cheat-proof event ordering for peer-to-peer games, in: Proceedings of the ACM International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Kinsale, County Cork, Ireland, 2004, pp. 134–139. [12] M. Kamada, A fair dynamical game over networks, in: Proceedings of the 2004 International Conference on Cyberworlds (CW’04), 2004, pp. 141–146. [13] M. Kamada, K. Kurosawa, Y. Ohtaki, S. Okamoto, A network game based on fair random numbers, IEICE Transactions on Information and Systems 88 (5) (2005) 859–864. [14] A. Corman, S. Douglas, P. Schachte, V. Teague, A secure event agreement (SEA) protocol for peer-to-peer games, in: Proceedings of the First International Conference on Availability, Reliability and Security, 2006.
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845 [15] B. Preneel, B. Van Rompay, S. Ors, A. Biryukov, L. Granboulan, E. Dottax, M. Dichtl, M. Schafheutle, P. Serf, S. Pyka, Performance of Optimized Implementations of the NESSIE Primitives,. [26] D. Pittman, C. GauthierDickey, A measurement study of virtual populations in massively multiplayer online games, in: Proceedings of the 6th ACM SIGCOMM Workshop on Network and System Support for Games, 2007, pp. 25–30.
Mo-Che Chan is currently a Ph.D. student with the Department of Computer Science and Information Engineering at National Central University, Taiwan. His current research interests encompass distributed systems and network security.
1845
Shun-Yun Hu ([email protected]) is currently a Ph.D student at National Central University, Taiwan. He received his M.Eng. degree in computer science and information engineering from Tamkang University in 2005. His main research interests are networked virtual environments and peer-topeer systems. He has published in IEEE Network and IEEE INFOCOM, and was a co-organizer of the IEEE Virtual Reality workshop Massively Multiuser Virtual Environments (http://peers-at-play.org/MMVE08/). He has been inspired and fascinated by the possibilities of virtual worlds since first playing with computer games at the age of 7. He started the SourceForge project VAST (http://vast.sourceforge.net) in 2005 and ASCEND (http://ascend.sourceforge.net) in 2006, to provide open source libraries for creating scalable peer-to-peer-based virtual environments.
Jehn-Ruey Jiang received his Ph.D. degree in Computer Science in 1995 from National Tsing-Hua University, Taiwan, ROC. He joined Chung-Yuan Christian University as an Associate Professor in 1995. He joined HsuanChuang University in 1998 and became a full Professor in 2004. He is currently with the Department of Computer Science and Information Engineering, National Central University. He was a recipient of the Best Paper Award of the 32nd International Conference on Parallel Processing, 2003, and a recipient of Excellent Paper Award of Mobile Computing 2004. His research interests include distributed computing, mobile computing, pervasive computing and peer-to-peer computing.
Contents lists available at ScienceDirect
Computer Networks journal homepage: www.elsevier.com/locate/comnet
An efficient and secure event signature (EASES) protocol for peer-to-peer massively multiplayer online games q Mo-Che Chan, Shun-Yun Hu, Jehn-Ruey Jiang * National Central University, Department of Computer Science and Information Engineering, No. 300, Jhongda Road, Chung-Li, Taiwan 32054, Taiwan, ROC
a r t i c l e
i n f o
Article history: Received 20 November 2007 Received in revised form 8 March 2008 Accepted 10 March 2008 Available online 18 March 2008 Responsible Editor: E. Ekici Keywords: MMOG Cheat-proof Peer-to-peer Hash-chain One-time signature
a b s t r a c t In recent years, massively multiplayer online games (MMOGs) have become very popular by providing more entertainment and sociability than single-player games. In order to prevent cheaters to gain unfair advantages in peer-to-peer (P2P)-based MMOGs, several cheatproof schemes have been proposed by using digital signatures. However, digital signatures generally require a large amount of computations and thus may not be practical for interactive real-time applications such as games. Based on the concept of one-time signature, we propose an efficient and secure event signature (EASES) protocol to efficiently sign discrete event messages with hash-chain keys. As most messages need only two hash operations to achieve non-repudiation and event commitment, usage of digital signatures is greatly reduced. We also describe a dynamic version of EASES that does not require the pre-production of hash-chain keys to reduce key preparation time and memory usage at the expense of a slight delay of message commitment. As shown by both analysis and experiments, the computation, memory, and bandwidth footprints of EASES are low, making it readily applicable to P2P-based MMOGs. Ó 2008 Elsevier B.V. All rights reserved.
1. Introduction Multiplayer online games are a rapidly growing segment of Internet applications in recent years. By providing more entertainment and sociability than single-player games, it is fast becoming a major form of digital entertainment. Earlier multiplayer games adopt client–server architectures where all players connect with the server to send and receive event updates. As it is hard for a single server to support a large number of concurrent players, server clusters were introduced later to enable massively multiplayer online games (MMOGs) where concurrent users may reach into the range of hundreds of thousands [1]. However, even if
q
This research was supported in part by the National Science Council (NSC) of the Republic of China (Taiwan) under the Grant NSC95-2221-E008-048-MY3. * Corresponding author. Tel.: +886 3 5426959. E-mail address: [email protected] (J.-R. Jiang). URL: http://www.csie.ncu.edu.tw/textsuperscript~jrjiang/ (J.-R. Jiang).
1389-1286/$ - see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2008.03.004
a server cluster provides better scalability than a single server, it still has limited scalability due to limited resources such as CPU and bandwidth at a given time. A number of recent peer-to-peer (P2P) virtual environment (VE) [2–9] research thus seek to further improve the scalability of existing MMOGs by utilizing the resources of participating player nodes (i.e., peers), and distributing the workload to all player nodes. Unlike earlier fully connected P2P systems where the number of connections grows quadratically with the number of players, these recent scalable P2P VEs provide better scalability by allowing players to exchange messages with only the neighboring players within their visibility range. Although P2P-based MMOGs may provide better scalability, by distributing server-side workload to clients, new issues such as maintaining consistency and ensuring fairness arise [2,10,11]. In server-based MMOGs, game states (e.g., user statuses, experience points, equipments, world items) are maintained and updated via game logic (i.e., game rules) executions on trusted servers. When a player
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
performs an action such as running, shooting, turning, etc., an event message is sent to the server, which subsequently processes the events and updates the game states. The server then periodically sends state updates to the affected players to synchronize their local copies of the game states with the server’s. Under such processing model, the server maintains all the information to ensure a global ordering for event executions and fair gameplay. However, when we turn to a P2P approach, game state maintenance and game logic execution could be distributed to individual players, creating opportunities for players to cheat. Cheating gives a player various advantages in multiplayer games. It is especially attractive as gaining valuable items or winning over others is central to the MMOG gameplay. Valuable virtual items can even be sold in exchange for real-world money, which increases the motivations to cheat. Cheat-prevention thus is a serious issue to game designers. Games may adopt cryptographic techniques to prevent cheating by concealing a player’s actions from others before submitting the final decisions [10]. In such countermeasures, a secure event update protocol is often used, and includes: 1. a commitment scheme to ensure that players do not change their actions after decisions are made and 2. a digital signature scheme to ensure that players cannot deny the actions they have done. If the commitments are digitally signed, we can also prevent impersonation and dodging [12,13]. Commitment and digital signatures together thus provide a fair environment for games even when players do not trust each other [12,13]. However, public-key cryptography has some time-consuming exponential operations when signing signatures, so a large amount of computation is required to sign and verify all event updates. We begin this research by considering the question: can the authentication and non-repudiation properties of digital signatures still be achieved, without incurring the heavy costs of signing messages continuously? In existing cryptography schemes, when a large document needs to be signed, a hash function can be used to reduce the computations. The document is first hashed into a much smaller digest, which is then signed to be a digital signature. The digest can be used to characterize the original document. As it is very hard to find another document that can produce the same digest, signing the digest can be seen as signing the original document. By using a digest, the computation time to sign a document can be greatly reduced. Unforgeability and verifiability are the two requirements for digital signatures that currently can only be achieved via public-key cryptography; together they provide the non-repudiation (i.e., undeniableness of user actions) of the signature. Two event update protocols [11,14] have been proposed to use digital signatures to sign every event update to avoid cheating in P2P-based MMOGs. However, both protocols may not be practical due to the excessive use of public-key cryptographic signatures. As shown in [15], digital signatures consume much more computation than hash functions and symmetric encryptions. Since the use of digital signatures is unavoidable to prevent users from denying their behaviors, our main concern is thus how to use digital signature only minimally while achieving the same cheat-proof properties. We
1839
propose an efficient and secure event signature (EASES) protocol to efficiently sign a sequence of event updates by using the hash-chain keys based on the concept of one-time signatures [16]. We further describe a dynamic version of EASES that does not require the pre-production of hashchain keys to reduce key preparation time and memory usage at the expense of an extra one-round delay of message commitment. We perform measurement experiments for EASES and compare the experimental results with those of existing digital signature-based approaches. As we will show, EASES has low computation and bandwidth costs, and is thus applicable to P2P-based MMOGs. In the following sections, we first review related work for cheat-proof mechanisms in Section 2 and present a message signing model in Section 3. We propose the EASES protocol in Section 4, and extend it to a dynamic version where the production of signature keys can be done dynamically in Section 5. We evaluate the security and performance of EASES in Section 6 and conclude the paper in Section 7.
2. Related work Several papers have investigated the types of cheats and security requirements of multiplayer games. Kirmse and Kirmse [17] present the security goals for online games in respect to the protection of sensitive information and the provision of fair play. Dickey et al. [11] shows that several types of cheats may occur when honest players’ actions are known in advance by cheaters, who can then respond unfairly to their advantages. Smed [18] describe considerations in multiplayer games such as the network resources, communication architectures, scalability and security. Yan [19] demonstrates several security requirements for online games via a simple client–server bridge game. Besides the above work, several cheat-proof mechanisms have also been proposed. Baughman and Levine [10] present the ‘‘lockstep” mechanism to solve the cheating problem. Based on the concept of bucket synchronization [20,21], their mechanism divides a game session into ‘‘time buckets” (i.e., time intervals, or ‘‘rounds”) for game state synchronization. In each round, a player first sends a cryptographically secure one-way hash value of its state update as a commitment, and then sends the plaintext update to reveal the commitment in the next round. This prevents any player from knowing other players’ actions ahead of time. Cronin et al. [22] further improve the performance of lockstep with ‘‘sliding pipeline” by sending out several updates in advance without waiting for acknowledgements from other players. GauthierDickey et al. propose the new event ordering (NEO) protocol [11] to improve the work of Baughman and Levine [10] and Cronin et al. [22]. NEO claims to prevent common protocol-level cheats with low latency. However, Corman et al. [14] later show that NEO cannot prevent all cheats as claimed, and present an improvement called secure event agreement (SEA) as a remedy. Since our work is mostly inspired by NEO and SEA, we detail the two protocols below.
1840
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
2.1. Description of NEO GauthierDickey et al. propose NEO to prevent cheating by digital signatures and a voting mechanism to compensate for packet loss [11]. NEO divides the time into fixedlength rounds, and every player sends an event update message in each round. The event update of NEO is described in formula (1), where U rA is the update from player A for round r, SA ð Þ is the signature function, f gK r represents A an encryption, K Ar1 is A’s key for the update from round r1 r 1, and V A is a bit vector for voting. The voting is used to form a consensus on whether a given player has sent an update within a round, in order to determine if that update should be accepted. When each player acts, an event update is first signed and encrypted before sending to other players. The event update and its signature are encrypted together as a commitment, which is revealed in the next round when the player sends the associated key. Players are obliged not to modify their actions after the commitments are sent (i.e., when they might have learned about others’ actions), as other players can verify an action by the associated commitment sent in the previous round. M rA ¼ fSA ðU rA ÞgK r ; A
K Ar1 ;
SA ðV Ar1 Þ:
ð1Þ
2.2. Description of SEA However, Corman et al. [14] show that NEO has some drawbacks (e.g., an attacker can replay updates for another player, or send different updates to different players) and thus propose the SEA protocol as an improvement. The event update message of SEA is described in formula (2), where H( ) is a hash function, U rA is the update from player A for round r, nr is a random value for round r, SessID is the session ID to prevent players from replaying this message in a different session, IDA is the unique identity of player r1 A, and VhA is the votes of updates received by player A in round r 1 that includes a hash of the updates (
r
CommitA ¼ HðU rA ; nr ; SessID; IDA Þ; r
r1
MrA ¼ SA ðCommitA ; U Ar1 ; VhA ; nr1 ; rÞ:
ð2Þ
Signing the entire message is used to authenticate the message creator, and the hash serves as the commitment of the update sent in the next round. In order to achieve better performance and avoid potential issues with key tampering and selection, the SEA protocol replaces encryption with a cryptographic hash function as the commitment method. When the commitment is done by encryption, the distribution, protection and selection of keys must be carefully considered, or problems would arise from poorly designed key management schemes. However, if the commitment is made via hash functions, the above key-related issues can be avoided. 3. Message signing model As public-key cryptosystem requires a large amount of computations. To improve the efficiency, we compute a message’s digest by a hash function before signing the
message. The information used in a digest signature protocol is described in the following equation: 8 the full message; >
The ith player in the game Hash operator with input message x One-time signature key of player i in the rth round A message x signed by secret key sk An event update of player i in the rth round Concatenation of message x and y To check if x equals to y Signature signed by player i ’s rth one-time signature key Signature signed by player i ’s secret key sk
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
4.1. Initialization phase Before starting the game, each player must first generate a series of one-time signature keys. The following key generation operation can be done before a user logins the game, or before the first event update is sent. 1. Each playeri first picks an unpredictable random number as the master key MK i to compute a series of n one-time signature keys, where n is a system parameter that specifies the maximum number of updates (i.e., rounds) in a session. Choosing larger n increases the costs to compute and store the keys, but may save computing time during the later update stage. 2. We begin the key generation with the last key, so the nth one-time signature key is computed by K ni ¼ HðMK i Þ. And for the other rth round, where r ¼ ðn 1Þ; . . . ; 0, the signature key is computed by K r1 ¼ HðK ri Þ. i After these one-time signature keys (i.e., a hash-chain keys) are generated, player i signs the first one-time signature key by its secret key to get the signature Di ¼ Ssk ðK 0i Þ. Note that keys are used in the reverse order of their production (i.e., the last key produced is the first key used in the game session and needs to be signed). See Fig. 1 for a schematic of the key production. 4.2. Signing phase In the rth round, playeri computes the signature of the event updates dri ¼ HðK ri jU ri Þ, where U ri is player i ’s rth event update. Playeri then sends the signature dri , the previous event update U r1 and its associated key K ir1 to other playi ers. The below equation shows the message sent by player i ( d1i ¼ HðK 1i jU 1i Þ; Di ; K 0i in the first round; dri ¼ HðK ri jU ri Þ; U ir1 ; K r1 i
in the subsequent rth round: ð5Þ
For instance, playeri sends out the message d1i ¼ HðK 1i jU 1i Þ; Di ; K 0i in the first round. In the second round, player i sends out d2i ¼ HðK 2i jU 2i Þ; U 1i ; K 1i . In a subsequent rth round, player i sends out dri ¼ HðK ri jU ri Þ; U ir1 , and K r1 . i 4.3. Verification phase On receiving messages from player i , each player verify the messages as follows:
1841
1. In the first round, each player receiving d1i ¼ HðK 1i jU 1i Þ; Di ; K 0i , verifies Di with player i ’s public-key and K 0i to see if the key K 0i is legitimate. 2. In the rth round, r ¼ 2; . . . ; n, each player receiving dri ; U ir1 ; K r1 verifies: i (a) K ir2 9HðK ir1 Þ to see if the signature key K ir1 is authentic (i.e., the signature key K ir2 was generated from K ir1 ). (b) dir1 9HðK r1 jU ir1 Þ to see if the update has been i tampered.
For example, in the second round, a player should verify K 0i 9HðK 1i Þ as well as d1i 9HðK 1i jU 1i Þ for player i . If the verification passes, then a player can be sure that the update is from player i and is not tampered. 4.4. Re-initialization phase The signature keys have to be re-generated when they are depleted for a session. One basic method is for players to start over from the initialization phase to generate and use new signature keys. However, a more efficient way is for playeri to perform the following actions in the nth and ðn þ 1Þth round. 1. In the nth round, playeri generates a series of new onetime signature keys NewK 0i ; . . . ; NewK ni with a new random number (i.e., a master key NewMK i ). In practice, player i can generate the keys in advance to avoid sudden computing load. Playeri signs (hashes) the new signature key NewK 0i with the key K ni to have dni ¼ HðK ni jU ni jNewK 0i Þ. Playeri then sends dni ; U n1 ; K n1 i to other players as usual. 2. In the ðn þ 1Þth round, playeri sends dnþ1 ¼ HðNewK 1i jU nþ1 Þ; U n ; K ni and NewK 0i to other i i players. 3. In the ðn þ 2Þth round, in addition to the regular message, playeri should also send the old master key MK i (i.e., the pre-image of K ni ). Besides the regular verifications, the receivers now should perform the following additional verifications. 1. On receiving dnþ1 ; U n ; K ni in the ðn þ 1Þth round, the i receiver should verify dni 9HðK ni jU ni jNewK 0i Þ to check the authenticity of NewK 0i . 2. In the ðn þ 2Þth round, the receiver should also verify K ni 9HðMK i Þ. If the above verifications pass, NewK 0i is authenticated to be sent by player i and the series of new keys NewK 0i ; . . . ; NewK ni can be used after the ðn þ 2Þth round according to the normal procedures. 4.5. Late joining
Fig. 1. Production rule for the one-time signature keys.
If the set of receivers is fixed during a game session, then player i only needs a single set of keys to sign updates. On the other hand, player i may need separate sets of keys for each player j if we allow a new players to join an on-going session.
1842
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
However, the cost to maintain separate key sets can be high. Below, we show two alternatives for player j to authenticate the key K ri when it joins an on-going session in the rth round without keeping separate key sets. 1. Re-send previous signature keys. Playeri sends Di ð¼ Ssk ðK 0i ÞÞ; K 0i ; . . . ; K ir1 to playerj along with dri ¼ HðK ri jU ri Þ. This is for player j to verify that K 0i ; . . . ; K ir1 is generated by player i . Player j can then authenticate K ri when it is sent in the ðr þ 1Þth round by checking K ir1 9HðK ri Þ. Playerj can also check dri 9HðK ri jU ri Þ to see if U ri sent in the ðr þ 1Þth round is tampered or not. 2. Encrypt last signature key. Playeri signs the key K ir1 by its secret key sk and sends the key K ir1 and the signature Ssk ðK r1 Þ along with dri ¼ HðK ri jU ri Þ. The signature i r1 Ssk ðK i Þ is for player j to authenticate K r1 . Again, i playerj can then check if K ri and U ri are correct in the next round given that K ir1 is already authenticated. 5. Dynamic EASES Dynamic EASES extends the ‘‘authentication via hashing” idea of the basic EASES but avoids the pre-generation of hash-chain keys. This helps to reduce memory usage. We achieve this by signing the messages without first preparing a series of hash-chain keys. The key point is to defer the revelation of committing key for two rounds. An adversary cannot intrude since he gets no knowledge about the committing key. As it is not necessary to initialize or re-initialize the hash-chain in the dynamic version, there are only two phases: signing and verification. 5.1. Signing phase When player i has to sign an update message U ri for playerj in round r, there are three cases to consider: 1. In the first round, player i picks an unpredictable random value K 1i , computes HðU 1i jK 1i Þ, and sends out the signed hash value Ssk ðHðU 1i jK 1i ÞÞ. 2. In the second round, playeri picks an unpredictable random value K 2i , computes HðU 2i jK 2i jK 1i Þ, and then sends out the signed hash value Ssk ðHðU 2i jK 2i jK 1i ÞÞ. 3. In subsequent rounds, player i generates an unpredictable random value K ri , computes HðU ri jK ri jK ir1 Þ and sends HðU ri jK ri jK ir1 Þ, K ir2 , U ir2 . The playeri ’s out-going messages are summarized in the following equation: 8 1 1 > in the first round; < Ssk ðHðU i jK i ÞÞ > :
Ssk ðHðU 2i jK 2i jK 1i ÞÞ
in the second round;
HðU ri jK ri jK ir1 Þ; K ir2 ; U ir2
in the subsequent rth round: ð6Þ
5.2. Verification phase Playerj performs the following actions to verify the authenticity of the received messages from player i . There are three cases to verify:
Fig. 2. Message signing structure of dynamic EASES.
1. In the first round, player j verifies the signature Ssk ðHðU 1i jK 1i ÞÞ by playeri ’s public-key and then keeps HðU 1i jK 1i Þ in the memory. 2. In the second round, playerj verifies the signature Ssk ðHðU 2i jK 2i jK 1i ÞÞ by player i ’s public-key and then keeps HðU 2i jK 2i jK 1i Þ in the memory. 3. In subsequent rounds, player j can reveal the commitment and check the authenticity of the messages received in the previous two rounds. In other words, the authenticity of U ir2 is checked in the rth round. To verify K ir2 ; U ir2 for the ðr 2Þth round, player j simply computes HðU ir2 jK ir2 jK r1 Þ. Note that in the 3rd i round, only HðU 1i jK 1i Þ (i.e., the signature obtained in the 1st round) needs to be computed. The full message exchange in dynamic EASES is shown in Fig. 2. Similar to the basic EASES, the player can ensure that the messages from previous rounds are correct by verifying the messages with hashing. The major difference between the dynamic and the basic EASES are: 1. Dynamic EASES needs two digital signature operations when initializing a new game session. 2. Hash-chain generation is no longer necessary in the dynamic version. 3. Dynamic EASES requires one more round than the basic EASES to reveal the plaintext of a message. For example, in the basic EASES, the receiver reveals the commitment of dri and confirms the authenticity of K ri by deciding whether K ir1 9HðK ri Þ after receiving U ri and K ri in the rth round. But in dynamic EASES, the player ensures that the message of the ðr 2Þth round is correct by verifying the message received in the rth round. 6. Evaluation 6.1. Applicability EASES can be used to sign many discrete messages efficiently and is suitable for both fully connected and scalable P2P topologies. In the former, player i sends the messages to all other players. In the latter, player i sends the messages to all players within its visibility range (often called area of interest or AOI). The concepts of EASES can be easily applied to NEO and SEA, and also to the sliding pipeline protocol [22] by utilizing multiple series of hash-chain keys. To prevent other attacks such as eavesdropping with network sniffers, authenticated key exchange protocol [23] can be used to encrypt data between two communication parties. Adding a counter to the message before encryption can also prevent modification and fabrication attacks. Besides, voting mechanism can be used to prevent an
1843
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
attacker from sending different updates to different players [14]. However, those topics are beyond our current scope. 6.2. Security analysis EASES supports message non-repudiation via commitments. The event update U ri is committed by K ri at round r and revealed in the next round. This property is based on EASES’ support of the two fundamental requirements for digital signatures: unforgeability and verifiability. Unforgeability means that no one can generate a legal signature for a specific message except the signer. Only the signer keeps the correct private key for generating a legal signature verifiable by the corresponding public-key. Verifiability means that everyone can verify whether a digital signature is legal. Below, we analyze EASES according to these two requirements. Unforgeability: In EASES, one cannot claim to have signed U ri and produced the signature dri unless K ri is presented. However, no one can show the signing key K ri for the current update U ri before the original signer reveals it. The cryptographic hash used by EASES also has the following secure properties: for any given hashed value, it is computationally infeasible to find its pre-image due to the one-way property of hash functions (i.e., for any given message x, it is computationally infeasible to find another message x0 such that HðxÞ ¼ Hðx0 Þ). Moreover, strong collision resistance exists in some hash functions, meaning that it is computationally infeasible to find any pair of ðx; yÞ such that HðxÞ ¼ HðyÞ, where x 6¼ y. EASES is unforgeable since it adopts a secure hash function that has the above properties. With unforgeability, non-repudiation can be achieved in EASES. Verifiability: Cryptographic hash function is a public standard that can be installed and executed on every player’s computer, so everyone can re-compute the hash value of a given signature key K ri and message U ri to verify if it equals the previously received signature by checking dri 9HðK ri jU ri Þ. Dynamic EASES: Both the basic and the dynamic version of EASES maintain their security under ‘‘lockstep” game environment (i.e., the players will only advance game rounds together, making the adversary unable to gain advantages via uneven information across rounds). We can especially appreciate this property by observing the dynamic version. In dynamic EASES, the first and the second messages can be undoubtedly authenticated by the sender’s public-key. In the third round, the player receives HðU 3i jK 3i jK 2i Þ; K 1i ; U ri , so the adversary must know K 2i in order to replace U 3i jK 3i and forge messages afterwards. However, K 2i will only be revealed in the fourth round. For example, the message U 3i whose commitment was received in the third round can be revealed and confirmed, when its committing keys K 2i and K 3i are received in the fourth and fifth round. K 2i cannot be forged because all K 2i keys that appear in rounds 2, 3 and 4 can be compared. Likewise, K 3i cannot be forged because all K 3i keys in rounds 3, 4 and 5 can be compared. The authenticity of message U 3i is thus ensured as K 2i ; K 3i are verifiable in the fourth and the fifth rounds.
6.3. Performance analysis and comparisons Computation cost: The major benefit of EASES is computational efficiency. There is at least one signature operation and one verification operation for each event update in the schemes such as NEO and SEA. In comparison, there are only two hash operations for each event update in EASES and one traditional signature operation during the initialization phase in EASES. The approximate CPU cycles for some cryptographic functions are listed in Table 2. Memory consumption: EASES requires a player to prepare a block of memory to store the list of one-time signature keys. The exact memory size depends on the hash value length and the chosen round size n. For example, if MD-5 is used and n ¼ 1000, then each player will need 1000 128 = 128,000 bits = 16,000 bytes of memory to store the one-time signature keys. Bandwidth consumption: Except for the first update, EASES needs to transfer the one-time signature for every event update, with the size of a hash value. This is much shorter than the size of traditional digital signatures. For example, SHA-1 uses 192 bits for each hash value, whereas 1024-RSA uses 1024 bits for each signature. EASES thus only needs a size about twice the hash value. We briefly compare EASES with NEO [11] and SEA [14], both of which adopt traditional digital signatures to sign updates in every round (see Table 3). NEO uses two signature operations, and SEA uses one. EASES replaces the signature by hash operations. NEO and SEA need one signature operation in each round. EASES needs one signature operation only for initialization of the one-time signature keys, and only hash operations are used afterwards. 6.4. Experimental results We perform simulation experiments on an Intel Pentium-4 3.4 GHz PC for evaluating the performances of the two versions of EASES and the digital signature-based
Table 2 Approximate CPU cycles for some cryptographic functions [14,15] Primitive type
Example
Clock cycles
Hash function Symmetric encryption Digital signature
SHA-1 AES RSA-PSS
15/byte +1040 25/byte +504 42,000,000
Table 3 The comparisons of NEO, SEA and EASES
NEO SEA Basic EASES Dynamic EASES
Message sizea
Memory space
Computation cost
1 ds + 1 en + 1 dk 1 ds 2 hashes
None
1 ds + 1 en
None n hash-chain keys None
1 ds + 1 hash 2 hashes
2 hashes
1 hash
ds: digital signature; en: encryption; and dk: decrypting key. a The actual game update message is excluded.
1844
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845
schemes, which NEO and SEA rely on. We are mainly interested in the time required to commit event messages. We assume that the popular RSA OAEP (optimal asymmetric encryption padding) [24] signature protocol is adopted by NEO and SEA, and adopt the functions from the Crypto++ library [25] for RSA OAEP signing and verification in our evaluation. The hash algorithm SHA1 is used for EASES. We assume that the event update length is 70 bytes. The length of RSA key is 1024 bits. The number of game rounds are fixed at 1000. Both the scenarios where the number of concurrent players n changes and the new player arrival rate changes are evaluated, respectively. Fig. 3 shows the total CPU time spent by each player’s personal computer in 1000 rounds. In each round, one signing and n verifications are invoked for each participating player. The resulting growth in computing time is expected since CPU load grows heavier with more concurrent players. Even though Crypto++ uses low exponential public-key as default to help accelerate multiple verifications in a general signature protocol, EASES still performs better. Consider that new players join and depart constantly in a dynamic game environment, since authentication is not necessary for the departing player, the cost is caused mainly by player joining. There are about 500 to 4500 new players joining in realistic online games [26]. If each round is for one second, we can estimate that there are about 132–1245 new players joining the game in 1000 rounds. Simulation results on new player arrivals is presented in Fig. 4. We fix the total number of players at 100, and then measure how the arrival rate impacts the
Fig. 3. CPU time usage of RSA OAEP and EASES for each player in 1000 rounds.
Fig. 4. Effect of new player arrivals.
performance of EASES. From the figure, we can see that EASES still has better overall performance. 7. Conclusion In this paper, an efficient and secure event signature (EASES) protocol for P2P-based MMOGs is proposed. EASES supports the commitment property of digital signatures by using hash functions, and we show that it has the nonrepudiation property by possessing unforgeability and verifiability as traditional digital signatures do. Unlike existing schemes such as NEO and SEA that use digital signatures in every round of a game session, EASES uses a digital signature only during initialization and uses hash-chain keys in all subsequent rounds. To reduce memory usage, we also describe a dynamic version of EASES that removes the requirement of hash-chain key pre-production at the expense of an extra one-round delay of message commitment. As shown by analysis and measurement experiments, EASES thus requires much less computation and bandwidth than current signature protocols. The low resource requirement and adaptability to dynamically changing topologies make EASES quite applicable to P2Pbased MMOGs. References [1] B.S. Woodcock, An Analysis of MMOG Subscription Growth,
M.-C. Chan et al. / Computer Networks 52 (2008) 1838–1845 [15] B. Preneel, B. Van Rompay, S. Ors, A. Biryukov, L. Granboulan, E. Dottax, M. Dichtl, M. Schafheutle, P. Serf, S. Pyka, Performance of Optimized Implementations of the NESSIE Primitives,
Mo-Che Chan is currently a Ph.D. student with the Department of Computer Science and Information Engineering at National Central University, Taiwan. His current research interests encompass distributed systems and network security.
1845
Shun-Yun Hu ([email protected]) is currently a Ph.D student at National Central University, Taiwan. He received his M.Eng. degree in computer science and information engineering from Tamkang University in 2005. His main research interests are networked virtual environments and peer-topeer systems. He has published in IEEE Network and IEEE INFOCOM, and was a co-organizer of the IEEE Virtual Reality workshop Massively Multiuser Virtual Environments (http://peers-at-play.org/MMVE08/). He has been inspired and fascinated by the possibilities of virtual worlds since first playing with computer games at the age of 7. He started the SourceForge project VAST (http://vast.sourceforge.net) in 2005 and ASCEND (http://ascend.sourceforge.net) in 2006, to provide open source libraries for creating scalable peer-to-peer-based virtual environments.
Jehn-Ruey Jiang received his Ph.D. degree in Computer Science in 1995 from National Tsing-Hua University, Taiwan, ROC. He joined Chung-Yuan Christian University as an Associate Professor in 1995. He joined HsuanChuang University in 1998 and became a full Professor in 2004. He is currently with the Department of Computer Science and Information Engineering, National Central University. He was a recipient of the Best Paper Award of the 32nd International Conference on Parallel Processing, 2003, and a recipient of Excellent Paper Award of Mobile Computing 2004. His research interests include distributed computing, mobile computing, pervasive computing and peer-to-peer computing.