WO2022123745A1 - 証明書発行支援システム、証明書発行支援方法及びプログラム - Google Patents

証明書発行支援システム、証明書発行支援方法及びプログラム Download PDF

Info

Publication number
WO2022123745A1
WO2022123745A1 PCT/JP2020/046126 JP2020046126W WO2022123745A1 WO 2022123745 A1 WO2022123745 A1 WO 2022123745A1 JP 2020046126 W JP2020046126 W JP 2020046126W WO 2022123745 A1 WO2022123745 A1 WO 2022123745A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
information
existence
organization
employee
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/JP2020/046126
Other languages
English (en)
French (fr)
Inventor
亮平 鈴木
哲矢 奥田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to US18/250,639 priority Critical patent/US12278911B2/en
Priority to PCT/JP2020/046126 priority patent/WO2022123745A1/ja
Priority to JP2022567987A priority patent/JP7485087B2/ja
Publication of WO2022123745A1 publication Critical patent/WO2022123745A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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/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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • 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

Definitions

  • the present invention relates to a certificate issuance support system, a certificate issuance support method, and a program.
  • the digital certificate showing the identity of the website is an electronic certificate of the identity of a trusted third party.
  • Electronic certificates include DV (Domain Validation) certificates, OV (Organization Validation) certificates, and the like, depending on the degree of identity verification.
  • a DV certificate is a certificate issued by the applicant after confirming the ownership of the domain.
  • An OV certificate is a certificate issued by confirming the existence of the certificate application organization and whether the applicant belongs to the organization, in addition to the ownership of the domain by the applicant.
  • ACME Automatic Certificate Management Environment
  • Non-Patent Document 1 a protocol used for issuing DV certificates
  • eKYC electroKnowYourCustomer
  • ACME cannot be applied to the issuance of OV certificates as it is because the existence confirmation of the organization is not taken into consideration.
  • confirmation by hand such as by using documents or telephone, is performed to confirm who the organization to be issued is and whether the applicant belongs to the organization.
  • the identity that can be guaranteed by eKYC is the identity of the individual, and the existence confirmation of the organization is not taken into consideration.
  • the present invention has been made in view of the above points, and an object of the present invention is to support the automatic issuance of an OV certificate.
  • a certificate application device in a first organization that applies for issuance of an OV certificate to a certificate authority, and an existence guarantee device possessed by a second organization that guarantees the existence of the first organization.
  • the existence guarantee device responds to a request from a terminal used by a member of the first organization with respect to the first information for guaranteeing the existence of the first organization.
  • the granting unit that grants the first electronic signature, the transmitting unit that transmits the first information to which the first electronic signature is assigned to the certificate application device, and the certificate application device generated, said.
  • the device has a verification unit that verifies the second electronic signature given to the second information that guarantees the affiliation of the member to the first organization in cooperation with the certificate authority, and applies for the certificate.
  • the device transmits the first information to which the first electronic signature is attached and the second information to which the second electronic signature is attached to the certificate authority in order to receive the issuance of the OV certificate. do.
  • the specific organization that applies for the issuance of the OV certificate is called a "corporation”.
  • a specific person as an applicant for issuance of a certificate is called an "employee”.
  • FIG. 1 is a diagram showing a configuration example of a certificate issuance support system according to the first embodiment.
  • each region surrounded by a broken line indicates a structure.
  • the computers of three organizations, a corporation, a corporate eKYC provider, and a certificate authority cooperate with each other via a network.
  • a corporation is an example of an organization to which an OV certificate is issued (application source for issuance).
  • the corporation is ready to authenticate its employees.
  • a corporation can issue an ID / PW or the like to each employee to authenticate the employee within the corporation.
  • the legal entity includes a certificate application device 20 and one or more employee terminals 30.
  • the employee terminal 30 is a terminal such as a PC (Personal Computer) used by an employee who is in charge of certificate issuance application work.
  • the employee terminal 30 is connected to the certificate application device 20 via the network N1 in the corporation, and is also connected to the existence guarantee device 10 and the CA server 40 via the network N1 and the network N2 such as the Internet.
  • the certificate application device 20 has the authority to authenticate the employee and request the corporate eKYC provider for information that guarantees the existence of the corporation (hereinafter, referred to as “existence guarantee information”) ”(hereinafter, simply, When the employee has "authority”), it functions as an extended ACME client.
  • the certificate application device 20 functions as an extended ACME client, so that the existence guarantee device 10 guarantees the existence of the corporation, and the existence of the employee is guaranteed to the existence guarantee device 10, and then the CA server 40. Is requested to issue an OV certificate.
  • the actual existence of an employee means that the employee certainly belongs to a corporation.
  • the certificate application device 20 is connected to the existence guarantee device 10 and the CA server 40 via the network N1 and the network N2.
  • the corporate eKYC provider is an organization whose existence is assumed in this embodiment, and is an organization that guarantees the existence of the corporation (the claim of the corporation).
  • the corporate eKYC provider has a function as a general PKI authentication infrastructure (hereinafter referred to as "corporate PKI"), and the corporate PKI allows the corporation to use an electronic signature. Since the corporate eKYC provider is a PKI authentication infrastructure, it also functions as a CA (Certificate Authority) for a public key certificate for authentication.
  • the certificate authority is a CA (CA that issues an OV certificate) for guaranteeing a corporate Web server, while the corporate eKYC provider also functions as a CA as an authentication platform. That is, their roles are different.
  • the corporate eKYC provider may be realized by the government or a third party organization. That is, the existence of the corporation may be guaranteed electronically by the government or the like, or there may be a third-party organization that provides information confirming the identity of the corporation. In any case, since the identity of the corporation can be guaranteed, the guarantor of the identity (existence or identity) of the corporation may be either an administrative or a third party.
  • the corporate eKYC provider has a reality guarantee device 10.
  • the existence guarantee device 10 is one or more computers that electronically realize the functions of the corporate eKYC provider.
  • the broker server guarantees the existence of the corporation and confirms the existence of the employee (the employee belongs to the corporation).
  • the certificate authority is a conventional certificate authority.
  • the certificate authority has a CA server 40.
  • the CA server 40 issues an OV (Organization Validation) certificate to a corporation according to ACME.
  • OV Organization Validation
  • FIG. 2 is a diagram showing a hardware configuration example of the existence guarantee device 10 according to the first embodiment.
  • the existence guarantee device 10 of FIG. 3 has a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, and the like, which are connected to each other by a bus B, respectively.
  • the program that realizes the processing in the existence guarantee device 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed in the auxiliary storage device 102 from the recording medium 101 via the drive device 100.
  • the program does not necessarily have to be installed from the recording medium 101, and may be downloaded from another computer via the network.
  • the auxiliary storage device 102 stores the installed program and also stores necessary files, data, and the like.
  • the memory device 103 reads a program from the auxiliary storage device 102 and stores it when there is an instruction to start the program.
  • the CPU 104 executes the function related to the existence guarantee device 10 according to the program stored in the memory device 103.
  • the interface device 105 is used as an interface for connecting to a network.
  • FIG. 3 is a diagram showing a functional configuration example of the certificate issuance support system according to the first embodiment.
  • the certificate application device 20 has an employee authentication infrastructure unit 21, an extended ACME client unit 22, and a conventional ACME client unit 23. Each of these parts is realized by a process of causing the CPU of the certificate application device 20 to execute one or more programs installed in the certificate application device 20. However, each of these parts may be realized by a different computer.
  • the certificate application device 20 also uses the private key storage unit 24.
  • the private key storage unit 24 can be realized by using, for example, an auxiliary storage device of the certificate application device 20, a storage device that can be connected to the certificate application device 20 via a network, or the like.
  • the employee authentication infrastructure department 21 authenticates the employee and confirms the existence of authority for the employee.
  • the extended ACME client unit 22 and the conventional ACME client unit 23 are ACME clients in the present embodiment.
  • the ACME client refers to software that interprets exchanges based on ACME and applies for certificate issuance, etc., with a CA server 40 that supports ACME (Automatic Certificate Management Environment), which is an automatic certificate issuance protocol.
  • ACME Automatic Certificate Management Environment
  • the extended ACME client unit 22 executes a flow extended to the ACME protocol in the present embodiment.
  • the conventional ACME client unit 23 interacts with the CA server 40 using the conventional ACME protocol.
  • the private key storage unit 24 stores a private key (hereinafter referred to as "corporate secret key") used for assigning a signature that can be verified by the corporate PKI unit 12 of the existence guarantee device 10.
  • the corporate private key is provided by the corporate PKI department 12.
  • the existence guarantee device 10 includes the corporate eKYC department 11 and the corporate PKI department 12. Each of these parts is realized by a process of causing the CPU 104 to execute one or more programs installed in the existence guarantee device 10. However, each of these parts may be realized by a different computer.
  • the corporate eKYC department 11 provides information that guarantees the existence of the corporation (existence guarantee information) to the corporation.
  • the corporate eKYC department 11 causes the corporate PKI department 12 to assign an electronic signature to the information that guarantees the existence of the corporation by the corporate eKYC provider.
  • the corporate PKI department 12 provides a general PKI to a corporation.
  • the corporate PKI department 12 distributes a public key certificate and a root certificate of a corporate eKYC provider to a corporation.
  • the CA server 40 has a certificate issuing unit 41.
  • the certificate issuing unit 41 is realized by a process of causing the CPU of the CA server 40 to execute one or more programs installed in the CA server 40.
  • the certificate issuing unit 41 issues an electronic certificate (OV certificate in this embodiment) based on ACME, which is an automatic certificate issuing protocol.
  • FIG. 4 is a sequence diagram for explaining an example of a processing procedure executed in the certificate issuance support system.
  • the axis of "corporation" represents a set of the employee terminal 30, the conventional ACME client unit 23, the extended ACME client unit 22, and the employee authentication infrastructure unit 21.
  • steps S11 to S13, S16 and S17 are steps based on the conventional ACME. Therefore, the extended ACME client unit 22 is not involved in these steps.
  • steps S14 and S15 are expansion steps for ACME. Therefore, conventionally, the ACME client unit 23 is not involved in steps S14 and S15.
  • step S11 the corporation registers an account for the corporation with the CA server 40.
  • the CA server 40 returns the registration result of the account (S12).
  • a corporate public key (a public key corresponding to a corporate private key (hereinafter referred to as "corporate public key")) is also registered in the CA server 40.
  • the CA server 40 can authenticate the corporation in the subsequent steps. That is, in the subsequent steps, the CA server 40 authenticates the corporation for each request from the corporation to the CA server 40, as in the conventional ACME. Account registration only needs to be done once.
  • step S13 a confirmation process is executed between the corporation and the CA server 40 to confirm that the corporation possesses a domain (domain related to the application for a certificate) according to ACME.
  • step S14 the existence of the corporation is confirmed by the cooperation between the corporation, the CA server 40, and the existence guarantee device 10.
  • step S15 the confirmation process of the employee's affiliation (employee's existence) to the corporation is executed by the cooperation between the corporation, the CA server 40, and the existence guarantee device 10.
  • the CA server 40 records information indicating what confirmation has been completed for the corporation in association with the corporate account each time steps S13 to S15 are executed. That is, if step S13 is normally completed, the CA server 40 records information indicating that the confirmation that the corporation possesses the domain is completed. If step S14 ends normally, the CA server 40 records information indicating that the confirmation that the corporation actually exists has been completed. If step S15 ends normally, the CA server 40 records information indicating that the confirmation that the employee belongs to the corporation is completed. Since the corporation is authenticated in each step of steps S13 to S15, the CA server 40 can identify which corporation the confirmation is for.
  • the corporation for example, the conventional ACME client unit 23 transmits a certificate issuance request (CSR (Certificate Signing Request)) to the CA server 40 (S16). Even in the certificate issuance request, the CA server 40 authenticates the corporation.
  • CSR Certificate Signing Request
  • the CA server 40 determines which of steps S13 to S15 has been confirmed for the corporation that is the sender of the certificate issuance request (the corporation that has been authenticated with respect to the certificate issuance request). Confirm. If all the confirmations have been completed, the CA server 40 generates an OV certificate for the corporation and returns the OV certificate to the corporation (S17).
  • FIG. 5 is a sequence diagram for explaining an example of the processing procedure of the confirmation processing of the existence of the corporation in the first embodiment.
  • step S101 the employee terminal 30 requests the corporate eKYC department 11 for the corporate existence guarantee information in response to the input by the employee (instruction to acquire the corporate existence guarantee information).
  • the corporate eKYC unit 11 sends an authentication request to the employee terminal 30 in response to the request from the employee terminal 30 (S102).
  • the authentication request is transmitted from the corporate eKYC unit 11 to the employee terminal 30 because the employee authentication infrastructure unit 21 capable of authenticating an employee is located in the corporation (inside the certificate application device 20), and the existence guarantee device 10 is used. This is because employees cannot be authenticated. Therefore, the corporate eKYC unit 11 unit transmits the authentication request to the employee terminal 30 so that the authentication request is redirected to the employee authentication infrastructure unit 21.
  • the employee terminal 30 executes employee authentication in cooperation with the employee authentication infrastructure unit 21 of the certificate application device 20 (S103). For example, the employee terminal 30 displays a screen for inputting an employee ID and password for such authentication. The employee terminal 30 transmits the ID and password entered on the screen to the employee authentication infrastructure unit 21. The employee authentication infrastructure unit 21 compares the ID and password with the correct ID and password stored in the certificate application device 20 in advance, and if they match, the employee authentication succeeds. The authentication is for acquiring the existence guarantee information of the corporation (that is, for using the corporation eKYC unit 11).
  • the employee authentication infrastructure unit 21 confirms whether or not the employee has the authority to "request the existence guarantee information of the corporation from the corporation eKYC department 11" (S104). For example, information indicating the presence or absence of authority for each member of the corporation is stored in the certificate application device 20, and the employee authentication infrastructure unit 21 refers to the information and confirms whether or not the employee has authority. do.
  • the employee authentication infrastructure unit 21 notifies the corporate eKYC department 11 that the employee has authority (S105).
  • a notification may be executed by any procedure.
  • the corporate eKYC unit 11 may transmit a token, which is data indicating that the employee has authority, to the employee terminal 30, and the employee terminal 30 may transmit the token to the corporate eKYC unit 11.
  • the employee authentication infrastructure department 21 inquires the employee authentication infrastructure unit 21 whether or not the token is authorized with the token, the employee authentication infrastructure department 21 verifies the token, and if the token is valid, the employee has the authority.
  • the notification may be sent to the corporate eKYC unit 11.
  • the corporate eKYC department 11 In response to the notification that the employee has authority, the corporate eKYC department 11 generates the corporate existence guarantee information (S106). For example, the corporate eKYC unit 11 generates the following existence guarantee information in the JSON (JavaScript (registered trademark) Object Notation) format. ⁇ "iss”: "https://ekyc.example.com”, “aud”: "xxxx", "name”: "xxxx Corp", ... ⁇ In the above-mentioned existence guarantee information, "xxxx” is, for example, a character string indicating the name of a corporation.
  • JSON JavaScript (registered trademark) Object Notation
  • the corporate eKYC department 11 transmits the existence guarantee information to the corporation PKI department 12 and requests the corporation PKI department 12 to give a signature (electronic signature) to the existence guarantee information (S107).
  • the corporate PKI department 12 uses the corporate PKI to sign the existence guarantee information with the private key of the corporation eKYC provider (signs the existence guarantee information), and the signed existence guarantee information is transferred to the corporation eKYC department 11. (S108).
  • the CA server 40 can confirm the authenticity of the existence guarantee information.
  • the corporate eKYC unit 11 transmits the signed existence guarantee information to the extended ACME client unit 22 of the certificate application device 20 (S109).
  • the existence guarantee information may be transmitted to the extended ACME client unit 22 via the employee terminal 30.
  • the corporate eKYC unit 11 transmits the existence guarantee information to the employee terminal 30 as a response to step S101.
  • the employee terminal 30 transmits the existence guarantee information to the extended ACME client unit 22.
  • the extended ACME client unit 22 transmits the existence guarantee information to the certificate issuing unit 41 of the CA server 40 (S110).
  • the certificate issuing unit 41 causes the corporate PKI unit 12 to verify the signature given to the existence guarantee information (S111).
  • the certificate issuing unit 41 transmits the verification result of the existence guarantee information to the extended ACME client unit 22 (S112).
  • the certificate issuing unit 41 records the existence guarantee information in the CA server 40 as information indicating that the confirmation that the corporation actually exists has been completed.
  • the existence guarantee information is transmitted to the certificate issuing unit 41 by the extended ACME client unit 22, but what if the existence guarantee information finally reaches the certificate issuing unit 41?
  • the procedure may be adopted.
  • the CA and the corporate eKYC provider may directly cooperate with each other to acquire information. In that case, a technique based on OAuth 2.0 may be used.
  • FIG. 6 is a sequence diagram for explaining an example of the processing procedure of the confirmation processing of the affiliation of an employee to a corporation.
  • step S201 the employee terminal 30 requests the employee authentication infrastructure unit 21 to guarantee the existence of the employee in response to the input by the employee (instruction for requesting the existence guarantee of the employee).
  • the employee authentication infrastructure unit 21 executes employee authentication in cooperation with the employee terminal 30 (S202). Authentication confirms whether the employee is who he or she is.
  • the employee authentication infrastructure unit 21 If the employee is successfully authenticated, the employee authentication infrastructure unit 21 generates the employee's existence guarantee information (S203). For example, the employee authentication infrastructure unit 21 generates the following existence guarantee information in JSON format. ⁇ "affiliation”: “xxx Corp.”, "name”: “yyy”, ... ⁇ In the above-mentioned existence guarantee information, "xxx” is, for example, a character string indicating the name of a corporation, and "yyy" is a character string indicating the name of an employee.
  • the employee authentication infrastructure unit 21 signs (assigns a signature) the generated existence guarantee information using the corporate private key.
  • the existence guarantee information By signing the existence guarantee information using the corporate private key, the existence (affiliation) of the employee is guaranteed by the corporation.
  • the certificate issuing unit 41 can confirm the authenticity of the existence guarantee information by the signature.
  • the signature may be performed by an external service.
  • the corporate private key management function and the signature function may be performed by an external service.
  • the employee authentication infrastructure unit 21 transmits the signed existence guarantee information to the extended ACME client unit 22 (S204).
  • the existence guarantee information may be transmitted to the extended ACME client unit 22 via the employee terminal 30.
  • the employee authentication infrastructure unit 21 transmits the existence guarantee information to the employee terminal 30 as a response to step S201.
  • the employee terminal 30 transmits the existence guarantee information to the extended ACME client unit 22.
  • the extended ACME client unit 22 transmits the existence guarantee information to the certificate issuing unit 41 of the CA server 40 (S205).
  • the certificate issuing unit 41 cooperates with the corporate PKI unit 12 to verify the signature given to the existence guarantee information (S206).
  • the corporate PKI department 12 cooperates with the certificate issuing department 41 to verify the signature given to the existence guarantee information.
  • the certificate issuing unit 41 receives the distribution of the corporate public key from the corporate PKI unit 12 and verifies the signature.
  • the corporate public key may be distributed by another method (other timing).
  • the corporate PKI unit 12 may verify the signature given to the existence guarantee information and send the result to the certificate issuing unit 41.
  • the certificate issuing unit 41 transmits the verification result of the signature to the employee terminal 30 (S207).
  • the certificate issuing unit 41 records the existence guarantee information in the CA server 40 as information indicating that the confirmation that the employee belongs to the corporation has been completed.
  • the existence of the corporation can be confirmed electronically, and the eKYC that guarantees the affiliation of the employee (applicant) to the corporation is guaranteed. ((Individual) electronic identity verification) can be realized.
  • all OV certificate applications can be executed electronically, and by extension, automatic issuance of OV certificates can be supported.
  • the second embodiment will explain the differences from the first embodiment.
  • the points not particularly mentioned in the second embodiment may be the same as those in the first embodiment.
  • FIG. 7 is a diagram showing a functional configuration example of the certificate issuance support system according to the second embodiment.
  • the existence guarantee device 10 further has an existence guarantee authentication unit 13.
  • the existence guarantee authentication unit 13 is realized by a process of causing the CPU 104 to execute one or more programs installed in the existence guarantee device 10.
  • the existence guarantee certification unit 13 authenticates employees for the existence guarantee of a corporation.
  • the account of the employee who is permitted to request the existence guarantee is registered in the existence guarantee device 10 in advance.
  • SCIM System for Cross-Domains Identity Management
  • FIG. 8 is a sequence diagram for explaining an example of the processing procedure of the confirmation processing of the existence of the corporation in the second embodiment.
  • the same steps as those in FIG. 5 are assigned the same step numbers, and the description thereof will be omitted as appropriate.
  • steps S102 to S105 in FIG. 5 are replaced with steps S102a to S105a.
  • step S102a the corporate eKYC department 11 requests the authentication of the employee from the authentication unit 13 for guaranteeing the existence.
  • the existence guarantee authentication unit 13 executes employee authentication in cooperation with the employee terminal 30 (S103a).
  • the existence guarantee authentication unit 13 transmits a Web page for displaying a screen for inputting an employee ID and password for such authentication to the employee terminal 30.
  • the employee terminal 30 displays the screen based on the Web page.
  • the employee terminal 30 transmits the ID and password entered on the screen to the authentication unit 13 for guaranteeing existence.
  • the existence guarantee authentication unit 13 compares the ID and password with a pre-registered account (correct ID and password), and if both match, the employee is successfully authenticated.
  • the existence assurance authentication unit 13 may authenticate employees in cooperation with the employee authentication infrastructure unit 21.
  • the authentication unit 13 for guaranteeing the existence confirms whether or not the employee has the authority to "request the existence guarantee information of the corporation from the corporation eKYC department 11" (S104a). For example, information indicating a person having such authority is stored in the existence guarantee device 10, and the existence guarantee authentication unit 13 refers to the information and confirms whether or not the employee has authority.
  • the authentication unit 13 for guarantee of existence notifies the corporate eKYC unit 11 that the employee has authority (S105a). The rest is the same as in FIG.
  • the existence guarantee device 10 can directly provide the authentication function to the employee. Further, the notification that the employee has the authority can be notified only by the cooperation in the existence guarantee device 10.
  • the existence guarantee device 10 does not need to know which employee the request source (applicant) of the existence guarantee is (corporate eKYC provider requested by an authorized employee). I only know that, and I don't even know who the employee is requesting.) On the other hand, in the second embodiment, the corporate eKYC provider knows who the applicant is an employee.
  • the corporation is an example of the first organization.
  • the corporate eKYC provider is an example of a second organization.
  • the corporate PKI department 12 is an example of a granting department and a verification department.
  • the corporate eKYC unit 11 is an example of a transmission unit.
  • the corporate existence guarantee information is an example of the first information.
  • the employee existence guarantee information is an example of the second information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

ＯＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とを含む証明書発行支援システムにおいて、前記実在保証装置は、前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する付与部と、前記第１の電子署名が付与された前記第１の情報を前記証明書申請装置へ送信する送信部と、前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証部と、を有し、前記証明書申請装置は、前記第１の電子署名が付与された第１の情報及び前記第２の電子署名が付与された前記第２の情報を、前記ＯＶ証明書の発行を受けるために前記認証局へ送信することで、ＯＶ証明書の自動的な発行を支援する。

Description

証明書発行支援システム、証明書発行支援方法及びプログラム
　本発明は、証明書発行支援システム、証明書発行支援方法及びプログラムに関する。
　Ｗｅｂサイトのアイデンティティを示す電子証明書は、信頼できる第三者が本人性を電子的に証明するものである。電子証明書には、本人確認の度合いによって、ＤＶ（Domain Validation）証明書やＯＶ（Organization Validation）証明書等が有る。ＤＶ証明書とは、申請者がドメインの所有を確認し、発行される証明書をいう。ＯＶ証明書とは、申請者によるドメインの所有に加え、証明書申請組織の実在、申請者が組織に属するかを確認し、発行される証明書をいう。
　ＤＶ証明書の発行に利用されるプロトコルとしてＡＣＭＥ（Automatic Certificate Management Environment）が知られている（非特許文献１）。ＡＣＭＥを利用することで、ＤＶ証明書の自動的な発行が可能となる。
　他方において、個人の身元を電子的に保証する技術として、ｅＫＹＣ（electoronic Know Your Customer）が知られている（非特許文献２）。
Automatic Certificate Management Environment（RFC8555）、［online］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc8555＞ 宮川晃一、"本人確認手段としてのeKYCと今後の発展"、JNSA Press 第48号, pp.2-8, 2020/1、［online］、インターネット＜ＵＲＬ：https://www.jnsa.org/jnsapress/vol48/2_kikou.pdf＞
　しかしながら、ＡＣＭＥは、組織の実在確認が考慮されていないため、そのままではＯＶ証明書の発行に適用することができない。従来、ＯＶ証明書の発行においては、発行対象の組織が何者であるのか、申請者は組織に属するのか、という確認が書類や電話を用いるなど人手によって行われている。
　また、ｅＫＹＣによって保証可能な身元は、個人の身元であり、組織の実在確認は考慮されていない。
　したがって、従来技術では、ＯＶ証明書の自動的な発行が困難である。
　本発明は、上記の点に鑑みてなされたものであって、ＯＶ証明書の自動的な発行を支援することを目的とする。
　そこで上記課題を解決するため、ＯＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とを含む証明書発行支援システムにおいて、前記実在保証装置は、前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する付与部と、前記第１の電子署名が付与された前記第１の情報を前記証明書申請装置へ送信する送信部と、前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証部と、を有し、前記証明書申請装置は、前記第１の電子署名が付与された第１の情報及び前記第２の電子署名が付与された前記第２の情報を、前記ＯＶ証明書の発行を受けるために前記認証局へ送信する。
　ＯＶ証明書の自動的な発行を支援することができる。
第１の実施の形態における証明書発行支援システムの構成例を示す図である。 第１の実施の形態における実在保証装置１０のハードウェア構成例を示す図である。 第１の実施の形態における証明書発行支援システムの機能構成例を示す図である。 証明書発行支援システムにおいて実行される処理手順の一例を説明するためのシーケンス図である。 第１の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。 法人への社員の所属の確認処理の処理手順の一例を説明するためのシーケンス図である。 第２の実施の形態における証明書発行支援システムの機能構成例を示す図である。 第２の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。
　本実施の形態では、ＡＣＭＥ（Automatic Certificate Management Environment）を拡張することで、従来のドメインの所持確認だけでなく、「申請組織の実在」及び「組織への申請者の所属」を確認するフローを含む、ＯＶ証明書の電子的な発行手順が開示される。なお、ＯＶ（Organization Validation）証明書とは、証明書発行時に申請者がドメインを所有していることに加え、証明書発行対象の組織が実在するか、申請者が証明書の発行対象の組織に属するかなどを確認して発行される電子証明書をいう。
　また、斯かる確認について電子的な処理を可能とするため、構成員が組織に属することを保証するｅＫＹＣ方法が開示される。
　なお、本実施の形態において、ＯＶ証明書の発行を申請する特定の組織を「法人」という。また、組織（法人）の構成員のうち、証明書発行の申請者としての特定の者を「社員」という。
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態における証明書発行支援システムの構成例を示す図である。図１において、破線で囲まれた各領域は、組織を示す。本実施の形態では、法人、法人ｅＫＹＣプロバイダ及び認証局の３つの組織のコンピュータがネットワークを介して連携する。
　法人は、ＯＶ証明書の発行対象（発行の申請元）の組織の一例である。法人は、社員を認証できる状態にある。例えば、法人は、各社員にＩＤ／ＰＷなど発行し、法人内で社員を認証することができる。図１において、法人は、証明書申請装置２０及び１以上の社員端末３０を含む。
　社員端末３０は、証明書発行申請作業の担当者である社員が利用するＰＣ（Personal Computer）等の端末である。社員端末３０は、法人内のネットワークＮ１を介して証明書申請装置２０に接続されるとともに、ネットワークＮ１及びインターネット等のネットワークＮ２を介して実在保証装置１０及びＣＡサーバ４０に接続される。
　証明書申請装置２０は、社員の認証を行うとともに、法人ｅＫＹＣプロバイダに対して法人の実在を保証する情報（以下、「実在保証情報」という。）」を要求するための権限（以下、単に、「権限」という。）を当該社員が有する場合に、拡張されたＡＣＭＥクライアントとして機能する。証明書申請装置２０は、拡張されたＡＣＭＥクライアントとして機能することで、実在保証装置１０に法人の実在を保証させると共に、社員の実在を実在保証装置１０に対して保証した上で、ＣＡサーバ４０に対してＯＶ証明書の発行を要求する。なお、社員の実在とは、社員が法人に確かに所属することをいう。なお、証明書申請装置２０は、ネットワークＮ１及びネットワークＮ２を介して実在保証装置１０及びＣＡサーバ４０に接続される。
　法人ｅＫＹＣプロバイダは、本実施の形態においてその存在が仮定される組織であり、法人の実在（法人の主張）を保証する組織である。法人ｅＫＹＣプロバイダは、一般的なＰＫＩ認証基盤（以下、「法人ＰＫＩ」という。）としての機能を有し、法人ＰＫＩにより、法人は電子署名を利用することができる。法人ｅＫＹＣプロバイダは、また、ＰＫＩ認証基盤であるため、認証用の公開鍵証明書のＣＡ（Certificate Authority）としても機能する。なお、認証局は、法人のＷｅｂサーバを保証するためのＣＡ（ＯＶ証明書を発行するＣＡ）であるのに対し、法人ｅＫＹＣプロバイダは、もう一つは認証基盤としてのＣＡとして機能する。すなわち、両者の役割は異なる。
　なお、法人ｅＫＹＣプロバイダは、行政又は第三者組織によって実現されてもよい。すなわち、法人の実在を行政などが電子的に保証してもよいし、法人の身元を確認した情報を提供する第三者組織が存在してもよい。いずれにせよ法人のアイデンティティを保証できるため、法人のアイデンティティ（実在又は身元）の保証者は、行政又は第三者のいずれでもよい。
　図１において、法人ｅＫＹＣプロバイダは、実在保証装置１０を有する。実在保証装置１０は、法人ｅＫＹＣプロバイダの機能を電子的に実現する１以上のコンピュータである。例えば、ブロバイダサーバは、法人の実在の保証や社員の実在（社員について法人への所属）の確認等を行う。
　認証局は、従来から存在する認証局である。図１において、認証局は、ＣＡサーバ４０を有する。本実施の形態において、ＣＡサーバ４０は、ＡＣＭＥに従って、法人に対してＯＶ（Organization Validation）証明書を発行する。
　図２は、第１の実施の形態における実在保証装置１０のハードウェア構成例を示す図である。図３の実在保証装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
　実在保証装置１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って実在保証装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　図３は、第１の実施の形態における証明書発行支援システムの機能構成例を示す図である。図３において、証明書申請装置２０は、社員認証基盤部２１と、拡張ＡＣＭＥクライアント部２２及び従来ＡＣＭＥクライアント部２３を有する。これら各部は、証明書申請装置２０にインストールされた１以上のプログラムが、証明書申請装置２０のＣＰＵに実行させる処理により実現される。但し、これら各部は、それぞれ異なるコンピュータによって実現されてもよい。証明書申請装置２０は、また、秘密鍵記憶部２４を利用する。秘密鍵記憶部２４は、例えば、証明書申請装置２０の補助記憶装置、又は証明書申請装置２０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
　社員認証基盤部２１は、社員の認証を行うと共に、社員について権限の有無を確認する。
　拡張ＡＣＭＥクライアント部２２及び従来ＡＣＭＥクライアント部２３は、本実施の形態におけるＡＣＭＥクライアントである。ＡＣＭＥクライアントとは、証明書自動発行プロトコルであるＡＣＭＥ（Automatic Certificate Management Environment）をサポートしているＣＡサーバ４０との間で、ＡＣＭＥに基づくやりとりを解釈し証明書発行申請等を行うソフトウェアをいう。
　拡張ＡＣＭＥクライアント部２２は、本実施の形態においてＡＣＭＥプロトコルに対して拡張されるフローを実行する。
　従来ＡＣＭＥクライアント部２３は、従来のＡＣＭＥプロトコルでＣＡサーバ４０と対話する。
　秘密鍵記憶部２４には、実在保証装置１０の法人ＰＫＩ部１２によって検証可能な署名の付与に利用される秘密鍵（以下、「法人秘密鍵」という。）が記憶されている。なお、法人秘密鍵は、法人ＰＫＩ部１２から提供される。
　実在保証装置１０は、法人ｅＫＹＣ部１１及び法人ＰＫＩ部１２を含む。これら各部は、実在保証装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。但し、これら各部は、それぞれ異なるコンピュータによって実現されてもよい。
　法人ｅＫＹＣ部１１は、法人の実在を保証する情報（実在保証情報）を法人に対して提供する。法人ｅＫＹＣ部１１は、法人の実在を保証する情報に対する法人ｅＫＹＣプロバイダによる電子署名の付与を法人ＰＫＩ部１２に実行させる。
　法人ＰＫＩ部１２は、法人に対して一般的なＰＫＩを提供する。例えば、法人ＰＫＩ部１２は、法人に対して公開鍵証明書や法人ｅＫＹＣプロバイダのルート証明書を配布する。
　ＣＡサーバ４０は、証明書発行部４１を有する。証明書発行部４１は、ＣＡサーバ４０にインストールされた１以上のプログラムが、ＣＡサーバ４０のＣＰＵに実行させる処理により実現される。
　証明書発行部４１は、証明書自動発行プロトコルであるＡＣＭＥに基づき電子証明書（本実施の形態では、ＯＶ証明書）の発行を行う。
　以下、証明書発行支援システムにおいて実行される処理手順について説明する。図４は、証明書発行支援システムにおいて実行される処理手順の一例を説明するためのシーケンス図である。なお、図４において、「法人」の軸は、社員端末３０、従来ＡＣＭＥクライアント部２３、拡張ＡＣＭＥクライアント部２２及び社員認証基盤部２１の集合を表現する。また、図４において、ステップＳ１１～Ｓ１３、Ｓ１６及びＳ１７は、従来のＡＣＭＥに基づくステップである。したがって、拡張ＡＣＭＥクライアント部２２は、これらのステップには関与しない。一方、ステップＳ１４及びＳ１５は、ＡＣＭＥに対する拡張のステップである。したがって、従来ＡＣＭＥクライアント部２３は、ステップＳ１４及びＳ１５には関与しない。
　ステップＳ１１において、法人は、ＣＡサーバ４０に対して法人に対するアカウントを登録する。ＣＡサーバ４０は、アカウントの登録結果を返信する（Ｓ１２）。アカウントの登録では、法人の公開鍵（法人秘密鍵に対応する公開鍵（以下、「法人公開鍵」という。））もＣＡサーバ４０に登録される。そうすることで、ＣＡサーバ４０が、以降のステップにおいて法人の認証ができるようにする。すなわち、以降のステップにおいては、従来のＡＣＭＥと同様に、法人からＣＡサーバ４０へのリクエストごとに、ＣＡサーバ４０は、法人の認証を行う。なお、アカウント登録は、一度行われればよい。
　続くステップＳ１３～Ｓ１５の実行順序は順不同であり、これら各ステップは非同期に（それぞれ任意のタイミングで）実行されてよい。
　ステップＳ１３では、法人とＣＡサーバ４０との間で、ＡＣＭＥに従って法人がドメイン（証明書おの申請に係るドメイン）を所持することの確認処理が実行される。
　ステップＳ１４では、法人とＣＡサーバ４０と実在保証装置１０との連携により、法人の実在の確認処理がされる。
　ステップＳ１５では、法人とＣＡサーバ４０と実在保証装置１０との連携により、法人への社員の所属（社員の実在）の確認処理が実行される。
　なお、ＣＡサーバ４０は、ステップＳ１３～Ｓ１５が実行されるたびに、法人について何の確認が完了したのかを示す情報を、法人のアカウントに対応付けて記録する。すなわち、ステップＳ１３が正常終了すれば、ＣＡサーバ４０は、法人がドメインを所持することの確認が完了したことを示す情報を記録する。ステップＳ１４が正常終了すれば、ＣＡサーバ４０は、法人が実在することの確認が完了したことを示す情報を記録する。ステップＳ１５が正常終了すれば、ＣＡサーバ４０は、法人に社員が所属することの確認が完了したことを示す情報を記録する。なお、ステップＳ１３～Ｓ１５の各ステップにおいて、法人の認証が行われるため、ＣＡサーバ４０は、いずれの法人についての確認であるのかを識別することができる。
　ステップＳ１３～Ｓ１５の実行後の任意のタイミングにおいて、法人（例えば、従来ＡＣＭＥクライアント部２３）は、証明書発行要求（CSR（Certificate Signing Request））をＣＡサーバ４０へ送信する（Ｓ１６）。なお、証明書発行要求においても、ＣＡサーバ４０によって法人の認証が行われる。
　ＣＡサーバ４０は、証明書発行要求に応じ、当該証明書発行要求の送信元の法人（当該証明書発行要求に関して認証された法人）について、ステップＳ１３～Ｓ１５のいずれの確認が済んでいるのかを確認する。全ての確認が済んでいれば、ＣＡサーバ４０は、当該法人に対するＯＶ証明書を生成し、当該ＯＶ証明書を法人へ返信する（Ｓ１７）。
　続いて、ステップＳ１４の詳細について説明する。図５は、第１の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。
　ステップＳ１０１において、社員端末３０は、社員による入力（法人の実在保証情報の取得指示）に応じ、法人の実在保証情報を法人ｅＫＹＣ部１１へ要求する。法人ｅＫＹＣ部１１は、社員端末３０からの要求に応じ、認証要求を社員端末３０へ送信する（Ｓ１０２）。なお、当該認証要求が法人ｅＫＹＣ部１１から社員端末３０へ送信されるのは、社員を認証可能な社員認証基盤部２１が法人内（証明書申請装置２０内）にあり、実在保証装置１０では社員を認証できないからである。そこで、法人ｅＫＹＣ部１１部は、当該認証要求が社員認証基盤部２１へリダイレクトされるように、当該認証要求を社員端末３０へ送信する。
　当該認証要求に応じ、社員端末３０は、証明書申請装置２０の社員認証基盤部２１と連携して社員の認証を実行する（Ｓ１０３）。例えば、社員端末３０は、斯かる認証のための社員のＩＤ及びパスワードを入力させる画面を表示する。社員端末３０は、当該画面に入力されたＩＤ及びパスワードを社員認証基盤部２１へ送信する。社員認証基盤部２１は、当該ＩＤ及びパスワードを、予め証明書申請装置２０に記憶されている正しいＩＤ及びパスワードと比較し、両者が一致すれば、社員の認証を成功させる。なお、当該認証は、法人の実在保証情報の取得のため（すなわち、法人ｅＫＹＣ部１１を利用するため）の認証である。
　社員の認証に成功した場合、社員認証基盤部２１は、「法人の実在保証情報を法人ｅＫＹＣ部１１に対して要求する」権限を社員が有するか否かを確認する（Ｓ１０４）。例えば、法人の構成員ごとに権限の有無を示す情報が証明書申請装置２０に記憶されており、社員認証基盤部２１は、当該情報を参照して、社員に権限が有るか否かを確認する。
　社員に権限がある場合、社員認証基盤部２１は、社員に権限があることを法人ｅＫＹＣ部１１に通知する（Ｓ１０５）。なお、斯かる通知は、どのような手順で実行されてもよい。例えば、法人ｅＫＹＣ部１１は、社員が権限を有することを示すデータであるトークンを社員端末３０へ送信し、社員端末３０が当該トークンを法人ｅＫＹＣ部１１に送信してもよい。この場合、法人ｅＫＹＣ部１１が当該トークンを伴って権限の有無を社員認証基盤部２１へ照会すると、社員認証基盤部２１が、当該トークンを検証し、当該トークンが正当であれば権限が有ることの通知を法人ｅＫＹＣ部１１へ応答してもよい。
　社員に権限が有ることの通知に応じ、法人ｅＫＹＣ部１１は、法人の実在保証情報を生成する（Ｓ１０６）。例えば、法人ｅＫＹＣ部１１は、ＪＳＯＮ（JavaScript（登録商標） Object Notation）形式によって、以下のような実在保証情報を生成する。
{"iss":"https://ekyc.example.com","aud":"xxxx","name":"xxxx Corp",・・・}
　なお、上記の実在保証情報において、「xxxx」は、例えば、法人の名称を示す文字列である。
　続いて、法人ｅＫＹＣ部１１は、当該実在保証情報を法人ＰＫＩ部１２に送信して、当該実在保証情報に対する署名（電子署名）の付与を法人ＰＫＩ部１２に要求する（Ｓ１０７）。法人ＰＫＩ部１２は、法人ＰＫＩを用いて、法人ｅＫＹＣプロバイダの秘密鍵によって当該実在保証情報へ署名を行い（当該実在保証情報へ署名を付与し）、署名済みの実在保証情報を法人ｅＫＹＣ部１１へ応答する（Ｓ１０８）。当該署名により、ＣＡサーバ４０は、当該実在保証情報の真正性を確認することができる。
　続いて、法人ｅＫＹＣ部１１は、署名済みの当該実在保証情報を証明書申請装置２０の拡張ＡＣＭＥクライアント部２２へ送信する（Ｓ１０９）。但し、当該実在保証情報は、社員端末３０を経由して拡張ＡＣＭＥクライアント部２２へ送信されてもよい。この場合、法人ｅＫＹＣ部１１は、ステップＳ１０１に対する応答として、当該実在保証情報を社員端末３０へ送信する。社員端末３０は、当該実在保証情報を拡張ＡＣＭＥクライアント部２２へ送信する。
　続いて、拡張ＡＣＭＥクライアント部２２は、当該実在保証情報をＣＡサーバ４０の証明書発行部４１へ送信する（Ｓ１１０）。証明書発行部４１は、当該実在保証情報を受信すると、当該実在保証情報に付与された署名の検証を法人ＰＫＩ部１２に実行させる（Ｓ１１１）。法人ＰＫＩ部１２によって当該署名が正しいことが確認されると、証明書発行部４１は、当該実在保証情報の検証結果を拡張ＡＣＭＥクライアント部２２へ送信する（Ｓ１１２）。なお、証明書発行部４１は、当該実在保証情報を、法人が実在することの確認が完了したことを示す情報としてＣＡサーバ４０に記録する。
　なお、図４では、実在保証情報は、拡張ＡＣＭＥクライアント部２２によって証明書発行部４１へ送信されるが、最終的に実在保証情報が証明書発行部４１に到達するのであれば、どのような手順が採用されてもよい。ＣＡと法人ｅＫＹＣプロバイダが直接連携し、情報を取得してもよい。その際はＯＡｕｔｈ　２．０をベースとする技術が利用されてもよい。
　続いて、図４のステップＳ１５の詳細について説明する。図６は、法人への社員の所属の確認処理の処理手順の一例を説明するためのシーケンス図である。
　ステップＳ２０１において、社員端末３０は、社員による入力（社員の実在保証の要求指示）に応じ、社員の実在保証を社員認証基盤部２１へ要求する。社員認証基盤部２１は、社員端末３０と連携して社員の認証を実行する（Ｓ２０２）。認証により、社員が本人であるか否かが確認される。
　社員の認証に成功すると、社員認証基盤部２１は、社員の実在保証情報を生成する（Ｓ２０３）。例えば、社員認証基盤部２１は、ＪＳＯＮ形式によって、以下のような実在保証情報を生成する。
{"affiliation":"xxx Corp.","name":"yyy",・・・}
　なお、上記の実在保証情報において、「xxx」は、例えば、法人の名称を示す文字列であり、「yyy」は、社員の氏名を示す文字列である。
　なお、社員認証基盤部２１は、生成した実在保証情報に対して法人秘密鍵を用いて署名を行う（署名を付与する）。法人秘密鍵を用いて当該実在保証情報に対して署名が付与されることで、法人によって社員の実在（所属）が保証される。また、証明書発行部４１は、当該署名により当該実在保証情報の真正性を確認することができる。なお、署名は、外部のサービスによって行われてもよい。例えば、法人秘密鍵の管理機能や署名機能が外部サービスによって行われてもよい。
　続いて、社員認証基盤部２１は、署名された当該実在保証情報を拡張ＡＣＭＥクライアント部２２へ送信する（Ｓ２０４）。但し、当該実在保証情報は、社員端末３０を経由して拡張ＡＣＭＥクライアント部２２へ送信されてもよい。この場合、社員認証基盤部２１は、ステップＳ２０１に対する応答として、当該実在保証情報を社員端末３０へ送信する。社員端末３０は、当該実在保証情報を拡張ＡＣＭＥクライアント部２２へ送信する。
　続いて、拡張ＡＣＭＥクライアント部２２は、当該実在保証情報をＣＡサーバ４０の証明書発行部４１へ送信する（Ｓ２０５）。証明書発行部４１は、当該実在保証情報を受信すると、法人ＰＫＩ部１２と連携して、当該実在保証情報に付与された署名を検証する（Ｓ２０６）。換言すれば、法人ＰＫＩ部１２は、証明書発行部４１と連携して、当該実在保証情報に付与された署名を検証する。例えば、証明書発行部４１は、法人ＰＫＩ部１２から法人公開鍵の配布を受けて、当該署名を検証する。但し、法人公開鍵の配布は他の方法（他のタイミング）で行われてもよい。又は、法人ＰＫＩ部１２が、当該実在保証情報に付与された署名を検証し、その結果を証明書発行部４１へ送信してもよい。
　当該署名が正しいことが確認されると、証明書発行部４１は、当該署名の検証結果を社員端末３０へ送信する（Ｓ２０７）。なお、証明書発行部４１は、当該実在保証情報を、法人へ社員が所属することの確認が完了したことを示す情報としてＣＡサーバ４０に記録する。
　上述したように、第１の実施の形態によれば、ＡＣＭＥを拡張することで、法人の実在を電子的に確認することができると共に、法人への社員（申請者）の所属を保証するｅＫＹＣ（（個人の）電子的な身元確認）を実現することができる。その結果、ＯＶ証明書の申請を全て電子的に実行することができ、ひいてはＯＶ証明書の自動的な発行を支援することができる。
　次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。
　第２の実施の形態では、図４のステップＳ１４の処理手順（すなわち、図５の処理手順）の変形例を示す。
　図７は、第２の実施の形態における証明書発行支援システムの機能構成例を示す図である。図７において、実在保証装置１０は、更に、実在保証用認証部１３を有する。実在保証用認証部１３は、実在保証装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
　実在保証用認証部１３は、法人の実在保証のための社員の認証を行う。斯かる認証を可能にするため、第２の実施の形態では、実在保証の要求が許可される社員のアカウントが実在保証装置１０に事前に登録される。斯かるアカウントの登録には、ＳＣＩＭ（System for Cross-Domains Identity Management）が利用されてもよい。
　図８は、第２の実施の形態における法人の実在の確認処理の処理手順の一例を説明するためのシーケンス図である。図８中、図５と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。
　図８では、図５のステップＳ１０２～Ｓ１０５が、ステップＳ１０２ａ～Ｓ１０５ａに置き換わる。
　ステップＳ１０２ａにおいて、法人ｅＫＹＣ部１１は、社員の認証を実在保証用認証部１３へ要求する。当該認証の要求に応じ、実在保証用認証部１３は、社員端末３０と連携して社員の認証を実行する（Ｓ１０３ａ）。例えば、実在保証用認証部１３は、斯かる認証のための社員のＩＤ及びパスワードを入力させる画面を表示させるＷｅｂページを社員端末３０へ送信する。社員端末３０は、当該Ｗｅｂページに基づき当該画面を表示する。社員端末３０は、当該画面に入力されたＩＤ及びパスワードを実在保証用認証部１３へ送信する。実在保証用認証部１３は、当該ＩＤ及びパスワードを、予め登録されているアカウント（正しいＩＤ及びパスワード）と比較し、両者が一致すれば、社員の認証を成功させる。なお、実在保証用認証部１３は、社員認証基盤部２１と連携して社員の認証を行ってもよい。
　社員の認証に成功した場合、実在保証用認証部１３は、「法人の実在保証情報を法人ｅＫＹＣ部１１に対して要求する」権限を社員が有するか否かを確認する（Ｓ１０４ａ）。例えば、斯かる権限を有する者を示す情報が実在保証装置１０に記憶されており、実在保証用認証部１３は、当該情報を参照して、社員に権限が有るか否かを確認する。
　社員に権限がある場合、実在保証用認証部１３は、社員に権限があることを法人ｅＫＹＣ部１１に通知する（Ｓ１０５ａ）。以降は、図５と同様である。
　第２の実施の形態では、社員の認証機能が実在保証装置１０内に存在するため、実在保証装置１０が社員に直接的に認証機能を提供することが可能となる。また、社員に権限が有ることの通知も実在保証装置１０内の連携で済むようになる。
　なお、第１の実施の形態の場合、実在保証装置１０は、実在保証の要求元（申請者）がどの社員であるかまで知る必要はない（法人ｅＫＹＣプロバイダは、権限の有る社員が要求したことしか分からず、社員の誰が要求しているのかまで分からない。）。一方、第２の実施の形態では、法人ｅＫＹＣプロバイダは、当該申請者が社員の誰であるかが分かる。
　なお、上記各実施の形態において、法人は、第１の組織の一例である。法人ｅＫＹＣプロバイダは、第２の組織の一例である。法人ＰＫＩ部１２は、付与部及び検証部の一例である。法人ｅＫＹＣ部１１は、送信部の一例である。法人の実在保証情報は、第１の情報の一例である。社員の実在保証情報は、第２の情報の一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
１０　　　　　実在保証装置
１１　　　　　法人ｅＫＹＣ部
１２　　　　　法人ＰＫＩ部
１３　　　　　実在保証用認証部
２０　　　　　証明書申請装置
２１　　　　　社員認証基盤部
２２　　　　　拡張ＡＣＭＥクライアント部
２３　　　　　従来ＡＣＭＥクライアント部
２４　　　　　秘密鍵記憶部
３０　　　　　社員端末
４０　　　　　ＣＡサーバ
４１　　　　　証明書発行部
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
Ｂ　　　　　　バス

