U.S. Pat. No. 7,512,235

DETAILED DESCRIPTION

The following discussion is directed to console-based online gaming systems and techniques for authenticating multiple identities—game console, game title, multiple users—in one authentication roundtrip. The discussion assumes that the reader is familiar with basic cryptography principles, such as encryption, decryption, authentication, hashing, and digital signatures. For a basic introduction to cryptography, the reader is directed to a text written by Bruce Schneier and entitled, “Applied Cryptography: Protocols, Algorithms, and Source Code in C,” published by John Wiley & Sons, copyright 1994 (second edition 1996), which is hereby incorporated by reference.

Gaming System

FIG. 1shows an exemplary gaming system100. It includes a game console102and up to four controllers, as represented by controllers104(1) and104(2). The game console102is equipped with an internal hard disk drive and a portable media drive106that supports various forms of portable storage media as represented by optical storage disc108. Examples of suitable portable storage media include DVD, CD-ROM, game discs, game cartridges, and so forth.

The game console102has four slots110on its front face to support up to four controllers, although the number and arrangement of slots may be modified. A power button112and an eject button114are also positioned on the front face of the game console102. The power button112switches power to the game console and the eject button114alternately opens and closes a tray of the portable media drive106to allow insertion and extraction of the storage disc108.

The game console102connects to a television or other display (not shown) via A/V interfacing cables120. A power cable122provides power to the game console. The game console102may further be configured with broadband capabilities, as represented by the cable or modem connector124to facilitate access to a network, such as the Internet.

Each controller104is coupled to the game console102via a wire or wireless interface. In the illustrated implementation, the controllers are USB (Universal Serial Bus) compatible and are connected to the console102via serial cables130. The controller102may be equipped with any of a wide variety of user interaction mechanisms. As illustrated inFIG. 1, each controller104is equipped with two thumbsticks132(1) and132(2), a D-pad134, buttons136, and two triggers138. These mechanisms are merely representative, and other known gaming mechanisms may be substituted for or added to those shown inFIG. 1.

A memory unit (MU)140may be inserted into the controller104to provide additional and portable storage. Portable memory units enable users to store game parameters and port them for play on other consoles. In the described implementation, each controller is configured to accommodate two memory units140, although more or less than two units may be employed in other implementations.

The gaming system100is capable of playing, for example, games, music, and videos. With the different storage offerings, titles can be played from the hard disk drive or the portable medium108in drive106, from an online source, or from a memory unit140. A sample of what the gaming system100is capable of playing back include:1. Game titles played from CD and DVD discs, from the hard disk drive, or from an online source.2. Digital music played from a CD in the portable media drive106, from a file on the hard disk drive (e.g., Windows Media Audio (WMA) format), or from online streaming sources.3. Digital audio/video played from a DVD disc in the portable media drive106, from a file on the hard disk drive (e.g., Active Streaming Format), or from online streaming sources.

FIG. 2shows functional components of the gaming system100in more detail. The game console102has a central processing unit (CPU)200and a memory controller202that facilitates processor access to various types of memory, including a flash ROM (Read Only Memory)204, a RAM (Random Access Memory)206, a hard disk drive208, and the portable media drive106. The CPU200is equipped with a level 1 cache210and a level 2 cache212to temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput.

The CPU200, memory controller202, and various memory devices are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.

As one suitable implementation, the CPU200, memory controller202, ROM204, and RAM206are integrated onto a common module214. In this implementation, ROM204is configured as a flash ROM that is connected to the memory controller202via a PCI (Peripheral Component Interconnect) bus and a ROM bus (neither of which are shown). RAM206is configured as multiple DDR SDRAM (Double Data Rate Synchronous Dynamic RAM) that are independently controlled by the memory controller202via separate buses (not shown). The hard disk drive208and portable media drive106are connected to the memory controller via the PCI bus and an ATA (AT Attachment) bus216.

A 3D graphics processing unit220and a video encoder222form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit220to the video encoder222via a digital video bus (not shown). An audio processing unit224and an audio codec (coder/decoder)226form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit224and the audio codec226via a communication link (not shown). The video and audio processing pipelines output data to an A/V (audio/video) port228for transmission to the television or other display. In the illustrated implementation, the video and audio processing components220-228are mounted on the module214.

