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

Abstract

This server issues and transmits challenge data to a client. The client: stores a first parameter; sets a client-side response key; receives the challenge data; generates response data from the received challenge data by using the response key; and transmits the response data and the stored first parameter to a server. The server, in addition: receives the response data and the first parameter; identifies seed data of an operation for setting a server-side response key by using the first parameter; sets the server-side response key by executing the operation by using the seed data; verifies the received response data by using the challenge data and the server-side response key; and notifies the result. The client receives the notification.

Description

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

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

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

[0003] RFC Editor, ”RFC7616”, [online], [searched on August 29, Reiwa 6], Internet (URL: https: / / www.rfc-editor.org / info / rfc7616)

[0004] There has been room for providing a new method for the device authentication method using the above challenge & response method.

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

[0006] (Configuration 1) Configuration 1 is an information processing system comprising a client connected to a network and a server, which performs authentication processing of the client using a challenge and response method between the client and the server. The server comprises means for issuing challenge data and transmitting it to the client. The client comprises means for storing a first parameter, means for setting a client-side response key, means for receiving challenge data, means for generating response data from the received challenge data using the set client-side response key, and means for transmitting the generated response data and the stored first parameter to the server. The server (meaning a group of servers, and may be a different server device from the server device that issues and transmits challenge data to the client) further comprises means for receiving response data and the first parameter, means for identifying seed data for a calculation to set the server-side response key using the received first parameter, means for setting the server-side response key by executing a calculation 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 includes means for receiving the results of the above verification.

[0007] According to the above configuration, parameters stored on the client are sent to the server, which then uses these parameters to identify the seed data and set a response key on the server side. This allows for a response key that is specific to each client. This configuration can be applied even if the seed data is confidential.

[0008] (Configuration 2) In Configuration 2, the client-side response key may be set without using the first parameter, as in Configuration 1 above.

[0009] (Configuration 3) Configuration 3 is the same as Configuration 1 or 2 above, in which the first parameter may be signed data that includes at least the first parameter, and the identification of seed data may be performed by verifying the signature and using the first parameter.

[0010] (Configuration 4) Configuration 4 is the same as Configuration 3 above, but the client may further include means for storing a second parameter which is unsigned data, and means for transmitting the second parameter stored 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, seed data can be identified from multiple different aspects using both signed and unsigned parameters.

[0012] (Configuration 5) Configuration 5 is the same as Configuration 4 above, but the server may further include means for storing data that defines the correspondence between the combination of the first parameter and the second parameter and the seed data. The identification of the seed data may be performed based on the defined data.

[0013] (Configuration 6) Configuration 6 is the same as Configuration 4 above, and the calculation may include a first calculation and a second calculation. The client may further include means for storing the calculation result data of the first calculation and means for transmitting the calculation result data to the server. The server may further include means for receiving the transmitted calculation result data. The server-side response key may be set by executing the second calculation using the specified seed data and the calculation result data.

[0014] With the above configuration, at least some of the calculations for setting the response key on the server side can be omitted. For example, even if the values ​​and calculation formulas used in the calculation differ depending on the client, the increase in information processing on the server side can be suppressed. Furthermore, whether the values ​​and calculation formulas used in the calculation differ depending on the client or not, the server does not need to hold the various data (such as key data and seed data) used in the first calculation used in the first calculation, thereby reducing the risk of such data being leaked from the server.

[0015] (Configuration 7) Configuration 7 is the same as Configuration 6 above, in which the calculation result data and the first parameter are at least signed data with a signature attached, and the server-side response key setting may be performed by verifying the signature and executing a second operation using the identified seed data and the calculation result data.

[0016] (Configuration 8) Configuration 8 is a configuration in which, in 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 which is a different communication session 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. The server device for the first communication session and the server device for the second communication session may be different.

[0017] (Configuration 9) Configuration 9 is the same as Configuration 8 above, but the client may further provide means for sending the received challenge data to the server, and the server may further provide means for receiving the challenge data. In the above verification, the received response data may be verified using the received challenge data and the server-side response key that has been set.

[0018] (Configuration 10) Configuration 10 is the same as Configuration 1 above, in which the client may further provide means for passing predetermined information to the application based on the results of verification.

