WO2022124352A1 - リクエスト検証システムおよびリクエスト検証方法 - Google Patents

リクエスト検証システムおよびリクエスト検証方法 Download PDF

Info

Publication number
WO2022124352A1
WO2022124352A1 PCT/JP2021/045219 JP2021045219W WO2022124352A1 WO 2022124352 A1 WO2022124352 A1 WO 2022124352A1 JP 2021045219 W JP2021045219 W JP 2021045219W WO 2022124352 A1 WO2022124352 A1 WO 2022124352A1
Authority
WO
WIPO (PCT)
Prior art keywords
authorization data
verification
request
client device
certificate
Prior art date
Application number
PCT/JP2021/045219
Other languages
English (en)
French (fr)
Inventor
三朗 豊永
将清 坂本
Original Assignee
パナソニックＩｐマネジメント株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニックＩｐマネジメント株式会社 filed Critical パナソニックＩｐマネジメント株式会社
Priority to JP2022568320A priority Critical patent/JPWO2022124352A1/ja
Publication of WO2022124352A1 publication Critical patent/WO2022124352A1/ja
Priority to US18/206,483 priority patent/US20230318828A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Definitions

  • This disclosure relates to a request verification system and a request verification method.
  • 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 for identifying a client device owned by the user (for example, information based on confidential information of the client device), and uses this specific information to generate an electronic ticket.
  • the application device communicates with the client device and inspects the electronic ticket to verify the user's access entitlement.
  • Patent Document 1 specific information based on the confidential information of the client device is shared by both the client device and the electronic ticket generator, and is further passed from the electronic ticket generator to the application device. Therefore, since there is a risk that specific information is leaked, there is a concern that the security of the client device may be deteriorated.
  • This disclosure was devised in view of the above-mentioned conventional situation, and is a request verification system and a request verification method that safely verifies a user's request without leaking confidential information of the client device and suppresses a decrease in the security of the client device.
  • the purpose is to provide.
  • the present disclosure includes an authorization data generator that generates and outputs authorization data that authorizes the provision of services and holds a certificate including a public key, an authorization data generator, and a verification device that shares the certificate with the authorization data generator.
  • a request verification system including a client device that uses the provided service, wherein the verification device verifies the authorization data using the certificate when receiving a verification request for the authorization data from the client device. offer.
  • this disclosure requests a step of generating and outputting authorization data for authorizing the provision of services, holding a certificate including a public key, a step of sharing the certificate, and verification of the authorization data. Then, a request verification method is provided, which comprises a step of verifying the authorization data using the certificate.
  • the user's request can be safely verified without leaking the confidential information of the client device, and the security deterioration of the client device can be suppressed.
  • the figure which shows the outline example of the determination procedure of the certificate issued corresponding to the ID A sequence diagram showing an example of the operation procedure of the request verification system according to the second embodiment.
  • the verification device constituting the request verification system makes a request desired by the user (for example, each application for issuing an electronic certificate of the client device and transmitting to the client device) from the client device.
  • the verification device determines that the verification is successful, the verification device provides a response to the request (for example, issuance of a digital certificate of the client device and transmission to the client device) to the client device.
  • the verification device determines that the verification has failed, the verification device sends an error notification to the client device to the effect that the verification has failed.
  • FIG. 1 is a diagram showing a system configuration example of the request verification system 1 according to the 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 shown in FIG. 1, two or more client devices 30 may be connected to the network NW1.
  • the authorization data generation device 10, the verification device 20, and the client device 30 are communicably connected to each other via the network NW1.
  • the network NW1 may be a wired network (for example, a wired LAN (Local Area Network)) or a wireless network (for example, a wireless LAN).
  • the authorization data generation device 10 generates data (hereinafter referred to as “authorization data”) indicating that the provision of a response (see above) to a request (see above) desired by a user using the client device 30 is authorized. This authorization data is sent to the client device 30.
  • the authorization data generation device 10 holds the secret key PRK1 of the authorization data generation device 10, and generates the hash value of the arbitrary data DTA1 (for example, a random number) or the DTA1 by encrypting it with the secret key PRK1 of the authorization data generation device 10.
  • the authorization data AUTOH1 is generated by concatenating the signature (sometimes referred to as "electronic signature") with the arbitrary data DTA1.
  • the authorization data generation device 10 and the verification device 20 share a hash function used for calculating the hash value in advance. Further, the authorization data generation device 10 holds a certificate CERT1 (sometimes referred to as an "electronic certificate") including the public key of the authorization data generation device 10, and the certificate CERT1 is used with the verification device 20. Share between.
  • This certificate CERT1 is generated (issued) for the authorized data generation device 10 by CA, which will be described later, and is generated by encrypting arbitrary data by CA using a CA's private key (not shown). It includes at least a signature (not shown), arbitrary data used for generating the signature, a public key of CA, and a public key of the authorization data generation device 10, and is held by the authorization data generation device 10.
  • the arbitrary data to be encrypted by the CA using the CA's private key is the same when the CA generates one or more certificates (for example, certificate CERT1 and CA certificate CA1). Has been done.
  • the request verification system 1 may be configured to include a plurality of authorization data generation devices 10.
  • the authorization data generation device 10 having the certificate CERT1 having the usage authority to be granted to the client device 30 may be appropriately switched.
  • the client device 30 can be made to hold the desired certificate CERT1 from the corresponding authorization data generation device 10.
  • the verification device 20 Upon receiving the request from the client device 30, the verification device 20 uses the public key included in the certificate CERT1 shared in advance with the authorization data generation device 10 (for example, the public key of the authorization data generation device 10). , Validate the authorization data AUTOH1 (see above) contained in the request. Although the details will be described later, the verification device 20 may verify the authorization data AUTOH1 (see above) included in the request by using the CA certificate CA1 downloaded in advance from the CA described later. As a result, even if a plurality of authorization data generation devices 10 are provided, the verification device 20 can generate a plurality of authorization data by simply downloading and acquiring the CA certificate CA1 from the CA (certificate authority).
  • the verification device 20 When it is determined that the verification is successful, the verification device 20 provides the client device 30 with a response to the above-mentioned request (for example, issuance of an electronic certificate of the client device 30 and transmission to the client device 30). When the verification device 20 determines that the verification has failed, the verification device 20 transmits an error notification to the effect that the verification has failed to the client device 30.
  • the error notification means that the digital certificate of the client device 30 cannot be issued (that is, the desired usage authority cannot be obtained for the client device 30).
  • the verification device 20 may acquire and retain the CA certificate CA1 generated (issued) by a CA (Certification Authority), which is also called a public certificate authority, by downloading it from the CA.
  • the CA certificate CA1 contains at least a signature generated by encryption of arbitrary data by CA using a CA private key (not shown), arbitrary data used to generate the signature, and a CA public key. include.
  • 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.
  • the client device 30 is used by the 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 be a PC (Personal Computer).
  • the authorization data AUTOH1 generated by the authorization data generation device 10 is received and stored.
  • the client device 30 sends a request (see above) containing the authorization data AUTOH1 to the verification device 20.
  • the client device 30 determines that the verification of the request by the verification device 20 is successful, the client device 30 verifies the provision of a response to the request (for example, issuance of an electronic certificate of the client device and transmission to the client device).
  • the client device 30 receives an error notification from the verification device 20 to the effect that the verification has failed.
  • FIG. 2 is a block diagram showing a hardware configuration example of each device constituting the request verification system 1 according to the first embodiment.
  • the request verification system 1 shown in FIG. 2 has a configuration including an authorization data generation device 10, a verification device 20, and a client device 30.
  • the authorization data generation device 10 includes an operation device 11, a memory 12, a communication device 13, and a processor PRC1.
  • the operation device 11 is a device that accepts the operation of the user of the authorization data generation device 10, and is composed of, for example, at least one of a mouse, a keyboard, a touch pad, and a touch panel.
  • the operation device 11 sends a signal based on the user's operation to the processor PRC1.
  • the memory 12 includes, for example, a RAM (Random Access Memory) and a ROM (Read Only Memory), a program necessary for executing the operation of the authorization data generation device 10, and data or information generated by the processor PRC1 during the operation temporarily.
  • the RAM is, for example, a work memory used during the operation of the processor PRC1.
  • the ROM stores, for example, a program and data for controlling the processor PRC1 in advance.
  • the memory 12 may be configured to include storage such as an HDD (Hard Disk Drive), a flash memory, or an SSD (Solid State Drive) capable of storing data acquired or generated by the processor PRC1.
  • the communication device 13 is configured by using a communication circuit that transmits / receives data or information to / from the network NW1 and transmits / receives data or information to / from the verification device 20 or one or more client devices 30.
  • the communication device 13 communicates with the verification device 20 or one or more client devices 30 using a highly secure communication path (for example, BLE: Bluetooth® Low Energy) that is mutually authenticated. You may.
  • BLE Bluetooth® Low Energy
  • the processor PRC1 is configured by 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 part of the authorization data generation device 10. Further, the processor PRC1 may control the operation of each part of the authorization data generation device 10 based on the signal from the operation device 11.
  • the processor PRC1 functions as a control unit of the authorization data generation device 10, controls processing for overall control of the operation of each part of the authorization data generation device 10, and input of data between each part of the authorization data generation device 10. Performs output processing, data calculation (calculation) processing, and data storage processing.
  • the processor PRC1 operates according to the execution of the program stored in the ROM in the memory 12.
  • the processor PRC1 includes 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 as a functional configuration based on the execution of the above-mentioned program. Have.
  • the private key management unit 14 generates and holds the private key of the authorization data generation device 10 (for example, a pair of private keys (d, N) of RSA encryption).
  • the type of private key does not have to be limited to RSA encryption.
  • the authorization data management unit 15 generates and holds the authorization data AUTOH1 by concatenating (concatenating) the signature (so-called electronic signature) generated by the signature generation unit 18 with the arbitrary data DTA1.
  • [A] and [B] indicate that the data A and the data B are connected to each other.
  • the authorization data AUTOH1 is generated so as to have a different data entity for each client device 30.
  • the public key management unit 16 generates and holds a public key of the authorization data generation device 10 (for example, a pair of public keys (e, N) of RSA cryptography). The type of public key does not have to be limited to RSA cryptography. Further, the public key management unit 16 generates and holds a certificate CERT1 (that is, an electronic certificate of the authorization data generation device 10) including the generated public key.
  • the certificate CERT1 may be issued by a certificate authority (see above, CA: Certification Authority) (see above).
  • the arbitrary data management unit 17 generates and holds arbitrary data DTA1 (for example, a random number or a counter value) constituting the authorization data AUTOH1.
  • the arbitrary data DTA1 is arbitrary data having so-called randomness, and is different from, for example, confidential information of the client device 30 (for example, an IP (Internet Protocol) address, a MAC (Media Access Control) address), such as a random number. It is data that does not have confidentiality.
  • the signature generation unit 18 signs by encrypting the arbitrary data DTA1 generated by the arbitrary data management unit 17 by using the private key (for example, a pair of (e, N)) generated by the private key management unit 14. To generate and hold.
  • the signature generation algorithm is not limited to RSA, and may be, for example, ECDSA.
  • the signature generation unit 18 calculates Hash (arbitrary data D) between the authorization data generation device 10 and the verification device 20 using a default hash function.
  • Hash (A) is an operator for obtaining a hash value (digest value) of data A, and is, for example, SHA2 or SHA3.
  • the signature generation unit 18 generates the signature S by the operation of (Hash (arbitrary data D)) d modN. For example, when a signature is generated with the private key of RSA cryptography, this signature can be decrypted using only the public key of the authorization data generation device 10.
  • the verification device 20 includes an operation device 21, a memory 22, a communication device 23, and a processor PRC2.
  • the operation device 21 is a device that accepts the operation of the user of the verification device 20, and is composed of, for example, at least one of a mouse, a keyboard, a touch pad, and a touch panel.
  • the operating device 21 sends a signal based on the user's operation to the processor PRC2.
  • the memory 22 includes, for example, a RAM and a ROM, and temporarily stores a program necessary for executing the operation of the verification device 20, data or information generated by the processor PRC2 during the operation.
  • the RAM is, for example, a working memory used during the operation of the processor PRC2.
  • the ROM stores, for example, a program and data for controlling the processor PRC2 in advance.
  • the memory 22 may be configured to include storage such as an HDD, a flash memory, or an SSD that can store data acquired or generated by the processor PRC2.
  • the communication device 23 is configured by using a communication circuit that transmits / receives data or information to / from the network NW1 and transmits / receives data or information to / from the authorized 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 highly secure communication path (for example, BLE) that is mutually authenticated.
  • a highly secure communication path for example, BLE
  • the processor PRC2 is configured using, for example, at least one of a CPU, DSP, FPGA and GPU.
  • the processor PRC2 controls the operation of each part of the verification device 20. Further, the processor PRC2 may control the operation of each part of the verification device 20 based on the signal from the operating device 21.
  • the processor PRC2 functions as a control unit of the verification device 20, and controls processing for overall control of the operation of each part of the verification device 20, data input / output processing with each part of the verification device 20, and data calculation. Performs (calculation) processing and data storage processing.
  • the processor PRC2 operates according to the execution of the program stored in the ROM in the memory 22.
  • the processor PRC2 has a signature verification unit 24 and a public key management unit 25 as a functional configuration based on the execution of the above-mentioned program.
  • the signature verification unit 24 uses the public key (that is, the public key of the authorization data generation device 10) included in the certificate CERT1 (that is, the digital certificate of the authorization data generation device 10) held by the public key management unit 25. , The authorization data T included in the request from the client device 30 is verified. Specifically, when the signature verification unit 24 acquires the authorization data T (for example, [signature S] [arbitrary data D]) from the client device 30, the signature S is given using the public key (e, N) pair. Decrypt. For example, the signature verification unit 24 acquires the decrypted data F by the calculation of (signature S) emodN , and configures the authorization data T between the authorization data generation device 10 and the verification device 20 by using a default hash function.
  • the hash value (Hash (arbitrary data D)) of the arbitrary data D is calculated.
  • the signature verification unit 24 verifies the authorization data T included in the request from the client device 30 depending on whether the hash value of the arbitrary data D and the decryption data F are the same.
  • the signature verification unit 24 determines that the verification is successful when it is determined that the hash value of the arbitrary data D and the decrypted data F are the same, and determines that the hash value of the arbitrary data D and the decoded data F are not the same. If so, it is determined that the verification has failed.
  • the signature verification unit 24 determines that the verification is successful, it instructs the approval of the response to the above-mentioned request (for example, issuance of the digital certificate of the client device 30 and transmission to the client device 30). Based on this instruction, the processor PRC2 issues (generates), for example, an electronic certificate of the client device 30, and provides (transmits) it to the client device 30 via the communication device 23. Further, when the signature verification unit 24 determines that the verification has failed, the signature verification unit 24 transmits an error notification to the effect that the verification has failed to the client device 30 via the communication device 23.
  • the public key management unit 25 is a certificate sent to be shared by the authorization data generation device 10 (that is, an electronic certificate of the authorization data generation device 10), or a CA certificate CA1 downloaded in advance from CA (see above). (See FIG. 3B) is acquired and held.
  • the certificate sent to be shared by the authorization data generation device 10 includes the signature generated by the CA, the public key of the CA, and the public key of the authorization data generation device 10. For example, (e, N) pair) and at least are included.
  • the CA certificate CA1 downloaded in advance from the CA includes at least the signature generated by the CA and the public key of the CA.
  • the client device 30 includes an operation device 31, a memory 32, a communication device 33, and a processor PRC3.
  • the operation device 31 is a device that accepts the operation of the user of the client device 30, and is composed of, for example, at least one of a mouse, a keyboard, a touch pad, and a touch panel.
  • the operation device 31 sends a signal based on the user's operation to the processor PRC3.
  • the operation device 31 may be omitted from the configuration of the client device 30.
  • the memory 32 includes, for example, a RAM and a ROM, and temporarily stores a program necessary for executing the operation of the client device 30, data or information generated by the processor PRC3 during the operation.
  • the RAM is, for example, a working memory used during the operation of the processor PRC3.
  • the ROM stores, for example, a program and data for controlling the processor PRC3 in advance.
  • the memory 32 may be configured to include storage such as an HDD, a flash memory, or an SSD that can store data acquired or generated by the processor PRC3.
  • the communication device 33 is configured by using a communication circuit that transmits / receives data or information to / from the network NW1, and transmits / receives data or information to / from the authorization data generation device 10 or the verification device 20.
  • the communication device 33 may communicate with the authorization data generation device 10 or the verification device 20 using a highly secure communication path (for example, BLE) that is mutually authenticated.
  • the processor PRC3 is configured using, for example, at least one of a CPU, DSP, FPGA and GPU.
  • the processor PRC3 controls the operation of each part of the client device 30. Further, the processor PRC3 may control the operation of each part of the client device 30 based on the signal from the operating device 31.
  • the processor PRC3 functions as a control unit of the client device 30, and controls processing for overall control of the operation of each part of the client device 30, data input / output processing with and from each part of the client device 30, and data calculation. Performs (calculation) processing and data storage processing.
  • the processor PRC3 operates according to the execution of the program stored in the 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.
  • the authorization data management unit 34 acquires and holds the authorization data T (see above) sent from the authorization data generation device 10 via the communication device 33.
  • 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.
  • the arbitrary data DTA1 is referred to as "arbitrary data D”
  • the authorization data AUTOH1 is referred to as "authorization data T”.
  • the same step number is assigned to the process overlapping with FIG. 3A to simplify or omit the description, and different contents will be described.
  • the authorization data generation device 10 holds each of the certificate CERT1 and the private key PRK1 of the authorization data generation device 10, and the verification device 20 is used to share the certificate CERT1 of the authorization data generation device 10.
  • Send (St1).
  • the verification device 20 receives and stores the certificate CERT1 of the authorization data generation device 10 sent from the authorization data generation device 10 in step St1 (St2).
  • the authorization data generation device 10 generates an arbitrary data D such as a random number and encrypts a hash value (that is, Hash (arbitrary data D)) using the secret key PRK1 of the authorization data generation device 10 to sign S. Is generated (St3).
  • the authorization data generation device 10 generates authorization data T by concatenating (concatenating) the generated signature S with arbitrary data D (St3).
  • the order of concatenation (concatenation) between the signature S and the arbitrary data D does not have to be limited.
  • the authorization data generation device 10 uses the authorization data T generated in step St3 with a highly secure communication path (for example, mutually authenticated BLE) formed between the authorization data generation apparatus 10 and the client apparatus 30. Is transmitted to the client device 30 (St4).
  • the client device 30 forms a highly secure communication path (for example, mutually authenticated BLE) with the verification device 20.
  • the client device 30 generates a request Y (for example, each application for issuing a certificate of the client device 30 and transmitting to the client device 30) based on an operation using the user's operation device 31, and generates authorization data in step St4.
  • the authorization data T sent from the device 10 is included in the request Y and sent to the verification device 20 via the above-mentioned communication path (St5).
  • 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.
  • the verification device 20 decrypts the signature S constituting the authorization data T by 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 arbitrary data D constituting the authorization data T by using a default 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 and the decrypted data F obtained by decoding are the same (St6).
  • the verification device 20 determines that the verification of the authorization data T is successful, the verification device 20 issues an electronic certificate of the client device 30 as a response to the request Y and transmits the digital certificate to the client device 30 via the above-mentioned highly secure communication path. (St7).
  • the request is an application for issuance of a certificate of the client device 30 and transmission to the client device 30, and the response is issuance of a certificate of the client device 30 and transmission to the client device 30.
  • request and response examples are not limited to these.
  • the request is an application for accessing the data file to the verification device 20 or the file management server (not shown) or granting the authority to access the data file
  • the response is the data to the verification device 20 or the file management server (not shown). It may be to access the file or grant the permission to access the file.
  • the verification device 20 determines that the verification of the authorization data T has failed
  • the verification device 20 generates an error notification indicating that the verification of the authorization data T has failed and transmits the error notification to the client device 30 via the above-mentioned highly secure communication path. (St7).
  • the verification device 20 downloads the CA certificate CA1 from the CA (certificate authority) in advance (St0) and stores it in the memory 22 (St2A).
  • the verification device 20 does not download the CA certificate CA1 from the CA (certificate authority) in advance, but obtains the CA certificate from the authorization data generation device 10 when the authorization data generation device 10 holds the CA certificate CA1.
  • the document CA1 may be acquired and stored in the memory 22.
  • the authorization data generation device 10 generates an arbitrary data D such as a random number and encrypts a hash value (that is, Hash (arbitrary data D)) using the secret key PRK1 of the authorization data generation device 10 to sign S. Is generated (St3A).
  • the authorization data generation device 10 generates authorization data T by concatenating (concatenating) the generated signature S, arbitrary data D, and the certificate CERT1 generated for the authorization data generation device 10 from the CA (certificate authority). (St3A).
  • the order of concatenation (concatenation) between the signature S, the arbitrary data D, and the certificate CERT1 is not limited.
  • 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).
  • the verification device 20 uses the CA certificate CA1 saved in step St2A to certify that the certificate CERT1 constituting the authorization data T acquired in step St6-1 is generated (issued) by the CA (certificate authority). Verify whether it is a book (St6-1).
  • the verification device 20 decrypts the signature included in the CA certificate CA1 using the public key of the CA included in the CA certificate CA1, and has a hash value of arbitrary data included in the CA certificate CA1 (provided, a hash function).
  • the verification device 20 determines whether or not the calculation result of the CA (certificate authority), the authorization data generation device 10, and the verification device 20) is the same as the above-mentioned signature decryption result.
  • the verification device 20 determines that the hash value calculation result and the signature decryption result described above are the same, the certificate CERT1 constituting the authorization data T acquired in step St6-1 is CA (authentication). It is determined that the certificate is generated (issued) by the authority (St6-1).
  • step St6-1 the verification device 20 from the client device 30 in step St5.
  • the signature S constituting the sent authorization data T is decrypted 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 by using a default 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 and the decrypted data F obtained by decoding are the same (St6-2). In this way, the verification device 20 may determine whether or not to provide a response to the request sent from the client device 30 in step St5 by the two-step verification of step St6-1 and step St6-2. As a result, even if a plurality of authorization data generation devices 10 are provided, the verification device 20 can obtain the CA certificate CA1 by simply downloading it from the CA (certificate authority), and the authorization data of the plurality of units can be obtained.
  • the authorization data generation device 10 and the verification device 20 are connected to each other so as to be communicable with each other.
  • the authorization data generation device 10 signs the arbitrary data DTA1 with the arbitrary data DTA1 to generate the authorization data AUTOH1, and sends the authorization data AUTOH1 to the client apparatus 30.
  • the verification device 20 Upon receiving the service use request including the authorization data AUTOH1 from the client apparatus 30, the verification device 20 verifies the authorization data AUTOH1.
  • the verification device 20 provides a service corresponding to the request to the client device 30 when it is determined that the verification of the received authorization data AUTOH1 is successful, and determines to the client device 30 that the verification of the received authorization data AUTOH1 is unsuccessful. Send an error notification.
  • the confidential information of the client device 30 is not shared from the authorization data generation device 10 to the verification device 20.
  • the authorization data AUTOH1 is not generated so as to include the secret information of the client device 30, but is generated based on a random number or a counter value having no confidentiality to the last.
  • the request verification system 1 can safely verify the user's request from the client device 30 without leaking the confidential information of the client device 30 in the communication path, and can suppress the security deterioration of the client device 30.
  • the authorization data generation device 10 shares an electronic certificate (for example, 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 AUTOH1 included in the request by using the public key included in the shared digital certificate.
  • the request verification system 1 uses PKI (Public Key Infrastructure) to obtain authorization data between the authorization data generation device 10 and the client apparatus 30, and between the client apparatus 30 and the verification apparatus 20. The transmission and reception of AUTOH1 can be executed safely.
  • PKI Public Key Infrastructure
  • 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 or not the data obtained by decrypting the signature included in the received authorization data AUTOH1 with the public key and the data based on the arbitrary data DTA1 included in the authorization data AUTOH1 (for example, the hash value of the arbitrary data) are the same. The success or failure of the verification of the authorization data AUTOH1 is determined accordingly. As a result, the request verification system 1 can safely and easily verify the request from the client device 30.
  • the verification device constituting the request verification system generates an ID (Identification) corresponding to the client device and sends it to the authorization data generation device.
  • the authorization data generation device generates authorization data by using the ID corresponding to the client device sent from the verification device as arbitrary data.
  • the verification device determines that the verification of the authorization data included in the request from the client device is successful, the verification device identifies the service corresponding to the ID included in the authorization data and provides the service to the client device.
  • FIG. 4 is a block diagram showing a hardware configuration example of each device constituting the request verification system 1A according to the second embodiment.
  • the request verification system 1A shown in FIG. 4 has a configuration including an authorization data generation device 10, a verification device 20A, and a client device 30.
  • the same reference numerals are given to those overlapping with the configuration of FIG. 2, and the description is simplified or omitted, and different contents will be described.
  • the verification device 20A includes an operation device 21, a memory 22, a communication device 23, and a processor PRC2A.
  • the processor PRC2A is configured using, for example, at least one of a CPU, DSP, FPGA and GPU.
  • the processor PRC2A controls the operation of each part of the verification device 20A. Further, the processor PRC2A may control the operation of each part of the verification device 20A based on the signal from the operating device 21.
  • the processor PRC2A functions as a control unit of the verification device 20A, and controls processing for overall control of the operation of each part of the verification device 20A, data input / output processing between each part of the verification device 20A, and data calculation. Performs (calculation) processing and data storage processing.
  • the processor PRC2A operates according to the execution of the program stored in the 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 a functional configuration based on the execution of the above-mentioned program.
  • the memory 22A includes, for example, a RAM and a ROM, and temporarily stores a program necessary for executing the operation of the verification device 20A, and data or information generated by the processor PRC2A during the operation.
  • the RAM is, for example, a working memory used when operating the processor PRC2A.
  • the ROM stores, for example, a program and data for controlling the processor PRC2A in advance.
  • the memory 22A may be configured to include storage such as an HDD, a flash memory, or an SSD that can store data acquired or generated by the processor PRC2A.
  • the memory 22A is a counter value (for example, 16 digits) output by an ID of the authorization data generation device 10 (for example, a combination of 4-digit alphanumeric characters) and a counter that is incremented each time the ID is generated (for example, built in the processor PRC2). (Hexadecimal number) and the data of the ID certificate table TBL1 (see FIG. 5) are stored respectively.
  • an ID of the authorization data generation device 10 for example, a combination of 4-digit alphanumeric characters
  • a counter that is incremented each time the ID is generated for example, built in the processor PRC2. (Hexadecimal number) and the data of the ID certificate table TBL1 (see FIG. 5) are stored respectively.
  • the ID generation unit 26 reads the ID (for example, a combination of 4-digit alphanumerical characters) and the counter value (for example, a 16-digit hexadecimal number) of the authorization data generation device 10 from the memory 22A, and reads the ID of the authorization data generation device 10 and the counter.
  • An ID consisting of a value (for example, a combination of 20-digit alphanumerical characters) is generated and held.
  • FIG. 5 is a diagram showing an outline example of a procedure for determining a certificate issued corresponding to an ID.
  • the ID generation unit 26 generates an ID in which the ID (for example, “01AB”) of the authorization data generation device 10 and the counter value (for example, “0000000000000001”) are concatenated.
  • the ID certificate table TBL1 is stored in, for example, the memory 22A, and the ID and the type of the certificate to be issued are associated with each other. Examples of certificate types include a server certificate with an expiration date of 10 years, a client certificate with an expiration date of 1 year, a code signing certificate with an expiration date of 10 years, and so on. ing.
  • the server certificate proves that, for example, the access authority to the Web server (not shown) that provides the Web service is authorized.
  • the client certificate certifies that the client device 30 is a legitimate client device when the client device 30 is authenticated by, for example, an authentication server (not shown).
  • the code signing certificate proves that the program code to be verified or authenticated is a legitimate program code, for example.
  • the verification device 20A determines that the verification of the authorization data included in the request from the client device 30 is successful, it is based on the ID constituting the authorization data and the ID certificate table TBL1. Then, the type of the certificate corresponding to the ID is specified. The verification device 20A issues a certificate of the specified type and sends it to the client device 30.
  • FIG. 6 is a sequence diagram showing an example of an operation procedure of the request verification system 1A according to the second embodiment.
  • the same process as that of FIG. 3A or FIG. 3B is given the same step number to simplify or omit the description, and different contents will be described.
  • the verification device 20A has an ID (for example, 20 digits) composed of an ID of the authorization data generation device 10 (for example, a combination of 4-digit alphanumericals) and a counter value (for example, a 16-digit hexadecimal number).
  • ID for example, 20 digits
  • the authorization data generation device 10 for example, a combination of 4-digit alphanumericals
  • a counter value for example, a 16-digit hexadecimal number
  • the authorization data generation device 10 generates a signature SA by encrypting the hash value of the ID sent in step St12 (that is, refer to Hash (ID)) using the private key PRK1 of the authorization data generation device 10 (refer to Hash (ID)). St13).
  • the authorization data generation device 10 generates authorization data TA by concatenating (concatenating) the signature S generated in step St13 with the ID sent in step St12 (St13).
  • the authorization data generation device 10 uses the authorization data TA generated in step St13 with a highly secure communication path (for example, mutually authenticated BLE) formed between the authorization data generation apparatus 10 and the client apparatus 30. Is transmitted to the client device 30 (St4A).
  • the authorization data generation apparatus 10 may send the authorization data TA to the client apparatus 30 (St4A0).
  • the client device 30 forms a highly secure communication path (for example, mutually authenticated BLE) with the verification device 20A.
  • the client device 30 generates a request YA (for example, service provision according to an ID) based on an operation using the user's operation device 31, and requests an authorization data TA sent from the authorization data generation apparatus 10 in step St4A. It is sent to the verification device 20 via the communication path described above (St5A).
  • the verification device 20A extracts and acquires 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 by using the public key of the authorization data generation apparatus 10 included in the certificate CERT1 of the client apparatus 30 stored in step St2 (St14).
  • the verification device 20A calculates a hash value of an ID (see step St11) that constitutes the authorization data TA by using a default 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 and the decrypted data F obtained by decoding are the same (St14).
  • the verification device 20A determines that the verification of the authorization data TA is successful, the verification device 20A issues a certificate (for example, see FIG. 5) corresponding to the ID constituting the authorization data TA in step St14 as a response to the request YA, and also describes the above.
  • the certificate is transmitted to the client device 30 via the highly secure communication path (St15).
  • the verification device 20A generates an ID corresponding 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 (see, for example, a combination of 20-digit alphanumerical characters shown in FIG. 5) as arbitrary data and sends it to the client apparatus 30.
  • the verification device 20A determines that the verification of the received authorization data TA is successful, the verification device 20A 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.
  • the request verification system 1A is generated by the verification device 20A when the verification of the authorization data TA sent from the client device 30 is successful, similar to the effect of the request verification system 1 according to the first embodiment.
  • the service according to the ID can be adaptively provided to the client device 30.
  • the authorization data generation device 10 may generate authorization data TA only once using the same ID.
  • the verification device 20A stores the ID included in the received authorization data TA at each verification, and rejects the verification of the authorization data TA including the same ID as the stored ID.
  • the request verification system 1A generates the authorization data TA for the same ID and verifies the authorization data TA only once. Therefore, it is assumed that a plurality of IDs or authorization data TAs are copied and received a reply attack. However, since the service according to the ID is provided only once, it is possible to suppress the deterioration of security when the service is provided.
  • a plurality of authorization data generation devices 10 may be provided.
  • the verification device 20A generates an ID including the identification information (for example, 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.
  • the request verification system 1A can easily determine which authorization data generation device 10 is the authorization data by determining the ID constituting the authorization data TA at the time of verification by the verification device 20A, and provides the service. You can improve the convenience of time.
  • the verification device 20A may store the authorization data revocation information indicating whether or not the validity of the authorization data TA generated by the authorization data generation device 10 has expired in the memory 22A in association with the ID. In this case, the verification device 20A revokes the validity of the authorization data subject to 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 when the authorization data TA is sent from the authorization data generation apparatus 10 to the client apparatus 30, the verification apparatus 20A can be used from the authorization data generation apparatus 10. Based on the revocation instruction, the validity of the authorization data TA subject to the revocation instruction can be revoked, and the stolen or lost authorization data can be prevented from being misused to improve security. Can be done.
  • the verification device 20A may set an expiration date of the ID and send the ID for which the expiration date has been set to the authorization data generation device 10.
  • the authorization data generation device 10 generates authorization data TA having the same expiration date as the expiration date.
  • the request verification system 1A can reduce the misuse of the authorization data TA by a malicious third party as compared with the case where the request verification system 1A has an indefinite expiration date.
  • the authorization data generation device 10 generates authorization data TA using connection destination information (for example, URL (Uniform Resource Locator), IP address) to the verification device 20A as arbitrary data and sends it to the client apparatus 30.
  • connection destination information for example, URL (Uniform Resource Locator), IP address
  • the client device 30 can easily access the verification device 20A based on the connection destination information included in the authorization data TA even if the destination of the verification device 20A is not known. Therefore, it is possible to omit the preset setting of the connection destination information of the verification device 20A that should access the client device 30 when using the service.
  • the verification device constituting the request verification system receives a request for use of the application acquired from the download server by the client device.
  • the encryption authorization data (see below) included in the request is verified.
  • the verification device determines that the verification is successful, the verification device authorizes the use of the application and returns it to the client device as a response to the request.
  • the verification device sends an error notification to the client device to the effect that the verification has failed.
  • the request verification system can receive a request using the forged authorization data even if the authorization data sent from the authorization data generator to the client device is leaked and the authorization data is forged.
  • Security can be improved by effectively blocking the use of forged authorization data and denying approval of the use of applications associated with the authorization data.
  • FIG. 7 is a diagram showing a system configuration example of the request verification system 1B according to the 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.
  • the same reference numerals are given to those overlapping with the configuration of FIG. 1, and the description is simplified or omitted, and different contents will be described.
  • 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 the configurations of the corresponding devices according to the first embodiment, detailed description thereof will be omitted. ..
  • the authorization data generation device 10, the client device 30, and the download server 40 are communicably connected to each other via the network NW1.
  • the verification device 20 used by the service provider generates the application key APK1 and sends it to, for example, the authorization data generation device 10 used by the application maker.
  • the application key APK1 is composed of, for example, a common key or password of AES and is shared between the authorization data generation device 10 and the verification device 20, and encrypts the application APP1 generated by the authorization data generation device 10. Used to do.
  • the authorization data generation device 10 uploads the data of the application APP1 including the application key APK1 to the download server 40.
  • the authorization data AUTOH1 (see the first embodiment) sent from the authorization data generation device 10 is encrypted with the application key APK1.
  • the encryption authorization data EAUTH1 is generated, and a request including the encryption authorization data EAUTH1 is sent to the verification device 20.
  • the verification device 20 decrypts the encryption authorization data EATH1 with the application key APK1 and acquires the authorization data AUTOH1.
  • the download server 40 is a server computer having a communication function for storing data of one or more applications, and is configured to include a processor such as a CPU, a memory, and a communication device, although detailed hardware configuration is not shown. be.
  • the download server 40 stores application data when it receives an upload request from the authorization data generation device 10.
  • the download server 40 transmits the data of the application specified in the request to the client device 30.
  • 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.
  • the same step numbers are assigned to the same processes as those of FIGS. 3A or 3B to simplify or omit the description, and different contents will be described.
  • the download server 40 holds the application APP1 so that it can be provided, and exemplifies that it is an application store that sells the application.
  • the verification device 20 generates the application key APK1 corresponding to the application to be generated by the authorization data generation device 10 after step St2 (St21).
  • the verification device 20 sends the software library including the application key APK1 generated in step St21 to the authorization data generation device 10 (St22).
  • This software library contains the application key APIK1 (in other words, the application key APIK1 is embedded), and software for bridging the connection to the verification device 20 by calling (calling) this software library during the execution of the application. It is a part (API: Application Programming Interface).
  • the client device 30 generates a request for requesting the transmission of the authorization data T and sends it to the authorization data generation device 10 (St23).
  • the authorization data generation device 10 forms the authorization data T generated in step St3 (see FIG. 3A or FIG. 3B) between the authorization data generation device 10 and the client device 30 in response to a request from the client device 30.
  • the data is transmitted to the client device 30 using a highly secure communication path (for example, mutually authenticated BLE) (St4).
  • 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 (sends) the data of the application APP1 including the software library in which the application key APK1 is embedded to the download server 40 (St25).
  • the client device 30 accesses the download server 40 (for example, an app store) (St26).
  • the download server 40 for example, an app store
  • the client device 30 downloads and acquires the data of the application APP1 including the software library in which the application key APK1 is embedded from the download server 40 (St27). Based on the 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 the encryption authorization data EAUTH1 and inputs it to the software library of the application APP1 for setting. (St28). The client device 30 includes the encryption authorization data EAUTH1 in the request Y for permitting the use of the application APP1 and sends it to the verification device 20 (St5B).
  • the verification device 20 extracts and acquires the encryption authorization data EAUTH1 included in the request Y sent from the client device 30 in step St5B.
  • the verification device 20 decrypts the encryption 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 saved in step St2 ( St6B).
  • the verification device 20 calculates a hash value of arbitrary data D constituting the authorization data T by using a default 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 and the decrypted data F obtained by decoding are the same (St6B).
  • the verification device 20 determines that the verification of the authorization data T is successful, the verification device 20 generates permission information for permitting the use of the application APP1 as a response to the request Y and transmits it to the client device 30 (St7B).
  • the verification device 20 determines that the verification of the authorization data T has failed, the verification device 20 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).
  • the verification device 20 can acquire the application key APK1 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.
  • step St6B Unless the verification is successful in step St6B, the use of authorization data forged by a malicious third party can be effectively blocked, or the application APP1 can be used for purposes other than the application key APK1 associated with the authorization data. Can be rejected (denied) to improve security.
  • the verification device 20 constituting the request verification system 1B receives a request Y for use of the application APP1 acquired by the client device 30 from the download server 40 such as an app store as a client.
  • the encryption authorization data EATH1 included in the request Y is verified.
  • the verification device 20 determines that the verification is successful, the verification device 20 authorizes the use of the application APP1 and returns it to the client device 30 as a response to the request Y.
  • the verification device 20 determines that the verification has failed, the verification device 20 transmits an error notification to the effect that the verification has failed to the client device 30.
  • the request verification system 1B first verifies whether or not the encryption authorization data EATH1 sent from the client device 30 can be appropriately decrypted by the application key APK1, and the authorization data AUTOH1 obtained by the decryption.
  • double verification such as the second verification of whether or not the verification can be performed, it is possible to appropriately determine whether or not the application APP1 can be used from the client device 30 without using the confidential information of the client device 30.
  • the request verification system 1B acquires the application key APK1 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 use of the forged authorization data can be effectively blocked even if a request using the forged authorization data is received, or it is linked to the authorization data. It is possible to improve the security by denying the approval of the use of the application.
  • This disclosure is useful as a request verification system and a request verification method that safely verifies the user's request without leaking the confidential information of the client device and suppresses the security deterioration of the client device.