Also implemented on the module214are a USB host controller230and a network interface232. The USB host controller230is coupled to the CPU200and the memory controller202via a bus (e.g., PCI bus) and serves as host for the peripheral controllers104(1)-104(4). The network interface232provides access to a network (e.g., Internet, home network, etc.) and may be any of a wide variety is of various wire or wireless interface components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.

The game console102has two dual controller support subassemblies240(1) and240(2), with each subassembly supporting two game controllers104(1)-104(4). A front panel I/O subassembly242supports the functionality of the power button112and the eject button114, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the game console. The subassemblies240(1),240(2), and242are coupled to the module214via one or more cable assemblies244.

Eight memory units140(1)-140(8) are illustrated as being connectable to the four controllers104(1)-104(4), i.e., two memory units for each controller. Each memory unit140offers additional storage on which games, game parameters, and other data may be stored. When inserted into a controller, the memory unit140can be accessed by the memory controller202.

A system power supply module250provides power to the components of the gaming system100. A fan252cools the circuitry within the game console102.

A console user interface (UI) application260is stored on the hard disk drive208. When the game console is powered on, various portions of the console application260are loaded into RAM206and/or caches210,212and executed on the CPU200. The console application260presents a graphical user interface that provides a consistent user experience when navigating to different media types available on the game console.

The game console102implements a cryptography engine to perform common cryptographic functions, such as encryption, decryption, authentication, digital signing, hashing, and the like. The cryptography engine may be implemented as part of the CPU200, or in software stored on the hard disk drive208that executes on the CPU, so that the CPU is configured to perform the is cryptographic functions.

The gaming system100may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the gaming system100allows one or more players to play games, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface232, the gaming system100may further be operated as a participant in a larger network gaming community. This network gaming environment is described next.

Network Gaming

FIG. 3shows an exemplary network gaming environment300that interconnects multiple gaming systems100(1), . . . ,100(g) via a network302. The network302represents any of a wide variety of data communications networks. It may include public portions (e.g., the Internet) as well as private portions (e.g., a residential Local Area Network (LAN)), as well as combinations of public and private portions. Network302may be implemented using any one or more of a wide variety of conventional communications media including both wired and wireless media. Any of a wide variety of communications protocols can be used to communicate data via network302, including both public and proprietary protocols. Examples of such protocols include TCP/IP, IPX/SPX, NetBEUI, etc.

In addition to gaming systems100, one or more online services304(1), . . . ,304(s) may be accessible via the network302to provide various services for the participants, such as hosting online games, serving downloadable music or video files, hosting gaming competitions, serving streaming audio/video files, and the like. The network gaming environment300may further involve a key distribution center306that plays a role in authenticating individual players and/or gaming systems100to one another as well as online services304. The distribution center306distributes keys and service tickets to valid participants that may then be used to form games amongst multiple players or to purchase services from the online services304.

The network gaming environment300introduces another memory source available to individual gaming systems100—online storage. In addition to the portable storage medium108, the hard disk drive208, and the memory unit(s)140, the gaming system100(1) can also access data files available at remote storage locations via the network302, as exemplified by remote storage308at online service304(s).

Multi-User Authentication

To participate in an online gaming situation, it is desirable for every participant to authenticate themselves to one another. Ideally, the entities that should be authenticated include the users, the game title, the game console, and any online service the might be involved. One approach to authenticating each entity is to employ the well-known Kerberos authentication protocol, which is described in the above referenced Schneier book. With the Kerberos authentication protocol, each user would perform an independent authentication cycle with the key distribution center because Kerberos is only used to authenticate a single user identity at a time. Unfortunately, this results in multiple authentication cycles for the various users, which is undesirable in the gaming context.

