Method of network architecture for gaming system, its game console, its system, and recording medium

The present invention relates to a console-based gaming system, and more particularly to a method of establishing secure communication between two gaming systems connected via a local area network.

Traditionally, gaming systems with dedicated consoles have been stand-alone machines that handle a limited number of players (eg 2-4 players). Personal computer-based gaming has become popular, in part, because it allows you to play games online with many remote players over the Internet. Therefore, one trend with dedicated gaming systems is the ability to facilitate network-based gaming, such as internet-based online gaming and LAN-based gaming where multiple consoles are connected over a local area network (LAN). To provide.

One challenge in network gaming is protecting network traffic between any two game consoles from modification or monitoring by other devices on the network. Gamers are notorious for developing ingenious fraudulent mechanisms. For example, gamers can use their computers to view parts of a game map that they wouldn't normally see, or change unprotected network traffic to perfect targets or speed up players. Sometimes I put myself in an advantageous position during play. Unfortunately, previous console-based gaming systems did not provide secure communication.

In a console-based system that establishes secure communication between a plurality of gaming systems, techniques such as encryption are required, but there is a text that discloses a basic outline of encryption (see, for example, Non-Patent Document 1). ).<nplcit num="1"><text>Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", published by John Wiley &amp; Sons, copyright 1994 (second edition 1996)</text></nplcit>

<p> Therefore, there is a need for a system architecture that supports secure communication between two or more gaming systems over a local area network. The present invention has been made in view of such problems, and an object of the present invention is to provide a network architecture for a gaming system in which a plurality of game consoles can establish secure communication via a local area network. The method , the game console, the system and the recording medium are to be provided.</p>

<p> Describe the network architecture for console-based gaming systems. This architecture allows multiple game consoles to establish secure communication over a local area network.</p><p> In the described implementation, the system architecture supports a three-step secure communication protocol. The first step involves generating a shared key that is unique to the authentic game console that runs the authentic game title. The same game console running the same game will generate the same shared key. In the second phase, the "client" console attempts to discover existing game sessions hosted by the "host" game console by broadcasting requests over the local area network. This broadcast request indicates that we want to join the game play at the next convenient opportunity. This broadcast request is protected using a shared key. If the host console agrees to play, the host console generates a session key and the session key is securely returned to the client console. The third stage involves a key exchange between the client console and the host console exchanging the data used to derive one or more secrets. This key exchange is protected using a session key. This secret is then used to establish a secure point-to-point link between the two consoles for ongoing communication.</p>

Embodiment of the invention

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In each drawing, parts having the same function are designated by the same reference numerals, and duplication of description will be omitted. The following discussion covers console-based systems and techniques that establish secure communication between multiple gaming systems connected over a local area network (LAN). This commentary assumes that the reader is familiar with basic cryptographic principles such as encryption, decryption, authentication, hashing, and digital signatures. See the text for a basic overview of cryptography (see, for example, Non-Patent Document 1).

<u style="single">Gaming system</u> Figure 1 shows an exemplary gaming system 100. This exemplary gaming system 100 includes a game console 102 and up to four controllers represented by controllers 104-1 and 104-2. The game console 102 is equipped with an internal hard disk drive and a portable media drive 106. The portable media drive 106 supports various forms of portable storage media represented by the optical storage disk 108. Examples of suitable portable storage media include DVDs (digital versatile disks), CDs (compact disks)-ROMs (read only members), game discs, game cartridges, and the like.

The game console 102 has four slots 110a-110d in front of it to support up to four controllers, but the number and arrangement of slots can be changed. The power button 112 and eject button 114 are also located in front of the game console 102. The power button 112 switches power to the game console, and the eject button 114 alternately opens and closes the tray of the portable media drive 106 to allow insertion and removal of the storage disk 108.

The game console 102 connects to a television or other display (not shown) via the A / V interface cable 120. The power cable 122 powers the game console. The Game Console 102 is further equipped with an internal network function or an external network function represented by a cable or modem connector 124 to facilitate access to networks such as local area networks (LANs) or the Internet. ..

