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

Abstract

The server issues challenge data and sends it to the client. The client stores the first parameter, sets a client-side response key, receives the challenge data, generates response data from the received challenge data using the response key, and sends the response data and the stored first parameter to the server. The server further receives the response data and the first parameter, identifies seed data for an operation to set a server-side response key using the first parameter, sets the server-side response key by performing an operation using the seed data, verifies the received response data using the challenge data and the server-side response key, and notifies the client of the result. The client receives the notification.

Description

[Technical Field]

[0001] The present disclosure relates to a device authentication method that uses a challenge and response scheme. [Background technology]

[0002] 2. Description of the Related Art Conventionally, a challenge-and-response authentication method has been known as a method for authenticating a client device (for example, Non-Patent Document 1). [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] RFC Editor, “RFC7616”, [online], [searched on August 29, 2020], Internet (URL: https: / / www.rfc-editor.org / info / rfc7616) Summary of the Invention [Problem to be solved by the invention]

[0004] There is room for providing a new method for device authentication using the challenge and response method. [Means for solving the problem]

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

[0006] (Configuration 1) Configuration 1 is an information processing system that includes a client and a server connected to a network, and performs authentication processing for the client between the client and the server using a challenge and response method. The server has means for issuing challenge data and transmitting it to the client. The client includes a means for storing a first parameter, a means for setting a client-side response key, a means for receiving challenge data, a means for generating response data from the received challenge data using the set client-side response key, and a means for transmitting the generated response data and the stored first parameter to the server. The server (meaning a group of servers, which may be a server device different from the server device that issues the challenge data and transmits it to the client) further includes means for receiving response data and a first parameter, means for identifying seed data for an operation that sets a server-side response key using the received first parameter, means for setting the server-side response key by performing an operation using the identified seed data, means for verifying the received response data using the challenge data and the set server-side response key, and means for notifying the client of the verification result. The client further comprises means for receiving a result of the verification.

[0007] According to the above configuration, the parameters stored in the client are sent to the server, and the server uses the parameters to identify seed data and set a response key on the server side, so that the response key can be tailored to the client. This configuration can be applied even when the seed data is confidential.

[0008] (Configuration 2) In a second configuration, in the first configuration, the response key on the client side may be set without using the first parameter.

[0009] (Configuration 3) In configuration 3, in configuration 1 or 2 above, the first parameter may be signed data with a signature of data including at least the first parameter, and the seed data may be identified using the first parameter while verifying the signature.

[0010] (Configuration 4) In configuration 4, in configuration 3, the client may further include means for storing a second parameter that is unsigned data, and means for transmitting the stored second parameter to the server. The server may further include receiving means for receiving the second parameter. The seed data may be identified using the first parameter and the second parameter.

[0011] According to the above configuration, the seed data can be identified from a number of different aspects using both signed and unsigned parameters.

[0012] (Configuration 5) In a fifth aspect of the fourth aspect, the server may further include means for storing data defining a correspondence between a combination of the first parameter and the second parameter and seed data. The seed data may be identified based on the defined data.

[0013] (Configuration 6) In configuration 6, in configuration 4, the calculation may include a first calculation and a second calculation, and the client may further include a means for storing calculation result data of the first calculation and a means for transmitting the calculation result data to the server. The server may further include a means for receiving the transmitted calculation result data, and the setting of the response key on the server side may be performed by executing a second calculation using the identified seed data and the calculation result data.

[0014] According to the above configuration, it is possible to omit at least a part of the calculations for setting the response key on the server side. For example, even if the values ​​and arithmetic expressions used in the calculations differ depending on the client, it is possible to suppress an increase in the amount of information processing on the server side. Furthermore, whether the values ​​and arithmetic expressions used in the calculations differ depending on the client or not, it is possible to reduce the risk of data leakage from the server by not storing various data (such as key data and seed data) used in the first calculation.

[0015] (Configuration 7) In configuration 7, in configuration 6, the calculation result data and the first parameter are signed data with at least a signature of the data attached, and the server-side response key may be set by verifying the signature and executing a second calculation using the identified seed data and the calculation result data.

[0016] (Configuration 8) In configuration 8, in the above configuration 1, the communication session for authentication processing between the server and the client includes a first communication session in which challenge data is sent and received, and a second communication session that is a communication session different from the first communication session in which response data is sent and received, the response data is verified, and the results are sent and received, and the server device for the first communication session and the server device for the second communication session may be allowed to be different.

[0017] (Configuration 9) In configuration 9, in configuration 8, the client may further include means for transmitting the received challenge data to the server, and the server may further include means for receiving the challenge data. In the verification, the received response data may be verified using the received challenge data and a set server-side response key.

[0018] (Configuration 10) In a tenth aspect of the present invention, in the first aspect, the client may further include means for delivering predetermined information to the application based on a result of the verification.

[0019] (Configuration 11) In configuration 11, in the above configuration 1, the verification result may include data for using a specified online service, and the client may further have a means for handing over the data for using the online service to the application.

[0020] (Configuration 12) In a twelfth aspect of the present invention, in the first aspect, the client may further include a means for using a predetermined online service based on a result of the verification.

[0021] (Configuration 13) Configuration 13 is the same as configuration 1, wherein the first parameter may have a different value depending on the client.

[0022] (Configuration 14) Configuration 14 is the same as configuration 3, wherein the first parameter and the second parameter may have different values ​​depending on the client.

[0023] (Configuration 15) The configuration 15 may be a client in the information processing system according to any one of the configurations 1 to 14 above.

[0024] (Configuration 16) The configuration 16 may be an information processing program for causing a computer to function as each of the means included in the server in the information processing system according to any one of the configurations 1 to 14 above.

[0025] (Configuration 17) The configuration 17 may be a server in the information processing system according to any one of the configurations 1 to 14 above.

[0026] (Configuration 18) The configuration 18 may be an information processing program for causing a computer to function as each of the means included in the server in the information processing system according to any one of the configurations 1 to 14 above.

[0027] (Configuration 19) Configuration 19 is a program that causes a client computer that performs authentication processing with a server using a challenge-and-response method to perform the following processes: setting a client-side response key; receiving challenge data from the server; generating response data from the received challenge data using the set client-side response key; sending the generated response data to the server; reading a first parameter used in the process of setting a server-side response key that is executed on the server side; sending the read first parameter to the server; and receiving an authentication result from the server based on a verification result of the response data, which is performed by identifying seed data for an operation that sets the server-side response key based on the first parameter.

[0028] (Configuration 20) In a 20th aspect of the present invention, in the 19th aspect, the response key on the client side may be set without using the first parameter.

[0029] (Configuration 21) Configuration 21 may be configured as in configuration 19 or 20, wherein the first parameter is signed data to which a signature of data including at least the first parameter is attached.

[0030] (Configuration 22) Configuration 22, in the above configuration 21, further causes the computer to execute a process of reading a second parameter, which is unsigned data, and a process of sending the read second parameter to a server, and the seed data identification performed on the above server may be performed using the first parameter and the second parameter.

[0031] (Configuration 23) In configuration 23, in configuration 22, the calculation may include a first calculation and a second calculation, and the computer may further execute a process of reading out calculation result data of the first calculation and a process of sending the calculation result data to the server, and the setting of the response key on the server may be performed by executing the second calculation using the identified seed data and the calculation result data.

[0032] (Configuration 24) Configuration 24 is the configuration 23 in which the calculation result data and the first parameter may be signed data with at least a signature of the data attached thereto.

[0033] (Configuration 25) Configuration 25 is the above configuration 19, in which the communication session for authentication processing between the server and the client includes a first communication session in which challenge data is sent and received, and a second communication session that is a communication session different from the first communication session in which response data is sent and received, the response data is verified, and the results are sent and received, and the server device for the first communication session and the server device for the second communication session may be allowed to be different.