To authenticate multiple users, the gaming system implements an authentication process that allows simultaneous authentication of all entities—game console, game title, and multiple users—in one request/reply exchange with the key distribution center. Moreover, a single ticket can be used to prove the particular game console and the multiple user identities playing at the game console. This is very efficient and highly desirable in the gaming context. In the described implementation, the process is a Kerberos-like authentication protocol.

FIG. 4shows three primary participants in the multi-user authentication process: the gaming system100(1), an online service304, and the key distribution center306. The participants are networked together via the network302(not shown inFIG. 4) and are each capable of performing one or more routine cryptographic functions, such as encryption, decryption, one way hashing, random number generation, digital signing, and the like. Although more participants may be involved in the online gaming event, the illustrated participants represent an exemplary set of participants that are involved in the multi-user authentication process.

For discussion purposes, suppose there are four users of the gaming system100(1), as represented by the four controllers104(1)-104(4). Each user is given an identity U1, U2, U3, and U4and is assigned a user key K1, K2, K3, and K4. The game console102is also assigned its own identity X and a game console key KX. (One exemplary approach to assigning the game console identity and key is described below in more detail with reference toFIG. 6.) Additionally, the game title, which is shown here as a game disc108, is assigned a separate identity G. In a similar manner, the online service304is assigned its own identity A and a key KA.

The multi-user authentication process may be understood as a four-step process conducted in two roundtrip communication cycles. The first two steps occur during a single roundtrip request/reply exchange between the gaming system100(1) and the key distribution center306, which is illustrated as paths402and404. The latter two steps occur during a single roundtrip request/reply exchange between the gaming system100(1) and the online service304, which is illustrated as paths406and408. Note that the406request and408response are usually piggy backed on a regular online service request, and thus does not incur an extra round trip. Thus, the full authentication process may be carried out very quickly, with minimal information exchanges between the participants.

During the first request/reply exchange, the gaming system100(1) submits a request asking the key distribution center306to issue a single ticket on behalf of all identities—game console X, game title G, and all four users U1, U2, U3, and U4—for purposes of participating with the online service304(i.e., path402inFIG. 4). The key distribution center306generates and returns a ticket for use with the desired online service (i.e., path404inFIG. 4). In this manner, the key distribution center306functions as a ticket issuing entity that issues tickets for services.

During the second request/reply exchange, the gaming system100(1) submits the ticket to the online service304for authentication (i.e., path406inFIG. 4). The ticket is piggyback information along with the first request for the online service, and does not need to be sent in a separate request or until the service is needed. If valid, the online service304sends back a reply that can be used by the gaming system100(1) to authenticate the online service304(i.e., path408inFIG. 4). If all entities are authenticated, the gaming system100(1) can trust the returned results from the online service and can continue to interact with the online service304.

The process illustrated inFIG. 4is advantageous in that a single ticket obtained from the key distribution center306is used to prove the game console and the multiple user identities playing at the game console. This is much more efficient than the traditional approach where multiple tickets are needed, one for each authenticated principal.

FIG. 5shows the multi-user authentication process500that is implemented by the three participants ofFIG. 4. The process can be implemented in software as computer-executable instructions stored on various storage media at the participants. When executed, the instructions direct the various participants to perform operations illustrated as blocks inFIG. 5. The tasks are illustrated beneath headings “Key Distribution Center”, “Game Console”, and “Online Service” to convey an exemplary location as to which entities are performing them. The multi-user authentication process500will be described with reference to bothFIGS. 4 and 5.

At block502inFIG. 5, the game console102generates validated user identities based on the user identities U1, U2, U3, and U4and user keys K1, K2, K3, and K4. More specifically, the validated user identities include the user identities and values derived from the user keys. The validated user identities will be submitted with the request and used to demonstrate to the key distribution center306that the gaming system has knowledge of the user key and hence, implicitly authenticates the users.

One way to generate the key derivative value is to compute a cryptographic hash of the user key using the key of the game console. For user U1with key K1, a hash H1is computed as follows:
H1=HMACKx(K1)

The hash H1forms the key derivative value. Another way is to encrypt the current time using the user key K1, as follows:
H1=EK1(T)

Once again, the resulting value H1forms the key derivative value. The validated user identity is the combination of the user identity U1and the corresponding key derivative value H1:
Validated User Identity=(U1, H1).

