WO2021066323A1 - Système de vérification d'intégrité de document électronique utilisant une technologie de chaîne de blocs, et procédé de commande associé - Google Patents

Système de vérification d'intégrité de document électronique utilisant une technologie de chaîne de blocs, et procédé de commande associé Download PDF

Info

Publication number
WO2021066323A1
WO2021066323A1 PCT/KR2020/011293 KR2020011293W WO2021066323A1 WO 2021066323 A1 WO2021066323 A1 WO 2021066323A1 KR 2020011293 W KR2020011293 W KR 2020011293W WO 2021066323 A1 WO2021066323 A1 WO 2021066323A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
information
verification
blockchain
hash value
Prior art date
Application number
PCT/KR2020/011293
Other languages
English (en)
Korean (ko)
Inventor
전정우
Original Assignee
주식회사 디지털존
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 디지털존 filed Critical 주식회사 디지털존
Publication of WO2021066323A1 publication Critical patent/WO2021066323A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Definitions

  • the present invention relates to a certificate verification system, and more particularly, to a system capable of verifying whether or not a certificate to be viewed is forged or altered when viewing an issued certificate.
  • Blockchain technology refers to a data distribution processing technology that distributes and stores all the data that are subject to management by all users participating in the network. It is also called'distributed ledger technology (DLT)' or'public transaction ledger' in that the ledger containing transaction information is not owned by the transaction entity or a specific institution, but is shared by all network participants. .
  • Blockchain is a name given as a chain of blocks containing transaction details.
  • the public blockchain corresponds to the public transaction ledger described above, and generally refers to the public blockchain when it comes to blockchain.
  • Private blockchain is a relative concept, and is also referred to as enterprise blockchain because it is mainly used by companies.
  • Consortium blockchain in which several companies (or institutions) jointly participate, also belongs to the category of private blockchain in a broad sense.
  • private blockchains can participate only with the approval of a service provider (corporate or institution), and only legally responsible organizations can create transactions.
  • a service provider corporate or institution
  • transaction details are open to all, and all nodes participating in the network verify it and approve the transaction
  • private blockchain only authorized organizations verify the transaction and approve the transaction.
  • the public blockchain has a high reliability through mutual verification of all participants, but it has the disadvantage that the processing speed is slow to record and share the transaction records of all participants.
  • the private blockchain is much faster because only authorized nodes participate and there is no need to seek verification of other nodes.
  • the reliability is limited compared to the public blockchain.
  • Such a blockchain can be used in various industrial fields, and it will be most suitable especially for fields where reliability against forgery and alteration must be secured.
  • Verification work such as authentication for users or verification of documents, is a work that is inevitably exposed to the risk of forgery or alteration, and securing reliability will be more urgent than work in other industries. Nevertheless, research on such a proof system using blockchain technology has not been properly conducted.
  • Another object of the present invention is to solve the above and other problems. Another object is to provide an authentication system that can improve the reliability of user authentication or document authentication.
  • Another purpose is to provide a certificate verification system that can reliably verify whether or not forgery or alteration has been made when viewing issued certificates, and to provide certificate access only when verified.
  • a system for verifying an electronic document comprising: a main block chain consisting of a plurality of main nodes; A sub-blockchain composed of a plurality of sub-nodes; A certificate issuing server for generating a certificate; And a viewing terminal for viewing the generated certificate, wherein the viewing terminal requests verification of the certificate from the sub-blockchain, and provides viewing of the certificate based on a result of the verification request, or It provides an electronic document verification system, characterized in that blocking.
  • a destination of the issued electronic certificate can be specified, and access to an organization or user other than the specified destination can be set to be restricted.
  • FIG. 1 is a diagram showing the structure of a block chain according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an extension relationship between a main block chain and a sub block chain according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating a first verification procedure of a document according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating a process of requesting a certificate between certification authorities according to an embodiment of the present invention.
  • FIG. 5 is a diagram showing a procedure for verifying the authenticity of a certificate according to an embodiment of the present invention.
  • FIG. 6 is a conceptual diagram of generating a first hash value according to an embodiment of the present invention.
  • 7 is a conceptual diagram for generating a second hash value according to an embodiment of the present invention.
  • Blockchain technology is currently being actively used in financial systems. Hereinafter, a method applied in the financial system will be described.
  • Blockchain is a core concept of decentralization, which aims for P2P (Peer to Peer) transactions, away from the existing financial system that secures and manages all transactions in financial institutions.
  • P2P refers to a communication network that connects personal computers without a server or client, and each connected computer acts as a server and a client to share information.
  • Blockchain technology processing for the transaction process (transaction, transaction) in the financial system is performed as follows. 1 A requests for a transaction, such as a request for remittance, to B. 2 A block containing the transaction information is created. 3 When the block is transmitted to all participants on the network, the participants mutually verify the validity of the transaction information. 4 The transaction details that match the data of the majority of participants are checked with the normal ledger, and the verified block is linked to the previous block, and a copy is made and distributed and stored on each user's computer. 5 A transfers money to B and the transaction is completed. At this time, all transactions that have occurred within a preset period (for example, about 10 minutes) can be generated as one block.
  • a preset period for example, about 10 minutes
  • a block is a unit that stores data and is divided into a body and a header.
  • the body contains the transaction details
  • the header contains encryption codes such as merkle hash (merclout) and nonce (an arbitrary number related to encryption).
  • Blocks are created every about 10 minutes, and they are connected to the previous block to form a block chain while collecting transaction records and creating blocks to verify reliability.
  • the block that starts here is called the genesis block.
  • the genesis block refers to the first block in which no block has been created before it.
  • Blockchain does not store and manage transaction records on a centralized server, but individual servers participating in transactions gather to maintain and manage the network. This individual server, or participant, is called a node. Since there is no central manager, the role of the node distributing blocks is important, and a new block is created only when more than half of the participating nodes agree. Nodes store the blockchain in their computers, and even if some nodes are hacked and the existing contents are changed, data remains in multiple nodes, so data can be preserved continuously.
  • SHA-2 (SHA 256) in a more advanced form came out after SHA (Secure Hash Algorithm)-1 was first devised, which is being used in the blockchain. SHA-2 results in 256 bits no matter what length value is entered.
  • 1 is a diagram showing the structure of a block chain according to an embodiment of the present invention.
  • 2 is a diagram illustrating an extension relationship between a main block chain and a sub block chain according to an embodiment of the present invention.
  • the proof system includes a main blockchain 110 in which at least two main nodes 111-1 to 111-3 participate and at least two sub-nodes 121-1 to 121-4. It may include a sub-blockchain 120 to participate in.
  • the main block chain 110 may form a main block at a preset cycle based on the main transaction
  • the sub block chain 120 may form a sub block at a preset cycle based on the sub transaction. That is, blocks generated between the main blockchain 110 and the sub-blockchain 120 are not connected to each other or a verification procedure is performed.
  • main blockchain 110 and the sub-blockchain 120 may be selectively connected, and when selectively connected, a verification procedure may be required.
  • the sub-blockchain 120 may perform a verification query for the transaction.
  • the main blockchain 110 and the sub-blockchain 120 may transmit and receive data by a connection node.
  • At least one of the main nodes 111-1 to 111-3 participating in the main blockchain 110 is the main connection node 111-3, and the sub-nodes 121-1 to participating in the sub-blockchain 120 At least one of 121-4) is a sub-connection node 121-1, and the main and sub-connection nodes 111-3 and 121-1 are provided to connect the main and sub-block chains to each other.
  • being connected to each other may mean exchanging data.
  • connection nodes it is proposed to exchange data between the connection nodes only under specific conditions. This is because the main blockchain is a private blockchain, and information stored in the main blockchain should not be disclosed to the outside.
  • only data transmission/reception in the case of receiving only a preset query from the sub-blockchain 120 or replying to the preset query may be performed through the connection node.
  • a preset query and a response thereto will be described in detail later.
  • the main blockchain 110 may be a private blockchain. That is, the main nodes 111-1 to 111-3, which are nodes of the main blockchain 110, are not disclosed to anyone, and only authorized or designated organizations can participate.
  • the sub-blockchain 120 may be a private blockchain or a public blockchain. Although it is not completely blocked, it may be a private blockchain in a broad sense, in which only confirmed or authenticated subjects (pre-set some subjects) can participate in a limited manner. Accordingly, the sub-nodes 121-1 to 121-4, which are nodes of the sub-blockchain 120, will be able to participate in additional sub-nodes 122-1, 122-2, ....
  • the main block chain 110 and the sub block chain 120 are separated because security for the proof system is required.
  • all transactions are open to the public, because user authentication or the contents of the document itself must not be disclosed to the public.
  • a certificate of graduation should be disclosed only to a recipient organization (e.g., a company wishing to receive a certificate for an applicant) requested by the requestor (e.g., an applicant from a company), and other companies, other than the recipient, This is because it is information that should not be disclosed to third parties such as financial institutions or others.
  • main blockchain 110 Another reason why the main blockchain 110 and the sub-blockchain 120 are separated is to secure the scalability of the recipient institution.
  • main blockchain 110 since it is a private blockchain whose contents should not be disclosed, it is bound to be limited in terms of its scalability.
  • a company that wants to participate as a node of the block chain additionally occurs, in the system according to an embodiment of the present invention, it is provided to participate in the node of the sub-block chain.
  • a plurality of organizations (hereinafter referred to as recipient organizations) requesting user authentication or document authentication may correspond to the sub-nodes 121-1 to 121-4. That is, the recipient organization may be matched to and connected to one sub-node, and one recipient organization may be connected to one sub-node.
  • a certification authority may be connected to at least one of the plurality of main nodes 111-1 to 111-3.
  • one integrated certification authority can use multiple nodes.
  • the sub-blockchain 120 can expand the number of blockchains themselves. As shown in FIG. 2, a plurality of sub-blockchains 120-1, 120-2, 120-3, ... may be connected to one main blockchain 110 to operate. At this time, the main connection node 111-3 of the main blockchain 110 is in a '1 to many' relationship with a plurality of sub-connection nodes (121-1, 130-1, 130-2 in FIG. 2). Each will be able to be connected.
  • FIG. 3 is a diagram illustrating a first verification procedure of a document according to an embodiment of the present invention.
  • the certificate request server 391 may mean a server managed by a recipient organization (or individual) that wants to check the authenticity of a document related to the requestor 390.
  • the certificate request server 391 It is a server operated by a company, and the requestor 390 may be an applicant who applies for employment in the company, and the graduation certificate document to check the enrollment information of the requester 390 through the certificate request server 391 in the corresponding company We can assume a situation where we check the authenticity of.
  • the certification institution 393 refers to a subject that performs the corresponding certification, and in the above example, the requestor 390 may be a university bachelor's certificate or academic certificate system. It will be apparent that the term “certification agency 393” used in the present invention is only a term used to make the concept easier to understand, and can be interpreted as a device, system, or server operated by the certification authority 393.
  • the certificate issuing server 392 is an organization for collectively managing the certification-related procedures of a plurality of certification agencies 393, and means a subject that issues the matters certified by the certification agency 393 as an encrypted document. .
  • the certificate issuing server 392 may play a role of integrating the contents verified/certified by the numerous universities, encrypting it, and issuing it as a certificate.
  • the present invention is not limited to generating certificates directly by the certificate issuing server 392, and a case where certificates are issued by a plurality of certification authorities 393 and the collection and management of the issued certificates is also included in the present invention. will be.
  • the certificate issuing server 392 may be provided separately from the certification authority 393, but may be provided as a single organization without being distinguished from the certification authority 393.
  • server used in the detailed description for carrying out the present invention is a term that includes all devices capable of transmitting and receiving data on and off-line, and the content of the present invention is not limited to the term server itself.
  • certificate in the specific content for carrying out the present invention is a term encompassing all electronic documents that can be issued, distributed, and stored electronically.
  • the requestor 390 directly requests a graduation certification document from the certification authority 393 or the certificate issuing server 392 to print the graduation certification document through a printer and output the graduation certification document to the recipient institution. Confirmed by the method of submission.
  • an institution that wants to verify the certificate using blockchain technology for example, a company that wants to check the registration information of the requestor
  • step S301 the requester 390 requests the certificate request server 391 to generate a document (certificate) that he/she wants to prove.
  • step S302 the certificate request server 391 delivers the request to the certificate issuing server 392.
  • step S303 the certificate issuing server 392 designates the name of the certificate file to be generated, and returns the designated file name to the certificate request server 391.
  • step S304 the certificate issuing server 392 transmits a request for generating a certificate to the certification authority 393.
  • the certification authority 393 may generate a certificate based on the received request.
  • the certificate issuing server 392 transmits the transaction for generating the certificate to the node of the main blockchain 110 (S305).
  • the transferred transaction may be stored in the main block as described above, and further, may be selectively transmitted to the sub-blockchain 120 and stored in the sub-block.
  • the transaction according to an embodiment of the present invention be transferred to a sub-chain and stored as a sub-block. This is because the verification is performed in step S307 to be described later.
  • the transaction may be transmitted through a connection between the main connection node 111-3 and the sub connection node 121-1. That is, the transaction for generating the certificate may be recorded in the sub-block of the sub-blockchain through sequentially through the main connection node 111-3 and the sub-connection node 121-1.
  • step S306 the certificate request server 391 continuously checks the creation contract with the certificate issuing server 392. That is, based on the file name returned in step S303, it is continuously checked whether a certificate having the corresponding file name has been generated. If it is confirmed that the certificate is generated, a verification query is transmitted to verify that the certificate has been generated through the sub-blockchain 120 (S307). In other words, it is to check whether the certificate was generated correctly.
  • the checking process (S307) may be performed based on the contents stored in the sub-block. That is, a transaction for generating a certificate is stored in a sub-block, and verification is performed by checking the transaction recorded in the sub-block.
  • the confirmation result which is a response to the query, may be returned to the certificate request server 391 again.
  • the generated certificate is transmitted to the certification authority 393, the certificate issuing server 392, and the certificate request server 391 through steps S308 and S309, so that the certificate request server 391 can receive (download) it.
  • the certificate request server 391 Upon completion of receipt of the certificate, the certificate request server 391 transmits a transaction for completion of receipt to the sub-node 121-4 in step S310.
  • the transmitted transaction will be stored in the sub-block of the sub-blockchain 120.
  • step S311 the requester 390 receives (downloads) a certificate from the certificate request server 391.
  • the certificate request server 391 can transmit a transaction for issuing a certificate (i.e., complete delivery to the requestor) to the sub node 121-4 of the sub-blockchain 120 (step S312) and store it in the sub-block. There will be. Further, not only the completion of the transfer of the certificate, but also all operations such as copying, destruction, and transfer of the certificate can be transferred to the sub-node 121-4 as a transaction.
  • the certificate request server 391 receiving the certificate can verify with high reliability whether the received certificate is correctly generated, and the requester 390 receives the generated certificate by the receiving organization. It has the advantage of being able to check with high reliability whether it has been done, whether it is delivered to a third party, or whether it is destroyed.
  • FIG. 4 is a diagram illustrating a process of requesting a certificate between certification authorities according to an embodiment of the present invention.
  • step S401 the first certification authority 393-1 transmits a request to generate a certificate to the certificate issuing server 392. Subsequently, the certificate issuing server 392 designates the name of the certificate file to be generated, and returns the designated file name to the first certification authority 393-1. In step S403, the certificate issuing server 392 transmits a certificate generation request to the second certification authority 393-2, and the second certification authority 393-2 generates the requested certificate.
  • the certificate issuing server 392 may transmit a transaction for generating the certificate to the main node of the main blockchain 110.
  • step S405 the first certification authority 393-1 continuously checks the generated contract with the certificate issuing server 392. Based on the file name returned in step S402, it is continuously checked whether a certificate having the corresponding file name has been generated.
  • step S406 the second certification authority 393-2 transmits the generated certificate to the certificate issuing server 392.
  • the certificate issuing server 392 Upon receiving the certificate, the certificate issuing server 392 generates a transaction for receiving the certificate, and transmits it to the main node of the main blockchain 110 (step S407).
  • the certificate issuing server 392 delivers the received certificate to the first certification authority (step S408). Then, when the certificate transfer is completed, a transaction for certificate transfer is generated and transferred to the main node of the main blockchain 110 (step S409).
  • FIG. 5 is a diagram showing a procedure for verifying the authenticity of a certificate according to an embodiment of the present invention.
  • the certificate received by the requestor 390 in step S311 of FIG. 3 described above may be stored in the form of a document file, and may be copied and/or moved. That is, the requester 390 who has received the certificate may copy the document file to another person or transmit it in the form of an attached file such as an e-mail.
  • the document file according to an embodiment of the present invention may be a widely used extension such as pdf or jpg, but may be a separate extension.
  • the document file of the certificate according to an embodiment of the present invention can be checked only through a preset viewer program (software). That is, in the case of a new extension, the extension of the document file can be viewed only by the preset viewer program, and even in the case of an extension such as pdf or jpg, which is generally used, it cannot be viewed with a general document/image viewer. It can be set to be viewed only by a preset viewer program.
  • a preset viewer program software
  • the requester 390 may transmit a document file of a certificate to a third party 620 (hereinafter referred to as a certificate viewer).
  • the certificate viewer 620 receiving the document file of the certificate may view the certificate through the viewing terminal 502.
  • the browsing terminal 502 may include all of various terminals such as a PC, a tablet PC, and a mobile terminal, and refers to a terminal installed with a viewer program for viewing a certificate.
  • the certificate viewer 620 may view the document file of the received certificate through the viewer program of the viewing terminal 502. As shown in FIG. 5, the certificate viewer 620 requests the viewing terminal 502 to view the certificate (S591) in order to view the certificate.
  • Such a view request may include all various manipulation methods that can be performed by the certificate viewer 620, and the most representative example may be an act of designating the document file of the certificate by double-clicking or touching it with a mouse. (The certificate designated in this way is called the'target certificate').
  • the viewing terminal 502 performs a certificate verification procedure by controlling the viewer program in response to the certificate viewing request.
  • the certificate is distributed in the form of a document file. If distributed in the form of a file like this, it will always be exposed to the possibility of forgery or alteration. Therefore, in one embodiment of the present invention, before the viewer program provides reading of the document (outputting the document to the display), whether the document has been forged or altered, whether the document is authorized to access the document, whether the document has a viewing period exceeded, etc. And, according to the verification result, it is suggested to provide access to the document or block the output of the document.
  • the procedure for checking as described above is referred to as a certificate validation procedure, and the validation procedure according to an embodiment of the present invention can check the conditions shown in Table 1 below.
  • the browsing terminal 502 requests the certificate verification server 501 to verify the validity of the certificate (S592).
  • the certificate verification server 501 requests a hash value from the sub-node 121-3 of the sub-blockchain 120 (S593). This is to perform validation through a hash value.
  • the requested hash value is a hash value corresponding to the certificate to be verified, and the certificate verification server 501 uses a code (for example, a file name) for identifying the certificate. Etc.) together with the hash value (S593).
  • a certificate issuing server generates a hash value when issuing a certificate, but proposes to generate a hash value in two steps. This embodiment will be described with reference to FIGS. 6 and 7.
  • FIG. 6 is a conceptual diagram of generating a first hash value according to an embodiment of the present invention.
  • 7 is a conceptual diagram for generating a second hash value according to an embodiment of the present invention.
  • data 601 of a certificate includes content information 603 and metadata information 602.
  • the content information 603 relates to information displayed on an actual document viewing screen, and may include, for example, information on a subject of certification, information on a certificate text, information on a subject of certificate issuance, and the like. That is, it means information displayed to the certificate viewer 620.
  • the metadata information 602 is information on the corresponding certificate, and may include all information except for the content information 603.
  • the metadata information 602 may be at least one of timestamp information, location information, recipient's corporate identity (CI) information, issuer's date of birth information, usage information, period information, and country information. have.
  • the certificate issuing server generates a first hash value 610 based on the content information 603 and the metadata information 602.
  • the certificate issuing server may generate a second hash value 710 by combining the generated first hash value 610 and the authentication information 701.
  • the generation of the first and second hash values can be generated by various known secure hash algorithms (SHAs) or other algorithms, and is not limited to a specific type of hash value generation algorithm.
  • SHAs secure hash algorithms
  • the authentication information 701 may include information used to distinguish the certificate from other certificates, and may include at least one of usage, period, location, country, and recipient's CI information.
  • the certificate issuing server receives the authentication information 701 information when issuing a certificate, and combines the received authentication information 701 and the first hash value to obtain the second hash value 710. Is to create.
  • the business registration number of the certificate recipient may be input as the authentication information 701.
  • the first hash value 610 generated in the manner of FIG. 6 and the business registration number are combined to obtain a second hash value.
  • the certificate issuing server may generate the above first and second hash values, and the generated second hash value 710 is used as the main block. It can be delivered to the nodes of the chain 110.
  • the second hash value 710 transmitted to the node of the main blockchain 110 is transmitted to the node of the sub-blockchain 120, so that it can be used in the verification procedure of the certificate. There will be.
  • the hash value requested by the certificate verification server 501 to the sub-node 121-3 of the sub-blockchain 120 is the sub-blockchain 120 It may be the received second hash value.
  • the certificate verification server 501 may perform certificate verification (S594) based on the second hash value.
  • the certificate verification may be performed by comparing the second hash value and the comparison target hash value.
  • the comparison target hash value is a hash value generated by the browsing terminal 502 and may mean a hash value generated from a target certificate for which a certificate browsing request (S591) is made by a user. In other words, it refers to a hash value obtained from the subject certificate to be viewed by the certificate viewer 620 (the subject certificate to be viewed).
  • the method of obtaining the hash value to be compared will be the same as the method of generating a hash value over two steps described above with reference to FIGS. 6 and 7.
  • the validity of the certificate is verified by comparing whether the second hash value 710 generated at the time the certificate is issued and the comparison target hash value generated at the time the document is viewed are the same or different.
  • the browsing terminal 502 requests a user to log in with a public certificate, and proposes to generate the comparison target hash value based on information that can be obtained when the user is logged in with the public certificate. .
  • the'business registration number' is inputted as the authentication information 701 in order to limit the recipient of the certificate. That is, the certificate issued for the purpose of submitting only to Bank A is proposed to generate the second hash value 710 by entering the business registration number of Bank A so that only Bank A is limited as a recipient and cannot be submitted to other banks. will be.
  • the browsing terminal 502 generates a hash value to be compared, the validity of the certificate may be verified only when the second hash value 710 is generated as a business registration number.
  • the business registration number is a number that can be easily obtained by a third party, and it is difficult to limit the recipient by simply inputting the business registration number when generating a hash value to be compared. That is, in the above example, if you enter the business registration number of Bank A while viewing the certificate at Bank B, you can verify the validity of the certificate as well.
  • the business registration number was mentioned as an example of the authentication information 701, it is not necessarily limited thereto, and it will be as described above that it may include at least one of usage, period, location, country, and recipient's CI information.
  • FIG. 8 shows a specific example of comparing hash values according to an embodiment of the present invention.
  • the certificate issuing server 392 creates a first hash value 610 by combining the content information 603 and the metadata information 602 of the issued certificate itself as described above in FIG. 6.
  • the certificate issuing server 392 generates a second hash value 710 by combining the business registration number of the recipient (to limit the recipient) received from the person in charge of issuing the certificate with the first hash value 610. .
  • the browsing terminal 502 generates a third hash value 801 by combining the content information 603 and the metadata information 602 of the certificate to be viewed.
  • the browsing terminal 502 requests the certificate reader 620 to log in to a public certificate.
  • the browsing terminal 502 may obtain the fourth hash value 802 by combining the business registration number obtainable at the time of logging in and the third hash value 801.
  • the fourth hash value 802 obtained as described above is the hash value to be compared and is compared by the certificate verification server 501 to determine whether it is the same as the second hash value 710, and can be used to verify the validity of the certificate. have.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un système permettant d'émettre un document électronique sur la base d'une technologie de chaîne de blocs et de vérifier le document électronique émis, et, plus spécifiquement, elle concerne un système de vérification de document électronique qui comprend : une chaîne de blocs principale comprenant une pluralité de noeuds principaux ; une sous-chaîne de blocs comprenant une pluralité de sous-noeuds ; un serveur d'émission de certificat servant à générer un certificat ; et un terminal de visualisation servant à visualiser le certificat généré, le terminal de visualisation demandant la vérification du certificat à partir de la sous-chaîne de blocs et permettant ou bloquant la visualisation du certificat sur la base d'un résultat de la demande de vérification.