[0034] (Configuration 26) Configuration 26, in the above configuration 25, further causes the computer to execute a process of transferring the received challenge data to a server, and the server may verify the received response data using the transferred challenge data.

[0035] (Configuration 27) Configuration 27 may be configured to cause the computer to execute a process of passing predetermined information to the application based on the result of the verification in configuration 26.

[0036] (Configuration 28) Configuration 28 may be configured as configuration 19, wherein the first parameter may have a different value depending on the client.

[0037] (Configuration 29) Configuration 29 is the configuration 22 in which the first parameter and the second parameter may have different values ​​depending on the client. [Brief explanation of the drawings]

[0038] [Figure 1] Schematic diagram showing an overall image of the system of this embodiment. [Figure 2] A diagram for explaining the outline of the response key setting process [Figure 3] Overview of the certificate creation process [Figure 4] An example of the configuration of certificate data D101 [Figure 5] A diagram showing an overview of the process of generating and transmitting a challenge dataset. [Figure 6] An example of the structure of challenge dataset D102 [Figure 7] An overview of the response dataset generation process [Figure 8] An example of data sent by Client 3 to Server 1 [Figure 9] FIG. 10 shows an overview of the response key setting process in the server 1. [Figure 10] An example of the data configuration of the counter value identification table SV404 [Figure 11] An example of the data configuration of the second KDF seed data identification table SV405 [Figure 12] Diagram for explaining the overview of the verification process [Figure 13] Block diagram showing the hardware configuration of client 3 [Figure 14] An example of data stored in the storage unit 32 of the client 3 [Figure 15] FIG. 1 is a diagram illustrating the functional configuration of the system program CL201. [Figure 16] An example of data stored in the storage unit 12 of the server 1 [Figure 17] An example of data stored in the storage unit 42 of the PC 4 [Figure 18]An example of a flowchart for certificate generation and writing processing [Figure 19] A diagram showing the details of the challenge session process [Figure 20] Flowchart showing details of challenge generation process [Figure 21] A detailed diagram of the process during a validation session [Figure 22] Flowchart showing details of response generation processing [Figure 23] A flowchart showing a first example of a first derivative key setting process. [Figure 24] A flowchart showing a second example of a first derived key setting process. [Figure 25] A flowchart showing a first example of a second derived key setting process. [Figure 26] A flowchart showing a second example of a second derived key setting process. [Figure 27] Flowchart showing details of the response dataset generation process [Figure 28] Flowchart showing details of verification process [Figure 29] Flowchart showing details of verification process [Figure 30] Flowchart showing details of online game processing DETAILED DESCRIPTION OF THE INVENTION

[0039] The following describes the embodiments.

[0040] This embodiment relates to processing related to device authentication. In this embodiment, an example of processing for device authentication is described, in which a predetermined communication service is provided to a device or a predetermined function of the device is enabled (more specifically, for example, when providing an online service (for example, online games, partner matching, access to online shops (download sites for software and content), etc.)). In device authentication, the legitimacy of a client device (hereinafter simply referred to as a client) is confirmed.

[0041] In this embodiment, a challenge-and-response method is used as a device authentication method. In this method, authentication is performed using the following method. First, FIG. 1 schematically shows the overall configuration of an authentication processing system according to this embodiment. In FIG. 1, a client authentication server (hereinafter simply referred to as a server) 1 and a client device (hereinafter simply referred to as a client) 3 are connected via a network. Note that the server 1 may be configured with multiple server devices. In this configuration, (1) a client 3 wishing to start an online game requests the server 1 (different from the server providing the online game in this embodiment) to send challenge data. (2) In response to the request, the server 1 generates challenge data and sends it to the client 3. (3) The client 3 performs a predetermined calculation process based on the challenge data to generate response data and send it to the server 1. (4) The server 1 verifies the response data received from the client and sends predetermined data to the client 3 depending on whether the verification was successful, thereby authenticating the legitimacy of the client 3. In a server configured with multiple server devices, the server device performing the process (2) above may be different from the server device performing the process (4).

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

[0043] [Response keys] The response key is key data used in the process of creating response data. The response data is generated by performing an operation using this response key on the challenge data received from the server 1.

[0044] FIG. 2 is a diagram for explaining an overview of the response key setting process in this embodiment, and shows a schematic diagram of the data flow in this process. In FIG. 2, elements shown in ovals indicate data / parameter elements, and elements shown in rectangles indicate processing elements. For ease of explanation, in FIG. 2, data / parameter elements are given reference symbols in the format "Dnn (nn is an integer)." Similar figures will appear hereafter, and these will also be given the same reference symbols.

[0045] In the example shown in FIG. 2, a key derivation function (hereinafter referred to as KDF) is used to generate key data from predetermined data, and the generated key data is set as a response key. Here, KDF is a function for generating another key based on key data. When key data and predetermined data called seed data are input to the KDF, another key data is generated based on these. Hereinafter, the key data output by the KDF will be referred to as a "derived key." Furthermore, in this embodiment, derived key data generated using a multi-stage KDF (in this embodiment, a two-stage KDF) is used as the response key. In the following description, the first-stage KDF will be referred to as the "first KDF," the second-stage KDF 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." The calculation content of each KDF may be any, for example, a KDF that uses HMAC or CMAC as a PRF, a KDF that uses a hash function or a block cipher, etc. Furthermore, the calculation content of the KDFs at each stage may be the same or different.

[0046] The flow of response key setting will be explained using Figure 2. The response key setting process is executed by both the server and the client, but in this embodiment, as will be described later, there are differences between the response key setting process executed by the server and the response key setting process executed by the client. Figure 2 explains the response key setting process executed by client 3. Note that the response key set by client 3 may be called the "response key (client)," and the response key set by server 1 may be called the "response key (server)." Furthermore, the second derived key calculated by client 3 may be called the "second derived key (client)," and the second derived key calculated by server 1 may be called the "second derived key (server)."

[0047] First, the storage unit of the client 3 stores a master key D01, a counter value D02, first KDF seed data D03, and second KDF seed data D04. The master key D01 is key data input to the first KDF. The master key D01 may be configured as fixed-value data or may be configured as changeable data. Furthermore, the master key D01 may be data that differs depending on the client. When the client is realized using emulator technology, the master key D01 may be the same data as the master key to be emulated.

[0048] The counter value D02, the first KDF seed data D03, and the second KDF seed data D04 are each data used as seed data for the KDF. The counter value D02 can take on different values ​​depending on the client 3. For example, it is a value that can be changed in response to a system update of the client 3, and specifically, is incremented by 1. In this embodiment, as an example, a case will be described where the counter value can take on any of four values ​​from 0 to 3. In addition, in this embodiment, the initial value of the counter value D02 is 0.

[0049] The first KDF seed data D03 is seed data input to the first KDF and may take different values ​​depending on the client 3. The second KDF seed data D04 is seed data input to the second KDF and may take different values ​​depending on the client 3. These seed data may be any data. For example, the first KDF seed data D03 may be a fixed value. More specifically, it may be identification data indicating a certain characteristic of the client 3. For example, it may be identification data indicating either a development machine or a production machine. Note that, when the client is implemented using emulator technology, the identification data may be data indicating the characteristics of the target to be emulated. Furthermore, the second KDF seed data D04 may be data that can be set or changed by the client 3 itself or in response to an external instruction from a server or the like. More specifically, it may be identification data indicating another characteristic of the client 3 (for example, data indicating security settings). It may also be data that differs depending on the system version (data that is updated due to a version upgrade). Note that, when the client is implemented using emulator technology, the identification data may be data indicating the characteristics of the target to be emulated. Furthermore, each of the KDF seed data D03 and D04 may be changed by, for example, updating the system software. Furthermore, both the first KDF seed data D03 and the second KDF seed data D04 may have different values ​​depending on the client.

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

