Request verification system and request verification method

Abstract

According to the present invention, an authorization data generation device applies, to arbitrary data, the signature of the arbitrary data and generates authorization data, and transmits the authorization data to a client device. When receiving, from the client device, a service use request including the authorization data, a verification device verifies the authorization data, provides a service corresponding to the request to the client device when the verification for the received authorization data is determined to be successful, and transmits an error notification to the client device when the verification for the received authorization data is determined to be unsuccessful.

Description

[Technical Field]

[0001] The present disclosure relates to a request validation system and a request validation method. [Background technology]

[0002] Patent Document 1 discloses an access right management device having an electronic ticket generation device and an application device. The electronic ticket generation device acquires specific information (e.g., information based on the confidential information of the client device) for identifying the client device owned by the user, and generates an electronic ticket using this specific information. The application device communicates with the client device, inspects the electronic ticket, and verifies the user's access rights. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2004-32220 Summary of the Invention [Problem to be solved by the invention]

[0004] In the configuration of Patent Document 1, specific information based on the confidential information of the client device is shared between both the client device and the electronic ticket generation device, and is also passed from the electronic ticket generation device to the application device. This creates a risk of the specific information being leaked, raising concerns about a decrease in security on the client device.

[0005] The present disclosure has been devised in consideration of the above-described conventional situation, and aims to provide a request verification system and a request verification method that safely verify user requests without leaking confidential information of the client device and prevent a decrease in security of the client device. [Means for solving the problem]

[0006] The present disclosure provides a system including an authorization data generation device that generates and outputs authorization data that authorizes the provision of a service and that holds a certificate including a public key, a verification device that shares the certificate with the authorization data generation device, and a client device that uses the provided service, wherein the verification device: generating an ID corresponding to the client device and sending it to the authorization data generation device; When a request to verify the authorization data is received from the client device, the authorization data is verified using the certificate. The authorization data generation device holds a private key of the authorization data generation device, generates the authorization data using a signature obtained by encrypting an ID corresponding to the client device with the private key, and transmits the generated authorization data to the client device. It provides a request validation system.

[0007] The present disclosure also provides a method for generating and outputting authorization data for authorizing provision of a service, and retaining a certificate including a public key; generating an ID corresponding to the client device requesting the provision of the service; sharing the certificate; and verifying the authorization data using the certificate when verification of the authorization data is requested. In generating the authorization data, the authorization data is generated using a signature obtained by encrypting an ID corresponding to the client device with a private key of an authorization data generating device that generates the authorization data. It provides a method for validating requests. [Effects of the Invention]

[0008] According to the present disclosure, a user request can be safely verified without leaking confidential information of the client device, and a decrease in security of the client device can be suppressed. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of a system configuration of a request verification system according to a first embodiment. [Figure 2] FIG. 1 is a block diagram showing an example of the hardware configuration of each device constituting the request verification system according to the first embodiment. [Figure 3A] FIG. 1 is a sequence diagram illustrating an example of an operation procedure of the request verification system according to the first embodiment. [Figure 3B] FIG. 10 is a sequence diagram illustrating another example of the operation procedure of the request verification system according to the first embodiment. [Figure 4] FIG. 10 is a block diagram showing an example of the hardware configuration of each device constituting the request verification system according to the second embodiment. [Figure 5] A diagram showing an example of the procedure for determining the certificate to be issued for an ID [Figure 6] FIG. 10 is a sequence diagram illustrating an example of an operation procedure of a request verification system according to a second embodiment. [Figure 7] FIG. 10 is a diagram illustrating an example of a system configuration of a request verification system according to a third embodiment. [Figure 8] A sequence diagram showing an example of an operation procedure of a request verification system according to a third embodiment. [Figure 9] A sequence diagram showing an example of an operation procedure of a request verification system according to a third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, with reference to the accompanying drawings as appropriate, detailed descriptions of embodiments specifically disclosing a request validation system and a request validation method according to the present disclosure will be provided. However, unnecessary detailed descriptions may be omitted. For example, detailed descriptions of well-known matters or redundant descriptions of substantially identical configurations may be omitted. This is to avoid unnecessary redundancy in the following description and to facilitate understanding by those skilled in the art. Note that the accompanying drawings and the following description are provided to enable those skilled in the art to fully understand the present disclosure, and are not intended to limit the subject matter recited in the claims.

[0011] (Embodiment 1) In the request verification system according to the first embodiment, when a verification device included in the request verification system receives a user-desired request (e.g., an application for issuing a digital certificate for the client device and transmitting the digital certificate to the client device) from the client device, the verification device verifies the authorization data (see below) included in the request. If the verification device determines that the verification is successful, the verification device provides the client device with a response to the request (e.g., an application for issuing a digital certificate for the client device and transmitting the digital certificate to the client device). If the verification device determines that the verification is unsuccessful, the verification device sends an error notification to the client device indicating that the verification has failed.

[0012] FIG. 1 is a diagram illustrating an example of a system configuration of a request verification system 1 according to a first embodiment. The request verification system 1 includes at least an authorization data generation device 10 and a verification device 20. The request verification system 1 may further include a client device 30. Although only one client device 30 is illustrated in FIG. 1, two or more client devices 30 may be connected to a network NW1. The authorization data generation device 10, the verification device 20, and the client device 30 are connected to each other via the network NW1 so as to be able to communicate with each other. The network NW1 may be a wired network (e.g., a wired LAN (Local Area Network)) or a wireless network (e.g., a wireless LAN).

[0013] The authorization data generation device 10 generates data (hereinafter referred to as "authorization data") indicating authorization to provide a response (see above) to a request (see above) desired by a user of the client device 30, and sends this authorization data to the client device 30. The authorization data generation device 10 holds its own private key PRK1, and generates authorization data AUTH1 by concatenating a signature (sometimes referred to as an "electronic signature") generated by encrypting arbitrary data DTA1 (e.g., a random number) or a hash value of DTA1 with the authorization data generation device 10's private key PRK1 with the arbitrary data DTA1. The authorization data generation device 10 and the verification device 20 share in advance hash functions to be used respectively to calculate hash values. The authorization data generation device 10 also holds a certificate CERT1 (sometimes referred to as an "electronic certificate") including the public key of the authorization data generation device 10, and shares this certificate CERT1 with the verification device 20. This certificate CERT1 is generated (issued) for the authorization data generation device 10 by a CA described later, and includes at least a signature (not shown) generated by the CA by encrypting arbitrary data using the CA's private key (not shown), arbitrary data used to generate the signature, the CA's public key, and the public key of the authorization data generation device 10, and is held in the authorization data generation device 10. Note that the arbitrary data to be encrypted by the CA using the CA's private key is the same as the data used when the CA generates one or more certificates (e.g., certificate CERT1, CA certificate CA1).