At block504inFIG. 5, the game console102constructs a request containing the game console identity X, the game title identity G, the online service identity A of the service being requested, and multiple validated user identities (U1, H1), (U2, H2), (U3, H3), and (U4, H4). The request has the following identity string:
Request=[X, G, A, (U1, H1), (U2, H2), (U3, H3),(U4, H4)]

If the gaming system wanted authentication for more than online service, the identities of other services B, C, . . . , etc. are added to the request. Additionally, the request may include a version of the authentication protocol and a random nonce generated by the game console to resist replay attacks. The request may further include a checksum value to be used to verify receipt of the entire identity string. The game console102submits the request over the network302to the key distribution center306(i.e., path402).

At block506inFIG. 5, the key distribution center306evaluates the request as well as the identities contained in the request. The distribution center306generates a random session key to be used for each service being requested by the gaming system100(1). In this example, the center306generates a random session key KXAto be used during the second communication cycle involving the game console102and the online service304. If other services are requested, additional random session keys KXB, KXC, . . . , etc. are produced.

At block508inFIG. 5, the key distribution center306generates a ticket that will subsequently be presented to the requested online service. There is one ticket issued for each service requested, but each ticket is effective for multiple9users. The ticket contains the identity string submitted in the request. It also includes a time TGthat the ticket is generated, a time TLidentifying the time length before expiration of the ticket, and the randomly generated session key KXAfor the service requested. The ticket contents are encrypted via a symmetric key cipher (e.g., DES) that utilizes the online service's key KA, as follows:
TicketA=EKA[TG, TL, KXA, X, G, A, U1, U2, U3, U4]

Notice that the ticket does not carry the corresponding key derivative values Hi. Once the authentication server reads the key derivative values and believes the game console knows the user keys, the authentication server places the identities of the users within the issued tickets. Individual online services will subsequently believe in whatever the ticket tells it and hence do not need to see the key derivative values Hi.

If the gaming system sought tickets for more than one service, the key distribution center306issues multiple tickets, each ticket being encrypted with the public key of the desired online service, as follows:
TicketB=EKB[TG, TL, KXB, X, G, B, U1, U2, U3, U4]
TicketC=EKC[TG, TL, KXC, X, G, C, U1, U2, U3, U4]
:
TicketN=EKN[TG, TL, KXN, X, G, N, U1, U2, U3, U4]

At block510inFIG. 5, the key distribution center306returns each ticket over the network302to the gaming system100(1) (i.e., path404). Since the game console102does not know the online service's key KA, the game console102cannot open the ticket and alter the contents. The key distribution center also returns the session keys in an attached encrypted message. The session key message contains the ticket generation time TG, the ticket expiration length TL, and one or more session keys KXA, KXB, KXC, etc., and all contents are encrypted using the game console's key KX, as follows:
Session Key Message=EKX[TG, TL, KXA, KXB, KXC, . . . ]

Since the session key message is encrypted with the game console's key KX, the game console102is able to open the session key message and recover the session time parameters and session keys.

At block512inFIG. 5, the game console102passes the ticket, as is, onto the online service304(i.e., path406). The game console102also generates and sends the current time T (instead of its own ID) encrypted with the random session key KXA, as follows:
Time Message=EKXA[T]

At block514inFIG. 5, the online service304evaluates the authenticity of the ticket. It decrypts the ticket using its key KAto recover the contents, as follows:
DKA[TicketA] TG, TL, KA, X, G, A, U1, U2, U3, U4

The decrypted contents include the session key KXA. The online service then uses the session key KXAto decrypt the time message and recover the time T, as follows:
DKXA[Time Message]=T

The online service304compares the recovered time sent from the game console with the current time. If the recovered time is not within an allowable time horizon from the current time, the online service deems the game console102as not authentic and the ticket as a forgery. In this case (i.e., the “No” branch from block516), the online service denies service to the game console.

