Information processing systems, information processing methods, information processing programs, clients, servers

Abstract

This provides a device authentication method that utilizes a challenge-response approach. [Solution] In the system, the server issues challenge data and sends it to the client. The client stores calculated data, which is the result of performing at least some of the calculations for setting the server-side response key, sets the client-side response key without using this calculated data, generates response data from the challenge data received from the server based on this response key, and sends the generated response data and the stored calculated data to the server. The server receives this response data and calculated data, sets the server-side response key based on the calculated data, verifies the response received from the client based on the issued challenge data and the set response key, and notifies the client of the result based on the verification.

Description

Technical Field

[0001] The present disclosure relates to a device authentication method using a challenge & response method.

Background Art

[0002] Conventionally, as a method for authenticating a client device, an authentication method using a challenge & response method is known (for example, Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Regarding the device authentication method using the above challenge & response method, there was room for providing a new method.

Means for Solving the Problems

[0005] In view of the above points, for example, the following configuration examples can be given.

[0006] (Configuration 1) Configuration 1 is an information processing system including a client connected to a network and a server, and performing authentication processing of the client between the client and the server by a challenge & response method. The server is provided with means for issuing challenge data and transmitting it to the client. The client includes means for storing calculated data which is the result of performing at least some of the calculations for setting the server-side response key; means for setting the client-side response key; means for receiving the transmitted challenge data; means for generating response data from the received challenge data based on the set client-side response key; means for transmitting the generated response data to the server; and means for transmitting the stored calculated data to the server. The above-mentioned server (meaning a group of servers, and may be a different server device from the server device that issues challenge data and sends it to the client) further comprises means for receiving transmitted response data, means for receiving transmitted calculated data, means for setting a server-side response key based on the received calculated data, means for verifying the received response data based on the challenge data and the above-mentioned set server-side response key, and means for notifying the client of the results based on the verification. The above-mentioned client further comprises means for receiving the above-mentioned results.

[0007] According to the above configuration, at least some of the calculations for setting the response key on the server side can be omitted, and at least some of the various data used in the calculations (such as key data and seed data) can not be held by the server, thereby reducing the risk of such data being leaked from the server. In addition, even if the values ​​or calculation formulas used in the calculations differ depending on the client, for example, the increase in information processing on the server side can be suppressed.

[0008] (Configuration 2) Configuration 2 is an alternative configuration in which the client-side response key setting may be performed without using pre-calculated data.

[0009] (Composition 3) Configuration 3 is a configuration in which, in Configuration 1 or 2, the above calculation includes a first calculation and a second calculation performed based on the result of the first calculation, the calculated data is the result of performing the first calculation, and the setting of the server-side response key may be performed by performing the second calculation based on the received calculated data.

[0010] With the above configuration, by pre-calculating some of the multiple aspects that constitute the verification elements and performing calculations on the server for the other parts, it becomes possible to perform verification in a way that is appropriate to the nature of the verification elements.

[0011] (Composition 4) Configuration 4, in Configuration 3, may further include means for storing second calculation data used when performing the second calculation, and means for transmitting the second calculation data. Furthermore, it may include means for receiving the transmitted second calculation data, and the server-side response key may be set by executing the second calculation based on the received calculated data and the second calculation data.

[0012] (Composition 5) Configuration 5 is a configuration in which, in any of Configurations 1 to 4, the calculated data is a signed data that includes the calculated data and at least the data containing the calculated data, and the server-side response key setting may be performed based on the calculated data as well as verifying the signature.

[0013] (Composition 6) Configuration 6 is a configuration in which, in Configuration 3, the client may further store data for the second operation, which is data used when performing the second operation, and the calculated data may be stored as a set of signed data that includes the second operation data and at least signature data for that data, and the server-side response key setting may be performed based on the calculated data and the second operation data, as well as the verification of the signature.

[0014] (Composition 7) Configuration 7 is an example where, in any of Configurations 1 to 6, the calculated data may be encrypted data obtained by encrypting the calculated data with the server key, and the server-side response key setting may be performed by decrypting the encrypted data with the server key.

[0015] With the above configuration, confidential data can be sent from the client to the server and used for setting the server-side response key.

[0016] (Composition 8) Configuration 8, in Configuration 6, may further include means for the client to store unsigned data, which is data different from the data used for the second calculation and is not signed, used when performing the second calculation in setting the server-side response key, and the server may further include means for receiving the transmitted unsigned data, and the server-side response key may be set based on the calculated data, the second calculation data, and the unsigned data.

[0017] With the above configuration, data that can be signed and data that is difficult to sign can be sent from the client to the server and used for setting the response key on the server side.

[0018] (Composition 9) In configuration 9, the server-side response key setting in configuration 8 may be based on data identified based on a combination of second operation data and unsigned data.

[0019] (Composition 10) Configuration 10, in any of Configurations 1 to 9, may include a first communication session for authentication processing between the server and the client, where challenge data is sent and received, and a second communication session, which is a different communication session from the first communication session, where response data is sent and received, the response data is verified, and the results are sent and received. It is also permissible for the server device for the first communication session and the server device for the second communication session to be different.

[0020] (Configuration 11) In Configuration 10, the client may further include means for transferring the received challenge data to the server, and the server may further include means for receiving the transferred challenge data. In verification, the challenge data may be reproduced based on the transferred challenge data, and the received response data may be verified.

[0021] (Configuration 12) In Configuration 1, the client may further include means for delivering predetermined information to the application when the received authentication result is positive.

[0022] (Configuration 13) In Configuration 1, the authentication result may include data for using a predetermined online service, and the client may further include means for delivering the data for using the online service included in the authentication result to the application.

[0023] (Configuration 14) In Configuration 1, the client may further include means for using a predetermined online service when the authentication result is positive.

[0024] (Configuration 15) In Configuration 1, the processed data may have different values by the client.

[0025] (Configuration 16) In Configuration 2, the second processed data may have different values by the client.

[0026] (Configuration 17) In Configuration 8, the unsigned data may have different values by the client.

[0027] (Configuration 18) Configuration 18 may be a client in any of the information processing systems of Configurations 1 through 17.

[0028] (Composition 19) Configuration 19 may be an information processing program for causing a computer to function as one of the means provided by a client in any of the information processing systems in Configurations 1 to 17.

[0029] (Composition 20) Configuration 20 may be a server in any of the information processing systems from Configuration 1 to 17.

[0030] (Composition 21) Configuration 21 may be an information processing program that causes a computer to function as one of the means provided by the server in any of the information processing systems in Configurations 1 to 17.

[0031] (Composition 22) Configuration 22 is a program that causes a client computer, which performs authentication processing with a server using a challenge-response method, to execute the following processes: setting a client-side response key; receiving challenge data sent from the server; generating response data from the received challenge data based on the set response key; sending the generated response data to the server (meaning a group of servers, which may be individual servers different from the individual servers that issue and send challenge data to the client); reading calculated data from the client's memory, which is the result of performing at least some of the calculations for setting the server-side response key; sending the calculated data to the server; and receiving the result from the server based on the verification of the response data, which is performed based on the server-side response key set based on the calculated data.

[0032] (Composition 23) In configuration 23, the client-side response key setting may be performed without using pre-calculated data, as described in configuration 22 above.

[0033] (Composition 24) Configuration 24, in configuration 22 or 23 above, may include a first operation and a second operation performed on the server based on the result of the first operation, and the calculated data may be the result of performing the first operation.

[0034] (Composition 25) Configuration 25 may, in configuration 19 above, cause the computer to perform the following processes: reading second calculation data, which is data used when performing a second calculation on the server, from the client's memory, and sending the second calculation data to the server. The verification may also be performed using a server-side response key set by a second calculation based on the calculated data and the second calculation data.

[0035] (Composition 26) In configuration 26, the calculated data may be signed data that includes the calculated data and at least signature data of the data containing the calculated data, as described in configuration 22 or 23 above.

[0036] (Composition 27) Configuration 27 may store the calculated data as a set of signed data, which includes the second calculation data and at least the signature data of the data containing them, in the above configuration 25.

[0037] (Composition 28) In configuration 28, the calculated data in configuration 22 or 23 may be encrypted data obtained by encrypting the calculated data with a predetermined server key.

[0038] (Composition 29) Configuration 29, in the configuration 27 described above, may cause the computer to perform the following processes: reading unsigned data from the client's memory, which is different from the second calculation data used when the server performs the second calculation, and which is not signed; and sending the unsigned data to the server. Verification may also be performed using a server-side response key set based on the calculated data, the second calculation data, and the unsigned data.

[0039] (Composition 30) Configuration 30, in configuration 22 or 23 above, may include a first communication session for authentication processing between the server and the client, where challenge data is sent and received, and a second communication session, which is a different communication session from the first communication session, where response data is sent and received, the response data is verified, and the results are sent and received. It is also permissible for the server device for the first communication session and the server device for the second communication session to be different.

[0040] (Composition 31) Configuration 31 may also involve the computer in configuration 30 to perform a process of transferring the received challenge data to the server for playback.

[0041] (Composition 32) Configuration 32 may cause the computer to execute a process to pass predetermined information to the application when it receives a positive authentication result, as described in Configuration 22 above.

[0042] (Composition 33) Configuration 33, in the above configuration 22, may include data for using a predetermined online service in the authentication result, and may cause the computer to perform a process to pass the data for using the online service included in the received authentication result to the application.

[0043] (Composition 34) Configuration 34 may cause the computer in Configuration 22 to execute a service usage process that uses a predetermined online service if the received authentication result is positive.

[0044] (Composition 35) Configuration 35 may be configured such that the calculated data has different values ​​depending on the client, as in configuration 22 or 23.

[0045] (Composition 36) In configuration 36, the second calculation data may have different values ​​depending on the client, as in configuration 35.

[0046] (Composition 37) Configuration 37 may be configured such that, in configuration 36, the unsigned data has different values ​​depending on the client.

[0047] (Composition 38) Configuration 38 may also cause the computer to perform a process to specify an area where the calculated data will be stored, in addition to the processes described in configurations 22 to 37 above.

[0048] (Composition 39) Configuration 39 may also cause the computer to perform a process to specify an area where calculated data is stored and a process to specify an area where unsigned data is stored, in addition to the above configuration 29.

[0049] (Composition 40) Configuration 40 is a computer-based information processing method comprising a client and a server connected to a network, which performs client authentication processing between the client and the server using a challenge-response method. The server issues challenge data and sends it to the client. The client retrieves calculated data from its memory, which is the result of performing at least some of the calculations for setting the server-side response key, sets the client-side response key without using the calculated data, receives the challenge data sent from the server, generates response data from the received challenge data based on the set response key, and sends the generated response data and the retrieved calculated data to the server. The server further receives the response data and calculated data, sets the server-side response key based on the received calculated data, verifies the response data sent from the client based on the challenge data and the set server-side response key, and notifies the client of the result based on the verification. The client further receives the above result.

[0050] (Composition 41) Configuration 41 is a data structure for data that is stored by the client and sent to the server for authentication processing on the server, with respect to the challenge-response authentication process of a device, and includes at least calculated data which is the result of performing a first operation which is a part of the operation for setting the server-side response key, and first data which is used for a second operation which is another part of the operation for setting the server-side response key, and is a data structure used on the server to set the server-side response key by performing the second operation based on the calculated data and the first data.

[0051] (Composition 42) Configuration 42 includes multiple calculated data in Configuration 41, and the server may select the calculated data to be used from among the multiple calculated data based on the first data.

[0052] (Composition 43) Configuration 43 may be data obtained in Configuration 41 or 42 in which the calculated data is encrypted with a predetermined server key after performing a first operation, which is a part of the operations for setting the server-side response key.

[0053] (Composition 44) Configuration 44 further includes a signature on the calculated data and the first data in Configuration 41 or 42, and the server may verify the signature and perform a second operation based on the calculated data and the first data.

[0054] (Composition 45) Configuration 45 further includes the client's client ID in Configuration 41 or 42 and is sent to the server when a challenge issuance request is made and when a response is made. The server may then perform a verification process to confirm the consistency between the client at the time of challenge issuance sharing and the client at the time of response, based on the client ID received at the time of challenge issuance request and the client ID received at the time of response. [Brief explanation of the drawing]

[0055] [Figure 1] A schematic diagram showing the overall structure of the system of this embodiment. [Figure 2] Diagram illustrating the overview of the response key setting process. [Figure 3] Diagram showing an overview of the certificate creation process. [Figure 4] Example of the structure of certificate data D101 [Figure 5] This diagram outlines the process of generating and submitting challenge datasets. [Figure 6] An example of the structure of the challenge dataset D102 [Figure 7] A diagram illustrating the process of generating response datasets. [Figure 8] An example of data that client 3 sends to server 1. [Figure 9] This diagram shows an overview of the response key setting process on Server 1. [Figure 10] An example of the data structure of the counter value identification table SV404. [Figure 11] An example of the data structure of the 2nd KDF seed data specific table SV405. [Figure 12] Diagram illustrating the overview of the verification process. [Figure 13] Block diagram showing the hardware configuration of Client 3 [Figure 14] An example of data stored in the memory unit 32 of client 3. [Figure 15] Diagram illustrating the functional configuration of the system program CL201. [Figure 16] An example of data stored in the storage unit 12 of server 1. [Figure 17] An example of data stored in the memory unit 42 of PC4 [Figure 18] Example of a flowchart for certificate generation and writing process [Figure 19] Diagram showing the details of the process in a challenge issuance session. [Figure 20] Flowchart showing the details of the challenge generation process [Figure 21] Diagram showing details of the processing in the verification session. [Figure 22] Flowchart showing the details of the response generation process [Figure 23] A flowchart showing the first example of the first derived key setting process. [Figure 24] A flowchart showing a second example of the first derived key setting process. [Figure 25] A flowchart showing the first example of the second derived key setting process. [Figure 26] A flowchart showing a second example of the second derived key setting process. [Figure 27] A flowchart showing the details of the response dataset generation process. [Figure 28] A flowchart showing the details of the verification process. [Figure 29]A flowchart showing the details of the verification process. [Figure 30] Flowchart showing details of online game processing [Modes for carrying out the invention]

[0056] The embodiments will be described below.

[0057] This embodiment relates to a process for device authentication. In this embodiment, the process of performing device authentication when providing a predetermined communication service to a device or enabling the device to perform a predetermined function (more specifically, when providing online services, for example, online games, matching with opponents, accessing online shops (software and content download sites), etc.) is described as an example. In device authentication, the legitimacy of the client device (hereinafter simply referred to as the client) is confirmed.

[0058] In this embodiment, a challenge-response method is used as the device authentication method. In this method, authentication is performed in the following manner. First, Figure 1 schematically shows the overall configuration of the authentication processing system according to this embodiment. In Figure 1, a client authentication server (hereinafter simply referred to as server) 1 and a client device (hereinafter simply referred to as client) 3 are connected via a network. Note that server 1 may be composed of multiple server devices. In such a configuration, first, (1) a client 3 that wishes to start an online game requests server 1 (which in this embodiment is different from the server that provides the online game) to send challenge data. (2) In response to the request, server 1 generates challenge data and sends it to client 3. (3) Client 3 performs predetermined calculation processing based on the challenge data to generate response data and sends it to server 1. (4) Server 1 verifies the response data received from the client and sends predetermined data to client 3 according to the success or failure of the verification, thereby authenticating the legitimacy of client 3. In the case of a server composed of multiple server devices, it is permissible that the server device that performs the processing in (2) and the server device that performs the processing in (4) are different.

[0059] Next, we will describe the device authentication process using the challenge-response method in this embodiment (hereinafter simply referred to as the authentication process). First, we will explain the "response key" used in the authentication process.

[0060] [About Response Keys] A response key is key data used in the process of creating response data. Response data is generated by performing calculations using this response key on the challenge data received from Server 1.

[0061] Figure 2 is a diagram illustrating the overview of the response key setting process in this embodiment, and schematically shows the data flow in the process. In Figure 2, elements shown as ellipses represent data parameter elements, and elements shown as rectangles represent processing elements. For the sake of explanation, in Figure 2, data parameter elements are denoted with a reference sign of the form "Dnn (where nn is an integer)". Similar diagrams will appear hereafter, and these will also be denoted with the same reference sign.

[0062] In the example shown in Figure 2, a key derivation function (KDF) is used to generate key data from predetermined data, and the generated key data is set as the response key. Here, a KDF is a function for generating another key based on key data. When key data and predetermined data called seed data are input to the KDF, another key data is generated based on these. Hereafter, the key data output by the KDF will be called the "derived key". In this embodiment, derived key data generated using multiple KDFs (two KDFs in this embodiment) is used as the response key. In the following explanation, the first KDF will be called the "first KDF", the second KDF will be called the "second KDF", the key data output by the first KDF will be called the "first derived key data" or simply the "first derived key", and the key data output by the second KDF will be called the "second derived key data" or simply the "second derived key". The calculations performed by each KDF can be anything, but examples include KDFs that use HMAC or CMAC as the PRF, or KDFs that use a hash function or block cipher. Also, the calculations performed by each stage of the KDF may be the same or different.

[0063] Figure 2 illustrates the flow of response key setting. The response key setting process is performed on both the server and the client, but in this embodiment, as will be described later, there are differences between the response key setting process performed on the server and the response key setting process performed on the client. Figure 2 illustrates the response key setting process performed on client 3. The response key set on client 3 is sometimes referred to as "response key (client)," and the response key set on server 1 is sometimes referred to as "response key (server)." Also, the second derived key calculated on client 3 is sometimes referred to as "second derived key (client)," and the second derived key calculated on server 1 is sometimes referred to as "second derived key (server)."

[0064] First, the memory unit of client 3 stores the master key D01, counter value D02, first KDF seed data D03, and second KDF seed data D04. The master key D01 is the key data input to the first KDF. The master key D01 may be configured as a fixed value or as modifiable data. Also, the master key D01 may be different data depending on the client. If the client is implemented using emulator technology, it may be the same data as the master key being emulated.

[0065] The counter value D02, the first KDF seed data D03, and the second KDF seed data D04 are data used as seed data for the KDF, respectively. The counter value D02 can take on different values ​​depending on the client 3. For example, it is a value that may change in response to system updates of client 3, and specifically, it is incremented by 1. In this embodiment, as an example, we will describe the case where the counter value can take on any of the four values ​​from 0 to 3. Also, in this embodiment, the initial value of the counter value D02 is 0.

[0066] The first KDF seed data D03 is seed data input to the first KDF and may take different values ​​depending on the client 3. The second KDF seed data D04 is seed data input to the second KDF and may take different values ​​depending on the client 3. These seed data can be any kind of data, but for example, the first KDF seed data D03 may be a fixed value, or more specifically, identification data that indicates a certain characteristic of client 3. For example, it may be identification data that indicates either a development machine or a production machine. If the client is implemented using emulator technology, the identification data may be data that indicates the characteristics of the object being emulated. The second KDF seed data D04 may be data that client 3 can set or change itself or in response to instructions from an external source such as a server. More specifically, it may be identification data that indicates another characteristic of client 3 (for example, data that indicates security settings). It may also be data that differs depending on the system version (data that is updated by version upgrades). If the client is implemented using emulator technology, the identification data may be data that indicates the characteristics of the object being emulated. Furthermore, each KDF seed data D03 and D04 may be changed, for example, by a system software update. Also, both the first KDF seed data D03 and the second KDF seed data D04 may have different values ​​depending on the client.

[0067] Of this data, the master key D01, the (current) counter value D02, and the first KDF seed data D03 are first input into the first KDF. As a result, the derived key "first derived key" D05, which is output by the first KDF calculation, is generated.

[0068] Next, the second KDF seed data D04 is input to the second KDF along with the generated first derived key D05. This generates the "second derived key (client)" D06, which is the derived key output by the second KDF calculation.

[0069] In this embodiment, the second derived key (client) D06 is used as the response key (client). That is, in this embodiment, the response key (client) is set by generating the second derived key, which is then used in the process of generating the response dataset D103, which will be described later.

[0070] The calculations for each KDF in the response key setting process may be performed at runtime (i.e., each time authentication is performed), but the results of the calculations may be stored in advance and read when authentication is performed, thus avoiding repeated calculations. For example, the first derived key data and / or second derived key data may be calculated and stored when client 3's system starts up, and the response key may be set by reading them when authentication is performed. Alternatively, the calculated data (first derived key data and / or second derived key data) may be obtained from an external source and stored, and the response key may be set by reading it when authentication is performed. Furthermore, one of the calculations for the first KDF and the second KDF may be performed at runtime, while the other is performed by reading pre-calculated data.

[0071] As described above, in this embodiment, the response key setting process performed on Server 1 and the response key setting process performed on Client 3 are different. One of these differences is that the calculation of the first KDF is not performed in the response key setting process performed on Server 1. More specifically, the calculated data (first derived key data; in this embodiment, encrypted first derived key data as described later) which is the result of performing the calculation of the first KDF in advance (for example, in the Client 3 setup process performed in advance before the start of the authentication process) is written to the storage unit of Client 3. Then, when the authentication process is performed, the calculated data is sent from Client 3 to Server 1, and Server 1 uses this calculated data to perform the calculation of the second KDF without performing the calculation of the first KDF and sets the response key. In this embodiment, as described later, this calculated data is included in the client certificate data (hereinafter simply referred to as certificate data).

[0072] Here, we will explain how to generate certificate data. The above certificate data is stored in Client 3 in advance (before the start of the authentication process). This certificate data is written to the storage unit (described later) of Client 3 during the Client 3 configuration process. Figure 3 is a schematic diagram showing the overview of the certificate creation process when the writing process is performed by a PC (hereinafter referred to as PC4). In Figure 3, first, the master key D01 of the Client 3 to be manufactured, the counter value D02, and the first KDF seed data D03 are input to the first KDF. This generates the first derived key D05. The master key D01 can be read, for example, from Client 3 connected to PC4 and targeted for the certificate data writing process. Here, as described above, in this embodiment, the counter value D02 can take four values. Therefore, the calculation of the first KDF in PC4 is performed for each possible value of the counter value D02 (0 to 3), and the first derived key D05 corresponding to each value of the counter value D02 is generated. In other words, in this example, four first derived keys D05 are generated. Below, when referring to these four first derived keys D05 individually, we will use the notations D05A (counter value 0), D05B (counter value 1), D05C (counter value 2), and D05D (counter value 3).

[0073] Next, each first derived key D05 is encrypted. Specifically, each first derived key D05 is encrypted using the encryption key, the first server key D07. Hereafter, the encrypted first derived key D05 will be referred to as the "encrypted first derived key" D08. In this embodiment, a different first server key D07 is prepared for each counter value D02. Hereafter, the first server key used when the counter value D02 is 0 will be referred to as "first server key (counter value 0) D07A", the first server key D07 used when the counter value D02 is 1 will be referred to as "first server key (counter value 1) D07B", and so on, and the encrypted encrypted first derived key will be referred to as "encrypted first derived key (counter value 0) D08A", "encrypted first derived key (counter value 1) D08B", and so on. In this way, a first derived encryption key D08 is generated for each counter value D02, and in this embodiment, a total of four first derived encryption keys D08 are generated. The first server key D07 may be a symmetric key or a private key / public key.

[0074] Next, an electronic signature (hereinafter simply referred to as "signature") D12 to be attached to the client certificate is generated. Signature D12 is generated by performing calculations using a predetermined signature generation algorithm that uses the signing key D09, which is the key used for signing. Specifically, it is generated by signing data containing a total of seven data elements: (A) client ID_D10, (B) the first parameter for identifying the second KDF seed (hereinafter sometimes referred to as the first identification parameter) D11, which will be described later, and (C) the four first encryption derived keys D08 mentioned above, using the signing key D09.

[0075] Here, client ID_D10 is an ID used to identify client 3. For example, client ID_D10 may be the ID, serial number, or manufacturing number of the client device's SoC. If the client is implemented using emulator technology, this number may be information related to the object being emulated. When generating the certificate, for example, client ID_D10 may be read from client 3, which is connected to PC4 and is the target of the certificate data writing process, and used. In addition, the first specific parameter D11 is used by server 1 to specify the value of the second KDF seed data D04 (details will be described later).

[0076] Next, certificate data D101 is generated, which includes client ID_D10, first specific parameter D11, and the four first encryption derived keys D08 mentioned above, and is accompanied by the signature D12 generated as described above. Figure 4 shows the structure of certificate data D101. Certificate data D101 includes signature D12, four first encryption derived keys D08A~08D, client ID_D10, and the first specific parameter D11 mentioned above.

[0077] Finally, the generated certificate data D101 is written to the non-volatile storage unit (described later) of client 3. As described later, the certificate data D101 is sent from client 3 to server 1 during the authentication process, and each piece of data contained in the certificate data D101 is used by server 1. Of the data contained in the certificate data D101, the first derived key D08 (more precisely, the first derived key D05 obtained by decrypting it) is the first derived key data, which is the result of performing the first KDF operation, and server 1 uses this data to set the response key. Therefore, server 1 does not need to perform the first KDF operation. Note that the certificate data D101 may also be downloaded or transferred from a designated server or other PC to client 3 and written to client 3.

[0078] Furthermore, in this embodiment, the counter value D02 is used as seed data for the KDF calculation for setting the response key. This makes it possible to change the response key depending on the situation.

[0079] Furthermore, in this embodiment, multiple derived keys are included in the certificate and can be selected and used, enabling efficient modification of the response key.

[0080] [Overview of Challenge Creation and Submission] Next, we will explain the overview of the challenge data generation and transmission process in Server 1. This process is executed in response to a challenge issuance request from Client 3. When Client 3 requests a challenge issuance, it sends certificate data D101. Figure 5 shows an overview of the challenge data generation and transmission process in Server 1, and schematically illustrates the data flow in this process. In this process, first, certificate data D101 is received from Client 3 and verified (signature verification) is performed. If there are no problems as a result of this verification, Client ID_D10 is extracted from certificate data D101.

[0081] Next, the client ID_D10, the "challenge version" D14, and the "challenge issuance time" D15 are used as the calculation targets, and a predetermined MAC calculation is performed using the "second server key" D13 to calculate the first MAC (Message Authentication Code) value D16. The first MAC value D16 is used as the challenge data.

[0082] In this embodiment, challenge data was generated by MAC operation, but any cryptographic operation capable of generating tamper-verification data (data used for tamper verification) may be used, for example, the AES-GCM algorithm. Also, the second server key used in the operation may be a symmetric key or a private key / public key.

[0083] Here, Challenge Version D14 is data stored on Server 1, and it is information that defines the "version" of the method for generating challenge data generated on Server 1 at a given time, and it indicates the current version. For example, Challenge Version D14 is initially set to "1.0" and can be changed to "2.0" at a predetermined time.

[0084] Furthermore, the challenge issuance time D15 is the time on Server 1 when the process of generating the challenge data is performed on Server 1.

[0085] Furthermore, the second server key D13 is key data used to calculate the first MAC value (challenge data) D16. In this embodiment, the second server key D13 may differ for each challenge version D14 (although the key may remain the same even if the version changes). In this embodiment, the second server key D13 corresponding to the current challenge version D14 is selected and used to calculate the first MAC value (challenge data) D16. The first MAC value D16 is the data that is the target of calculations using the response key in client 3, and is the so-called challenge data.

[0086] Once the first MAC value D16 is calculated, a challenge dataset D102 is generated based on the (current) challenge version D14, the challenge issuance time D15, and the first MAC value (challenge data) D16. Figure 6 schematically shows the structure of the challenge dataset D102. Note that the challenge dataset D102 is data that includes challenge data as well as other data. In this embodiment, the challenge dataset D102 is data with the structure of "challenge version D14 + challenge issuance time D15 + first MAC value (challenge data) D16". Note that the value of the result of the MAC calculation is generally attached to the data to be calculated (message data) and transmitted, but in this embodiment, the client ID_D10 is used in the calculation of the first MAC value but is not included in the challenge dataset.

[0087] The challenge dataset D102 generated as described above is sent to client 3, who requested the challenge.

[0088] [Overview of response generation process in Client 3] Next, we will explain the overview of the response generation process executed by client 3, which receives the challenge dataset D102. Figure 7 is a diagram illustrating the overview of this process. First, the second MAC value (response data) D17 is calculated by performing a MAC operation on the first MAC value (challenge data) D16 contained in the challenge dataset D102 received from server 1, using the response key (client) (second derived key (client) D06) set as described above using Figure 2. The second MAC value D17 is the result of performing an operation on the challenge data using the response key, and is the so-called response data. Note that the content of the MAC operation when calculating the second MAC value (response data) D17 may be the same as the content of the MAC operation when calculating the first MAC value (challenge data) D16, or it may be a different operation. Note that the length of the first MAC value, which is the data input to the second MAC operation, is determined by the content of the first MAC operation and is a fixed length regardless of the length of the data input to the first MAC operation. In this embodiment, MAC calculation was used to generate response data from challenge data using the response key, but any algorithm that can generate response data from challenge data using the response key is acceptable, not limited to MAC calculation.

[0089] Next, a response dataset D103 is generated based on the second MAC value (response data) D17, the challenge version D14 included in the received challenge dataset D102, and the challenge issuance time D15. The response dataset D103 includes the response data and other data (in this embodiment, data other than the challenge data included in the challenge dataset D102 received from server 1; specifically, the challenge version D14 and the challenge issuance time D15). As mentioned above, the result of the MAC calculation is generally attached to the data to be calculated (message data) and transmitted, but in this embodiment, the first MAC value (challenge data) D16 is used in the calculation of the second MAC value (response data) D17, but it is not included in the data sent to the server (the response dataset and client-sent data described later).

[0090] Once the response dataset D103 is generated, client 3 sends (A) the response dataset D103, (B) the certificate data D101, and (C) the second parameter for identifying the second KDF seed data (hereinafter sometimes referred to as the second identification parameter) D19, which will be described later, to server 1. Figure 8 is a schematic diagram of the data that client 3 sends to server 1 (hereinafter sometimes collectively referred to as client-sent data D104). Note that each piece of client-sent data may be sent as a set, or it may be sent separately at different times. In Figure 8, the response dataset D103 includes the challenge version D14, the challenge issuance time D15, and the second MAC value (response data) D17. This is a configuration similar to that of the challenge dataset D102 described above, but with the first MAC value (challenge data) D16 replaced by the second MAC value (response data) D17. In other words, the challenge version D14 and challenge issuance time D15 included in the challenge dataset received from Server 1 when receiving challenge data are included in the response dataset and sent to Server 1 when sending response data. The certificate data D101 is the same as the certificate data D101 sent when requesting challenge issuance. That is, the certificate data D101 is sent when requesting Server 1 to send challenge data and when sending response data to Server 1. The second specific parameter D19, together with the first specific parameter D11, is a parameter used in Server 1's processing to identify the value of the second KDF seed data D04 (details will be described later).

[0091] Next, we will explain the process involved in response verification at Server 1, which receives client-transmitted data D104. First, a response key (server) is set at Server 1. Next, a second MAC value (during verification) D217 is calculated using the set response key (server). Then, it is determined whether the second MAC value (during verification) D217 calculated at Server 1 matches the second MAC value (response data) D17 sent from the client, thereby verifying the response data D17.

[0092] Figure 9 is a diagram illustrating the overview of the response key setting process in Server 1. First, the signature D12 is verified for the certificate data D101 contained in the client transmission data D104. If there are no problems with the verification, the first encryption derived key D08 and the first identification parameter D11 are extracted from the certificate data D101. Here, as described above, the certificate data D101 contains four first encryption derived keys D08, but one of them is identified and extracted by the following procedure. First, the current counter value D02 in Client 3 is identified. This identification is done by referring to the "counter value identification table" which is stored in advance in Server 1. The counter value identification table is a table for identifying the current counter value D02 of the client based on the first identification parameter D11 and the second identification parameter D19 sent from Client 3. In other words, the current counter value D02 in client 3 (client 3 being authenticated), which sent the response data, is determined using the first specific parameter D11 extracted from the certificate data D101 and the second specific parameter D19 that was sent along with the certificate data D101. Figure 10 shows an example of the data structure of the counter value identification table SV404. In the counter value identification table SV404, the counter value D02 is defined in association with the combination of the value of the first specific parameter D11 and the value of the second specific parameter D19.

[0093] Returning to Figure 9, next, Server 1 selects the encryption first derived key D08 corresponding to the counter value D02 identified using the counter value identification table SV404 from among the multiple encryption first derived keys D08 contained in the certificate data D101, and retrieves it from the certificate data D101. Next, in Server 1, the retrieved encryption first derived key D08 is decrypted using the first server key D07 stored in Server 1 to obtain the first derived key D05. Here, the first server key D07 is different key data depending on the counter value D02 as described above. If the counter value D02 may differ depending on Client 3, Server 1 stores each first server key D07 corresponding to the currently possible counter value D02, and the first server key D07 corresponding to the identified counter value D02 is used.

[0094] Next, the second KDF is processed using the decrypted first derived key D05 and the second KDF seed data D204. Here, the value of the second KDF seed data D204 in the second KDF processing is determined as follows. The "second KDF seed data identification table" is used to identify the value of the second KDF seed data D204. The second KDF seed data identification table is a table for identifying the second KDF seed data D04 based on the first identification parameter D11 and the second identification parameter D19. In other words, the second KDF seed data D04 in client 3, which sent the response data, is identified using the first identification parameter D11 extracted from the certificate data D101 and the second identification parameter D19 sent from the client along with the certificate data D101. Figure 11 shows an example of the data structure of the second KDF seed data identification table SV405. In the second KDF seed data identification table SV405, the value of the second KDF seed data D204 is defined in association with the combination of the first identification parameter D11 and the second identification parameter D19. That is, as described above using Figure 2, in the response key setting process of client 3, the response key is set using the second KDF seed data stored in client 3. On the other hand, in the response key setting process of server 1, the value D04 of the second KDF seed data stored in client 3 that sent the response data is identified based on the first identification parameter D11 and the second identification parameter D19 received from client 3, and the response key is set using that value. This is one of the differences between the response key setting process performed on the server and the response key setting process performed on the client.

[0095] In this embodiment, Server 1 identifies the KDF seed data using specific parameters sent from Client 3. This configuration allows for response key settings that take into account the attributes and state of the client (or the emulated client device if implemented using emulator technology). Furthermore, in this embodiment, two parameters are used to identify the KDF seed data: the first specific parameter is subject to signing, while the second specific parameter is not. This configuration allows for flexibility in the composition of the KDF seed data, for example, by using parameters that can be signed and parameters that are difficult to sign.

[0096] The parameters to be designated as the first specific parameter D11 and the second specific parameter D19 can be designed as appropriate. For example, the first specific parameter D11 may be a fixed value. For example, it may be attribute information of the client 3 hardware. The second specific parameter D19 may be data that can be set or changed in client 3. For example, it may be attribute information of software, or attribute information of system software (for example, system software version information). The first specific parameter D11 may be data that can be set or changed in client 3, and the second specific parameter D19 may be a fixed value. Note that if client 3 is implemented using emulator technology, the first specific parameter and the second specific parameter may be attribute information of the object to be emulated. However, in this embodiment, the first specific parameter and the second specific parameter are data different from the second KDF seed data, and the second KDF seed data can be identified by the combination of the first specific parameter and the second specific parameter. Also, in this embodiment, the first specific parameter and the second specific parameter are data different from the first KDF seed data.

[0097] Returning to Figure 9, Server 1 performs the second KDF calculation using the second KDF seed data D204 determined as described above and the first derived key D05 extracted from the certificate data D101, thereby generating the second derived key (server) D206. The calculation method (algorithm) for the second KDF performed on Server 1 is the same as that performed on Client 3. Then, Server 1 uses the generated second derived key (server) D206 as the response key. In other words, the response key (server) is set by generating the second derived key (server) D206.

[0098] Here, if the data used as the basis for the KDF calculation and the calculation content of the KDF calculation differ depending on the client configuration, when generating a derived key in Server 1, it would be necessary to manage a database or the like to change the data used as the basis for the KDF calculation and the calculation content of the KDF calculation according to the configuration of each client. However, in this embodiment, for the first KDF calculation, the data (derived key) after the KDF calculation is sent from Client 3 to Server 1, and Server 1 uses it to generate a response key, so there is no need to have such a database.

[0099] Furthermore, in this embodiment, the KDF calculation is multi-stage. For the first KDF calculation, the calculated derived key is sent from client 3 to server 1, and server 1 uses it to perform another KDF calculation (second KDF calculation) to generate a response key. This allows for some aspects of the verification elements to be calculated in advance, while other aspects are calculated on the server, enabling verification in a manner appropriate to the nature of the verification elements.

[0100] As shown in Figure 9, the response key setting process on Server 1 does not utilize the response dataset D103. In the verification process described next, the second MAC value (response data) D17 included in the response dataset D103 is verified.

[0101] [Overview of the verification process] Next, we will explain the overview of the verification process performed on the server (in this embodiment, this includes not only verification of the response data but also verification of the challenge issuance time included in the response data, as will be described later). Figure 12 is a diagram illustrating the overview of the verification process. In the verification process, Server 1 calculates the second MAC value (at the time of verification) D217 and determines whether it matches the second MAC value (response data) D17 sent from Client 3, thereby verifying the second MAC value D17, which is the response data.

[0102] First, Server 1 performs a process to calculate the first MAC value (during verification) D216. This process is basically the same as the process described above using Figure 5 to calculate the first MAC value (challenge data) D16 in the challenge generation process. Based on the challenge version D14 contained in the response dataset D103 sent from Client 3, the second server key D13 corresponding to the challenge version D14 is selected. Then, using the selected second server key D13, the first MAC value (during verification) D216 is calculated by performing a MAC value calculation targeting "the challenge version D14 and challenge issuance time D15 contained in the response dataset D103, and the client ID_D10 contained in the certificate data D101 sent from the client (certificate data D101 sent at the time of the verification request)".

[0103] Furthermore, regarding the calculation process of the first MAC value (during verification) D16, in other embodiments, the first MAC value (challenge data) D16 calculated in the challenge generation process may be stored on server 1. Then, the stored first MAC value (challenge data) D16 may be used in the verification process, thereby omitting the calculation process of the first MAC value (during verification) D16.

[0104] Next, using the response key (server) D206 and the first MAC value (during verification) D216 set above, the second MAC value (during verification) D217 is calculated using the same algorithm as the MAC calculation on client 3.

[0105] Next, the second MAC value (response data) D17 included in the response dataset D103 is compared with the second MAC value (during verification) D217 calculated above, and it is determined whether they match. If they match, the response verification result is determined to be OK (affirmative); if they do not match, the response verification result is determined to be NG (negative).

[0106] Furthermore, in this embodiment, Server 1 performs a verification process from a temporal perspective. This process determines whether the time from when Server 1 issues the challenge dataset D102 until when the client returns the response dataset D103, etc. (or the time from when the challenge data is issued until the verification is performed) is within a certain time limit. Specifically, the challenge issuance time D15 included in the response dataset D103 is compared with the current time of Server 1 at the time the verification process is performed. If this time is within a certain time limit, it is judged as OK; if it takes longer than a certain time limit, it is judged as NG.

[0107] If both the verification of response data D17 and the verification from a temporal perspective are OK, authentication is determined to be successful. Otherwise, authentication is determined to be failed. If authentication is successful, the process of sending a predetermined service token to the client is executed. If authentication fails, an error message or similar will be sent. The contents of the service token include, for example, the client ID, the identifier of the predetermined online service, the expiration date, and information including the signature or MAC value of that data.

[0108] As described above, in this embodiment, when a challenge is issued, Server 1 sends a MAC value (first MAC value) to Client 3, which is calculated using at least the challenge issuance time, along with the challenge issuance time. Furthermore, when generating response data, Client 3 generates a value (second MAC value) by further calculating the MAC value using the response key, and sends it to Server 1 as response data. Server 1 verifies this value, and also performs temporal verification using the challenge issuance time. This prevents fraud during the authentication process.

[0109] The following describes the details of the process according to this embodiment.

[0110] [Client 3 Hardware Configuration] Next, the hardware configuration of client 3 will be described. Figure 13 is a block diagram showing the hardware configuration of client 3. In this embodiment, client 3 is a game device, but it may also be a general-purpose PC, smartphone, tablet device, etc. Client 3 is an example of a computer and includes a main processor, subprocessor, memory, programs, peripheral processors, etc. Client 3 includes at least a processing unit 31, a storage unit 32, a network communication unit 35, an operation device 36 (game controller), and an image output unit 37. The processing unit 31 is, for example, a processor and executes various programs for controlling client 3. Client 3 may be composed of multiple devices. The processing unit 31 may be composed of multiple processors, in which case it may be multiple processors of multiple devices. Also, the processor may be a general-purpose processor or a dedicated processor, and is not limited to the form of a so-called SoC, CPU, ASIC, microcontroller, etc. The storage unit 32 stores various programs executed by the processing unit 31 and various data used. The program may be a group of programs composed of multiple programs, each program may be executed by a different processor, and each program may be stored in a different memory. Furthermore, the program may be any type of software, such as application software, system software, firmware, or emulator. The program may include data and table parameters in addition to code. Specifically, the storage unit 32 includes a non-volatile storage unit 33 and a volatile storage unit 34. The non-volatile storage unit 33 is, for example, flash memory or an SSD (Solid State Drive). The volatile storage unit 34 is, for example, DRAM and functions as main memory. Various programs and data stored in the non-volatile storage unit 33 are loaded onto the volatile storage unit 34 as needed, and the processing unit 31 can execute various processes as described later. The network communication unit 35 communicates with other servers and clients 3 via a network such as the Internet (this may be wireless or wired). Alternatively, the system may be configured to communicate directly with the communication partner without using a network.The operating device is various types of operating devices (keyboard, mouse, etc.). The image output unit 37 outputs a predetermined image generated as a result of information processing by the processing unit 31.

[0111] Furthermore, a portion of the non-volatile storage unit 33 and the volatile storage unit 34 may be configured as a secure area. Some of the various types of data described later may be configured to be stored in a secure area such as the memory within the SoC (System on a Chip).

[0112] The hardware configuration of Server 1 and PC 4 can be any common server or PC hardware configuration, and the explanation is omitted, but it is the same configuration as in Figure 13. Server 1 may be composed of multiple server devices. Specifically, Server 1 consists of a processing unit 11 and a storage unit 12 including a non-volatile storage unit 13 such as flash memory and a volatile storage unit 14 such as DRAM. Server 1 is an example of a computer. PC 4 consists of a processing unit 41 and a storage unit 42 including a non-volatile storage unit 43 such as flash memory and a volatile storage unit 44 such as DRAM.

[0113] Next, we will explain the various data used in the processing according to this embodiment.

[0114] [Data used by Client 3] Figure 14 shows an example of data stored in the memory unit 32 of client 3. The data shown in Figure 14 is data stored in the non-volatile memory unit 33, and when authentication processing is performed, this data is read into the volatile memory unit 34 as needed, thereby enabling the authentication process to be executed. Note that this data may be stored in different memories. For example, some of the data may be stored in the secure area mentioned above.

[0115] In Figure 14, the non-volatile memory unit 33 stores at least the system program CL201, the online game program CL202, the master key D01, the counter value D02, the first KDF seed data D03, the second KDF seed data D04, the certificate data D101, and the second parameter D19 for identifying the second KDF seed data. In Figure 14, all data other than the system program CL201 and the online game program CL202 are essentially the same as the various data described above.

[0116] In Figure 14, the system program CL201 is a program for controlling the client 3 system. The system program CL201 includes at least the programs for realizing the authentication function of this embodiment, as shown in Figure 15. First, the system program CL201 includes a challenge issuance request program that requests the server 1 to issue a challenge. The system program CL201 also includes a response key setting program that has the function of setting a response key (client). The system program CL201 also includes a response generation and transmission program that has the function of receiving the challenge dataset D102, generating a response dataset D103, and transmitting the response dataset D103, etc. (the client transmission data described above). The system program CL201 also includes an authentication result processing program that has the function of starting an online game based on the authentication result. The device authentication process according to this embodiment is executed as one of the system-side processes that control client 3 (not as an application process).

[0117] Returning to Figure 14, the online game program CL202 is a program for a predetermined online game. In this embodiment, as described above, a device authentication process is performed when starting to play the online game.

[0118] Furthermore, the various data mentioned above (including various data necessary for setting the response key (client) (seed data for each KDF calculation, certificate data, parameters for identifying the seed data, etc.)) may be downloaded at a predetermined timing or transferred from another information processing device and stored in the storage unit 32. In this case, for example, the response key setting program may have a function to specify the various data that have been downloaded or transferred. Alternatively, it may have a function to specify the location where the various data is stored (a folder on client 3, etc.).

[0119] In another embodiment, for example, the data for the first derived key D05 may be stored in the storage unit 32. In this case, the master key D01 and the first KDF seed data D03 do not need to be stored in the storage unit 32.

[0120] Furthermore, in another embodiment, for example, the data for the second derived key D06 may be stored in the storage unit 32. In this case, the master key D01, the first KDF seed data D03, and the second KDF seed data D04 do not need to be stored. Also in this case, the response key setting program may be configured not to have a first derived key setting function.

[0121] [Data used on Server 1] Next, we will describe the data stored in the storage unit 12 of server 1. Figure 16 shows the data stored in the non-volatile storage unit 13 of server 1. When the authentication process is executed, this data is read into the volatile storage unit 14 as needed, thereby enabling the authentication process on the server 1 side to be executed.

[0122] The non-volatile memory unit 13 of server 1 stores the authentication program SV401, the first server key D07, the second server key D13, the counter value identification table SV404, the second KDF seed data identification table SV405, the CA public key SV406, the challenge version D14, and the like.

[0123] The authentication program SV401 is a program that performs authentication processing on the server 1 side. The authentication program SV401 has a challenge issuance function that issues the above challenge data to client 3 and sends other data, and a verification function that verifies using the response dataset D103 etc. from client 3. The verification function also includes a function to set the response key (server) as described above using Figure 12.

[0124] Here, we will provide some additional information regarding the first server key D07. As described above, in this embodiment, multiple key data are prepared for the first server key D07 according to the counter value, but only one of these key data is stored as the first server key D07 in Server 1. And each time the counter value is incremented, the key data is replaced with the key data corresponding to the counter value.

[0125] Furthermore, if the increment of counter value D02 in client 3 occurs during a system update of client 3, the timing of the update of counter value D02 in each client 3 may not be the same. Therefore, for a certain period after the increment of counter value D02 occurs (for example, at the time of a system update), the first server key D07 corresponding to the counter value D02 before the increment may be stored as the "old first server key". During this period, even if authentication is requested from a client 3 that has not yet undergone a system update, the system may be configured to determine that authentication was successful using the "old first server key".

[0126] As described above, in this embodiment, the second server key D13 is key data with different content for each challenge version D14. The storage unit 12 of server 1 stores key data corresponding to the currently used challenge version D14 as the second server key D13. When the challenge version D14 is changed, there is a possibility that there are clients 3 that make verification requests using challenges issued with the old challenge version. Therefore, the second server key D13 corresponding to the old challenge version may be stored to respond to verification requests from such clients 3.

[0127] The counter value identification table SV404 contains the data shown in Figure 10 above. Therefore, a detailed explanation is omitted here.

[0128] The second KDF seed data specific table SV405 contains the data shown in Figure 11 above. Therefore, a detailed explanation is omitted here.

[0129] The CA public key SV406 is the key data paired with the signing key D09, and is the key data (decryption key or verification key in public-key cryptography) used by Server 1 to verify the signature D12 of certificate data D101.

[0130] Challenge version D14 is the challenge version assigned to the challenge issued at that time. As described above, in this embodiment, the second server key D13 is different for each challenge version, so when challenge data D16 is generated, challenge version D14 is used to determine which second server key D13 was used to calculate the first MAC value (challenge data) D16. In addition, various processes of server 1 and / or client 3 may be changed depending on the challenge version, other than the change of the second server key D13. In this case, the processing may be branched according to the challenge version D14 included in the challenge.

[0131] [Data used in PC4] Next, Figure 17 shows an example of the data stored in the storage unit 42 of the PC4 described above. That is, Figure 3 shows an example of the data used in the certificate creation process described above. The storage unit 42 of the PC4 stores the certificate generation / writing program FC501, master key D01 (master key D01 corresponding to client 3 to be manufactured), first KDF seed data D03 (first KDF seed data D03 corresponding to client 3 to be manufactured), four first server keys D07A to D07D, signing key D09, client ID_D10 (client ID_D10 corresponding to client 3 to be manufactured), and first identification parameter D11 (first parameter D11 for identifying second KDF seed data corresponding to client 3 to be manufactured).

[0132] The certificate generation and writing program FC501 is a program that generates the certificate data D101 described above using Figure 3 and writes it to the non-volatile storage unit 33 of client 3.

[0133] Furthermore, the first parameter D11 used in PC4 to identify the second KDF seed data is pre-set to a predetermined value corresponding to the client 3 to which the data is to be written.

[0134] The following flowcharts describe the details of the processes performed by PC4, Client3, and Server1. Note that the flowcharts shown below are merely examples of the processing steps. Therefore, the order of each step may be changed if similar results can be obtained. Also, the variable values ​​and thresholds used in the judgment steps are merely examples; other values ​​may be used as needed.

[0135] First, we will explain the details of the certificate generation and writing process performed on PC4. Figure 18 is an example of a flowchart of the certificate generation and writing process. First, the processing unit 41 of PC4 sets the variable counter value n to 0 (step S201).

[0136] Next, the processing unit 41 reads the master key D01, the first KDF seed data D03, and the client ID_D10 from the client 3 that is the target of the certificate data D101 writing, and stores them in the storage unit 42 (step S202). For example, these data are read from the client 3 that is connected to the PC4 and is the target of the writing process. Note that these data may be generated on the manufacturing equipment side or read from the storage device on the manufacturing equipment side, rather than being read from the client 3.

[0137] Next, the processing unit 41 performs a first KDF operation based on the master key D01, the current counter value n, and the first KDF seed data D03 to generate a first derived key n corresponding to the current counter value n (step S203).

[0138] Next, the processing unit 41 encrypts the generated first derived key n with the first server key D07 (the key at counter value n) corresponding to the current counter value n (step S204).

[0139] Next, the processing unit 41 adds 1 to the counter value n (step S205).

[0140] Next, the processing unit 41 determines whether the counter value n has become greater than a predetermined value (step S206). In this embodiment, the counter value n takes one of four values ​​from 0 to 3, so this predetermined value is 3. If the result of this determination is that the value has not become greater than the predetermined value (NO in step S206), the process returns to step S203 and is repeated.

[0141] On the other hand, if the counter value n becomes greater than a predetermined value (YES in step S206), the processing unit 41 creates a signature D12 using the hash values ​​of the four first encryption derived keys D08, the client ID_D10, the first specific parameter D11, and the signing key FC-D09 (step S207).

[0142] Next, the processing unit 41 creates certificate data D101 (see Figure 4) which includes four first encryption derived keys D08, client ID_D10, and first specific parameter D11, and is assigned the signature D12 created above. Furthermore, the processing unit 41 writes the certificate data D101 to the non-volatile storage unit 33 of client 3 (step S208). Alternatively, the certificate data may be downloaded or transferred from a predetermined server or other PC and written to the non-volatile storage unit 33 of client 3.

[0143] Next, the details of the authentication process will be explained. In this embodiment, the authentication process consists of a challenge issuance session and a verification session. The challenge issuance session is initiated when a challenge issuance request is made from client 3, and is primarily a session for server 1 to issue challenge data D16 and send it to client 3 (other processes are also performed as described later). The verification session is initiated when a verification request (requesting verification of the response) is made from client 3, and is primarily a session for client 3 to send a response, server 1 to verify this response, and send the result to client 3. In this embodiment, the challenge issuance session and the verification session are separate communication sessions. Note that if server 1 is composed of multiple server devices, the challenge issuance session and the verification session may be executed on separate server devices. The challenge issuance session and the verification session are different communication sessions, and these communication sessions do not constitute a series of processes. Therefore, the issued challenge cannot be used directly when verifying the response. In this embodiment, the data on which the challenge originated is sent to the client along with the challenge, and the client returns that data (the data on which the challenge originated) to the server along with the response. The server then regenerates the challenge from that data, thereby ensuring the relationship between the issued challenge and the response. Figures 19 to 30 illustrate the processes executed by the processing unit 11 of server 1 and the processing unit 31 of client 3. Note that the order of the processes described in Figures 19 to 30 is merely an example, and the order may be changed as appropriate. In addition, multiple processes may be performed in parallel.

[0144] [Details of processing challenge issuance sessions] Figure 19 shows the details of the processing in a challenge issuance session. Figure 19 shows the processing of the processing unit 31 of client 3, which executes the system program (authentication function) CL201, and the processing unit 11 of server 1, which executes the authentication program SV401. In Figure 19, first, the processing unit 31 of client 3 establishes a session with server 1 and sends a request for challenge issuance and certificate data D101 via the network communication unit 35 (step S1).

[0145] Next, the processing unit 11 of server 1 performs the process of receiving certificate data D101 via the network communication unit 15 (step S2).

[0146] Next, the processing unit 11 verifies the signature D12 (step S3). Specifically, the processing unit 11 decrypts the signature D12 using the CA public key SV406. Using the decryption result, it determines whether the four encryption first derived keys D08, client ID_D10, and first specific parameter D11 contained in the certificate data D101 have not been tampered with. If they match, the verification result is determined to be positive. If the decryption result does not match, it is determined to be negative, and the challenge dataset D102 is not sent. The processing is then terminated by notifying client 3 of this fact (communication may be terminated without notification).

[0147] If the verification result is positive, the processing unit 11 extracts the client ID_D10 from the certificate data D101 (step S4). Next, the processing unit 11 executes the challenge generation process (step S5).

[0148] Figure 20 is a flowchart detailing the challenge generation process (step S5). First, the processing unit 11 obtains the current time of the server as the challenge issuance time D15 (step S21).

[0149] Next, the processing unit 11 calculates the first MAC value (challenge data) D16 using the second server key D13 corresponding to the challenge version D14, with respect to the challenge version D14 read from the storage unit 12, the challenge issuance time D15 obtained in step S21, and the client ID_D10 obtained in step S4 (step S22).

[0150] Next, the processing unit 11 generates a challenge dataset D102 that includes the challenge version D14, the challenge issuance time D15, and the first MAC value (challenge data) D16 calculated in step S22 (step S23). This completes the challenge generation process.

[0151] Returning to Figure 19, once the challenge dataset D102 is generated, the processing unit 11 performs the process of sending the challenge dataset D102 to the client 3 via the network communication unit 15 (step S6).

[0152] Next, the processing unit 31 of client 3 receives the challenge dataset D102 via the network communication unit 35 (step S7). After that, the challenge issuance session is terminated (step S8).

[0153] Figure 21 shows the details of the processing in the verification session. First, the processing unit 31 of client 3, which has received the challenge dataset D102, executes the response generation process (step S9).

[0154] Figure 22 is a flowchart detailing the response generation process performed in client 3. In Figure 22, first, processing unit 31 performs the first derived key setting process (step S31).

[0155] Figure 23 is a flowchart showing a first example of the first derived key setting process described above. In Figure 23, the processing unit 31 reads the master key D01, the counter value D02, and the first KDF seed data D03 from the storage unit 32 (step S41).

[0156] Next, the processing unit 31 performs calculations for the first KDF based on the read master key D01, counter value D02, and first KDF seed data D03, and generates the first derived key D05 (step S42). This completes the first derived key setting process.

[0157] In addition, the first derived key D05 calculated in advance may be stored in the storage unit 32. In this configuration, as part of the first derived key setting process, the processing unit 31 may set the first derived key by reading the first derived key data stored in advance from the storage unit 32 (step S43), as shown in Figure 24. In other words, if the client 3 has already calculated the first KDF and stored the first derived key D05 as data, the calculation process using the first KDF may be omitted.

[0158] Returning to Figure 22, the processing unit 31 then executes the second derived key setting process (step S32). Figure 25 is a flowchart of the first example of the second derived key setting process. In Figure 25, the processing unit 31 reads the second KDF seed data D04 from the storage unit 32 (step S51). Next, the processing unit 31 performs calculations on the second KDF based on the first derived key D05 and the second KDF seed data D04 to generate the second derived key (client) D06 (step S52). This completes the second derived key setting process.

[0159] Alternatively, the second derived key (client) D06 calculated in advance may be stored in the storage unit 32. In this configuration, as shown in Figure 26, the processing unit 31 may set the second derived key by reading the data of the second derived key (client) D06 stored in advance from the storage unit 32 (step S53). In other words, if the client 3 has already stored the second derived key, which is data for which the second KDF calculation has been performed, the second KDF calculation process may be omitted. Also, in this example, the first derived key setting process itself may be omitted.

[0160] In this embodiment, the second derived key (client) set by the second derived key setting process is used as the response key (client) in the response generation process.

[0161] Returning to Figure 22, the processing unit 31 then executes the response data generation process (step S34). Figure 27 is a flowchart detailing the response data generation process. First, the processing unit 31 reads the first MAC value (challenge data) D16 from the challenge dataset D102 received in step S8 of Figure 19 (step S61).

[0162] Next, the processing unit 31 calculates the second MAC value (response data) D17 based on the first MAC value (challenge data) D16 and the response key (client) set as described above (the second derived key (client) set by the second derived key setting process) (step S62).

[0163] Next, the processing unit 31 generates a response dataset D103 (see Figure 8 above) which includes the challenge version D14, the challenge issuance time D15, and the second MAC value (response data) D17 calculated above, all of which are included in the challenge dataset D102 received in step S8 of Figure 21 (step S63). This completes the response dataset generation process.

[0164] In this example, the processes in steps S31 to S34 described above are executed in a series of steps as part of the response generation process shown in Figure 22. In other embodiments, the process of setting the response key (client) (steps S31 to S32) may be performed by pre-calculating the data and storing it in the storage unit 32, and then reading it in step S9. For example, the response key (client) data may be executed when client 3 is started and stored in the storage unit 32, and then read in step S9.

[0165] Returning to Figure 21, once the response generation process is complete, the processing unit 31 re-establishes a session with server 1 (which does not have to be the same server device). Then, the processing unit 31 sends the verification request and the client transmission data D104 via the network communication unit 35 to server 1 (step S10). That is, the response dataset D103 generated in step S9, the certificate data D101 read from the storage unit 32, and the second specific parameter D19 are sent to server 1. The system program (authentication function) CL201 may have a function to specify the area where the certificate data D101 is stored, and thereby read the certificate data D101 from the specified area. The response generation and transmission program may also have a function to specify the area where the second specific parameter D19 is stored, and thereby read the second specific parameter from the specified area. Furthermore, the system program (authentication function) CL201 may have a function to obtain (for example, download) certificate data D101 and / or second specific parameter D19 from a predetermined server or PC, and may store the obtained certificate data D101 and / or second specific parameter D19 in the designated area.

[0166] Next, the processing unit 11 of server 1 performs the process of receiving the response dataset D103, certificate data D101, and second specific parameter D19 via the network communication unit 15 (step S11).

[0167] Next, the processing unit 11 performs a verification process (step S12). Figures 28 and 29 are flowcharts detailing the verification process. In Figure 28, first, the processing unit 11 verifies the signature D12 of the received certificate data D101 (step S71). This process is the same as the process described above, so a detailed explanation is omitted.

[0168] If there are no problems with signature verification, the processing unit 11 then extracts the first specific parameter D11 from the certificate data D101 (step S72).

[0169] Next, the processing unit 11 refers to the second KDF seed data identification table SV405 based on the extracted first identification parameter D11 and the second identification parameter D19 received from client 3, and identifies the value of the second KDF seed data D04. The processing unit 11 also refers to the counter value identification table SV404 based on the first identification parameter D11 and the second identification parameter D19, and identifies the counter value D02 (step S73).

[0170] Next, the processing unit 11 retrieves the first derived encryption key D08 corresponding to the identified counter value D02 from the certificate data D101 received from client 3 (step S74).

[0171] Next, the processing unit 11 decrypts the extracted encryption first derived key D08 into the first derived key D05 using the first server key D07 corresponding to the identified counter value D02 (step S75).

[0172] Next, the processing unit 11 performs calculations on the second KDF based on the first derived key D05 and the value of the second KDF seed data D04 identified in step S73, and generates the second derived key (server) D206. This second derived key (server) D206 is used as the response key (server) (step S76). In other words, the response key (server) is set by generating the second derived key D206.

[0173] Next, the processing unit 11 calculates the first MAC value (at time of verification) D216 based on the challenge version D14 and challenge issuance time D15 included in the response dataset D103 received in step S11, the client ID_D10 included in the certificate data D101 received in step S11, and the second server key D13 corresponding to the challenge version D14 (step S77).

[0174] Next, the processing unit 11 calculates the second MAC value (during verification) D217 based on the first MAC value (during verification) D216 and the response key (server) set in step S76 (second derived key (server) D206 generated in step S76) (step S78). The calculation algorithm in this process is the same as the algorithm for calculating the second MAC value in client 3.

[0175] Next, the processing unit 11 verifies whether the second MAC value (response data) D17 received from the client matches the second MAC value (verification time) D217 calculated by the server 1 (step S79).

[0176] Next, the processing unit 11 determines whether the results of the above verification match (step S80). If they do not match (NO in step S80), the processing unit 11 executes a process to return an error to client 3 (step S83). After that, the verification process ends. On the other hand, if they match (YES in step S80), the response data D17 received from client 3 is considered to be valid. Note that since the MAC value is calculated using the client ID, if the second MAC value (response data) and the second MAC value (verification time) match, it can be determined that the client to which the challenge data was issued in the challenge issuance session and the client to which the response data D17 etc. was sent in the verification session are the same client 3 (they match). Note that it is not necessary to compare the client ID itself in the challenge issuance session and the client ID in the verification session.

[0177] If the answer in step S80 is YES, the processing unit 11 performs verification from a temporal perspective. Specifically, the processing unit 11 determines whether the current time of server 1 has elapsed for a certain amount of time since the challenge issuance time D15 included in the received response dataset D103. If the result of this determination is that the time has elapsed (YES in step S81), the process proceeds to step S83, and the process of returning an error to client 3 is executed. On the other hand, if the time has not elapsed (NO in step S81), the processing unit 11 determines that the legitimacy of client 3 has been confirmed and the verification has been successful, and generates a predetermined service token. After that, the response verification process ends.

[0178] In the example above, we showed a process where the second MAC value was verified first, followed by verification from a temporal perspective. However, the order of these verifications can be reversed.

[0179] Returning to Figure 21, once the response verification process is complete, the processing unit 11 then performs the process of sending a predetermined service token to the client via the network communication unit 15 if the verification was successful (step S13).

[0180] Next, the processing unit 31 of client 3 performs the process of receiving a service token via the network communication unit 35 (step S14). After that, the response session is terminated (step S15).

[0181] Next, the processing unit 31 passes the service token to the application, which in this embodiment is the online game program (step S16). As a result, the online game program uses this service token to request a service from a predetermined server, and the server provides the online game service.

[0182] Furthermore, any communication method may be used for the communication related to the challenge issuance session and the verification session. For example, it may be conducted using encrypted communication such as SSL, or it may be conducted using unencrypted communication.

[0183] Next, using Figure 30, an example of online game processing in client 3 that utilizes the authentication process described above will be explained. In Figure 30, first, the processing unit 31 receives a request to start an online game (step S101). For example, the processing unit 31 receives an online game startup operation from the user.

[0184] Next, the processing unit 31 starts the system software (authentication function). This performs the authentication process described above.

[0185] Next, the processing unit 31 determines whether or not it has received a service token from the system software (step S109). If the result of this determination is that it has not been received (NO in step S103), it waits until it is received.

[0186] On the other hand, if a service token is received (YES in step S103), the processing unit 31 then uses the received service token to request a service from the online game server (step S104).

[0187] Subsequently, the processing unit 31 executes the online game while communicating with the online game server and other clients 3 as needed (step S105). Next, the processing unit 31 determines whether the conditions for terminating the online game have been met (step S106). If the conditions have not been met (NO in step S106), the execution of the online game continues; if the conditions have been met (YES in step S106), the online game process terminates.

[0188] This concludes the detailed explanation of each process according to this embodiment.

[0189] [Differentiation] In other embodiments, the configuration may be such that a counter value is not used as the seed data for the first KDF. That is, the configuration may be such that the first KDF is calculated using the master key D01 and the first KDF seed data D03 to generate the first derived key D05. In this case, the certificate will contain one encrypted first derived key D05. It goes without saying that the counter value is not limited to values ​​between 0 and 3. Furthermore, a predetermined variable value may be used instead of the counter, and it does not have to be changed by an incrementing method.

[0190] Furthermore, the above embodiment shows an example in which KDF calculation is performed in two stages, a first KDF calculation and a second KDF calculation, in the response key setting process. In other embodiments, the KDF calculation may be performed in one stage, or the number of KDF calculation stages may be increased further, and the result of a further KDF calculation (derived key) performed after the second KDF calculation may be set as the response key. As for the "further KDF calculation," for example, a KDF calculation may be performed using data on the volatile memory or non-volatile memory of client 3 or data processed therefrom as seed data. This data on memory may be different for each version of the system software.

[0191] Furthermore, in the above embodiment, the response key setting process in Server 1 identified and used the second KDF seed data D04 based on the first specific parameter D11 and the second specific parameter D19. In other embodiments, however, the response key may be set without using these parameters. For example, the second KDF seed data may be identified using a single parameter, or the second KDF seed data itself may be sent from Client 3 to Server 1. Alternatively, if the second KDF seed data is common to all clients, the second KDF seed data can be stored in Server 1.

[0192] Furthermore, in the above embodiment, the calculation of the first KDF is not performed on server 1, but it is also possible to have server 1 identify the master key D01 and the first KDF seed data and perform the calculation of the first KDF on server 1. In that case, the encrypted first derived key D08 in the certificate data D101 becomes unnecessary. In this case, the data obtained by encrypting the master key D01 with the first server key may be included in the certificate data D101. Then, server 1 should decrypt the master key D01 and perform the first KDF processing described above to obtain the first derived key D05.

[0193] Furthermore, regarding the generation of challenge data, the above example shows how to calculate the first MAC value by performing a MAC operation using the second server key. In other embodiments, a configuration that performs a signature instead of a MAC operation may be used. For example, an RSA signature may be used.

[0194] Furthermore, regarding the generation of response data using the above response key, instead of calculating the second MAC value, the response data may be generated using a blocking encryption operation. The blocking encryption operation may be, for example, AES.

[0195] In another embodiment, when client 3 sends response data D17, it may be configured to send a parameter for identifying the current value of counter value D02 along with the response data D17. Server 1 may then use this transmitted parameter to identify counter value D02 and set the response key using the process described above.

[0196] Furthermore, although the challenge issuance session and the verification session were treated as separate communication sessions in the above embodiment, challenge issuance and verification may be performed in a single session.

[0197] Furthermore, although the encrypted derived key was included in the client certificate in the above embodiment, the encrypted derived key may also be sent to the server separately from the client certificate when sending response data. This is similar to the first parameter for identifying the second KDF seed data. The second parameter for identifying the second KDF seed data may also be included in the certificate, and the certificate, etc., may be separately signed and sent. [Industrial applicability]

[0198] The information processing system described herein can provide a novel authentication method for authenticating a client's device. [Explanation of Symbols]

[0199] 1 server 3 clients 4 PC 11 Processing Section 12 Storage section 13 Non-volatile memory unit 14. Volatile memory 15 Network Communications Department 16 Operating devices 17 Image Output Unit 31 Processing Unit 32 Storage section 33 Non-volatile memory unit 34. Volatile memory unit 35 Network Communications Department 36 Operating Devices 37 Image output section 41 Processing Unit 42 Storage section 43 Non-volatile memory unit 44. Volatile memory unit 45 Network Communications Department 46 Operating Devices 47 Image output section

Claims

1. An information processing system comprising a client connected to a network and a server, wherein authentication processing of the client is performed between the client and the server using a challenge-and-response method, The server includes means for issuing challenge data and transmitting it to the client. The aforementioned client, means for storing calculated data which is the result of performing at least some of the calculations for setting the server-side response key, A means of setting the client-side response key, A means for receiving the transmitted challenge data, A means for generating response data from the received challenge data based on the client-side response key set above, Means for sending the generated response data to the server, The server comprises means for transmitting the calculated data stored therein, The aforementioned server further, Means for receiving the transmitted response data, means for receiving the transmitted processed data, A means for setting the server-side response key based on the received calculated data, A means for verifying the received response data based on the challenge data and the configured server-side response key, The system includes means for notifying the client of the results based on the verification, The aforementioned client further stated, An information processing system comprising means for receiving the aforementioned results.

2. The information processing system according to claim 1, wherein the setting of the client-side response key is performed without using the calculated data.

3. The aforementioned calculation includes a first calculation and a second calculation performed based on the result of the first calculation. The calculated data is the result of performing the first calculation, The information processing system according to claim 1 or 2, wherein the setting of the server-side response key is performed by executing the second calculation based on the received calculated data.

4. The aforementioned client further stated, means for storing second calculation data, which is data used when performing the second calculation, The system includes means for transmitting the second calculation data, The aforementioned server further, The system includes means for receiving the transmitted second calculation data, The information processing system according to claim 3, wherein the setting of the server-side response key is performed by executing the second calculation based on the received calculated data and the second calculation data.

5. The calculated data is signed data which includes the calculated data and at least signature data of the data containing the calculated data. The information processing system according to claim 1 or 2, wherein the setting of the response key on the server side is performed based on the verified signature and the calculated data.

6. The client further stores data for the second operation, which is data used when performing the second operation. The calculated data is stored as a set of signed data, which includes the second calculation data and at least the signature data of that data. The information processing system according to claim 3, wherein the setting of the response key on the server side is performed based on the verification of the signature and the calculated data and the second calculation data.

7. The calculated data is encrypted data obtained by encrypting the calculated data with a server key. The information processing system according to claim 1 or 2, wherein the setting of the server-side response key is performed by decrypting the encrypted data with the server key.

8. The aforementioned client further stated, In the setting of the response key on the server side, there is a means for storing unsigned data, which is data different from the data used for the second calculation and is not signed, which is used when performing the second calculation. The system includes means for transmitting the unsigned data to the server, The aforementioned server further, The system includes means for receiving the transmitted unsigned data, The information processing system according to claim 6, wherein the server-side response key is set based on the calculated data, the second calculation data, and the unsigned data.

9. The information processing system according to claim 8, wherein the setting of the server-side response key is performed based on data identified based on the combination of the second calculation data and the unsigned data.

10. The communication session for authentication processing between the server and the client includes a first communication session in which the challenge data is sent and received, and a second communication session which is a different communication session from the first communication session in which the response data is sent and received, the response data is verified, and the results of the verification are sent and received. The information processing system according to claim 1 or 2, wherein the server device for the first communication session and the server device for the second communication session are permitted to be different.

11. The client further includes means for transferring the received challenge data to the server. The server further includes means for receiving the transferred challenge data, The information processing system according to claim 10, wherein the verification involves reproducing the challenge data based on the transmitted challenge data and verifying the received response data.

12. The information processing system according to claim 1 or 2, wherein the calculated data has different values ​​depending on the client.

13. A client in the information processing system according to claim 1 or 2.

14. An information processing program for causing a computer to function as each of the means provided by a client in the information processing system described in claim 1 or 2.

15. A server in the information processing system according to claim 1 or 2.

16. An information processing program for causing a computer to function as each of the means provided by the server in the information processing system described in claim 1 or 2.

17. The client computer performs authentication processing with the server using a challenge-response method. The process of setting the client-side response key, The process of receiving challenge data transmitted from the aforementioned server, A process to generate response data from the received challenge data based on the set response key, The process of sending the generated response data to the server, The process involves reading calculated data from the client's memory, which is the result of performing at least some of the calculations for setting the server-side response key. The process of sending the calculated data to the server, A program that executes a process to receive the results from the server based on the verification of the response data, which is performed based on the server-side response key set based on the calculated data.

18. The program according to claim 17, wherein the setting of the client-side response key is performed without using the calculated data.

19. The calculation includes a first calculation and a second calculation performed on the server based on the result of the first calculation. The program according to claim 17 or 18, wherein the calculated data is the result of performing the first calculation.

20. The aforementioned computer further, The process involves reading the second calculation data, which is the data used when performing the second calculation on the server, from the client's memory. The process of sending the second calculation data to the server is executed. The program according to claim 19, wherein the verification is performed using a server-side response key set by the second calculation based on the calculated data and the second calculation data.

21. The program according to claim 17 or 18, wherein the calculated data is signed data that includes the calculated data and signature data of the data including at least the calculated data.

22. The information processing system according to claim 20, wherein the calculated data is stored as a set of signed data including the second calculation data and signature data of the data including at least the above.

23. The program according to claim 17 or 18, wherein the calculated data is encrypted data obtained by encrypting the calculated data with a predetermined server key.

24. The aforementioned computer further, The process of reading unsigned data, which is different from the data used for the second calculation and is not signed, from the client's memory, which is used when the server performs the second calculation, The process of sending the aforementioned unsigned data to the server is executed. The program according to claim 22, wherein the verification is performed using a server-side response key set based on the calculated data, the second calculation data, and the unsigned data.

25. The communication session for authentication processing between the server and the client includes a first communication session in which the challenge data is sent and received, and a second communication session which is a different communication session from the first communication session in which the response data is sent and received, the response data is verified, and the results of the verification are sent and received. The program according to claim 17 or 18, wherein the server device for the first communication session and the server device for the second communication session are permitted to be different.

26. The program according to claim 25, further comprising causing the computer to perform a process of transferring the received challenge data to a server for playback.

27. The program according to claim 17 or 18, wherein the calculated data has different values ​​depending on the client.

28. The program according to claim 17 or 18, further comprising causing the computer to perform a process to specify an area in which the calculated data is stored.

29. The program according to claim 24, further comprising causing the computer to perform a process to specify an area in which the calculated data is stored and a process to specify an area in which the unsigned data is stored.

30. A computer-based information processing method comprising a client connected to a network and a server, wherein authentication processing of the client is performed between the client and the server using a challenge-and-response method, The server issues challenge data and sends it to the client. The aforementioned client, The calculated data, which is the result of performing at least some of the calculations for setting the server-side response key, is obtained from the client's memory. Without using the aforementioned calculated data, set the client-side response key, The challenge data transmitted from the aforementioned server is received, Based on the set response key, response data is generated from the received challenge data. The generated response data and the acquired calculated data are sent to the server. The aforementioned server further, The response data and the calculated data are received, Based on the received calculated data, set the server-side response key. Based on the challenge data and the configured server-side response key, the response data sent from the client is verified. The results based on the above verification are notified to the client. The aforementioned client further stated, An information processing method for receiving the aforementioned result.

Images