[0051] Next, the second KDF seed data D04 is input to the second KDF together with the generated first derived key D05, thereby generating a "second derived key (client)" D06, which is a derived key output by the second KDF operation.

[0052] 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 process of generating a response data set D103, which will be described later.

[0053] Note that the calculation of each KDF in the response key setting process may be performed at runtime (i.e., calculated each time authentication processing is performed), but the results of calculations may be stored in advance and read out when authentication processing is performed, thereby avoiding calculations each time. For example, the first derived key data and / or the second derived key data may be calculated and stored when the system of client 3 is started, and the response key may be set by reading out the calculated data when authentication processing is performed. Also, for example, the calculated data (first derived key data and / or second derived key data) may be obtained from an external source and stored, and the response key may be set by reading out the calculated data when authentication processing is performed. Also, one of the first KDF calculation and the second KDF calculation may be performed at runtime, and the other may be set by reading out pre-calculated data.

[0054] As described above, in this embodiment, the response key setting process executed by the server 1 differs from the response key setting process executed by the client 3. One difference is that the response key setting process executed by the server 1 does not execute the first KDF calculation process. More specifically, calculated data (first derived key data; in this embodiment, encrypted first derived key data, as described below) resulting from the first KDF calculation is written in advance (before the start of the authentication process, for example, in the client 3 setting process executed in advance) to the storage unit of the client 3. Then, when the authentication process is executed, the calculated data is transmitted from the client 3 to the server 1, and the server 1 uses the calculated data to perform the second KDF calculation to set the response key, without executing the first KDF calculation. In this embodiment, as described below, this calculated data is included in the client certificate data (hereinafter simply referred to as certificate data).

[0055] Here, a method for generating certificate data will be described. The certificate data is stored in advance in the client 3 (before the authentication process begins). The certificate data is written to a storage unit (described later) of the client 3 during the client 3 configuration process. FIG. 3 is a diagram schematically illustrating an overview of the certificate creation process when the write process is performed by a PC (hereinafter referred to as PC4). In FIG. 3, first, a master key D01 of the client 3 to be manufactured, a counter value D02, and first KDF seed data D03 are input to the first KDF. This generates a first derived key D05. Note that the master key D01 may be read from the client 3 that is connected to the PC4 and is the target of the certificate data write process. Here, as described above, in this embodiment, the counter value D02 can take four values. Therefore, the first KDF calculation in PC4 is performed for each of the possible values ​​(0 to 3) of the counter value D02, and a first derived key D05 corresponding to each value of the counter value D02 is generated. That is, in this example, four first derived keys D05 are generated. Hereinafter, when these four first derived keys D05 are individually written, they will be written as first derived key (when counter value is 0) D05A, first derived key (when counter value is 1) D05B, first derived key (when counter value is 2) D05C, and first derived key (when counter value is 3) D05D.

[0056] Next, a process of encrypting each first derived key D05 is performed. Specifically, a process of encrypting each first derived key D05 is performed using a first server key D07, which is an encryption key. Hereinafter, the encrypted first derived key D05 is referred to as an "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 represented as a "first server key (when counter value is 0) D07A," the first server key used when the counter value D02 is 1 will be represented as a "first server key (when counter value is 1) D07B," and the encrypted encrypted first derived key will be represented as an "encrypted first derived key (when counter value is 0) D08A," an "encrypted first derived key (when counter value is 1) D08B," and the like. In this way, an encrypted first derived key D08 is generated for each counter value D02, and in this embodiment, a total of four encrypted first derived keys D08 are generated. Note that the first server key D07 may be a common key or a private key / public key.

[0057] Next, a digital signature (hereinafter simply referred to as a signature) D12 to be attached to the client certificate is generated. The signature D12 is generated by performing a calculation according to a predetermined signature generation algorithm using a signing key D09, which is a key for signing. Specifically, the signature D12 is generated by signing data including a total of seven data elements: (A) a client ID D10, (B) a first parameter for identifying a second KDF seed (hereinafter also referred to as a first identification parameter) D11, which will be described later, and (C) the above four encrypted first derived keys D08, using the signing key D09.

[0058] Here, the client ID_D10 is an ID for identifying the client 3. For example, the client ID_D10 may be the ID, serial number, or manufacturing number of the SoC of the client device. If the client is implemented using emulator technology, the number may be the information of the target to be emulated. When generating a certificate, for example, the client ID_D10 may be read and used from the client 3 that is connected to PC4 and is the target of the certificate data writing process. The first identification parameter D11 is also used by the server 1 to identify the value of the second KDF seed data D04 (details will be described later).

[0059] Next, certificate data D101 is generated, which includes the client ID D10, the first specified parameter D11, and the four encrypted first derived keys D08, and is affixed with the signature D12 generated as described above. Figure 4 shows the configuration of the certificate data D101. The certificate data D101 includes the signature D12, the four encrypted first derived keys D08A to D08D, the client ID D10, and the first specified parameter D11.

[0060] Finally, a process is executed to write the generated certificate data D101 to a non-volatile storage unit (described later) of the client 3. As described later, the certificate data D101 is transmitted from the client 3 to the server 1 during the authentication process, and each piece of data included in the certificate data D101 is used by the server 1. Of the data included in the certificate data D101, the encrypted first derived key D08 (strictly speaking, the first derived key D05 obtained by decrypting it) is first derived key data that is the result of a first KDF calculation, and the server 1 uses this data to set a response key. Therefore, the server 1 does not need to perform the first KDF calculation. Note that the certificate data D101 may be downloaded or transferred from a predetermined server or another PC to the client 3 and then written to the client 3.

[0061] In this embodiment, the counter value D02 is used as seed data for the KDF calculation to set the response key, which makes it possible to change the response key depending on the situation.

[0062] Furthermore, in this embodiment, a plurality of derived keys can be included in the certificate and selected for use, thereby enabling efficient change of the response key.

[0063] [Challenge generation and transmission overview] Next, an overview of the challenge data generation and transmission process in the server 1 will be described. This process is executed in response to a challenge issuance request from the client 3. The client 3 transmits certificate data D101 when a challenge issuance request is made. Figure 5 shows an overview of the challenge data generation and transmission process in the server 1, and is a diagram that schematically shows the data flow in this process. In this process, first, the certificate data D101 is received from the client 3 and verified (signature verification). If there are no problems as a result of this verification, the client ID_D10 is extracted from the certificate data D101.

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

[0065] In this embodiment, the challenge data is generated by a MAC operation, but any cryptographic operation that can generate tamper verification data (data used for tamper verification) may be used, for example, the AES-GCM algorithm, etc. The second server key used in the operation may be a common key or a private key / public key.

[0066] Here, the challenge version D14 is data stored in the server 1, and is information that defines the "version" of the method for generating challenge data generated by the server 1 at a certain point in time, and is information that indicates the current version. For example, the challenge version D14 is initially set to "1.0" and can be changed to "2.0" at a certain point in time.

[0067] The challenge issuance time D15 is the time on the server 1 when the process of generating challenge data is performed on the server 1.