On the other hand, if the recovered time is within an allowable time window from the current time, the online service is assured that the game console102is authentic. In this case (i.e., the “Yes” branch from block516), the online service generates a reply containing the time T in the request Time Message, encrypted with the session key KXA, as follows:
Reply=EKXA[T]

At block518, the online service304returns the reply over the network302to the gaming system100(1) (i.e., path408). Once again, this reply is piggybacked on a regular online service reply and does not incur an extra communication trip.

At block520inFIG. 5, the game console102evaluates the authenticity of the reply. The game console102decrypts the reply using the session key KXAthat it previously received in the session key message from the key distribution center306. If the game console102can successfully decrypt the reply, and the T value is the same as the T value originally sent in the Time Message, the game console is assured that the online service is authentic because the online service could not otherwise have known the random session key KXA. In this case (i.e., the “Yes” branch from block522), the game console is free to interact with the services offered by the online service (block524). Otherwise, if the reply cannot be decrypted successfully (i.e., the “No” branch from block522), the game console deems the online service as not authentic and forgoes its services.

The multi-user authentication process is built a top the three-participant model in the Kerberos authentication process. It differs from Kerberos in that it allows authentication of multiple users simultaneously, with one trip to the key distribution center and one ticket for all users. The extension involved, in part, defining new message strings to be passed among the participants.

An alternative implementation is to leverage the existing well-defined data packets employed in the conventional Kerberos protocol. Kerberos defines a packet that includes a data field known as the “Pre-Auth” data field for pre-authorized data. In the alternate implementation, the multiple validated user identities (U1, H1), (U2, H2), (U3, H3), and (U4, H4) are inserted into this “Pre-Auth” data field so that all users are authenticated in the same request. Also the Kerberos tickets issued would be modified to contain extra “Authorization Data” that contains the user identities that have been authenticated (U1, U2, U3, U4).

Establishing Game Console Identity and Key

The above multi-user authentication protocol hinges in part on the ability to establish the game console identity X and associated game console key KX. This section describes how these parameters are created in the first place.

Generally, each game console102is manufactured with secret information that is very difficult to guess and very difficult to access. Tamper resistant designs are employed to physically protect the secret information on the game console from attacks on the hardware. The secret information is stored at a backend server is for use later at account creation time to verify whether the game console is authentic. The secret information may be the same for all or a batch of consoles, or unique for each console. Preferably, the secret information is unique so that if the information is compromised, only a single fake account can be created.

The establishment of a secure game console identity relies on the fact that console manufacturing is a regulated process and that all consoles have consistent characteristics, regardless of the manufacturing date. It also relies on the fact that because manufacturing is controlled by one or a limited number of entities, a robust and secure database of the secret information unique to each machine can be generated and used on the backend to verify that a particular game console is, in fact, a real console at the time a game console account is being created.

FIG. 6illustrates a process600for constructing a game console with secret information for use in establishing a console identity X and game console key KX. The process600is performed in part during manufacturing and in part during account creation in which an online gaming account for the game console is created. These two phases are distinguished inFIG. 6by a horizontal dashed line. The tasks are illustrated beneath headings “Manufacturing”, “Authentication Server” and “Game Console” to convey exemplary locations as to where the tasks are performed.

At block602, the manufacturer constructs the game console to incorporate one or more pieces of information at the time of manufacture. The information is preferably of the type that can be made available programmatically. In one implementation, the game console is built to include at least two pieces of information, one that is unique to the individual machine and a second that is very difficult to guess and access. The first piece of information need not be evenly distributed across a name space, nor does it need to be secret or hard to read, but it does need to be unique across the name space and accessible programmatically. For example, the first piece of information could be a console serial number is assigned by the manufacturer, a hard disk ID printed on the hard disk drive, or a serial number of any chip, ROM, firmware, or the like. This first piece of information will be used as the “name” of the game console to look up which row in table650corresponds to the particular game console.