Abstract

認可データ生成装置は、任意データに任意データの署名を施して認可データを生成し、認可データをクライアント装置に送る。検証装置は、認可データを含むサービス利用のリクエストをクライアント装置から受信すると、認可データを検証し、受信された認可データの検証が成功したと判定すると、リクエストに対応するサービスをクライアント装置に提供し、受信された認可データの検証が失敗したと判定すると、クライアント装置にエラー通知を送る。

Description

リクエスト検証システムおよびリクエスト検証方法
　本開示は、リクエスト検証システムおよびリクエスト検証方法に関する。
　特許文献１には、電子チケット生成装置とアプリケーション装置とを有するアクセス権管理装置が開示されている。電子チケット生成装置は、ユーザが所有するクライアント装置を特定するための特定情報（例えばクライアント装置の秘密情報に基づく情報）を取得し、この特定情報を利用して電子チケットを生成する。アプリケーション装置は、クライアント装置と通信を行い、電子チケットを検査してユーザのアクセス資格を検証する。
日本国特開２００４－３２２２０号公報
　特許文献１の構成では、クライアント装置の秘密情報に基づく特定情報がクライアント装置と電子チケット生成装置との双方において共有され、また、電子チケット生成装置からアプリケーション装置にさらに渡されることになる。このため、特定情報が漏洩するリスクが存在するので、クライアント装置におけるセキュリティの低下が懸念されてしまう。
　本開示は、上述した従来の状況に鑑みて案出され、クライアント装置の秘密情報を漏洩することなくユーザのリクエストを安全に検証し、クライアント装置のセキュリティ低下を抑制するリクエスト検証システムおよびリクエスト検証方法を提供することを目的とする。
　本開示は、サービスの提供を認可する認可データを生成して出力し、公開鍵を含む証明書を保持する認可データ生成装置と、前記認可データ生成装置と前記証明書を共有する検証装置と、提供されるサービスを利用するクライアント装置と、を備え、前記検証装置は、前記クライアント装置から前記認可データの検証リクエストを受けると、前記証明書を用いて前記認可データを検証する、リクエスト検証システムを提供する。
　また、本開示は、サービスの提供を認可する認可データを生成して出力し、公開鍵を含む証明書を保持するステップと、前記証明書を共有するステップと、前記認可データについての検証がリクエストされると、前記証明書を用いて前記認可データを検証するステップと、を有する、リクエスト検証方法を提供する。
　本開示によれば、クライアント装置の秘密情報を漏洩することなくユーザのリクエストを安全に検証でき、クライアント装置のセキュリティ低下を抑制できる。
実施の形態１に係るリクエスト検証システムのシステム構成例を示す図 実施の形態１に係るリクエスト検証システムを構成する各装置のハードウェア構成例を示すブロック図 実施の形態１に係るリクエスト検証システムの動作手順の一例を示すシーケンス図 実施の形態１に係るリクエスト検証システムの動作手順の他の一例を示すシーケンス図 実施の形態２に係るリクエスト検証システムを構成する各装置のハードウェア構成例を示すブロック図 ＩＤに対応して発行される証明書の決定手順の概要例を示す図 実施の形態２に係るリクエスト検証システムの動作手順例を示すシーケンス図 実施の形態３に係るリクエスト検証システムのシステム構成例を示す図 実施の形態３に係るリクエスト検証システムの動作手順例を示すシーケンス図 実施の形態３に係るリクエスト検証システムの動作手順例を示すシーケンス図
　以下、適宜図面を参照しながら、本開示に係るリクエスト検証システムおよびリクエスト検証方法を具体的に開示した実施の形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。なお、添付図面および以下の説明は、当業者が本開示を十分に理解するために提供されるのであって、これらにより特許請求の範囲に記載の主題を限定することは意図されていない。
（実施の形態１）
　実施の形態１に係るリクエスト検証システムでは、リクエスト検証システムを構成する検証装置は、ユーザが希望するリクエスト（例えばクライアント装置の電子証明書の発行およびクライアント装置への送信の各申請）をクライアント装置から受けた際、そのリクエストに含まれる認可データ（後述参照）を検証する。検証装置は、検証が成功したと判定した場合に、そのリクエストに対するレスポンス（例えばクライアント装置の電子証明書の発行およびクライアント装置への送信）をクライアント装置に提供する。検証装置は、検証が失敗したと判定した場合に、検証が失敗した旨のエラー通知をクライアント装置に送信する。
　図１は、実施の形態１に係るリクエスト検証システム１のシステム構成例を示す図である。リクエスト検証システム１は、認可データ生成装置１０と、検証装置２０とを少なくとも含む。リクエスト検証システム１は、クライアント装置３０をさらに含んでもよい。図１ではクライアント装置３０は１台のみ図示されているが、２台以上のクライアント装置３０がネットワークＮＷ１に接続されてよい。認可データ生成装置１０と検証装置２０とクライアント装置３０とは、ネットワークＮＷ１を介して互いに通信可能に接続される。ネットワークＮＷ１は、有線ネットワーク（例えば有線ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ））でもよいし、無線ネットワーク（例えば無線ＬＡＮ）でもよい。
　認可データ生成装置１０は、クライアント装置３０を使用するユーザが希望するリクエスト（上述参照）に対するレスポンス（上述参照）の提供を認可することを示すデータ（以下「認可データ」と称する）を生成し、この認可データをクライアント装置３０に送る。認可データ生成装置１０は、認可データ生成装置１０の秘密鍵ＰＲＫ１を保持しており、任意データＤＴＡ１（例えば乱数）またはＤＴＡ１のハッシュ値を認可データ生成装置１０の秘密鍵ＰＲＫ１で暗号化して生成した署名（「電子署名」と称する場合がある）と任意データＤＴＡ１とを連接することで、認可データＡＵＴＨ１を生成する。なお、認可データ生成装置１０と検証装置２０とは、ハッシュ値を演算するためにそれぞれ使用するハッシュ関数を予め共有している。また、認可データ生成装置１０は、認可データ生成装置１０の公開鍵を含む証明書ＣＥＲＴ１（「電子証明書」と称する場合がある）を保持しており、この証明書ＣＥＲＴ１を検証装置２０との間で共有する。この証明書ＣＥＲＴ１は、後述するＣＡによって認可データ生成装置１０用に生成（発行）されたものであり、ＣＡによって任意データがＣＡの秘密鍵（図示略）を用いて暗号化されて生成された署名（図示略）と、署名の生成に使用された任意データと、ＣＡの公開鍵と、認可データ生成装置１０の公開鍵とを少なくとも含み、認可データ生成装置１０にて保持されている。なお、ＣＡがＣＡの秘密鍵を用いて暗号化する対象となる任意データは、ＣＡが１つ以上の証明書（例えば証明書ＣＥＲＴ１、ＣＡ証明書ＣＡ１）を生成する際に同一のものが使用されている。
　なお、リクエスト検証システム１は複数台の認可データ生成装置１０を含む構成としてもよく、この場合にはクライアント装置３０に付与させたい利用権限を有する証明書ＣＥＲＴ１を有する認可データ生成装置１０を適宜切り替ながら、該当する認可データ生成装置１０からクライアント装置３０に所望の証明書ＣＥＲＴ１を保持させることができる。
　検証装置２０は、クライアント装置３０からのリクエストを受けると、予め認可データ生成装置１０との間で共有された証明書ＣＥＲＴ１に含まれる公開鍵（例えば認可データ生成装置１０の公開鍵）を用いて、そのリクエストに含まれる認可データＡＵＴＨ１（上述参照）を検証する。なお、詳細は後述するが、検証装置２０は、予め後述するＣＡからダウンロードして取得したＣＡ証明書ＣＡ１を用いて、そのリクエストに含まれる認可データＡＵＴＨ１（上述参照）を検証してもよい。これにより、検証装置２０は、認可データ生成装置１０が複数台設けられている場合でも、ＣＡ（認証局）からＣＡ証明書ＣＡ１をダウンロードして取得しておくだけで、複数台の認可データ生成装置１０のそれぞれから予め証明書ＣＥＲＴ１を取得して共有することなく、クライアント装置３０からのリクエストに含まれる認可データの検証を個別かつ簡易に行え、さらに複数の証明書ＣＥＲＴ１を保存することで生じ得るメモリ容量の圧迫を回避できる。
　検証装置２０は、検証が成功したと判定した場合に、上述したリクエストに対するレスポンス（例えばクライアント装置３０の電子証明書の発行およびクライアント装置３０への送信）をクライアント装置３０に提供する。検証装置２０は、検証が失敗したと判定した場合に、検証が失敗した旨のエラー通知をクライアント装置３０に送信する。言い換えると、エラー通知は、クライアント装置３０の電子証明書の発行ができない（つまり、クライアント装置３０にとって所望の利用権限が得られない）ことを意味する。
　なお、検証装置２０は、公的な認証局とも言われるＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）により生成（発行）されたＣＡ証明書ＣＡ１をＣＡからダウンロードすることで取得、保持してもよい。ＣＡ証明書ＣＡ１は、ＣＡによって任意データがＣＡの秘密鍵（図示略）を用いて暗号化されて生成された署名と、署名の生成に使用された任意データと、ＣＡの公開鍵とを少なくとも含む。このＣＡ証明書ＣＡ１は、上述した証明書ＣＥＲＴ１と同一である。なお、ＣＡ証明書ＣＡ１と証明書ＣＥＲＴ１とは異なってもよいが、いずれも同一のＣＡにより生成（発行）された証明書である。
　クライアント装置３０は、リクエスト検証システム１のユーザにより使用され、例えばスマートフォン等のモバイル端末もしくはＩｏＴ（Ｉｎｔｅｒｎｅｔ　ｏｆ　Ｔｈｉｎｇｓ）機器である。なお、クライアント装置３０は、ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）でもよい。認可データ生成装置１０により生成された認可データＡＵＴＨ１を受信して保存する。クライアント装置３０は、認可データＡＵＴＨ１を含むリクエスト（上述参照）を検証装置２０に送る。クライアント装置３０は、そのリクエストを対象とした検証装置２０での検証が成功したと判定された場合、リクエストに対するレスポンス（例えばクライアント装置の電子証明書の発行およびクライアント装置への送信）の提供を検証装置２０から受ける。クライアント装置３０は、そのリクエストを対象とした検証装置２０での検証が失敗したと判定された場合、検証が失敗した旨のエラー通知を検証装置２０から受ける。
　図２は、実施の形態１に係るリクエスト検証システム１を構成する各装置のハードウェア構成例を示すブロック図である。図２に示すリクエスト検証システム１は、認可データ生成装置１０と、検証装置２０と、クライアント装置３０とを含む構成である。
　認可データ生成装置１０は、操作デバイス１１と、メモリ１２と、通信デバイス１３と、プロセッサＰＲＣ１とを含む。
　操作デバイス１１は、認可データ生成装置１０の使用者の操作を受け付けるデバイスであり、例えばマウス、キーボード、タッチパッドおよびタッチパネルのうち少なくとも１つにより構成される。操作デバイス１１は、使用者の操作に基づく信号をプロセッサＰＲＣ１に送る。
　メモリ１２は、例えばＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）とＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）とを含み、認可データ生成装置１０の動作の実行に必要なプログラム、動作中にプロセッサＰＲＣ１により生成されたデータあるいは情報を一時的に格納する。ＲＡＭは、例えばプロセッサＰＲＣ１の動作時に使用されるワークメモリである。ＲＯＭは、例えばプロセッサＰＲＣ１を制御するためのプログラムおよびデータを予め記憶する。なお、メモリ１２は、プロセッサＰＲＣ１により取得あるいは生成されたデータを記憶可能な、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）、フラッシュメモリあるいはＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等のストレージを含む構成としてもよい。
　通信デバイス１３は、ネットワークＮＷ１との間でデータもしくは情報の送受信を行う通信回路を用いて構成され、検証装置２０もしくは１台以上のクライアント装置３０との間でデータもしくは情報の送受信を行う。なお、通信デバイス１３は、検証装置２０もしくは１台以上のクライアント装置３０との間で、相互に認証されたセキュリティの高い通信経路（例えばＢＬＥ：Ｂｌｕｅｔｏｏｔｈ（登録商標）　Ｌｏｗ　Ｅｎｅｒｇｙ）を用いて通信してもよい。
　プロセッサＰＲＣ１は、例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、ＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）およびＧＰＵ（Ｇｒａｐｈｉｃａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）のうち少なくとも１つを用いて構成される。プロセッサＰＲＣ１は、認可データ生成装置１０の各部の動作を制御する。また、プロセッサＰＲＣ１は、操作デバイス１１からの信号に基づいて、認可データ生成装置１０の各部の動作を制御してもよい。プロセッサＰＲＣ１は、認可データ生成装置１０の制御部として機能し、認可データ生成装置１０の各部の動作を全体的に統括するための制御処理、認可データ生成装置１０の各部との間のデータの入出力処理、データの演算（計算）処理およびデータの記憶処理を行う。プロセッサＰＲＣ１は、メモリ１２内のＲＯＭに記憶されたプログラムの実行に従って動作する。プロセッサＰＲＣ１は、上述したプログラムの実行に基づく機能的構成として、秘密鍵管理部１４と、認可データ管理部１５と、公開鍵管理部１６と、任意データ管理部１７と、署名生成部１８とを有する。
　秘密鍵管理部１４は、認可データ生成装置１０の秘密鍵（例えばＲＳＡ暗号の秘密鍵（ｄ，Ｎ）のペア）を生成して保持する。なお、秘密鍵の種類はＲＳＡ暗号に限定されなくてもよい。
　認可データ管理部１５は、署名生成部１８により生成された署名（いわゆる電子署名）を任意データＤＴＡ１に連接（連結）することで認可データＡＵＴＨ１を生成して保持する。例えば、認可データＡＵＴＨ１は次のデータ構造を有する。つまり、［認可データＴ］＝［署名Ｓ］［任意データＤ］となる。ここで、［Ａ］［Ｂ］は、データＡとデータＢとが連接したことを示している。認可データＡＵＴＨ１は、クライアント装置３０ごとに異なるデータ実体を有するように生成される。なお、詳細は図３Ｂを用いて後述するが、［認可データＴ］＝［署名Ｓ］［任意データＤ］［証明書ＣＥＲＴ１］であってもよい。
　公開鍵管理部１６は、認可データ生成装置１０の公開鍵（例えばＲＳＡ暗号の公開鍵（ｅ，Ｎ）のペア）を生成して保持する。なお、公開鍵の種類はＲＳＡ暗号に限定されなくてもよい。また、公開鍵管理部１６は、生成された公開鍵を含む証明書ＣＥＲＴ１（つまり認可データ生成装置１０の電子証明書）を生成して保持する。なお、証明書ＣＥＲＴ１は、図示しない認証局（上述参照、ＣＡ：Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）により発行されたものでも構わない。
　任意データ管理部１７は、認可データＡＵＴＨ１を構成する任意データＤＴＡ１（例えば乱数、もしくはカウンター値）を生成して保持する。ここで、任意データＤＴＡ１は、いわゆるランダム性を有する任意のデータであり、例えばクライアント装置３０の秘密情報（例えばＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）アドレス、ＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレス）とは異なり、乱数等のように秘密性を有さないデータである。
　署名生成部１８は、秘密鍵管理部１４により生成された秘密鍵（例えば（ｅ，Ｎ）のペア）を用いて、任意データ管理部１７により生成された任意データＤＴＡ１を暗号化することで署名を生成して保持する。署名の生成アルゴリズムは、ＲＳＡに限定されず、例えばＥＣＤＳＡでもよい。具体的には、署名生成部１８は、認可データ生成装置１０と検証装置２０との間で既定のハッシュ関数を用いてＨａｓｈ（任意データＤ）を演算する。Ｈａｓｈ（Ａ）はデータＡのハッシュ値（ダイジェスト値）を求める演算子であり、例えばＳＨＡ２あるいはＳＨＡ３である。署名生成部１８は、（Ｈａｓｈ（任意データＤ））ｄｍｏｄＮの演算により署名Ｓを生成する。例えばＲＳＡ暗号の秘密鍵で署名が生成された場合には、この署名は認可データ生成装置１０の公開鍵のみを用いて復号可能となる。
　検証装置２０は、操作デバイス２１と、メモリ２２と、通信デバイス２３と、プロセッサＰＲＣ２とを含む。
　操作デバイス２１は、検証装置２０の使用者の操作を受け付けるデバイスであり、例えばマウス、キーボード、タッチパッドおよびタッチパネルのうち少なくとも１つにより構成される。操作デバイス２１は、使用者の操作に基づく信号をプロセッサＰＲＣ２に送る。
　メモリ２２は、例えばＲＡＭとＲＯＭとを含み、検証装置２０の動作の実行に必要なプログラム、動作中にプロセッサＰＲＣ２により生成されたデータあるいは情報を一時的に格納する。ＲＡＭは、例えばプロセッサＰＲＣ２の動作時に使用されるワークメモリである。ＲＯＭは、例えばプロセッサＰＲＣ２を制御するためのプログラムおよびデータを予め記憶する。なお、メモリ２２は、プロセッサＰＲＣ２により取得あるいは生成されたデータを記憶可能な、ＨＤＤ、フラッシュメモリあるいはＳＳＤ等のストレージを含む構成としてもよい。
　通信デバイス２３は、ネットワークＮＷ１との間でデータもしくは情報の送受信を行う通信回路を用いて構成され、認可データ生成装置１０もしくは１台以上のクライアント装置３０との間でデータもしくは情報の送受信を行う。なお、通信デバイス２３は、認可データ生成装置１０もしくは１台以上のクライアント装置３０との間で、相互に認証されたセキュリティの高い通信経路（例えばＢＬＥ）を用いて通信してもよい。
　プロセッサＰＲＣ２は、例えばＣＰＵ、ＤＳＰ、ＦＰＧＡおよびＧＰＵのうち少なくとも１つを用いて構成される。プロセッサＰＲＣ２は、検証装置２０の各部の動作を制御する。また、プロセッサＰＲＣ２は、操作デバイス２１からの信号に基づいて、検証装置２０の各部の動作を制御してもよい。プロセッサＰＲＣ２は、検証装置２０の制御部として機能し、検証装置２０の各部の動作を全体的に統括するための制御処理、検証装置２０の各部との間のデータの入出力処理、データの演算（計算）処理およびデータの記憶処理を行う。プロセッサＰＲＣ２は、メモリ２２内のＲＯＭに記憶されたプログラムの実行に従って動作する。プロセッサＰＲＣ２は、上述したプログラムの実行に基づく機能的構成として、署名検証部２４と、公開鍵管理部２５とを有する。
　署名検証部２４は、公開鍵管理部２５により保持されている証明書ＣＥＲＴ１（つまり認可データ生成装置１０の電子証明書）に含まれる公開鍵（つまり認可データ生成装置１０の公開鍵）を用いて、クライアント装置３０からのリクエストに含まれる認可データＴの検証を行う。具体的には、署名検証部２４は、クライアント装置３０からの認可データＴ（例えば［署名Ｓ］［任意データＤ］）を取得すると、公開鍵（ｅ，Ｎ）のペアを用いて署名Ｓを復号する。例えば署名検証部２４は、（署名Ｓ）ｅｍｏｄＮの演算により復号データＦを取得するとともに、認可データ生成装置１０と検証装置２０との間で既定のハッシュ関数を用いて認可データＴを構成する任意データＤのハッシュ値（Ｈａｓｈ（任意データＤ））を演算する。署名検証部２４は、任意データＤのハッシュ値と復号データＦとが同一であるか否かにより、クライアント装置３０からのリクエストに含まれる認可データＴの検証を行う。署名検証部２４は、任意データＤのハッシュ値と復号データＦとが同一であると判定した場合に検証が成功したと判定し、任意データＤのハッシュ値と復号データＦとが同一でないと判定した場合に検証が失敗したと判定する。
　署名検証部２４は、検証が成功したと判定した場合に、上述したリクエストに対するレスポンス（例えばクライアント装置３０の電子証明書の発行およびクライアント装置３０への送信）の認可を指示する。プロセッサＰＲＣ２は、この指示に基づいて、例えばクライアント装置３０の電子証明書を発行（生成）し、通信デバイス２３を介してクライアント装置３０に提供（送信）する。また、署名検証部２４は、検証が失敗したと判定した場合に、検証が失敗した旨のエラー通知を、通信デバイス２３を介してクライアント装置３０に送信する。
　公開鍵管理部２５は、認可データ生成装置１０から共有されるために送られた証明書（つまり認可データ生成装置１０の電子証明書）、あるいはＣＡ（上述参照）から予めダウンロードしたＣＡ証明書ＣＡ１（図３Ｂ参照）を取得して保持する。なお、上述したように、この認可データ生成装置１０から共有されるために送られた証明書には、ＣＡにより生成された署名と、ＣＡの公開鍵と、認可データ生成装置１０の公開鍵（例えば（ｅ，Ｎ）のペア）とが少なくとも含まれている。また、上述したように、ＣＡから予めダウンロードしたＣＡ証明書ＣＡ１には、ＣＡにより生成された署名と、ＣＡの公開鍵とが少なくとも含まれている。
　クライアント装置３０は、操作デバイス３１と、メモリ３２と、通信デバイス３３と、プロセッサＰＲＣ３とを含む。
　操作デバイス３１は、クライアント装置３０の使用者の操作を受け付けるデバイスであり、例えばマウス、キーボード、タッチパッドおよびタッチパネルのうち少なくとも１つにより構成される。操作デバイス３１は、使用者の操作に基づく信号をプロセッサＰＲＣ３に送る。なお、操作デバイス３１は、クライアント装置３０の構成から省略されてもよい。
　メモリ３２は、例えばＲＡＭとＲＯＭとを含み、クライアント装置３０の動作の実行に必要なプログラム、動作中にプロセッサＰＲＣ３により生成されたデータあるいは情報を一時的に格納する。ＲＡＭは、例えばプロセッサＰＲＣ３の動作時に使用されるワークメモリである。ＲＯＭは、例えばプロセッサＰＲＣ３を制御するためのプログラムおよびデータを予め記憶する。なお、メモリ３２は、プロセッサＰＲＣ３により取得あるいは生成されたデータを記憶可能な、ＨＤＤ、フラッシュメモリあるいはＳＳＤ等のストレージを含む構成としてもよい。
　通信デバイス３３は、ネットワークＮＷ１との間でデータもしくは情報の送受信を行う通信回路を用いて構成され、認可データ生成装置１０もしくは検証装置２０との間でデータもしくは情報の送受信を行う。なお、通信デバイス３３は、認可データ生成装置１０もしくは検証装置２０との間で、相互に認証されたセキュリティの高い通信経路（例えばＢＬＥ）を用いて通信してもよい。
　プロセッサＰＲＣ３は、例えばＣＰＵ、ＤＳＰ、ＦＰＧＡおよびＧＰＵのうち少なくとも１つを用いて構成される。プロセッサＰＲＣ３は、クライアント装置３０の各部の動作を制御する。また、プロセッサＰＲＣ３は、操作デバイス３１からの信号に基づいて、クライアント装置３０の各部の動作を制御してもよい。プロセッサＰＲＣ３は、クライアント装置３０の制御部として機能し、クライアント装置３０の各部の動作を全体的に統括するための制御処理、クライアント装置３０の各部との間のデータの入出力処理、データの演算（計算）処理およびデータの記憶処理を行う。プロセッサＰＲＣ３は、メモリ３２内のＲＯＭに記憶されたプログラムの実行に従って動作する。プロセッサＰＲＣ３は、上述したプログラムの実行に基づく機能的構成として、認可データ管理部３４を有する。
　認可データ管理部３４は、認可データ生成装置１０から送られた認可データＴ（上述参照）を、通信デバイス３３を介して取得して保持する。
　次に、実施の形態１に係るリクエスト検証システム１の動作手順について、図３Ａおよび図３Ｂを参照して説明する。図３Ａは、実施の形態１に係るリクエスト検証システム１の動作手順の一例を示すシーケンス図である。図３Ｂは、実施の形態１に係るリクエスト検証システム１の動作手順の他の一例を示すシーケンス図である。図３Ａおよび図３Ｂの説明において、任意データＤＴＡ１を「任意データＤ」と称し、認可データＡＵＴＨ１を「認可データＴ」と称する。なお、図３Ｂの説明において、図３Ａと重複する処理については同一のステップ番号を付与して説明を簡略化あるいは省略し、異なる内容について説明する。
　図３Ａにおいて、認可データ生成装置１０は、認可データ生成装置１０の証明書ＣＥＲＴ１および秘密鍵ＰＲＫ１のそれぞれを保持しており、認可データ生成装置１０の証明書ＣＥＲＴ１を共有するために検証装置２０に送る（Ｓｔ１）。検証装置２０は、ステップＳｔ１で認可データ生成装置１０から送られた認可データ生成装置１０の証明書ＣＥＲＴ１を受信して保存する（Ｓｔ２）。
　認可データ生成装置１０は、例えば乱数等の任意データＤを生成してハッシュ値（つまりＨａｓｈ（任意データＤ））を、認可データ生成装置１０の秘密鍵ＰＲＫ１を用いて暗号化することで署名Ｓを生成する（Ｓｔ３）。認可データ生成装置１０は、生成された署名Ｓを任意データＤに連接（連結）することで認可データＴを生成する（Ｓｔ３）。なお、署名Ｓと任意データＤとの連接（連結）の順序は限定されなくてよい。認可データ生成装置１０は、ステップＳｔ３で生成された認可データＴを、認可データ生成装置１０とクライアント装置３０との間で形成されたセキュリティの高い通信路（例えば相互に認証されたＢＬＥ）を用いてクライアント装置３０に送信する（Ｓｔ４）。
　クライアント装置３０は、検証装置２０との間でセキュリティの高い通信路（例えば相互に認証されたＢＬＥ）を形成する。クライアント装置３０は、例えばユーザの操作デバイス３１を用いた操作に基づくリクエストＹ（例えばクライアント装置３０の証明書の発行およびクライアント装置３０への送信の各申請）を生成し、ステップＳｔ４で認可データ生成装置１０から送られた認可データＴをリクエストＹに含んで上述した通信路を介して検証装置２０に送る（Ｓｔ５）。
　検証装置２０は、ステップＳｔ５でクライアント装置３０から送られたリクエストＹに含まれる認可データＴを抽出して取得する。検証装置２０は、認可データＴを構成する署名Ｓを、ステップＳｔ２で保存されたクライアント装置３０の証明書ＣＥＲＴ１に含まれる認可データ生成装置１０の公開鍵を用いて復号する（Ｓｔ６）。検証装置２０は、認可データ生成装置１０と検証装置２０との間で既定のハッシュ関数を用いて認可データＴを構成する任意データＤのハッシュ値を演算する。検証装置２０は、ハッシュ値と復号により得られた復号データＦとが同一か否かに応じて、認可データＴの検証が成功か失敗かを判定する（Ｓｔ６）。
　検証装置２０は、認可データＴの検証が成功したと判定した場合、リクエストＹに対するレスポンスとして、クライアント装置３０の電子証明書を発行するとともに上述したセキュリティの高い通信路を経てクライアント装置３０に送信する（Ｓｔ７）。なお、ここではリクエストがクライアント装置３０の証明書の発行およびクライアント装置３０への送信の各申請であり、レスポンスがクライアント装置３０の証明書の発行およびクライアント装置３０への送信である例を説明したが、リクエストおよびレスポンスの例はこれらに限定されなくてよい。例えば、リクエストが検証装置２０あるいはファイル管理サーバ（図示略）へのデータファイルへのアクセスあるいはそのアクセスの権限の付与の申請であり、レスポンスが検証装置２０あるいはファイル管理サーバ（図示略）へのデータファイルへのアクセスあるいはそのアクセスの権限を付与することであってもよい。一方、検証装置２０は、認可データＴの検証が失敗したと判定した場合、認可データＴの検証が失敗した旨のエラー通知を生成し、上述したセキュリティの高い通信路を経てクライアント装置３０に送信する（Ｓｔ７）。
　また、図３Ｂにおいて、検証装置２０は、ＣＡ（認証局）からＣＡ証明書ＣＡ１を予めダウンロードして取得し（Ｓｔ０）、メモリ２２に保存しておく（Ｓｔ２Ａ）。なお、検証装置２０は、ＣＡ（認証局）からＣＡ証明書ＣＡ１を予めダウンロードするのではなく、認可データ生成装置１０がＣＡ証明書ＣＡ１を保持している場合に認可データ生成装置１０からＣＡ証明書ＣＡ１を取得してメモリ２２に保存してもよい。
　認可データ生成装置１０は、例えば乱数等の任意データＤを生成してハッシュ値（つまりＨａｓｈ（任意データＤ））を、認可データ生成装置１０の秘密鍵ＰＲＫ１を用いて暗号化することで署名Ｓを生成する（Ｓｔ３Ａ）。認可データ生成装置１０は、生成された署名Ｓと任意データＤとＣＡ（認証局）から認可データ生成装置１０用に生成された証明書ＣＥＲＴ１とを連接（連結）することで認可データＴを生成する（Ｓｔ３Ａ）。なお、署名Ｓと任意データＤと証明書ＣＥＲＴ１との連接（連結）の順序は限定されなくてよい。
　検証装置２０は、ステップＳｔ５でクライアント装置３０から送られたリクエストＹに含まれる認可データＴを抽出して取得する（Ｓｔ６－１）。検証装置２０は、ステップＳｔ２Ａで保存されたＣＡ証明書ＣＡ１を用いて、ステップＳｔ６－１で取得された認可データＴを構成する証明書ＣＥＲＴ１がＣＡ（認証局）によって生成（発行）された証明書であるか否かを検証する（Ｓｔ６－１）。例えば、検証装置２０は、ＣＡ証明書ＣＡ１に含まれるＣＡの公開鍵を用いてＣＡ証明書ＣＡ１に含まれる署名を復号し、ＣＡ証明書ＣＡ１に含まれる任意データのハッシュ値（但し、ハッシュ関数はＣＡ（認証局）、認可データ生成装置１０、検証装置２０において既知）の演算結果と上述した署名の復号結果とが同一であるか否かを判定する。検証装置２０は、ハッシュ値の演算結果と、上述した署名の復号結果とが同一であると判定した場合に、ステップＳｔ６－１で取得された認可データＴを構成する証明書ＣＥＲＴ１がＣＡ（認証局）によって生成（発行）された証明書であると判定する（Ｓｔ６－１）。
　さらに、検証装置２０は、ステップＳｔ６－１の検証が成功した場合（つまりハッシュ値の演算結果と上述した署名の復号結果とが同一であると判定した場合）に、ステップＳｔ５でクライアント装置３０から送られた認可データＴを構成する署名Ｓを、ステップＳｔ５でクライアント装置３０から送られた証明書ＣＥＲＴ１に含まれる認可データ生成装置１０の公開鍵を用いて復号する（Ｓｔ６－２）。検証装置２０は、認可データ生成装置１０と検証装置２０との間で既定のハッシュ関数を用いて認可データＴを構成する任意データＤのハッシュ値を演算する。検証装置２０は、ハッシュ値と復号により得られた復号データＦとが同一か否かに応じて、認可データＴの検証が成功か失敗かを判定する（Ｓｔ６－２）。このように、検証装置２０は、ステップＳｔ６－１およびステップＳｔ６－２の２段階検証によって、ステップＳｔ５でクライアント装置３０から送られたリクエストに対するレスポンスの提供可否を判定してもよい。これにより、検証装置２０は、例えば認可データ生成装置１０が複数台設けられている場合でも、ＣＡ（認証局）からＣＡ証明書ＣＡ１をダウンロードして取得しておくだけで、複数台の認可データ生成装置１０のそれぞれから予め証明書ＣＥＲＴ１を取得して共有することなく、クライアント装置３０からのリクエストに含まれる認可データの検証を個別かつ簡易に行え、さらに複数の証明書ＣＥＲＴ１を保存することで生じ得るメモリ容量の圧迫を回避できる。
　以上により、実施の形態１に係るリクエスト検証システム１では、認可データ生成装置１０と検証装置２０とが互いに通信可能に接続される。認可データ生成装置１０は、任意データＤＴＡ１に任意データＤＴＡ１の署名を施して認可データＡＵＴＨ１を生成し、認可データＡＵＴＨ１をクライアント装置３０に送る。検証装置２０は、認可データＡＵＴＨ１を含むサービス利用のリクエストをクライアント装置３０から受信すると、認可データＡＵＴＨ１を検証する。検証装置２０は、受信された認可データＡＵＴＨ１の検証が成功したと判定するとリクエストに対応するサービスをクライアント装置３０に提供し、受信された認可データＡＵＴＨ１の検証が失敗したと判定するとクライアント装置３０にエラー通知を送る。
　つまり、リクエスト検証システム１では、上述した特許文献１とは異なり、クライアント装置３０の秘密情報が認可データ生成装置１０から検証装置２０には共有されることがなくなる。また、認可データＡＵＴＨ１は、クライアント装置３０の秘密情報を含むように生成されることが無く、あくまで秘密性を有さない乱数もしくはカウンター値等に基づいて生成される。これにより、リクエスト検証システム１は、クライアント装置３０の秘密情報を通信路において漏洩することなく、クライアント装置３０からのユーザのリクエストを安全に検証でき、クライアント装置３０のセキュリティ低下を抑制できる。
　また、認可データ生成装置１０は、認可データ生成装置１０の公開鍵を含む電子証明書（例えば証明書ＣＥＲＴ１）を検証装置２０との間で共有する。検証装置２０は、共有された電子証明書に含まれる公開鍵を用いて、リクエストに含まれる認可データＡＵＴＨ１を検証する。これにより、リクエスト検証システム１は、ＰＫＩ（公開鍵暗号基盤）を用いて、認可データ生成装置１０とクライアント装置３０との間、ならびに、クライアント装置３０と検証装置２０との間のそれぞれで認可データＡＵＴＨ１の送受信を安全に実行できる。
　また、認可データ生成装置１０は、認可データ生成装置１０の秘密鍵で任意データＤＴＡ１を暗号化して署名を生成する。検証装置２０は、受信された認可データＡＵＴＨ１に含まれる署名を公開鍵で復号したデータと、認可データＡＵＴＨ１に含まれる任意データＤＴＡ１に基づくデータ（例えば任意データのハッシュ値）とが同一か否かに応じて、認可データＡＵＴＨ１の検証の成否を判定する。これにより、リクエスト検証システム１は、クライアント装置３０からのリクエストの検証を安全かつ簡易に行える。
（実施の形態２）
　実施の形態２に係るリクエスト検証システムでは、リクエスト検証システムを構成する検証装置は、クライアント装置に応じたＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を生成して認可データ生成装置に送る。認可データ生成装置は、検証装置から送られたクライアント装置に応じたＩＤを任意データとして用いて認可データを生成する。検証装置は、クライアント装置からのリクエストに含まれる認可データの検証が成功したと判定すると、認可データに含まれるＩＤに応じたサービスを特定してクライアント装置に提供する。
　図４は、実施の形態２に係るリクエスト検証システム１Ａを構成する各装置のハードウェア構成例を示すブロック図である。図４に示すリクエスト検証システム１Ａは、認可データ生成装置１０と、検証装置２０Ａと、クライアント装置３０とを含む構成である。図４の説明において、図２の構成と重複するものには同一の符号を付与して説明を簡略化あるいは省略し、異なる内容について説明する。
　検証装置２０Ａは、操作デバイス２１と、メモリ２２と、通信デバイス２３と、プロセッサＰＲＣ２Ａとを含む。
　プロセッサＰＲＣ２Ａは、例えばＣＰＵ、ＤＳＰ、ＦＰＧＡおよびＧＰＵのうち少なくとも１つを用いて構成される。プロセッサＰＲＣ２Ａは、検証装置２０Ａの各部の動作を制御する。また、プロセッサＰＲＣ２Ａは、操作デバイス２１からの信号に基づいて、検証装置２０Ａの各部の動作を制御してもよい。プロセッサＰＲＣ２Ａは、検証装置２０Ａの制御部として機能し、検証装置２０Ａの各部の動作を全体的に統括するための制御処理、検証装置２０Ａの各部との間のデータの入出力処理、データの演算（計算）処理およびデータの記憶処理を行う。プロセッサＰＲＣ２Ａは、メモリ２２内のＲＯＭに記憶されたプログラムの実行に従って動作する。プロセッサＰＲＣ２Ａは、上述したプログラムの実行に基づく機能的構成として、署名検証部２４と、公開鍵管理部２５と、ＩＤ生成部２６とを有する。
　メモリ２２Ａは、例えばＲＡＭとＲＯＭとを含み、検証装置２０Ａの動作の実行に必要なプログラム、動作中にプロセッサＰＲＣ２Ａにより生成されたデータあるいは情報を一時的に格納する。ＲＡＭは、例えばプロセッサＰＲＣ２Ａの動作時に使用されるワークメモリである。ＲＯＭは、例えばプロセッサＰＲＣ２Ａを制御するためのプログラムおよびデータを予め記憶する。なお、メモリ２２Ａは、プロセッサＰＲＣ２Ａにより取得あるいは生成されたデータを記憶可能な、ＨＤＤ、フラッシュメモリあるいはＳＳＤ等のストレージを含む構成としてもよい。また、メモリ２２Ａは、認可データ生成装置１０のＩＤ（例えば４桁の英数字の組み合わせ）、ＩＤの生成の度にインクリメントされるカウンタ（例えばプロセッサＰＲＣ２に内蔵）が出力するカウンター値（例えば１６桁の１６進数）、ＩＤ証明書テーブルＴＢＬ１（図５参照）のデータをそれぞれ記憶している。
　ＩＤ生成部２６は、認可データ生成装置１０のＩＤ（例えば４桁の英数字の組み合わせ）とカウンター値（例えば１６桁の１６進数）とをメモリ２２Ａから読み出し、認可データ生成装置１０のＩＤとカウンター値とからなるＩＤ（例えば２０桁の英数字の組み合わせ）を生成して保持する。
　図５は、ＩＤに対応して発行される証明書の決定手順の概要例を示す図である。図５に示すように、ＩＤ生成部２６は、認可データ生成装置１０のＩＤ（例えば「０１ＡＢ」）とカウンター値（例えば「０００００００００００００００１」）とを連接したＩＤを生成する。ＩＤ証明書テーブルＴＢＬ１は、例えばメモリ２２Ａに記憶されており、ＩＤと発行する証明書の種別とが対応付けられている。証明書の種別は、例えば有効期限が１０年間であるサーバ証明書と、有効期限が１年間であるクライアント証明書と、有効期限が１０年間であるコードサイニング証明書と、…とが例示されている。
　サーバ証明書は、例えばＷｅｂサービスを提供しているＷｅｂサーバ（図示略）へのアクセス権限が認可されたことを証明する。クライアント証明書は、例えば認証サーバ（図示略）にクライアント装置３０が認証される際に正当なクライアント装置であることを証明する。コードサイニング証明書は、例えば検証もしくは認証の対象となるプログラムコードが正当なプログラムコードであることを証明する。
　検証装置２０Ａ（例えば署名検証部２４）は、クライアント装置３０からのリクエストに含まれる認可データの検証が成功したと判定した場合に、その認可データを構成するＩＤとＩＤ証明書テーブルＴＢＬ１とに基づいて、そのＩＤに対応する証明書の種別を特定する。検証装置２０Ａは、その特定された種別の証明書を発行してクライアント装置３０に送る。
　次に、実施の形態２に係るリクエスト検証システム１Ａの動作手順について、図６を参照して説明する。図６は、実施の形態２に係るリクエスト検証システム１Ａの動作手順例を示すシーケンス図である。図６の説明において、図３Ａあるいは図３Ｂの処理と同一のものには同一のステップ番号を付与して説明を簡略化あるいは省略し、異なる内容について説明する。
　図６において、検証装置２０Ａは、ステップＳｔ２の後、認可データ生成装置１０のＩＤ（例えば４桁の英数字の組み合わせ）とカウンター値（例えば１６桁の１６進数）とからなるＩＤ（例えば２０桁の英数字の組み合わせ）を生成し（Ｓｔ１１）、その生成されたＩＤを認可データ生成装置１０に送る（Ｓｔ１２）。
　認可データ生成装置１０は、ステップＳｔ１２で送られたＩＤのハッシュ値（つまりＨａｓｈ（ＩＤ）参照）を、認可データ生成装置１０の秘密鍵ＰＲＫ１を用いて暗号化することで署名ＳＡを生成する（Ｓｔ１３）。認可データ生成装置１０は、ステップＳｔ１２で送られたＩＤに、ステップＳｔ１３で生成された署名Ｓを連接（連結）することで認可データＴＡを生成する（Ｓｔ１３）。認可データ生成装置１０は、ステップＳｔ１３で生成された認可データＴＡを、認可データ生成装置１０とクライアント装置３０との間で形成されたセキュリティの高い通信路（例えば相互に認証されたＢＬＥ）を用いてクライアント装置３０に送信する（Ｓｔ４Ａ）。なお、クライアント装置３０からの認可データＴＡの送信のリクエストがあった場合に、認可データ生成装置１０は、認可データＴＡをクライアント装置３０に送ってもよい（Ｓｔ４Ａ０）。
　クライアント装置３０は、検証装置２０Ａとの間でセキュリティの高い通信路（例えば相互に認証されたＢＬＥ）を形成する。クライアント装置３０は、例えばユーザの操作デバイス３１を用いた操作に基づくリクエストＹＡ（例えばＩＤに応じたサービス提供）を生成し、ステップＳｔ４Ａで認可データ生成装置１０から送られた認可データＴＡをリクエストＹＡに含んで上述した通信路を介して検証装置２０に送る（Ｓｔ５Ａ）。
　検証装置２０Ａは、ステップＳｔ５Ａでクライアント装置３０から送られたリクエストＹＡに含まれる認可データＴＡを抽出して取得する。検証装置２０Ａは、認可データＴＡを構成する署名ＳＡを、ステップＳｔ２で保存されたクライアント装置３０の証明書ＣＥＲＴ１に含まれる認可データ生成装置１０の公開鍵を用いて復号する（Ｓｔ１４）。検証装置２０Ａは、認可データ生成装置１０と検証装置２０Ａとの間で既定のハッシュ関数を用いて認可データＴＡを構成するＩＤ（ステップＳｔ１１参照）のハッシュ値を演算する。検証装置２０Ａは、ハッシュ値と復号により得られた復号データＦとが同一か否かに応じて、認可データＴＡの検証が成功か失敗かを判定する（Ｓｔ１４）。
　検証装置２０Ａは、認可データＴＡの検証が成功したと判定した場合、リクエストＹＡに対するレスポンスとして、ステップＳｔ１４で認可データＴＡを構成するＩＤに応じた証明書（例えば図５参照）を発行するとともに上述したセキュリティの高い通信路を経てその証明書をクライアント装置３０に送信する（Ｓｔ１５）。
　以上により、実施の形態２に係るリクエスト検証システム１Ａでは、検証装置２０Ａは、クライアント装置３０に応じたＩＤを生成して認可データ生成装置１０に送る。認可データ生成装置１０は、任意データとしてＩＤ（例えば図５に示す２０桁の英数字の組み合わせ参照）を用いて認可データＴＡを生成してクライアント装置３０に送る。検証装置２０Ａは、受信された認可データＴＡの検証が成功したと判定すると、受信された認可データＴＡに含まれるＩＤに応じたサービス（例えば証明書の発行）をクライアント装置３０に提供する。これにより、リクエスト検証システム１Ａは、実施の形態１に係るリクエスト検証システム１による効果と同様に、クライアント装置３０から送られた認可データＴＡの検証が成功した場合に、検証装置２０Ａにより生成されたＩＤに応じたサービスを適応的にクライアント装置３０に提供できる。
　また、認可データ生成装置１０は、同一のＩＤを用いて１回のみ認可データＴＡを生成してもよい。この場合、検証装置２０Ａは、受信された認可データＴＡに含まれるＩＤを検証の度に記憶し、記憶されているＩＤと同一のＩＤを含む認可データＴＡの検証を拒否する。これにより、リクエスト検証システム１Ａは、同一のＩＤに対する認可データＴＡの生成ならびにその認可データＴＡの検証は一回しか行わないので、ＩＤあるいは認可データＴＡが複数個コピーされてリプライ攻撃を受けたとしても、ＩＤに応じたサービスの提供は一度しか行わないのでサービス提供時のセキュリティ低下を抑制できる。
　また、リクエスト検証システム１Ａでは、認可データ生成装置１０は複数設けられてよい。検証装置２０Ａは、認可データ生成装置１０の識別情報（例えば製造番号）を含んでＩＤを生成し、生成されたＩＤを識別情報に対応する認可データ生成装置１０に送信する。これにより、リクエスト検証システム１Ａは、検証装置２０Ａが検証時に認可データＴＡを構成するＩＤを判別することでどの認可データ生成装置１０によって生成された認可データであるかを簡単に判定でき、サービス提供時の利便性を向上できる。
　また、検証装置２０Ａは、認可データ生成装置１０により生成された認可データＴＡの有効性が失効したか否かを示す認可データ失効情報をＩＤに紐付けてメモリ２２Ａに記憶してもよい。この場合、検証装置２０Ａは、認可データ生成装置１０からの失効指示に基づいて、失効指示の対象となった認可データの有効性を失効処理する。これにより、仮に認可データ生成装置１０からクライアント装置３０に認可データＴＡが送られている際に悪意ある第三者によって盗まれたもしくは紛失した場合でも、検証装置２０Ａは、認可データ生成装置１０からの失効指示に基づいて、その失効指示の対象となった認可データＴＡの有効性を失効処理できて、その盗まれたもしくは紛失した認可データの悪用を防ぐことができてセキュリティの向上を図ることができる。
　また、検証装置２０Ａは、ＩＤの有効期限を設定し、有効期限が設定されたＩＤを認可データ生成装置１０に送ってもよい。この場合、認可データ生成装置１０は、有効期限と同一の有効期限を有する認可データＴＡを生成する。これにより、リクエスト検証システム１Ａは、徒に無期限の有効期限を有する場合に比べて、悪意ある第三者による認可データＴＡの悪用を低減できる。
　また、認可データ生成装置１０は、任意データとして検証装置２０Ａへの接続先情報（例えばＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）、ＩＰアドレス）を用いて認可データＴＡを生成してクライアント装置３０に送る。これにより、クライアント装置３０は、たとえ検証装置２０Ａの宛先を知らなかった場合でも認可データＴＡに含まれる接続先情報に基づいて、簡単に検証装置２０Ａにアクセス可能となる。したがって、クライアント装置３０にサービス利用時にアクセスするべき検証装置２０Ａの接続先情報の事前設定を省くことができる。
（実施の形態３）
　実施の形態３に係るリクエスト検証システムでは、実施の形態１もしくは実施の形態２のさらなる応用例として、リクエスト検証システムを構成する検証装置は、クライアント装置がダウンロードサーバから取得したアプリケーションの使用のリクエストをクライアント装置から受けた際、そのリクエストに含まれる暗号化認可データ（後述参照）を検証する。検証装置は、検証が成功したと判定した場合に、そのリクエストに対するレスポンスとして、アプリケーションの使用を認可してクライアント装置に返送する。検証装置は、検証が失敗したと判定した場合に、検証が失敗した旨のエラー通知をクライアント装置に送信する。これにより、リクエスト検証システムは、認可データ生成装置からクライアント装置に送られた認可データが万が一漏洩して認可データが偽造された場合でも、その偽造された認可データを用いたリクエストを受けてもその偽造された認可データの使用を効果的にブロックできたりその認可データに紐づくアプリケーションの使用の承認を否認できたりしてセキュリティの向上を図ることができる。
　図７は、実施の形態３に係るリクエスト検証システム１Ｂのシステム構成例を示す図である。リクエスト検証システム１Ｂは、認可データ生成装置１０と、検証装置２０と、クライアント装置３０と、ダウンロードサーバ４０とを含む。図７の説明において、図１の構成と重複するものには同一の符号を付与して説明を簡略化あるいは省略し、異なる内容について説明する。また、実施の形態３に係る認可データ生成装置１０、検証装置２０およびクライアント装置３０のハードウェア構成は実施の形態１に係るそれぞれの対応装置の構成と同一であるため、詳細な説明は省略する。図７ではクライアント装置３０は１台のみ図示されているが、２台以上のクライアント装置３０がネットワークＮＷ１に接続されてよい。認可データ生成装置１０とクライアント装置３０とダウンロードサーバ４０とは、ネットワークＮＷ１を介して互いに通信可能に接続される。
　実施の形態３では、サービスを提供する業者で使用される検証装置２０は、アプリケーション鍵ＡＰＫ１を生成し、例えばアプリケーションメーカで使用される認可データ生成装置１０に送る。アプリケーション鍵ＡＰＫ１は、例えばＡＥＳの共通鍵あるいはパスワードにより構成され、認可データ生成装置１０と検証装置２０との間で共有されるものであり、認可データ生成装置１０により生成されるアプリケーションＡＰＰ１を暗号化するために使用される。認可データ生成装置１０は、アプリケーションＡＰＰ１が生成されると、アプリケーション鍵ＡＰＫ１を含むアプリケーションＡＰＰ１のデータをダウンロードサーバ４０にアップロードする。クライアント装置３０は、ダウンロードサーバ４０からアプリケーション鍵ＡＰＫ１を含むアプリケーションＡＰＰ１のデータをダウンロードすると、認可データ生成装置１０から送られた認可データＡＵＴＨ１（実施の形態１参照）をアプリケーション鍵ＡＰＫ１で暗号化した暗号化認可データＥＡＵＴＨ１を生成し、この暗号化認可データＥＡＵＴＨ１を含むリクエストを検証装置２０に送る。検証装置２０は、暗号化認可データＥＡＵＴＨ１をアプリケーション鍵ＡＰＫ１で復号して認可データＡＵＴＨ１を取得する。
　ダウンロードサーバ４０は、１つ以上のアプリケーションのデータを格納している通信機能を有するサーバコンピュータであり、詳細なハードウェア構成の図示は省略するがＣＰＵ等のプロセッサ、メモリおよび通信デバイスを含む構成である。ダウンロードサーバ４０は、認可データ生成装置１０からのアップロードのリクエストを受けるとアプリケーションのデータを格納する。ダウンロードサーバ４０は、クライアント装置３０からのダウンロードのリクエストを受けるとリクエストで指定されているアプリケーションのデータをクライアント装置３０に送信する。
　次に、実施の形態３に係るリクエスト検証システム１Ｂの動作手順について、図８および図９を参照して説明する。図８および図９は、実施の形態３に係るリクエスト検証システム１Ｂの動作手順例を示すシーケンス図である。図８および図９の説明において、図３Ａあるいは図３Ｂの処理と同一のものには同一のステップ番号を付与して説明を簡略化あるいは省略し、異なる内容について説明する。図８および図９では、ダウンロードサーバ４０は、アプリケーションＡＰＰ１を提供可能に保持しており、アプリケーションを販売するアプリストアであると例示して説明する。
　図８において、検証装置２０は、ステップＳｔ２の後、認可データ生成装置１０により生成される予定のアプリケーションに対応するアプリケーション鍵ＡＰＫ１を生成する（Ｓｔ２１）。検証装置２０は、ステップＳｔ２１で生成されたアプリケーション鍵ＡＰＫ１を含むソフトウェアライブラリを認可データ生成装置１０に送る（Ｓｔ２２）。このソフトウェアライブラリは、アプリケーション鍵ＡＰＫ１を含み（言い換えると、アプリケーション鍵ＡＰＫ１が埋め込まれ）、このソフトウェアライブラリをアプリケーションの実行中に呼び出す（コールする）ことで検証装置２０への接続を橋渡しするためのソフトウェア部品（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）である。
　クライアント装置３０は、認可データＴの送信を要求するためのリクエストを生成して認可データ生成装置１０に送る（Ｓｔ２３）。認可データ生成装置１０は、クライアント装置３０からのリクエストに応じて、ステップＳｔ３（図３Ａあるいは図３Ｂ参照）で生成された認可データＴを、認可データ生成装置１０とクライアント装置３０との間で形成されたセキュリティの高い通信路（例えば相互に認証されたＢＬＥ）を用いてクライアント装置３０に送信する（Ｓｔ４）。
　認可データ生成装置１０は、ステップＳｔ２２で検証装置２０から送られたソフトウェアライブラリを受信し、このソフトウェアライブラリをコールすることで実行可能となるアプリケーションを生成する（Ｓｔ２４）。認可データ生成装置１０は、アプリケーション鍵ＡＰＫ１が埋め込まれたソフトウェアライブラリを含むアプリケーションＡＰＰ１のデータをダウンロードサーバ４０にアップロード（送信）する（Ｓｔ２５）。
　クライアント装置３０がダウンロードサーバ４０（例えばアプリストア）にアクセスする（Ｓｔ２６）。
　図９において、クライアント装置３０は、アプリケーション鍵ＡＰＫ１が埋め込まれたソフトウェアライブラリを含むアプリケーションＡＰＰ１のデータをダウンロードサーバ４０からダウンロードして取得する（Ｓｔ２７）。クライアント装置３０は、クライアント装置３０のユーザ操作に基づき、ステップＳｔ４で送られた認可データＴをアプリケーション鍵ＡＰＫ１で暗号化して暗号化認可データＥＡＵＴＨ１を生成してアプリケーションＡＰＰ１のソフトウェアライブラリに入力して設定する（Ｓｔ２８）。クライアント装置３０は、暗号化認可データＥＡＵＴＨ１をアプリケーションＡＰＰ１の使用を許可するためのリクエストＹに含んで検証装置２０に送る（Ｓｔ５Ｂ）。
　検証装置２０は、ステップＳｔ５Ｂでクライアント装置３０から送られたリクエストＹに含まれる暗号化認可データＥＡＵＴＨ１を抽出して取得する。検証装置２０は、暗号化認可データＥＡＵＴＨ１を、ステップＳｔ２１で生成されたアプリケーション鍵ＡＰＫ１で復号する（Ｓｔ６Ｂ）。検証装置２０は、復号により得られた認可データＴを構成する署名Ｓを、ステップＳｔ２で保存されたクライアント装置３０の証明書ＣＥＲＴ１に含まれる認可データ生成装置１０の公開鍵を用いて復号する（Ｓｔ６Ｂ）。検証装置２０は、認可データ生成装置１０と検証装置２０との間で既定のハッシュ関数を用いて認可データＴを構成する任意データＤのハッシュ値を演算する。検証装置２０は、ハッシュ値と復号により得られた復号データＦとが同一か否かに応じて、認可データＴの検証が成功か失敗かを判定する（Ｓｔ６Ｂ）。
　検証装置２０は、認可データＴの検証が成功したと判定した場合、リクエストＹに対するレスポンスとして、アプリケーションＡＰＰ１の使用を許可するための権限情報を生成してクライアント装置３０に送信する（Ｓｔ７Ｂ）。一方、検証装置２０は、認可データＴの検証が失敗したと判定した場合、アプリケーションＡＰＰ１の使用を許可しない旨のエラー通知を生成し、上述したセキュリティの高い通信路を経てクライアント装置３０に送信する（Ｓｔ７Ｂ）。例えば、検証装置２０は、認可データ生成装置１０からクライアント装置３０に送られた認可データＴが万が一漏洩して悪意ある第三者によって認可データＴが偽造された場合でもアプリケーション鍵ＡＰＫ１の取得がなされていない限りステップＳｔ６Ｂでの検証が成功しないので、悪意ある第三者によって偽造された認可データの使用を効果的にブロックしたり、その認可データに紐づくアプリケーション鍵ＡＰＫ１以外でのアプリケーションＡＰＰ１の使用を拒否（否認）できたりしてセキュリティの向上を図ることができる。
　以上により、実施の形態３に係るリクエスト検証システム１Ｂでは、リクエスト検証システム１Ｂを構成する検証装置２０は、クライアント装置３０がアプリストア等のダウンロードサーバ４０から取得したアプリケーションＡＰＰ１の使用のリクエストＹをクライアント装置３０から受けた際、そのリクエストＹに含まれる暗号化認可データＥＡＵＴＨ１を検証する。検証装置２０は、検証が成功したと判定した場合に、そのリクエストＹに対するレスポンスとして、アプリケーションＡＰＰ１の使用を認可してクライアント装置３０に返送する。検証装置２０は、検証が失敗したと判定した場合に、検証が失敗した旨のエラー通知をクライアント装置３０に送信する。
　これにより、リクエスト検証システム１Ｂは、クライアント装置３０から送られた暗号化認可データＥＡＵＴＨ１をアプリケーション鍵ＡＰＫ１で適切に復号できるか否かの第１の検証、および、復号により得られた認可データＡＵＴＨ１の検証ができるか否かの第２の検証というように二重の検証により、クライアント装置３０の秘密情報を使うことなく、クライアント装置３０からのアプリケーションＡＰＰ１の使用の許否を適切に判定できる。これにより、リクエスト検証システム１Ｂは、認可データ生成装置１０からクライアント装置３０に送られた認可データＴが万が一漏洩して悪意ある第三者によって認可データＴが偽造された場合でもアプリケーション鍵ＡＰＫ１の取得がなされていない限り検証装置２０での検証が成功しないので、その偽造された認可データを用いたリクエストを受けてもその偽造された認可データの使用を効果的にブロックできたりその認可データに紐づくアプリケーションの使用の承認を否認できたりしてセキュリティの向上を図ることができる。
　以上、図面を参照しながら各種の実施の形態について説明したが、本開示はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例、修正例、置換例、付加例、削除例、均等例に想到し得ることは明らかであり、それらについても当然に本開示の技術的範囲に属するものと了解される。また、発明の趣旨を逸脱しない範囲において、上述した各種の実施の形態における各構成要素を任意に組み合わせてもよい。
　なお、本出願は、２０２０年１２月９日出願の日本特許出願（特願２０２０－２０４２４８）に基づくものであり、その内容は本出願の中に参照として援用される。
　本開示は、クライアント装置の秘密情報を漏洩することなくユーザのリクエストを安全に検証し、クライアント装置のセキュリティ低下を抑制するリクエスト検証システムおよびリクエスト検証方法として有用である。
１、１Ａ、１Ｂ　リクエスト検証システム
１０　認可データ生成装置
１１、２１、３１　操作デバイス
１２、２２、３２　メモリ
１３、２３、３３　通信デバイス
１４　秘密鍵管理部
１５　認可データ管理部
１６　公開鍵管理部
１７　任意データ管理部
１８　署名生成部
２０　検証装置
２４　署名検証部
２５　公開鍵管理部
２６　ＩＤ生成部
３０　クライアント装置
３４　認可データ管理部
ＰＲＣ１、ＰＲＣ２、ＰＲＣ３　プロセッサ