[0068] Furthermore, the second server key D13 is key data used to calculate the first MAC value (challenge data) D16, and in this embodiment, the second server key D13 may differ for each challenge version D14 (the key may 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 to calculate the first MAC value (challenge data) D16. The first MAC value D16 is data that is the target of calculation using the response key in the client 3, and is so-called challenge data.

[0069] Once the first MAC value D16 is calculated, a challenge data set D102 is generated based on the (current) challenge version D14, the challenge issuance time D15, and the first MAC value (challenge data) D16. FIG. 6 schematically shows the configuration of the challenge data set D102. The challenge data set D102 is data that includes the challenge data as well as other data. In this embodiment, the challenge data set D102 is data that includes each of the following contents: "challenge version D14 + challenge issuance time D15 + first MAC value (challenge data) D16." While the result of the MAC calculation is generally added to the data (message data) to be calculated and transmitted, in this embodiment, the client ID_D10 is used to calculate the first MAC value but is not included in the challenge data set.

[0070] The challenge data set D102 generated as described above is sent to the client 3 that has requested the transmission of the challenge.

[0071] [Overview of response generation process on client 3] Next, an outline of the response generation process executed by the client 3 that has received the challenge data set D102 will be described. FIG. 7 is a diagram for explaining the outline of this process. First, a second MAC value (response data) D17 is calculated by performing a MAC operation on the first MAC value (challenge data) D16 included in the challenge data set D102 received from the server 1 using the response key (client) (second derived key (client) D06) set as described above with reference to FIG. 2. The second MAC value D17 is the result of calculating the challenge data using the response key, and is so-called response data. Note that the content of the MAC operation used to calculate the second MAC value (response data) D17 may be the same as the content of the MAC operation used to calculate the first MAC value (challenge data) D16, or may be different. Note that the length of the first MAC value, which is data input to the second MAC operation, is determined by the content of the first MAC operation and is a fixed length regardless of the length of the data input to the first MAC operation. In this embodiment, a MAC operation is used to generate response data from challenge data using a response key, but any algorithm that can generate response data from challenge data using a response key is acceptable, not limited to a MAC operation.

[0072] Next, a response data set D103 is generated based on the second MAC value (response data) D17 and the challenge version D14 and challenge issue time D15 included in the received challenge data set D102. The response data set D103 includes the response data, as well as other data (in this embodiment, data other than the challenge data included in the challenge data set D102 received from the server 1; specifically, the challenge version D14 and the challenge issue time D15). As described above, the value resulting from the MAC calculation is generally added to the data to be calculated (message data) before being transmitted. However, in this embodiment, the first MAC value (challenge data) D16 is used to calculate the second MAC value (response data) D17, but is not included in the data (the response data set and client transmission data described below) when transmitting the result to the server.

[0073] Once the response data set D103 is generated, the client 3 transmits (A) the response data set D103, (B) the certificate data D101, and (C) a second parameter for identifying second KDF seed data (hereinafter, also referred to as a second identification parameter) D19, which will be described later, to the server 1. FIG. 8 is a schematic diagram of data (hereinafter, also referred to collectively as client transmission data D104) that the client 3 transmits to the server 1. Note that each piece of client transmission data may be transmitted as a single unit, or may be transmitted separately at different times. In FIG. 8, the response data set D103 includes a challenge version D14, a challenge issuance time D15, and a second MAC value (response data) D17. This is configured as if the first MAC value (challenge data) D16 of the challenge data set D102 above had been replaced with the second MAC value (response data) D17. That is, the challenge version D14 and challenge issuance time D15 included in the challenge data set received from the server 1 when the challenge data is received are included in the response data set and transmitted to the server 1 when the response data is transmitted. The certificate data D101 is the same as the certificate data D101 transmitted when a challenge issuance request is made. That is, the certificate data D101 is transmitted when a request is made to the server 1 to transmit challenge data and when response data is transmitted to the server 1. The second specifying parameter D19, together with the first specifying parameter D11, is a parameter used to identify the value of the second KDF seed data D04 in the processing of the server 1 (details will be described later).

[0074] Next, an overview of the process of response verification in the server 1 that receives the client transmission data D104 will be described. First, a response key (server) is set in the server 1. Next, a second MAC value (at verification) D217 is calculated using the set response key (server). Then, the response data D17 is verified by determining whether the second MAC value (at verification) D217 calculated by the server 1 matches the second MAC value (response data) D17 sent from the client.

[0075] FIG. 9 is a diagram for explaining an overview of the response key setting process in the server 1. First, the signature D12 is verified for the certificate data D101 included in the client transmission data D104. If the verification is successful, the encrypted first derived key D08 and the first identification parameter D11 are extracted from the certificate data D101. As described above, the certificate data D101 includes four encrypted first derived keys D08, and one of these is identified and extracted using the following procedure. First, the current counter value D02 of the client 3 is identified. This identification is performed by referring to a "counter value identification table" stored in advance in the server 1. The counter value identification table is a table for identifying the current counter value D02 of the client 3 based on the first identification parameter D11 and the second identification parameter D19 transmitted from the client 3. That is, the current counter value D02 of the client 3 that sent the response data (the client 3 to be authenticated) is identified using the first identification parameter D11 extracted from the certificate data D101 and the second identification parameter D19 sent together with the certificate data D101. Fig. 10 shows an example of the data configuration of the counter value identification table SV404. In the counter value identification table SV404, the counter value D02 is defined in association with a combination of the value of the first identification parameter D11 and the value of the second identification parameter D19.

[0076] 9 , the server 1 next selects, from among the multiple encrypted first derived keys D08 included in the certificate data D101, the encrypted first derived key D08 that corresponds to the counter value D02 identified using the counter value identification table SV404, and extracts it from the certificate data D101. The server 1 then decrypts the extracted encrypted first derived key D08 using the first server key D07 stored in the server 1, thereby obtaining the first derived key D05. Here, the first server key D07 is key data that differs depending on the counter value D02, as described above. Here, if the counter value D02 can differ depending on the client 3, the server 1 stores each first server key D07 that corresponds to each possible counter value D02, and uses the first server key D07 that corresponds to the identified counter value D02.

[0077] Next, the second KDF process is executed using the decrypted first derived key D05 and the second KDF seed data D204. Here, the (value of) the second KDF seed data D204 in the second KDF process is determined as follows. A "second KDF seed data identification table" is used to identify the value of the second KDF seed data D204. The second KDF seed data identification table is a table for identifying the second KDF seed data D04 based on the first identification parameter D11 and the second identification parameter D19. That is, the second KDF seed data D04 of the client 3 that sent the response data is identified using the first identification parameter D11 extracted from the certificate data D101 and the second identification parameter D19 sent from the client together with the certificate data D101. FIG. 11 shows an example of the data configuration of the second KDF seed data identification table SV405. In the second KDF seed data identification table SV405, values ​​of the second KDF seed data D204 are defined in association with combinations of the first identification parameter D11 and the second identification parameter D19. That is, as described above with reference to FIG. 2, in the response key setting process of the client 3, a response key is set using the second KDF seed data stored in the client 3. On the other hand, in the response key setting process of the server 1, the value D04 of the second KDF seed data stored in the client 3 that sent the response data is identified based on the first identification parameter D11 and the second identification parameter D19 received from the client 3, and the response key is set using that value. This is one of the differences between the response key setting process executed by the server and the response key setting process executed by the client.

[0078] In this embodiment, the server 1 identifies the KDF seed data using a specific parameter sent from the client 3. This configuration enables response key setting that takes into account the attributes and status of the client (or the client device to be emulated, if implemented using emulator technology). In addition, in this embodiment, two parameters are used to identify the KDF seed data, with the first specific parameter being the signature target and the second specific parameter not being the signature target. This configuration allows for flexibility in the configuration of the KDF seed data, for example, by using a parameter that can be signed and a parameter that is difficult to sign.

[0079] The parameters to be used as the first specifying parameter D11 and the second specifying parameter D19 may be appropriately designed. For example, the first specifying parameter D11 may be a fixed value. For example, the first specifying parameter D11 may be attribute information of the hardware of the client 3. The second specifying parameter D19 may be data that can be set or changed in the client 3. For example, the first specifying parameter D11 may be attribute information of software or attribute information of system software (e.g., version information of the system software). The first specifying parameter D11 may be data that can be set or changed in the client 3, and the second specifying parameter D19 may be a fixed value. Note that, when the client 3 is realized using emulator technology, the first specifying parameter and the second specifying parameter may be attribute information of the emulation target, etc. However, in this embodiment, the first specifying parameter and the second specifying parameter are data different from the second KDF seed data, and are data that can identify the second KDF seed data by combining the first specifying parameter and the second specifying parameter. Also, in this embodiment, the first specifying parameter and the second specifying parameter are data different from the first KDF seed data.

[0080] 9, in the server 1, a second KDF calculation process is performed using the second KDF seed data D204 determined as described above and the first derived key D05 extracted from the certificate data D101, thereby generating a second derived key (server) D206. The calculation content (algorithm) of the second KDF performed in the server 1 is the same as the calculation content of the second KDF performed in the client 3. Then, in the server 1, the generated second derived key (server) D206 is used as a response key. That is, the response key (server) is set by generating the second derived key (server) D206.

[0081] Here, if the data on which the KDF calculation is based and the calculation contents of the KDF calculation differ depending on the configuration of the client, it is necessary to manage a database or the like for changing the data on which the KDF calculation is based and the calculation contents of the KDF calculation according to the configuration of each client when generating a derived key in the server 1. However, in this embodiment, for the first KDF calculation, the data on which the KDF calculation has been performed (derived key) is sent from the client 3 to the server 1, and the server 1 uses this to generate a response key, so there is no need to have such a database.

[0082] In this embodiment, the KDF calculation is performed in multiple stages, and for the first KDF calculation, the calculated derived key is sent from the client 3 to the server 1, and the server 1 uses this to perform another KDF calculation (second KDF calculation) to generate a response key. This allows some of the multiple aspects that are elements of verification to be calculated in advance and the other parts to be calculated by the server, making it possible to perform verification using a method that suits the properties of the elements of verification.

[0083] 9, the response data set D103 is not used in the response key setting process in the server 1. In the verification process described next, the second MAC value (response data) D17 included in the response data set D103 is verified.

[0084] [Verification process overview] Next, an overview of the verification process performed by the server (in this embodiment, this includes not only verification of response data but also verification of the challenge issuance time included in the response data, as will be described later) will be described. Fig. 12 is a diagram for explaining the overview of the verification process. In the verification process, the server 1 calculates a second MAC value (at the time of verification) D217 and determines whether it matches the second MAC value (response data) D17 sent from the client 3, thereby verifying the second MAC value D17, which is the response data.

[0085] First, the server 1 performs a process of calculating a first MAC value (at verification) D216. This process is basically the same as the process of calculating the first MAC value (challenge data) D16 in the challenge generation process described above with reference to Fig. 5. Based on the challenge version D14 included in the response data set D103 sent from the client 3, the server 1 selects a second server key D13 corresponding to the challenge version D14. Then, using the selected second server key D13, the server 1 calculates a MAC value based on "the challenge version D14 and challenge issue time D15 included in the response data set D103, and the client ID_D10 included in the certificate data D101 sent from the client (the certificate data D101 sent at the time of the verification request)," thereby calculating the first MAC value (at verification) D216.

[0086] Regarding the calculation process of the first MAC value (at verification) D16, in another embodiment, the first MAC value (challenge data) D16 calculated in the challenge generation process may be stored in the server 1. The stored first MAC value (challenge data) D16 may then be used in the verification process, thereby omitting the calculation process of the first MAC value (at verification) D16.

[0087] Next, using the response key (server) D206 and the first MAC value (verification) D216 that have been set, the second MAC value (verification) D217 is calculated by the same algorithm as the MAC calculation in the client 3.

[0088] Next, the second MAC value (response data) D17 included in the response data set D103 is compared with the calculated second MAC value (at verification) D217 to determine whether they match. If they match, the response verification result is determined to be OK (positive), and if they do not match, the response verification result is determined to be NG (negative).

[0089] Furthermore, in this embodiment, the server 1 performs a verification process from a time perspective. In this process, it is determined whether the time from when the server 1 issues the challenge data set D102 to when the client returns the response data set D103, etc. (or the time from when the challenge data is issued to when the verification is executed) is within a certain time. Specifically, the challenge issuance time D15 included in the response data set D103 is compared with the current time of the server 1 at the time when the verification process is executed. If this time is within the certain time, it is determined as OK, and if it takes more than the certain time, it is determined as NG.

[0090] If both the verification of the response data D17 and the verification from a time perspective are OK, the authentication is determined to be successful. Otherwise, the authentication is determined to be unsuccessful. If the authentication is successful, a process is executed to send a predetermined service token to the client. If the authentication is unsuccessful, an error message or the like is sent. The content of the service token is information including, for example, a client ID, an identifier of a predetermined online service, an expiration date, and a signature or MAC value of these data.

[0091] As described above, in this embodiment, when a challenge is issued, the server 1 transmits to the client 3 a MAC value (first MAC value) that is calculated using at least the time the challenge is issued, along with the time the challenge is issued. Furthermore, when generating response data, the client 3 generates a value (second MAC value) by further performing a MAC operation on that MAC value using the response key, and transmits this response data to the server 1. The server 1 then verifies this value, and furthermore, the server 1 also performs temporal verification using the time the challenge is issued. This makes it possible to prevent fraud during the authentication process.

[0092] The processing according to this embodiment will be described in detail below.

[0093] [Client 3 hardware configuration] Next, the hardware configuration of the client 3 will be described. FIG. 13 is a block diagram showing the hardware configuration of the client 3. In this embodiment, the client 3 is a game device, but it may also be a general-purpose PC, smartphone, tablet device, etc. The client 3 is an example of a computer and includes a processor, memory, peripheral processors such as a communication processor and a display processor, etc. The client 3 includes at least a processing unit 31, a storage unit 32, a network communication unit 35, an operation device 36 (game controller), and an image output unit 37. The processing unit 31 is, for example, a processor and executes various programs for controlling the client 3. The client 3 may be composed of multiple devices. The processing unit 31 may also be composed of multiple processors, in which case multiple processors in multiple devices may be used. The processor may be a general-purpose processor or a dedicated processor, and may be, for example, a SoC, a CPU, an ASIC, a microcomputer, etc. The storage unit 32 stores various programs executed by the processing unit 31 and various data used by the processing unit 31. The program may be a group of programs composed of multiple programs, each of which may be executed by a different processor and stored in a different memory. The program may be any type of software, such as application software, system software, firmware, or an emulator. The program may include data and table parameters in addition to code. Specifically, the storage unit 32 includes a non-volatile storage unit 33 and a volatile storage unit 34. The non-volatile storage unit 33 is, for example, a flash memory or a solid-state drive (SSD). The volatile storage unit 34 is, for example, a dynamic random access memory (DRAM) and functions as a main memory. Various programs and data stored in the non-volatile storage unit 33 are loaded into the volatile storage unit 34 as needed, and the processing unit 31 may execute various processes, as described below. The network communication unit 35 communicates (wirelessly or wired) with other servers and clients 3 via a network, such as the Internet. The network communication unit 35 may also be configured to communicate directly with communication partners without using a network.The operation device is a variety of operation devices (keyboard, mouse, etc.) The image output unit 37 outputs a predetermined image generated as a result of information processing by the processing unit 31.

[0094] Note that a part of the area of ​​the non-volatile memory unit 33 or the volatile memory unit 34 may be configured as a secure area. Some of the various data described below may be configured to be stored in a secure area such as a memory in an SoC (System on a Chip).

[0095] The hardware configuration of the server 1 and PC 4 may be the same as that of a general server or PC, and will not be described further, but is the same as that shown in FIG. 13. The server 1 may be made up of multiple server devices. That is, the server 1 is made up of a processing unit 11, a storage unit 12 including a non-volatile storage unit 13 such as a flash memory and a volatile storage unit 14 such as a DRAM, etc. The server 1 is an example of a computer. The PC 4 is made up of a processing unit 41, a storage unit 42 including a non-volatile storage unit 43 such as a flash memory and a volatile storage unit 44 such as a DRAM, etc.

[0096] Next, various types of data used in the processing according to this embodiment will be described.

[0097] [Data used in Client 3] Fig. 14 shows an example of data stored in the storage unit 32 of the client 3. The data shown in Fig. 14 indicates data stored in the non-volatile storage unit 33, and when performing authentication processing, this data is read into the volatile storage unit 34 as necessary, thereby enabling the authentication processing to be performed. Note that this data may be stored separately in different memories. For example, some of the data may be stored in the above-mentioned secure area.

[0098] 14, at least a system program CL201, an online game program CL202, a master key D01, a counter value D02, first KDF seed data D03, second KDF seed data D04, certificate data D101, and a second parameter D19 for identifying second KDF seed data are stored in non-volatile memory unit 33. Note that in FIG. 14, the content of each piece of data other than the system program CL201 and online game program CL202 is the same as the various data described above.

[0099] In FIG. 14, the system program CL201 is a program for controlling the system of the client 3. The system program CL201 includes at least a program for realizing the authentication function of this embodiment, as shown in FIG. 15. First, the system program CL201 includes a challenge issuance request program that requests the server 1 to issue a challenge. The system program CL201 also includes a response key setting program having a function for setting a response key (client). The system program CL201 also includes a response generation and transmission program having a function for receiving a challenge data set D102, generating a response data set D103, and transmitting the response data set D103 and the like (the above-mentioned client transmission data). The system program CL201 also includes an authentication result processing program having a function for starting an online game based on the authentication result. The device authentication processing according to this embodiment is executed as one of the processes on the system side that controls the client 3 (rather than application processing).

[0100] 14, the online game program CL202 is a program for a predetermined online game. In this embodiment, as described above, device authentication processing is executed when playing an online game starts.

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

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

[0103] For example, in another embodiment, the data of the second derived key D06 may be stored in the storage unit 32. In this case, the master key D01, the first KDF seed data D03, and the second KDF seed data D04 may not be stored. In this case, the response key setting program may not have the first derived key setting function.

[0104] [Data used on Server 1] Next, a description will be given of the data stored in the storage unit 12 of the server 1. Fig. 16 shows the data stored in the non-volatile storage unit 13 of the server 1. When performing the authentication process, this data is read into the volatile storage unit 14 as needed, so that the authentication process can be performed on the server 1 side.

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

[0106] The authentication program SV401 is a program for executing authentication processing on the server 1 side. The authentication program SV401 is a program having a challenge issuing function for issuing the above-mentioned challenge data to the client 3 and transmitting other data, and a verification function for verifying using the response data set D103 etc. from the client 3. The verification function also includes a function for setting the response key (server) described above with reference to FIG. 12.

[0107] Here, a supplementary explanation will be given regarding the first server key D07. As described above, in this embodiment, a plurality of key data corresponding to counter values ​​are prepared for the first server key D07, and any one of these key data is stored as the first server key D07 stored in the server 1. Then, every time the counter value is incremented, the key data is replaced with the key data corresponding to the counter value.

[0108] Note that when the counter value D02 of a client 3 is incremented when the client 3's system is updated, the timing of updating the counter value D02 is not necessarily the same for each client 3. For this reason, for a certain period of time after the occurrence of the increment of the counter value D02 (for example, the timing of the system update), the first server key D07 corresponding to the counter value D02 before the increment may be stored as the "old first server key." Then, for the certain period of time, even when authentication is requested by a client 3 whose system has not yet been updated, the authentication may be determined to be successful using the "old first server key."

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

[0110] The counter value specification table SV404 contains data such as that shown in Fig. 10. Therefore, detailed description will be omitted here.

[0111] The second KDF seed data identification table SV405 contains data such as that shown in Fig. 11. Therefore, a detailed description will be omitted here.

[0112] CA public key SV406 is key data paired with signature key D09, and is key data (a decryption key or verification key in a public key cryptosystem) used when server 1 verifies signature D12 of certificate data D101.

[0113] The challenge version D14 is the challenge version attached to the challenge issued at that time. As described above, in this embodiment, since the second server key D13 differs for each challenge version, when the challenge data D16 is generated, the challenge version D14 is used to determine which second server key D13 was used to calculate the first MAC value (challenge data) D16. Note that various processes of the server 1 and / or the client 3 other than changing the second server key D13 may be changed depending on the challenge version. In this case, the process may be branched depending on the challenge version D14 included in the challenge.

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

[0115] The certificate generation / writing program FC501 is a program for generating the certificate data D101 described above with reference to FIG.

[0116] It is assumed that the first parameter D11 for specifying the second KDF seed data used by the PC 4 is set in advance to a predetermined value according to the client 3 to which the data is to be written.

[0117] Below, the details of the processing performed by the PC 4, client 3, and server 1 are explained using flowcharts. Note that the flowcharts shown below are merely examples of the processing steps. Therefore, the order of the steps may be changed as long as the same results are obtained. Furthermore, the values ​​of the variables and the thresholds used in the judgment steps are merely examples, and other values ​​may be used as necessary.

[0118] First, we will explain the details of the certificate generation and writing process executed by the PC 4. Fig. 18 is an example of a flowchart of the certificate generation and writing process. First, the processing unit 41 of the PC 4 sets a counter value n, which is a variable, to 0 (step S201).

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

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

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

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

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

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

[0125] Next, the processing unit 41 creates certificate data D101 (see FIG. 4) that includes the four encrypted first derived keys D08, the client ID D10, and the first specific parameter D11 and is given the signature D12 created above. Furthermore, the processing unit 41 writes the certificate data D101 to the non-volatile storage unit 33 of the client 3 (step S208). Note that the certificate data may be downloaded or transferred from a predetermined server or another PC and written to the non-volatile storage unit 33 of the client 3.

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

[0127] [Challenge issuance session processing details] Fig. 19 is a diagram showing details of the processing in a challenge issuance session. Fig. 19 shows the processing of the processing unit 31 of the client 3 that executes the system program (authentication function) CL201 and the processing unit 11 of the server 1 that executes the authentication program SV401. In Fig. 19, first, the processing unit 31 of the client 3 establishes a session with the server 1 and performs processing to transmit a request for challenge issuance and certificate data D101 via the network communication unit 35 (step S1).

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

[0129] Next, the processing unit 11 verifies the signature D12 (step S3). Specifically, the processing unit 11 decrypts the signature D12 using the CA public key SV406. Then, using the decryption result, it is determined that the four encrypted first derived key D08, the client ID_D10, and the first specific parameter D11 included in the certificate data D101 have not been tampered with, and if they match, the verification result is determined as positive. Note that if the decryption result does not match, it is determined as negative, and the challenge data set D102 is not transmitted, and the client 3 is notified of this (communication may be terminated without notifying), and the processing ends.

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

[0131] 20 is a flowchart showing the details of the challenge generation process (step S5). First, the processing unit 11 acquires the current time of the server as the challenge issuance time D15 (step S21).

[0132] Next, the processing unit 11 calculates a first MAC value (challenge data) D16 using the second server key D13 corresponding to the challenge version D14, based on the challenge version D14 read from the memory unit 12, the challenge issuance time D15 obtained in step S21, and the client ID D10 obtained in step S4 (step S22).

[0133] Next, the processing unit 11 generates a challenge data set D102 including the challenge version D14, the challenge issue time D15, and the first MAC value (challenge data) D16 calculated in step S22 (step S23). This ends the challenge generation process.

[0134] Returning to FIG. 19, once the challenge data set D102 is generated, the processing unit 11 performs processing to transmit the challenge data set D102 to the client 3 via the network communication unit 15 (step S6).

[0135] Next, the processing unit 31 of the client 3 performs processing to receive the challenge data set D102 via the network communication unit 35 (step S7). Thereafter, the challenge issuing session is ended (step S8).

[0136] 21 is a diagram showing details of the processing in the verification session. First, upon receiving the challenge data set D102, the processing unit 31 of the client 3 executes a response generation process (step S9).

[0137] Fig. 22 is a flowchart showing details of the response generation process executed in the client 3. In Fig. 22, first, the processing unit 31 executes a first derived key setting process (step S31).

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

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

[0140] Note that the first derived key D05 calculated in advance may be stored in the storage unit 32, but in this case, as the first derived key setting process, the processing unit 31 may set the first derived key by reading out the first derived key data stored in advance from the storage unit 32 (step S43), as shown in Fig. 24. In other words, if the first derived key D05 calculated using the first KDF is stored as data in the client 3, the calculation process using the first KDF may be omitted.

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

[0142] The second derived key (client) D06 calculated in advance may be stored in the storage unit 32. In this case, the processing unit 31 may set the second derived key by reading out the data of the second derived key (client) D06 stored in advance from the storage unit 32 (step S53), as shown in FIG. 26. In other words, if the client 3 stores the second derived key, which is data on which the second KDF calculation has been performed, the second KDF calculation process may be omitted. In addition, in this example, the first derived key setting process itself may also be omitted.

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

[0144] Returning to Fig. 22, next, the processing unit 31 executes a response data generation process (step S34). Fig. 27 is a flowchart showing the details of the response data generation process. First, the processing unit 31 reads out the first MAC value (challenge data) D16 from the challenge data set D102 received in step S8 of Fig. 19 (step S61).

[0145] Next, the processing unit 31 calculates a 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).

