WO2024063519A1 - Procédé, appareil et système de gestion de données sur la base d'une chaîne de blocs - Google Patents

Procédé, appareil et système de gestion de données sur la base d'une chaîne de blocs Download PDF

Info

Publication number
WO2024063519A1
WO2024063519A1 PCT/KR2023/014206 KR2023014206W WO2024063519A1 WO 2024063519 A1 WO2024063519 A1 WO 2024063519A1 KR 2023014206 W KR2023014206 W KR 2023014206W WO 2024063519 A1 WO2024063519 A1 WO 2024063519A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
blockchain
original data
content
information
Prior art date
Application number
PCT/KR2023/014206
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
Priority claimed from KR1020220117966A external-priority patent/KR102494825B1/ko
Priority claimed from KR1020220117967A external-priority patent/KR102501004B1/ko
Priority claimed from KR1020220132895A external-priority patent/KR102529277B1/ko
Application filed by 주식회사 레드윗 filed Critical 주식회사 레드윗
Publication of WO2024063519A1 publication Critical patent/WO2024063519A1/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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • 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
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • 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

Definitions

  • This disclosure provides methods, devices, and systems for blockchain-based data management, encryption, and ID distribution.
  • Blockchain is a technology that shares the same ledger among all nodes to operate transaction details transparently and prevent hacking and tampering.
  • This blockchain has a structure in which blocks containing transactions are connected in a chain.
  • IPFS stands for InterPlanetary File System and is a distributed P2P (Peer to Peer) file system that seeks to connect all computer nodes. IPFS is a faster, safer, and more open network realized through peer-to-peer communication between nodes without a centralized server. Unlike the conventional HTTP web, where the connection to a large, centralized server is cut off with fatal consequences, in IPFS the system can remain stable even if several nodes are disconnected.
  • IPFS In IPFS, each file consists of several blocks, and each block has a unique name expressed as a hash. IPFS stores the names of all files in the database, excludes duplicates of the same file, and tracks the version information of each file. Each node stores only the files it is interested in, and through indexing information, it is possible to know who is storing which files. To find a network file, simply look up the file name and track the node that holds the file.
  • IPFS IP-based distributed storage services
  • uploading a file to the IPFS service provider does not automatically cause the file to be distributed and stored.
  • each distributed server must receive the necessary content ID.
  • IPFS IP-based distributed file storage services
  • the proposal for the IPFS standard places responsibility for the distribution of content IDs on end users (eg, customers).
  • end users eg, customers
  • a typical SaaS-type service in addition to files uploaded directly by users, there are various files derived from them.
  • customers directly secure their own content ID list and directly register it in their own pinning service. It is unrealistic to do so. Therefore, it is necessary to implement a system that guarantees efficiency and reliability in terms of distributing and storing content IDs in servers that provide IPFS-based distributed file storage services and in each distributed node.
  • Web 3.0 refers to an intelligent, personalized web technology that allows computers to understand the contents of web pages and provide personalized information using semantic web technology.
  • Semantic Web is a concept that has evolved from existing web pages, and each web page is not information that only users (humans) can understand and read, but “data that describes data” that can also be understood by machines, that is, metadata. refers to a web environment including.
  • Web 3.0 Compared to Web 2.0, which enabled reading and writing to enable interaction, the concept of 'ownership' was added to Web 3.0. Specifically, compared to Web 2.0, which had a centralized structure in terms of information ownership on the platform, Web 3.0 has a decentralized structure in which data is distributed and stored through distributed supercomputing and information ownership lies with individual users. has A representative example is IPFS.
  • the purpose of this disclosure is to provide a blockchain-based data management method and device, a method and system for distributing content IDs for IPFS, and a data encryption method and device for implementing Web 3.0.
  • it was designed to improve the above problems, and its purpose is to provide a blockchain-based research note management system.
  • a system for distributing content IDs includes a user terminal that uploads one or more content IDs corresponding to one or more backup data; a publishing server that publishes a content ID list including the one or more content IDs; a pinning server that transmits a data request for pinning the one or more backup data and performs pinning on the one or more backup data; and a web server that transmits a returned content ID list included in the content ID list to the pinning server in response to the data request.
  • a blockchain-based data management method includes generating a first block for a user's original data; Applying an original data timestamp issued by a Time-Stamping Authority (TSA) to the original data, thereby generating a second block related to the original data timestamp; generating a third block related to a third party's signature for at least one of the first block and the second block;
  • TSA Time-Stamping Authority
  • a blockchain-based data management method including a step of sequentially recording the first to third blocks in the ledger of the original blockchain can be provided.
  • a blockchain-based data management device includes: a memory in which at least one program is stored; and a processor operating by executing the at least one program, wherein the processor generates a first block for the user's original data, and adds original data issued by a Time-Stamping Authority (TSA) to the original data.
  • TSA Time-Stamping Authority
  • Apply a timestamp to generate a second block related to the original data timestamp generate a third block related to a third party signature for at least one of the first block and the second block, and generate a third block related to the first block and the second block. It is possible to provide a blockchain-based data management device that sequentially records first through third blocks in the ledger of the original blockchain.
  • a blockchain-based data management device may provide a computer-readable recording medium recording a program for executing the method of the first aspect on a computer.
  • a data encryption method includes receiving original data and a user input for selecting one of a plurality of upload buttons for the original data; determining whether to encrypt the original data based on the user input; And according to the decision, uploading the original data or encrypted data obtained by encrypting the original data to an IPFS network.
  • a data encryption method for implementing Web 3.0 including a step can be provided.
  • a data encryption device includes: a memory storing at least one program; and a processor operating by executing the at least one program, wherein the processor receives a user input for selecting one of original data and a plurality of upload buttons for the original data, and based on the user input, It is possible to provide a data encryption device for implementing Web 3.0, which determines whether to encrypt the original data and, according to the decision, uploads the original data or encrypted data encrypted with the original data to the IPFS network. .
  • the data encryption device may provide a computer-readable recording medium recording a program for executing the method of the first aspect on a computer.
  • a blockchain-based research note management system includes a user terminal that acquires research record data through a research note management application; A research note management server that stores at least part of the research note management application and performs operations to manage the research record data uploaded from the user terminal; A blockchain network that receives transactions and hash values for the research record data and generates blocks for the research record data; Storage for storing the original research record data; and a data server that stores metadata of the research record data.
  • the system further includes a proxy server that receives the transaction from the research note management server and transmits it to the blockchain network, and the proxy server can perform asynchronous transaction processing.
  • a certification authority participates as an orderer, and a research institution can configure a plurality of peers.
  • At least some of the plurality of peers guarantee the transaction by executing the transaction received from the research note management server through the gateway, and based on the guarantee, participate in the transaction through the gateway.
  • the result value can be delivered to the orderer.
  • At least some of the plurality of peers transmit a result value for the transaction to the orderer along with the peer's signature based on the guarantee, thereby providing the research institute's information on the research record data.
  • the signature requirements can be met.
  • the orderer may perform timestamping on the research record data by creating a block for the transaction and distributing the block to the plurality of peers.
  • the storage stores the signature of the author of the study record data, and the author's signature may be added to transactions for the study record data based on which the study record data is uploaded.
  • a blockchain-based data management method includes generating a first block for user's original data; Applying an original data timestamp issued by a Time-Stamping Authority (TSA) to the original data, thereby generating a second block related to the original data timestamp; generating a third block related to a third party's signature for at least one of the first block and the second block; Applying an administrator signature timestamp issued by the TSA to the third block, thereby generating a fourth block related to the administrator signature timestamp; sequentially recording the first to fourth blocks in the ledger of the original blockchain; and migrating the original blockchain to another blockchain.
  • TSA Time-Stamping Authority
  • the migrating step includes: extracting the positions of the first to fourth blocks from the original blockchain based on the fourth block; Verifying the integrity of the first to fourth blocks; and sequentially storing information included in the first to fourth blocks in blocks of the other blockchain.
  • the first block includes a user certificate that can prove the user's identity, a content ID of the original data, a creation time of the original data indicated by the user, a content ID of the original data, and the content ID of the original data. It may include first essential information including at least one signature of the time of creation of the original data.
  • the method may further include determining whether to encrypt the content ID of the original data.
  • the first essential information is, when the content ID of the original data is encrypted, at least one of a symmetric-key algorithm and an initial vector used to encrypt the content ID of the original data. It may further include, when the content ID of the original data is not encrypted, at least one of a hash of the original data and a hash algorithm of the original data.
  • the second to fourth blocks may include second to fourth essential information and second to fourth index information, respectively.
  • the step of storing the first essential information in a block of another blockchain includes: storing the first essential information as essential information in a first migration block constituting the other blockchain; Storing the second essential information as essential information in a second migration block constituting the other blockchain, and storing the location of the first migration block as index information in the second migration block; Storing the third essential information as essential information in a third migration block constituting the other blockchain, and storing the location of the second migration block as index information in the third migration block; Storing the fourth essential information as essential information in a fourth migration block constituting the other blockchain, and storing the location of the third migration block as index information in the fourth migration block; And essentially storing the hash of at least one block among the first to fourth blocks as index information in the first migration block, and including the Genesis Block Hash and Block Height of the original blockchain. and selectively storing at least one of the unique IDs of individual transactions as index information in the first migration block.
  • the original data timestamp proves that the original data existed at a specific point in time after the time of creation of the original data indicated by the user, and the specific point in time is when the TSA It may be characterized as the time of issuing the original data timestamp or the time of generating the second block.
  • the second block may include the second essential information including at least one of a content ID for the first essential information and information about the original data timestamp.
  • the second block may include the second index information, including the location of the transaction in which the first essential information is recorded.
  • the third block includes the third essential information including at least one of a third-party certificate that can prove the identity of the third party, a certification body of the third party, and a signature on the certification body. may include.
  • the third party's authentication body may include a content ID for the first essential information, a content ID for the second essential information, and the third party's authentication point indicated by the third party. there is.
  • the third block may include the third index information, including the location of the transaction in which the second essential information is recorded.
  • the fourth block may include the fourth essential information including at least one of a content ID for the third essential information and information about the administrator signature timestamp.
  • the fourth block may include the fourth index information, including the location of the transaction in which the third essential information is recorded.
  • a blockchain-based data management device includes a memory storing at least one program; and a processor that operates by executing the at least one program.
  • the processor generates a first block for the user's original data, applies an original data timestamp issued by TSA (Time-Stamping Authority) to the original data, and generates the original data timestamp.
  • TSA Time-Stamping Authority
  • a fourth block related to the administrator signature timestamp is generated, the first to fourth blocks are sequentially recorded in the ledger of the original blockchain, and the original blockchain is migrated to another blockchain,
  • the migration includes extracting the positions of the first to fourth blocks from the original blockchain based on the fourth block, verifying the integrity of the first to fourth blocks, and It may further include sequentially storing the information included in blocks of the other blockchain.
  • the first block includes a user certificate that can prove the user's identity, a content ID of the original data, a creation time of the original data indicated by the user, a content ID of the original data, and the content ID of the original data. It may include first essential information including at least one signature of the time of creation of the original data.
  • the processor determines whether to encrypt the content ID of the original data, and the first essential information is, when the content ID of the original data is encrypted, the content ID of the original data is encrypted. It further includes at least one of a symmetric-key algorithm and an initial vector used to do so, and when the content ID of the original data is not encrypted, at least one of a hash of the original data and a hash algorithm of the original data. It may further include.
  • the second to fourth blocks may include second to fourth essential information and second to fourth index information, respectively.
  • storing in the block of the other blockchain stores the first essential information as essential information in the first migration block constituting the other blockchain, and stores the second essential information in the other block.
  • Store the second migration block constituting the chain as essential information store the location of the first migration block as index information in the second migration block, and store the third essential information in the third migration block constituting the other blockchain.
  • Store the location of the second migration block as essential information in the migration block store the location of the second migration block as index information in the third migration block, and store the fourth essential information as essential information in the fourth migration block constituting the other blockchain.
  • the location of the third migration block as index information in the fourth migration block essentially storing the hash of at least one block among the first to fourth blocks as index information in the first migration block, and including the Genesis Block Hash and Block Height of the original blockchain. And it may further include selectively storing at least one of the unique IDs of individual transactions as index information in the first migration block.
  • a system for distributing content IDs includes a user terminal that uploads one or more content IDs corresponding to one or more backup data to a publishing server; the publishing server that publishes a content ID list including the one or more content IDs to a web server; a pinning server that transmits a data request for pinning the one or more backup data to the web server and performs pinning on the one or more backup data; and the web server transmitting a return content ID list included in the content ID list to the pinning server in response to the data request.
  • the publishing server that publishes a content ID list including the one or more content IDs to a web server
  • a pinning server that transmits a data request for pinning the one or more backup data to the web server and performs pinning on the one or more backup data
  • the web server transmitting a return content ID list included in the content ID list to the pinning server in response to the data request.
  • the pinning server may transmit the data request based on at least one of a specified time, request size, first latest primary key, and user authentication information.
  • the data request may request that a list of content IDs corresponding to the size of the request be returned for content IDs uploaded before the specified time among the one or more content IDs.
  • the web server may transmit the returned content ID list to the pinning server based on the user authentication information if it has authority to access the content ID list.
  • the web server may not transmit the return content ID list if the pinning server does not have the access authority.
  • the user authentication information is information that can authenticate that the user has the access authority without a separate login procedure and may correspond to at least one of a token, a digital signature, and a decentralized identifier (DID). You can.
  • the content ID list further includes one or more owner authentication information, wherein the one or more owner authentication information authenticates an owner for each of the one or more content IDs. It could be information.
  • a data encryption method includes receiving original data and a user input for selecting one of a plurality of upload buttons for the original data; determining whether to encrypt the original data based on the user input; And according to the decision, uploading the original data or encrypted data obtained by encrypting the original data to the IPFS network.
  • the IPFS network may include multiple sharers.
  • the uploading to the IPFS network includes obtaining the encrypted data by encrypting the original data with an encryption key; Splitting the encryption key into a plurality of subkeys; Encrypting the plurality of sub-keys with the public key of each of the plurality of sharers and distributing them to the plurality of sharers; and uploading the encryption data, the plurality of subkeys, and information about the encryption key to the IPFS network.
  • the IPFS network after uploading to the IPFS network, destroying the encryption key; Receiving a decryption request for the encrypted data from the user; Receiving from some of the plurality of sharers some of the plurality of sub-keys decrypted by each of the plurality of sharers with their respective private keys and re-encrypted with the user's public key; and downloading the encryption data and information about the encryption key from the IPFS network, and recovering some of the plurality of subkeys with the encryption key based on the information about the encryption key.
  • the encryption key corresponds to a symmetric key that enables both encryption of the original data and decryption of the encryption data
  • information about the encryption key includes encryption key specification and encryption key.
  • receiving the decryption request includes verifying that the user is the owner of the original data based on the user's public key; It may further include.
  • receiving some of the plurality of sub-keys includes receiving some of the plurality of sub-keys decrypted by some of the plurality of sharers with respective secret keys; It may further include.
  • the plurality of upload buttons may include a first button and a second button that are form data objects on a web browser.
  • the determining step determines to encrypt the original data based on a user input of selecting the first button containing a predetermined string, and the second button does not contain the predetermined string. It may further include determining not to encrypt the original data based on a user input of selecting button 2.
  • an apparatus for data encryption includes a memory storing at least one program; and a processor that operates by executing the at least one program.
  • the processor receives original data and a user input for selecting one of a plurality of upload buttons for the original data, and determines whether to encrypt the original data based on the user input, According to the decision, the original data or encrypted data obtained by encrypting the original data may be uploaded to the IPFS network.
  • the IPFS network may include multiple sharers.
  • uploading to the IPFS network involves encrypting the original data with an encryption key to obtain the encryption data, dividing the encryption key into a plurality of subkeys, and dividing the plurality of subkeys into the plurality of sharers. It may include encrypting with each public key, distributing to the plurality of sharers, and uploading the encryption data, the plurality of subkeys, and information about the encryption key to the IPFS network.
  • the step of uploading to the IPFS network may further include destroying the encryption key.
  • the processor receives a decryption request for the encrypted data from the user, decrypts the encrypted data from some of the plurality of sharers with each private key, and decrypts the encrypted data with the user's public key.
  • Receive some of the plurality of subkeys that have been re-encrypted download the encryption data and information about the encryption key from the IPFS network, and use some of the plurality of subkeys based on the information about the encryption key. It may further include recovery using the encryption key.
  • a blockchain network device includes a memory storing at least one program; and a processor that performs calculations by executing the at least one program.
  • the processor obtains a hash value of research record data, executes the research record transaction based on an endorsement request signal for the research record transaction, outputs an endorsement result, and provides the endorsement result and endorsement.
  • a third party is added to the research record data by passing the peer's signature to an orderer, generating a block for the research record transaction based on the endorsement result, and distributing the block to a plurality of peers.
  • a user's signature and timestamping may be applied, and a signal indicating that the block has been created may be transmitted to a user terminal corresponding to one of the plurality of peers.
  • the research record transaction may be created in response to the upload of the research record data.
  • a certification authority participates as the orderer
  • a research institute configures the plurality of peers
  • the third party's signature may be the signature of the research institute.
  • the timing of the timestamping may be the timing at which the orderer creates the block or the timing at which the block is distributed to the plurality of peers.
  • the user terminal acquires research record data, creates a research record transaction corresponding to the upload of the research record data, and transmits a guarantee request signal for the research record transaction to the blockchain network. , Displays identification information and timestamping information of the block for the research record transaction based on user input confirming the research record data, but if the user downloads the electronic file to which the research record data is uploaded, the electronic file
  • a research note management application that generates a cover page and provides it to the user may be executed.
  • the electronic file may be processed to include the cover in accordance with preset formal requirements and an authentication mark indicating that the electronic file is a research note with public trust.
  • the authentication mark indicating that the electronic file is a research note with public trust includes the researcher's name, the researcher's signature, the creation date of the research record data, the assurance result output based on the assurance request signal, and the The point of time stamping may be included.
  • data processes can be managed separately within one blockchain, and data authentication processes can be proven independently of the time order within the blockchain.
  • security can be strengthened by dividing and storing decryption rights for encrypted data using secret sharing.
  • an algorithm for determining whether to encrypt without going through a server can be provided.
  • the reliability of research note data can be guaranteed and the cost of agreement can be reduced.
  • the time it takes to process a transaction or create a block can be reduced.
  • Figure 1 is a conceptual diagram showing the schematic configuration of an IPFS-based distributed file storage system according to an embodiment.
  • Figure 2 is a block diagram showing the configuration of a node according to an embodiment.
  • Figure 3 is a conceptual diagram illustrating a block and blockchain according to an embodiment.
  • Figure 4 is a diagram for explaining the IPFS standard.
  • Figure 5 is an exemplary diagram showing the operation of a system for distributing content ID according to an embodiment.
  • Figure 6 is an example diagram illustrating a content ID list and a returned content ID list according to an embodiment.
  • Figure 7 is a flowchart illustrating a redundancy condition algorithm according to an embodiment.
  • Figure 8 is a flowchart explaining a blockchain-based data management method according to an embodiment.
  • Figure 9 is a diagram for explaining the process of implementing a virtual blockchain according to an embodiment.
  • Figure 10 is a block diagram showing the configuration of an original blockchain according to an embodiment.
  • FIG 11 is a flowchart to explain the blockchain migration process according to one embodiment.
  • Figure 12 is a block diagram of a data encryption system according to one embodiment.
  • FIG. 13 is a flowchart of an encryption algorithm according to one embodiment.
  • Figure 14 is a flowchart of a decryption algorithm according to one embodiment.
  • Figure 15 is a flowchart of a data encryption method according to one embodiment.
  • 16 is a block diagram of a data encryption and data management device.
  • Figure 17 is an example of the configuration of a blockchain-based research note management system (2010) according to an embodiment of the present invention.
  • Figure 18 shows an example of the configuration of a blockchain network 2300 according to an embodiment of the present invention.
  • Figure 19 is an example of the signal flow of a blockchain-based research note management system according to an embodiment of the present invention.
  • Figures 20 and 21 are diagrams to explain an example of uploading an electronic file through a research note management application according to an embodiment of the present invention.
  • Figure 22 is a diagram illustrating an example of granting permission to use a research note management application to another person according to an embodiment of the present invention.
  • Figures 23 and 24 are diagrams to explain an example in which an electronic file uploaded to a research note management application according to an embodiment of the present invention is downloaded.
  • Figure 25 is a diagram to explain an example in which electronic files uploaded through a research note management application according to an embodiment of the present invention are managed based on blockchain technology.
  • Figure 26 is a diagram to explain an example in which a research note management application according to an embodiment of the present invention is linked with another service.
  • Figure 27 is a diagram for explaining an example of searching electronic files uploaded to a research note management application according to an embodiment of the present invention.
  • Some embodiments of the present disclosure may be represented by functional block configurations and various processing steps. Some or all of these functional blocks may be implemented in various numbers of hardware and/or software configurations that perform specific functions.
  • the functional blocks of the present disclosure may be implemented by one or more microprocessors, or may be implemented by circuit configurations for certain functions.
  • functional blocks of the present disclosure may be implemented in various programming or scripting languages.
  • Functional blocks may be implemented as algorithms running on one or more processors.
  • the present disclosure may employ conventional technologies for electronic environment setup, signal processing, and/or data processing. Terms such as “mechanism,” “element,” “means,” and “configuration” may be used broadly and are not limited to mechanical and physical configurations.
  • connection lines or connection members between components shown in the drawings merely exemplify functional connections and/or physical or circuit connections. In an actual device, connections between components may be represented by various replaceable or additional functional connections, physical connections, or circuit connections.
  • Figure 1 is a conceptual diagram showing the schematic configuration of an IPFS-based distributed file storage system according to an embodiment.
  • the IPFS-based distributed file storage system 100 may include a main server 110, an IPFS network 120, a sharer terminal 130, and a requester terminal 140. Additionally, the IPFS network 120 may include IPFS nodes 121, 122, 123, and 124.
  • the main server 110 performs control and management of the IPFS network 120, and at this time, the main server 110 can be said to perform the role of a peer leader. Therefore, among the IPFS nodes 121, 122, 123, and 124, the main server 110 may be the peer leader. Alternatively, it is also possible to have a separate main server 110 to perform a management role for the IPFS nodes (121, 122, 123, and 124).
  • the main server 110 can be the entity that performs file encryption, split processing, and distributed storage to the IPFS nodes 121, 122, 123, and 124, and forms the IPFS network 120 and plays the role of a peer leader. If it can be performed, there are no separate restrictions.
  • the main server 110 monitors the IPFS nodes (121, 122, 123, 124) through active monitoring to determine the operating status of the IPFS nodes (121, 122, 123, 124) and passive monitoring to monitor the upload/download status of data. ) and distributed storage of data through it, as well as control and monitoring of data upload and download.
  • the main server 110 distributes and communicates an application loaded with a unique code for each user to the user terminal 130, and verifies and confirms the document, restores the results, and records the processing history. It may further include an application server (not shown) that manages and processes re-authentication in case of change or loss of the user terminal.
  • the IPFS nodes (121, 122, 123, and 124) not only store and process the data pieces into which the file is divided in the IPFS network 120, but also store transaction information that may include the download history or upload history of the file. It performs the function of storing a copy of the included block and the blockchain in which the block is accumulated. Blocks and blockchain are explained in detail in FIG. 3.
  • IPFS nodes 121, 122, 123, and 124 may refer to any computing equipment that receives a Contents ID (Contents Identification, CID) as input and has the ability to recover the original data of the Content ID. Additionally, IPFS nodes (121, 122, 123, and 124) can communicate with each other through various communication means such as a central server, relay server, P2P network, and blockchain network.
  • a Contents ID Contents Identification, CID
  • CID Contents Identification
  • the content ID is the unique name of the original file data. Like the hash value of data, even if the two data have different file names such as “ABC.txt” and “DEF.txt”, if the data contents are the same, they will have the same content ID.
  • the content ID has a very small size compared to the original file and can be generated based on the calculation result of a cryptographic hash function.
  • the main server 110 which supplies content IDs to the IPFS nodes (121, 122, 123, 124), communicates with the IPFS nodes (121, 122, 123, 124) to supply content ID information and prevents unauthorized use. It is possible to have an authentication method to prevent this.
  • the communication means itself does not need to be a secure channel.
  • Authentication methods include network methods that restrict IP addresses, user authentication methods using encryption technology, user authentication through blockchain networks (120), or methods that prevent unauthorized users from arbitrarily entering content IDs into the IPFS network (120). All methods can be included. In this case, illegal use can be prevented at the source through authentication procedures or illegal use can be prevented from increasing beyond a certain percentage through proof of work, etc.
  • the content ID provided by the main server 110 may be the content ID of the original file or the content ID of the result of encrypting the original according to requirements.
  • separate metadata for sharing encryption standards can be shared. Metadata can only contain information that has no security vulnerabilities even if the original is exposed. For example, there are types of encryption algorithms, padding methods, and initial vector values.
  • the sharing terminal 130 and the requesting terminal 140 may themselves be IPFS nodes (121, 122, 123, 124), or may use existing IPFS nodes (121, 122, 123, 124) through a relay server. It may be a terminal being used.
  • the sharer terminal 130 and the requester terminal 140 refer to terminals that perform upload and download of files, and may include terminals that can transmit and receive various document data via a communication network according to key manipulation.
  • the sharer terminal 130 and the requester terminal 140 are a tablet terminal, a laptop, a personal computer (PC), a smartphone, and a personal digital assistant (PDA). It may be either a Digital Assistant) or a wireless terminal.
  • IPFS nodes (121, 122, 123, 124) can use the cryptographic hash function of the content ID to complete verification of the possibility of forgery and alteration of the original file without the help of the main server 110, and the original file of the content ID is IPFS. Even if it is stored in any device on the network 120, it can be searched and retrieved through automated procedures.
  • Figure 2 is a block diagram showing the configuration of a node in a blockchain network according to an embodiment.
  • the node 200 may include a communication unit 210, a processing unit 220, and a storage unit 230. Additionally, the node 200 may be the same as or perform the same function as the IPFS nodes 121, 122, 123, and 124 of FIG. 1.
  • the communication unit 210 may provide an interface for transmitting and receiving data inside or outside the blockchain.
  • a distributed ledger may be stored in the storage unit 230.
  • blocks, smart contracts, accounts, transactions, etc. can be stored.
  • the processing unit 220 can process the contents of transactions stored in blocks of a blockchain, a distributed ledger, stored in the storage unit 230.
  • the configuration of the processing unit 220 may vary depending on the function of the corresponding node.
  • the functions of the node include an integrated management function, a block creation function, and a block verification function.
  • the processing unit 220 of the integrated management node can perform overall pool management, P2P management, and block synchronization management functions, and the processing unit 220 of the block generation node can perform block generation.
  • the processing unit 220 of the block verification node can perform block verification and consensus.
  • the IPFS node 200 may correspond to a node that performs functions other than the above-described functions or a combination of functions as well.
  • Figure 3 is a conceptual diagram illustrating a block and blockchain according to an embodiment.
  • the blockchain 300 is a type of distributed database of one or more sequentially connected blocks 310, 320, and 330.
  • Blockchain 300 is used to store and manage the addition, deletion, and update of user information (transactions) within the blockchain system, and each node participating in the network of the blockchain system creates blocks (310, 320, 330). ) can be created and connected to the blockchain 300.
  • blocks 310, 320, and 330 are shown in Figure 3, the number of blocks that can be included in the blockchain is not limited thereto.
  • Each block (310, 320, 330) included in the blockchain 300 has a unique hash value (311, 321, 331), a block header (312, 322, 332) and a block body (313, 323, 332). 333).
  • Blockchain 300 may include one or more connected blocks 310, 320, and 330.
  • the block headers 312, 322, and 332 may include the hash value of the previous block to indicate the connection relationship between each block 310, 320, and 330.
  • the hash value of the previous block included in the block headers 312, 322, and 332 is the hash value for the previous block and is the same value as the current hash included in the previous block.
  • the block header 322 of block N may include the hash value (311) of block N-1 (310) to indicate a connection relationship with the previous block, block N-1 (310). You can.
  • the block header 332 of block N+1 330 may include the hash value 321 of block N 320 to indicate a connection relationship with block N 320, which is the previous block. The connection relationship within the block headers 312, 322, and 332 expressed in this way can be used in the validation process of the blockchain 300.
  • Blocks 310, 320, and 330 are connected in chain by the hash value of the previous block in each block header 312, 322, and 332. Nodes participating in the decentralized network verify the validity of the block based on the hash value of the previous block included in the blocks 310, 320, and 330, so a single malicious node cannot forge or alter the contents of an already created block. The action is impossible.
  • the block bodies 313, 323, and 333 may include data stored and managed in the blocks 310, 320, and 330, that is, a transaction list (not shown).
  • the transaction list (not shown) is a list of blockchain-based transactions.
  • the transaction list (not shown) may be expressed in tree form.
  • Blocks 310, 320, and 330 may include other information in addition to the information included in the block headers 312, 322, and 332 and the block bodies 313, 323, and 333.
  • operations according to various embodiments may be understood as being performed by a processor included in a content ID distribution method or content ID distribution system.
  • operations according to various embodiments may be understood as being performed by a processor included in a blockchain-based data management method or a blockchain-based data management device.
  • Figure 4 is a diagram for explaining the IPFS standard.
  • the environment in which IPFS is implemented may include a user terminal 410, a publishing server 420, and a storage providing server 430, 440, and 450.
  • the user terminal 410 and the announcement server 420 may be the same as or perform the same function as the sharer terminal 130 and the main server 110 of FIG. 1, respectively, and the storage providing servers 430, 440, and 450 may be the same as the IPFS network 120 of FIG. 1 or may perform the same function.
  • the announcement server 420 provides online applications using IPFS or corresponds to a server that provides IPFS services.
  • the publishing server 420 may receive a file from the user terminal 410 that receives the application or the service and announce a unique content ID corresponding to the file of the user terminal 410. In other words, the content ID can be announced so that the file is distributed and stored on the storage providing servers 430, 440, and 450.
  • the file is stored as a content ID in the storage providing server (430, 440, 450), and the actual act of allocating capacity to the physical hard disk by the storage providing server (430, 440, 450) is called pinning. Therefore, the storage providing servers 430, 440, and 450 may be referred to as pinning servers or pinning service providers.
  • the user terminal 410 uploads a specific file as a content ID using the IPFS service of the publishing server 420, it does not automatically pin it to the storage providing servers 430, 440, and 450. Specifically, when a file corresponding to a specific content ID is uploaded to the first storage providing server 430, the content is stored on all servers around the world, including the remaining second storage providing server 440 and third storage providing server 450. You can access the files of the ID, but this does not mean that the files of the content ID are distributed and stored on all servers around the world.
  • the second storage providing server 440 communicates with the first storage providing server 430.
  • the file is read and provided to the user terminal 410. Therefore, if the content ID cannot be read due to the actual storage first storage providing server 430 being down or unstable, there is a problem in which the content ID cannot be accessed. Accordingly, it becomes important to pin files to IPFS servers distributed around the world, that is, servers providing storage.
  • the publishing server 420 announces the content ID list uploaded by the user terminal 410 through HTTP, and how each storage providing server 430, 440, and 450 pins the content ID to each node. In order to determine this, the method for distributing content IDs will be described in detail.
  • Figure 5 is an exemplary diagram showing the operation of a system (hereinafter referred to as 'system') for distributing content IDs according to an embodiment.
  • the environment in which the system operates may include a user terminal 510, an announcement server 520, a web server 521, a pinning server 530, and a pinning server database (not shown).
  • the user terminal 510, announcement server 520, and pinning server 530 are the same as or identical to one of the user terminal 410, announcement server 420, and storage provision server 430, 440, and 450 in FIG. 4, respectively. It may be performing a function.
  • only one pinning server 530 is shown, but the number is not limited.
  • the user terminal 510 using the IPFS service of the publishing server 520 may upload the content ID corresponding to the backup data to the publishing server 520.
  • the user terminal 510 can upload one or more content IDs to the publication server 520.
  • the user terminal 510 sets a redundancy requirement for each content ID indicating how many copies of each of the one or more content IDs are required or how many copies are required to be safe, and posts the content ID to the publishing server 520. You can upload it with .
  • the user terminal 510 can upload owner authentication information for backup data or content ID together with the content ID to the publishing server 520 for each content ID or by specifying a specific publishing server in batches.
  • owner authentication information may correspond to one or more of a token, electronic signature, or decentralized identifier (DID).
  • DID decentralized identifier
  • Authentication information is a public key-based method, so even if its contents are made public, it can only prove the owner's identity and it is impossible for a third party to forge the owner's identity.
  • the publishing server 520 may announce a content ID list including content IDs uploaded by the user terminal 510 to the web server 521. In another embodiment, publishing server 520 may publish a list of content IDs including content IDs and redundancy conditions and/or owner authentication information determined for each content ID.
  • the web server 521 may be a standard protocol server based on HTTP API or REST API.
  • each pinning server 530 can independently receive a content ID list and perform pinning, and the publishing server 520 distributes the content ID list to any pinning server 530. Since it is unknown whether or not it has been saved, the security of the backup data of the user terminal 510 and the reliability of the IPFS service provided by the public announcement server 520 can be improved.
  • the pinning server 530 may transmit a data request to the web server 521 requesting a list of published content IDs for pinning backup data of the user terminal 510.
  • the pinning server 530 collects data based on at least one of the specified time (BeforeAt), request size (FetchSize), first latest primary key (Latest Primary Key, LastPK), and user authentication (User Authentication) information. You can send a request.
  • the primary key must be unique for at least an individual content ID, and the content ID itself can serve as a primary key. If the content ID is not wanted to be exposed for some reason, the content ID can be converted to the original using a cryptographic hash function. This can make inference difficult.
  • the designated time may correspond to a time designated to request only a list of content IDs uploaded before a certain point in the published content ID list.
  • the request size is the size of the content ID list to be returned and refers to the number of content IDs included in the content ID list.
  • the data request transmitted by the pinning server 530 may correspond to a request to return a list of content IDs uploaded before a specified time from among the published content ID list in the number corresponding to the request size.
  • the web server 521 may transmit a return content ID list included in the published content ID list to the pinning server 530 in response to a data request from the pinning server 530.
  • the latest primary key (LastPK) transmitted by the pinning server 530 is the latest indicating the upload time of the last content ID in the return content ID list. If the primary key falls within the error range of a predetermined time (for example, less than 1 ms), in other words, the latest primary key transmitted by the pinning server 530 and the latest primary key in the returned content ID list are within a predetermined time unit. If it matches, only the list of content IDs uploaded before the specified time can be returned. This allows the return content ID list to be transmitted without overlapping or missing content IDs even in distributed storage systems where millions of data are uploaded per second.
  • a predetermined time for example, less than 1 ms
  • the user authentication information is information that certifies that the pinning server 530 has the authority to access the backup data without a separate login procedure in order to perform pinning on the backup data of the user terminal 510. Based on this authentication information, the pinning server performs data backup using a portion of the storage space contracted with the user.
  • User authentication information may be received in advance from the user terminal 510 or may be generated with consent.
  • user authentication information may correspond to one or more of a token, electronic signature, or decentralized identifier (DID).
  • the web server 521 further selects the content ID list requested by the pinning server 530 according to conditions such as the validity of the user authentication information presented by the pinning server 530 and the security settings of the pinning server 530.
  • the returned content ID list which is a small content ID list, may be transmitted, or the content ID list may not be returned despite a data request from the pinning server 530.
  • the web server 521 sends the returned content ID to the pinning server 530. If the content ID list is transmitted and the pinning server 530 does not have the access authority, the content ID list may not be transmitted. Alternatively, the return content ID list transmitted by the web server 521 may be null.
  • FIG. 6 is an example diagram illustrating a content ID list 610 and a returned content ID list 620 according to an embodiment.
  • the content ID list 610 published by the publishing server or the returned content ID list 620 transmitted by the web server includes one or more content IDs, a redundancy condition corresponding to each of the one or more content IDs, and owner authentication information. may be included, and each content ID list 610, 620 may include one corresponding latest primary key.
  • the web server compares it with the latest primary key PK#4 in the published content ID list 610 and searches for a matching data in a predetermined time unit.
  • data before PK#4 can be sent to the pinning server as a return content ID list (620).
  • the first pinning server and the second pinning server exist in parallel, the first pinning server and the second pinning server do not communicate between servers, so each server receives the returned content from the web server.
  • the ID list 620 and which content ID was pinned are unknown.
  • the redundancy condition algorithm determines which content IDs each pinning server will pin to each component node
  • storage providers operating pinning servers can easily expand servers and achieve high scalability.
  • a method in which the pinning server performs pinning according to the redundancy condition algorithm will be described in detail with reference to FIG. 7.
  • Figure 7 is a flowchart illustrating a redundancy condition algorithm according to an embodiment.
  • the redundancy condition algorithm ensures that each node is pinning to satisfy the redundancy condition based on the number of nodes constituting the pinning server, the redundancy condition included in the returned content ID list, and the pinning server database.
  • the pinning server database stores information about content IDs that were previously pinned on the pinning server.
  • redundancy condition algorithm described below is only an example, and various other algorithms that ensure pinning to satisfy the redundancy condition can be used.
  • step 710 assuming that the pinning server consists of X nodes, the pinning server randomly selects a prime number N greater than It can be allocated as evenly as possible. ‘As evenly as possible’ means assigning N numbers so that the difference between the numbers distributed to each node is at most 1. At this time, since N is a natural number greater than X, there may be nodes assigned more than one number.
  • each node of the pinning server may independently obtain the return content ID list from the web server. Afterwards, the owner authentication information in the obtained returned content ID list can be compared with the content ID stored in the pinning server database to filter the list of content IDs to be pinned. Accordingly, each node can pin the content ID without duplication.
  • each node of the pinning server may extract a redundancy condition M of a content ID from a list of returned content IDs for any content ID to be determined as to whether or not to pinning. Additionally, each node of the pinning server can select the largest natural number A whose product with M is N or less. In other words, you can select the largest natural number A such that A*M is N or less.
  • each node of the pinning server may convert the corresponding content ID into a byte array.
  • each node of the pinning server can convert the content ID into a byte array using various codecs such as Bases64 and ASC type.
  • each node of the pinning server can obtain an integer K by expressing the byte array again in binary, and obtain a natural number R by dividing K by A.
  • each node of the pinning server pins the content ID to the node if there is a number matching R among the assigned numbers (750), and if there is no number matching R among the assigned numbers, it pins the content ID to the node. No pinning (760).
  • each node of the pinning server checks the returned content ID list for another random content ID to determine whether to pinning, or another random content ID filtered by comparison with the content ID stored in the pinning server database. Steps 720 to 740 may be repeatedly performed.
  • embodiments according to the present invention may be implemented in the form of a computer program that can be executed through various components on a computer, and such a computer program may be recorded on a computer-readable medium.
  • the media includes magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and ROM.
  • RAM, flash memory, etc. may include hardware devices specifically configured to store and execute program instructions.
  • the computer program may be designed and configured specifically for the present invention, or may be known and available to those skilled in the art of computer software.
  • Examples of computer programs may include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • methods according to various embodiments of the present disclosure may be included and provided in a computer program product.
  • Computer program products are commodities and can be traded between sellers and buyers.
  • the computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store (e.g. Play StoreTM) or between two user devices. It may be distributed in person or online (e.g., downloaded or uploaded). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.
  • a machine-readable storage medium such as the memory of a manufacturer's server, an application store's server, or a relay server.
  • Figure 8 is a flowchart explaining a blockchain-based data management method according to an embodiment.
  • a blockchain-based data management device (hereinafter referred to as 'device') can receive original data from a user and provide a service for managing the original data based on blockchain.
  • the original data may correspond to a research note written by a researcher, and the device generates a transaction regarding the contents of the research note, authentication by the administrator, time of creation of the research note, and time of authentication by the administrator, etc., and records it on the blockchain. It can be saved on the network. Through this, the information of the author and manager of the research note and the manager's approval process can be stored and managed.
  • the original data may be written directly to the blockchain network, or may be written to an IPFS-based system using an indirect distributed storage method through IPFS.
  • the device may generate a first block for the user's original data.
  • the first block may include a transaction list regarding the original data, such as information about the user who created the original data, the existence of the original data, and the creation time of the original data.
  • the creation time of the original data may correspond to the time the user claims to have created the original data, regardless of the timestamp of the certification authority as described later. Therefore, in this case, the original data creation time indicated by the user may not have legal effect.
  • the device may determine whether to encrypt the content ID of the original data. Because data recorded on the blockchain can be viewed by anyone, devices can decide whether to encrypt the content ID of the original data for security purposes.
  • the first block may include a symmetric-key algorithm and/or an initial vector used to encrypt the content ID of the original data.
  • a symmetric key algorithm is a type of encryption algorithm that uses the same encryption key for encryption and decryption.
  • the initial vector is a virtual block and can be used to convert the result of encrypting the initial vector and the block to be encrypted into a ciphertext block by XOR (exclusive OR).
  • the first block may include a hash of the original data and/or a hash algorithm of the original data.
  • the device may apply the original data timestamp issued by the Time Stamping Authority (TSA) to the received original data to generate a second block related to the original data timestamp.
  • TSA Time Stamping Authority
  • TSA is an organization that issues timestamps, that is, an organization that provides point-in-time authentication services.
  • the TSA service consists of a process in which a time-certification agency certifies the creation and modification time of the original data. By performing timestamping by TSA, even the owner of the original data cannot be changed, so the original data existed at the time TSA issued a timestamp for the original data or created a block related to the timestamp issued by TSA, and thereafter You can prove that it has not changed.
  • the device transmits a hash of the user's original data to the TSA to request issuance of a timestamp, obtains a timestamp token from the TSA, and injects it into the original data, thereby applying a timestamp to the original data. there is. Additionally, the device may generate a second block for the original data timestamp issued by TSA.
  • the timestamp of the second block is the Block 1 can also guarantee that it was created at the same time as or before the time when the second block was created.
  • the device may generate a third block related to a third party's signature for at least one of the first block and the second block.
  • third party may refer to a third party other than the user who created the original data.
  • the third party may be the research institution to which the user who wrote the research note belongs or the administrator of the research institution.
  • the signature may correspond to a content ID for an image file of an analog signature.
  • the signature may include an electronic signature using private key and public key encryption.
  • the third block contains information about the third party signing, information about the user who created the original data that is the subject of the signature and the original data timestamp issued by TSA, and the time of the third party's signature. It may contain a list of transactions related to signatures. In this case, as with the creation time of the original data, the third party's signature time may correspond to the time that the third party claims to have signed and may not have legal effect.
  • step 840 the device may sequentially record the first to third blocks in the ledger of the original blockchain.
  • the original blockchain network may correspond to blockchain 300 in FIG. 3, and the first to third blocks may correspond to one or more blocks 310, 320, and 330 in FIG. 3. there is.
  • the original blockchain network may be linked to the IPFS-based distributed file storage system 100 of FIG. 1.
  • the device records the first to third blocks in the ledger of the original blockchain network, and the original data is distributed to the IPFS-based file distributed storage system 100 or IPFS nodes 121, 122, 123, and 124. You can save it.
  • Figure 9 is a diagram for explaining the process of implementing a virtual blockchain according to an embodiment.
  • the content recorded on the blockchain is information signed with a public key as a 'blockchain wallet' and has nothing to do with an individual's electronic signature.
  • RSA-based certificates issued as public certificates are not compatible with certificates based on the Elliptic Curve Cryptosystem used in blockchain.
  • the universal blockchain technology which has a linear order regardless of the data type, the user's original data is created, a timestamp issued by the TSA is applied to it, and a third party's signature is placed on the original data and/or timestamp. It cannot be implemented so that an authentication chain exists for each source data.
  • the original blockchain 900 may include blocks N-2 to blocks N+3 (910 to 960). Since blocks N-2 to blocks N+3 (910 to 960) store generated transactions in order, they are connected to a chain in a linear order. For convenience of explanation, six blocks are shown, but the number is not limited thereto.
  • the device may sequentially record the first to third blocks in the original blockchain 900. Therefore, each block may correspond to any one of blocks N-1 to blocks N+3 (910 to 960).
  • recording blocks 'sequentially' does not mean recording them as consecutive blocks.
  • the first block 910 was recorded in the original blockchain 900 before the second block 930, but the first block 910 and the second block 930 are not neighbors. You can confirm that it is not.
  • the second block may include the location of the first block.
  • the third block may include the location of the first and/or second block.
  • the device can create a block containing the location information of the block it wants to connect to the virtual chain.
  • each block created by the device can have a separate connection relationship as a virtual chain.
  • Figure 10 is a block diagram showing the configuration of an original blockchain according to an embodiment.
  • block N-1 (1010), block N (1020), and block N+1 (1030) are blocks connected in succession, and block N-1 (1010) and block N+1 (1030) are It is a block connected to a virtual chain (1013).
  • each block (1010, 1030) connected to the virtual chain (1013) may include essential information (1011, 1031) and/or index information (1012, 1032).
  • Required information (1011, 1031) is information about the content stored in the block.
  • essential information included in the first block may be information about original data written by the user.
  • Index information (1012, 1032) is information referenced to connect the virtual chain (1013).
  • the index information included in the second block may be information about the location of the first block.
  • the index information included in the second block includes information about the location of the first block, it can be defined that the first block and the second block are connected by a virtual chain. For example, assuming that block N-1 (1010) is the first block and block N+1 (1030) is the second block, the index information 1032 of the second block 1030 is the first block 1010. It may include information about the location or N-1, which is the block number of the first block 1010.
  • the index information (1012, 1032) must ensure that the above-mentioned essential information (1011, 1031) has not changed.
  • the hash value of the entire required information (1011, 1031) using a separate cryptographic hash function separate from the blockchain the hash value of the data including the entire required information (1011, 1031) (e.g., the required information is There are methods to prove the integrity of the block hash of the included block), genesis block hash and block height value, and other essential information (1011, 1031). Users can have one or more index information from the above methods at the same time to improve search performance for each system. At this time, the index information for the previous block must be included in the essential information for the next block. Meanwhile, if it does not contain index information, it can be replaced with a copy of the original data. This will be described in detail later in Figure 7.
  • each block is managed by connecting it to a virtual chain, making data management and migration to other blockchains easier.
  • the first block 910 may include first essential information.
  • the first essential information is at least a user certificate that can prove the identity of the user who created the original data, the content ID of the original data, the time of creation of the original data indicated by the user, and the content ID of the original data and a signature regarding the time of creation. It can contain one.
  • the user certificate may mean the user's public key, and the content ID of the original data and the signature for the time of creation of the original data may use the user certificate as is.
  • the first block 910 may include all information indicating that the user created original data.
  • the second block 930 may include second essential information. Additionally, the second essential information may include at least one of a content ID for all of the first essential information and information about an original data timestamp for the first essential information.
  • the content ID for the entire first essential information refers to the content ID corresponding to the entire first essential information as one piece of data, separately from the content ID of the original data.
  • the timestamp corresponds to the one issued by TSA for time authentication of the first required information. At this time, the timestamp may follow the RFC 3161 standard.
  • the second block 930 may include second index information. Additionally, the second index information may include the location of the block or transaction in which the first essential information is recorded. For example, the second index information may include the location of the first block 910 in which the first essential information is recorded or the detailed location of the transaction within the first block 910 in which the first essential information is recorded. Accordingly, the first block 910 and the second block 930 can be connected to the virtual chain through the second index information.
  • the second block 930 may include all information regarding TSA's point-in-time authentication of the original data and connection with the first block 910.
  • the third block 940 may include third essential information.
  • the third essential information may include at least one of a third-party certificate that can prove the identity of the third party, a third-party certification text, and a signature on the certification text.
  • the third party's authentication body may include a content ID for all of the first essential information, a content ID for all of the second essential information, and the third party's authentication point indicated by the third party.
  • the third-party certificate may mean a third-party public key, and the third-party certificate may be used as a signature on the third-party certification body.
  • the third block 940 may include third index information. Additionally, the third index information may include the location of the block or transaction in which the second essential information is recorded. Accordingly, the second block 930 and the third block 940 can be connected to the virtual chain through the third index information.
  • the third index information may further include the location of the block or transaction in which the first essential information is recorded. Accordingly, the first block 910 and the third block 940 can be connected to the virtual chain through the third index information.
  • the third block 940 may include all information regarding the original data, third-party authentication of the original data timestamp, and connection with the second block 930.
  • the device may apply the administrator signature timestamp issued by the TSA to the third block 940 to generate the fourth block 960 regarding the administrator signature timestamp.
  • TSA can authenticate once more whether a third party performed the authentication role for the original data and the original data timestamp at the appropriate time.
  • the device can record the fourth block 960 in the ledger of the original blockchain 900.
  • the fourth block 960 may include fourth essential information. Additionally, the fourth essential information may include at least one of information about a content ID for all of the third essential information and an administrator signature timestamp for all of the third essential information.
  • the fourth block 960 may include fourth index information. Additionally, the fourth index information may include the location of the block or transaction in which the third essential information is recorded. Accordingly, the fourth block 960 can be connected to the third block 940 and the virtual chain through the fourth index information.
  • the fourth index information may further include the location of each block or the location of each transaction in which the first and/or second essential information is recorded. Accordingly, the fourth block 960 can be connected to the first block 910 and/or the second block 940 in a virtual chain through the fourth index information.
  • the fourth block 960 may include all information regarding TSA's point-of-view authentication for the third party's authentication and connection with the third block 940.
  • proof of the time order of the above-mentioned first to fourth blocks is possible not only through blockchain but also through a timestamp separately issued by TSA, and the order of blocks can be reconstructed and proven through the timestamp.
  • FIG 11 is a flowchart to explain the blockchain migration process according to one embodiment.
  • the device can migrate the original blockchain to another blockchain.
  • another blockchain may be a new blockchain following a hard fork.
  • the other blockchain may be a new blockchain with a completely different domain from the original blockchain. The migration process is explained in detail below.
  • the device may extract the positions of the first to fourth blocks in the original blockchain based on the fourth block.
  • the device may extract the location of the third block from the fourth index information included in the fourth block, and extract the location of the second block from the third index information included in the third block.
  • the location of the first block can be extracted from the second index information included in the second block.
  • the device may extract the positions of all the first to third blocks from the fourth index information.
  • the device can obtain all of the first to fourth essential information from the first to fourth blocks. Additionally, the device can obtain all information including content ID, certificate, creation or authentication time, signature, etc. from the first to fourth essential information.
  • the device may verify the integrity of the first to fourth blocks.
  • the device may verify the integrity of the first to fourth blocks by verifying the validity of the hash value and digital signature recorded in the first to fourth blocks.
  • the device may sequentially store information included in the first to fourth blocks in blocks of another blockchain.
  • the blocks of other blockchains to which the first to fourth blocks of the original blockchain will be migrated are defined as the first to fourth migration blocks, respectively.
  • the device may store the first essential information as essential information in the first migration block. Additionally, the device may store the second essential information as essential information in the second migration block, and store the location of the first migration block as index information in the second migration block. Additionally, the device may store the third essential information as essential information in the third migration block, and store the location of the second migration block as index information in the third migration block. Likewise, the device may store the fourth essential information as essential information in the fourth migration block, and store the location of the third migration block as index information in the fourth migration block.
  • the index information of the third migration block may further include the location of the first migration block
  • the index information of the fourth migration block may further include the location of the first and/or second migration block.
  • the device stores the hash of at least one block among the first to fourth blocks of the original blockchain in which the data to be referenced is stored, the Genesis Block Hash, the block height, and the unique value of each transaction. At least one of the IDs may be stored as index information of the first migration block.
  • the device may essentially include the hash of at least one block among the first to fourth blocks of the original blockchain in which the reference data is stored as index information of the first migration block, including a genesis block hash, At least one of the block height and the unique ID of an individual transaction may be optionally included as index information of the first migration block.
  • the hash of each block of the original blockchain is essential to prove its existence, while the genesis block hash, block height, and unique ID of individual transactions are optional to increase search speed.
  • a genesis block is a block created when a blockchain network first starts, and refers to a block with a block height of 0. Also called block 0.
  • Block height refers to the total number of blocks created from the genesis block.
  • the block height of a specific block is defined as the number of blocks that exist before it in the blockchain. Unlike genesis blocks, every block has a block height because it contains the hash of the immediately previous block.
  • the unique ID of an individual transaction can be information that specifies where (number) in the block the transaction to be referenced in the first to fourth blocks is located.
  • a block related to the original data e.g., the first migration block in another blockchain
  • first index information it means that the blockchain containing the block is a migrated blockchain. You can.
  • Figure 12 is a block diagram of a data encryption system according to one embodiment.
  • a data encryption system may include a web browser 1200, a terminal 1210, and an IFPS network 1260.
  • the terminal 1210 may be the terminal 1210 of a user who owns the original data to be encrypted. Alternatively, the terminal 1210 may be the terminal 1210 of a user requesting data encryption.
  • IPFS network 1260 may be the same as, or may perform the same function as, the IPFS-based distributed file storage system 100 described above in FIG. 1 .
  • IPFS network 1260 may include a plurality of sharers 1270, which are servers that provide IPFS-based services.
  • a plurality of sharers 1270 may perform date encryption by distributing a subkey, which is an encryption key piece. Additionally, the plurality of sharers 1270 may be servers where the owner of the original data can be trusted. However, as will be described later, recovery of the original data may be possible if not all but some of the plurality of sharers 1270 cooperate in decrypting the encrypted data.
  • Web browser 1200 refers to the general term for applications for searching and viewing Internet content based on the World Wide Web (WWW), such as HTML documents, pictures, and multimedia files.
  • WWW World Wide Web
  • Web 3.0 can be implemented by proposing a method of encrypting directly in the web browser 1200 rather than operating IPFS encryption on a separate server.
  • the web browser 1200 may include an input reception unit 1220, an IPFS upload unit 1230, an encryption unit 1240, and a key distribution unit 1250.
  • the input receiver 1220 may receive a user input for selecting one of the original data and a plurality of upload buttons (not shown) for the original data.
  • the plurality of upload buttons may include a first button (not shown) and a second button (not shown) that are form data objects on the web browser 1200.
  • Web 3.0 is also composed of HTML and is stored in the Document Object Model format, which is an interface to a web page, on the web browser 1200, for example, a first button (not shown) and a second button for uploading. (not shown) may have data to upload in the form of a document object model element.
  • the IPFS upload unit 1230 sequentially checks the first button (not shown) and the second button (not shown) so that the ID of each button is set to a predetermined value. It is possible to decide whether to encrypt data depending on whether it contains a string or begins with a predetermined string.
  • the IPFS upload unit 1230 may determine whether to encrypt the original data based on a user input of selecting a first button (not shown) or a second button (not shown). Specifically, the IPFS upload unit 1230 determines to encrypt the original data based on a user input of selecting a first button (not shown) containing a predetermined string, and a second button not containing the predetermined string. It may be decided not to encrypt the original data based on the user input of selecting (not shown). For example, the predetermined string may be “encrypted,” and the IPFS upload unit 1230 checks whether the upload button includes “encrypted” in response to receiving a user input for selecting one upload button. You can decide whether to encrypt the original data.
  • the encryption unit 1240 may obtain encrypted data by encrypting the received original data with an encryption key.
  • the encryption key may be the symmetric key of the original data owner.
  • a symmetric key means a single secret key where the key used for encryption and decryption is the same.
  • the symmetric key encryption method has the characteristic that the encryption key used for encryption and the decryption key used for decryption are the same, so if the original data is encrypted with a symmetric key, the encrypted data can be decrypted with the same symmetric key. Security is more important.
  • the key distribution unit 1250 may divide the encryption key into a plurality of subkeys, which are key fragments, and upload the divided plurality of subkeys to the IPFS network 1260. Alternatively, the key distribution unit 1250 may distribute one divided subkey to each of the plurality of sharers 1270 of the IPFS network 1260.
  • the key distribution unit 1250 may destroy the encryption key after uploading the plurality of divided subkeys and encryption data to the IPFS network 1260.
  • the security of the data can be strengthened by lowering the risk of data being exposed even in the event of an issue such as loss of the device, and especially in cases where the encryption key is a symmetric key.
  • the original owner cannot recover or view the original data on his own without requesting decryption.
  • FIG. 13 is a flowchart of an encryption algorithm according to one embodiment.
  • a data encryption device (hereinafter referred to as 'device') according to an embodiment may provide an algorithm of steps 1310 to 1340 for encrypting original data.
  • the device may obtain encrypted data by encrypting the original data with an encryption key.
  • the device may split the encryption key into a plurality of subkeys.
  • the plurality of subkeys may include a string encrypting the divided encryption key.
  • the device may define a method of dividing an encryption key into a plurality of subkeys (hereinafter referred to as an 'encryption key recovery specification').
  • the encryption key recovery specification must implement Secret Sharing. For example, assuming that the device divides the encryption key into N (N is a natural number greater than or equal to 2) subkeys, the encryption key recovery specification must be at least M (M is a natural number greater than or equal to 1 and less than N) among the N pieces. There must be a condition in which the original data can be recovered only when these two subkeys are gathered, and there must be a condition in which no information can be inferred when (M-1) or less subkeys are gathered.
  • the encryption key recovery specification may be the Shamir Secret Sharing algorithm.
  • the device can split the encryption key into N subkeys according to the encryption key recovery specification.
  • the N divided subkeys exist only in volatile memory (eg, random access memory, RAM), and the device can perform asymmetric encryption with the public key of each of the plurality of sharers who will receive the divided subkeys.
  • the division and the asymmetric encryption may be performed continuously, so that the asymmetric encryption may be performed before the divided subkey is volatilized from memory. Since the subkey is the result of dividing the symmetric key into N pieces and encrypting them with the public key of the owner of each piece (the sharer), the contents of the subkey cannot be confirmed by anyone other than the owner.
  • each subkey may include information about which recovery algorithm specification was used.
  • the recovery algorithm may include information about which symmetric key encryption algorithm was used for the result of the recovery process (i.e., symmetric key). This is called the symmetric key encryption specification.
  • the information may be included by itself or may include only index information using a unique ID.
  • the device can transmit the asymmetrically encrypted subkey result to the sharer of each subkey through a public or private network.
  • the device may upload encryption data, a plurality of subkeys, and information regarding the encryption key to the IPFS network.
  • information about the encryption key may include an encryption key specification and an encryption key recovery specification.
  • the encryption key specification may include details regarding the algorithm of the encryption key.
  • the encryption key recovery specification may include details of the encryption key recovery algorithm.
  • the encryption key recovery algorithm may correspond to an algorithm related to the minimum number of subkeys required to decrypt encrypted data among a plurality of subkeys. For example, in the encryption key recovery algorithm, if the device divides the encryption key into N (N is a natural number of 2 or more) subkeys, at least M (M is a natural number of 1 or more or N or less) subkeys to decrypt the encrypted data. It may include information that is needed. In this case, the owner of the original data can decrypt the encrypted data and restore the original data with only M subkeys among the N subkeys.
  • N is a natural number of 2 or more
  • M is a natural number of 1 or more or N or less
  • the encryption key specification and encryption key recovery specification may include a unique ID for each encryption key and encryption key recovery algorithm. Additionally, the encryption key specification and encryption key recovery specification may further include a unique ID of the symmetric key that encrypted the original data when the encryption key is a symmetric key.
  • the device may encrypt a plurality of subkeys with the public key of each of the plurality of sharers and distribute them to the plurality of sharers.
  • the encryption key specification may further include a unique ID of each of the plurality of sharers who encrypted the subkey or a unique ID of the public key of each of the plurality of sharers. This unique ID can be used when any sharer who has been distributed the subkey decrypts the subkey.
  • step 1340 the device may destroy the encryption key after step 1330. This is the same as described above in FIG. 12.
  • Figure 14 is a flowchart of a decryption algorithm according to one embodiment.
  • a device may provide an algorithm of steps 1410 to 1440 for decrypting encrypted data and recovering original data.
  • the device may receive a decryption request for encrypted data from the user.
  • a request to decrypt the user's encrypted data may be a request to view the user's original data.
  • step 1410 may further include receiving the user's public key.
  • the user's public key can serve as the user's electronic signature
  • multiple sharers respond to the user's decryption request and verify that the user who sent the decryption request is the owner of the original data based on the user's public key. It can be verified.
  • each sharer can use his or her private key to decrypt the subkey encrypted with his or her public key and then re-encrypt it with the public key of the user who sent the decryption request.
  • each subkey temporarily exists in volatile memory, and each subkey moving to the network must be encrypted with the public key of the sharer who owned the subkey or the user who sent the decryption request.
  • the device may perform the above process in volatile memory or in a secure enclave that is protected by hardware.
  • the device may receive some of the plurality of subkeys from some of the plurality of sharers.
  • the device may receive some of the plurality of subkeys decrypted by some of the plurality of sharers with their respective private keys. .
  • some of the plurality of subkeys must satisfy the minimum number of subkeys condition required for decryption of encrypted data.
  • multiple sharers have information about the encryption key including the encryption key recovery algorithm, so when the device divides the encryption key into N (N is a natural number of 2 or more) subkeys, the multiple sharers can decrypt the encrypted data. For this, at least M (M is a natural number between 1 and N and below) must be transmitted to the device.
  • the device may receive some of a plurality of subkeys that some of the plurality of sharers have decrypted with their respective private keys and re-encrypted with the user's public key. For example, as described above, if the subkey distributed to multiple sharers is encrypted with the public key of each of the multiple sharers, some of the multiple sharers can decrypt the subkey they own with each private key. Before transmitting it to the device, you can re-encrypt it with the user's public key (same word, re-encryption) and transmit the re-encrypted subkey to the device.
  • each of the corresponding subkeys can be encrypted with the user's public key and become a piece of the encryption key that only the user can decrypt. Through this, even if an event occurs where the sub-key itself is exposed, the user can safely recover the original data because only he or she can decrypt the sub-key from the secret key and restore it with the encryption key.
  • the device may download information regarding the encryption data and encryption key from the IPFS network.
  • the device may recover some of the plurality of subkeys as an encryption key based on the information about the encryption key described above.
  • the encryption key recovery algorithm determines at least how many subkeys are needed among the plurality of subkeys, and the encryption key can be recovered using some subkeys corresponding to the set number. For example, if M subkeys, which are the minimum condition among N subkeys, are received encrypted with the user's public key, the M subkeys can be recovered as an encryption key based on information about the encryption key downloaded from the IPFS network. there is.
  • the user can restore the encrypted data to the original data using the recovered encryption key (symmetric key).
  • the recovered encryption key symmetric key
  • Figure 15 is a flowchart of a data encryption method according to one embodiment.
  • the device may receive a user input for selecting one of the original data and a plurality of upload buttons for the original data.
  • the plurality of upload buttons may include a first button and a second button that are form data objects on a web browser.
  • the device may determine whether to encrypt the original data based on user input.
  • the device determines to encrypt the original data based on user input selecting a first button containing a predetermined string and based on user input selecting a second button not containing the predetermined string. Therefore, you can decide not to encrypt the original data.
  • the device may upload original data or encrypted data obtained by encrypting the original data to the IPFS network, according to the above decision.
  • an IPFS network may include multiple sharers.
  • the device may obtain encrypted data by encrypting the original data with an encryption key.
  • the device may split the encryption key into multiple subkeys.
  • a device may upload encryption data, a plurality of subkeys, and information regarding the encryption key to an IPFS network.
  • the encryption key corresponds to a symmetric key
  • information about the encryption key may include an encryption key specification and an encryption key recovery specification.
  • the encryption key specification includes detailed information about the algorithm of the symmetric key
  • the encryption key recovery specification may include detailed information about the algorithm regarding the minimum number of subkeys required to decrypt the encrypted data among the plurality of subkeys. You can.
  • the device may encrypt a plurality of subkeys with the public key of each of the plurality of sharers and distribute them to the plurality of sharers.
  • the device may destroy the encryption key after step 1530.
  • the device may receive a decryption request for encrypted data from a user.
  • the device may verify that the user is the owner of the original data based on the user's public key.
  • a device may receive some of a plurality of subkeys from some of the plurality of sharers.
  • the device may receive some of a plurality of subkeys decrypted by some of the plurality of sharers with their respective secret keys.
  • the device may receive some of a plurality of subkeys in which some of the plurality of sharers encrypt each distributed subkey with the user's public key.
  • the device may download the encryption data and information about the encryption key from the IPFS network and recover some of the plurality of subkeys as the encryption key based on the information about the encryption key.
  • 16 is a block diagram of a data encryption and data management device.
  • the device 1600 may include a communication unit 1610, a processor 1620, and a DB 1630.
  • a communication unit 1610 In the device 1600 of FIG. 16, only components related to the embodiment are shown. Accordingly, those skilled in the art can understand that other general-purpose components may be included in addition to the components shown in FIG. 16.
  • the communication unit 1610 may include one or more components that enable wired/wireless communication with an external server or external device.
  • the communication unit 1610 may include at least one of a short-range communication unit (not shown), a mobile communication unit (not shown), and a broadcast receiver (not shown).
  • the communication unit 1610 may receive a user input for selecting one of the original data and a plurality of upload buttons for the original data.
  • the communication unit 1610 may upload original data or encrypted data encrypted with the original data to the IPFS network, depending on whether to encrypt.
  • the communication unit 1610 may receive original data from the user.
  • the DB 1630 is hardware that stores various data processed within the device 1600, and can store programs for processing and control of the processor 1620.
  • the DB 1630 is a random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD- It may include ROM, Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or flash memory.
  • RAM random access memory
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • CD- It may include ROM, Blu-ray or other optical disk storage, a hard disk drive (HDD), a solid state drive (SSD), or flash memory.
  • Processor 1620 controls the overall operation of device 1600.
  • the processor 1620 can generally control the input unit (not shown), display (not shown), communication unit 1610, DB 1630, etc. by executing programs stored in the DB 1630.
  • the processor 1620 can control the operation of the device 1600 by executing programs stored in the DB 1630.
  • the processor 1620 may control at least some of the operations of the data encryption device described above in FIGS. 1 to 15 and the operation of the blockchain-based data management device described above.
  • the processor 1620 includes application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, and microcontrollers. It may be implemented using at least one of micro-controllers, microprocessors, and other electrical units for performing functions.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • controllers and microcontrollers. It may be implemented using at least one of micro-controllers, microprocessors, and other electrical units for performing functions.
  • device 1600 may be a server.
  • a server may be implemented as a computer device or a plurality of computer devices that communicate over a network to provide commands, codes, files, content, services, etc.
  • the server can receive data necessary to manage data based on blockchain and manage data received from users based on the received data.
  • embodiments according to the present invention may be implemented in the form of a computer program that can be executed through various components on a computer, and such a computer program may be recorded on a computer-readable medium.
  • the media includes magnetic media such as hard disks, floppy disks, and magnetic tapes, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, and ROM.
  • RAM, flash memory, etc. may include hardware devices specifically configured to store and execute program instructions.
  • the computer program may be designed and configured specifically for the present invention, or may be known and available to those skilled in the art of computer software.
  • Examples of computer programs may include not only machine language code such as that created by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.
  • methods according to various embodiments of the present disclosure may be included and provided in a computer program product.
  • Computer program products are commodities and can be traded between sellers and buyers.
  • the computer program product may be distributed in the form of a machine-readable storage medium (e.g. compact disc read only memory (CD-ROM)) or through an application store (e.g. Play StoreTM) or between two user devices. It may be distributed in person or online (e.g., downloaded or uploaded). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.
  • a machine-readable storage medium such as the memory of a manufacturer's server, an application store's server, or a relay server.
  • Figure 17 is an example of the configuration of a blockchain-based research note management system (2010) according to an embodiment of the present invention.
  • the blockchain-based research note management system (2010) includes a user terminal (2100), a research note management server (2200), a blockchain network (2300), storage (2400), and a data server (2500). may include.
  • the explanation is centered on the electronic device (e.g., user terminal, server, etc.) as the subject of the embodiment, but the present invention is not limited thereto, and the electronic device may be interpreted as being replaced by a program or application.
  • the electronic device e.g., user terminal, server, etc.
  • the user terminal 2100 is a researcher's electronic device and may include, for example, at least one of a mobile phone, a terminal, a PDA, a laptop, a PC, a tablet, and a wearable device.
  • the user terminal 100 is a device corresponding to a client running a research note management application.
  • the user terminal 2100 can obtain research records in various formats through a research note management application.
  • Research records can take many forms, for example images, videos, photos, and text.
  • the research record may be a photograph of a written record.
  • a researcher can take a record of a handwritten note using the camera of the user terminal 2100 or a camera of another electronic device, and upload the captured photo or video (as a research record) to a research note management application.
  • the user terminal 2100 may create a transaction corresponding to the upload of the research records. Transactions can be structured data or functions. A transaction for a specific research record may include a hash value of the research record. For example, the user terminal 2100 can add a hash value as one of the transaction components through a research note management application.
  • the user terminal 2100 can upload research records to the research note management server 2200.
  • research record data e.g., image data
  • the transaction corresponding to the research record and the hash value included therein may also be transmitted to the research note management server 2200.
  • the research note management server 2200 can store a research note management application and perform various operations to manage research records uploaded through the application.
  • the research note management server 2200 transmits the hash value of the research record to the blockchain network 2300, encrypts the original research record and delivers it to the storage 2400, and transfers metadata corresponding to the research record to the data server. It can be sent to (2500). Metadata may include secondary processed data, such as optical character recognition (OCR) data for research records.
  • OCR optical character recognition
  • the original data (e.g., original image) of the research record is stored in the storage 2400, and the metadata (e.g., OCR data) obtained from the original data is stored in a separate data server (2500). It can be saved. Additionally, the processing speed and performance of the blockchain network (2300) can be improved by storing only the hash values required for authentication of research records in blocks. Meanwhile, a third party's signature and timestamping can be applied to research record data through the blockchain network 2300, and it is possible to check whether research records have been forged or altered.
  • the metadata e.g., OCR data
  • the storage 2400 may be, for example, cloud storage, and the data server 2500 may include a database of the research note management server 2200.
  • the blockchain network 2300 may be a private blockchain network, for example, a network configured through Hyperledger Fabric.
  • the blockchain-based research note management system (2010) according to the present invention can authenticate research notes through the blockchain network (2300) using private blockchain technology.
  • Figure 18 shows an example of the configuration of a blockchain network 2300 according to an embodiment of the present invention.
  • the blockchain network 2300 can be configured using Hyperledger Fabric, a private blockchain network.
  • Certification organizations can participate as orderers in the channel 2330 for one research note.
  • the number of orderers may vary depending on the policy, and the number of orderers is not limited.
  • Research institutions may consist of multiple peers.
  • the user terminal 2100 of a specific researcher may be connected to a peer of the research institution to which the researcher belongs.
  • a plurality of peers corresponding to the research institute may form an organization (2310-1, 2310-2).
  • a research institution may be composed of various organizations and peers.
  • Blockchain network 2300 may include one or more organizations 2310-1 and 2310-2. Each organization may consist of one or more peers. Although the first organization 2310-1 and the second organization 2310-2 are shown in FIG. 2, the number of organizations within the blockchain network 2300 is not limited. Additionally, the number of peers included in each organization is not limited.
  • the distributed ledger within the organization (2310-1, 2310-2) may correspond to the peer's database. Peers having the same database can communicate through a channel 2330. For example, channel 2330 may be mapped to a distributed ledger.
  • Figure 19 is an example of the signal flow of a blockchain-based research note management system according to an embodiment of the present invention.
  • research records may be uploaded from the user terminal 2100 through an application.
  • Research records may be image files, for example, photographs of handwritten notes.
  • the user terminal 2100 can create a transaction corresponding to the upload of the research record through the application.
  • the hash value of the research record may be added to the transaction.
  • Transactions corresponding to research records may be transmitted to gateway 2220 through proxy server 2210.
  • Transactions may include the signature of the author (or creator) of the research record.
  • the author's signature may be obtained through a research note management application in the user terminal 2100, and the author's signature may be stored in the storage 2400.
  • the author's signature can be added to the transaction corresponding to the research record when the research record is uploaded.
  • the user terminal 2100 may be connected to a peer 2310 of a research institution to which the user (i.e., researcher) of the user terminal 2100 belongs.
  • Peers 2310 are nodes corresponding to research institutes.
  • the gateway 2220 may request a transaction guarantee from at least some of the peers 2310.
  • the gateway 2220 may request a guarantee for the integrity of the transaction from an endorsing peer among the peers 2310 constituting the research institute.
  • the endorsing peer may be some of the peers 2310 constituting the research institute.
  • the endorsing peer can execute the transaction to verify that it completes normally. If the transaction is executed normally, the guarantee peer can output a result indicating that the transaction is normal (S103)
  • the transaction and/or the result may be delivered to the orderer 2320 in S104.
  • the vouching peer may deliver the result of the transaction along with the vouching peer's signature to the orderer 2320 through the gateway 2220.
  • the signature of a third party e.g., a research institute
  • the orderer 2320 can create a block based on the result of the transaction.
  • the orderer 2320 can order transaction results in order, define a transaction, and create a block for the transaction.
  • the orderer 2320 may distribute the generated block to peers 2310.
  • the orderer 2320 can distribute blocks to all peers 2310, including the guarantee peers described above. Because of this, peers 2310 within the blockchain network 2300 can all have the same chain.
  • the operation of distributing the block generated by the orderer 2320 to the peers 2310 may include performing timestamping on the transaction corresponding to the research record. For example, the time when the orderer 2320 creates or distributes a block can be considered the time stamping time.
  • the peer 2310 may transmit a signal that block creation has been completed to the research note management server 2200 and/or the user terminal 2100 through the gateway 2220 (S107).
  • the peer 2310 may transmit information about the generated block to the research note management server 2200 through the gateway 2220.
  • the information about the block may include identification information of the generated block (e.g., block ID) and/or timestamping information of the block.
  • the research note management server 2200 can link and store the identification information of the block corresponding to the research record, timestamping information of the block, hash value, etc. for each research record.
  • the user terminal 2100 may display identification information of the block and timestamping information of the block corresponding to the research record, based on a user input confirming the research record uploaded through the research note management application. For example, the researcher can check the detailed information of the blockchain corresponding to the research record through the research note management application on the user terminal 2100, such as block identification information, hash value, and timestamping information (e.g., authentication completion time), etc.
  • block identification information e.g., hash value
  • timestamping information e.g., authentication completion time
  • the proxy server 2210 can increase the efficiency of transaction processing between the research note management server 2200 and the gateway 2220.
  • the proxy server 2210 may perform asynchronous transaction processing.
  • the proxy server 2210 can batch process multiple transactions. Therefore, the proxy server 2210 can improve the processing speed of the blockchain-based research note management system (2010).
  • the research note management method described above with reference to FIGS. 17 to 19 may be implemented as an application.
  • the research note management application is executed on the user terminal 2110, and the research note management system 2010 described above with reference to FIGS. 17 to 19 may operate as the user executes the application.
  • the research note management method executed through the application may be implemented as a web service or app service.
  • Figures 20 and 21 are diagrams to explain an example of uploading an electronic file through a research note management application according to an embodiment of the present invention.
  • Figure 20 shows an example 2400 of a screen where a research note management application is executed. Users can upload electronic files to the research note management server (2200) through the research note management application. At this time, as described above with reference to FIGS. 17 to 19, the uploaded electronic file can be managed by blockchain technology.
  • an electronic file can correspond to any identifiable file such as text or image, and there is no limit to the file format of the electronic file.
  • the user can upload an electronic file to the research note management server 2200 by selecting the indicator 2410 displayed in one area of the screen 2400. Specifically, as the user selects the indicator 2410, at least one method for uploading an electronic file may be displayed in one area of the screen 2400.
  • a user can upload an electronic file to the management server 2200 by moving the electronic file to an area 2420 of the screen 2400 through drag and drop.
  • the user can search the path where electronic files are stored in the user terminal 2100 by selecting the indicator 2430 displayed in one area of the screen and upload the electronic files existing within the searched path to the management server 2200. there is.
  • the user can select an electronic file stored in the cloud server by selecting the indicator 2440 displayed in one area of the screen and upload the selected electronic file to the management server 2200.
  • the electronic file may be an image captured through the user terminal 2100.
  • a user can capture an image 2510 through the user terminal 2100 and upload an electronic file corresponding to the captured image to the management server 2200.
  • text or images included in the image may be identified by a method such as optical character recognition (OCR).
  • OCR optical character recognition
  • an image 2520 corresponding to the uploaded electronic file may be displayed on the screen of the user terminal 2100. Additionally, the name of the folder in which the uploaded electronic file is stored (2530) and a hashtag (2540) corresponding to the electronic file may be displayed on the screen of the user terminal 2100.
  • Figure 22 is a diagram illustrating an example of granting permission to use a research note management application to another person according to an embodiment of the present invention.
  • Figure 22 shows an example 2600 of a screen on which a research note management application is executed. Users can grant permission to use the research note management application to others. Here, the usage rights can be divided into a first right to only view the uploaded electronic file, a second right to edit the uploaded electronic file or upload another electronic file to the management server 2200, etc. However, without being limited to the examples of permissions described above, various permissions may be set to allow some or all of the functions of the research note management application.
  • the user can grant permission to others through the image 2610 displayed in one area of the screen 2600, and at this time, a link to which an electronic file related to the permission to use is uploaded is also displayed in one area of the screen. can be printed.
  • Figures 23 and 24 are diagrams to explain an example in which an electronic file uploaded to a research note management application according to an embodiment of the present invention is downloaded.
  • 23 and 24 show an example in which an electronic file uploaded to the management server 2200 is downloaded.
  • formal requirements stipulated by the state must be met.
  • the researcher's name, signature, date of creation, authentication time, etc. must be specified, and a mark certifying that the contents of the research notes have not been forged or altered must be included.
  • the research note management application can process electronic files on the management server 2200 so that the above-mentioned formal requirements can be met, and thus the downloaded research notes are recognized as research notes with public trust. It can be.
  • a cover 2700 for the electronic file may be created.
  • the cover 2700 not only contains information indicating that it is an electronic research note, but also contains the name of the research topic corresponding to the electronic file (2710) and a mark indicating that the downloaded electronic file is a research note with public trust (e.g. For example, a mark confirming the original) may be displayed together.
  • the page 2800 may display not only the content included in the electronic file, but also a mark 2810 and a page number 2820 indicating that the downloaded electronic file is a research note with public trust. Additionally, in one area 2830 of the page 2800, the name, signature, creation date, authentication time, etc. of the researcher who created the downloaded electronic file may be displayed.
  • Figure 25 is a diagram to explain an example in which electronic files uploaded through a research note management application according to an embodiment of the present invention are managed based on blockchain technology.
  • electronic files uploaded to the management server 2200 through the application are managed based on blockchain technology. Accordingly, the user can check the management status of the electronic files he or she uploaded through the application. For example, a block number 2910 and a hash value 2920 corresponding to the uploaded electronic file may be displayed on the application execution screen 2900.
  • Figure 26 is a diagram to explain an example in which a research note management application according to an embodiment of the present invention is linked with another service.
  • Figure 26 shows an example (3000) of a screen on which a research note management application is executed.
  • the research note management application can be linked with other programs (for example, Github, etc.), and accordingly, electronic files uploaded to the research note management application can be automatically uploaded to other linked programs. Additionally, electronic files uploaded to other programs linked to the research note management application may be automatically uploaded to the research note management application.
  • Figure 27 is a diagram for explaining an example of searching electronic files uploaded to a research note management application according to an embodiment of the present invention.
  • Figure 27 shows an example (3100) of a screen on which a research note management application is executed. Users can upload one or more electronic files through the research note management application and search for the electronic files they uploaded. For example, a user can search for electronic files related to the input text by entering specific text into a search window displayed in one area 3110 of the screen 3100.
  • a hashtag may be assigned to the electronic file, and content included in the electronic file may be identified. Accordingly, electronic files related to specific text entered by the user in one area 3110 may be searched and displayed on the screen 3100.
  • the above-described method can be written as a program that can be executed on a computer, and can be implemented in a general-purpose digital computer that operates the program using a computer-readable recording medium. Additionally, the data structure used in the above-described method can be recorded on a computer-readable recording medium through various means.
  • the computer-readable recording media includes storage media such as magnetic storage media (e.g., ROM, RAM, USB, floppy disk, hard disk, etc.) and optical read media (e.g., CD-ROM, DVD, etc.) do.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