[0019] (Configuration 11) Configuration 11 is the same as Configuration 1 above, in which the verification results include data for using a predetermined online service, and the client may further include means for transferring the data for using the online service to the application.

[0020] (Configuration 12) Configuration 12 may further include means for the client to use a predetermined online service based on the results of verification, in the configuration described above.

[0021] (Configuration 13) Configuration 13 is the same as Configuration 1 above, in which the first parameter may have different values ​​depending on the client.

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

[0023] (Configuration 15) Configuration 15 may be a client in the information processing system described in any of Configurations 1 to 14 above.

[0024] (Configuration 16) Configuration 16 may be an information processing program that causes a computer to function as one of the means provided by the server in the information processing system described in any of Configurations 1 to 14 above.

[0025] (Configuration 17) Configuration 17 may be a server in the information processing system described in any of Configurations 1 to 14 above.

[0026] (Configuration 18) Configuration 18 may be an information processing program that causes a computer to function as one of the means provided by the server in the information processing system described in any of Configurations 1 to 14 above.

[0027] (Configuration 19) Configuration 19 is a program that causes a client computer, which performs authentication processing with a server using a challenge-response method, to execute the following processes: setting a client-side response key; receiving challenge data 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 server-side response key setting process executed on the server; sending the read first parameter to the server; and receiving an authentication result from the server based on the verification result of the response data, which is performed by identifying seed data for the calculation that sets the server-side response key based on the first parameter.

[0028] (Configuration 20) In Configuration 20, the client-side response key may be set without using the first parameter, as in Configuration 19 above.

[0029] (Configuration 21) Configuration 21 is the configuration in which, in configuration 19 or 20, the first parameter may be signed data that has been signed to include at least the first parameter.

[0030] (Configuration 22) Configuration 22 is configured in which the computer further performs the process of reading a second parameter, which is unsigned data, and the process of sending the read second parameter to the server, and the identification of seed data performed by the server may be performed using the first parameter and the second parameter.

[0031] (Configuration 23) Configuration 23 is the same as Configuration 22, but the calculation may include a first calculation and a second calculation, and the computer may be made to perform a process of reading the 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 side may be performed by performing the second calculation using the specified seed data and the calculation result data.

[0032] (Configuration 24) Configuration 24 is a configuration in which, in configuration 23, the calculation result data and the first parameter may be signed data to which at least the data has been signed.

[0033] (Configuration 25) Configuration 25 is a configuration in which, in the above configuration 19, 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 which is a different communication session from the first communication session in which response data is sent and received, the response data is verified, and the server device for the first communication session and the server device for the second communication session may be different.

[0034] (Configuration 26) Configuration 26 is the configuration in which the computer further executes a process to transfer the received challenge data to the server, and the server uses the transferred challenge data to verify the received response data.

[0035] (Configuration 27) Configuration 27 may cause the computer in Configuration 26 to perform a process of passing predetermined information to the application based on the verification results.

[0036] (Configuration 28) Configuration 28 is the configuration in which the first parameter may have different values ​​depending on the client.

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

[0038] A schematic diagram showing the overall system of this embodiment. A diagram illustrating the overview of the response key setting process. A diagram illustrating the overview of the certificate creation process. An example of the configuration of certificate data D101. A diagram illustrating the overview of the challenge dataset generation and transmission process. An example of the configuration of challenge dataset D102. A diagram illustrating the overview of the response dataset generation process. An example of data that client 3 sends to server 1. A diagram illustrating the overview of the response key setting process on server 1. An example of the data configuration of counter value identification table SV404. An example of the data configuration of second KDF seed data identification table SV405. A diagram illustrating the overview of the verification process. A block diagram showing the hardware configuration of client 3. An example of data stored in the storage unit 32 of client 3. Explanation of the functional configuration of system program CL201. Diagram for use as a reference to show an example of data stored in the storage unit 12 of server 1. Diagram for use as a reference to show an example of data stored in the storage unit 42 of PC 4. Diagram showing details of the process in a challenge issuance session. Diagram showing details of the challenge generation process. Diagram showing details of the process in a verification session. Diagram showing details of the response generation process. Diagram showing the first example of the first derived key setting process. Diagram showing the second example of the first derived key setting process. Diagram showing the first example of the second derived key setting process. Diagram showing the second example of the second derived key setting process. Diagram showing details of the response dataset generation process. Diagram showing details of the verification process. Diagram showing details of the verification process. Diagram showing details of the online game process.

