Information processing system, information processing method, information processing program, client, server, program

Abstract

Provided is an information processing system, an information processing method, an information processing program, a client, a server, and a program. The server issues challenge data and transmits the challenge data to the client. The client stores calculated data that is a result of performing at least a part of an operation for setting a response key on the server side, sets a response key on the client side without using the calculated data, generates response data from the challenge data received from the server based on the response key, and transmits the generated response data and the stored calculated data to the server. The server receives the response data and the calculated data, sets a response key on the server side 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 a result of the verification.

Description

[0001] This application is a divisional application of Chinese invention patent application filed on December 5, 2024, with application number 202480005239.X (PCT / JP2024 / 043100) and entitled "Information Processing System, Information Processing Method, Information Processing Program, Client, Server". Technical Field

[0002] This disclosure relates to a device authentication method that utilizes a challenge-response approach. Background Technology

[0003] Previously, challenge-response based authentication methods have been known as methods for authenticating client devices (e.g., non-patent literature 1).

[0004] Existing technical documents

[0005] Non-patent literature

[0006] Non-patent document 1: RFC Editor, "RFC7616", [online], [searched on August 29, 2007], Internet (URL: https: / / www.rfc-editor.org / info / rfc7616) Summary of the Invention

[0007] The problem the invention aims to solve

[0008] There is room for developing new methods regarding the aforementioned challenge-response approach to device authentication.

[0009] Solution for solving the problem

[0010] In view of the above points, the following structural example can be cited, for example.

[0011] (Structure 1)

[0012] Structure 1 is an information processing system that includes a client and a server connected to a network, and the client performs authentication processing between the client and the server through a challenge-response method.

[0013] The server has a unit that issues challenge data and sends the challenge data to the client.

[0014] The client includes: a unit for storing computed data, the computed data being the result of performing at least a portion of a computation for setting a response key on the server side; a unit for setting a response key on the client side; a unit for receiving the sent challenge data; a unit for generating response data based on the received challenge data and the set response key on the client side; a unit for sending the generated response data to the server; and a unit for sending the stored computed data to the server.

[0015] The aforementioned server (the term "server group" can refer to a server device different from the server device that issues challenge data and sends the challenge data to the client) further includes: a unit for receiving sent response data; a unit for receiving sent processed data; a unit for setting a server-side response key based on the received processed data; a unit for verifying the received response data based on the challenge data and the server-side set response key; and a unit for notifying the client of the verification result. The aforementioned client also includes a unit for receiving the aforementioned result.

[0016] Based on the above structure, at least a portion of the server-side computation used to set the response key can be omitted, allowing the server to avoid holding at least a portion of the various data used in the computation (key data, seed data, etc.), thereby reducing the risk of this data being leaked from the server. Furthermore, for example, when the values ​​and formulas used in the computation differ depending on the client, the increase in information processing on the server side can also be suppressed.

[0017] (Structure 2)

[0018] Structure 2 can also be an example of Structure 1, where the client-side response key is set in a way that does not use the already computed data.

[0019] (Structure 3)

[0020] Structure 3 can be in structure 1 or 2, and the above operation includes a first operation and a second operation based on the result of the first operation. The already operated data is the result obtained by performing the first operation, and the server-side response key is set by performing the second operation based on the received above-mentioned already operated data.

[0021] Based on the above structure, regarding multiple aspects of the elements to be verified, by performing some calculations in advance and another part of the calculations on the server, verification can be performed using a method corresponding to the properties of the elements to be verified.

[0022] (Structure 4)

[0023] Structure 4, in addition to Structure 3, may also include: a unit for storing second computation data, which is data used during the second computation; and a unit for sending the second computation data. Furthermore, it may also include a unit for receiving the sent second computation data, whereby the server-side response key is set by performing the second computation based on the received computed data and the second computation data.

[0024] (Structure 5)

[0025] Structure 5 can be any of structures 1 to 4, where the computed data is signed data that includes both computed data and signature data, and the signature data is signed data that includes at least the computed data. The server-side response key is set to verify the signature and is based on the computed data.

[0026] (Structure 6)

[0027] Structure 6, in addition to Structure 3, may also include the client storing second computational data, which is the data used when performing the second computation. The already computed data may also be stored as a single signed data that includes the second computational data and at least the signature data of the already computed data and the second computational data. The server-side response key setting may also be based on signature verification and the already computed data and the second computational data.

[0028] (Structure 7)

[0029] Structure 7 can be any of structures 1 to 6, or it can be that the computed data is encrypted using the server key to encrypt the computed data, and the server-side response key can be set by decrypting the encrypted data using the server key.

[0030] Based on the above structure, confidential data can be sent from the client to the server for setting the response key on the server side.

[0031] (Structure 8)

[0032] Structure 8 can also be derived from Structure 6, where the client further includes a unit for storing unsigned data. This unsigned data is data that is different from the data used in the second operation and is not signed, and is used in the setting of the response key on the server side. The server may also include a unit for receiving the sent unsigned data. The setting of the response key on the server side may also be based on the already operated data, the data used in the second operation, and the unsigned data.

[0033] Based on the above structure, both signable and unsignable data can be sent from the client to the server for setting the response key on the server side.

[0034] (Structure 9)

[0035] Structure 9, in addition to Structure 8, can also be a case where the server-side response key is set based on data determined by a combination of the second computational data and the unsigned data.

[0036] (Structure 10)

[0037] Structure 10 may be any of structures 1 to 9, in which the communication session between the server and the client for authentication processing includes a first communication session for sending and receiving challenge data and a second communication session different from the first communication session, wherein in the second communication session, the sending and receiving of response data, the verification of the response data and the sending and receiving of the results are performed, and the server device of the first communication session may be different from the server device of the second communication session.

[0038] (Structure 11)

[0039] Structure 11, in addition to Structure 10, may also include a unit in which the client forwards the received challenge data to the server, and the server may also have a unit in which it receives the forwarded challenge data. During verification, challenge data may be regenerated based on the forwarded challenge data, and the received response data may be verified.

[0040] (Structure 12)

[0041] Structure 12 can also be derived from Structure 1, where the client further includes a unit that transmits specified information to the application when the received authentication result is positive.

[0042] (Structure 13)

[0043] Structure 13, in addition to Structure 1, may also include an authentication result containing data for utilizing the specified online service, and the client may also have a unit that transmits the data contained in the authentication result for utilizing the online service to the application.

[0044] (Structure 14)

[0045] Structure 14, in addition to Structure 1, may also include a unit in which the client utilizes the prescribed online services if the authentication result is positive.

[0046] (Structure 15)

[0047] Structure 15, in structure 1, can also be that the computed data has different values ​​depending on the client.

[0048] (Structure 16)

[0049] Structure 16 can be in structure 2, or the second operation data can have different values ​​depending on the client.

[0050] (Structure 17)

[0051] Structure 17 can be found in Structure 8, and the unsigned data can have different values ​​depending on the client.

[0052] (Structure 18)

[0053] Structure 18 can also be a client in an information processing system of any of Structures 1 to 17.

[0054] (Structure 19)

[0055] Structure 19 can also be an information processing program that enables the various units of a computer as a client in any of the information processing systems of structures 1 to 17 to perform their functions.

[0056] (Structure 20)

[0057] Structure 20 can also be a server in the information processing system of any of Structures 1 to 17.

[0058] (Structure 21)

[0059] Structure 21 can also be an information processing program that enables the various units of a computer to function as a server in any of the information processing systems of structures 1 to 17.

[0060] (Structure 22)

[0061] Structure 22 is a program for causing a client computer, which performs challenge-response authentication with a server, to perform the following processes: setting a client-side response key; receiving challenge data sent from the server; generating response data based on the received challenge data and the set response key; sending the generated response data to the server (meaning a group of servers, which may be a separate server different from the individual server that issues the challenge data and sends it to the client); reading computed data from the client's memory, the computed data being the result of performing at least a portion of the computations used to set the server-side response key; sending the computed data to the server; and receiving from the server a verification result based on the response data, the verification of which is based on the server-side response key set according to the computed data.

[0062] (Structure 23)

[0063] Structure 23, in addition to structure 22 above, can also be that the response key on the client side is set in a way that does not use the already computed data.

[0064] (Structure 24)

[0065] Structure 24 can also be in the same way as structure 22 or 23 above, where the operation includes a first operation and a second operation performed on the server based on the result of the first operation, and the operated data can also be the result obtained by performing the first operation.

[0066] (Structure 25)

[0067] Structure 25, in the above structure 19, may also involve the computer performing the following processes: reading second computation data from the client's memory, the second computation data being the data used when performing the second computation on the server; and sending the second computation data to the server. The above verification may also be performed using a server-side response key, which is set by the second computation based on the computed data and the second computation data.

[0068] (Structure 26)

[0069] Structure 26 can also be in the same way as structure 22 or 23 above, where the computed data is signed data that includes both computed data and signature data, and the signature data is signed data that includes at least the computed data.

[0070] (Structure 27)

[0071] Structure 27, in the above structure 25, can also be a signed data that integrates the computed data into a single unit, which includes second computation data and signature data that includes at least the computed data and the second computation data.

[0072] (Structure 28)

[0073] Structure 28, in the above structures 22 or 23, can also be encrypted data obtained by encrypting the computed data with a specified server key.

[0074] (Structure 29)

[0075] Structure 29, in addition to structure 27, may also involve the computer performing the following processes: reading unsigned data from the client's memory, the unsigned data being unsigned data that is different from the data used in the second operation and is used in the second operation on the server; and sending the unsigned data to the server. Furthermore, verification may be performed using a server-side response key, which is set based on the already operated data, the data used in the second operation, and the unsigned data.

[0076] (Structure 30)