Each controller 104-1 to 104-2 is coupled to the game console 102 via a wired or wireless interface. In the implementation shown, the controller is USB (Universal Serial Bus) compatible and is connected to the console 102 via a serial cable 130. The console 102 can be equipped with any of a wide range of user interaction mechanisms. As shown in FIG. 1, each controller 104-1 to 104-2 is equipped with two thumbsticks 132-1 and 132-2a to 132-2b, a D pad 134, a button 136, and two triggers 138. To. These mechanisms are merely representative, and the mechanism shown in FIG. 1 can be replaced with another well-known gaming mechanism, or other well-known gaming mechanism can be added to the mechanism shown in FIG. ..

A memory unit (MU) 140 can be inserted into controller 104-2 to provide additional and portable storage. The portable memory unit allows the user to store game parameters, transfer the game parameters, and play them on other consoles. In the implementation described, each controller is configured to accommodate two memory units 140, but in other implementations three or more or one or less may be utilized.

The gaming system 100 can play games, music, and videos, for example. By providing various storage devices, titles can be played from a hard disk drive, portable media 108 in drive 106, online source, or memory unit 140. Examples of what the Gaming System 100 can play are: 1. Game titles played from CD and DVD discs, optical disc drives, or online sources 2. CDs in portable media s drive 106, compression on optical disc drives Files (eg, Windows® Media Audio (WMA) format), or digital music played from online streaming sources 3. DVD discs in portable media drive 106, files on hard disk drives (eg, Windows® ) Media Video (WMV) format), or includes digital audio / video played from online streaming sources.

Figure 2 shows the functional components of the gaming system 100 in more detail. The game console 102 has a central processing unit (CPU) 200 and various types of memory including flash ROM (read-only memory) 204, RAM (random access memory) 206, hard disk drive 208, and portable media drive 106. It has a memory controller 202 that makes it easy for the user to access. CPU 200 is equipped with Level 1 cache 210 and Level 2 cache 212 to temporarily store data and thus reduce the number of memory access cycles, thereby increasing processing speed and throughput.

The CPU 200, memory controller 202, and various memory devices include one or more serial and parallel buses, memory buses, peripheral buses, and processor or local buses that use any of the various bus architectures. It is interconnected via a bus. For example, such architectures include Industry Standard Architecture (ISA) Bus, Micro Channel Architecture (MCA) Bus, Enhanced ISA (EISA) Bus, Video Electronics Standards Association (VESA) Local Bus, and Peripheral Component Interconnect (PCI). Buses can be included.

One suitable implementation is to integrate CPU 200, memory controller 202, ROM 204, and RAM 206 on common module 214. In this implementation, ROM 204 is configured as a flash ROM connected to memory controller 202 via a PCI bus and a ROM bus (neither shown). The RAM 206 is configured as a plurality of DDR SDRAM (Double Data Rate Synchronous Dynamic RAM) modules that are separately controlled by the memory controller 202 via separate buses (not shown). The hard disk drive 208 and the portable media drive 106 are connected to the memory controller via the PCI bus and the ATA (AT attachment) bus 216.

The 3D graphics processor 220 and the video encoder 222 form a high-speed, high-resolution video processing pipeline for graphics processing. Data is transported from the graphics processor 220 to the video encoder 222 via a digital video bus (not shown). The audio processor 224 and the audio codec (coder / decoder) 226 form a corresponding audio processing pipeline with high precision and stereo processing. Audio data is carried between the audio processor 224 and the audio codec 226 via a communication link (not shown). The video and audio processing pipeline outputs data to A / V (audio / video) port 228 for transmission to televisions or other displays. In the illustrated implementation, the video and audio processing components 220-228 are mounted on module 214.

The USB host controller 230 and network interface 232 are also mounted on module 214. The USB host controller 230 is coupled to the CPU 200 and the memory controller 202 via a bus (for example, the PCI bus) and acts as a host for peripheral controllers 104-1 to 104-4. Network interface 232 provides access to the network (eg LAN, Internet, etc.). The network interface 232 may be any of a wide range of wired or wireless interface components, including Ethernet cards, modems, Bluetooth modules, cable modems, and the like.

The game console 102 has two dual controller support subassemblies 240-1 and 240-2 that subassemble support two game controllers 104-1 to 104-4, respectively. The front panel I / O subassembly 242 supports the functions of the power button 112 and eject button 114, exposing LEDs (light emitting diodes) or other indicators to the exterior of the game console. Subassemblies 240-1, 240-2, and 242 are coupled to module 214 via one or more cable assemblies 244.