[0039] The embodiments will be described below.

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

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

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

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

[0044] FIG. 2 is a diagram for explaining the outline of the response key setting process in the present embodiment, and schematically shows the data flow in the process. In FIG. 2, the elements shown by ellipses indicate data parameter elements, and the elements shown by rectangles indicate processing elements. For the sake of convenience of explanation, in FIG. 2, the data parameter elements are assigned reference signs in the form of "Dnn (nn is an integer)". In the following, similar figures will appear, and these will also be assigned reference signs in the same way.

[0045] In the example shown in FIG. 2, a key derivation function (hereinafter referred to as KDF for short) is used to generate key data from predetermined data, and the generated key data is set as the response key. Here, the KDF is a function for generating another key based on the key data. When the key data and predetermined data called seed data are input to the KDF, another key data based on these is generated. Hereinafter, the key data output by the KDF is called "derived key". In the present embodiment, the derived key data generated using multiple stages of KDF (in the present embodiment, two stages of KDF) is used as the response key. In the following description, the first stage of KDF is called "first KDF", the second stage of KDF is called "second KDF", the key data output by the first KDF is called "first derived key data" or simply "first derived key", and the key data output by the second KDF is called "second derived key data" or simply "second derived key". The calculation content of each KDF may be anything, for example, a KDF that uses HMAC or CMAC as a PRF, a KDF that uses a hash function or a block cipher, and the like. Also, the calculation content of each stage of KDF may be the same or different.

[0046] Using FIG. 2, the process flow of response key setting will be described. The response key setting process is executed on both the server and the client. In this embodiment, as will be described later, there are differences between the response key setting process executed on the server and the response key setting process executed on the client. In FIG. 2, the response key setting process executed on the client 3 will be described. Note that the response key set on the client 3 may be referred to as the "response key (client)", and the response key set on the server 1 may be referred to as the "response key (server)". Also, the second derived key calculated on the client 3 may be referred to as the "second derived key (client)", and the second derived key calculated on the server 1 may be referred to as the "second derived key (server)".

[0047] First, in the storage unit of the client 3, a master key D01, a counter value D02, a first KDF seed data D03, and a second KDF seed data D04 are stored. The master key D01 is key data input to the first KDF. The master key D01 may be configured as fixed-value data or as changeable data. Also, the master key D01 may be different data for each client. When the client is realized by emulator technology, it may be the same data as the master key of the emulated target.

[0048] The counter value D02, the first KDF seed data D03, and the second KDF seed data D04 are each data used as the seed data of the KDF. The counter value D02 can take different values depending on the client 3. For example, it is a value that can be changed according to an update of the system of the client 3 or the like, and specifically, it is incremented by 1. In this embodiment, as an example, the case where the counter value can take any of four values from 0 to 3 will be described. Also, 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 can be any kind of data, but for example, the first KDF seed data D03 may be a fixed value, or more specifically, identification data that indicates a certain characteristic of the client 3. For example, it may be identification data that indicates either a development machine or a production machine. If the client is implemented using emulator technology, the identification data may be data that indicates the characteristics of the object being emulated. The second KDF seed data D04 may be data that the client 3 can set or change itself, or in response to instructions from an external source such as a server. More specifically, it may be identification data that indicates another characteristic of 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 by version upgrades). Furthermore, if the client is implemented using emulator technology, the identification data may be data that indicates the characteristics of the object being emulated. Also, each KDF seed data D03 and D04 may be changed, for example, by system software updates. In addition, both the first KDF seed data D03 and the second KDF seed data D04 may have different values ​​depending on the client.

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

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