[0146] Next, the processing unit 31 generates a response data set D103 (see FIG. 8 above) including the challenge version D14 and challenge issue time D15 included in the challenge data set D102 received in step S8 of Fig. 21, and the second MAC value (response data) D17 calculated above (step S63). This ends the response data set generation process.

[0147] 22 shows an example in which the processes of steps S31 to S34 are executed as a series of steps. In other embodiments, the process of setting the response key (client) (steps S31 to S32) may be performed in advance and stored in the storage unit 32, and this may be read out in step S9. For example, this process may be performed when the client 3 is started up, and the response key (client) data may be stored in the storage unit 32, and this may be read out in step S9.

[0148] Returning to FIG. 21, once the response generation process is completed, 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 a process of transmitting the verification request and the client transmission data D104 to the server 1 via the network communication unit 35 (step S10). That is, the response data set D103 generated in step S9, and the certificate data D101 and second specification parameter D19 read from the storage unit 32 are transmitted to the server 1. The system program (authentication function) CL201 may have a function of specifying an area in which the certificate data D101 is stored, and the certificate data D101 may be read from the specified area. The response generation / transmission program may have a function of specifying an area in which the second specification parameter D19 is stored, and the second specification parameter may be read from the specified area. In addition, the system program (authentication function) CL201 may have a function to acquire (e.g., download) the certificate data D101 and / or the second specific parameter D19 from a specified server or PC, and may store the acquired certificate data D101 and / or the second specific parameter D19 in the specified area.

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