[0014] In addition, the request verification system 1 may be configured to include multiple authorization data generation devices 10. In this case, the authorization data generation device 10 having the certificate CERT1 with the usage rights that the client device 30 is to be granted can be switched as appropriate, and the desired certificate CERT1 can be retained in the client device 30 from the corresponding authorization data generation device 10.

[0015] When the verification device 20 receives a request from the client device 30, the verification device 20 verifies the authorization data AUTH1 (see above) included in the request by using a public key (e.g., the public key of the authorization data generation device 10) included in a certificate CERT1 shared in advance with the authorization data generation device 10. Note that, as will be described in detail later, the verification device 20 may verify the authorization data AUTH1 (see above) included in the request by using a CA certificate CA1 that has been downloaded and acquired in advance from a CA (described later). In this way, even when a plurality of authorization data generation devices 10 are provided, the verification device 20 can individually and easily verify the authorization data included in the request from the client device 30 by simply downloading and acquiring the CA certificate CA1 from a CA (certificate authority) without having to acquire and share a certificate CERT1 from each of the plurality of authorization data generation devices 10 in advance, and further, avoid a memory capacity shortage that may occur due to storing a plurality of certificates CERT1.

[0016] If the verification device 20 determines that the verification is successful, it provides the client device 30 with a response to the request (for example, issuing a digital certificate for the client device 30 and sending it to the client device 30). If the verification device 20 determines that the verification is unsuccessful, it sends an error notification to the client device 30 indicating that the verification has failed. In other words, the error notification means that a digital certificate for the client device 30 cannot be issued (i.e., the client device 30 cannot obtain the desired usage rights).

[0017] The verification device 20 may acquire and store a CA certificate CA1 generated (issued) by a CA (Certification Authority), also known as a public certification authority, by downloading it from the CA. The CA certificate CA1 includes at least a signature generated by the CA by encrypting arbitrary data using the CA's private key (not shown), arbitrary data used to generate the signature, and the CA's public key. This CA certificate CA1 is the same as the above-mentioned certificate CERT1. The CA certificate CA1 and the certificate CERT1 may be different, but both are certificates generated (issued) by the same CA.

[0018] The client device 30 is used by a user of the request verification system 1 and is, for example, a mobile terminal such as a smartphone or an IoT (Internet of Things) device. The client device 30 may also be a PC (Personal Computer). The client device 30 receives and stores the authorization data AUTH1 generated by the authorization data generation device 10. The client device 30 sends a request (see above) including the authorization data AUTH1 to the verification device 20. If the client device 30 determines that the verification of the request by the verification device 20 is successful, the client device 30 receives a response to the request (for example, issuance of a digital certificate for the client device and transmission of the digital certificate to the client device) from the verification device 20. If the client device 30 determines that the verification of the request by the verification device 20 is unsuccessful, the client device 30 receives an error notification from the verification device 20 indicating that the verification has failed.

[0019] 2 is a block diagram showing an example of the hardware configuration of each device constituting the request verification system 1 according to Embodiment 1. The request verification system 1 shown in FIG. 2 includes an authorization data generation device 10, a verification device 20, and a client device 30.

[0020] The authorization data generating device 10 includes an operation device 11, a memory 12, a communication device 13, and a processor PRC1.

[0021] The operation device 11 is a device that accepts operations by a user of the authorization data generation apparatus 10, and is configured by, for example, at least one of a mouse, a keyboard, a touchpad, and a touch panel. The operation device 11 sends a signal based on the user's operation to the processor PRC1.

[0022] The memory 12 includes, for example, a RAM (Random Access Memory) and a ROM (Read Only Memory), and temporarily stores programs required to execute the operation of the authorization data generation device 10, and data or information generated by the processor PRC1 during operation. The RAM is, for example, a work memory used when the processor PRC1 is operating. The ROM stores, for example, programs and data for controlling the processor PRC1 in advance. The memory 12 may also be configured to include storage such as an HDD (Hard Disk Drive), flash memory, or SSD (Solid State Drive) that can store data acquired or generated by the processor PRC1.

[0023] The communication device 13 is configured using a communication circuit for transmitting and receiving data or information to and from the network NW1, and transmits and receives data or information to and from the verification device 20 or one or more client devices 30. The communication device 13 may communicate with the verification device 20 or one or more client devices 30 using a mutually authenticated, highly secure communication path (for example, BLE: Bluetooth (registered trademark) Low Energy).

[0024] The processor PRC1 is configured using at least one of, for example, a CPU (Central Processing Unit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), and a GPU (Graphical Processing Unit). The processor PRC1 controls the operation of each unit of the authorization data generation device 10. The processor PRC1 may also control the operation of each unit of the authorization data generation device 10 based on a signal from the operation device 11. The processor PRC1 functions as a control unit of the authorization data generation device 10 and performs control processing for overall supervision of the operation of each unit of the authorization data generation device 10, data input / output processing between each unit of the authorization data generation device 10, data arithmetic (calculation) processing, and data storage processing. The processor PRC1 operates according to the execution of a program stored in a ROM in the memory 12. The processor PRC1 has, as functional components based on the execution of the above-mentioned programs, a private key management unit 14, an authorization data management unit 15, a public key management unit 16, an arbitrary data management unit 17, and a signature generation unit 18.

[0025] The private key management unit 14 generates and holds a private key (for example, a pair of RSA private keys (d, N)) for the authorization data generation device 10. Note that the type of private key is not limited to RSA encryption.

[0026] The authorization data management unit 15 generates and stores authorization data AUTH1 by concatenating (linking) the signature (so-called electronic signature) generated by the signature generation unit 18 to arbitrary data DTA1. For example, the authorization data AUTH1 has the following data structure: [authorization data T] = [signature S] [arbitrary data D]. Here, [A] [B] indicates that data A and data B are concatenated. The authorization data AUTH1 is generated so as to have a different data entity for each client device 30. Note that, as will be described in detail later with reference to FIG. 3B, it may also be the case that [authorization data T] = [signature S] [arbitrary data D] [certificate CERT1].