Claims (12)

  1. 　サービスの提供を認可する認可データを生成して出力し、公開鍵を含む証明書を保持する認可データ生成装置と、
    　前記認可データ生成装置と前記証明書を共有する検証装置と、
    　提供されるサービスを利用するクライアント装置と、を備え、
    　前記検証装置は、前記クライアント装置から前記認可データの検証リクエストを受けると、前記証明書を用いて前記認可データを検証する、
    　リクエスト検証システム。
  2. 　前記検証装置は、
    　前記認可データの検証が成功したと判定すると、前記クライアント装置に前記サービスを提供する、
    　請求項１に記載のリクエスト検証システム。
  3. 　前記検証装置は、
    　前記認可データの検証が失敗したと判定すると、前記クライアント装置にエラー通知を送信する、
    　請求項１に記載のリクエスト検証システム。
  4. 　前記認可データ生成装置は、
    　前記認可データ生成装置の秘密鍵を保持し、当該秘密鍵で任意データを暗号化した署名を生成する、
    　請求項１に記載のリクエスト検証システム。
  5. 　前記検証装置は、
    　前記署名を前記公開鍵で復号したデータと、前記認可データに含まれる任意データに基づくデータとが同一か否かに応じて、前記認可データの検証の成否を判定する、
    　請求項４に記載のリクエスト検証システム。
  6. 　前記検証装置は、
    　前記クライアント装置に応じたＩＤを生成して前記認可データ生成装置に送り、
    　前記認可データ生成装置は、
    　前記任意データとして前記ＩＤを用いて前記認可データを生成して前記クライアント装置に送り、
    　前記検証装置は、
    　受信された前記認可データの検証が成功したと判定すると、受信された前記認可データに含まれるＩＤに応じたサービスを前記クライアント装置に提供する、
    　請求項４に記載のリクエスト検証システム。
  7. 　前記認可データ生成装置は、
    　同一の前記ＩＤを用いて１回のみ前記認可データを生成し、
    　前記検証装置は、
    　受信された前記認可データに含まれるＩＤを前記検証の度に記憶し、記憶されている前記ＩＤと同一のＩＤを含む認可データの検証を拒否する、
    　請求項６に記載のリクエスト検証システム。
  8. 　前記認可データ生成装置は複数設けられ、
    　前記検証装置は、
    　前記認可データ生成装置の識別情報を含んで前記ＩＤを生成し、生成された前記ＩＤを前記識別情報に対応する認可データ生成装置に送信する、
    　請求項６に記載のリクエスト検証システム。
  9. 　前記検証装置は、
    　前記認可データ生成装置により生成された前記認可データの有効性が失効したか否かを示す認可データ失効情報を前記ＩＤに紐付けて記憶し、
    　前記認可データ生成装置からの失効指示に基づいて、前記失効指示の対象となった認可データの有効性を失効処理する、
    　請求項６に記載のリクエスト検証システム。
  10. 　前記検証装置は、
    　前記ＩＤの有効期限を設定し、前記有効期限が設定された前記ＩＤを前記認可データ生成装置に送り、
    　前記認可データ生成装置は、
    　前記有効期限と同一の有効期限を有する前記認可データを生成する、
    　請求項６に記載のリクエスト検証システム。
  11. 　前記認可データ生成装置は、
    　前記任意データとして前記検証装置への接続先情報を用いて前記認可データを生成して前記クライアント装置に送る、
    　請求項４に記載のリクエスト検証システム。
  12. 　サービスの提供を認可する認可データを生成して出力し、公開鍵を含む証明書を保持するステップと、
    　前記証明書を共有するステップと、
    　前記認可データについての検証がリクエストされると、前記証明書を用いて前記認可データを検証するステップと、を有する、
    　リクエスト検証方法。