[0150] Next, the processing unit 11 executes verification processing (step S12). Figures 28 and 29 are flowcharts showing the details of the verification processing. In Figure 28, first, the processing unit 11 verifies the signature D12 of the received certificate data D101 (step S71). This processing is the same as the processing described above, so a detailed description will be omitted.

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

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

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

[0154] Next, the processing unit 11 decrypts the extracted encrypted first derived key D08 to generate the first derived key D05 using the first server key D07 corresponding to the specified counter value D02 (step S75).

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

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

[0157] Next, the processing unit 11 calculates a second MAC value (at verification) D217 based on the first MAC value (at verification) D216 and the response key (server) set in step S76 (the second derived key (server) D206 generated in step S76) (step S78). Note that the calculation algorithm used in this process is the same as the algorithm used by the client 3 to calculate the second MAC value.

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

[0159] Next, the processing unit 11 determines whether or not there is a match as a result of the above verification (step S80). If there is no match (NO in step S80), the processing unit 11 executes a process of returning an error to the client 3 (step S83). Thereafter, the verification process ends. On the other hand, if there is a match (YES in step S80), the response data D17 received from the client 3 is considered to be valid. Note that, since the client ID is the object of calculation for the MAC value, if the second MAC value (response data) and the second MAC value (at the time of verification) match, it can be determined that the client to which the challenge data was issued in the challenge issuance session and the client that sent the response data D17, etc. in the verification session are the same client 3 (there is a match). Note that it is not necessary to compare the client ID in the challenge issuance session with the client ID in the verification session.