[0027] The public key management unit 16 generates and stores a public key (for example, a pair of RSA public keys (e, N)) of the authorization data generation device 10. The type of public key is not limited to RSA encryption. The public key management unit 16 also generates and stores a certificate CERT1 (i.e., a digital certificate of the authorization data generation device 10) including the generated public key. The certificate CERT1 may be issued by a certification authority (see above, CA: Certification Authority), not shown.

[0028] The arbitrary data management unit 17 generates and holds arbitrary data DTA1 (for example, a random number or a counter value) that constitutes the authorization data AUTH1. Here, the arbitrary data DTA1 is arbitrary data that has so-called randomness, and is data that does not have confidentiality like a random number, unlike, for example, confidential information of the client device 30 (for example, an IP (Internet Protocol) address or a MAC (Media Access Control) address).

[0029] The signature generation unit 18 generates and stores a signature by encrypting the arbitrary data DTA1 generated by the arbitrary data management unit 17 using a private key (for example, a pair of (e, N)) generated by the private key management unit 14. The signature generation algorithm is not limited to RSA, and may be, for example, ECDSA. Specifically, the signature generation unit 18 calculates Hash(arbitrary data D) using a predetermined hash function between the authorization data generation device 10 and the verification device 20. Hash(A) is an operator that obtains a hash value (digest value) of data A, and is, for example, SHA2 or SHA3. The signature generation unit 18 calculates (Hash(arbitrary data D)) d A signature S is generated by performing the operation mod N. For example, if the signature is generated using a private key of the RSA encryption, this signature can be decrypted using only the public key of the authorization data generation device 10.

[0030] The verification device 20 includes an operation device 21, a memory 22, a communication device 23, and a processor PRC2.

[0031] The operation device 21 is a device that accepts operations by the user of the verification device 20, and is configured by, for example, at least one of a mouse, a keyboard, a touchpad, and a touch panel. The operation device 21 sends a signal based on the user's operation to the processor PRC2.

[0032] The memory 22 includes, for example, RAM and ROM, and temporarily stores programs required for executing the operation of the verification device 20, and data or information generated by the processor PRC2 during operation. The RAM is, for example, a work memory used when the processor PRC2 is operating. The ROM stores, for example, programs and data for controlling the processor PRC2 in advance. The memory 22 may also be configured to include storage such as an HDD, flash memory, or SSD that can store data acquired or generated by the processor PRC2.

[0033] The communication device 23 is configured using a communication circuit for transmitting and receiving data or information to and from the network NW1, and transmits and receives data or information to and from the authorization data generation device 10 or one or more client devices 30. The communication device 23 may communicate with the authorization data generation device 10 or one or more client devices 30 using a mutually authenticated, highly secure communication path (e.g., BLE).

[0034] The processor PRC2 is configured using at least one of a CPU, a DSP, an FPGA, and a GPU, for example. The processor PRC2 controls the operation of each unit of the verification device 20. The processor PRC2 may also control the operation of each unit of the verification device 20 based on a signal from the operation device 21. The processor PRC2 functions as a control unit of the verification device 20, and performs control processing for overall supervision of the operation of each unit of the verification device 20, data input / output processing between each unit of the verification device 20, data arithmetic (calculation) processing, and data storage processing. The processor PRC2 operates in accordance with the execution of a program stored in a ROM in the memory 22. The processor PRC2 has a signature verification unit 24 and a public key management unit 25 as functional components based on the execution of the above-mentioned program.

[0035] The signature verification unit 24 verifies the authorization data T included in the request from the client device 30 using the public key (i.e., the public key of the authorization data generation device 10) included in the certificate CERT1 (i.e., the digital certificate of the authorization data generation device 10) held by the public key management unit 25. Specifically, when the signature verification unit 24 acquires the authorization data T (e.g., [signature S] [arbitrary data D]) from the client device 30, it decrypts the signature S using a pair of public keys (e, N). For example, the signature verification unit 24 decrypts (signature S) e The decrypted data F is obtained by calculating modN, and a hash value (Hash(arbitrary data D)) of the arbitrary data D constituting the authorization data T is calculated between the authorization data generation device 10 and the verification device 20 using a predetermined hash function. The signature verification unit 24 verifies the authorization data T included in the request from the client device 30 based on whether the hash value of the arbitrary data D and the decrypted data F are the same. The signature verification unit 24 determines that the verification is successful when it determines that the hash value of the arbitrary data D and the decrypted data F are the same, and determines that the verification is unsuccessful when it determines that the hash value of the arbitrary data D and the decrypted data F are not the same.

[0036] If the signature verification unit 24 determines that the verification is successful, it instructs the authorization of a response to the above-mentioned request (for example, issuing a digital certificate for the client device 30 and transmitting it to the client device 30). Based on this instruction, the processor PRC2 issues (generates) a digital certificate for the client device 30, for example, and provides (transmits) it to the client device 30 via the communication device 23. Furthermore, if the signature verification unit 24 determines that the verification is unsuccessful, it transmits an error notification indicating that the verification has failed to the client device 30 via the communication device 23.

[0037] The public key management unit 25 acquires and holds the certificate sent from the authorization data generation device 10 to be shared (i.e., the digital certificate of the authorization data generation device 10) or the CA certificate CA1 (see FIG. 3B) downloaded in advance from the CA (see above). As described above, the certificate sent from the authorization data generation device 10 to be shared includes at least a signature generated by the CA, the CA's public key, and the authorization data generation device 10's public key (for example, a pair (e, N)). As described above, the CA certificate CA1 downloaded in advance from the CA includes at least a signature generated by the CA and the CA's public key.

[0038] The client device 30 includes an operation device 31, a memory 32, a communication device 33, and a processor PRC3.

[0039] The operation device 31 is a device that accepts operations by the user of the client device 30, and is configured by, for example, at least one of a mouse, a keyboard, a touchpad, and a touch panel. The operation device 31 sends a signal based on the user's operation to the processor PRC3. Note that the operation device 31 may be omitted from the configuration of the client device 30.

[0040] The memory 32 includes, for example, RAM and ROM, and temporarily stores programs required to execute the operations of the client device 30, and data or information generated by the processor PRC3 during operation. The RAM is, for example, a work memory used when the processor PRC3 is operating. The ROM stores, for example, programs and data for controlling the processor PRC3 in advance. The memory 32 may also be configured to include storage such as an HDD, flash memory, or SSD that can store data acquired or generated by the processor PRC3.