Claims (7)

  1. 　ＯＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とを含む証明書発行支援システムであって、
    　前記実在保証装置は、
    　前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する付与部と、
    　前記第１の電子署名が付与された前記第１の情報を前記証明書申請装置へ送信する送信部と、
    　前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証部と、
    を有し、
    　前記証明書申請装置は、
    　前記第１の電子署名が付与された第１の情報及び前記第２の電子署名が付与された前記第２の情報を、前記ＯＶ証明書の発行を受けるために前記認証局へ送信する、
    ことを特徴とする証明書発行支援システム。
  2. 　前記付与部は、前記構成員が認証された場合に前記第１の情報に対して前記第１の電子署名を付与する、
    ことを特徴とする請求項１記載の証明書発行支援システム。
  3. 　前記証明書申請装置は、ＡＣＭＥ（Automatic Certificate Management Environment）に従った手順に加えて、前記第１の情報及び前記第２の情報の前記認証局への送信を実行する、
    ことを特徴とする請求項１又は２記載の証明書発行支援システム。
  4. 　ＯＶ証明書の発行を認証局へ申請する第１の組織における証明書申請装置と、前記第１の組織の実在を保証する第２の組織が有する実在保証装置とが実行する証明書発行支援方法であって、
    　前記実在保証装置が、
    　前記第１の組織の構成員が利用する端末からの要求に応じ、前記第１の組織の実在を保証する第１の情報に対して第１の電子署名を付与する付与手順と、
    　前記第１の電子署名が付与された前記第１の情報を前記証明書申請装置へ送信する送信手順と、
    　前記証明書申請装置が生成した、前記第１の組織への前記構成員の所属を保証する第２の情報に付与された第２の電子署名を、前記認証局と連携して検証する検証手順と、
    を実行し、
    　前記証明書申請装置が、
    　前記第１の電子署名が付与された第１の情報及び前記第２の電子署名が付与された前記第２の情報を、前記ＯＶ証明書の発行を受けるために前記認証局へ送信する、
    ことを特徴とする証明書発行支援方法。
  5. 　前記付与手順は、前記構成員が認証された場合に前記第１の情報に対して前記第１の電子署名を付与する、
    ことを特徴とする請求項４記載の証明書発行支援方法。
  6. 　前記証明書申請装置は、ＡＣＭＥ（Automatic Certificate Management Environment）に従った手順に加えて、前記第１の情報及び前記第２の情報の前記認証局への送信を実行する、
    ことを特徴とする請求項４又は５記載の証明書発行支援方法。
  7. 　請求項４乃至６いずれか一項記載の証明書発行支援方法において前記実在保証装置が実行する手順をコンピュータに実行させることを特徴とするプログラム。