La présente divulgation concerne un procédé, un appareil et un système de gestion de données basée sur une chaîne de blocs. Un mode de réalisation de la divulgation concerne le procédé de gestion de données basée sur une chaîne de blocs, comprenant les étapes consistant à : générer un premier bloc pour des données d'origine d'un utilisateur ; appliquer, aux données d'origine, une estampille temporelle de données d'origine émise par une autorité d'horodatage (TSA), de façon à générer un deuxième bloc associé à l'estampille temporelle de données d'origine ; générer un troisième bloc associé à la signature d'une tierce partie pour le premier bloc et/ou le deuxième bloc ; et enregistrer séquentiellement les premier à troisième blocs dans un registre de la chaîne de blocs d'origine.
PCT/KR2023/014206 2022-09-19 2023-09-19 Procédé, appareil et système de gestion de données sur la base d'une chaîne de blocs WO2024063519A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR10-2022-0117966 2022-09-19
KR1020220117966A KR102494825B1 (ko) 2022-09-19 2022-09-19 Ipfs를 위해 콘텐츠 id를 분배하는 방법 및 시스템
KR10-2022-0117967 2022-09-19
KR1020220117967A KR102501004B1 (ko) 2022-09-19 2022-09-19 블록체인 기반의 데이터 관리 방법 및 장치
KR10-2022-0132895 2022-10-17
KR1020220132895A KR102529277B1 (ko) 2022-10-17 2022-10-17 웹3.0을 구현하기 위한 데이터 암호화 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2024063519A1 true WO2024063519A1 (fr) 2024-03-28