[0160] If the answer is YES in step S80, the processing unit 11 performs verification from a time perspective. Specifically, the processing unit 11 determines whether or not a certain time has passed since the challenge issuance time D15 included in the received response data set D103. If the result of the determination is that a certain time has passed (YES in step S81), the process proceeds to step S83, where an error is returned to the client 3. On the other hand, if the time has not passed (NO in step S81), the processing unit 11 generates a predetermined service token, assuming that the authenticity of the client 3 has been confirmed and verification has been successful. Thereafter, the response verification process ends.

[0161] In the above example, the second MAC value is verified first, and then verification from a time perspective is performed. However, the order of the verifications may be reversed.

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

[0163] Next, the processing unit 31 of the client 3 performs processing to receive the service token via the network communication unit 35 (step S14), after which the response session is ended (step S15).

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

[0165] The communication related to the challenge issuing session and the communication related to the verification session may use any communication method, such as encrypted communication using SSL or the like, or may be unencrypted communication.

[0166] Next, an example of online game processing in the client 3 using the above-described authentication processing will be described with reference to Figure 30. In Figure 30, first, the processing unit 31 accepts a request to start an online game (step S101). For example, the processing unit 31 accepts an operation to start the online game by the user.

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

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

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

[0170] Thereafter, the processing unit 31 executes the online game while communicating with the online game server or other clients 3 as necessary (step S105). Next, the processing unit 31 determines whether or not the conditions for ending the online game have been met (step S106). If the conditions have not been met (NO in step S106), the execution of the online game continues; if the conditions have been met (YES in step S106), the online game processing ends.

[0171] This concludes the detailed description of each process according to this embodiment.

[0172] [Variations] In other embodiments, a counter value may not be used as seed data for the first KDF. That is, the first KDF may be calculated using the master key D01 and the first KDF seed data D03 to generate the first derived key D05. In this case, the certificate includes one encrypted first derived key D05. It goes without saying that the counter value is not limited to values ​​between 0 and 3. A predetermined variable value may be used instead of a counter, and the counter value does not need to be changed in an incrementing manner.

[0173] In the above embodiment, an example was shown in which the response key setting process uses two KDF calculations: a first KDF calculation and a second KDF calculation. In other embodiments, the KDF calculation may be performed in one stage, or the number of KDF calculation stages may be increased, and the result (derived key) of a further KDF calculation performed after the second KDF calculation may be set as the response key. As the "further KDF calculation," for example, a KDF calculation may be performed using data in the volatile memory or nonvolatile memory of the client 3 or data obtained by processing the data as seed data. The data in this memory may be different data for each version of the system software.

