Architecture for manufacturing authenticatable gaming systems

[0001] [Technical field to which the invention belongs] The present invention relates to console-based game systems, and more particularly to systems and methods for manufacturing game consoles that can be authenticated for participation in online services such as online games. [0002] [Conventional technology] Traditionally, game systems with dedicated consoles have been stand-alone machines that can accommodate a limited number of players (eg, four). PC-based games have become widespread, to some extent due to the ability to play games online with a large number of remote players over networks (eg, the Internet). Therefore, one trend of dedicated game systems is to provide broadband functions that facilitate online games. [0003] Creating an online gaming architecture for a dedicated console has some inherent and difficult problems. One problem is that there are some hackers who constantly try to cheat during online games to gain various gaming benefits. To prevent this fraud, various security schemes have been deployed to protect data being transmitted over the network from hacker observations and / or alterations. However, such schemes require the game console to authenticate itself to remote entities (eg, online game servers, registration servers, other player systems, etc.). Valid proofs are used during authentication to ensure the authenticity of network traffic during the game. If it is possible to easily obtain these certifications during registration, the hacker can easily manipulate the certifications and use another computer to forge all network packets from the video game console. Can be done. From the game server's point of view, the game packet appears to be genuine because it comes from a network source that could provide the required proof. [0004] [Problems to be Solved by the Invention] Therefore, to secure online games and other services, we prevent hackers from easily obtaining valid proof for fraudulent or other improper use purposes. There is a need. [0005] [Means for solving problems] The architecture for manufacturing console-based game systems is to place off-the-shelf secrets on the game console during manufacturing and later use the secrets to ensure the authenticity of the game console during registration. Get involved. [0006] The following two typical embodiments will be described. Symmetric key architecture and public key architecture. The symmetric key architecture involves writing a randomly generated symmetric key, along with the console ID, into non-volatile memory accessible to the game console's programmatic formula during manufacturing. The symmetric key is encrypted using the public key during the transport. The corresponding private key and encrypted symmetric key are kept secure and secure in the authentication entity. [0007] During registration, the game console submits this key (or proof of key knowledge) to the console ID pair to the authenticating entity. This pair acts as a password / name pair that seeks out the corresponding symmetric key that is maintained in the authentication entity. The symmetric key is then decrypted using the private key. The key issued by the game console is verified against the recovered symmetric key as a way to determine if the console is genuine. [0008] The public key architecture involves writing private keys and digital certificates within each game console during manufacturing. This certificate contains the public key that corresponds to the private key. This certificate is part of a certificate chain that includes the certification authority certificate associated with the certification authority at each manufacturing site and the root certificate from which the certification authority certificate is derived. Whenever a game console comes online for registration, the certificate chain verification process is responsible for the knowledge of the private key stored on the game console, even though the console authenticates as authentic. Used with evidence. [0009] BEST MODE FOR CARRYING OUT THE INVENTION The following description describes such game systems in a way that allows them to be authenticated by a console-based game system with online connectivity, and a remote authentication entity over an open network such as the Internet. Targets techniques for manufacturing. This technique addresses the question of how an authenticating entity can obtain a guarantee that the entity on the other side of the network is an authorized gaming system. [0010] This description assumes that the reader is familiar with basic cryptographic principles such as encryption, decryption, authentication, hashes, digital signatures, and digital certificates. For a basic overview of cryptography, readers should refer to the text (eg, "Applied Cryptography: Protocols, Algorithms, and Source Code in C" by Bruce Schneier (published by John Wiley & Sons, copyright 1994 (second)). See the text named edition 1996))). This text is incorporated herein by reference. [0011] Game system FIG. 1 shows a game system 100 as an example. The game system includes a game console 102 and up to four controllers as shown in controllers 104 (1) and 104 (2). The game console 102 includes an internal hard disk drive and a portable media drive 106 that supports the various forms of portable storage media shown in Optical Storage Disk 108. Examples of suitable portable storage media include DVDs, CD-ROMs, game discs, game cartridges, and others. [0012] The game console 102 has four slots 110 on its front that support up to four controllers, but the number and configuration of slots can be changed. The power button 112 and eject button 114 are also located on the front of the game console 102. The power button 112 switches the power of the game console, and the eject button 114 alternately opens and closes the tray of the portable media drive 106 to allow the storage disk 108 to be inserted and removed. [0013] 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 can also be further configured to include the broadband features indicated by cable or modem connectors 124 that facilitate access to networks such as the Internet. [0014] Each controller 104 is coupled to the game console 102 via a wired or wireless interface. In the illustrated embodiment, the controller is USB (Universal Serial Bus) compliant and is connected to the console 102 via a serial cable 130. The console 102 can have a wide variety of user interaction mechanisms. As shown in FIG. 1, each controller 104 includes two thumbsticks 132 (1) and 132 (2), a D pad 134, a button 136, and two triggers 138. The above mechanisms are merely representative, and other well-known game mechanisms can be substituted or added to those shown in FIG. [0015] A memory unit (MU) 140 can be inserted into the controller 104 to provide additional portable storage. The portable memory unit allows the user to store and carry game parameters for playing games on other consoles. In the embodiments described, each controller is configured to accommodate two memory units 140, but in other embodiments, more or less than two units can be used. [0016] The game system 100 can play, for example, games, music, and videos. A variety of storage is provided and titles can be played from the hard disk drive, or portable media 108 in drive 106, from online sources, or from memory unit 140. The following are examples of what the game system 100 can play. [0017] 1. Game titles played from CD and DVD discs, from optical disc drives, or from online sources. 2. Digital music played from a CD in Portable Media Drive 106, from a file on your hard disk drive (eg, Windows® Media Audio (WMA) format), or from an online stream source. 3. Digital audio / video played from a DVD disc in Portable Media Drive 106, from a file on your hard disk drive (for example, in Active Streaming format), or from an online stream source. [0018] FIG. 2 shows in more detail the functional components of the game system 100. The game console 102 has processor access to 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 facilitates the operation. The CPU 200 includes a Level 1 cache 210 and a Level 2 cache 212 that temporarily store data and thus reduce the number of memory access cycles, thereby increasing processing speed and throughput. [0019] The CPU 200, memory controller 202, and various memory devices use any of the various bus architectures, including serial buses, parallel buses, memory buses, peripheral buses, and one or more buses, including processor or local buses. It is interconnected via. As an example, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, and Video Electronics Standards Association (Video). It can include the Electronics Standards Association (VESA) local bus and the Peripheral Component Interconnects (PCI) bus. [0020] As one suitable embodiment, the CPU 20, memory controller 202, ROM 204, and RAM 206 can be incorporated on the common module 214. In this embodiment, the ROM 204 is configured as a flash ROM connected to the memory controller 202 via a PCI (Peripheral Component Interconnect) bus and a ROM bus (neither shown). The RAM 206 is configured as a plurality of DDR SDRAMs (Double Data Rate Synchronous Dynamic RAM) independently controlled by the memory controller 202 via a separate bus (not shown). Hard disk drive 208 and portable media drive 106 are connected to the memory controller via the PCI bus and ATA (AT Attachment) bus 216. [0021] [0021] The 3D graphics processing device 220 and the video encoder 222 form a video processing pipeline for high-speed and high-resolution graphics processing. Data is transported from the graphics processing device 220 to the video encoder 222 via a digital video bus (not shown). The audio processor 224 and the audio CODEC (encoder / decoder) 226 form the corresponding audio processing pipeline with high fidelity stereo processing. Audio data is carried between the audio processor 224 and the audio CODEC 226 via a communication link (not shown). Video processing pipelines and audio processing pipelines output data to A / V (audio / video) port 228 for transmission to televisions or other displays. In the illustrated embodiment, video processing components and audio processing components 220-228 are mounted on module 214. [0022] A USB host controller 230 and a network interface 232 are also mounted on the module 214. The USB host controller 230 is coupled to the CPU 200 and the memory controller 202 via a bus (eg, the PCI bus) and acts as a host for the peripheral controllers 104 (1) -104 (4). Network interface 232 provides access to networks (eg, the Internet, home networks, etc.) and a wide variety of wired or wireless interface components, including Ethernet® cards, modems, Bluetooth modules, cable modems, etc. It is possible that [0023] The game console 102 has two dual controller support subassemblies 204 (1) and 204 (2), each supporting two game controllers 104 (1) -104 (4). The front panel I / O subassembly 242 supports the functionality of the power button 112 and eject button 114, and also supports any LED (light emitting diode) or other indicator exposed on 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. [0024] In the figure, eight memory units 140 (1) -140 (8) can be connected to four controllers 104 (1) -104 (4), that is, two memory units for each controller. Each memory unit 140 provides additional storage that can store games, game parameters, and other data. When inserted into the controller, the memory unit 140 can be accessed by the memory controller 202. [0025] The system power supply module 250 powers the components of the game system 100. Fan 252 cools the circuit inside game console 102. [0026] The console user interface (UI) application 260 is stored on the 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 caches 210, 212 and run on CPU 200. The console application 260 provides a graphical user interface that provides a consistent user experience when navigating to the different media types available on the game console. [0027] The game console 102 implements an encryption engine that performs common encryption functions such as encryption, decryption, authentication, digital signatures, and hashes. The encryption engine can be implemented as part of the CPU 200 or as software stored on the hard disk drive 208 running on the CPU and configured to perform the encryption function on the CPU. is there. [0028] The game system 100 can be operated as a stand-alone system by simply connecting the system to a television or other display. In this stand-alone mode, the game system 100 allows one or more players to play games, watch movies, or listen to music. However, when broadband connectivity becomes available via network interface 232, the gaming system 100 can be further operated as a participant in the wider network gaming community. Next, this network game environment will be described. [0029] Network game FIG. 3 shows a network game environment 300 as an example of interconnecting a plurality of game systems 100 (1), ... 100 (g) via a network 302. Network 302 represents any of a wide variety of data communication networks. The network 302 can include a public part (eg, the Internet) and a private part (eg, a residential local area network (LAN)), as well as a combination of the public part and the private part. The network 302 can be implemented using any one or more of a wide variety of conventional communication media, including both wired and wireless media. Data can be communicated over network 302 using any of a wide variety of communication protocols, including both public and proprietary protocols. Examples of such protocols include TCP / IP, IPX / SPX, NetBEUI and the like. [0030] In addition to the game system 100, one or more data centers are accessible via network 302 and can provide a variety of services to participants. An example data center 304 hosts an authentication server 306 that registers individual game systems 100, hosts online games, provides downloadable music or video files, and provides streaming audio / video files. It is illustrated as including one or more online servers 308 (1), ... 308 (s) that provide various services such as. Authentication server 306 has access to database 310, which stores manufacturing secrets placed on individual game systems during manufacturing. These secrets are used to register or authenticate the gaming system prior to allowing the gaming system to participate in online games or other services. [0031] Authentication server 306, online server 308, and database 310 are logically grouped to form a data center 304, but various computer systems are physically co-located or similar equipment. Note that it may or may not be part of. Further, in the figure, the authentication server 306 is separate from the online server 308, but it is possible to include the authentication functionality as part of the service. [0032] The network gaming environment 300 can further involve a key distribution center 312 that plays a role in authenticating individual players and / or game systems 100 to each other and to online service 304. The distribution center 312 distributes keys and service tickets to valid participants, who then use the keys and tickets to configure a game among multiple players, or service from online service 308. It is possible to purchase. The distribution center 312 can be integrated into the data center 304 or exist independently as shown. [0033] To participate in an online game (or other network service), the game system 100 first requires that it be authenticated by the authentication server 306. To grant permission to participate in online services, Authentication Server 306 needs to trust that each gaming system is genuine and not an inappropriate computer device. The true game system 100 is manufactured with secrets stored in database 310. Authentication server 306 uses these secrets to identify whether the game system 100 is authentic. The next section describes techniques for manufacturing game systems that can be authenticated for online games over open networks such as the Internet. [0034] Once authenticated, the gaming system can participate in online games or other services, or use the key distribution center to authenticate individual users. The multi-user authentication architecture is described in more detail (see, for example, the US patent application entitled "Multiple User Authentication for Online Console-Based Gaming" filed March 9, 2001, serial number 09/802795). This application is assigned to Microsoft® Corporation and is incorporated herein by reference. [0035] Manufacture an authenticateable game system Provides an architecture for manufacturing gaming systems that address console authentication issues. Simply put, the question is how an authenticating entity can be assured that the entity on the other side of the network is a true game console. The architecture generally involves storing secrets that are authenticateable data on the game console during manufacturing and maintaining the corresponding validation data in the authentication entity. During registration, the authenticating entity uses the validation data to validate the authenticable data issued by the game console to determine the authenticity of the game console. The following two typical architectures will be described. (1) symmetric key architecture, and (2) public key architecture. [0036] Symmetric key architecture The symmetric key architecture involves writing a randomly generated symmetric key along with the console ID on the game console during manufacturing. Later, this key / ID pair acts as a password / name pair that proves to the authentication server that the game console is authentic during registration. The architecture will be described with reference to Figure 4, which shows the manufacturing process, and Figure 5, which shows the registration process. [0037] FIG. 4 shows the manufacturing process 400 as an example where the symmetric key and console ID are placed on the game console during manufacturing. For illustration purposes, the manufacturer shall operate one or more manufacturing facilities, each containing one or more manufacturing computer systems 450 and manufacturing database 452. The manufacturing database is sometimes referred to as the "lineage database". The manufacturing computer system 450 is used to program, configure, or otherwise enable the software / firmware deployed on the game console. [0038] In step 402, the unique identifier Ni is assigned to each manufactured console 102 (i). The console ID can be, for example, a serial number or serial number of the manufactured console. In step 404, a symmetric key Ki is randomly generated for console 102 (i). In step 406, the symmetric key Ki and the console identifier Ni are stored in a non-volatile memory accessible to the programmatic expression of console 102 (i). The location of memory is preferably secure and / or secret from access by the game console owner, but otherwise programmatically accessible by an authorized game console. Possible locations include, but are not limited to, EEPROMs, hard drives, or flash ROMs. You can also cryptographically protect your Ki / Ni pair to further prevent access by game console owners. [0039] Ki / Ni pairs are used during the registration process to prove the authenticity of the game console. Therefore, Ki / Ni pairs are collected during manufacturing for transfer to the data center 304, which is responsible for registering the game console. However, key / identity pair transfer and storage introduces the risk of being discovered. To ensure the security of the symmetric key for storage and transfer, the symmetric key is encrypted using the transfer public key Kt_pub immediately after the symmetric key Ki is generated and stored in the game console (step 408). .. The corresponding transfer private key Kt_prv, which is used to decrypt and access the symmetric key Ki, is kept secure in data center 304 and is only accessed when used during game console registration. .. [0040] Note that one or more of steps 404-408 can be performed by the manufacturing computer system 450 or by the game console itself. Regardless of where the key Ki is generated and encrypted, the goal is to minimize the amount of time this key exists in its raw state. Minimizing this time further enhances security. [0041] It should be further noted that the symmetric key Ki can be encrypted using cryptographic cryptography other than public key cryptography. For example, symmetric key cryptography can be used to encrypt symmetric key Ki that is securely maintained in manufacturers and data centers. [0042] In step 410, the encrypted symmetric key (indicated by E (Kt_pub, Ki)) is stored in the manufacturer database 452 along with the console identifier Ni. In step 412, the console identifier Ni and the encrypted symmetric key (E (Kt_pub, Ki)) for all manufactured consoles are transferred from the manufacturer database 452 to the data center 304 individually or in bulk. Information can be transferred according to electronic transmission over a network, secure transportation on a portable storage medium, or any number of different techniques by other means. [0043] At this point, the game console is discontinued and packed for distribution and sale. After the game console is purchased, it is possible for the owner to wish to play a game or participate in an online service such as downloading an audio / video file. When the game console first encounters an online service, it goes through a registration process to prove its authenticity to the online service. For illustration purposes, it is assumed that the game console will be able to register with authentication server 306 in data center 304 to participate in online game events hosted by one or more online servers 308. [0044] FIG. 5 shows the registration process 500 as an example in which the authentication server 306 in the data center 304 authenticates the game console 102 (i). In step 502, console 102 (i) issues a symmetric key (or proof of key knowledge) and console ID pair (eg, Ki, Ni) to authentication server 306 in data center 304 as part of the authentication protocol. .. The symmetric key Ki is usually somehow protected during the authentication protocol, while the console identifier Ni does not need to be protected. Many different authentication protocols can be used during this process, including Kerberos, Digest, and HTTP Basic. All communication over the network can optionally be secured within a secure channel (eg, an SSL channel). [0045] In step 504, the authentication server 306 uses the console identifier Ni to look up the relevant symmetric key in the manufacturer's secret database 310. The result of this lookup is data record 520 for console 102 (i). The data record 520 contains an encrypted symmetric key (E (Kt_pub, Ki)) originally created and transferred by the manufacturer in the manufacturing process 400 of FIG. 4. In step 506, the authentication server 306 The transfer private key Kt_prv stored in the authentication server 306 is used to decrypt the symmetric key to recover the symmetric key Ki. [0046] In step 508, authentication server 306 assigns, in part, the issued key Ki (or evidence of key knowledge) by the manufacturer recovered from record 520 in the manufacturer's secret database 310. The proof issued by the game console 102 (i) is verified by comparing it with the symmetric key Ki. The authentication server accepts or rejects the game console based on whether the authentication succeeds or fails, and this success or failure is based, at least in part, on whether the two keys match. [0047] At this point, the results of the authentication can be used to directly allow / deny participation in the online service. In this case, a symmetric key is used each time the game console requests authentication to join an online service. Alternatively, the result of the authentication can be used to bootstrap a new set of certificates that will be generated and transferred to the game console for later use during online service authentication. In this second case, the Ki / Ni pair is used only once for authentication during game console registration, and the registration process consoles a new set of proofs that can be used thereafter. Return to. [0048] The advantage of the symmetric key architecture is that no confidentiality is maintained at the manufacturer. Secret Transfer The private key is retained in the data center. Therefore, the chances of a fraudster stealing a secret are greatly reduced. [0049] Public key architecture The public key architecture involves writing private keys and digital certificates to each game console during manufacturing. The certificate contains a public key that matches the private key. The certificate is signed by a certification authority located at each manufacturing site. Each certification authority certificate is further signed by another certificate that follows the certificate chain and eventually leads to the root certificate. Whenever a game console comes online and registers itself, the certificate chain verification process and evidence of private key knowledge are used to authenticate the console as authentic. The public key architecture is described with reference to FIG. 6, which shows the pre-manufacturing process, FIG. 7 which shows the manufacturing process, and FIG. 8 which shows the registration process. [0050] Figure 6 shows the pre-manufacturing process 600 as an example of generating public key pair and chained certificates. Process 600 can be performed at any time before the game console 102 is manufactured. This process can be done in the manufacturing facility or elsewhere. In step 602, a root public key pair consisting of the root public key Kroot_pub and the root private key Kroot_prv is generated. This root key pair is trusted and securely stored. [0051] In step 604, the root key pair is used to generate the root certificate CERT (Kroot_prv, Kroot_pub). The notation "CERT (Kroot_prv, Kroot_pub)" digitally signs the composition of the root public key Kroot_pub and the objective statement, which guarantees the authenticity of the root public key to anyone who knows the corresponding root private key. Means the root private key Kroot_prv used for. Therefore, anyone with access to the root public key Kroot_pub should be able to verify the authenticity of the certificate. One type of certificate is an X.509 format certificate. However, other types of data structures that carry a public key signed with another private key can also be considered a certificate. [0052] In step 606, a second public key pair is generated for use by a certificate authority (CA) at the manufacturing site. This second key pair is called the certificate authority key pair (or CA key pair) and consists of the CA public key Kca_pub and the CA private key Kca_prv. If there are multiple certification authorities at each manufacturing site, different CA key pairs are generated for each certification authority. Therefore, each manufacturing site is associated with one or more CA key pairs. [0053] In step 608, a CA certificate for the certificate authority is generated and signed with the root private key Kroot_prv. The CA certificate is shown as CERT (Kroot_prv, Kca_pub), which digitally signs the synthesis of the CA public key Kca_pub and the objective statement that guarantees the authenticity of the CA public key to any entity that knows the CA private key. This means that the root private key Kroot_prv will be used to do this. [0054] In step 610, the CA certificate CERT (Kroot_prv, Kca_pub) and the CA private key are stored in the certificate authority 650 at the manufacturing site. The CA certificate and CA private key Kca_prv are maintained in a secure manner to prevent leakage. In step 612, the root public key Kroot_pub and / or the root certificate CERT (Kroot_prv, Kroot_pub) is transferred to data center 304 (if generated remotely) and stored in a secure and secure manner. [0055] Figure 7 shows the manufacturing process 700 as an example of a private key and one or more certificates being placed on the game console during manufacturing. For manufacturing, the manufacturer maintains a CA public key pair (Kca_pub, Kca_prv) and a CA certificate CERT (Kroot_prv, Kca_pub). [0056] In step 702, a game console public key pair is generated for each manufactured console 102 (i). The console public key pair consists of the console public key Ki_pub and the console private key Ki_prv. In step 704, a console certificate CERT (Kca_prv, Ki_pub) is generated and signed with the CA private key Kca_prv of the certification authority at the factory. This console certificate contains the public key Ki_pub and guarantees the authenticity of the console to any entity that knows the console private key Ki_prv. [0057] In step 706, the manufacturer records the console private key Ki_prv, the console certificate CERT (Kca_prv, Ki_pub), and the CA certificate CERT (Kroot_prv, Kca_pub) in the game console. The storage location ensures that keys and certificates are programmatically accessible by authorized game consoles, but secure from access by game console owners. Possible locations include, but are not limited to, EEPROMs, hard drives, or flashable ROMs. The CA private key Kca_prv is secured at the manufacturing site, but all other information, including public keys and certificates, can be freely distributed without security measures. [0058] [0058] FIG. 8 shows the registration process 800 as an example where the game console is authenticated by the authentication server 306 in the data center 304. The registration process can be performed using a number of different public key authentication protocols. Upon registration, authentication server 306 accesses the root certificate (and therefore the root public key). [0059] In step 802, as part of the appropriate protocol, console 102 (i) sends the console certificate CERT (Kca_prv, Ki_pub) to authentication server 306 in the data center 304. The console can optionally send the CA certificate CERT (Kroot_prv, Kca_pub) if the certificate server does not already own the CA certificate CERT (Kroot_prv, Kca_pub). The console also issues some evidence that it knows the console private key Ki_prv. This evidence can be obtained in many ways. One technique for providing such evidence is to use the console private key Ki_prv to encrypt some data. This data can be, for example, a current time, a random number, a message, or the like. In the following description, it is assumed that the console encrypts the current time using the console private key, that is, E (Ki_prv, CurrentTime). Using the current time may help thwart replay attacks. [0060] The authentication server 306 then performs a certificate chain authentication process to traverse the certificate chain to the console certificate. More specifically, in step 804, the certificate server 306 authenticates the CA certificate CERT (Kroot_prv, Kca_pub) by verifying the signature of the CA certificate using the public key Kroot_pub. The root public key can be stored in the authentication server or extracted from the root certificate CERT (Kroot_prv, Kroot_pub). In step 806, the certificate server 306 obtains the CA public key Kca_pub from the CA certificate and uses it to verify the signature of the console certificate CERT (Kca_prv, Ki_pub), thereby obtaining the console certificate. Certify. [0061] In step 808, authentication server 306 uses the console public key Ki_pub retrieved from the console certificate to evaluate evidence of knowledge of the console private key Ki_prv. If the authentication server 306 can verify through the issued evidence that the console has knowledge of the correct console private key, then the game console 102 (i) is trusted as authentic. Using Current Time In this example, the authentication server uses the console public key to decrypt the encrypted current time issued by the console. The recovered current time is verified to be within an acceptable time skew. The game server accepts or rejects the game console based on whether the authentication succeeds or fails, and this success or failure is at least partly whether the recovered time is within the time skew. Based on. [0062] At this point, the results of the authentication can be used to directly allow / deny participation in the online service. In this case, the same registration process is used each time the game console requests authentication for the purpose of joining an online service. Alternatively, the result of the authentication can be used to bootstrap a new set of certificates that will be generated and transferred to the game console for later use during online service authentication. In this second case, the console private key Ki_prv, the console certificate CERT (Kca_prv, Ki_pub), and the CA certificate CERT (Kroot_prv, Kca_pub) proof are used only once for authentication during registration. The registration process then returns a new set of certificates that can be used to the console. [0063] Note that the public key architecture described herein uses two levels of certificate chaining, from root certificates to console certificates. It is also possible to implement this architecture with more or less levels of certificate chaining. [0064] The advantage of the public key architecture is that no key is transferred between the console manufacturing site and the authentication server in the data center. However, the public key architecture remains confidential to the manufacturer. [0065] Conclusion Although the present invention has been described in terms specific to structural features and / or methodical treatments, the invention as defined in the claims of the heading does not necessarily relate to the particular features and treatments described. Please understand that it is not limited. Rather, specific features and specific treatments are disclosed as an exemplary embodiment of the claimed invention. [Simple explanation of drawings] FIG. 1 shows a game system with a game console and one or more controllers. FIG. 2 is a block diagram showing a game system. FIG. 3 illustrates a network game system in which the game system of FIG. 1 is connected to other consoles, services, and ticketing entities via a network. FIG. 4 shows a manufacturing process in which a symmetric key and console ID are placed on a game console during manufacturing. FIG. 5 shows a registration process in which an authentication server authenticates a game console using a symmetric key and a console ID. FIG. 6 illustrates the pre-manufacturing process in which public key pairs and chained certificates are first generated. FIG. 7 illustrates a manufacturing process in which a private key and one or more certificates are placed on a game console during manufacturing. FIG. 8 shows a registration process in which an authentication server authenticates a game console using a private key and certificate verification process. [Explanation of symbols] 100 (1), 100 (g) game system 102 Game Console 104 (1), 104 (2), 104 (3), 104 (4) controllers 106 Portable Media Drive 108 Portable storage medium 110 slots 112 Power button 114 eject button 120 A / V interface cable 122 power cable 124 Modem connector 130 serial cable 132 (1), 132 (2) thumb stick 134 D pad 136 button 138 Trigger 140 (1), 140 (2), 140 (3), 140 (4), 140 (5), 140 (6), 140 (7), 140 (8) Memory unit 200 central processing unit 202 memory controller 204 flash ROM 206 RAM 208 hard disk drive 210,212 cache 216 ATA cable 220 3D graphics processing unit 222 Video Encoder 224 Audio processing unit 226 Audio CODEC 228 A / V port 230 USB host controller 240 (1), 240 (2), 242 subassembly 250 system power supply module 252 fan 300 network environment 302 network 304 data center 306 Authentication server 308 (1), 308 (s) Online server 310 database 312 Key distribution center