PCT/JP2021/045219 2020-12-09 2021-12-08 リクエスト検証システムおよびリクエスト検証方法 WO2022124352A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022568320A JPWO2022124352A1 (ja) 2020-12-09 2021-12-08
US18/206,483 US20230318828A1 (en) 2020-12-09 2023-06-06 Request verification system and request verification method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020204248 2020-12-09
JP2020-204248 2020-12-09

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/206,483 Continuation US20230318828A1 (en) 2020-12-09 2023-06-06 Request verification system and request verification method

Publications (1)

Publication Number Publication Date
WO2022124352A1 true WO2022124352A1 (ja) 2022-06-16

Family

ID=81973367

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/045219 WO2022124352A1 (ja) 2020-12-09 2021-12-08 リクエスト検証システムおよびリクエスト検証方法

Country Status (3)

Country Link
US (1) US20230318828A1 (ja)
JP (1) JPWO2022124352A1 (ja)
WO (1) WO2022124352A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000123095A (ja) * 1998-08-12 2000-04-28 Nippon Telegr & Teleph Corp <Ntt> 電子チケット記録媒体、処理方法及び処理装置
JP2001084311A (ja) * 1999-07-14 2001-03-30 Matsushita Electric Ind Co Ltd 電子チケットと電子財布と情報端末
JP2001320356A (ja) * 2000-02-29 2001-11-16 Sony Corp 公開鍵系暗号を使用したデータ通信システムおよびデータ通信システム構築方法
JP2012049752A (ja) * 2010-08-26 2012-03-08 Hitachi Ltd 電子証明書発行システムおよびその方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000123095A (ja) * 1998-08-12 2000-04-28 Nippon Telegr & Teleph Corp <Ntt> 電子チケット記録媒体、処理方法及び処理装置
JP2001084311A (ja) * 1999-07-14 2001-03-30 Matsushita Electric Ind Co Ltd 電子チケットと電子財布と情報端末
JP2001320356A (ja) * 2000-02-29 2001-11-16 Sony Corp 公開鍵系暗号を使用したデータ通信システムおよびデータ通信システム構築方法
JP2012049752A (ja) * 2010-08-26 2012-03-08 Hitachi Ltd 電子証明書発行システムおよびその方法