[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 the response dataset D103, which will be described later.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0093] [Hardware Configuration of Client 3] Next, the hardware configuration of Client 3 will be described. Figure 13 is a block diagram showing the hardware configuration of Client 3. In this embodiment, Client 3 is a game device, but it may also be a general-purpose PC, smartphone, tablet device, etc. Client 3 is an example of a computer and includes a processor, memory, peripheral processors such as a communication processor and a display processor. Client 3 comprises at least a processing unit 31, a storage unit 32, a network communication unit 35, an operation device 36 (game controller), and an image output unit 37. The processing unit 31 is, for example, a processor and executes various programs for controlling Client 3. Client 3 may be composed of multiple devices. The processing unit 31 may be composed of multiple processors, in which case it may be multiple processors of multiple devices. The processor may be a general-purpose processor or a dedicated processor, and is not limited to any particular form such as a SoC, CPU, ASIC, or microcontroller. The storage unit 32 stores various programs executed by the processing unit 31 and various data used. The program may be a group of multiple programs, each program may be executed by a different processor, and each program may be stored in a different memory location. Furthermore, the program may be application software, system software, firmware, an emulator, or any other form of software. In addition to code, the program may include data and table parameters. Specifically, the storage unit 32 includes a non-volatile storage unit 33 and a volatile storage unit 34. The non-volatile storage unit 33 is, for example, flash memory or an SSD (Solid State Drive). The volatile storage unit 34 is, for example, DRAM and functions as main memory. Various programs and data stored in the non-volatile storage unit 33 are loaded onto the volatile storage unit 34 as needed, and the processing unit 31 can execute various processes as described later. The network communication unit 35 communicates with other servers and clients 3 via a network, such as the Internet (this may be wireless or wired).Note that it may be configured to communicate directly with a communication partner without going through a network. The operation device is various operation devices (such as a keyboard, a 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 non-volatile storage unit 33 or the volatile storage unit 34 may be configured as a secure area. A part of various data described later may be configured to be stored in a secure area such as a memory in the SoC (System on a Chip).

[0095] Note that the hardware configuration of the server 1 and the PC 4 may be a general hardware configuration of a server or a PC, and the description thereof is omitted. It has the same configuration as that in FIG. 13. Note that the server 1 may be composed of a plurality of server devices. That is, the server 1 is composed 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. Also, the PC 4 is composed 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 data used in the processing according to this embodiment will be described.

[0097] [Data used in the client 3] FIG. 14 is an example of data stored in the storage unit 32 of the client 3. The data shown in FIG. 14 indicates the data stored in the non-volatile storage unit 33. When the authentication process is executed, these data are read into the volatile storage unit 34 as needed, and thus the authentication process can be executed. Note that these data may be stored separately in different memories. For example, some data may be stored in the above-described secure area.

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

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

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

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

[0102] In another embodiment, for example, 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] In another embodiment, for example, the data for the second derived key D06 may be stored in the storage unit 32. In this case, the master key D01, the first KDF seed data D03, and the second KDF seed data D04 do not need to be stored. In this case, the response key setting program may not have a first derived key setting function.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 to generate 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 at counter value 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 has become greater than a predetermined value (step S206). In this embodiment, the counter value n is shown to take one of four values ​​from 0 to 3, so this predetermined value is 3. If the result of this determination is that the value has not become greater than the predetermined value (NO in step S206), the process returns to step S203 and is repeated.

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

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

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

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

[0128] Next, the processing unit 11 of server 1 performs the process of receiving 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. Using the decryption result, it determines whether the four encryption first derived keys D08, client ID_D10, and first specific parameter D11 contained in the certificate data D101 have not been tampered with. If they match, the verification result is determined to be positive. If the decryption result does not match, it is determined to be negative, and the challenge dataset D102 is not sent. The processing is then terminated by notifying the client 3 of this fact (or by terminating communication without notification).

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

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

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

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

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

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

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

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

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

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

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

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

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

[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 Figure 22, the processing unit 31 then executes the response data generation process (step S34). Figure 27 is a flowchart detailing the response data generation process. First, the processing unit 31 reads the first MAC value (challenge data) D16 from the challenge dataset D102 received in step S8 of Figure 19 (step S61).

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

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

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

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

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

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

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

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

[0153] Next, the processing unit 11 retrieves the first encryption 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 first encryption derived key D08 into the first derived key D05 using the first server key D07 corresponding to the identified counter value D02 (step S75).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0172] [Modification] In other embodiments, the configuration may be such that a counter value is not used as the seed data for the first KDF. That is, the configuration may be such that the calculation of the first KDF is performed using the master key D01 and the first KDF seed data D03 to generate the first derived key D05. In this case, the certificate will contain one encrypted first derived key D05. It goes without saying that the counter value is not limited to 0 to 3. Also, a predetermined variable value may be used instead of the counter, and it does not have to be changed in an incrementing manner.

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

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

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