Eight memory units 140-1 to 140-8 are shown as connectable to four controllers 104-1 to 104-4. That is, there are two memory units for each controller. Each memory unit 140-1 to 140-8 provides additional storage that can store games, game parameters, and other data. The memory units 140-1 to 140-8 can be accessed by the memory controller 202 when inserted into the controller.

The system power supply module 250 powers the components of the gaming system 100. Fan 252 cools the circuit in game console 102. The console user interface (UI) application 260 is stored on hard disk drive 208. When the game console is powered on, various parts of the console application 260 are loaded into RAM 206 and / or cache 210, 212 and run on CPU 200. The console application 260 presents a graphical user interface that provides a consistent user experience when navigating through the various media types available on the game console.

Game console 102 implements a cryptographic engine that performs common cryptographic functions such as encryption, decryption, authentication, digital signatures, and hashing. The crypto engine can be implemented as part of the CPU 200, or it can be implemented with software stored in memory (eg ROM 204, hard disk drive 208) that runs on the CPU, thereby allowing the CPU to perform cryptographic functions. It can also be configured to run.

The gaming system 100 can operate as a stand-alone system simply by connecting the system to a television or other display. In this standalone mode, the gaming system 100 allows one or more players to play games, watch movies, or listen to music. However, the integration of network connectivity made available through network interface 232 allows the gaming system 100 to even act as a participant within a larger network gaming community. This network gaming environment will be described below.

<u style="single">Network gaming</u> FIG. 3 shows an exemplary network gaming environment 300 in which multiple gaming systems 100-1, 100-2, ..., 100-g are interconnected via a local area network 302. LAN 302 can be implemented using any one or more of a wide range of conventional communication media, including wired and wireless media. As an example, LAN 302 represents an Ethernet® crossover cable or Ethernet® hub. Other possible implementations of LAN 302 include FireWire (specifically IEEE 1394) and Universal Serial Bus (USB).

Many game titles are scalable to support multiple players on different consoles. By interconnecting a plurality of gaming systems via LAN 302, a plurality of players can compete in the same game. For example, some game titles allow up to 16 different players. This up to 16 different players consist of any player and gaming system combination (eg, from 1 player each on 16 gaming systems to 4 players each on 4 gaming systems). can do.

Network-based games are hosted by one of the game consoles. This discussion assumes that gaming system 100-1 hosts games for client gaming systems 100-2, ..., 100-g. In this situation, the hosting function is the function of adjusting the player's access to the multiplayer game. The "hosting" metaphor does not mean that one game console supplies game content to another. Each game console 100-1 to 100-g has a hard disk drive 208 (for example, by purchasing or downloading an authentic game title from the vendor's website), or a digital video disc (DVD) 108-1, 108-2 ,. Each game console has a copy of the game itself, stored on either of the portable storage media represented by .., 108-g.

<u style="single">Secure communication protocol</u> All game consoles involved in network gaming conditions first establish a secure communication link between them. Secure communication means that data can be transferred between two entities to resist alteration. The transferred data can be authenticated by the entity and can be assured that the trusted entity actually sent that particular data. Secure communication may or may not use encryption. Encryption effectively hides the transmitted data from the observer. If encryption is used, the encryption can be done before or after authentication.

Referring to Figure 3, each client game console 100-2 ~ 100-g wishing to participate seeks permission from the host gaming system 100-1. Secure communication is established between the requesting client console and the host console if the host so desires. The establishment of a secure communication link is carried out by a three-step process. Briefly, the first step involves the generation of a shared private key known only to the authentic game console that runs the authentic game title.

The second stage involves session discovery, where the client console attempts to discover an existing game session hosted by the host game console. During session discovery, the client console broadcasts the discovery request over the local area network. This discovery request indicates that you want to join the LAN-based game at your next convenient opportunity. This discovery request is protected using a shared key. If the host console agrees to play, the host console will generate a discovery response containing the session key. This discovery response is returned directly or indirectly to the client console via broadcast communication.

The third stage involves key exchange, where the client and host consoles exchange data that they use to derive one or more secrets. This key exchange is protected using a session key. This secret is then used to establish a secure point-to-point link between multiple consoles for ongoing communications.