[0041] The communication device 33 is configured using a communication circuit that transmits and receives data or information to and from the network NW1, and transmits and receives data or information to and from the authorization data generation device 10 or the verification device 20. Note that the communication device 33 may communicate with the authorization data generation device 10 or the verification device 20 using a mutually authenticated, highly secure communication path (e.g., BLE).

[0042] The processor PRC3 is configured using at least one of, for example, a CPU, a DSP, an FPGA, and a GPU. The processor PRC3 controls the operation of each unit of the client device 30. The processor PRC3 may also control the operation of each unit of the client device 30 based on a signal from the operation device 31. The processor PRC3 functions as a control unit of the client device 30, and performs control processing for overall supervision of the operation of each unit of the client device 30, data input / output processing between the client device 30 and each unit, data arithmetic (calculation) processing, and data storage processing. The processor PRC3 operates in accordance with the execution of a program stored in a ROM in the memory 32. The processor PRC3 has an authorization data management unit 34 as a functional configuration based on the execution of the above-mentioned program.

[0043] The authorization data management unit 34 acquires the authorization data T (see above) sent from the authorization data generation device 10 via the communication device 33 and holds it.

[0044] Next, the operation procedure of the request verification system 1 according to the first embodiment will be described with reference to FIGS. 3A and 3B. FIG. 3A is a sequence diagram showing an example of the operation procedure of the request verification system 1 according to the first embodiment. FIG. 3B is a sequence diagram showing another example of the operation procedure of the request verification system 1 according to the first embodiment. In the description of FIGS. 3A and 3B, the arbitrary data DTA1 will be referred to as "arbitrary data D" and the authorization data AUTH1 will be referred to as "authorization data T." In the description of FIG. 3B, the same step numbers will be assigned to processes that overlap with those in FIG. 3A, and the description will be simplified or omitted, and only the differences will be described.

[0045] 3A, the authorization data generating device 10 holds its own certificate CERT1 and private key PRK1, and sends the certificate CERT1 of the authorization data generating device 10 to the verification device 20 to share it (St1). The verification device 20 receives and stores the certificate CERT1 of the authorization data generating device 10 sent from the authorization data generating device 10 in step St1 (St2).

[0046] The authorization data generation device 10 generates arbitrary data D, such as a random number, and encrypts the hash value (i.e., Hash (arbitrary data D)) using the private key PRK1 of the authorization data generation device 10 to generate a signature S (St3). The authorization data generation device 10 generates authorization data T by concatenating (linking) the generated signature S to the arbitrary data D (St3). Note that the order in which the signature S and the arbitrary data D are linked together does not need to be limited. The authorization data generation device 10 transmits the authorization data T generated in step St3 to the client device 30 using a highly secure communication channel (e.g., mutually authenticated BLE) formed between the authorization data generation device 10 and the client device 30 (St4).

[0047] The client device 30 establishes a highly secure communication path (e.g., mutually authenticated BLE) with the verification device 20. The client device 30 generates a request Y (e.g., a request for issuing a certificate for the client device 30 and sending it to the client device 30) based on, for example, a user's operation using the operation device 31, and includes the authorization data T sent from the authorization data generation device 10 in step St4 in the request Y and sends it to the verification device 20 via the above-mentioned communication path (St5).

[0048] The verification device 20 extracts and obtains the authorization data T included in the request Y sent from the client device 30 in step St5. The verification device 20 decrypts the signature S that constitutes the authorization data T using the public key of the authorization data generation device 10 included in the certificate CERT1 of the client device 30 saved in step St2 (St6). The verification device 20 calculates a hash value of the arbitrary data D that constitutes the authorization data T using a predetermined hash function between the authorization data generation device 10 and the verification device 20. The verification device 20 determines whether the verification of the authorization data T is successful or unsuccessful depending on whether the hash value is identical to the decrypted data F obtained by decryption (St6).

[0049] If the verification device 20 determines that the verification of the authorization data T is successful, it issues a digital certificate for the client device 30 as a response to the request Y and transmits it to the client device 30 via the above-mentioned highly secure communication channel (St7). Note that, here, an example has been described in which the request is a request for the issuance of a certificate for the client device 30 and transmission to the client device 30, and the response is a request for the issuance of a certificate for the client device 30 and transmission to the client device 30. However, examples of the request and response are not limited to these. For example, the request may be a request for access to a data file from the verification device 20 or a file management server (not shown) or for the granting of the access authority, and the response may be access to the data file from the verification device 20 or the file management server (not shown) or for the granting of the access authority. On the other hand, if the verification device 20 determines that the verification of the authorization data T has failed, it generates an error notification indicating that the verification of the authorization data T has failed and transmits it to the client device 30 via the above-mentioned highly secure communication channel (St7).

[0050] 3B, the verification device 20 downloads and acquires the CA certificate CA1 from the CA (certificate authority) in advance (St0) and stores it in the memory 22 (St2A). Note that instead of downloading the CA certificate CA1 from the CA (certificate authority) in advance, the verification device 20 may acquire the CA certificate CA1 from the authorization data generating device 10 when the authorization data generating device 10 holds the CA certificate CA1 and store it in the memory 22.

[0051] The authorization data generation device 10 generates arbitrary data D, such as a random number, and encrypts the hash value (i.e., Hash (arbitrary data D)) using the private key PRK1 of the authorization data generation device 10 to generate a signature S (St3A). The authorization data generation device 10 generates authorization data T by concatenating (linking) the generated signature S, the arbitrary data D, and a certificate CERT1 generated for the authorization data generation device 10 by a CA (certification authority) (St3A). Note that the order in which the signature S, the arbitrary data D, and the certificate CERT1 are concatenated does not need to be limited.

[0052] The verification device 20 extracts and acquires the authorization data T included in the request Y sent from the client device 30 in step St5 (St6-1). Using the CA certificate CA1 stored in step St2A, the verification device 20 verifies whether the certificate CERT1 included in the authorization data T acquired in step St6-1 is a certificate generated (issued) by a CA (certificate authority) (St6-1). For example, the verification device 20 decrypts the signature included in the CA certificate CA1 using the CA's public key included in the CA certificate CA1, and determines whether the calculation result of the hash value of arbitrary data included in the CA certificate CA1 (where the hash function is known to the CA (certificate authority), the authorization data generation device 10, and the verification device 20) is the same as the decryption result of the signature. If the verification device 20 determines that the calculation result of the hash value is the same as the decryption result of the signature, it determines that the certificate CERT1 included in the authorization data T acquired in step St6-1 is a certificate generated (issued) by a CA (certificate authority) (St6-1).