Family

ID=90454954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/014206 WO2024063519A1 (fr) 2022-09-19 2023-09-19 Procédé, appareil et système de gestion de données sur la base d'une chaîne de blocs

Country Status (1)

Country Link
WO (1) WO2024063519A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170045619A (ko) * 2015-10-19 2017-04-27 삼성전자주식회사 선택적 암호화 방법 및 그를 이용한 전자 장치
KR20190075772A (ko) * 2017-12-21 2019-07-01 바스아이디 랩 재팬 컴퍼니 리미티드 블록체인을 이용한 개인정보 분리 후 조합을 통한 인증 시스템
KR102368525B1 (ko) * 2020-08-20 2022-03-02 에이아이오티홀딩스 주식회사 블록체인과 ipfs를 활용한 디지털 문서 관리 시스템 및 방법
KR20220066466A (ko) * 2020-11-16 2022-05-24 두나무 주식회사 블록체인 기반 문서 관리 방법 및 장치
KR102407699B1 (ko) * 2022-02-16 2022-06-15 주식회사 글로싸인 생체정보의 인증을 통한 전자문서 관리 서비스 제공 서버, 방법 및 프로그램
KR102501004B1 (ko) * 2022-09-19 2023-02-21 주식회사 레드윗 블록체인 기반의 데이터 관리 방법 및 장치

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170045619A (ko) * 2015-10-19 2017-04-27 삼성전자주식회사 선택적 암호화 방법 및 그를 이용한 전자 장치
KR20190075772A (ko) * 2017-12-21 2019-07-01 바스아이디 랩 재팬 컴퍼니 리미티드 블록체인을 이용한 개인정보 분리 후 조합을 통한 인증 시스템
KR102368525B1 (ko) * 2020-08-20 2022-03-02 에이아이오티홀딩스 주식회사 블록체인과 ipfs를 활용한 디지털 문서 관리 시스템 및 방법
KR20220066466A (ko) * 2020-11-16 2022-05-24 두나무 주식회사 블록체인 기반 문서 관리 방법 및 장치
KR102407699B1 (ko) * 2022-02-16 2022-06-15 주식회사 글로싸인 생체정보의 인증을 통한 전자문서 관리 서비스 제공 서버, 방법 및 프로그램
KR102501004B1 (ko) * 2022-09-19 2023-02-21 주식회사 레드윗 블록체인 기반의 데이터 관리 방법 및 장치