Following one possible implementation of the secure communication protocol, these steps are described in more detail below.<u style="single">Stage I: Shared Private Key Generation</u> Figure 4 shows the first stage 400 of a secure communication protocol in which a shared private key unique to an authentic gaming system running an authentic game title is generated. The console stores the private key 402 in a secure location, such as in the protected portion of ROM 204. In addition, each game title certified to play on the gaming system has an associated unique, randomly generated title key 404. The title key 404 is the same for every copy of the same game title. Different titles have different title keys. The title key 404 can be stored as part of the game title, such as on a DVD, or along with a soft copy of the game title that was legitimately purchased and downloaded online for storage on the hard disk drive of the game console. Can be stored.

The LAN key generator 406 uses a console-based key 402 and a title-based key 404 to derive the LAN key 408. In one implementation, the LAN key generator 406 uses two keys 402 and 404 to compute a one-way encryption function during network stack initialization. As an example of a suitable encryption function, the LAN key generator 406 concatenates keys 402 and 404 and performs an HMAC-SHA-1 (Hashed Message Authentication Code-Secure Hash Algorithm 1) operation on it to perform the LAN key 408. To generate.

The LAN key 408 is then used to generate the shared private key. More specifically, when the network stack is initialized, the broadcast communication key generator 410 uses the LAN key 408 to generate the title broadcast communication encryption key 412 and the title broadcast communication signature key 414. As an example, the generator 410 can generate keys for symmetric cryptography, asymmetric cryptography, hashing algorithms, and digest algorithms.

During initialization, broadcast communication keys 412 and 414 are generated once. All gaming systems running the same title will generate the same key pair. Any gaming system that runs different titles on the same LAN will have different key pairs. The key combination prevents someone from discovering how to intercept or modify the broadcast message for a particular game simply by being able to read the game title.

<u style="single">Stage II: Session Discovery</u> Figure 5 shows Phase 500 of the secure communication protocol, where the client console attempts to discover if any other console on the LAN is currently hosting a multiplayer game session of a particular title. With just a few consoles connected over a small local area network, it is unlikely that one or more consoles are hosting a particular game. For a few consoles, there is no third-party matchup, and therefore it is left to the client console to find the appropriate host for the client console itself via broadcast communication techniques. However, keep in mind that the number of game sessions available can be very large in the future and dedicated match-up services may be used to find the right match.

The second stage is described in the context of the general flow of operations performed by the requesting client console 100-2 and the potential host console 100-1. The operations are shown below the client console and host console to tell you where such operations are performed.

In operation 502, client console 100-2 asks for a request message and a nonce N._iGenerate a request REQ that includes (the nonce on the invoking side). In operation 504, the client console has the title broadcast communication encryption key 412 (K)._EEncrypt the request using a symmetric key cipher E (eg, DES) that uses (shown as) as follows:

