WO2021153421A1 - 制御方法、サーバ、および、プログラム - Google Patents

制御方法、サーバ、および、プログラム Download PDF

Info

Publication number
WO2021153421A1
WO2021153421A1 PCT/JP2021/002084 JP2021002084W WO2021153421A1 WO 2021153421 A1 WO2021153421 A1 WO 2021153421A1 JP 2021002084 W JP2021002084 W JP 2021002084W WO 2021153421 A1 WO2021153421 A1 WO 2021153421A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction data
signature
reliability
contract
user
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/JP2021/002084
Other languages
English (en)
French (fr)
Japanese (ja)
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.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to CN202180011120.XA priority Critical patent/CN115004630A/zh
Priority to JP2021573978A priority patent/JPWO2021153421A1/ja
Priority to EP21748122.5A priority patent/EP4099612A4/en
Publication of WO2021153421A1 publication Critical patent/WO2021153421A1/ja
Priority to US17/872,584 priority patent/US20220358496A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • 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
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions

Definitions

  • the present invention relates to a control method, a server, and a program.
  • the distributed ledger stores transaction data including managed information and an electronic signature (also simply referred to as a signature) created for the information.
  • the present invention provides a control method for managing information in a distributed ledger with higher reliability.
  • the control method is a control method executed by one of the plurality of servers in an information management system including a plurality of servers having a distributed ledger, and is owned by the user.
  • the transaction data including the signature created by using one of the plurality of signature keys to which the reliability is associated with each of the plurality of signature keys is received and received. It is determined whether or not the reliability associated with the signature key used to create the signature included in the transaction data is equal to or higher than the specified value, and the reliability is the specified value in the determination. When it is determined that the value is equal to or more than the value, the transaction data is stored in the distributed ledger, and when it is determined in the determination that the reliability is less than the specified value, the transaction data is invalidated. Is a control method to execute.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program. And may be realized by any combination of recording media.
  • the control method of the present invention can manage information in a distributed ledger with higher reliability.
  • FIG. 1 is a block diagram schematically showing the configuration of the information management system according to the first embodiment.
  • FIG. 2 is a block diagram showing a first example of the functional configuration of the terminal according to the first embodiment.
  • FIG. 3 is a block diagram showing a second example of the functional configuration of the terminal according to the first embodiment.
  • FIG. 4 is a block diagram showing an example of the functional configuration of the authentication server according to the first embodiment.
  • FIG. 5 is an explanatory diagram showing an example of contract data according to the first embodiment.
  • FIG. 6 is an explanatory diagram showing an example of contract transaction data according to the first embodiment.
  • FIG. 7 is a flow chart showing the processing of the authentication server according to the first embodiment.
  • FIG. 8 is a sequence diagram showing the processing of the information management system according to the first embodiment.
  • FIG. 9 is a sequence diagram showing the processing of the information management system in the modified example of the first embodiment.
  • FIG. 10 is a block diagram showing an example of the functional configuration of the authentication server according to the second embodiment.
  • FIG. 11 is an explanatory diagram showing an example of contract data according to the second embodiment.
  • FIG. 12 is an explanatory diagram showing an example of contract transaction data according to the second embodiment.
  • FIG. 13 is a flow chart showing the processing of the authentication server according to the second embodiment.
  • FIG. 14 is an explanatory diagram showing a data structure of the blockchain.
  • FIG. 15 is an explanatory diagram showing a data structure of transaction data.
  • the distributed ledger stores transaction data including managed information and an electronic signature (also simply referred to as a signature) created for the information, and is managed so as to be substantially tamper-proof.
  • the signature is generated by performing an operation using the user's signature key on the managed information.
  • the user's signature key can be freely created by each user, and the signature key can be freely exchanged if there is an agreement between the users. Therefore, it is possible to hold the signature key of another user and impersonate that user to create a signature to be given to the transaction data.
  • the present invention provides a control method for managing information in a distributed ledger with higher reliability.
  • the control method is a control method executed by one of the plurality of servers in an information management system including a plurality of servers having a distributed ledger, and is owned by the user.
  • the transaction data including the signature created by using one of the plurality of signature keys to which the reliability is associated with each of the plurality of signature keys is received and received. It is determined whether or not the reliability associated with the signature key used to create the signature included in the transaction data is equal to or higher than the specified value, and the reliability is the specified value in the determination. When it is determined that the value is equal to or more than the value, the transaction data is stored in the distributed ledger, and when it is determined in the determination that the reliability is less than the specified value, the transaction data is invalidated. Is a control method to execute.
  • the reliability of the user who gave the signature is estimated based on the reliability of the signature key used to create the signature contained in the transaction data, and the transaction data is used using the reliability. Is stored in the distributed ledger or disabled. Then, when the reliability of the signature key is equal to or higher than the specified value, the transaction data is stored in the distributed ledger, while when it is not, the transaction data is invalidated. Therefore, the transaction data having a relatively high reliability is stored in the distributed ledger. can do. As described above, according to the above control method, information can be managed in the distributed ledger with higher reliability.
  • the specified value is a required reliability, which is a reliability required for the signature key used for creating the signature, which is defined by a requesting user who is a user who requests the user to give a signature.
  • the transaction data may further include the required reliability.
  • transaction data having a relatively high reliability can be stored in the distributed ledger by using the request reliability determined by the requesting user as a specified value. Therefore, according to the above control method, information can be managed more easily and with higher reliability in the distributed ledger.
  • the specified value may be a reliability predetermined according to the content of the transaction data.
  • transaction data having a relatively high reliability can be stored in the distributed ledger by using a predetermined reliability as a predetermined value according to the contents of the transaction data. Therefore, according to the above control method, information can be managed more easily and with higher reliability in the distributed ledger.
  • the invalidation process may include a process of adding invalid information indicating that the transaction data is invalid to the transaction data and storing the transaction data to which the invalid information is added in the distributed ledger. ..
  • the transaction data in which the reliability of the signature key used for creating the signature is less than the specified value is stored in the distributed ledger with invalid information, and the transaction data having a relatively high reliability is stored.
  • transaction data can be stored and managed in the distributed ledger regardless of whether the reliability of the signature key is greater than or equal to the specified value or less than the specified value. Therefore, according to the above control method, all transaction data can be managed by the distributed ledger with higher reliability.
  • the invalidation process may include a process of discarding the transaction data without storing it in the distributed ledger.
  • the transaction data in which the reliability of the signature key used for creating the signature is less than the specified value is discarded, and the transaction data having a relatively high reliability is stored in the distributed ledger as valid transaction data. ..
  • the transaction data whose signature key reliability is less than the specified value is not stored in the distributed ledger, it is possible to suppress an increase in the storage capacity of the storage device in which the distributed ledger is stored. Therefore, according to the above control method, it is possible to manage the information in the distributed ledger with higher reliability while suppressing the storage capacity of the required storage device.
  • the transaction data verification process is executed by the signature included in the received transaction data, and when the verification is successful in the verification process, the determination is made. You may go.
  • the transaction data has not been tampered with or destroyed by determining the reliability of the signature key used for creating the signature for the transaction data whose signature has been successfully verified. NS. Therefore, according to the above control method, the information can be managed by the distributed ledger with higher reliability and without falsification.
  • the transaction data further includes the signature of the requesting user, and when the transaction data is received, the signature of the requesting user and the signature of the user included in the received transaction data. Each of them may execute the transaction data verification process and make the determination when the verification is successful in the verification process.
  • the transaction data is not tampered with or destroyed by determining the reliability of the signature key used for creating the signature for the transaction data in which the verification of a plurality of signatures is successful. Also, it can be confirmed that the contents of the transaction data have been confirmed by a plurality of persons. Therefore, according to the above control method, it is possible to manage the information in the distributed ledger with higher reliability while obtaining confirmation of the contents by a plurality of users.
  • control method is a control method executed by one of the plurality of servers in an authentication system including a plurality of servers having a distributed ledger, and is executed by a user.
  • This is a control method for executing an invalidation process for invalidating the transaction data when it is determined that the data is not obtained.
  • the reliability of the user who gave the signature is estimated based on the attribute of the signature key used to create the signature contained in the transaction data, and the transaction data is obtained using the reliability. Controls whether to store in the distributed ledger or disable it. Then, when the signature key attribute contains at least one of the specified attributes, the transaction data is stored in the distributed ledger, while when not, the transaction data is invalidated, so that the transaction data has a relatively high reliability. Can be stored in the distributed ledger. As described above, according to the above control method, information can be managed in the distributed ledger with higher reliability.
  • the one or more attributes associated with the signature key used to create the signature included in the received transaction data are all of the predetermined one or more specified attributes.
  • the transaction data is stored in the distributed ledger, and the above 1 is stored.
  • the invalidation process for invalidating the transaction data may be executed.
  • the transaction data is stored in the distributed ledger when the signature key attribute includes all of the specified attributes, while the transaction data is invalidated otherwise, so the reliability is relatively high.
  • Transaction data can be stored in the distributed ledger.
  • information can be managed in the distributed ledger with higher reliability.
  • the specified attribute is a request attribute which is an attribute required for the signature defined by a requesting user who is a user who requests the user to give a signature
  • the transaction data further includes the request attribute. But it may be.
  • transaction data with relatively high reliability can be stored in the distributed ledger by using the request attribute defined by the request user as the default attribute. Therefore, according to the above control method, information can be managed more easily and with higher reliability in the distributed ledger.
  • the specified attribute may be a predetermined attribute according to the content of the transaction data.
  • transaction data having a relatively high reliability can be stored in the distributed ledger by using a predetermined attribute as a default attribute according to the content of the transaction data. Therefore, according to the above control method, information can be managed more easily and with higher reliability in the distributed ledger.
  • the invalidation process may include a process of adding invalid information indicating that the transaction data is invalid to the transaction data and storing the transaction data to which the invalid information is added in the distributed ledger. ..
  • transaction data in which the signature key attribute used for creating the signature does not include at least one of the specified attributes is stored in the distributed ledger with invalid information, and the signature attribute is specified.
  • transaction data can be stored and managed in the distributed ledger regardless of whether the signature key attribute includes at least one of the specified attributes or not. Therefore, according to the above control method, all transaction data can be managed by the distributed ledger with higher reliability.
  • the invalidation process may include a process of discarding the transaction data without storing it in the distributed ledger.
  • the transaction data in which the signature key attribute used for creating the signature does not contain at least one of the default attributes is discarded, and the transaction in which the signature attribute contains at least one of the default attributes.
  • since the transaction data whose signature key attribute does not include at least one of the specified attributes is not stored in the distributed ledger it is possible to suppress an increase in the storage capacity of the storage device in which the distributed ledger is stored. Therefore, according to the above control method, it is possible to manage the information in the distributed ledger with higher reliability while suppressing the storage capacity of the required storage device.
  • the transaction data verification process is executed by the signature included in the received transaction data, and when the verification is successful in the verification process, the determination is made. You may go.
  • the transaction data has not been tampered with or destroyed by determining the attribute of the signature key used for creating the signature for the transaction data whose signature has been successfully verified. .. Therefore, according to the above control method, the information can be managed by the distributed ledger with higher reliability and without falsification.
  • the transaction data further includes the signature of the requesting user, and when the transaction data is received, the signature of the requesting user and the signature of the user included in the received transaction data. Each of them may execute the transaction data verification process and make the determination when the verification is successful in the verification process.
  • the transaction data is not tampered with or destroyed by determining the attribute of the signature key used for creating the signature for the transaction data in which the verification of a plurality of signatures is successful. , It can be confirmed that the contents of the transaction data have been confirmed by multiple persons. Therefore, according to the above control method, it is possible to manage the information in the distributed ledger with higher reliability while obtaining confirmation of the contents by a plurality of users.
  • the server according to one aspect of the present invention is one of the plurality of servers in the authentication system including a plurality of servers holding the distributed ledger, and the distributed ledger is stored.
  • a ledger storage unit and a reliability verification unit are provided, and the reliability verification unit is a plurality of signature keys owned by a user, and a plurality of signature keys to which reliability is associated with each of the plurality of signature keys.
  • the server is one of the plurality of servers in an information management system including a plurality of servers having a distributed ledger, and the distributed ledger is stored.
  • the ledger storage unit and the attribute verification unit are provided, and the attribute verification unit includes a signature key owned by the user and created by using a signature key associated with one or more attributes.
  • the one or more attributes associated with the signature key used to create the signature included in the received transaction data after receiving the transaction data are among the predetermined one or more specified attributes. It is determined whether or not at least one specified attribute is included, and when it is determined in the determination that the one or more attributes include the at least one specified attribute, the transaction data is stored in the distributed ledger. It is a server that stores and executes an invalidation process that invalidates the transaction data when it is determined in the determination that the one or more attributes do not include the at least one specified attribute.
  • the program according to one aspect of the present invention is a program that causes a computer to execute the above control method.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program.
  • a recording medium such as a system, an apparatus, an integrated circuit, a computer program or a computer-readable CD-ROM, and the system, the apparatus, the integrated circuit, the computer program.
  • it may be realized by any combination of recording media.
  • FIG. 1 is a block diagram schematically showing the configuration of the information management system 1 according to the present embodiment.
  • Information management system 1 is a system that manages various types of information using a distributed ledger.
  • the information managed by the information management system 1 is information related to a sales contract concluded between the user A and the user B.
  • the information management system 1 includes authentication servers 310, 320, and 330.
  • the authentication server 310 is a server device that manages information on sales contracts using a distributed ledger.
  • the authentication server 310 is one of a plurality of servers that have a distributed ledger.
  • Transaction data also referred to as contract transaction data
  • the contract transaction data includes a signature given using a signature key associated with reliability. The processing, reliability, data structure of contract transaction data, and the like of the authentication server 310 will be described in detail later.
  • the authentication servers 320 and 330 are server devices that manage information on sales contracts using a distributed ledger, and operate independently of the authentication server 310.
  • the authentication servers 310, 320, and 330 may be connected so as to be communicable, and their physical positions may be anywhere. Further, the authentication server 310 and the like may be owned or managed by a single business operator or person, or may be owned or managed by a plurality of business operators or people.
  • the number of authentication servers 310 and the like is 3 will be described as an example, a larger number may be used.
  • the terminal 100 is an information terminal owned by the user A.
  • the terminal 100 receives an operation related to the contract by the user A, and communicates with the authentication server 310 or the like or the terminal 200 based on the operation. Further, the terminal 100 receives information about the contract from the authentication server 310 or the like or the terminal 200, and presents the information to the user A by screen display or voice.
  • the terminal 100 is, for example, a smartphone, a tablet, a personal computer, or the like.
  • the terminal 200 is an information terminal owned by user B.
  • the terminal 200 receives an operation related to the contract by the user B, and communicates with the authentication server 310 or the like or the terminal 100 based on the operation. Further, the terminal 200 receives information about the contract from the authentication server 310 or the like or the terminal 100, and presents the information to the user B by screen display or voice.
  • the terminal 200 is, for example, a smartphone, a tablet, a personal computer, or the like.
  • the terminal 100 and the terminal 200 may communicate with each other without going through the authentication server 310 or the like.
  • the information management system 1 may further include one or both of the terminal 100 owned by the user A and the terminal 200 owned by the user B.
  • the processing of the information management system 1, the terminals 100 and 200 when the information management system 1 manages the information regarding the sales contract between the user A and the user B by using the distributed ledger will be described.
  • the user A is a seller who intends to sell a product to an unspecified person
  • the user B is a purchaser who intends to purchase a product sold by the user A.
  • the information management system 1 manages information regarding a sales contract when the user A sells a product to the user B in response to the purchase request of the user B.
  • FIG. 2 is a block diagram showing a functional configuration of the terminal 100, which is a first example of the functional configuration of the terminal in the present embodiment.
  • the terminal 100 includes a contract determination unit 101, a condition determination unit 102, a data creation unit 103, and a communication unit 104.
  • Each functional unit included in the terminal 100 can be realized by the CPU (Central Processing Unit) (not shown) included in the terminal 100 executing a predetermined program using the memory.
  • CPU Central Processing Unit
  • the contract determination unit 101 is a functional unit that determines the content of the contract (also referred to as the contract content) concluded between the user A and the user B and generates information indicating the contract content. Specifically, the contract determination unit 101 determines the content of the sales contract concluded between the user A and the user B.
  • the contents of the sales contract may include, for example, information (product number, etc.) that identifies the product that the user A sells to the user B, information such as the quantity, delivery date, delivery destination, and price of the product.
  • the contract decision unit 101 identifies a person (also referred to as a contractor) who concludes a contract. Not all contractors need to be defined at the time of deciding the contract details. In that case, the contract determination unit 101 may at least generate information that identifies the contractor that is determined at the time of determining the contract content.
  • the condition determination unit 102 is a functional unit that determines conditions related to the reliability of the signature required of the user B who is the other party to conclude a contract with the user A.
  • An example of the condition regarding the reliability of the signature required of the other party to conclude the contract is that the reliability of the signature given to the contract transaction data by the other party to conclude the contract is equal to or higher than the specified value.
  • the default value is, for example, the required trust, which is the reliability required for the signature defined by the user A, that is, the user who requests the user B who concludes the contract to give the signature (also referred to as the requesting user). Degree. The reliability will be described in detail later.
  • the data creation unit 103 is a functional unit that creates contract data indicating the contents of the contract concluded between the user A and the user B.
  • the data creation unit 103 acquires the contract content determined by the contract determination unit 101, and creates contract data including the contract content.
  • the condition determination unit 102 determines the required reliability as a specified value
  • the contract determination unit 101 acquires the required reliability and creates contract data including the above contract contents and the required reliability. do.
  • the data creation unit 103 transmits the created contract data to the terminal 200 via the communication unit 104.
  • the data creation unit 103 When the user A's signature is given to the contract data created by the data creation unit 103, the data creation unit 103 performs an operation using the user A's signature key on the information indicating the contract content. Create a signature and generate contract data with the created signature. In this case, it is assumed that the data creation unit 103 holds the signature key of the user A in advance.
  • the communication unit 104 is a communication interface that is communicably connected to the authentication server 310 and the like and the terminal 200.
  • the communication unit 104 is used for transmitting contract data and the like.
  • FIG. 3 is a block diagram showing a functional configuration of the terminal 200, which is a second example of the functional configuration of the terminal in the present embodiment.
  • the terminal 200 includes a key storage unit 201, a contract acquisition unit 202, a signature creation unit 203, a transaction creation unit 204, and a communication unit 205.
  • Each functional unit included in the terminal 200 can be realized by a CPU (not shown) included in the terminal 200 executing a predetermined program using a memory, and can be realized by a storage device.
  • the key storage unit 201 has a storage device in which the signature key of the user B is stored.
  • a plurality of signature keys of user B are stored in the key storage unit 201.
  • a reliability is associated with each of the plurality of signature keys of the user B.
  • the reliability is an index indicating the high reliability of the signature key.
  • the reliability is an index showing the reliability of the signature key in three stages, for example.
  • the three levels of reliability are expressed as "gold” which means relatively high reliability, "silver” which means medium reliability, and “bronze” which means relatively low reliability. ..
  • the signature key having the reliability of gold and the signature generated by the signature key are referred to as "gold key” and "gold signature", respectively.
  • a signature key having silver reliability and a signature generated by the signature key are referred to as a “silver key” and a “silver signature”, respectively.
  • a signature key having bronze reliability and a signature generated by the signature key are referred to as a “bronze key” and a “bronze signature”, respectively.
  • the expression of the reliability of three levels is not limited to this, and may be expressed as “high”, “medium” and “low”, or may be expressed as “3", “2” and “1”. good. Further, the number of reliability stages may be any number as long as it is 2 or more.
  • the reliability associated with the signature key can be determined by various factors. For example, the reliability associated with the signing key may be determined by the person who created the signing key. For example, a signature key created by the user himself, a signature key created by a trusted organization, a signature key created by an organization certified by the country, prefecture or municipality, a signature key created by a listed company, or publicly recognized. Different credibility may be associated with each signature key created by the company.
  • the reliability associated with the signature key may be determined according to the degree of trust of the user himself / herself.
  • the signature key of a user who has done socially good acts donations, fundraising, volunteer activities, etc.
  • a user with a relatively high income or a user who has no criminal history
  • a reliability higher than the associated reliability may be associated.
  • the reliability associated with the signature key may be determined according to the identity verification document submitted when the user requests the institution to create the signature key. For example, the reliability may be determined depending on whether the family register, resident's card, driver's license, My Number card, identification card (ID), face photo, insurance card or passport is submitted.
  • the information that identifies the creator of the signature key may be managed by the distributed ledger so that it cannot be tampered with.
  • the contract acquisition unit 202 is a functional unit that acquires information indicating the contract details.
  • the contract acquisition unit 202 acquires the contract content included in the contract data transmitted by the terminal 100 as information indicating the contract content.
  • the contract acquisition unit 202 confirms that the acquired contract content is appropriate.
  • the confirmation of the contract contents may be performed by a confirmation process by a computer, or may be performed by receiving the result of confirmation of the contract contents by a person.
  • the signature creation unit 203 is a functional unit that creates the signature of user B.
  • the signature creation unit 203 refers to the contract transaction data created by the transaction creation unit 204, and signs the contract transaction data by performing an operation using the signature key of the user B stored in the key storage unit 201. To create.
  • the signature creation unit 203 provides the created signature to the transaction creation unit 204.
  • the transaction creation unit 204 is a functional unit that creates contract transaction data indicating the contents of the contract based on the contract data.
  • the transaction creation unit 204 acquires the contract data acquired by the contract acquisition unit 202, and generates contract transaction data including the information included in the contract data. Further, the transaction creation unit 204 acquires the signature of the user B to be included in the contract transaction data to be created from the signature creation unit 203, and generates the contract transaction data including the acquired signature. It is assumed that the signature acquired by the transaction creation unit 204 from the signature creation unit 203 is a signature created by a signature key having a reliability equal to or higher than the required reliability included in the contract data.
  • the transaction creation unit 204 transmits the created contract transaction data to the authentication server 310 or the like via the communication unit 205.
  • the communication unit 205 is a communication interface that is communicably connected to the authentication server 310 and the like and the terminal 100.
  • the communication unit 205 is used for receiving contract data, transmitting contract transaction data, and the like.
  • FIG. 4 is a block diagram showing an example of the functional configuration of the authentication server 310 according to the present embodiment.
  • the authentication server 310 includes a ledger storage unit 301, a reliability verification unit 302, a validity verification unit 303, and a communication unit 304.
  • Each functional unit included in the authentication server 310 can be realized by a CPU (not shown) included in the authentication server 310 executing a predetermined program using a memory, or can be realized by a storage device.
  • the ledger storage unit 301 has a storage device for storing the distributed ledger and a processing unit for storing contract transaction data in the distributed ledger.
  • the ledger storage unit 301 acquires contract transaction data whose validity has been verified by the validity verification unit 303 and whose reliability has been verified by the reliability verification unit 302, and stores it in the distributed ledger. Further, the ledger storage unit 301 transmits the contract transaction data to an authentication server (that is, authentication servers 320 and 330) different from the own device, and stores the contract transaction data in the distributed ledger stored in the authentication server.
  • the distributed ledger stored in the ledger storage unit 301 stores one or more contract transaction data, and is managed so as to be difficult to falsify by using characteristics such as a hash value (described later).
  • the distributed ledger is, for example, a blockchain, and this case will be described as an example, but it is also possible to adopt another type of distributed ledger (for example, IOTA or hash graph).
  • the distributed ledger may execute a consensus algorithm (for example, PBFT (Practical Byzantine Facility Resource), PoW (Proof of Work) or PoS (Proof of Stake)) when storing new transaction data. However, it may not be executed.
  • PBFT Practice Byzantine Facility Resource
  • PoW Proof of Work
  • PoS Proof of Stake
  • Hyperledger fabric is an example of a distributed ledger technology that does not execute a consensus algorithm.
  • the reliability verification unit 302 is a functional unit that verifies the reliability of the signature key used to create the signature of the contract transaction data.
  • the reliability verification unit 302 acquires the contract transaction data (described later) whose validity has been verified by the validity verification unit 303, and trusts the signature key used to create the signature given to the acquired contract transaction data.
  • the reliability of the contract transaction data is verified by determining whether or not the degree is equal to or higher than the specified value.
  • the reliability verification unit 302 determines in the above determination that the reliability of the signature key is equal to or higher than the specified value, the reliability verification unit 302 provides the contract transaction data to the ledger storage unit 301 and stores it in the distributed ledger.
  • the reliability verification unit 302 determines in the above determination that the reliability of the signature key is less than the specified value, the reliability verification unit 302 executes an invalidation process for invalidating the contract transaction data.
  • the invalidation process may include, for example, a process of adding invalid information indicating that the contract transaction data is invalid to the contract transaction data and storing the contract transaction data to which the invalid information is added in the distributed ledger. Further, the invalidation process may include a process of discarding the contract transaction data without storing it in the distributed ledger.
  • the "signature key used to create the signature" is also referred to as the "signature key of the signature".
  • the validity verification unit 303 is a functional unit that verifies the validity of contract transaction data.
  • the validity verification unit 303 receives the contract transaction data transmitted by the terminal 200 via the communication unit 304, and uses the signature given to the received contract transaction data to provide information included in the contract transaction data. Is justified, that is, it has not been tampered with or destroyed.
  • the received contract transaction data includes the request reliability.
  • the legitimacy verification unit 303 provides the reliability verification unit 302 with the contract transaction data that has been verified to be legitimate, that is, the verification process has been successful.
  • the validity verification unit 303 performs verification processing using each of the signatures of the two parties. ..
  • the communication unit 304 is a communication interface that is communicably connected to the terminals 100 and 200 and other authentication servers 320 and 330.
  • the communication unit 304 is used for transmitting or receiving contract transaction data.
  • FIG. 5 is an explanatory diagram showing an example of contract data in the present embodiment.
  • the contract data includes the fields of contractors 1 and 2, contract details, required reliability, and signatures 1 and 2.
  • the contract data is created by the contract determination unit 101.
  • the contractor 1 is identification information indicating one of the contractors of the contract related to the contract data, and may be any information as long as it is an identifier that can uniquely identify the contractor. In the sales contract in which the user A sells the product, it is determined that one of the contractors is the user A who is the seller at the time when the contract data is created. Therefore, the contractor 1 is the user A. (Described as "User A" in FIG. 5).
  • the contractor 2 is identification information indicating one contractor excluding the contractor 1 among the contractors of the contract related to the contract data, and any information as long as it is an identifier that can uniquely identify the contractor. You may.
  • the contractor 2 may or may not be specified at the time when the contract data is created.
  • FIG. 5 shows a case where the tightener 2 is not determined as an example, and includes information indicating that the tightener 2 is undecided.
  • the concluding party 2 includes the identification information of the user B.
  • the contract content is information indicating the content of the sales contract.
  • the contract content may include, for example, information that identifies a product to be sold (such as a product number), information such as the quantity, delivery date, delivery destination, and price of the product.
  • the contents of the contract shown in FIG. 5 are that the product number of the product to be sold is "A001", the quantity of the product is "100”, the delivery date is "February 1, 2020", and the price is "10". It shows that it is "1,000 yen”.
  • the required reliability is the reliability of the signing key required to sign this contract.
  • the request reliability is, for example, the reliability of the signature key used to create the signature requested by the user A from the user B.
  • the required reliability shown in FIG. 5 is gold.
  • Signature 1 is the signature of one of the contractors of the contract related to the contract data. In the sales contract in which the user A sells the product, since it is determined that one of the contractors is the user A at the time when the contract data is created, the signature 1 is the gold of the user A. It has been signed. Signature 1 is not essential.
  • Signature 2 is the signature of one of the contractors of the contract related to the contract data, excluding the contractor 1. Similar to the above description in the contractor 2, in the sales contract in which the user A sells the product, the contractor 2 may or may not be determined at the time when the contract data is created.
  • FIG. 5 shows a case where the concluding party 2 has not been determined as an example, and it is shown that the signature 2 has not been attached yet (indicated as “ ⁇ ” in FIG. 5).
  • FIG. 6 is an explanatory diagram showing an example of contract transaction data in the present embodiment.
  • the contract transaction data includes contractors 1 and 2, contract details, required reliability, and signatures 1 and 2.
  • the contract transaction data is created by the transaction creation unit 204.
  • the contract transaction data includes the fields of contractors 1 and 2, contract details, required reliability, and signatures 1 and 2.
  • the role of each field contained in the contract transaction data is the same as in the contract data. However, since one of the contractors except user A is determined to be user B at the time when the contract transaction data is created, the fields of the contractor 2 and the signature 2 are different from those in the contract data.
  • both users A and B have been identified. Since the contractor 2 is identified to the user B at the time of generating the contract transaction data, the contractor 2 includes the identification information of the user B (described as "user B" in FIG. 6), and the signature 2 Includes User B's Gold Signature.
  • FIG. 7 is a flow chart showing the processing of the authentication server 310 in the present embodiment.
  • the process shown in FIG. 7 shows the process executed when the authentication server 310 receives the contract transaction data from the terminal 200.
  • the authentication server 320 or 330 receives the contract transaction data from the terminal 200, the authentication server 320 or 330 executes the same process.
  • step S101 the validity verification unit 303 determines whether or not the contract transaction data has been received. If it is determined that the contract transaction data has been received (Yes in step S101), the process proceeds to step S102, and if not (No in step S101), step S101 is executed again. That is, the validity verification unit 303 waits in step S101 until it receives the contract transaction data.
  • step S102 the validity verification unit 303 determines whether or not the contract transaction data received in step S101 is valid. If it is determined that the contract transaction data is valid (Yes in step S102), the process proceeds to step S103, and if not (No in step S102), the process proceeds to step S111.
  • step S103 the reliability verification unit 302 determines whether or not the reliability of the signature key used for creating the signature given to the contract transaction data determined to be valid in step S102 is equal to or higher than the specified value. To judge. If it is determined that the reliability of the signing key is equal to or higher than the specified value (Yes in step S103), the process proceeds to step S104, and if not (No in step S103), the process proceeds to step S121.
  • step S104 the ledger storage unit 301 stores the contract transaction data determined in step S103 that the reliability of the signature key is equal to or higher than the specified value in the distributed ledger.
  • the contract transaction data is stored in the distributed ledger of another authentication server.
  • the consensus algorithm may or may not be executed when storing the contract transaction data in the distributed ledger.
  • step S111 the reliability verification unit 302 discards the contract transaction data determined to be invalid in step S102.
  • step S112 the reliability verification unit 302 performs error processing in connection with discarding the contract transaction data in step S111.
  • the error processing includes, for example, a processing of adding information indicating that the contract transaction data has been destroyed to the log of the authentication server 310. Note that step S112 does not have to be executed.
  • step S121 the reliability verification unit 302 executes invalidation processing for the contract transaction data determined to be invalid in step S103.
  • step S122 when invalid information is added to the contract transaction data in the invalidation process of step S121, the ledger storage unit 301 stores the contract transaction data to which the invalid information is added in the distributed ledger.
  • the execution of the consensus algorithm is the same as in step S104.
  • FIG. 8 is a sequence diagram showing the processing of the information management system 1 in the present embodiment.
  • the process shown in FIG. 8 shows the process executed when the authentication server 310 receives the contract transaction data from the terminal 200.
  • the authentication server 320 or 330 receives the contract transaction data from the terminal 200, the same process is executed.
  • the same processes as those shown in FIG. 7 may be designated by the same reference numerals and detailed description thereof may be omitted.
  • step S201 the data creation unit 103 of the terminal 100 creates contract data.
  • the contract data created includes the required reliability.
  • step S202 the data creation unit 103 of the terminal 100 transmits the contract data created in step S201 to the terminal 200.
  • the contract acquisition unit 202 of the terminal 200 receives the transmitted contract data.
  • step S203 the contract acquisition unit 202 of the terminal 200 confirms that the contract content included in the contract data received in step S202 is appropriate.
  • step S204 the signature creation unit 203 of the terminal 200 creates a signature to be attached to the contract transaction data generated by the transaction creation unit 204 using the signature key of the user B.
  • the signature creation unit 203 creates a gold signature using the gold key of the user B.
  • step S205 the transaction creation unit 204 of the terminal 200 creates the contract transaction data with the signature created in step S204.
  • step S206 the transaction creation unit 204 of the terminal 200 transmits the contract transaction data created in step S205 to the authentication server 310.
  • the authentication server 310 receives the contract transaction data transmitted in step S206, verifies the validity by the legitimacy verification unit 303, verifies the reliability by the reliability verification unit 302, and then inputs the contract transaction data. Store in the distributed ledger (steps S101 to S104).
  • the information management system 1 can manage information in the distributed ledger with higher reliability.
  • the specified value of the signature reliability in the condition relating to the signature reliability required by the condition determination unit 102 may be predetermined in the information management system 1.
  • the specified value of the reliability may be a predetermined reliability according to the contents of the contract transaction data.
  • the condition determination unit 102 determines the above conditions in the information management system 1 using a reliability predetermined according to the contents of the contract transaction data. In that case, the required reliability does not need to be included in the contract data created by the data creation unit 103.
  • FIG. 9 is a sequence diagram showing the processing of the information management system 1A in this modified example.
  • the same processes as those shown in FIG. 8 may be designated by the same reference numerals and detailed description thereof may be omitted.
  • step S211 the data creation unit 103 of the terminal 100 creates contract transaction data indicating the contents of the contract concluded between the user A and the user B.
  • the contract transaction data created by the data creation unit 103 is generated in place of the contract data in the first embodiment.
  • the content of the contract transaction data is the same as the contract data in the first embodiment (see FIG. 5).
  • step S212 the data creation unit 103 transmits the created contract transaction data to the authentication server 310 via the communication unit 104.
  • the ledger storage unit 301 of the authentication server 310 receives the transmitted contract transaction data.
  • step S213 the authentication server 310 stores the contract transaction data received in step S212 in the distributed ledger.
  • the consensus algorithm may or may not be executed.
  • step S214 the contract acquisition unit 202 of the terminal 200 transmits a request for contract transaction data to the authentication server 310.
  • the ledger storage unit 301 of the authentication server 310 receives the request for contract transaction data.
  • step S215 the ledger storage unit 301 of the authentication server 310 transmits the contract transaction data to the terminal 200 in response to receiving the above request.
  • the contract acquisition unit 202 of the terminal 200 receives the transmitted contract transaction data.
  • the terminal 200 confirms the contract contents included in the received contract transaction data, generates the contract transaction data with a signature based on the above contract contents, transmits it to the authentication server 310, and stores it in the distributed ledger. (Steps S203 to S104).
  • the information management system 1A can manage information in the distributed ledger with higher reliability.
  • the information management system of the present embodiment the terminals 100 and 200 provided in the information management system, the authentication servers 310, 320, 330, and the like are substantially the same as those in the first embodiment, but are linked to the signature key. The difference is that the attribute associated with the signing key is used instead of the reliability attached.
  • the terminal 100 in this embodiment will be described.
  • the terminal 100 in the present embodiment is the same as the terminal 100 in the first embodiment, but the condition determination unit 102 and the data creation unit 103 are different from those in the terminal 100 of the first embodiment.
  • the condition determination unit 102 determines the conditions related to the signature attribute requested from the user B who is the partner who concludes the contract with the user A.
  • An example of the condition regarding the signature attribute required from the contracting party is that the signature attribute given to the contract transaction data by the contracting party includes at least one of the specified attributes (also referred to as the specified attribute).
  • the condition is that there is, and this case will be described, but the present invention is not limited to this.
  • the attribute is, for example, a request attribute which is an attribute required for the signature defined by user A (also referred to as a requesting user) who is a user who requests the user B who is the other party to conclude a contract to give a signature.
  • the attributes will be described in detail later.
  • the data creation unit 103 creates contract data indicating the contents of the contract concluded between the user A and the user B.
  • the data creation unit 103 acquires the contract content determined by the contract determination unit 101, and creates contract data including the contract content.
  • the condition determination unit 102 determines the request attribute as the specified attribute
  • the contract determination unit 101 acquires the request attribute and creates contract data including the above contract contents and the request attribute.
  • the data creation unit 103 transmits the created contract data to the terminal 200 via the communication unit 104.
  • the terminal 200 in this embodiment will be described.
  • the terminal 200 in the present embodiment is the same as the terminal 200 in the first embodiment, but the key storage unit 201 and the signature creation unit 203 are different from those in the terminal 100 of the first embodiment.
  • the key storage unit 201 has a storage device in which the signature key of the user B is stored.
  • a plurality of signature keys of user B are stored in the key storage unit 201.
  • An attribute is associated with each of the plurality of signature keys of the user B.
  • the attribute is an index showing the characteristic or property of the user B. Attributes indicate, for example, nationality, address, age, gender, income status, debt status, or criminal history.
  • the signature creation unit 203 is a functional unit that creates the signature of user B.
  • the signature creation unit 203 refers to the contract transaction data created by the transaction creation unit 204, and signs the contract transaction data by performing an operation using the signature key of the user B stored in the key storage unit 201. To create.
  • the signature creation unit 203 provides the created signature to the transaction creation unit 204.
  • the authentication server 310A in this embodiment will be described.
  • FIG. 10 is a block diagram showing an example of the functional configuration of the authentication server 310A according to the present embodiment.
  • the authentication server 310A includes a ledger storage unit 301, an attribute verification unit 302A, a validity verification unit 303, and a communication unit 304.
  • Each functional unit included in the authentication server 310A can be realized by a CPU (not shown) included in the authentication server 310A executing a predetermined program using a memory, or can be realized by a storage device.
  • the ledger storage unit 301 is the same as that provided by the authentication server 310 in the first embodiment.
  • the attribute verification unit 302A is a functional unit that verifies the attributes of the signature key used to create the signature of the contract transaction data.
  • the attribute verification unit 302A acquires the contract transaction data (described later) whose validity has been verified by the validity verification unit 303, and associates it with the signature key used to create the signature given to the acquired contract transaction data.
  • the attributes of the contract transaction data are verified by determining whether or not the specified attributes (also simply referred to as "attributes of the contract transaction data”) include at least one of the specified attributes.
  • the attribute verification unit 302A determines in the above determination that the attribute of the contract transaction data includes at least one of the specified attributes, the attribute verification unit 302A provides the contract transaction data to the ledger storage unit 301 and stores it in the distributed ledger. Further, when it is determined in the above determination that the attribute of the contract transaction data does not include at least one of the specified attributes, the attribute verification unit 302A executes an invalidation process for invalidating the contract transaction data.
  • the invalidation process is the same as in the first embodiment.
  • all of the specified attributes may be used as "at least one of the specified attributes". That is, the attribute verification unit 302A determines whether or not the attributes of the signature key used for creating the signature given to the acquired contract transaction data include all of the specified attributes, thereby performing the contract transaction data. You may verify the attributes of. In this case, if the attribute verification unit 302A determines in the above determination that the attributes of the contract transaction data include all of the specified attributes, the attribute verification unit 302A provides the contract transaction data to the ledger storage unit 301 and stores it in the distributed ledger. .. Further, when the attribute verification unit 302A determines in the above determination that the attributes of the contract transaction data do not include all of the specified attributes, the attribute verification unit 302A executes an invalidation process for invalidating the contract transaction data.
  • the validity verification unit 303 is the same as the validity verification unit 303 in the first embodiment.
  • the contract transaction data received by the validity verification unit 303 includes a request attribute.
  • the legitimacy verification unit 303 provides the attribute verification unit 302A with the contract transaction data that has been verified to be legitimate, that is, the verification process is successful.
  • the validity verification unit 303 performs verification processing using each of the signatures of the two parties. ..
  • FIG. 11 is an explanatory diagram showing an example of contract data in the present embodiment.
  • the contract data includes the fields of contractors 1 and 2, contract details, request attributes, and signatures 1 and 2.
  • the contract data is created by the contract determination unit 101.
  • the fields excluding the request attribute and the signatures 1 and 2 are the same as those in the first embodiment, and thus the description thereof will be omitted.
  • the request attribute is the attribute of the signing key required for this contract.
  • the request attribute is, for example, an attribute of the signature key used for creating the signature requested by the user A from the user B.
  • the nationality attribute is "Japan”
  • the age attribute is "30s”
  • the gender attribute is "male”.
  • Signature 1 is the signature of one of the contractors of the contract related to the contract data.
  • the signature 1 is the signature of the user A.
  • S is given.
  • the attributes associated with the signature key used to create the signature S are that the nationality attribute is "Japan” and the age attribute is "30s”. , The gender attribute is "male”.
  • Signature 2 is the signature of one of the contractors of the contract related to the contract data, excluding the contractor 1.
  • FIG. 11 shows a case where the concluding party 2 has not been determined as an example, and it is shown that the signature 2 has not been attached yet.
  • FIG. 12 is an explanatory diagram showing an example of contract transaction data in the present embodiment.
  • the contract transaction data includes the fields of contractors 1 and 2, contract details, request attributes, and signatures 1 and 2.
  • the contract transaction data is created by the transaction creation unit 204.
  • the fields other than the required attributes are the same as those in the first embodiment, and thus the description thereof will be omitted.
  • the fields of the request attribute are the same as those in the contract data, the description thereof will be omitted.
  • the contractor 2 is specified to the user B at the time of generating the contract transaction data, the contractor 2 includes the identification information of the user B, and the signature 2 includes the signature T of the user B. ..
  • the attributes associated with the signature key used to create the signature T are that the nationality attribute is "Japan” and the age attribute is "30s”. , The gender attribute is "male”.
  • FIG. 13 is a flow chart showing the processing of the authentication server 310A in the present embodiment.
  • step S103A the processes other than step S103A are the same as those in the first embodiment.
  • step S103A the attribute verification unit 302A indicates whether the attribute of the signature key used for creating the signature given to the contract transaction data determined to be valid in step S102 includes at least one of the specified attributes. Judge whether or not. If it is determined that the signature key attribute includes at least one of the specified attributes (Yes in step S103A), the process proceeds to step S104, and if not (No in step S103A), the process proceeds to step S121.
  • step S103 of the processing of the information management system 1 (FIG. 8) in the first embodiment
  • step S103A of FIG. Detailed description will be omitted.
  • the information management system can manage the information in the distributed ledger with higher reliability.
  • the signature defining attribute in the condition relating to the signature attribute requested by the condition determination unit 102 may be predetermined in the information management system.
  • the definition attribute of the reliability may be a predetermined attribute according to the content of the contract transaction data.
  • the condition determination unit 102 determines the above conditions in the information management system using predetermined attributes according to the contents of the contract transaction data.
  • the contract data created by the data creation unit 103 does not need to include the request attribute.
  • one attribute value is set as a request attribute for each attribute, but a plurality of attribute values may be set as a request attribute.
  • the attribute verification unit 302A determines whether or not the attribute of the signature key used for creating the signature given to the contract transaction data includes at least one attribute value of the specified attribute. For example, if the nationality attribute included in the request attribute is "Japan” or "America", the signature key regardless of whether the nationality attribute associated with the signature key is "Japan” or "America”. It may be determined that the attribute of is included in the specified attribute.
  • a condition that combines the attribute values of a plurality of attributes may be set. For example, even if you set a condition that combines the attributes of nationality and age, such as nationality is "Japan” and age is "30s", or nationality is "America” and age is “40s”. good.
  • the attribute verification unit 302A determines that the attribute of the signing key includes the specified attribute when the condition of combining the attribute values of the plurality of attributes is satisfied.
  • FIG. 14 is an explanatory diagram showing the data structure of the blockchain.
  • a blockchain is a chain of blocks, which is the recording unit.
  • Each block has a plurality of transaction data and a hash value of the immediately preceding block.
  • the block B2 contains the hash value of the previous block B1.
  • the hash value calculated from the plurality of transaction data included in the block B2 and the hash value of the block B1 is included in the block B3 as the hash value of the block B2.
  • FIG. 15 is an explanatory diagram showing a data structure of transaction data.
  • the transaction data shown in FIG. 15 includes a transaction body P1 and a digital signature P2.
  • the transaction body P1 is a data body included in the transaction data.
  • the electronic signature P2 is generated by signing the hash value of the transaction body P1 with the signature key of the creator of the transaction data, and more specifically, encrypting it with the private key of the creator. be.
  • each component may be configured by dedicated hardware or may be realized by executing a software program suitable for each component.
  • Each component may be realized by a program execution unit such as a CPU or a processor reading and executing a software program recorded on a recording medium such as a hard disk or a semiconductor memory.
  • the software that realizes the content management system of the above embodiment is the following program.
  • this program is a control method executed by one of the plurality of servers in an information management system including a plurality of servers having a distributed ledger in the computer, and is a plurality of control methods owned by the user.
  • the transaction data including the signature created by using any of the plurality of signature keys whose reliability is associated with each of the plurality of signature keys, and the received transaction data. It is determined whether or not the reliability associated with the signature key used to create the signature included in is equal to or higher than the specified value, and in the determination, the reliability is equal to or higher than the specified value.
  • an invalidation process for invalidating the transaction data is executed. It is a program that executes the control method.
  • the present invention can be used in an information management system that manages various types of information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
PCT/JP2021/002084 2020-01-31 2021-01-21 制御方法、サーバ、および、プログラム Ceased WO2021153421A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN202180011120.XA CN115004630A (zh) 2020-01-31 2021-01-21 控制方法、服务器以及程序
JP2021573978A JPWO2021153421A1 (https=) 2020-01-31 2021-01-21
EP21748122.5A EP4099612A4 (en) 2020-01-31 2021-01-21 CONTROL METHOD, SERVER AND PROGRAM
US17/872,584 US20220358496A1 (en) 2020-01-31 2022-07-25 Control method, server, and recording medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062968425P 2020-01-31 2020-01-31
US62/968,425 2020-01-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/872,584 Continuation US20220358496A1 (en) 2020-01-31 2022-07-25 Control method, server, and recording medium

Publications (1)

Publication Number Publication Date
WO2021153421A1 true WO2021153421A1 (ja) 2021-08-05

Family

ID=77079906

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/002084 Ceased WO2021153421A1 (ja) 2020-01-31 2021-01-21 制御方法、サーバ、および、プログラム

Country Status (5)

Country Link
US (1) US20220358496A1 (https=)
EP (1) EP4099612A4 (https=)
JP (1) JPWO2021153421A1 (https=)
CN (1) CN115004630A (https=)
WO (1) WO2021153421A1 (https=)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102594355B1 (ko) * 2021-05-17 2023-10-26 주식회사 에이씨엘 비대면 중고물품 거래 서비스 제공 방법 및 장치

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015018057A (ja) * 2013-07-10 2015-01-29 日本放送協会 鍵生成装置、暗号化装置および復号装置、ならびに、それらのプログラム
JP2018196097A (ja) * 2017-05-22 2018-12-06 Kddi株式会社 生成装置、合意形成システム、プログラム、及び生成方法
JP2019184908A (ja) 2018-04-13 2019-10-24 株式会社ｂｉｔＦｌｙｅｒ Ｂｌｏｃｋｃｈａｉｎ ブロックチェーン・ネットワーク及びそのための確定方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100360480B1 (ko) * 2000-03-10 2002-11-09 삼성전자 주식회사 사용자 인증 장치 및 그 방법
KR101199476B1 (ko) * 2009-03-05 2012-11-12 한국전자통신연구원 지능형 로봇 서비스 시스템에서의 콘텐츠 관리 방법 및 장치, 이를 위한 콘텐츠 서버 및 로봇
MX2014002142A (es) * 2011-09-28 2014-03-27 Koninkl Philips Nv Cifrado y descifrado basados en atributos jerarquicos.
US9202057B2 (en) * 2013-08-30 2015-12-01 Symantec Corporation Systems and methods for identifying private keys that have been compromised
US9672499B2 (en) * 2014-04-02 2017-06-06 Modernity Financial Holdings, Ltd. Data analytic and security mechanism for implementing a hot wallet service
KR101883397B1 (ko) * 2016-03-25 2018-07-30 한국전자통신연구원 신뢰 기반 콘텐츠 공유 장치 및 방법
US10411905B2 (en) * 2016-07-01 2019-09-10 Intel Corporation Public key infrastructure using blockchains
GB201700367D0 (en) * 2017-01-10 2017-02-22 Trustonic Ltd A system for recording and attesting device lifecycle
US10922692B2 (en) * 2017-04-05 2021-02-16 Samsung Sds Co., Ltd. Method for calculating confirmation reliability for blockchain based transaction and blockchain network monitoring system for performing the method
US10306341B2 (en) * 2017-06-28 2019-05-28 Motorola Solutions, Inc. Method and apparatus for determining sensor data reliability at an incident scene for real-time and post-incident processing
WO2019161412A1 (en) * 2018-02-16 2019-08-22 Verimatrix, Inc. Systems and methods for decentralized certificate hierarchy using a distributed ledger to determine a level of trust
US20190303932A1 (en) * 2018-03-28 2019-10-03 NEC Laboratories Europe GmbH Method and system for verifying policy compliance of transactions in a blockchain executing smart contracts
US11226971B2 (en) * 2018-10-03 2022-01-18 International Business Machines Corporation Blockchain implementing reliability database
US11544252B2 (en) * 2019-12-17 2023-01-03 Akamai Technologies, Inc. High performance distributed system of record with extended transaction processing capability

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015018057A (ja) * 2013-07-10 2015-01-29 日本放送協会 鍵生成装置、暗号化装置および復号装置、ならびに、それらのプログラム
JP2018196097A (ja) * 2017-05-22 2018-12-06 Kddi株式会社 生成装置、合意形成システム、プログラム、及び生成方法
JP2019184908A (ja) 2018-04-13 2019-10-24 株式会社ｂｉｔＦｌｙｅｒ Ｂｌｏｃｋｃｈａｉｎ ブロックチェーン・ネットワーク及びそのための確定方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP4099612A4
TEPPEI SATO; KEITA EMUHA; KAZUMASA OMOTE: "A Consideration of Giving Anonymous Token on Blockchain System", PROCEEDINGS OF COMPUTER SECURITY SYMPOSIUM 2019, 14 October 2019 (2019-10-14), JP, pages 547 - 554, XP009530200, ISSN: 1882-0840 *

Also Published As

Publication number Publication date
EP4099612A1 (en) 2022-12-07
JPWO2021153421A1 (https=) 2021-08-05
CN115004630A (zh) 2022-09-02
EP4099612A4 (en) 2023-07-26
US20220358496A1 (en) 2022-11-10

Similar Documents

Publication Publication Date Title
US11777726B2 (en) Methods and systems for recovering data using dynamic passwords
US11876801B2 (en) User ID codes for online verification
US11936788B1 (en) Distributed ledger system for identity data storage and access control
CN111095327B (zh) 用于验证可验证声明的系统和方法
CN111213147B (zh) 用于基于区块链的交叉实体认证的系统和方法
CN111316303B (zh) 用于基于区块链的交叉实体认证的系统和方法
US12126721B2 (en) Reputation profile propagation on blockchain networks
US20180343120A1 (en) Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features
CN116910726A (zh) 用于将去中心化标识映射到真实实体的系统和方法
CN111754343B (zh) 隐私保护的死锁解除
US20240146523A1 (en) Access control using a blockchain identity and policy based authorization
JP2021524216A (ja) デジタルシールされたアセットを作成および登録し、デジタルシールされたアセットが本物であるかを確認するための方法、コンピュータプログラム製品および装置
CN110692214A (zh) 用于使用区块链的所有权验证的方法和系统
EP3073670A1 (en) A system and a method for personal identification and verification
US12602512B2 (en) Data resolution using user domain names
US20230206219A1 (en) Identification token, systems and methods for identification and identity verification.
CN119866614A (zh) 用于数字资产注册、跟踪和验证的集成平台
JP2025107364A (ja) 電子契約方法、電子契約システムおよびプログラム
US12407529B2 (en) Server, information management system, and information management method
WO2019209291A1 (en) Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features
CN114830159B (zh) 用于减轻票据融资欺诈的方法和设备
WO2021153421A1 (ja) 制御方法、サーバ、および、プログラム
JP2024503173A (ja) デジタルメディアを登録し、デジタルメディアの登録を検証する方法及びシステム
US12561681B2 (en) Acquisition of digital assets on a blockchain using off-chain valuation and authorization
US20230316262A1 (en) Fungible and Non-Fungible Tokens with Authenticity: Systems and Methods for Secure Funding and Fundraising for Businesses

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021573978

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021748122

Country of ref document: EP

Effective date: 20220831

WWW Wipo information: withdrawn in national office

Ref document number: 2021748122

Country of ref document: EP