[0077] Structure 30, in structure 22 or 23 above, may also be a communication session between the server and the client for authentication processing that includes a first communication session for sending and receiving challenge data and a second communication session different from the first communication session. In the second communication session, response data is sent and received, response data is verified, and the result of the response data is sent and received. It is also permissible for the server device of the first communication session to be different from the server device of the second communication session.

[0078] (Structure 31)

[0079] Structure 31, in the above structure 30, may also enable the computer to perform the following processing: forwarding the received challenge data to regenerate the challenge data in the server.

[0080] (Structure 32)

[0081] Structure 32, in the above structure 22, may also be configured to enable the computer to perform the following process: upon receiving an affirmative authentication result, transmit the specified information to the application program.

[0082] (Structure 33)

[0083] Structure 33, in the above structure 22, may also include authentication results containing data for utilizing specified online services, or may enable the computer to perform processing that passes the data for utilizing online services contained in the received authentication results to the application.

[0084] (Structure 34)

[0085] Structure 34, in the above structure 22, can also be a process that enables the computer to perform service utilization processing using the prescribed online service if the received authentication result is positive.

[0086] (Structure 35)

[0087] Structure 35, in the above structures 22 or 23, can also be a case where the computed data has different values ​​depending on the client.

[0088] (Structure 36)

[0089] Structure 36, in the above structure 35, can also be that the data used for the second operation has different values ​​depending on the client.

[0090] (Structure 37)

[0091] Structure 37 can also be an example of structure 36 above, where the unsigned data has different values ​​depending on the client.

[0092] (Structure 38)

[0093] Structure 38, in addition to structures 22 to 37 above, may also enable the computer to perform the following process: specifying a region for storing processed data.

[0094] (Structure 39)

[0095] Structure 39, in the above structure 29, may also enable the computer to perform the following processes: specifying a region for storing processed data; and specifying a region for storing unsigned data.

[0096] (Structure 40)

[0097] Structure 40 is an information processing method executed by a computer. This method includes a client and a server connected to a network, and client authentication is performed between the client and server using a challenge-response method. The server issues challenge data and sends it to the client. The client performs the following processing: retrieves computed data from its memory, the computed data being the result of performing at least a portion of the computations used to set a response key on the server side; sets the client-side response key without using the computed data; receives the challenge data sent from the server; generates response data based on the set response key and the received challenge data; and sends the generated response data and the retrieved computed data to the server. The server also performs the following processing: receives the response data and the computed data; sets the server-side response key based on the received computed data; verifies the response data sent from the client based on the challenge data and the server-side set response key; and notifies the client of the verification result. The client also performs the following processing: receives the above result.

[0098] (Structure 41)

[0099] Structure 41 is a data structure related to device authentication processing via challenge-response. This data structure is stored on the client and sent to the server for use in authentication processing within the server. The data structure includes at least: computed data, which is the result of performing a first operation, a subset of the computations used to set the server-side response key; and first data, which is used in a second operation, a subset of the computations used to set the server-side response key. In the server, this data structure is used to set the server-side response key by performing the second operation based on the computed data and the first data.

[0100] (Structure 42)

[0101] Structure 42, which is in structure 41, may also include multiple computed data. In the server, the computed data to be used is selected from the multiple computed data based on the first data.

[0102] (Structure 43)

[0103] Structure 43, in structure 41 or 42, can also be data that has been processed and is encrypted with the result of a part of the first operation, which is performed using the specified server key to set the response key on the server side.

[0104] (Structure 44)

[0105] Structure 44 may be in structure 41 or 42, and may also include a signature of the processed data and the first data. In the server, the signature is verified, and a second operation is performed based on the processed data and the first data.

[0106] (Structure 45)

[0107] Structure 45 may be in structure 41 or 42, and may also include the client's client ID, which is sent to the server when the challenge is issued and when the response is received. The server performs a confirmation process on the consistency between the client at the time of challenge issuance and the client at the time of response based on the client ID received when the challenge is issued and the client ID received when the response is received. Attached Figure Description

[0108] Figure 1 This is a schematic diagram showing the overall system of this embodiment.

[0109] Figure 2 This is a diagram used to illustrate the overview of the response key setting process.

[0110] Figure 3 This is a diagram showing an overview of the certificate creation process.

[0111] Figure 4 This is an example of the structure of certificate data D101.

[0112] Figure 5 This is a diagram illustrating an overview of the processing of the generation and transmission of the challenge dataset.

[0113] Figure 6 This is an example of the structure of the challenge dataset D102.

[0114] Figure 7 This is a diagram illustrating an overview of the generation and processing of the response dataset.

[0115] Figure 8 This is an example of data sent by client 3 to server 1.

[0116] Figure 9 This is a diagram showing an overview of the response key setting process in server 1.

[0117] Figure 10 This is an example of the data structure for the counter value determination table SV404.

[0118] Figure 11 This is an example of the data structure of the second KDF seed data determination table SV405.

[0119] Figure 12 This is a diagram used to illustrate the overview of the verification process.

[0120] Figure 13 This is a block diagram showing the hardware structure of client 3.

[0121] Figure 14 This is an example of data stored in storage unit 32 of client 3.

[0122] Figure 15 This is a diagram used to illustrate the functional structure of the system program CL201.

[0123] Figure 16 This is an example of data stored in storage unit 12 of server 1.

[0124] Figure 17 This is an example of data stored in the storage unit 42 of PC 4.

[0125] Figure 18 This is an example of a flowchart for certificate generation and writing processes.

[0126] Figure 19 This is a diagram showing the details of the processing during the challenge issuance session.

[0127] Figure 20 This is a flowchart illustrating the details of the challenge generation process.

[0128] Figure 21 This is a diagram showing the details of the processing in the verification session.

[0129] Figure 22 This is a flowchart illustrating the details of the response generation process.

[0130] Figure 23 This is a flowchart illustrating the first example of the first derived key setting process.

[0131] Figure 24 This is a flowchart illustrating a second example of the first derived key setting process.

[0132] Figure 25 This is a flowchart illustrating the first example of the second derived key setting process.

[0133] Figure 26 This is a flowchart illustrating a second example of the second derived key setting process.

[0134] Figure 27 This is a flowchart illustrating the details of the response dataset generation process.

[0135] Figure 28 This is a flowchart showing the details of the verification process.

[0136] Figure 29 This is a flowchart showing the details of the verification process.

[0137] Figure 30 This is a flowchart illustrating the details of online game processing. Detailed Implementation

[0138] The following describes the implementation method.

[0139] This embodiment relates to a process related to device authentication. In this embodiment, the following process will be described as an example: Device authentication is performed when a specified communication service is provided to a device, or when a specified function of the device is enabled to be performed (more specifically, for example, when providing online services such as online games, matchmaking, or accessing online stores (software or content download sites)). In device authentication, the legitimacy of the client device (hereinafter referred to as the client) is verified.

[0140] In this embodiment, a challenge-response method is used as the device authentication method. In this method, authentication is performed using the following approach: First, in... Figure 1 The overall structure of the authentication processing system involved in this embodiment is schematically shown. Figure 1In this configuration, the client authentication server (hereinafter referred to as server) 1 and the client device (hereinafter referred to as client) 3 are connected via a network. Furthermore, server 1 may also consist of multiple server devices. In this configuration, firstly, (1) client 3, wishing to start an online game, requests challenge data from server 1 (in this embodiment, it is different from the server providing the online game). (2) In response to the request, server 1 generates challenge data and sends it to client 3. (3) client 3 performs prescribed calculations 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 prescribed data corresponding to the success or failure of the verification to client 3, thereby authenticating the legitimacy of client 3. In the case of a server consisting of multiple server devices, the server device performing the above-mentioned (2) processing may be different from the server device performing (4) processing.

[0141] Next, an overview of the device authentication process (hereinafter referred to as authentication process) using the challenge-response method in this embodiment will be explained. First, the "response key" used in the authentication process will be explained.

[0142] [About the response key]

[0143] The response key is key data used in the process of creating the response data. The response data is generated by processing the challenge data received from server 1 using this response key.

[0144] Figure 2 This is a diagram illustrating the outline of the response key setting process in this embodiment, schematically showing the data flow in this process. Figure 2 In the diagram, features shown as ellipses represent data / parametric features, and features shown as rectangles represent processing features. Furthermore, for ease of explanation, in... Figure 2 The data / parametric elements are labeled with reference markers in the form of "Dnn" (where nn is an integer). Subsequent figures will also feature the same reference markers.

[0145] exist Figure 2In the example shown, a key derivation function (KDF) is used to generate key data based on specified data, and the generated key data is set as the response key. Here, KDF refers to a function used to generate another key based on key data. When key data and specified data called seed data are input to the KDF, another key data based on them is generated. Hereinafter, the key data output using the KDF will be referred to as the "derived key". In addition, in this embodiment, the derived key data generated using a multi-level KDF (a two-level KDF in this embodiment) will be used as the response key. In the following description, the first-level KDF will be referred to as the "first KDF", the second-level KDF will be referred to as the "second KDF", the key data output by the first KDF will be referred to as the "first derived key data" or simply the "first derived key", and the key data output by the second KDF will be referred to as the "second derived key data" or simply the "second derived key". Furthermore, the operation content of each KDF can be arbitrary, for example, KDFs that use HMAC or CMAC as PRFs, KDFs that use hash functions or block encryption, etc. In addition, the operations performed by each level of KDF can be the same or different.

[0146] use Figure 2 The process of setting the response key is explained. The response key setting process is performed on both the server and the client, but in this embodiment, as described below, the response key setting process performed on the server differs from the response key setting process performed on the client. Figure 2 This section explains the setting process of the response key performed on client 3. Furthermore, the response key set on client 3 is sometimes referred to as the "response key (client)", and the response key set on server 1 is sometimes referred to as the "response key (server)". Additionally, the second derived key calculated on client 3 is sometimes referred to as the "second derived key (client)", and the second derived key calculated on server 1 is sometimes referred to as the "second derived key (server)".