Also Published As

Publication number Publication date
US20230318828A1 (en) 2023-10-05
JPWO2022124352A1 (ja) 2022-06-16

Similar Documents

Publication Publication Date Title
CN108768664B (zh) 密钥管理方法、装置、系统、存储介质和计算机设备
US9847882B2 (en) Multiple factor authentication in an identity certificate service
KR101132148B1 (ko) 키 관리 프로토콜에 권한부여의 클라이언트 승인을 제공하기 위한 시스템 및 방법
US10567370B2 (en) Certificate authority
US9137017B2 (en) Key recovery mechanism
Barker et al. Recommendation for key management part 3: Application-specific key management guidance
US6993652B2 (en) Method and system for providing client privacy when requesting content from a public server
US7689828B2 (en) System and method for implementing digital signature using one time private keys
ES2665887T3 (es) Sistema de datos seguro
JP2005276122A (ja) アクセス元認証方法及びシステム
KR101007375B1 (ko) 스마트 카드 인증서 관리 장치 및 방법
JP7021376B2 (ja) 通信装置、通信方法、およびコンピュータプログラム
JP2007104118A (ja) 秘密情報の保護方法及び通信装置
Barker et al. Sp 800-57. recommendation for key management, part 1: General (revised)
CN114095919A (zh) 一种基于车联网的证书授权处理方法及相关设备
JP2014022920A (ja) 電子署名システム、電子署名方法および電子署名プログラム
WO2022124352A1 (ja) リクエスト検証システムおよびリクエスト検証方法
JP2010028689A (ja) 公開パラメータ提供サーバ、公開パラメータ提供方法、公開パラメータ提供プログラム、暗号化処理実行装置、暗号化処理実行方法、暗号化処理実行プログラム、署名処理実行装置、署名処理実行方法及び署名処理実行プログラム
KR20190097998A (ko) 개인키의 안전 보관을 지원하는 사용자 간편 인증 장치 및 그 동작 방법
KR101515312B1 (ko) 네트워크 액세스의 제어 방법 및 시스템
JP2000261428A (ja) 分散処理システムにおける認証装置
JP4071474B2 (ja) 失効確認装置及び方法
JP2005311531A (ja) デジタル署名処理方法及びそのためのプログラム
KR102320667B1 (ko) 사용자 정보의 관리 방법 및 단말
JP7036705B2 (ja) 通信装置、通信方法、およびコンピュータプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21903451

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022568320

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21903451

Country of ref document: EP

Kind code of ref document: A1