PCT/JP2020/046126 2020-12-10 2020-12-10 証明書発行支援システム、証明書発行支援方法及びプログラム Ceased WO2022123745A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/250,639 US12278911B2 (en) 2020-12-10 2020-12-10 Certificate issuance support system, certificate issuance support method and program
PCT/JP2020/046126 WO2022123745A1 (ja) 2020-12-10 2020-12-10 証明書発行支援システム、証明書発行支援方法及びプログラム
JP2022567987A JP7485087B2 (ja) 2020-12-10 2020-12-10 証明書発行支援システム、証明書発行支援方法及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/046126 WO2022123745A1 (ja) 2020-12-10 2020-12-10 証明書発行支援システム、証明書発行支援方法及びプログラム

Publications (1)

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

Family

ID=81973467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/046126 Ceased WO2022123745A1 (ja) 2020-12-10 2020-12-10 証明書発行支援システム、証明書発行支援方法及びプログラム

Country Status (3)

Country Link
US (1) US12278911B2 (ja)
JP (1) JP7485087B2 (ja)
WO (1) WO2022123745A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12124616B2 (en) * 2022-06-01 2024-10-22 Intel Corporation Enhancement of trustworthiness of artificial intelligence systems through data quality assessment

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005010301A (ja) * 2003-06-17 2005-01-13 Ricoh Co Ltd 電子証明書、認証方法及び認証プログラム
JP2018074546A (ja) * 2016-11-04 2018-05-10 周樹 是枝 証明書管理装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9467442B2 (en) * 2014-05-23 2016-10-11 Symantec Corporation Automated step-up digital certificate installation process
KR20180135446A (ko) * 2016-04-15 2018-12-20 퀄컴 인코포레이티드 콘텐츠 전달 네트워크에서 보안 콘텐츠 송신들을 관리하는 기법들
US11146407B2 (en) * 2018-04-17 2021-10-12 Digicert, Inc. Digital certificate validation using untrusted data
US12101417B1 (en) * 2020-03-23 2024-09-24 Amazon Technologies, Inc. Interface and manager for multiple certificate authorities
CN111865992B (zh) * 2020-07-23 2021-04-02 亚数信息科技（上海）有限公司 一种acme集中管理系统及其负载均衡方法
US11677728B2 (en) * 2021-08-31 2023-06-13 Coinbase, Inc. Secure authorization and transmission of data between trustless actors

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005010301A (ja) * 2003-06-17 2005-01-13 Ricoh Co Ltd 電子証明書、認証方法及び認証プログラム
JP2018074546A (ja) * 2016-11-04 2018-05-10 周樹 是枝 証明書管理装置