[0147] First, the client 3 stores the master key D01, counter value D02, first KDF seed data D03, and second KDF seed data D04 in its storage. The master key D01 is the key data input to the first KDF. The master key D01 can be a fixed value or it can be changed. Furthermore, the master key D01 can vary depending on the client. When using emulator technology to implement the client, it can be the same as the master key of the object to be emulated.

[0148] Counter value D02, first KDF seed data D03, and second KDF seed data D04 are the seed data used as KDFs. Counter value D02 can take different values ​​depending on the client 3. For example, it can be a value that changes in response to system updates or other events on the client 3. Specifically, counter value D02 is incremented by 1 each time. In this embodiment, as an example, the case where the counter value can take any of the four values ​​from 0 to 3 will be described. Furthermore, in this embodiment, the initial value of counter value D02 is 0.

[0149] The first KDF seed data D03 is the seed data input to the first KDF, and can take different values ​​depending on the client 3. The second KDF seed data D04 is the seed data input to the second KDF, and can take different values ​​depending on the client 3. These seed data can be arbitrary data. For example, the first KDF seed data D03 can be a fixed value, or more specifically, it can be identification data representing a certain characteristic of the client 3. For example, it can be identification data representing either the development machine or the production machine. Furthermore, when using emulator technology to implement the client, this identification data can be data representing the characteristics of the object to be simulated. In addition, the second KDF seed data D04 can be data that the client 3 can set or change according to its own instructions or instructions from external sources such as the server. More specifically, it can be identification data representing other characteristics of the client 3 (e.g., data representing security settings). In addition, it can also be data that varies depending on the system version (data updated through version upgrades). Furthermore, when using emulator technology to implement the client, this identification data can be data representing the characteristics of the object to be simulated. In addition, each KDF seed data D03 and D04 can be changed, for example, through system software updates. In addition, the first KDF seed data D03 and the second KDF seed data D04 can both be different values ​​depending on the client.

[0150] In this data set, the master key D01, the (current) counter value D02, and the first KDF seed data D03 are first input into the first KDF. The result is the generation of the derived key, the "first derived key" D05, which is output through the first KDF operation.

[0151] Next, the second KDF seed data D04 and the generated first derived key D05 are input into the second KDF. This generates the derived key output by the second KDF operation, namely the "second derived key (client)" D06.

[0152] Furthermore, 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 and is used in the subsequent processing of generating the response dataset D103.

[0153] Furthermore, the calculations of each KDF in the response key setting process can be performed at runtime (i.e., calculated each time authentication is performed), but the pre-calculated results can also be stored and read during authentication, thus avoiding calculations each time. For example, the first derived key data and / or the second derived key data could be calculated and stored when the client 3's system starts up, and then read during authentication to set the response key. Alternatively, the calculated data (first derived key data and / or second derived key data) could be obtained from an external source and stored, and then read during authentication to set the response key. Alternatively, one of the first KDF calculations and the second KDF calculations could be set to be performed at runtime, while the other is set to read pre-calculated data.

[0154] As described above, in this embodiment, the response key setting process performed in server 1 is different from the response key setting process performed in client 3. One difference is that the response key setting process performed in server 1 does not perform the first KDF operation. More specifically, the result of the first KDF operation, i.e., the processed data (first derived key data; in this embodiment, as described later, the encrypted first derived key data), is written to the storage of client 3 beforehand (before the authentication process begins, for example, in the prior setting process of client 3). Furthermore, during the authentication process, this processed data is sent from client 3 to server 1, and server 1 uses this processed data to perform the second KDF operation without performing the first KDF operation to set the response key. In this embodiment, as described later, this processed data is included in the client certificate data (hereinafter referred to as certificate data).

[0155] Here, the method for generating certificate data is explained. The aforementioned certificate data is pre-stored in client 3 (before the authentication process begins). This certificate data is written to the storage unit of client 3 (described later) during the configuration process of client 3. Figure 3 This is a schematic diagram illustrating the outline of the certificate creation process in the case where the write process is performed by a PC (hereinafter referred to as PC 4). Figure 3First, the master key D01, counter value D02, and first KDF seed data D03 of the client 3 (the object of manufacturing) are input into the first KDF. This generates the first derived key D05. Furthermore, the master key D01 can be read, for example, from the client 3 connected to the PC 4 and used for writing certificate data. Here, as described above, the counter value D02 can take four values ​​in this embodiment. Therefore, the operation of the first KDF in the PC 4 is performed for each possible value (0~3) of the counter value D02, generating the first derived key D05 corresponding to each value of the counter value D02. That is, in this example, four first derived keys D05 are generated. Hereinafter, when referring to these four first derived keys D05 independently, they will be described as first derived key (counter value 0) D05A, first derived key (counter value 1) D05B, first derived key (counter value 2) D05C, and first derived key (counter value 3) D05D.

[0156] Next, the encryption of each first derived key D05 is performed. Specifically, the following process is performed: each first derived key D05 is encrypted using the first server key D07, which serves as the encryption key. Hereinafter, the encrypted first derived key D05 will be referred to as the "encrypted first derived key" D08. In addition, in this embodiment, a different first server key D07 is prepared for each counter value D02. Hereinafter, 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. The 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, an encrypted first derived key D08 is generated for each counter value D02, and in this embodiment, a total of 4 encrypted first derived keys D08 are generated. In addition, the first server key D07 can be a shared key or a private / public key.

[0157] Next, an electronic signature (hereinafter referred to as signature) D12 attached to the client certificate is generated. Signature D12 is generated by using the signing key D09, which is the key used for signing, and by performing calculations based on a prescribed signature generation algorithm. Specifically, signature D12 is generated by signing data using the signing key D09, which includes a total of seven data elements, including (A) client ID_D10, (B) the first parameter for determining the second KDF seed (hereinafter sometimes referred to as the first determining parameter) D11, and (C) the four first derived encryption keys D08 mentioned above.

[0158] Here, Client ID_D10 is an ID used to identify Client 3. For example, the SoC ID, serial number, or manufacturing number of the client device can be used as Client ID_D10. Furthermore, when implementing the client using emulator technology, this ID can be information about the object to be emulated. During certificate generation, Client ID_D10 can be read from Client 3, the object connected to PC 4 and used for writing certificate data. Additionally, the first determination parameter D11 is used to determine the value of the second KDF seed data D04 in Server 1 (details described later).

[0159] Next, certificate data D101 is generated, which includes client ID_D10, first determination parameter D11, and the above four encrypted first derived keys D08, along with a signature D12 generated as described above. Figure 4 The structure of certificate data D101 is shown. Certificate data D101 includes a signature D12, four first derived encryption keys D08A~08D, client ID_D10, and the aforementioned first determination parameter D11.

[0160] Finally, the generated certificate data D101 is written to the non-volatile storage of client 3 (described later). As described later, certificate data D101 is sent from client 3 to server 1 during the authentication process, and the data contained in certificate data D101 is used by server 1. The encrypted first derived key D08 (strictly speaking, the decrypted first derived key D05) contained in certificate data D101 is the result of the first KDF operation, i.e., the first derived key data, which server 1 uses to set the response key. Therefore, the first KDF operation does not need to be performed on server 1. In addition, certificate data D101 can also be written to client 3 by downloading from a designated server, other PCs, or forwarding it to client 3.

[0161] Furthermore, in this embodiment, the counter value D02 is used as seed data for the KDF operation used to set the response key. Therefore, the response key can be changed according to the situation.

[0162] In addition, in this embodiment, the certificate contains multiple derived keys that can be selected for use, thereby enabling efficient changes to the response key.

[0163] [Summary of Challenge Generation and Submission]

[0164] Next, a summary of the challenge data generation and transmission process in server 1 will be provided. This process is performed based on the challenge issuance request from client 3. Client 3 sends certificate data D101 upon receiving the challenge issuance request. Figure 5 This diagram illustrates an overview of the process for generating and sending challenge data in server 1, and schematically shows the data flow within that process. In this process, firstly, certificate data D101 is received from client 3 and verified (signature verification). If the verification result is satisfactory, client ID_D10 is retrieved from certificate data D101.

[0165] Next, the client ID_D10, the "challenge version" D14, and the "challenge release time" D15 are used as the computational objects, and the "second server key" D13 is used to perform the prescribed MAC operation to calculate the first MAC (Message Authentication Code) value D16. The first MAC value D16 is used as the challenge data.

[0166] Furthermore, in this embodiment, challenge data is generated through MAC operations, but any cryptographic operation capable of generating tamper-proof verification data (data used for tampering with verification) is acceptable; it can be any operation, such as the AES-GCM algorithm. Additionally, the second server key used in this operation can be a shared key or a private / public key.

[0167] Here, challenge version D14 is data stored on server 1. It is information about the "version" of the challenge data generation method generated by server 1 at a certain point in time, and it represents the current version. For example, challenge version D14 may initially be set to "1.0", and can be changed to "2.0" at a specified time.

[0168] Additionally, the challenge release time D15 is the time on server 1 when the challenge data is being generated.

[0169] Additionally, the second server key D13 is the key data used to calculate the first MAC value (challenge data) D16. In this embodiment, the second server key D13 can be different for each challenge version D14 (or the key can remain unchanged even if the version changes). In this embodiment, the second server key D13 corresponding to the current challenge version D14 is selected and used for calculating the first MAC value (challenge data) D16. The first MAC value D16 is the data used as the computation object in client 3 using the response key, i.e., the so-called challenge data.