[0053] Furthermore, if the verification in step St6-1 is successful (i.e., if it is determined that the calculation result of the hash value and the decryption result of the signature are identical), the verification device 20 decrypts the signature S constituting the authorization data T sent from the client device 30 in step St5 using the public key of the authorization data generation device 10 included in the certificate CERT1 sent from the client device 30 in step St5 (St6-2). The verification device 20 calculates a hash value of arbitrary data D constituting the authorization data T using a predetermined hash function between the authorization data generation device 10 and the verification device 20. The verification device 20 determines whether the verification of the authorization data T is successful or failed depending on whether the hash value is identical to the decrypted data F obtained by decryption (St6-2). In this way, the verification device 20 may determine whether to provide a response to the request sent from the client device 30 in step St5 by the two-stage verification of steps St6-1 and St6-2. As a result, even if multiple authorization data generating devices 10 are installed, the verification device 20 can simply download and obtain the CA certificate CA1 from a CA (certificate authority) without having to obtain and share the certificate CERT1 in advance from each of the multiple authorization data generating devices 10, and can individually and easily verify the authorization data included in the request from the client device 30, and can also avoid the memory capacity pressure that may arise from storing multiple certificates CERT1.

[0054] As described above, in the request verification system 1 according to the first embodiment, the authorization data generation device 10 and the verification device 20 are connected to each other so that they can communicate with each other. The authorization data generation device 10 generates authorization data AUTH1 by signing arbitrary data DTA1 and sends the authorization data AUTH1 to the client device 30. When the verification device 20 receives a service usage request including the authorization data AUTH1 from the client device 30, the verification device 20 verifies the authorization data AUTH1. If the verification device 20 determines that the verification of the received authorization data AUTH1 is successful, the verification device 20 provides the client device 30 with the service corresponding to the request, and if the verification device 20 determines that the verification of the received authorization data AUTH1 is unsuccessful, the verification device 20 sends an error notification to the client device 30.

[0055] That is, in the request verification system 1, unlike Patent Document 1 described above, the secret information of the client device 30 is not shared from the authorization data generation device 10 to the verification device 20. Moreover, the authorization data AUTH1 is not generated so as to include the secret information of the client device 30, but is generated solely based on a random number, a counter value, or the like that does not have confidentiality. As a result, the request verification system 1 can safely verify the user request from the client device 30 without leaking the secret information of the client device 30 over the communication path, and can suppress a decrease in the security of the client device 30.

[0056] Furthermore, the authorization data generation device 10 shares a digital certificate (e.g., certificate CERT1) including the public key of the authorization data generation device 10 with the verification device 20. The verification device 20 verifies the authorization data AUTH1 included in the request by using the public key included in the shared digital certificate. This allows the request verification system 1 to safely transmit and receive the authorization data AUTH1 between the authorization data generation device 10 and the client device 30, and between the client device 30 and the verification device 20, using PKI (Public Key Infrastructure).

[0057] Furthermore, the authorization data generation device 10 encrypts the arbitrary data DTA1 with the private key of the authorization data generation device 10 to generate a signature. The verification device 20 determines whether the verification of the authorization data AUTH1 has succeeded or failed depending on whether the data obtained by decrypting the signature included in the received authorization data AUTH1 with the public key is identical to the data based on the arbitrary data DTA1 included in the authorization data AUTH1 (for example, a hash value of the arbitrary data). This allows the request verification system 1 to safely and easily verify requests from the client device 30.

[0058] (Embodiment 2) In a request verification system according to the second embodiment, a verification device constituting the request verification system generates an ID (Identification) corresponding to a client device and sends it to an authorization data generation device. The authorization data generation device generates authorization data using the ID corresponding to the client device sent from the verification device as arbitrary data. When the verification device determines that the verification of the authorization data included in the request from the client device is successful, it identifies a service corresponding to the ID included in the authorization data and provides it to the client device.

[0059] Fig. 4 is a block diagram showing an example of the hardware configuration of each device constituting a request verification system 1A according to embodiment 2. The request verification system 1A shown in Fig. 4 includes an authorization data generation device 10, a verification device 20A, and a client device 30. In the description of Fig. 4, the same reference numerals are assigned to components that overlap with those in Fig. 2, and the description will be simplified or omitted, and only differences will be described.

[0060] The verification device 20A includes an operation device 21, a memory 22, a communication device 23, and a processor PRC2A.

[0061] The processor PRC2A is configured using at least one of a CPU, a DSP, an FPGA, and a GPU, for example. The processor PRC2A controls the operation of each unit of the verification device 20A. The processor PRC2A may also control the operation of each unit of the verification device 20A based on a signal from the operation device 21. The processor PRC2A functions as a control unit of the verification device 20A and performs control processing for overall supervision of the operation of each unit of the verification device 20A, data input / output processing between each unit of the verification device 20A, data arithmetic (calculation) processing, and data storage processing. The processor PRC2A operates in accordance with the execution of a program stored in a ROM in the memory 22. The processor PRC2A has a signature verification unit 24, a public key management unit 25, and an ID generation unit 26 as functional components based on the execution of the above-mentioned program.

[0062] The memory 22A includes, for example, RAM and ROM, and temporarily stores programs required for the operation of the verification device 20A, and data or information generated by the processor PRC2A during operation. The RAM is, for example, a work memory used during operation of the processor PRC2A. The ROM pre-stores, for example, programs and data for controlling the processor PRC2A. The memory 22A may also include a storage device such as an HDD, flash memory, or SSD capable of storing data acquired or generated by the processor PRC2A. The memory 22A also stores the ID of the authorization data generation device 10 (for example, a four-digit alphanumeric combination), a counter value (for example, a 16-digit hexadecimal number) output by a counter (for example, built into the processor PRC2A) that is incremented each time an ID is generated, and data in the ID certificate table TBL1 (see FIG. 5).

[0063] The ID generation unit 26 reads the ID (e.g., a 4-digit alphanumeric combination) and the counter value (e.g., a 16-digit hexadecimal number) of the authorization data generation device 10 from memory 22A, and generates and stores an ID (e.g., a 20-digit alphanumeric combination) consisting of the ID of the authorization data generation device 10 and the counter value.