[0174] In the above embodiment, the second KDF seed data D04 was identified and used based on the first identification parameter D11 and the second identification parameter D19 in the response key setting process in the server 1. In this regard, in other embodiments, the response key may be set without using these parameters. For example, the second KDF seed data may be identified using a single parameter, or the second KDF seed data itself may be transmitted from the client 3 to the server 1. Alternatively, if the second KDF seed data is common to all clients, the second KDF seed data may be stored in the server 1.

[0175] Furthermore, in the above embodiment, the first KDF calculation is not performed by the server 1. However, the master key D01 and the first KDF seed data may be identified by the server 1, and the first KDF calculation may be performed by the server 1. In this case, the encrypted first derived key D08 in the certificate data D101 becomes unnecessary. In this case, data obtained by encrypting the master key D01 with the first server key may be included in the certificate data D101. Then, the server 1 may decrypt the master key D01 and perform the above-mentioned first KDF processing to obtain the first derived key D05.

[0176] Furthermore, in the above example, the challenge data is generated by performing a MAC operation using the second server key to calculate the first MAC value. In other embodiments, a signature may be performed instead of the MAC operation. For example, an RSA signature may be used.

[0177] Furthermore, in generating the response data using the response key, the response data may be generated using a block encryption operation instead of the second MAC value operation. The block encryption operation may be, for example, AES.

[0178] In another embodiment, the client 3 may be configured to transmit a parameter for specifying the current value of the counter value D02 together with the response data D17 when transmitting the response data D17. The server 1 may then use the transmitted parameter to specify the counter value D02 and set the response key using the processing described above.

[0179] Furthermore, in the above embodiment, the challenge issuance session and the verification session are different communication sessions, but the challenge issuance and verification may be performed in a single session.

[0180] In the above embodiment, the encrypted derived key is included in the client certificate, but the encrypted derived key may be sent to the server separately from the client certificate when transmitting response data. This is similar to the first parameter for identifying the second KDF seed data. The second parameter for identifying the second KDF seed data may also be included in the certificate, and the certificate may be sent with a separate signature. [Industrial Applicability]

[0181] The information processing system according to the present disclosure can provide a novel authentication method for device authentication of a client. [Explanation of symbols]

[0182] 1 server 3 Client 4 PC 11 Processing section 12 Storage section 13 Non-volatile memory unit 14 Volatile memory unit 15 Network Communications Department 16 Control Devices 17 Image output section 31 Processing section 32 Storage section 33 Non-volatile memory unit 34 Volatile memory unit 35 Network Communications Department 36 Control Devices 37 Image output unit 41 Processing section 42 Storage section 43 Non-volatile memory unit 44 Volatile memory unit 45 Network Communications Department 46 Control Devices 47 Image output unit

Claims

1. An information processing system 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 and response method, The server has a means for issuing challenge data and transmitting it to the client; The client: means for storing a first parameter; A means for setting a client-side response key; means for receiving the challenge data; means for generating response data from the received challenge data using the set client-side response key; the server is provided with a means for transmitting the generated response data and the stored first parameter; The server further means for receiving the response data and the first parameter; means for specifying seed data for an operation to set a response key on the server side using the received first parameter; a means for setting a response key on the server side by executing the calculation using the specified seed data; means for verifying the received response data using the challenge data and the set server-side response key; means for notifying the client of the result of the verification; The client further An information processing system comprising means for receiving a result of said verification.

2. 2. The information processing system according to claim 1, wherein the setting of the response key on the client side is performed without using the first parameter.

3. the first parameter is signed data to which a signature of data including at least the first parameter is attached, The information processing system according to claim 1 , wherein the seed data is identified by verifying the signature and using the first parameter.

4. The client further means for storing a second parameter, the second parameter being unsigned data; means for transmitting the stored second parameter to the server; The server further includes a receiving means for receiving the second parameter; The information processing system according to claim 3 , wherein the seed data is specified using the first parameter and the second parameter.

5. the server further includes means for storing data defining a correspondence between the combination of the first parameter and the second parameter and the seed data; The information processing system according to claim 4 , wherein the seed data is specified based on the specified data.

6. the operations include a first operation and a second operation; The client further means for storing the operation result data of the first operation; means for transmitting the calculation result data to the server; The server further a means for receiving the transmitted calculation result data, 5. The information processing system according to claim 4, wherein the server-side response key is set by executing the second operation using the specified seed data and the operation result data.

7. the operation result data and the first parameter are signed data to which at least a signature of the data is attached, 7. The information processing system according to claim 6, wherein the server-side response key is set by verifying the signature and executing the second operation using the identified seed data and the operation result data.

8. a communication session for the authentication process between the server and the client includes a first communication session in which the challenge data is transmitted and received, and a second communication session that is different from the first communication session and in which the response data is transmitted and received, the response data is verified, and the verification result is transmitted and received; The information processing system according to claim 1 , wherein the server device of the first communication session and the server device of the second communication session are allowed to be different.

9. The client further comprises means for transmitting the received challenge data to the server; The server further comprises means for receiving the challenge data; 9. The information processing system according to claim 8, wherein the verification verifies the received response data using the received challenge data and the set server-side response key.

10. 2. The information processing system according to claim 1, wherein the client further comprises means for delivering predetermined information to an application based on a result of the verification.

11. The information processing system according to claim 1 , wherein the first parameter has a value that differs depending on the client.

12. The information processing system according to claim 4 , wherein the first parameter and the second parameter have different values ​​depending on the client.

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

14. 13. An information processing program for causing a computer to function as each means provided in a client in the information processing system according to claim 1.

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

16. 13. An information processing program for causing a computer to function as each of the means provided in the server in the information processing system according to claim 1.

17. The client computer performs authentication processing between the server and the client computer using the challenge and response method. A process to set the response key on the client side, receiving challenge data from the server; generating response data from the received challenge data using the set client-side response key; a process of transmitting the generated response data to the server; a process of reading from the memory of the client a first parameter used in a process of setting a server-side response key executed on the server side; a process of transmitting the read first parameters to the server; a program that executes a process of receiving an authentication result from the server based on a verification result of the response data, the process being performed by identifying seed data for an operation that sets a response key on the server side based on the first parameter.

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

19. 19. The program according to claim 17, wherein the first parameter is signed data to which a signature of data including at least the first parameter is attached.

20. The computer further comprises: reading the second parameter, which is unsigned data, from a memory of the client; 20. The program according to claim 19, further comprising causing the server to execute a process of transmitting the read second parameter, and the seed data specified by the server is identified based on the first parameter and the second parameter.

21. the operations include a first operation and a second operation; The computer further comprises: a process of reading out the operation result data of the first operation from the memory of the client; Execute a process of transmitting the calculation result data to the server; 21. The program according to claim 20, wherein the setting of the server-side response key is performed by executing the second operation using the specified seed data and the operation result data.

22. 22. The program according to claim 21, wherein the operation result data and the first parameter are signed data to which a signature of at least those data is attached.

23. a communication session for the authentication process between the server and the client includes a first communication session in which the challenge data is transmitted and received, and a second communication session that is different from the first communication session and in which the response data is transmitted and received, the response data is verified, and the verification result is transmitted and received; 18. The program according to claim 17, wherein the server device of the first communication session and the server device of the second communication session are allowed to be different.

24. 24. The program according to claim 23, further causing the computer to execute a process of transferring the received challenge data to the server, and the server verifying the received response data using the transferred challenge data.

25. 25. The program according to claim 24, causing the computer to execute a process of passing predetermined information to an application based on a result of the verification.

26. The program according to claim 17 , wherein the first parameter has a value that varies depending on the client.

27. 21. The program according to claim 20, wherein the first parameter and the second parameter have different values ​​depending on the client.

Images