[0170] If the first MAC value D16 is calculated, then the challenge dataset D102 is generated based on the (current) challenge version D14, the challenge release time D15, and the first MAC value (challenge data) D16. Figure 6The structure of challenge dataset D102 is illustrated schematically. Furthermore, challenge dataset D102 is data that includes challenge data as well as other data. In this embodiment, challenge dataset D102 is data with a structure containing "challenge version D14 + challenge release time D15 + first MAC value (challenge data) D16". Additionally, although the result of the MAC operation is generally appended to the data (message data) that is the object of the operation before being sent, in this embodiment, although client ID_D10 is used in the calculation of the first MAC value, it is not included in the challenge dataset.

[0171] The challenge dataset D102 generated as described above is sent to client 3, which made the challenge sending request.

[0172] [Summary of response generation and processing in client 3]

[0173] Next, we will describe the summary of the response generation process performed in client 3 upon receiving challenge dataset D102. Figure 7 This is a diagram used to illustrate the overview of the process. First, for the first MAC value (challenge data) D16 contained in the challenge dataset D102 received from server 1, the following method is used: Figure 2 A MAC operation is performed on the response key (client) (second derived key (client) D06) set as described above, thereby calculating the second MAC value (response data) D17. The second MAC value D17 is the result of operating the challenge data using the response key, i.e., the so-called response data. Furthermore, the content of the MAC operation used to calculate the second MAC value (response data) D17 can be the same as or different from the content of the MAC operation used to calculate the first MAC value (challenge data) D16. Moreover, 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, independent of the length of the data input to the first MAC operation.

[0174] In this embodiment, MAC operation is used when using the response key and generating response data based on the challenge data. However, any algorithm that can use the response key and generate response data based on the challenge data is acceptable and is not limited to MAC operation; it can be any algorithm.

[0175] Next, based on the second MAC value (response data) D17, the challenge version D14 contained in the received challenge dataset D102, and the challenge release time D15, a response dataset D103 is generated. The response dataset D103 contains the response data, as well as other data (in this embodiment, the data other than the challenge data contained in the challenge dataset D102 received from server 1; specifically, the challenge version D14 and the challenge release time D15). Furthermore, as mentioned earlier, the result of the MAC operation is generally appended to the data (message data) that is the object of the operation before being sent. However, in this embodiment, although the first MAC value (challenge data) D16 is used in the operation of the second MAC value (response data) D17, the first MAC value D16 is not included in the data when the second MAC value (response data) D17 is sent to the server (the response dataset and client-sent data described later).

[0176] If a response dataset D103 is generated, then client 3 will send (A) response dataset D103, (B) certificate data D101, and (C) the second KDF seed data determination described below using the second parameter (hereinafter sometimes referred to as the second determination parameter) D19 to server 1. Figure 8 This is a schematic diagram of the data sent by client 3 to server 1 (hereinafter sometimes collectively referred to as client-sent data D104). Furthermore, the various data items sent by the client can either be sent as a single unit or sent separately at different times. Figure 8 In the response dataset D103, the challenge version D14, the challenge issuance time D15, and the second MAC value (response data) D17 are included. This is a structure where the first MAC value (challenge data) D16 of the aforementioned challenge dataset D102 is replaced with the second MAC value (response data) D17. That is, the challenge version D14 and challenge issuance time D15 contained in the challenge dataset received from server 1 when the challenge data is received are included in the response dataset and sent to server 1 when the response data is sent. The certificate data D101 is the same as the certificate data D101 sent when the challenge issuance request is made. That is, the certificate data D101 is sent when requesting the server 1 to send challenge data and when sending response data to server 1. The second determination parameter D19 is used together with the first determination parameter D11 to determine the value of the second KDF seed data D04 in the processing of server 1 (details are described later).

[0177] Next, a summary of the response verification process in server 1, which receives data D104 from the client, will be described. In server 1, a response key (server) is first set. Then, the set response key (server) is used to calculate a second MAC value (for verification) D217. Next, it is determined whether the second MAC value (for verification) D217 calculated by server 1 matches the second MAC value (response data) D17 sent from the client, thereby verifying the response data D17.

[0178] Figure 9 This diagram illustrates the outline of the response key setting process in server 1. First, the certificate data D101 contained in the data D104 sent by the client is verified using signature D12. If the verification is successful, the first encrypted derived key D08 and the first determination parameter D11 are extracted from the certificate data D101. Here, as described above, the certificate data D101 contains four first encrypted derived keys D08, one of which is determined and extracted through the following process. First, the current counter value D02 in client 3 is determined. This determination is performed by referring to a "counter value determination table" pre-stored in server 1. The counter value determination table is used to determine the current counter value D02 of the client based on the first determination parameter D11 and the second determination parameter D19 sent from client 3. That is, the current counter value D02 in client 3 (the client 3 being authenticated) that sent the response data is determined using the first determination parameter D11 extracted from the certificate data D101 and the second determination parameter D19 sent along with the certificate data D101. Figure 10 An example of the data structure of the counter value determination table SV404 is shown. In the counter value determination table SV404, the counter value D02 is defined corresponding to the combination of the value of the first determination parameter D11 and the value of the second determination parameter D19.

[0179] Back Figure 9Next, in server 1, the encrypted first derived key D08 corresponding to the counter value D02 determined using the counter value determination table SV404 is retrieved from the certificate data D101. Then, in server 1, the retrieved encrypted 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 key data that varies depending on the counter value D02, as described above. Since 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 determined counter value D02 is used.

[0180] Next, the decrypted first derived key D05 and the second KDF seed data D204 are used to perform the second KDF processing. Here, the value of the second KDF seed data D204 in the second KDF processing is determined as follows: To determine the value of the second KDF seed data D204, a "second KDF seed data determination table" is used. The second KDF seed data determination table is used to determine the aforementioned second KDF seed data D04 based on the first determination parameter D11 and the second determination parameter D19. That is, the second KDF seed data D04 in the client 3 that sent the response data is determined using the first determination parameter D11 extracted from the certificate data D101 and the second determination parameter D19 sent from the client along with the certificate data D101. Figure 11 An example of the data structure of the second KDF seed data determination table SV405 is shown. In the second KDF seed data determination table SV405, the value of the second KDF seed data D204 is defined corresponding to the combination of the first determination parameter D11 and the second determination parameter D19. That is, if using... Figure 2 As described above, in the response key setting process of client 3, the second KDF seed data stored in client 3 is used to set the response key. 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 determined based on the first determination parameter D11 and the second determination parameter D19 received from client 3, and this value is used to set the response key. This is one of the differences between the response key setting process performed by the server and the response key setting process performed by the client.

[0181] In this embodiment, the KDF seed data is determined on server 1 using parameters sent from client 3. This structure allows for response key setting that takes into account the attributes and status of the client (or, in the case of emulator technology, the client device being emulated). Furthermore, in this embodiment, two parameters are used to determine the KDF seed data; the first parameter is used as the signature object, while the second parameter is not. This structure allows for flexible construction of the KDF seed data, using, for example, both signatureable and difficult-to-sign parameters.

[0182] The choice of parameters as the first determined parameter D11 and the second determined parameter D19 is flexible and can be designed appropriately. For example, the first determined parameter D11 can be a fixed value. It could also be the hardware attribute information of client 3. The second determined parameter D19 can be data that can be set or changed in client 3. For example, it could be software attribute information or system software attribute information (e.g., system software version information). Alternatively, the first determined parameter D11 can be data that can be set or changed in client 3, and the second determined parameter D19 can be a fixed value. Furthermore, when client 3 is implemented using simulator technology, the first and second determined parameters can be attribute information of the simulated object, etc. In this embodiment, the first and second determined parameters are different from the second KDF seed data; they are data that can determine the second KDF seed data through a combination of the first and second determined parameters. Additionally, in this embodiment, the first and second determined parameters are also different from the first KDF seed data.

[0183] Back Figure 9 In server 1, a second derived key (server) D206 is generated by performing a second KDF operation using the second KDF seed data D204 determined as described above and the first derived key D05 retrieved from the certificate data D101. Furthermore, the second KDF operation (algorithm) performed in server 1 is the same as the second KDF operation performed in client 3. Moreover, the generated second derived key (server) D206 in server 1 is used as the response key. That is, the response key (server) is set by generating the second derived key (server) D206.

[0184] Here, when the data underlying the KDF operation and the content of the KDF operation vary depending on the client's structure, generating the derived key in server 1 requires managing databases, etc., for changing the data underlying the KDF operation and the content of the KDF operation, according to the structure of each client. However, in this embodiment, for the first KDF operation, the client 3 sends the data (derived key) that has undergone the KDF operation to server 1, and server 1 uses it to generate the response key, so such a database is not required.

[0185] Furthermore, in this embodiment, the KDF operation is configured as multi-level. Regarding the first KDF operation, the computed derived key is sent from client 3 to server 1. On server 1, the computed derived key is used to perform another KDF operation (the second KDF operation) to generate a response key. Thus, regarding the multiple aspects of the elements to be verified, by pre-compiling some and computing others on the server, verification can be performed using a method corresponding to the nature of the elements to be verified.

[0186] In addition, such as Figure 9 As shown, response dataset D103 was not used in the response key setting process of server 1. In the verification process described below, the second MAC value (response data) D17 contained in response dataset D103 is verified.

[0187] [Overview of Validation Processing]

[0188] Next, an outline of the verification process performed on the server (in this embodiment, this includes not only the verification of the response data, but also, as described later, the verification of the challenge release time contained in the response data) will be described. Figure 12 This is a diagram illustrating the overview of the verification process. In the verification process, the second MAC value D217, which is the response data, is verified by calculating the second MAC value (during verification) D217 on the server 1 side and determining whether it matches the second MAC value (response data) D17 sent from the client 3.