[0064] 5 is a diagram showing an example of an outline of a procedure for determining a certificate to be issued corresponding to an ID. As shown in FIG. 5, the ID generation unit 26 generates an ID by concatenating the ID of the authorization data generation device 10 (e.g., "01AB") and a counter value (e.g., "0000000000000001"). The ID certificate table TBL1 is stored in, for example, the memory 22A, and associates IDs with the types of certificates to be issued. Examples of certificate types include a server certificate with a validity period of 10 years, a client certificate with a validity period of one year, a code signing certificate with a validity period of 10 years, and so on.

[0065] A server certificate certifies that access to, for example, a web server (not shown) that provides a web service has been authorized. A client certificate certifies that a client device 30 is a legitimate client device when it is authenticated by, for example, an authentication server (not shown). A code signing certificate certifies that program code to be verified or authenticated is legitimate program code.

[0066] When the verification device 20A (e.g., the signature verification unit 24) determines that the verification of the authorization data included in the request from the client device 30 is successful, the verification device 20A identifies the type of certificate corresponding to the ID based on the ID constituting the authorization data and the ID certificate table TBL1. The verification device 20A issues a certificate of the identified type and sends it to the client device 30.

[0067] Next, the operation procedure of the request verification system 1A according to the second embodiment will be described with reference to Fig. 6. Fig. 6 is a sequence diagram showing an example of the operation procedure of the request verification system 1A according to the second embodiment. In the description of Fig. 6, the same steps as those in Fig. 3A or 3B are assigned the same step numbers, and the description will be simplified or omitted, and only different contents will be described.

[0068] In FIG. 6, after step St2, the verification device 20A generates an ID (e.g., a 20-digit alphanumeric combination) consisting of the ID (e.g., a 4-digit alphanumeric combination) of the authorization data generation device 10 and a counter value (e.g., a 16-digit hexadecimal number) (St11), and sends the generated ID to the authorization data generation device 10 (St12).

[0069] The authorization data generating device 10 generates a signature SA by encrypting the hash value of the ID sent in step St12 (i.e., see Hash(ID)) using the private key PRK1 of the authorization data generating device 10 (St13). The authorization data generating device 10 generates authorization data TA by concatenating the signature S generated in step St13 to the ID sent in step St12 (St13). The authorization data generating device 10 transmits the authorization data TA generated in step St13 to the client device 30 using a highly secure communication path (e.g., mutually authenticated BLE) formed between the authorization data generating device 10 and the client device 30 (St4A). Note that when there is a request from the client device 30 to transmit the authorization data TA, the authorization data generating device 10 may transmit the authorization data TA to the client device 30 (St4A0).

[0070] The client device 30 establishes a highly secure communication path (e.g., mutually authenticated BLE) with the verification device 20A. The client device 30 generates a request YA (e.g., service provision according to ID) based on, for example, a user's operation using the operation device 31, includes the authorization data TA sent from the authorization data generation device 10 in step St4A in the request YA, and sends the request YA to the verification device 20 via the above-mentioned communication path (St5A).

[0071] The verification device 20A extracts and obtains the authorization data TA included in the request YA sent from the client device 30 in step St5A. The verification device 20A decrypts the signature SA constituting the authorization data TA using the public key of the authorization data generation device 10 included in the certificate CERT1 of the client device 30 saved in step St2 (St14). The verification device 20A calculates a hash value of the ID (see step St11) constituting the authorization data TA using a predetermined hash function between the authorization data generation device 10 and the verification device 20A. The verification device 20A determines whether the verification of the authorization data TA is successful or unsuccessful depending on whether the hash value is identical to the decrypted data F obtained by decryption (St14).

[0072] If the verification device 20A determines that the verification of the authorization data TA is successful, in response to the request YA, it issues a certificate (see, for example, Figure 5) corresponding to the ID constituting the authorization data TA in step St14 and transmits the certificate to the client device 30 via the above-mentioned highly secure communication path (St15).

[0073] As described above, in the request verification system 1A according to the second embodiment, the verification device 20A generates an ID according to the client device 30 and sends it to the authorization data generation device 10. The authorization data generation device 10 generates authorization data TA using an ID (for example, see the combination of 20 alphanumeric characters shown in FIG. 5) as arbitrary data and sends it to the client device 30. If the verification device 20A determines that the verification of the received authorization data TA is successful, it provides the client device 30 with a service (for example, issuance of a certificate) according to the ID included in the received authorization data TA. As a result, similar to the effect of the request verification system 1 according to the first embodiment, the request verification system 1A can adaptively provide the client device 30 with a service according to the ID generated by the verification device 20A when the verification of the authorization data TA sent from the client device 30 is successful.

[0074] Alternatively, the authorization data generation device 10 may generate authorization data TA only once using the same ID. In this case, the verification device 20A stores the ID included in the received authorization data TA each time verification is performed, and rejects verification of authorization data TA that includes the same ID as the stored ID. As a result, the request verification system 1A generates authorization data TA for the same ID and verifies the authorization data TA only once. Therefore, even if the ID or authorization data TA is copied multiple times and a reply attack is performed, the service according to the ID is provided only once, thereby preventing a decrease in security when providing the service.

[0075] Furthermore, the request verification system 1A may be provided with a plurality of authorization data generation devices 10. The verification device 20A generates an ID including identification information (e.g., a serial number) of the authorization data generation device 10, and transmits the generated ID to the authorization data generation device 10 corresponding to the identification information. This allows the verification device 20A to easily determine which authorization data generation device 10 generated the authorization data by determining the ID constituting the authorization data TA during verification, thereby improving convenience when providing services.

[0076] Furthermore, the verification device 20A may associate authorization data revocation information, which indicates whether the authorization data TA generated by the authorization data generation device 10 has been revoked, with the ID and store it in the memory 22A. In this case, the verification device 20A revoks the authorization data that is the target of the revocation instruction, based on the revocation instruction from the authorization data generation device 10. As a result, even if the authorization data TA is stolen or lost by a malicious third party while being sent from the authorization data generation device 10 to the client device 30, the verification device 20A can revoked the authorization data TA that is the target of the revocation instruction, based on the revocation instruction from the authorization data generation device 10, and can prevent the stolen or lost authorization data from being misused, thereby improving security.