PCT/KR2020/011293 2019-09-30 2020-08-25 Système de vérification d'intégrité de document électronique utilisant une technologie de chaîne de blocs, et procédé de commande associé WO2021066323A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020190120554A KR102147083B1 (ko) 2019-09-30 2019-09-30 블록체인 기술을 이용한 전자문서 유효성 검증 시스템 및 그것의 제어 방법
KR10-2019-0120554 2019-09-30

Publications (1)

Publication Number Publication Date
WO2021066323A1 true WO2021066323A1 (fr) 2021-04-08

Family

ID=72235222

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/011293 WO2021066323A1 (fr) 2019-09-30 2020-08-25 Système de vérification d'intégrité de document électronique utilisant une technologie de chaîne de blocs, et procédé de commande associé

Country Status (2)

Country Link
KR (1) KR102147083B1 (fr)
WO (1) WO2021066323A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114610779A (zh) * 2022-03-06 2022-06-10 浙江数秦科技有限公司 一种基于区块链的民生档案数字化方法
CN116566710A (zh) * 2023-05-28 2023-08-08 易知名国际文化传媒(北京)有限公司 一种区块链数据管理方法及系统

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102147083B1 (ko) * 2019-09-30 2020-08-24 주식회사 디지털존 블록체인 기술을 이용한 전자문서 유효성 검증 시스템 및 그것의 제어 방법
CN112131599B (zh) * 2020-09-15 2024-08-16 京东科技信息技术有限公司 校验数据的方法、装置、设备和计算机可读介质
KR102271647B1 (ko) * 2020-11-11 2021-07-01 (주)소셜인프라테크 데이터 상호 공유 오브젝트 검증을 통한 포트폴리오 관리 시스템
KR102276527B1 (ko) * 2020-11-11 2021-07-13 (주)소셜인프라테크 오브젝트의 정보 변경 방지를 위한 오브젝트 발행 시스템
CN112487042B (zh) * 2020-12-08 2024-04-19 深圳供电局有限公司 电能计量数据处理方法、装置、计算机设备和存储介质
KR102284208B1 (ko) * 2020-12-14 2021-08-03 라온화이트햇 주식회사 블록체인 기반 증명서 관리 시스템 및 이를 이용한 증명서 발급 방법
KR102488139B1 (ko) * 2021-03-15 2023-01-13 블록체인랩스 주식회사 백신 접종의 인증 및 접종 후 사후 관리를 제공하기 위한 방법 및 그 시스템
CN114679311B (zh) * 2022-03-22 2023-04-07 电子科技大学 一种基于区块链的文档数据安全验证方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160150278A (ko) * 2016-06-15 2016-12-29 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
KR101882802B1 (ko) * 2017-04-17 2018-07-27 주식회사 코인플러그 Utxo 기반 프로토콜을 이용한 블록체인 기반의 문서 관리 방법 및 이를 이용한 문서 관리 서버
KR20180110670A (ko) * 2016-02-08 2018-10-10 린제이 몰로니 문서 정보의 진본성을 검증하기 위한 시스템 및 방법
KR20190093011A (ko) * 2018-01-31 2019-08-08 지송학 보안성이 강화된 블록 체인 시스템 및 이중 블록 체인 구조를 이용한 데이터 블록 생성방법
KR20190105955A (ko) * 2018-03-07 2019-09-18 주식회사 한글과컴퓨터 블록체인을 이용한 전자 문서 관리 장치 및 이의 동작 방법
KR102147083B1 (ko) * 2019-09-30 2020-08-24 주식회사 디지털존 블록체인 기술을 이용한 전자문서 유효성 검증 시스템 및 그것의 제어 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180110670A (ko) * 2016-02-08 2018-10-10 린제이 몰로니 문서 정보의 진본성을 검증하기 위한 시스템 및 방법
KR20160150278A (ko) * 2016-06-15 2016-12-29 주식회사 코인플러그 블록체인을 기반으로 하는 금융기관 제증명서류 위변조 검증시스템 및 방법
KR101882802B1 (ko) * 2017-04-17 2018-07-27 주식회사 코인플러그 Utxo 기반 프로토콜을 이용한 블록체인 기반의 문서 관리 방법 및 이를 이용한 문서 관리 서버
KR20190093011A (ko) * 2018-01-31 2019-08-08 지송학 보안성이 강화된 블록 체인 시스템 및 이중 블록 체인 구조를 이용한 데이터 블록 생성방법
KR20190105955A (ko) * 2018-03-07 2019-09-18 주식회사 한글과컴퓨터 블록체인을 이용한 전자 문서 관리 장치 및 이의 동작 방법
KR102147083B1 (ko) * 2019-09-30 2020-08-24 주식회사 디지털존 블록체인 기술을 이용한 전자문서 유효성 검증 시스템 및 그것의 제어 방법

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114610779A (zh) * 2022-03-06 2022-06-10 浙江数秦科技有限公司 一种基于区块链的民生档案数字化方法
CN114610779B (zh) * 2022-03-06 2024-07-30 浙江数秦科技有限公司 一种基于区块链的民生档案数字化方法
CN116566710A (zh) * 2023-05-28 2023-08-08 易知名国际文化传媒(北京)有限公司 一种区块链数据管理方法及系统
CN116566710B (zh) * 2023-05-28 2024-04-26 深圳市远东数智采技术服务有限公司 一种区块链数据管理方法及系统