[0189] First, the first MAC value (during verification) D216 is calculated on server 1. This process is essentially performed in conjunction with the use of... Figure 5The process for calculating the first MAC value (challenge data) D16 in the challenge generation process described above is the same. Based on the challenge version D14 contained in the response dataset D103 sent from client 3, a second server key D13 corresponding to challenge version D14 is selected. Then, using the selected second server key D13, the MAC value of the object "challenge version D14 contained in response dataset D103 and challenge issuance time D15, and client ID_D10 contained in certificate data D101 sent from the client (certificate data D101 sent during verification request)" is calculated, thereby calculating the first MAC value (at verification time) D216.

[0190] Furthermore, regarding the calculation of the first MAC value (during verification) D16, in other embodiments, the first MAC value (challenge data) D16 calculated in the above-mentioned challenge generation process may be stored in server 1 beforehand. Moreover, it is also possible to configure the process to use the already stored first MAC value (challenge data) D16 during verification, thereby omitting the calculation of the first MAC value (during verification) D16.

[0191] Next, using the response key (server) D206 and the first MAC value (for verification) D216 set above, the second MAC value (for verification) D217 is calculated using the same algorithm as the MAC operation in client 3.

[0192] Next, the second MAC value (response data) D17 contained in the response dataset D103 is compared with the second MAC value (at verification time) D217 calculated above to determine if they match. If they match, the verification result of the response is determined to be OK (positive); if they do not match, the verification result of the response is determined to be NG (negative).

[0193] Furthermore, in this embodiment, a time-based verification process is performed on server 1. This process determines whether the time from when server 1 issues challenge dataset D102 to when the client returns response dataset D103 (or the time from when the challenge data is issued to when verification is executed) is within a certain time frame. Specifically, the challenge issuance time D15 contained in the response dataset D103 is compared with the current time of server 1 at the point when the verification process is executed. If the time is within a certain time frame, it is determined to be OK; if more than a certain time has elapsed, it is determined to be NG.

[0194] Then, if both the verification of response data D17 and the time-based verification are OK, authentication is considered successful. Otherwise, authentication is considered a failure. In the case of successful authentication, the process of sending the specified service token to the client is executed. In the case of authentication failure, an error message is sent, etc. The content of the service token includes, for example, the client ID, the identifier of the specified online service, the validity period, and information such as the signature or MAC value of this data.

[0195] As described above, in this embodiment, when issuing a challenge, the MAC value (first MAC value) of the object to be MAC-operated at least at the challenge issuance time is sent from server 1 to client 3 along with the challenge issuance time. Furthermore, when generating response data, client 3 generates a value (second MAC value) obtained by further MAC-operating the MAC value using a response key and sends it as response data to server 1. Server 1 uses this value as a verification object, and also performs time-based verification using the challenge issuance time. This prevents improper behavior during the authentication process.

[0196] The following describes the details of the processing involved in this embodiment.

[0197] [Hardware structure of client 3]

[0198] Next, the hardware structure of the aforementioned client 3 will be explained. Figure 13This is a block diagram showing the hardware structure of client 3. In this embodiment, client 3 is a gaming device, but it can also be a general PC, smartphone, tablet, etc. Client 3 is an example of a computer, including a main processor, a secondary processor, memory, programs, peripheral processors, etc. Client 3 has at least a processing unit 31, a storage unit 32, a network communication unit 35, an operating device 36 (game controller), and an image output unit 37. The processing unit 31 is, for example, a processor that executes various programs for controlling client 3. Client 3 can also be composed of multiple devices. The processing unit 31 can also be composed of multiple processors, in which case it can be multiple processors of multiple devices. In addition, the processor can be a general-purpose processor or a special-purpose processor, such as a SoC, CPU, ASIC, microcontroller, etc. The storage unit 32 stores various programs executed by the processing unit 31 and various data used. The program can also be a program group composed of multiple programs, each program can be executed by different processors, and each program can also be stored in different memories. In addition, the program can be application software, system software, firmware, emulator, etc. In addition to code, the program may also include data and table parameters. 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, which functions as main memory. Various programs and data stored in the non-volatile storage unit 33 can be read into the volatile storage unit 34 as needed, and the processing unit 31 performs various processes as described below. The network communication unit 35 communicates with other servers or clients 3 via a network such as the Internet (wireless or wired). Alternatively, it can be configured to communicate directly with the other party without a network. The operating device is various operating devices (keyboard, mouse, etc.). The image output unit 37 outputs a specified image generated as a result of the information processing performed by the processing unit 31.

[0199] Furthermore, a portion of the non-volatile memory section 33 and the volatile memory section 34 can also be configured as a secure area. A portion of the various types of data described later can, for example, be configured as a secure area stored in the memory within the SoC (System on a Chip).

[0200] Furthermore, the hardware structure of Server 1 and PC 4 can be any standard server or PC hardware structure, so details are omitted. Figure 13The same structure applies. Furthermore, server 1 can also be composed of multiple server devices. That is, server 1 is composed 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. Additionally, PC 4 is composed 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.

[0201] Next, the various data used in the processing involved in this embodiment will be explained.

[0202] [Data used in Client 3]

[0203] Figure 14 This is an example of data stored in storage unit 32 of client 3. Figure 14 The data shown represents data stored in the non-volatile storage unit 33. During authentication processing, this data is read into the volatile storage unit 34 as needed, thereby enabling the authentication process. Furthermore, this data can also be stored separately in different memories. For example, a portion of the data can also be stored in the aforementioned secure area.

[0204] exist Figure 14 In the non-volatile storage unit 33, 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 determining the second KDF seed data are stored. Furthermore, in... Figure 14 In this document, all data except for the system program CL201 and the online game program CL202 are identical in content to the data mentioned above.

[0205] exist Figure 14 In this context, system program CL201 is used to control the system of client 3. System program CL201 contains at least the following: Figure 15The program shown implements the authentication function of this embodiment. First, system program CL201 includes a challenge issuance request program that requests the server 1 to issue a challenge. Additionally, system program CL201 includes a response key setting program that has the function of setting a response key (client). Furthermore, system program CL201 includes a response generation and sending program that has the function of receiving challenge dataset D102, generating response dataset D103, and sending response dataset D103 (the aforementioned client-sent data). Additionally, 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 processing involved in this embodiment is performed (not as application processing, but as one of the system-side processes for controlling the client 3).

[0206] Back Figure 14 The online game program CL202 is a program for a specified online game. In this embodiment, as described above, device authentication processing is performed when starting to play the online game.

[0207] Furthermore, the various data mentioned above (including the various data required for setting the response key (client) (seed data for each KDF operation, certificate data, parameters used to determine the seed data, etc.)) can also be stored in the storage unit 32 by downloading or forwarding from other information processing devices at a specified time. In this case, for example, the response key setting program may have the function of specifying the various data to be downloaded or forwarded. Alternatively, it may also have the function of specifying the location where the various data is stored (folders in client 3, etc.).

[0208] Alternatively, in other embodiments, the storage unit 32 may contain data of the first derived key D05. In this case, the master key D01 and the first KDF seed data D03 may not be stored in the storage unit 32.

[0209] Alternatively, in other embodiments, the storage unit 32 may store data of the second derived key D06. In this case, the master key D01, the first KDF seed data D03, and the second KDF seed data D04 may not be stored. Furthermore, in this case, the response key setting program may also be a structure that does not have the function of setting the first derived key.

[0210] [Data used in Server 1]

[0211] Next, the data stored in the storage unit 12 of server 1 will be explained. Figure 16The data stored in the non-volatile storage unit 13 of server 1 is shown. During authentication processing, this data can be appropriately read into the volatile storage unit 14 as needed, thereby performing authentication processing on the server 1 side.

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

[0213] The authentication program SV401 is a program used to perform authentication processing on the server side. Authentication program SV401 has a challenge issuance function that issues the aforementioned challenge data to client 3 and sends other data, as well as a verification function that uses the response dataset D103 from client 3 for verification. Furthermore, the verification function also includes using... Figure 12 The above describes the function of setting the response key (server).

[0214] Here, we will provide further explanation regarding the first server key D07. As described above, in this embodiment, multiple key data corresponding to counter values ​​are prepared for the first server key D07, but only one of these key data is stored as the first server key D07 in server 1. Furthermore, whenever the counter value is incremented, it is replaced with the key data corresponding to each counter value for storage.

[0215] Furthermore, since the increment of the counter value D02 in client 3 is performed through a system update of client 3, the update timing of the counter value D02 in each client 3 may not be the same. Therefore, it is also possible to store the first server key D07 corresponding to the counter value D02 before the increment as an "old first server key" for a certain period of time from the occurrence of the increment of the counter value D02 (e.g., the timing of a system update). Moreover, it is also possible to configure the system so that even if authentication is requested from a client 3 that has not yet undergone a system update, the "old first server key" can be used to determine successful authentication during a certain period of time.

[0216] As described above, in this embodiment, the second server key D13 is key data with content that varies for each challenge version D14. Furthermore, 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, since there may be clients 3 making verification requests using challenges released with older challenge versions, the second server key D13 corresponding to the older challenge version can also be stored to handle verification requests from such clients 3.

[0217] The counter value determination table SV404 is as described above. Figure 10 The data shown is provided below. Therefore, detailed explanations are omitted here.

[0218] The second KDF seed data determination table SV405 is as described above. Figure 11 The data shown is provided below. Therefore, detailed explanations are omitted here.

[0219] The CA public key SV406 is the key data paired with the signing key D09. It is the key data used in server 1 to verify the signature D12 of certificate data D101 (the decryption key or verification key in the public key encryption method).