[0077] Furthermore, the verification device 20A may set an expiration date for the ID and send the ID with the set expiration date to the authorization data generation device 10. In this case, the authorization data generation device 10 generates authorization data TA having the same expiration date as the expiration date. This allows the request verification system 1A to reduce the misuse of the authorization data TA by a malicious third party compared to when the ID has an indefinite expiration date.

[0078] Furthermore, the authorization data generation device 10 generates authorization data TA using connection destination information (e.g., URL (Uniform Resource Locator), IP address) for the verification device 20A as arbitrary data, and sends the generated authorization data TA to the client device 30. This allows the client device 30 to easily access the verification device 20A based on the connection destination information included in the authorization data TA, even if the client device 30 does not know the address of the verification device 20A. This eliminates the need to pre-configure the connection destination information for the verification device 20A that should be accessed when using a service in the client device 30.

[0079] (Embodiment 3) In a request verification system according to a third embodiment, as a further application of the first or second embodiment, when a verification device constituting the request verification system receives, from a client device, a request to use an application that the client device has acquired from a download server, the verification device verifies encrypted authorization data (see below) included in the request. If the verification device determines that the verification is successful, the verification device authorizes the use of the application as a response to the request and sends the response to the client device. If the verification device determines that the verification is unsuccessful, the verification device sends an error notification indicating that the verification has failed to the client device. As a result, even if the authorization data sent from the authorization data generation device to the client device is leaked and forged, the request verification system can effectively block the use of the forged authorization data even when a request using the forged authorization data is received, or can deny approval for the use of an application linked to the authorization data, thereby improving security.

[0080] FIG. 7 is a diagram illustrating an example of a system configuration of a request verification system 1B according to a third embodiment. The request verification system 1B includes an authorization data generation device 10, a verification device 20, a client device 30, and a download server 40. In the description of FIG. 7, components that overlap with those in FIG. 1 are assigned the same reference numerals, and descriptions thereof are simplified or omitted, and only differences are described. Furthermore, the hardware configurations of the authorization data generation device 10, the verification device 20, and the client device 30 according to the third embodiment are the same as those of the corresponding devices according to the first embodiment, and therefore detailed descriptions thereof are omitted. Although only one client device 30 is illustrated in FIG. 7, two or more client devices 30 may be connected to the network NW1. The authorization data generation device 10, the client device 30, and the download server 40 are connected to each other via the network NW1 so as to be able to communicate with each other.

[0081] In the third embodiment, a verification device 20 used by a service provider generates an application key APK1 and sends it to an authorization data generation device 10 used by, for example, an application maker. The application key APK1 is configured, for example, by an AES common key or a password, and is shared between the authorization data generation device 10 and the verification device 20. It is used to encrypt an application APP1 generated by the authorization data generation device 10. When the application APP1 is generated, the authorization data generation device 10 uploads the data of the application APP1 including the application key APK1 to the download server 40. When the client device 30 downloads the data of the application APP1 including the application key APK1 from the download server 40, the client device 30 encrypts the authorization data AUTH1 (see the first embodiment) sent from the authorization data generation device 10 with the application key APK1 to generate encrypted authorization data EAUTH1, and sends a request including this encrypted authorization data EAUTH1 to the verification device 20. The verification device 20 decrypts the encrypted authorization data EAUTH1 with the application key APK1 to obtain the authorization data AUTH1.

[0082] The download server 40 is a server computer with communication capabilities that stores data for one or more applications, and although a detailed hardware configuration is not shown, it includes a processor such as a CPU, memory, and a communication device. When the download server 40 receives an upload request from the authorization data generation device 10, it stores the application data. When the download server 40 receives a download request from the client device 30, it transmits the application data specified in the request to the client device 30.

[0083] Next, the operation procedure of the request verification system 1B according to the third embodiment will be described with reference to Figs. 8 and 9. Figs. 8 and 9 are sequence diagrams showing an example of the operation procedure of the request verification system 1B according to the third embodiment. In the description of Figs. 8 and 9, the same step numbers are assigned to the same processes as those in Fig. 3A or 3B, and the description will be simplified or omitted, and only the differences will be described. In Figs. 8 and 9, the download server 40 holds the application APP1 so that it can be provided, and will be described as an app store that sells applications.

[0084] 8, after step St2, the verification device 20 generates an application key APK1 corresponding to the application to be generated by the authorization data generation device 10 (St21). The verification device 20 sends a software library including the application key APK1 generated in step St21 to the authorization data generation device 10 (St22). This software library includes the application key APK1 (in other words, the application key APK1 is embedded), and is a software component (API: Application Programming Interface) for bridging a connection to the verification device 20 by calling this software library during execution of the application.

[0085] The client device 30 generates a request for requesting transmission of authorization data T and sends it to the authorization data generation device 10 (St23). In response to the request from the client device 30, the authorization data generation device 10 transmits the authorization data T generated in step St3 (see FIG. 3A or 3B) to the client device 30 using a highly secure communication path (e.g., mutually authenticated BLE) formed between the authorization data generation device 10 and the client device 30 (St4).

[0086] The authorization data generation device 10 receives the software library sent from the verification device 20 in step St22 and generates an application that can be executed by calling this software library (St24). The authorization data generation device 10 uploads (transmits) data of the application APP1, including the software library in which the application key APK1 is embedded, to the download server 40 (St25).

[0087] The client device 30 accesses the download server 40 (for example, an app store) (St26).

[0088] 9, the client device 30 downloads and acquires data of the application APP1, including a software library in which the application key APK1 is embedded, from the download server 40 (St27). Based on a user operation of the client device 30, the client device 30 encrypts the authorization data T sent in step St4 with the application key APK1 to generate encrypted authorization data EAUTH1, and inputs and sets the encrypted authorization data EAUTH1 into the software library of the application APP1 (St28). The client device 30 includes the encrypted authorization data EAUTH1 in a request Y for permitting use of the application APP1, and sends the request to the verification device 20 (St5B).

[0089] The verification device 20 extracts and obtains the encrypted authorization data EAUTH1 included in the request Y sent from the client device 30 in step St5B. The verification device 20 decrypts the encrypted authorization data EAUTH1 with the application key APK1 generated in step St21 (St6B). The verification device 20 decrypts the signature S constituting the authorization data T obtained by decryption using the public key of the authorization data generation device 10 included in the certificate CERT1 of the client device 30 stored in step St2 (St6B). The verification device 20 calculates a hash value of the arbitrary data D constituting the authorization data T using a predetermined hash function between the authorization data generation device 10 and the verification device 20. The verification device 20 determines whether the verification of the authorization data T is successful or failed depending on whether the hash value is identical to the decrypted data F obtained by decryption (St6B).