Similar Documents

Publication Publication Date Title
WO2020235782A1 (fr) Procédé d'authentification d'identification personnelle dans un environnement distribué
WO2015163735A1 (fr) Dispositif mobile et procédé de partage d'un contenu
WO2018086515A1 (fr) Procédé et dispositif de construction de vérification permettant une vérification hors ligne d'une étiquette d'informations de sécurité
WO2016178548A1 (fr) Procédé et appareil de fourniture de profil
WO2016108468A1 (fr) Terminal utilisateur, appareil de fourniture de services, procédé de commande de terminal utilisateur, procédé de commande d'appareil de fourniture de services, et système de recherche à base d'indexation de chiffrement
WO2011079753A1 (fr) Procédé d'authentification, système commercial d'authentification et appareil d'authentification
WO2015137745A1 (fr) Système et procédé de chiffrement de dossier dans un dispositif
WO2015061992A1 (fr) Procédé, système, et appareil de configuration de clé
WO2015163736A1 (fr) Procédés de fourniture de service de réseau social, et serveur les exécutant
WO2012112011A2 (fr) Procédé et appareil de lecture continue de contenu
WO2012165889A2 (fr) Procédé et terminal de cryptage et de signature basés sur l'id
WO2014036977A1 (fr) Système de gestion de la sécurité des données
WO2017035695A1 (fr) Procédé de transmission d'informations et dispositif mobile
WO2015061941A1 (fr) Procédé et appareil de configuration de clé
WO2020189926A1 (fr) Procédé et serveur permettant de gérer une identité d'utilisateur en utilisant un réseau à chaîne de blocs, et procédé et terminal d'authentification d'utilisateur utilisant l'identité d'utilisateur basée sur un réseau à chaîne de blocs
WO2023171887A1 (fr) Appareil et procédé d'activation d'une transaction d'image jnf de type à sceau invisible
CN107113171A (zh) 安全通信系统、方法及装置
WO2020171672A1 (fr) Procédé d'interfonctionnement entre un processus de téléchargement de faisceau et un processus de téléchargement de profil esim par un terminal ssp
WO2020197221A1 (fr) Procédé de communication et dispositif de communication
WO2021075867A1 (fr) Procédé de stockage et de récupération de clés pour système basé sur des chaînes de blocs et dispositif associé
WO2019146812A1 (fr) Système de mise à jour de véhicule et procédé de commande
WO2015005708A1 (fr) Méthode et dispositif de reproduction de contenu
WO2015194836A1 (fr) Procédé et dispositif de partage de clé
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2023106759A1 (fr) Dispositif et procédé de paiement facile hors ligne du type borne d'impression de photos hybride comprenant une lecture de code qr et une commande de médiation web du type à auto-sélection

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

Country of ref document: EP

Kind code of ref document: A1