[0220] Challenge version D14 is the challenge version assigned to the challenge issued at that point in time. As described above, in this embodiment, since the second server key D13 is different for each challenge version, challenge version D14 is used when generating challenge data D16 to determine which second server key D13 was used to calculate the first MAC value (challenge data) D16. Alternatively, depending on the challenge version, various processes of server 1 and / or client 3 may be changed in addition to changing the second server key D13. In this case, the branching of processing may also be based on challenge version D14 included in the challenge.

[0221] [Data used in PC 4]

[0222] Next, in Figure 17 The image shows an example of data stored in the storage unit 42 of the PC 4 described above. Specifically, it shows an example of data stored in the storage unit 42 of the PC 4 described above. Figure 3 An example of the data used in the certificate creation process described above. The storage unit 42 of PC 4 stores a certificate generation and writing program FC501, a master key D01 (the master key D01 corresponding to the client 3 to be created), first KDF seed data D03 (the first KDF seed data D03 corresponding to the client 3 to be created), four first server keys D07A~D07D, a signing key D09, a client ID_D10 (the client ID_D10 corresponding to the client 3 to be created), and a first determination parameter D11 (the first parameter D11 for determining the second KDF seed data corresponding to the client 3 to be created).

[0223] The FC501 certificate generation and writing program is used to generate and use certificates. Figure 3 The program that writes the aforementioned certificate data D101 to the non-volatile storage unit 33 of client 3.

[0224] Furthermore, it is set that the first parameter D11 is used to determine the second KDF seed data used in PC 4, for example, a value corresponding to the client 3 as the writing target is preset.

[0225] The following flowchart illustrates the details of the processing performed by PC 4, Client 3, and Server 1. Furthermore, the flowchart shown below is merely one example of the processing procedure. Therefore, the order of the steps can be changed to achieve the same result. Additionally, the values ​​of the variables and the thresholds used in the decision-making steps are also just examples; other values ​​can be used as needed.

[0226] First, the details of the certificate generation and writing process performed in PC 4 above will be explained. Figure 18 This is an example of a flowchart for certificate generation and writing processing. First, the processing unit 41 of PC 4 sets the counter value n, which is a variable, to 0 (step S201).

[0227] 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, which is currently the object of the write operation, and stores them in the storage unit 42 (step S202). For example, this data can be read from the client 3, which is connected to the PC 4 and is currently the object of the write operation. Alternatively, this data can be generated on the manufacturing equipment side or read from the storage device on the manufacturing equipment side, instead of being read from the client 3.

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

[0229] Next, the processing unit 41 encrypts the generated first derived key n using the first server key D07 (the key when the counter value is n) corresponding to the current counter value n (step S204).

[0230] Next, the processing unit 41 increments the counter value n by 1 (step S205).

[0231] Next, the processing unit 41 determines whether the counter value n is greater than a predetermined value (step S206). In this embodiment, the case where the counter value n takes the values ​​0 to 3 is illustrated, so the predetermined value is 3. If the result of the determination is that the counter value is not greater than the predetermined value ("No" in step S206), the process returns to step S203 and repeats the processing.

[0232] On the other hand, when the counter value n becomes a value greater than a predetermined value ("yes" in step S206), the processing unit 41 uses the hash value of "four encryption first derived keys D08, client ID_D10, first determination parameter D11" and the signature key FC-D09 to create signature D12 (step S207).

[0233] Next, the processing unit 41 generates certificate data D101 containing four encrypted first derived keys D08, client ID_D10, and first determination parameters D11, and is assigned the aforementioned signature D12 (see reference). Figure 4 Furthermore, the processing unit 41 writes the certificate data D101 to the non-volatile storage unit 33 of the client 3 (step S208). Alternatively, the certificate data can be downloaded or forwarded from a designated server or other PC and written to the non-volatile storage unit 33 of the client 3.

[0234] 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 begins with a challenge issuance request from client 3 and is primarily used to issue challenge data D16 on server 1 and send it to client 3 (other processing is also performed, as described later). The verification session begins with a verification request from client 3 (for requesting verification of the response) and is primarily used to send a response from client 3, verify the response on server 1, and send the result back to client 3. In this embodiment, the challenge issuance session and the verification session are separate communication sessions. Furthermore, if server 1 consists of multiple server devices, the challenge issuance session and the verification session may also be executed on different server devices. The challenge issuance session and the verification session are different communication sessions, and these communication sessions are not a series of processes. Therefore, the issued challenge cannot be directly used when verifying the response. In this embodiment, the challenge and the data based on the challenge are sent to the client together, and this data (the data based on the challenge) is returned from the client to the server along with the response. The server then regenerates the challenge based on this data, thereby ensuring the relationship between the issued challenge and the response. Figures 19 to 30 This section explains the processing performed by the processing unit 11 of server 1 and the processing unit 31 of client 3. Furthermore, in Figures 19 to 30 The processing order described is just one example and can be rearranged as needed. Alternatively, multiple processes can be performed in parallel.

[0235] [Details on handling challenge release sessions]

[0236] Figure 19 This is a diagram showing the details of the processing during the challenge issuance session. Figure 19The processing unit 31 of the client 3 executing the system program (authentication function) CL201 and the processing unit 11 of the server 1 executing the authentication program SV401 are shown. Figure 19 First, the processing unit 31 of the client 3 performs the following processing: establishes a session with the server 1, and sends the meaning of the request to issue a challenge and certificate data D101 via the network communication unit 35 (step S1).

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

[0238] Next, the processing unit 11 verifies the signature D12 (step S3). Specifically, the processing unit 11 decrypts the signature D12 using the aforementioned CA public key SV406. Then, it uses the decryption result to determine whether the four encrypted first derived keys D08, client ID_D10, and first determination parameter D11 contained in the certificate data D101 have been tampered with. If they match, the verification result is considered positive. Furthermore, if the decryption results do not match, it is considered negative, and the challenge dataset D102 is not sent. Instead, the client 3 is notified of this (or communication can be terminated without notification), and the processing ends.

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

[0240] Figure 20 This is a flowchart showing the details of 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).

[0241] Next, the processing unit 11 uses the challenge version D14 read from the storage unit 12, the challenge release time D15 obtained in step S21, and the client ID_D10 obtained in step S4 as objects, and uses the second server key D13 corresponding to the challenge version D14 to calculate the first MAC value (challenge data) D16 (step S22).

[0242] Next, the processing unit 11 generates a challenge dataset D102 containing challenge version D14, challenge release time D15, and the first MAC value (challenge data) D16 calculated in step S22 (step S23). At this point, the challenge generation process is complete.

[0243] Back Figure 19If a 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).

[0244] Next, the processing unit 31 of client 3 processes the receipt of challenge dataset D102 via network communication unit 35 (step S7). After that, the challenge issuance session ends (step S8).

[0245] Figure 21 This is a diagram illustrating the details of the processing in the verification session. First, the processing unit 31 of client 3, which receives challenge dataset D102, performs response generation processing (step S9).

[0246] Figure 22 This is a flowchart illustrating the details of the response generation process performed in client 3. Figure 22 First, the processing unit 31 performs the first derived key setting process (step S31).

[0247] Figure 23 This is a flowchart illustrating a first example of the first derived key setting process described above. Figure 23 In the process, 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).

[0248] Next, the processing unit 31 performs the first KDF operation based on the read master key D01, counter value D02, and first KDF seed data D03 to generate the first derived key D05 (step S42). At this point, the first derived key setting process is complete.

[0249] Alternatively, the pre-calculated first derived key D05 can be stored in the storage unit 32. In this case, the processing unit 31 can also perform the first derived key setting process as follows: Figure 24 The first derived key is set by reading the pre-stored first derived key data from the storage unit 32 as shown (step S43). In other words, if the client 3 stores the first derived key D05, which has already undergone the first KDF operation, as data, the operation process of using the first KDF can be omitted.

[0250] Back Figure 22 Next, the processing unit 31 performs the second derived key setting process (step S32). Figure 25 This is a flowchart illustrating the first example of the second derived key setting process. Figure 25In step S51, the processing unit 31 reads the second KDF seed data D04 from the storage unit 32. Next, the processing unit 31 performs a second KDF operation based on the first derived key D05 and the second KDF seed data D04 to generate the second derived key (client) D06 (step S52). At this point, the second derived key setting process is complete.

[0251] Alternatively, the pre-calculated second derived key (client) D06 can be stored in the storage unit 32. In this case, the processing unit 31 can also process the data through a method such as... Figure 26 As shown, the second derived key (client) D06 data, which is stored in advance, is read from the storage unit 32 (step S53) to set the second derived key. That is, if the client 3 stores the second derived key as data that has already undergone the second KDF operation, the second KDF operation process can be omitted. In addition, in this example, the first derived key setting process itself can also be omitted.

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

[0253] Back Figure 22 Next, the processing unit 31 performs response data generation processing (step S34). Figure 27 This is a flowchart illustrating the details of the response data generation process. First, the processing unit 31 retrieves data from... Figure 19 In step S8, the first MAC value (challenge data) D16 is read from the challenge dataset D102 received (step S61).

[0254] 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).

[0255] Next, the processing unit 31 generates the response dataset D103 (refer to the above). Figure 8 The response dataset D103 contains... Figure 21 The challenge dataset D102 received in step S8 contains the challenge version D14, the challenge release time D15, and the second MAC value (response data) D17 calculated above (step S63). At this point, the response dataset generation process is complete.

[0256] Furthermore, here, as Figure 22The response generation process illustrates an example where steps S31 to S34 are executed in a series of steps. In other embodiments, the process of setting the response key (client) (steps S31 to S32) may also store the pre-calculated content in storage unit 32 and read it in step S9. For example, it may also be executed when client 3 starts, storing the response key (client) data in storage unit 32 and reading it in step S9.