[0090] If the verification device 20 determines that the verification of the authorization data T is successful, it generates authority information for permitting the use of the application APP1 as a response to the request Y and transmits the generated authority information to the client device 30 (St7B). On the other hand, if the verification device 20 determines that the verification of the authorization data T is unsuccessful, it generates an error notification indicating that the use of the application APP1 is not permitted and transmits the error notification to the client device 30 via the above-mentioned highly secure communication path (St7B). For example, even if the authorization data T transmitted from the authorization data generation device 10 to the client device 30 is leaked and forged by a malicious third party, the verification device 20 will not succeed in the verification in step St6B unless the application key APK1 is obtained. Therefore, the verification device 20 can effectively block the use of authorization data forged by a malicious third party and can refuse (deny) the use of the application APP1 with any application key other than the application key APK1 associated with the authorization data, thereby improving security.

[0091] As described above, in the request verification system 1B according to the third embodiment, when the verification device 20 constituting the request verification system 1B receives from the client device 30 a request Y to use the application APP1 that the client device 30 has acquired from a download server 40 such as an app store, the verification device 20 verifies the encrypted authorization data EAUTH1 included in the request Y. If the verification device 20 determines that the verification is successful, the verification device 20 authorizes the use of the application APP1 as a response to the request Y and returns the response to the client device 30. If the verification device 20 determines that the verification is unsuccessful, the verification device 20 transmits an error notification to the client device 30 indicating that the verification has failed.

[0092] As a result, the request verification system 1B can properly determine whether to permit use of the application APP1 from the client device 30, without using secret information of the client device 30, by performing double verification, namely, a first verification of whether the encrypted authorization data EAUTH1 sent from the client device 30 can be properly decrypted by the application key APK1, and a second verification of whether the authorization data AUTH1 obtained by decryption can be verified. As a result, even if the authorization data T sent from the authorization data generation device 10 to the client device 30 is leaked and the authorization data T is forged by a malicious third party, the verification by the verification device 20 will not be successful unless the application key APK1 is obtained. Therefore, even if a request using the forged authorization data is received, the request verification system 1B can effectively block use of the forged authorization data or deny approval for use of the application linked to the authorization data, thereby improving security.

[0093] Although various embodiments have been described above with reference to the drawings, it goes without saying that the present disclosure is not limited to such examples. It is clear that a person skilled in the art can conceive of various modifications, alterations, substitutions, additions, deletions, and equivalents within the scope of the claims, and it is understood that these also naturally fall within the technical scope of the present disclosure. Furthermore, the components of the various embodiments described above may be combined in any manner without departing from the spirit of the invention.

[0094] This application is based on a Japanese patent application (Patent Application No. 2020-204248) filed on December 9, 2020, the contents of which are incorporated herein by reference. [Industrial Applicability]

[0095] The present disclosure is useful as a request verification system and a request verification method that safely verify a user's request without leaking confidential information of the client device and that suppresses a decrease in security of the client device. [Explanation of symbols]

[0096] 1, 1A, 1B Request Validation System 10 Authorization data generation device 11, 21, 31 Operation Device 12, 22, 32 memory 13, 23, 33 Communication Devices 14 Private key management department 15 Authorization Data Management Department 16 Public Key Management Unit 17 Optional Data Management Section 18 Signature generation section 20 Verification Device 24 Signature Verification Unit 25 Public Key Management Unit 26 ID generation section 30 Client Device 34 Authorization Data Management Department PRC1, PRC2, and PRC3 processors

Claims

1. an authorization data generating device that generates and outputs authorization data that authorizes the provision of a service and that holds a certificate including a public key; a verification device that shares the certificate with the authorization data generation device; a client device that uses the provided service; the verification device generates an ID corresponding to the client device and sends it to the authorization data generation device, and upon receiving a request to verify the authorization data from the client device, verifies the authorization data using the certificate; the authorization data generation device holds a private key of the authorization data generation device, generates the authorization data using a signature obtained by encrypting an ID corresponding to the client device with the private key, and sends the authorization data to the client device; Request validation system.

2. The verification device providing the service to the client device upon determining that the verification of the authorization data was successful; The request validation system of claim 1 .

3. The verification device If it is determined that the verification of the authorization data has failed, an error notification is sent to the client device. The request validation system of claim 1 .

4. the authorization data generation device, a private key of the authorization data generation device is held, and a signature is generated by encrypting arbitrary data with the private key; The request validation system of claim 1 .

5. The verification device determining whether the authentication of the authorization data has been successful or not based on whether data obtained by decrypting the signature with the public key is identical to data based on the arbitrary data included in the authorization data; The request validation system of claim 4.

6. the authorization data generation device, generating the authorization data only once using the same ID; The verification device storing an ID included in the received authorization data each time the verification is performed, and refusing to verify authorization data that includes an ID identical to the stored ID; The request validation system of claim 1 .

7. a plurality of the authorization data generation devices are provided, The verification device generating the ID including identification information of the authorization data generation device, and transmitting the generated ID to the authorization data generation device corresponding to the identification information; The request validation system of claim 1 .

8. The verification device storing authorization data revocation information indicating whether the authorization data generated by the authorization data generation device has expired in association with the ID; Revoke the validity of the authorization data that is the subject of the revocation instruction based on the revocation instruction from the authorization data generation device. The request validation system of claim 1 .

9. The verification device setting an expiration date for the ID, and sending the ID with the expiration date set to the authorization data generation device; the authorization data generation device, generating the authorization data having an expiration date that is the same as the expiration date; The request validation system of claim 1 .

10. the authorization data generation device, generating the authorization data using connection destination information of the verification device as the optional data and sending the authorization data to the client device; The request validation system of claim 4.

11. generating and outputting authorization data authorizing the provision of the service and retaining a certificate including the public key; generating an ID corresponding to the client device requesting the provision of the service; Sharing the certificate; and when verification of the authorization data is requested, verifying the authorization data using the certificate; In generating the authorization data, the authorization data is generated using a signature obtained by encrypting an ID corresponding to the client device with a private key of an authorization data generation device that generates the authorization data. The request validation method.

Images