[0176] Furthermore, regarding the generation of challenge data, the above example shows an example where a MAC calculation is performed using the second server key to calculate the first MAC value. In other embodiments, a configuration that performs a signature instead of MAC calculation may be used. For example, an RSA signature may be used.

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

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

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

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

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

[0182] 1 Server 3 Client 4 PC 11 Processing Unit 12 Storage Unit 13 Non-volatile Storage Unit 14 Volatile Storage Unit 15 Network Communication Unit 16 Operation Device 17 Image Output Unit 31 Processing Unit 32 Storage Unit 33 Non-volatile Storage Unit 34 Volatile Storage Unit 35 Network Communication Unit 36 ​​Operation Device 37 Image Output Unit 41 Processing Unit 42 Storage Unit 43 Non-volatile Storage Unit 44 Volatile Storage Unit 45 Network Communication Unit 46 Operation Device 47 Image Output Unit

Claims

1. An information processing system comprising a client connected to a network and a server, wherein authentication processing of the client is performed between the client and the server using a challenge and response method, wherein the server comprises means for issuing challenge data and transmitting it to the client, the client comprises means for storing a first parameter, 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, and means for transmitting the generated response data and the stored first parameter to the server, the server further comprises means for receiving the response data and the first parameter, means for identifying seed data for a calculation to set the server-side response key using the received first parameter, means for setting the server-side response key by executing the calculation 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 the verification result.

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

3. The information processing system according to claim 1 or 2, wherein the first parameter is signed data that includes at least the first parameter, and the identification of the seed data is performed by verifying the signature and using the first parameter.

4. The information processing system according to claim 3, wherein the client further comprises means for storing a second parameter which is unsigned data, and means for transmitting the stored second parameter to the server, and the server further comprises receiving means for receiving the second parameter, and the identification of the seed data is performed using the first parameter and the second parameter.

5. The information processing system according to claim 4, wherein the server further includes means for storing data that defines the correspondence between the combination of the first parameter and the second parameter and the seed data, and the identification of the seed data is performed based on the defined data.

6. The information processing system according to claim 4, wherein the calculation includes a first calculation and a second calculation, the client further comprises means for storing calculation result data of the first calculation and means for transmitting the calculation result data to the server, the server further comprises means for receiving the transmitted calculation result data, and the setting of the server-side response key is performed by executing the second calculation using the identified seed data and the calculation result data.

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

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

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

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

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

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

13. A client in an information processing system according to any one of claims 1 to 12.

14. An information processing program for causing a computer to function as each of the means provided by a client in the information processing system described in any one of claims 1 to 12.

15. A server in an information processing system according to any one of claims 1 to 12.

16. An information processing program for causing a computer to function as each of the means provided by a server in the information processing system described in any one of claims 1 to 12.

17. A program that causes a client computer, which performs authentication processing with a server using a challenge-response method, to execute the following processes: setting a client-side response key; receiving challenge data 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 from the client's memory that is used in the server-side response key setting process executed on the server; sending the read first parameter to the server; and receiving an authentication result from the server based on the verification result of the response data, which is performed by identifying seed data for the calculation that sets the server-side response key based on the first parameter.

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

19. The program according to claim 17 or 18, wherein the first parameter is signed data that includes at least the first parameter.

20. The program according to claim 19, wherein the computer further performs the process of reading the second parameter, which is the unsigned data, from the client's memory, and the process of sending the read second parameter to the server, and the identification of the seed data performed by the server is based on the first parameter and the second parameter.

21. The program according to claim 20, wherein the calculation includes a first calculation and a second calculation, and the computer is further instructed to perform the processes of reading the calculation result data of the first calculation from the client's memory and transmitting the calculation result data to the server, and the server-side response key is set by performing the second calculation using the identified seed data and the calculation result data.

22. The program according to claim 21, wherein the calculation result data and the first parameter are at least signed data to which the data has been signed.

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

24. The program according to claim 23, wherein the computer further executes a process to transfer the received challenge data to the server, and the server uses the transferred challenge data to verify the received response data.

25. The information processing system according to claim 24, wherein the computer is instructed to perform a process of transferring predetermined information to an application based on the results of the verification.

26. The program according to claim 17, wherein the first parameter is a different value depending on the client.

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

Images