[0257] return Figure 21 If the response generation process ends, the processing unit 31 re-establishes a session with the server 1 (which may not be the same server device). Then, the processing unit 31 performs the following processing: sending an authentication request and the aforementioned client-sent data D104 to the server 1 via the network communication unit 35 (step S10). That is, the response dataset D103 generated in step S9, along with the certificate data D101 and the second determination parameter D19 read from the storage unit 32, are sent to the server 1. Furthermore, the system program (authentication function) CL201 may have the function of specifying a region for storing the certificate data D101, thereby reading the certificate data D101 from the specified region. In addition, the response generation and sending program may have the function of specifying a region for storing the second determination parameter D19, thereby reading the second determination parameter from the specified region. Furthermore, the system program (authentication function) CL201 may have the function of obtaining (e.g., downloading) the certificate data D101 and / or the second determination parameter D19 from a specified server or PC, and storing the obtained certificate data D101 and / or the second determination parameter D19 in the aforementioned specified region.

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

[0259] Next, the processing unit 11 performs the verification process (step S12). Figures 28-29 This is a flowchart illustrating the details of the verification process. Figure 28 First, the processing unit 11 verifies the signature D12 of the received certificate data D101 (step S71). Since this process is the same as the process described above, a detailed description is omitted.

[0260] If the signature verification is successful, the next step is for the processing unit 11 to retrieve the first determination parameter D11 from the certificate data D101 (step S72).

[0261] Next, the processing unit 11 determines the value of the second KDF seed data D04 based on the retrieved first determination parameter D11 and the second determination parameter D19 received from the client 3, referring to the second KDF seed data determination table SV405. Additionally, the processing unit 11 determines the counter value D02 based on the first determination parameter D11 and the second determination parameter D19, referring to the counter value determination table SV404 (step S73).

[0262] Next, the processing unit 11 extracts the first encrypted derived key D08 corresponding to the determined counter value D02 from the certificate data D101 received from the client 3 (step S74).

[0263] Next, the processing unit 11 uses the first server key D07 corresponding to the counter value D02 determined above to decrypt the extracted encrypted first derived key D08 into the first derived key D05 (step S75).

[0264] Next, the processing unit 11 performs a second KDF operation based on the first derived key D05 and the value of the second KDF seed data D04 determined in step S73, generating a second derived key (server) D206. This second derived key (server) D206 is used as the response key (server) (step S76). That is, the response key (server) is set by generating the second derived key D206.

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

[0266] 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 (the second derived key (server) D206 generated in step S76) (step S78). Furthermore, the calculation algorithm in this process is the same as the algorithm used to calculate the second MAC value in the client 3.

[0267] Next, the processing unit 11 verifies whether the second MAC value (response data) D17 received from the client is consistent with the second MAC value (d217 during verification) calculated in the server 1 (step S79).

[0268] Next, the processing unit 11 determines whether the verification results are consistent (step S80). If they are inconsistent ("No" in step S80), the processing unit 11 performs the process of returning an error to the client 3 (step S83). After that, the verification process ends. On the other hand, if they are consistent ("Yes" in step S80), the response data D17 received from the client 3 can be considered legitimate. Furthermore, since the MAC value is calculated using the client ID, if the second MAC value (response data) is consistent with the second MAC value (at verification), it can be determined that the client that was the target of issuing challenge data in the challenge issuance session and the client that sent response data D17 in the verification session are the same client 3 (consistent). In addition, it is not necessary to compare the client ID in the challenge issuance session with the ID itself of the client ID in the verification session.

[0269] If "Yes" is true in step S80, the processing unit 11 performs a time-based verification. Specifically, the processing unit 11 determines whether a certain amount of time has elapsed since the challenge issuance time D15 included in the received response dataset D103, from the current time of server 1. If the determination result is that a certain amount of time has elapsed ("Yes" in step S81), the process proceeds to step S83, where an error is returned to client 3. On the other hand, if a certain amount of time has not elapsed ("No" in step S81), the processing unit 11 can verify the legitimacy of client 3, considers the verification successful, and generates the prescribed service token. After that, the response verification process ends.

[0270] Furthermore, the example above illustrates a process of performing time-based verification after verifying the second MAC value, but the order of verification can also be reversed.

[0271] return Figure 21 If the response verification process ends, the processing unit 11 will then send the specified service token to the client via the network communication unit 15 if the verification is successful (step S13).

[0272] Next, the processing unit 31 of client 3 processes the receipt of the service token via the network communication unit 35 (step S14). After that, the response session ends (step S15).

[0273] Next, the processing unit 31 passes the service token to the application, which in this embodiment is the online game program (step S16). The online game program then uses the service token to request service from the designated server, thereby receiving online game service from that server.

[0274] Furthermore, communications related to the challenge issuance session and the verification session can employ any communication method. For example, encrypted communication such as SSL can be used, as well as unencrypted communication.

[0275] Next, use Figure 30 This illustrates an example of online game processing in client 3 using the authentication process described above. Figure 30 First, the processing unit 31 accepts the online game start request (step S101). For example, the processing unit 31 accepts the online game start operation from the user.

[0276] Next, the processing unit 31 activates the system software (authentication function). The authentication process described above is then performed.

[0277] Next, the processing unit 31 determines whether a service token has been received from the system software (step S109). If the result of this determination is that no token has been received ("No" in step S103), it remains in standby mode until a token is received.

[0278] 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 services from the online game server (step S104).

[0279] Afterwards, the processing unit 31 communicates with the online game server and other clients 3 as needed while executing the online game (step S105). Next, the processing unit 31 determines whether the conditions for ending the online game are met (step S106). If not met ("No" in step S106), the online game continues to be executed; if met ("Yes" in step S106), the online game processing ends.

[0280] This concludes the detailed description of each process involved in this embodiment.

[0281] [Variation Example]

[0282] Furthermore, in other embodiments, the structure can be configured such that the counter value is not used as the seed data for the first KDF. That is, it can also be configured as follows: the first KDF operation is performed using the master key D01 and the first KDF seed data D03 to generate the first derived key D05. In this case, the certificate contains one encrypted first derived key D05. It is self-evident that the counter value is not limited to 0~3. Alternatively, a predetermined variable value can be used instead of the counter, and the value can be changed without incrementing.

[0283] Furthermore, the above embodiment illustrates an example of using a two-stage KDF operation, namely a first KDF operation and a second KDF operation, in the response key setting process. In other embodiments, the KDF operation may be a single stage, or the number of KDF operation stages may be further increased, with the result (derived key) obtained by performing a further KDF operation after the second KDF operation being set as the response key. As a "further KDF operation," for example, a KDF operation may be performed using data on the volatile or non-volatile memory of client 3, or data obtained by processing it, as seed data. The data on this memory may vary depending on each version of the system software.

[0284] Furthermore, in the above embodiment, the second KDF seed data D04 is determined and used based on the first determination parameter D11 and the second determination parameter D19 in the response key setting process in server 1. Regarding this, in other embodiments, these parameters may not be used to set the response key. For example, one parameter may be used to determine the second KDF seed data, or the second KDF seed data itself may be sent from client 3 to server 1. Alternatively, if the second KDF seed data is shared by all clients, it is sufficient to pre-store the second KDF seed data in server 1.

[0285] Alternatively, in the above embodiment, the first KDF operation may not be performed on server 1. However, the master key D01 and the first KDF seed data can be determined on server 1, and the first KDF operation can be performed on server 1. In this case, the encrypted first derived key D08 in the certificate data D101 is no longer needed. In this case, the data obtained by encrypting the master key D01 with the first server key can also be included in the certificate data D101. Then, on server 1, it is sufficient to decrypt the master key D01 and perform the above-described first KDF processing to obtain the first derived key D05.

[0286] Furthermore, regarding the generation of challenge data, the example above illustrates using a second server key to perform a MAC operation to calculate the first MAC value. In other implementations, a structure could be used where a signature is performed instead of a MAC operation. For example, an RSA signature could also be used.

[0287] Alternatively, the generation of response data using the response key can also be achieved by using block encryption instead of the second MAC value calculation. Block encryption could be, for example, AES.

[0288] Alternatively, in other embodiments, the client 3 may send a parameter used to determine the current value of the counter value D02 along with the response data D17. Then, in the server 1, the sent parameter can be used to determine the counter value D02, and the response key can be set through the processing described above.

[0289] In addition, in the above implementation, the challenge issuance session and the verification session are set as different communication sessions, but challenge issuance and verification can also be carried out in a single session.

[0290] Furthermore, in the above embodiment, the encrypted derived key is included in the client certificate, but it is also possible to send the encrypted derived key to the server separately from the client certificate when sending response data. The second KDF seed data is determined using the same first parameter. Alternatively, the second KDF seed data can be determined using the second parameter and included in the certificate, or the certificate can be separately signed before sending.

[0291] Industrial availability

[0292] The information processing system disclosed herein can provide a new authentication method for authenticating devices for clients.

[0293] Explanation of reference numerals in the attached figures

[0294] 1: Server; 3: Client; 4: PC; 11: Processing unit; 12: Storage unit; 13: Non-volatile storage unit; 14: Volatile storage unit; 15: Network communication unit; 16: Operating device; 17: Image output unit; 31: Processing unit; 32: Storage unit; 33: Non-volatile storage unit; 34: Volatile storage unit; 35: Network communication unit; 36: Operating device; 37: Image output unit; 41: Processing unit; 42: Storage unit; 43: Non-volatile storage unit; 44: Volatile storage unit; 45: Network communication unit; 46: Operating device; 47: Image output unit.

Claims