The second piece of information does not necessarily need to be unique per machine, but is evenly distributed across its namespace. It is very difficult to guess and very difficult to access. Programmatic access is permitted via secure techniques, such as code-signing techniques, but physical access is controlled via hardware-based solutions that resist tampering and render physical attack and reverse engineering very difficult. Examples of the second piece of information include a CPU ID or a value derived from the CPU ID, such as a one-way hash of the CPU ID. Another example is a random key written onto disk at manufacturing time, the disk drive needs to be protected from unauthorized reading (like using the CPU ID) through some other means. This second piece of information will be used as the “key” for the game console, to prove that the game console is genuine and not some other computing device pretending to be a game console.

At block604, the information is recorded in a database at the manufacturer as a set of database records650. Each record includes, for example, an identity of the console, the hard disk ID (HDID), and the CPU ID. At block606, the database records650are securely made available to an authentication server that may or may not be hosted by the key distribution center306. In one implementation, a secure database replication procedure is employed to securely transfer the console information database to the authentication server. It is further noted that the same entity may or may not control the manufacturing and authentication server.

At this point, the two pieces of information can be used in the verificafion is of the game console and creation of the game console identity X and key KX. Such information can be used to verify, for example, that the game console is valid and not an impersonating personal computer.

This completes the manufacturing phase of process600. The game consoles are subsequently released from manufacturing and sold to consumers. When the user first decides to play an online game or access online services, the game console first obtains an account. This initiates the account creation phase of the process600inFIG. 6.

At block610, the game console submits the information, or data derived from the information, to the authentication server. The information could be sent over a secure link (e.g., SSL) established between the game console and the authentication server. In one implementation, the game console submits the hard disk ID and the CPU ID assuming a secure connection is established, such as using SSL to protect the contents of the message. To avoid exposing the CPU ID, another implementation is to submit in place of the CPU ID, a one-way hash digest of the CPU ID in such a way that it is extremely difficult to deduce the CPU ID from the resulting value. Another way to prove knowledge of the CPU ID and to also prevent replay attacks is to send ECPUID(T) where the current time is encrypted with the CPU ID as the Key.

At block612, the authentication server evaluates the information from the game console. In one implementation, the authentication server uses the information as an index into the console database records650to identify that the information is a correct combination of pieces. For instance, the authentication server determines whether the hard disk ID and CPU ID passed in from the game console form a correct pair recorded in the database as belonging to the same is game console. If there is a match, the authentication server can be assured that the client is a valid game console because it would be very difficult for an impostor to guess, manually or programmatically, both pieces of information and their relationship.

At block614, the authentication server looks up in the console database records to determine whether an account has already been established for this information. If no account exists (i.e., the “No” branch from block614), the authentication server creates an account and assigns a unique game console identity X and a randomly generated key KXto that account (block616). If an account exists (i.e., the “Yes” branch from block614), the authentication server retrieves the existing account information (block618). The game console identity X and key KXare returned to the game console (block620).

At block622, the game console stores the game console identity X and key KXin a secure way to resist hardware attacks. It also sends back a message containing the identity X and the identity encrypted with the key KX, or EKX(X). Having the game console return a message allows the authentication server to ascertain whether the game console correctly received the account data. If the decrypted identity matches the non-encrypted identity, the game console received the account data correctly. If the two do not match, the game console received incorrect data and the authentication server should delete the account and restart the process at block610. If no reply is received from the game console, the authentication server cannot be sure if the account data successfully made it to the game console. In this case, the authentication server flags the account and waits for another new account creation for this game console (signifying that the game console did not receive the account data) or a successful logon (indicating that the game console did receive the account data).

At game time, the actual security of the console machine is achieved via the identity X and key KX, as described previously in the multi-user authentication process.

CONCLUSION

The above processes are advantageous for many reasons. First, the multi-user authentication process is fast because it accomplishes all authentication for the gaming system, including multiple users, the game title, and the machine itself, in a single roundtrip communication with the key distribution center. After this initial roundtrip, the game console is able to communicate with any trusted services without re-communicating with the key distribution center. The whole process is accomplished with minimal user input and minimal delay before play can begin. The single ticket obtained from the authentication server is also unique in that it not only proves the particular game console, but also the multiple user identities playing at the game console. This is in contrast to the traditional approach where multiple tickets would need to be used (one for each authenticated principal).

Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described, Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.