Also Published As

Publication number Publication date
KR102147083B1 (ko) 2020-08-24

Similar Documents

Publication Publication Date Title
WO2021066323A1 (fr) Système de vérification d'intégrité de document électronique utilisant une technologie de chaîne de blocs, et procédé de commande associé
KR102166233B1 (ko) 블록체인 기술을 이용한 전자문서 발급 시스템 및 그것의 제어 방법
WO2020192743A1 (fr) Procédé de gestion d'autorisation, procédé de validation d'autorisation et appareils associés
CN109377198B (zh) 一种基于联盟链多方共识的签约系统
US7788700B1 (en) Enterprise security system
US7549049B2 (en) Dynamic auditing of electronic elections
US7418401B2 (en) Secure internet transactions on unsecured computers
CN101944168B (zh) 电子文件权限控管系统
KR20180123709A (ko) 블록체인에서 복수개의 거래를 기록하는 방법 및 시스템
WO2002052480A1 (fr) Document chaine de confiance electronique et dynamique a filiere de verification
JP7114078B2 (ja) 電子認証方法及びプログラム
KR102079354B1 (ko) 블록체인 기술을 이용한 사용자 인증 시스템 및 그것의 제어 방법
Shakan et al. Verification of university student and graduate data using blockchain technology
KR102220599B1 (ko) 통합 인증을 위한 블록체인 시스템 및 그것의 제어 방법
WO2023095967A1 (fr) Système d'accès à un grand document avec interaction à distance dans lequel un service did basé sur une chaîne de blocs, une technologie de partage de données basée ipfs et une technologie de stockage distribuée à clé privée sont combinés
KR102147085B1 (ko) 전자문서의 사후 파기가 가능한 블록체인 기반 전자문서 관리 시스템 및 그것의 제어 방법
WO2019225850A1 (fr) Procédé et appareil de traitement d'informations de certificat
WO2022102980A1 (fr) Système de gestion de portefeuille par partage de données réciproque et vérification d'objet
WO2021117931A1 (fr) Système d'émission de document électronique, authentification d'utilisateur et authentification intégrée à l'aide d'une technologie de chaîne de blocs, et son procédé de commande
CN114565485A (zh) 基于区块链ipfs存储的劳动合同管理方法和系统
WO2021256681A1 (fr) Système de génération d'informations d'objet pourvu d'une fonction de prévention de changement d'informations
KR20210050846A (ko) 블록체인 기술에 기초하여 문서 데이터를 관리하기 위한 시스템
TWM583096U (zh) 區塊鏈證書與資產存證系統
WO2023128239A1 (fr) Système de gestion d'historique basé sur chaîne de blocs
KR102532319B1 (ko) 블록체인을 이용한 클라우드 가상머신 기반 다중 채널 노드 운용 방법 및 시스템

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20870729

Country of ref document: EP

Kind code of ref document: A1