1. An information processing system comprising a client and a server connected to a network, wherein authentication of the client is performed between the client and the server using a challenge-response method, wherein, The server has a unit that issues challenge data and sends the challenge data to the client. The client has the following features: A unit for storing processed data, the processed data being the result of performing at least a portion of the operations used to set the response key on the server side; A unit for setting the response key on the client side; A unit that receives the sent challenge data; A unit that generates response data based on the received challenge data, using the response key set on the client side; A unit that sends the generated response data to the server; as well as The unit that sends the stored processed data to the server. The server also has: A unit that receives the sent response data; A unit that receives the processed data that has been sent; A unit that sets the server-side response key based on the received processed data; A unit for verifying the received response data based on the challenge data and the server-side preset response key; and The unit that notifies the client of the verification result. The client also has: The unit that receives the result, The operation includes a first operation and a second operation based on the result of the first operation. The processed data is the result of performing the first operation. The server-side response key is set by performing the second operation based on the received processed data. The client also includes: A unit for storing second computational data, which is data used when performing the second computation; and The unit that sends the second calculation data. The server also has: The unit that receives the transmitted second computational data. The server-side response key is set by performing the second operation based on the received processed data and the second operation data.

2. The information processing system according to claim 1, wherein, The client-side response key is set in a manner that does not use the already computed data.

3. The information processing system according to claim 1 or 2, wherein, The client also stores signed data containing the processed data and the signed data, wherein the signed data is signed data that includes at least the processed data. The server-side response key is set to verify the signature and is based on the signed data.

4. The information processing system according to claim 1 or 2, wherein, The processed data is encrypted using the server key to obtain encrypted data. The response key on the server side is set by decrypting the encrypted data using the server key.

5. The information processing system according to claim 1 or 2, wherein, The communication session between the server and the client for authentication processing includes a first communication session for sending and receiving the challenge data, and a second communication session different from the first communication session. In the second communication session, the sending and receiving of response data, the verification of the response data, and the sending and receiving of the result are performed. The server device for the first communication session may be different from the server device for the second communication session.

6. The information processing system according to claim 5, wherein, The client also has a unit that forwards the received challenge data to the server. The server also has a unit for receiving the forwarded challenge data. In the verification, the challenge data is regenerated based on the forwarded challenge data, and the received response data is verified.

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

8. An information processing system comprising a client and a server connected to a network, wherein authentication of the client is performed between the client and the server using a challenge-response method, wherein... The server has a unit that issues challenge data and sends the challenge data to the client. The client has the following features: A unit for storing processed data, the processed data being the result of performing at least a portion of the operations used to set the response key on the server side; A unit for setting the response key on the client side; A unit that receives the sent challenge data; A unit that generates response data based on the received challenge data, using the response key set on the client side; A unit that sends the generated response data to the server; as well as The unit that sends the stored processed data to the server. The server also has: A unit that receives the sent response data; A unit that receives the processed data that has been sent; A unit that sets the server-side response key based on the received processed data; A unit for verifying the received response data based on the challenge data and the server-side preset response key; and The unit that notifies the client of the verification result. The client also has: The unit that receives the result, The operation includes a first operation and a second operation based on the result of the first operation. The processed data is the result of performing the first operation. The server-side response key is set by performing the second operation based on the received processed data. The client also stores second computational data, which is the data used when performing the second computation. The client also stores a single, signed data comprising the second computational data and at least the signed data of the already computed data and the second computational data. The server-side response key is set to verify the signature and is based on the already processed data and the second processing data.

9. The information processing system according to claim 8, wherein, The client also has: A unit for storing unsigned data, wherein the unsigned data is data that is different from the data used in the second operation and is unsigned, used in setting the response key on the server side; and The unit that sends the unsigned data to the server The server also has: The unit that receives the transmitted unsigned data. The server-side response key is set based on the computed data, the second computed data, and the unsigned data.

10. The information processing system according to claim 9, wherein, The server-side response key is set based on data determined by the combination of the second computational data and the unsigned data.

11. A client, which is a client in the information processing system according to claim 1 or 2.

12. A computer program product comprising an information processing program for enabling a computer to function as a client in an information processing system according to claim 1 or 2.

13. A server, which is a server in the information processing system according to claim 1 or 2.

14. A computer program product comprising an information processing program for enabling a computer to function as a unit of a server in an information processing system according to claim 1 or 2.

15. A computer program product comprising a program that causes a client computer, which processes authentication with a server via a challenge-response method, to perform the following processes: Set the response key on the client side; Receive challenge data sent from the server; Based on the set response key, response data is generated according to the received challenge data; Send the generated response data to the server; Read processed data from the client's memory, the processed data being the result of performing at least a portion of the operations used to set the response key on the server side; Send the processed data to the server; as well as The server receives a verification result based on the response data, wherein the verification of the response data is performed based on a server-side response key set according to the processed data. The operation includes a first operation and a second operation performed on the server based on the result of the first operation. The processed data is the result of performing the first operation. The program further causes the computer to perform the following processes: Read second computational data from the client's memory, the second computational data being the data used when performing the second computation on the server; and Send the second computational data to the server. The verification is performed using a server-side response key, which is set by the second operation based on the already processed data and the second operation data.

16. The computer program product according to claim 15, wherein, The client-side response key is set in a manner that does not use the already computed data.

17. The computer program product according to claim 15 or 16, wherein, The client also stores signed data containing the computed data and the signed data, wherein the signed data is signed data that includes at least the computed data.

18. The computer program product according to claim 15 or 16, wherein, The processed data is encrypted using the specified server key to obtain encrypted data.

19. The computer program product according to claim 15 or 16, wherein, The communication session between the server and the client for authentication processing includes a first communication session for sending and receiving the challenge data, and a second communication session different from the first communication session. In the second communication session, the sending and receiving of response data, the verification of the response data, and the sending and receiving of the result are performed. The server device for the first communication session may be different from the server device for the second communication session.

20. The computer program product according to claim 19, wherein, The computer also performs the following process: forwarding the received challenge data to regenerate the challenge data in the server.

21. The computer program product according to claim 15 or 16, wherein, The calculated data has different values ​​depending on the client.

22. The computer program product according to claim 15 or 16, wherein, The computer also performs the following process: designating a region for storing the processed data.

23. A computer program product comprising a program that causes a client computer, which processes authentication with a server via a challenge-response method, to perform the following processes: Set the response key on the client side; Receive challenge data sent from the server; Based on the set response key, response data is generated according to the received challenge data; Send the generated response data to the server; Read processed data from the client's memory, the processed data being the result of performing at least a portion of the operations used to set the response key on the server side; Send the processed data to the server; as well as The server receives a verification result based on the response data, wherein the verification of the response data is performed based on a server-side response key set according to the processed data. The operation includes a first operation and a second operation performed on the server based on the result of the first operation. The processed data is the result of performing the first operation. The client also stores second computational data, which is used during the second computation. The client further stores a unified signed data set, comprising the second computational data and signature data including at least the already computed data and the second computational data. The server-side response key is set to verify the signature and is based on the processed data and the second processed data.

24. The computer program product according to claim 23, wherein, The computer also performs the following processes: Read unsigned data from the client's memory, the unsigned data being data that is different from the data used in the second operation and is not signed, and is used in the second operation on the server; as well as Send the unsigned data to the server. The verification is performed using a server-side response key, which is set based on the computed data, the second computed data, and the unsigned data.

25. The computer program product according to claim 24, wherein, The computer also performs the following processes: designating a region for storing the processed data; and designating a region for storing the unsigned data.

26. An information processing method, executed by a computer, the information processing method comprising a client and a server connected to a network, wherein authentication processing of the client is performed between the client and the server using a challenge-response method, wherein... The server issues challenge data and sends the challenge data to the client. The client performs the following processing: Retrieve computed data from the client's memory, the computed data being the result of performing at least a portion of the computations used to set the response key on the server side; Set the client-side response key without using the already computed data; Receive challenge data sent from the server; Based on the set response key, response data is generated according to the received challenge data; as well as The generated response data and the acquired processed data are sent to the server. The server also performs the following processing: Receive the response data and the processed data; The server-side response key is set based on the received processed data; The response data sent from the client is verified based on the challenge data and the server-side configured response key; and The client will be notified of the verification result. The client also performs the following processing: Receive the result, The operation includes a first operation and a second operation based on the result of the first operation. The processed data is the result of performing the first operation. The server-side response key is set by performing the second operation based on the received processed data. The client also includes: A unit for storing second computational data, which is data used when performing the second computation; and The unit that sends the second calculation data. The server also has: The unit that receives the transmitted second computational data. The server-side response key is set by performing the second operation based on the received processed data and the second operation data.

27. An information processing method, executed by a computer, the information processing method comprising a client and a server connected to a network, wherein authentication processing of the client is performed between the client and the server using a challenge-response method, wherein... The server issues challenge data and sends the challenge data to the client. The client performs the following processing: Retrieve computed data from the client's memory, the computed data being the result of performing at least a portion of the computations used to set the response key on the server side; Set the client-side response key without using the already computed data; Receive challenge data sent from the server; Based on the set response key, response data is generated according to the received challenge data; as well as The generated response data and the acquired processed data are sent to the server. The server also performs the following processing: Receive the response data and the processed data; The server-side response key is set based on the received processed data; The response data sent from the client is verified based on the challenge data and the server-side configured response key; and The client will be notified of the verification result. The client also performs the following processing: Receive the result, The operation includes a first operation and a second operation based on the result of the first operation. The processed data is the result of performing the first operation. The server-side response key is set by performing the second operation based on the received processed data. The client also stores second computational data, which is the data used when performing the second computation. The client also stores a single, signed data comprising the second computational data and at least the signed data of the already computed data and the second computational data. The server-side response key is set to verify the signature and is based on the processed data and the second processed data.

Images