Also Published As

Publication number Publication date
JP7485087B2 (ja) 2024-05-16
US12278911B2 (en) 2025-04-15
JPWO2022123745A1 (ja) 2022-06-16
US20230403164A1 (en) 2023-12-14

Similar Documents

Publication Publication Date Title
CN111316267B (zh) 使用委托身份的认证
JP4744785B2 (ja) セッションキー・セキュリティプロトコル
US7747856B2 (en) Session ticket authentication scheme
CN1701295B (zh) 用于对计算机网格进行单次登录访问的方法和系统
US8996857B1 (en) Single sign-on method in multi-application framework
JP5170648B2 (ja) 権限委譲システム、権限委譲方法および権限委譲プログラム
US8806195B2 (en) User interface generation in view of constraints of a certificate profile
US11503012B1 (en) Client authentication using a client certificate-based identity provider
CN102823217A (zh) 证书机构
EP2262165B1 (en) User generated content registering method, apparatus and system
JP5743946B2 (ja) サービス提供装置、共同署名検証装置、利用者の識別・認証方法及びプログラム
JP2006031064A (ja) セッション管理システム及び管理方法
JP7077272B2 (ja) 証明書発行装置、検証装置、通信機器、証明書発行システム、証明書発行方法、およびプログラム
JP2002101093A (ja) 認証局の公開鍵および秘密鍵満了時の認証のための方法およびシステム
JP2020014168A (ja) 電子署名システム、証明書発行システム、鍵管理システム及び電子証明書発行方法
WO2021107755A1 (en) A system and method for digital identity data change between proof of possession to proof of identity
KR102484533B1 (ko) 인증서를 포함하는 검증 가능 자격 증명을 발행하는 방법 및 그 방법에 의해 발행된 검증 가능 자격 증명을 이용한 인증 방법
JP5036500B2 (ja) 属性証明書管理方法及び装置
JP7485087B2 (ja) 証明書発行支援システム、証明書発行支援方法及びプログラム
JP7574925B2 (ja) 証明書発行支援システム、証明書発行支援方法及びプログラム
JP5139490B2 (ja) サービス提供装置
JPWO2020145163A1 (ja) サービス提供システム、サービス提供装置、サービス提供方法、及びプログラム
Madsen et al. Challenges to supporting federated assurance
JP7548433B2 (ja) 登録申請支援システム及び登録申請支援方法
CN112926044B (zh) 一种身份验证方法和装置

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: 20965127

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022567987

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: 20965127

Country of ref document: EP

Kind code of ref document: A1

WWG Wipo information: grant in national office

Ref document number: 18250639

Country of ref document: US