REQ^E= E_KE[Request message, N_i In operation 506, the client console has the title broadcast communication signature key 414 (K)._SDigitally sign the request as follows:

REQ^ES= S_KS[REQ^E]

In operation 508, the client console encrypts and signs the request REQ.^ESBroadcast to other consoles on LAN 302. The host console 100-1 has a UDP (user datagram protocol) socket opened in advance, and listens to the discovery broadcast communication message via the LAN. A console running the same game title can generate the same set of title broadcast keys 412 and 414, thus authenticating and decrypting the message, thus recognizing the request. However, consoles running different game titles will discard the message. Suppose you have one host console and are running the same game title (Operation 510). Therefore, the host console can derive the title broadcast communication encryption key 412 and the title broadcast communication signature key 414 in the same manner as given in step I (Fig. 4).

In operation 512, the host console authenticates the request using the same title broadcast signature key 414. In operation 514, the host console uses the same title broadcast encryption key 412 to decrypt the message as follows:

REQ = D_KE[REQ^E]

In operation 516, the host console determines whether the requesting client console is able to participate in the network game. Factors that influence this determination include the number of current players, the number of players supported in the game, the current situation of the game (ie, just started, in the middle of the session, etc.). Assuming the host console accepts a new client console with one or more players, the host console will generate a unique key pair used to distinguish between different sessions (Operation 518). These keys include the network key identifier NKID and the network key exchange key NKEY. The identifier NKID is simply the name for the key NKEY. In one implementation, the session key is generated by a random number generator. These keys are used in the key exchange phase described below with reference to FIG. The session key NKEY will be used in the future to authenticate the contents of key exchange packets exchanged between the two consoles, while the key identifier NKID will specify the game session to which the source console is connected. use. Note that the session keys NKID and NKEY can be pre-generated before receiving any request from the client console.

In operation 520, the host console generates a response to the discovery request. This response includes at least the response message, the NKID / NKEY pair, and the network address NADDR of the host game console. The response message can include nonce Ni on the invoking side, nonce Nr on the responding side, and game-specific data. In operation 522, the host console uses the title broadcast encryption key 412 to encrypt the response as follows:

REPLY^E= E_KE[Request message, NKID, NKEY, NADDR]

In operation 524, the host console presses the title broadcast communication signature key 414 (K)._SSign the response as follows:

REPLY^ES= S_KS[REPLY^E]

In operation 526, the host console broadcasts the response over the local area network 302 to other consoles, including the requesting client console 100-2. In operation 528, the client console authenticates and decrypts the response. Every host console responds with its own cryptographic broadcast response, including the network address, as well as the encryption key and identifier unique to the game session. Upon discovering one or more hosts available on the network, the client uses the host's session key pair to communicate with the desired host. Any other session key pair returned by any other potential host will be discarded.

<u style="single">Stage III: Key exchange</u> Figure 6 shows Phase 3 600 of a secure communication protocol in which a client and host perform a secure key exchange to establish a secure point-to-point link for ongoing communication. After game session discovery, the client console and host console share the title broadcast encryption key 412, the title broadcast signature key 414, and the session key vs. NKID / NKEY for a particular game session. The client console and host console then exchange data used to derive one or more keys. This one or more keys will be used for this secure point-to-point communication. In the described implementation, the console uses Diffie-Hellman exponential operations to derive a new secret shared between the two consoles without transmission over the LAN. Key exchanges are protected using session keys.

In this discussion, it is assumed that the client console is the invoking side of the key exchange and the host is the responding side. When the client sends the first packet, the client notifies that there is no established security association between the game client and the game host. The packet is placed on the packet queue and the key exchange process is started.

In operation 602, the client generates the initial key exchange packet KeyExInit. This packet contains the secret used to derive the symmetric key. This symmetric key is used for secure communication over point-to-point communication links. In one exemplary implementation, a key exchange packet is a UDP packet with a payload containing the following data:

<tables num="1"><img file="JP2007190403A_D0001.tif" /></tables>

In operation 604, the client console uses the session key NKEY and the hashing function H to calculate the hash digest of the entire message as follows: HashInit = H_NKEY[NonceInit, g^x, NKID, NADDR, Time]

Therefore, the initial key exchange packet KeyExInit is created by generating a random nonce "NonceInit" and calculating the Diffie-Hellman value "g".^XIncludes padding, NKID and NADDR field padding, and Time field increments and settings. Set all other fields to 0. A hash digest of all preceding fields (HashInit) is placed within the Hash field of the key exchange packet so that the packet can be authenticated by the receiving console (eg, the host console). The obtained packet is as follows.

KeyExInit: [NonceInit, g^X, NKID, NADDR, Time, HashInit]

In operation 606, the client console sends the initial key exchange packet KeyExInit to the host console. Upon receiving this message, the host console uses the key identifier in the NKID field to identify the key NKEY for a particular game session. The session key is then used to authenticate the message as originating from the client console (Operation 608). More specifically, the host uses the session key NKEY to calculate a hash digest of the content and compare that digest with the attached "HashInit" value received in the initial key exchange packet.

In operation 610, the host console creates a response key exchange packet (denoted as "KeyExResp"). In the following example, the host console generates a random nonce "NonceResp" and the Diffie-Hellman function g^YEmbed the value calculated from, embed the NKID and NADDR fields, and increment and set the "Time" field. The "Nonce Init" field is copied from the initial message.

In operation 612, the host console uses the session key NKEY to hash the response packet as follows: HashResp = H_NKEY[NonceInit, NonceResp, g^Y, NKID, NADDR, Time]

The hash digest is placed in the "Hash" field of the key exchange packet. Next, the response packet has the following contents.

KeyExResp: [NonceInit, NonceResp, g^Y, NKID, NADDR, Time, HashResp]

In operation 614, the host console sends the response key exchange packet KeyExResp to the client console. Upon receipt, the client console uses the key identifier in the NKID field to identify the session key NKEY. The session key NKEY is then used to authenticate the message as originating from the host console (operation 616). That is, the client uses the session key NKEY to calculate a hash digest of the response packet and compares that digest with the attached "HashResp" value received in the response packet.

At this point, both the host and the client have sufficient data to calculate the security-related key (Operation 618). Security-related keys are used to secure point-to-point communication between two consoles. In this example, each console uses two Diffie-Hellman indices to function g^XYTo calculate. Each console is then NonceInit, NonceResp, and g^XYCan be used as input and the session key NKEY can be used to calculate four different digests. These digests are used to form security-related keys.

If the client has a security-related key, it can freely send and complete any packet waiting for a key exchange. However, the host console is not free to do so even if it has the same key pair, as it is not certain that its response message KeyExResp was not lost. The host waits until it receives a KeyExAck message or a packet authenticated with the calculated security-related key (Operation 620).

In the general case, the client console sends the packet to the host, so the key exchange process consists of only two messages, KeyExInit and KeyExResp. If the client does not have a packet to send, the client will send a pseudo-acknowledgement message (denoted as "KeyExAck"). This message differs from the other two key exchange messages in that the message is hashed using a calculated security-related key instead of the session key NKEY.

From then on, the two consoles use the security-related key to secure the communication. All network packets that need to be sent to other consoles are optionally encrypted and then authenticated before the receiving console, which verifies the authentication data, decrypts the packet content. After the game session ends, the console may stop accepting key exchange requests from any console that uses this session key vs. NKID / NKEY. The duration of the session key is expected to be minutes to hours.

<u style="single">Conclusion</u> Although the present invention has been described in terms of structural features and / or operations, it should be understood that the invention as defined in the claims is not necessarily limited to the particular features or operations described. Rather, this particular function and operation is disclosed as an exemplary embodiment of the claimed invention.

As described above, according to the present invention, a plurality of game consoles can establish secure communication via a local area network.

<figref num="1">FIG. 5 shows a gaming system with a game console and one or more controllers.</figref><figref num="2">It is a block diagram of a gaming system.</figref><figref num="3">FIG. 5 is a diagram showing a network gaming system in which the gaming system of FIG. 1 is connected to another gaming system via a local area network.</figref><figref num="4">It is a figure which shows the 1st stage of a secure communication process in which a game console which executes an authentic game title generates a shared private key.</figref><figref num="5">It is a figure which shows the 2nd stage of a secure communication process in which a client game console discovers a host game console on a local area network.</figref><figref num="6">It is a figure which shows the 3rd stage of a secure communication process in which a client game console and a host game console establish a point-to-point communication link.</figref>

Code description

100-1 ~ 100-g Gaming System 102 Game Console 104-1 ~ 104-4 Controller 106 Portable Media Drive 108-1 ~ 108-g Optical Storage Disk 110a ~ 110d Slot 112 Power Button 114 Eject Button 120 A / V Interface Cable 122 Power Cable 124 Cable or Modem Connector 130 Serial Cable 132-1, 132-2a, 132-2b Thumbstick 134 D Pad 136 Button 138 Trigger 140-1 ~ 140-8 Memory Unit 200 CPU 202 Memory Controller 204 Flash ROM 206 RAM 208 Hard Disk Drive 210 Level 1 Cache 212 Level 2 Cache 214 Common Module 216 ATA Bus 220 3D Graphics Processor 222 Video Encoder 224 Audio Processor 226 Audio Codec 228 A / V Port 230 USB Host Controller 232 Network Interface 240-1, 240-2 Dual Controller Port Subassembly 242 Front Panel I / O Subassembly 244 Cable Assembly 250 System Power Module 252 Fan 302 Local Area Network 400 Secure Communication Protocol No. 1st stage 402 Private key 404 Title key 406 LAN key generator 408 LAN key 410 Broadcast communication key generator 412 Title Broadcast communication encryption key 414 Title Broadcast communication signature key 500 2nd stage of secure communication protocol 600 3rd stage of secure communication protocol stage