Distributed data aggregation method and distributed data aggregation framework

Abstract

To cope with potential problems of authentication and permission by integrating SSI into distributed data aggregation.SOLUTION: A distributed data aggregation framework 100 in which a consumer 20 aggregates data provided by a data source 10 and stored in a storage 40 through an aggregator 50 includes an authority 30 that has a function of approving data provided by the data source 10, uploading the data to the storage 40, and issuing credentials as data possession proof, and a function of authorizing the consumer 20. The data source 10 has a function of acquiring and holding the credentials and a function of sending encrypted credentials to the aggregator 50. The aggregator 50 has a function of decrypting and verifying the encrypted credentials to authenticate the data source 10, verifying the data possession proof based on the credentials and the authorization of the consumer 20, and a function of decrypting the encrypted data.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a technology for sharing data while ensuring the authenticity, integrity, confidentiality, and anonymity of the data, and in particular to distributed data aggregation in which consumers aggregate data provided by data sources without the intervention of a central administrator. [Background technology]

[0002] Data aggregation is an essential process for bringing together information from multiple data sources, and it plays a key role especially in data-driven distributed systems. Typical data aggregation models employ a centralized architecture where a central aggregator manages data streams from multiple data sources through a common interface. Such centralized models generally rely on a set of trust assumptions, such as: a1: Aggregators trust data sources to guarantee the authenticity and integrity of the data. a2: Data sources trust the aggregator to ensure the correctness of access control for consumer requests. a3: Data confidentiality is maintained in all aggregation protocols. a4: The data source maintains anonymity from the consumer.

[0003] However, designing and implementing a mechanism for a data aggregation model that satisfies such trust assumptions is difficult, especially when building a zero-trust security model. Regarding a1, an audit system can be used to increase the trust of data sources, allowing the aggregator to supervise and audit the entire process from data generation to retrieval, preventing the possibility of data manipulation by the data source. However, these audit systems are not scalable for adding new data sources, and in practice may violate privacy. A2 relies on the access control mechanism provided by the aggregator and faces vulnerabilities and threats that are widely present in centralized systems, such as single-point-of-failure attacks and denial-of-service (DoS) attacks. Although A3 is theoretically possible through data encryption, there are challenges in key exchange and management, and there is a possibility of data leakage. Furthermore, A4 is likely to contradict A1 and A2, since the establishment of trust relies on two-way authentication and identity proof. Thus, centralized data aggregation faces significant security and privacy challenges, such as data authenticity, integrity, confidentiality, and anonymity.

[0004] In recent years, advances in distributed ledger technology, such as blockchain, have made it possible to achieve distributed data aggregation without a central administrator (see, for example, Non-Patent Documents 1 to 7). In distributed data aggregation, the aggregator of a centralized architecture can be decentralized and controlled by any group of nodes on the network. These nodes agree on the execution results of the aggregator through consensus mechanisms such as PoW (Proof of Work), PBFT (Practical Byzantine Fault Tolerance), and Raft. Data sources and consumers participate in data aggregation processing via reachable nodes, separate from the centralized management of the aggregator. [Prior art documents] [Non-patent literature]

[0005]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Non-Patent Document 4

[0006] However, blockchain-based systems still face challenges, especially with regard to identity management. Permissionless blockchains allow users to participate in a decentralized network as nodes or users without permission, but lack effective identity management mechanisms to authenticate and authorize data sources and consumers, which may violate a1 and a2. Permissioned blockchains, on the other hand, restrict participation through access control, but their identity management mechanisms face scalability issues and may potentially violate a4. Thus, the lack of proper identity management mechanisms in current decentralized data aggregation systems makes these systems vulnerable to spoofing attacks, manipulation of data sources, and collusion.

[0007] In recent years, a decentralized identity management mechanism has become feasible with the emergence of Self-Sovereign Identity (SSI), a new identity model that allows physical entities to manage their own identity information. SSI allows partially anonymous and fully pseudonymous authentication and authorization verification without a centralized mechanism. Physical entities register Decentralized Identifiers (DIDs) through a Verifiable Data Registry (VDR) and associate Verifiable Credentials (VCs) issued and endorsed by authorities to the DIDs. In this way, physical entities can prove their credentials to a third party by presenting the corresponding verifiable credential. The third party can verify the authenticity and authorization of the presented credential without relying on middleware.

[0008] Therefore, the present invention aims to provide an intelligent framework for integrating SSI into distributed data aggregation to address potential authentication and authorization issues. [Means for solving the problem]

[0009] According to one aspect of the present invention, there is provided a distributed data aggregation method in which a consumer aggregates data provided by a data source and stored in a storage through an aggregator, the method including a first step in which the aggregator receives an aggregation request from a consumer and requests data from the data source; a second step in which the data source requests authorization of the consumer from an authority in response to the request from the aggregator; a third step in which the authority authorizes the consumer in response to the request from the data source; a fourth step in which the data source collects its provided data from the storage, and uploads encrypted data encrypted with a symmetric key and an encryption key encrypted with the consumer's public key to the storage to obtain stored information; and a fourth step in which the data source uploads a credential issued by the authority and held therein as proof of data possession to the data source. a fifth step of sending to the aggregator encrypted credentials, the encrypted credentials having been encrypted with the consumer's private key and the data source's public key, and the encrypted stored information, the encrypted credentials having been encrypted with the consumer's public key; a sixth step of the aggregator verifying the credentials obtained by decrypting the encrypted credentials with the consumer's private key and the data source's public key to authenticate the data source and verifying data possession proof based on the credentials and authorization of the consumer by the authority; a seventh step of the aggregator fetching encrypted data and an encryption key from the storage based on the stored information obtained by decrypting the encrypted stored information with the consumer's private key; and an eighth step of the aggregator decrypting the encrypted data with a symmetric key obtained by decrypting the encryption key with the consumer's private key, converting the encrypted data into a predetermined format, and returning the data to the consumer.

[0010] According to another aspect of the present invention, there is provided a distributed data aggregation framework in which a consumer aggregates data provided from a data source and stored in a storage through an aggregator, the framework comprising an authority having a function of approving the provided data in response to a request from the data source, uploading encrypted data encrypted with a symmetric key to the storage to obtain stored information and issuing a credential as proof of data possession, and a function of authorizing the consumer in response to a request from the data source, the data source having a function of presenting its own ID to the authority to request approval of the provided data, a function of acquiring and holding the stored information and the credential from the authority, a function of requesting permission of the consumer from the authority in response to a request from the aggregator, a function of collecting its provided data from the storage, and uploading encrypted data encrypted with a symmetric key and an encryption key obtained by encrypting the symmetric key with the consumer's public key to the storage to obtain the stored information, and A distributed data aggregation framework is provided which has a function of sending to an aggregator encrypted credentials obtained by encrypting credentials issued by an authority and held by the authority as proof of data possession with the private key of the data source and the public key of the consumer, and encrypted stored information obtained by encrypting the stored information with the public key of the consumer, and the aggregator has a function of receiving an aggregation request from the consumer and requesting data from the data source, a function of verifying the credentials obtained by decrypting the encrypted credentials with the private key of the consumer and the public key of the data source, authenticating the data source, and verifying the data possession proof based on the credentials and the permission of the consumer by the authority, a function of fetching encrypted data and an encryption key from storage based on the stored information obtained by decrypting the encrypted stored information with the private key of the consumer, and a function of decrypting the encrypted data with a symmetric key obtained by decrypting the encryption key with the private key of the consumer, and returning the data converted into a specified format to the consumer. Effect of the Invention

[0011] According to the present invention, the authenticity, integrity, confidentiality, and anonymity of data are guaranteed in distributed data aggregation. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a schematic diagram of a distributed data aggregation framework according to an embodiment of the present invention. [Diagram 2] FIG. 2 illustrates an architecture of an aggregator according to an example. [Diagram 3] FIG. 11 is a sequence diagram of data persistent storage according to an example. [Figure 4] FIG. 11 is a sequence diagram of data acquisition according to an example. [Diagram 5] FIG. 11 is a sequence diagram of off-chain data acquisition according to an example. [Figure 6] FIG. 1 illustrates an example of distributed data aggregation. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, the embodiments of the present invention will be described in detail with reference to the drawings as appropriate. However, more detailed explanations than necessary may be omitted. For example, detailed explanations of already well-known matters or duplicate explanations of substantially identical configurations may be omitted. This is to avoid the following explanation becoming unnecessarily redundant and to facilitate understanding by those skilled in the art. Note that the inventor provides the accompanying drawings and the following explanation so that those skilled in the art can fully understand the present invention, and does not intend to limit the subject matter described in the claims by them. In addition, the dimensions of each member depicted in the drawings, detailed shapes of details, etc. may differ from the actual ones.

[0014] <Distributed Data Aggregation Framework> 1 is a schematic diagram of a decentralized data aggregation framework (hereinafter, for convenience, may be referred to as a degator) according to an embodiment of the present invention. The degator 100 according to this embodiment is configured by connecting a plurality of data sources 10, a plurality of consumers 20, a plurality of authorities 30, a storage 40, and a plurality of aggregators 50 to each other via electric communication lines such as wired communication or wireless communication to form a network.

[0015] The data source 10 is a physical entity that provides data, and may be an individual, an organization, a program, or a device. The data may be any digital information, such as measurements from various sensors, information input by a person through a user interface, or the results of calculations by a program. The consumer 20 is a physical entity that aggregates data provided by the data source 10 in order to use and process it, and may be an individual, an organization, a device, a server, a data center, or a program. The authority 30 is a physical entity that approves the data source 10 and the consumer 20, and may be an organization, an institution, a server, or a program. It should be understood that for entities that cannot be directly connected to a telecommunication line, such as individuals or organizations, agents such as programs or devices participate in the delegator 100.

[0016] The storage 40 is a distributed ledger consisting of multiple data nodes scattered in a cloud environment as shown in the figure. All data provided by the data source 10 is persistently stored in the storage 40. Meanwhile, the consumer 20 acquires the required data from the data source 10 via the storage 40. Thus, the degator 100 has two aspects: data persistence and data acquisition.

[0017] The degator 100 utilizes an SSI-based identity management mechanism, and behavioral patterns are shared between the degator 100 and each role of the SSI. The data source 10 is similar to a holder in the SSI and holds verifiable credentials to demonstrate the ownership and integrity of the data it provides. The authority 30 plays the role of an issuer and authorizes the data source 10 by issuing verifiable credentials. The consumer 20, as a verifier, can verify the authenticity and integrity of the data using the verifiable credentials presented by the data source 10.

[0018] The aggregator 50 is a hybrid application that operates as a distributed application, part of which is deployed on the blockchain, as described below. The aggregator 50 acts as a bridge for authentication, authorization, and data storage, collection, and processing. Consumers 20 obtain data on demand through the aggregator 50. Data sources 10 provide data and meta-information to the aggregator 50. Furthermore, authorities 30 endorse the data sources 10 through the aggregator 50.

[0019] The aggregator 50 also combines both aspects of data persistence and data retrieval: data persistence is relative to the data source 10 and authority 30 perspective, and data retrieval is relative to the consumer 20 perspective.

[0020] From the aspect of data persistence storage, emphasis is placed on streamlining data management of the data sources 10. To fully realize decentralization in data aggregation, the degator 100 adopts a distributed data storage approach, which will be described later. This allows the data sources 10 to manage data in a distributed network, even if the data is distributed across multiple nodes that the data sources 10 cannot control. The degator 100 works by associating each data source 10 with a single address instead of multiple data storage locations, so that the data sources 10 can obtain complete data by obtaining data partitions from a group of storage nodes. This is different from data retrieval, where a consumer 20 requests to retrieve data managed by multiple data sources 10. Furthermore, the degator 100 has the flexibility to be compatible with customized storage solutions, as will be described later.

[0021] From the data ingestion side, it becomes easy to collect and aggregate data on demand from multiple data sources 10 for consumers 20. We formulate a complete distributed data ingestion protocol, described below, in which an aggregator 50 interacts with the distributed ledger to establish communication with authenticated data sources 10, standardize data based on specifications, and consolidate the aggregated data. We also describe an off-chain data ingestion protocol, described below, that minimizes interactions with the distributed ledger for efficiency and cost-effectiveness.

[0022] We first formalize some basic concepts and clarify terminology for the following discussion.

[0023] (Definition 1) Distributed ledger A distributed ledger L consists of a finite set of nodes N (|N|>1). For a transaction x∈X, x is accepted at node n∈N if F(x,n)=True, where F:X×N→{True,False}, and X is the set of submitted transactions. L employs a consensus mechanism that determines a threshold δ for the network to reach consensus on finalizing transaction x, denoted as |{n|F(x,n)=T,n∈N}|>δ|N|. We denote the set of finalized transactions by X^. We also denote the transaction property access operation by [*], where * is any valid property name.

[0024] As an example of the threshold δ, if L adopts PBFT as the consensus mechanism, δ = 2 / 3. If the consensus mechanism is PoW, δ = 1 / 2.

[0025] (Definition 2) Virtual Entity The delegator 100 includes three types of entities: authorities 30, consumers 20, and data sources 10. Let O, C, and S be non-empty sets of authorities 30, consumers 20, and data sources 10, respectively, where |S|≧|O|. For a data source s (∀s∈S), s is endorsed by an authority A(s), where A:S→O. An authority o∈O is a data source A * (o) is approved. Here, A * :O→Pow(S). The set E=O∪C∪S is a complete set of virtual entities. In the following description, the term "virtual" will be omitted.

[0026] (Definition 3) Keys and encryption Any entity and aggregator 50 can generate a symmetric key κ. For an entity e (∀e∈E), e has an identifier ι e Asymmetric key pair (pk e ,sk e ) and generate a unique wallet address W(pk e ) can be obtained by using the signature function Ss is an object obj∈{0,1} * and the private key sk as input, and s Let (obj,sk) be the output. Signature verification function S v is the signature S s The input is (obj,sk) and the public key pk (or key identifier), and the output is obj. e is an object obj∈{0,1} * and the symmetric key κ (or asymmetric key ι) as input, and the ciphertext ε e (obj, κ) (or ε e The output is (obj,ι). The decoding function ε d is the ciphertext ε e (obj, κ) (or ε e The inputs are (obj, ι) and the symmetric key κ (or ι'), and the output is obj.

[0027] (Definition 4) Decentralized Identifier For an entity e (∀e∈E), e has a unique DID, and the DID is a DID document I e ∈I:α did →η did where α did and η did are the properties and property values ​​of a DID document. For convenience, we denote the resolve function R(e)(a) as ea, where R:E→I ∪ {} (the empty set). For the following explanation, α did ={id, auth, assert}. The meaning of each property is as follows: id: The DID of the DID object in the context auth: A key identifier that references the asymmetric key pair that authenticates the DID subject in the context. assert: a key identifier referencing an asymmetric key pair representing a claim made by a DID subject in a context

[0028] (Definition 5) Verifiable Credentials We denote a verifiable credential (VC) by ν∈V, where ν:α vc →ηvc and α vc and η vc are the properties and property values ​​of a VC document. For an entity e (∀e∈E), e has a VC set {ν|ν(credentialSubject)[id]=e.id}, where the operation [*] accesses the values ​​of subproperties. In this document, we define the range of a VC property as α vc = {id, issuer, credentialSubject, proof}, where credentialSubject:=〈id, claim〉, proof:=〈key, value〉. The meaning of each property is as follows: id: an identifier that uniquely references the VC in the context issuer: The DID of the issuer that issues the VC in the context credentialSubject[id]: The DID of the subject related to the VC's claim in the context credentialSubject[claim]: an object that contains statements about the subject of the VC in the context. proof[key]: The key used to sign the VC in the context proof[value]: Signature of the VC in the context (Definition 6) Verifiable Credential Proof For a complete-state verifiable credential ν ∈ V issued by an authority o ∈ O, its property proof has proof[key] = o.assert and proof[value] = S s (ν△proof,sk o assert ) is assigned, where △:V×α vc →V ￣ is an operation that removes a property from a VC.

[0029] Aggregator 2 is a diagram showing the architecture of an example of an aggregator 50. The aggregator 50 includes a controller 51, a connector 52, an authenticator 53, a processor 54, a registry 55, and a mediator 56. The "entities" in the diagram correspond to the data source 10, the consumer 20, and the authority 30. These entities can interact with the controller 51 and the registry 55 to perform the main functions of the degator 100, such as data acquisition, data persistence, and DID management.

[0030] Among the above components, the controller 51, the connector 52, the authenticator 53, and the processor 54 constitute the aggregator client. The aggregator client is a comprehensive system that is responsible for the logic of data persistence and data retrieval through the mediator 56 that interacts with the distributed ledger (storage 40). The aggregator client provides common functionality to all entities, independent of a specific context. Thus, each entity may have its own local instance of the aggregator client. Meanwhile, the registry 55 and the mediator 56 are distributed components deployed on the distributed ledger. In theory, the distributed ledger can provide infinite replicas of these to entities. That is, an infinite number of replicas of the aggregator 50 operate in the same way in the network.

[0031] The authority 30 approves the data provided by the data source 10 through the controller 51. The controller 51 performs the approval process through a remote procedure call (RPC) on the mediator 56. In the approval process, the mediator 56 adds a transaction that records the verifiable credentials issued to the data source 10. The authority 30 can also interact with the controller 51 to manage the approval process. Thus, the controller 51 mediates the communication between the data source 10 and the authority 30.

[0032] The data source 10 requests the controller 51 to participate in data approval and data acquisition. With the permission of the authority 30, the data source 10 provides data to the connector 52, not directly to the consumer 20. The connector 52 collects and decodes data from multiple data sources and passes it to the processor 54. The processor 54 performs data processing such as data conversion, fusion, and optimization, and passes the processed data to the consumer 20.

[0033] The Consumers 20 interact with the Controller 51 to request data retrieval. The Controller 51 communicates with the Data Sources 10 in both active and passive ways, exchanging information about the data retrieval process (e.g., data storage locations) and invoking RPCs to read and write transactions in the distributed ledger via the Mediator 56. The Controller 51 also notifies the Connector 52 when the data retrieval is ready. The Connector 52 builds connections with the data storage locations provided by the Controller 51, collects data in parallel with the assistance of the Authenticator 53, and validates the collected data. Finally, the Processor 54 processes the data according to the provided specifications and presents it to the Consumers 20.

[0034] Registry55 is a smart contract deployed on a distributed ledger that manages the propagation, update, deletion and resolution of DIDs for all virtual entities.

[0035] (DID propagation) Each entity has a DID that is propagated for public viewing. The Registry55 provides a propagation interface function (usually an Application Binary Interface (ABI)) to enable the publication of such DIDs. Invoking the propagation function propagates a transaction x:τ to a block in the distributed ledger. p ∈X^ is added. τ pA transaction of type α in the context of the calling entity did Includes evaluation of.

[0036] (DID update) Non-identifier properties such as auth and assert can be updated by calling the Update function of the registry 55. The Update function writes an update transaction x:τ to the distributed ledger. u ∈X^ is newly generated. τ u The transaction holds the DID in x[did] and the associated transaction property α did \id. Deprecated properties are assigned the empty set. Thus, the resolve function R can resolve a DID to its latest document by parsing the latest undeleted transaction.

[0037] (Deletion of DID) An entity e can delete its own propagated DID by invoking the Deletion function of the registry 55. A new deletion transaction x:τ d is determined after it is called. d For a transaction x, x[did] = e.id ∧ x[deleted] = T.

[0038] <<Permanent data storage>> The degator 100 adopts a distributed data storage approach to allow data owners to manage data in a distributed manner. In particular, the degator 100 achieves independence of persistent storage and processing by relying on storage information provided by the data source 10, rather than directly accessing the actual data storage location.

[0039] (Data Specifications) The data source 10 is required to generate a semi-structured specification and an adapter for the data and include the specification in the data. For convenience, the term data will be used to refer to the data and its specification. A data specification is semi-structured data that defines the fields and types within the data. For example, a JSON data specification for personal data can be {"firstName":"string", "lastName":"string", "age":"number"}. It is also possible to create complex data specifications such as {"Name"} using nested structures, e.g. {"firstName":"string", "lastName":"string"}, "Person":{"name":"Name", "age":"number"}}.

[0040] (Data Approval) A data source s provides data d∈{0,1} * For each s, d can be approved by an authority o∈O. If o approves d, then o issues a verifiable credential ν to s as a proof-of-possession. The issuance of ν is facilitated by the aggregator client controller, following the definitions outlined in Definition 5 and Definition 6.

[0041] (Distributed Data Storage) According to the distributed storage approach, data is partitioned and distributed across repositories provided by incentivized third parties to participate in a consensus mechanism. The repositories are encapsulated in transactions that are recorded on a distributed ledger. Data sources can collect stored data by reassembling data partitions collected from parsed repositories. Note that data sources may encrypt data partitions before uploading them to repositories to protect privacy.

[0042] The distributed storage system has a layered architecture consisting of three layers: a partition layer, a mapping layer, and a chain layer.

[0043] The partition layer implements a data partitioning and assembly algorithm. The partitioning algorithm takes data d and a dispersion γ∈[0,1] as input, and partitions d into an ordered set D={d0,...,d i}, where i=floor(1 / γ) for γ≠0. Otherwise, d is partitioned into the set {d0}, where d0=d.

[0044] Mapping layers are a set of available storage locations L ~ Given an ordered set D, the mapping layer maps each d∈D to a storage location l∈L based on business factors such as availability, reputation, and cost. ~ After creating the ordered location set L corresponding to D, assign all d i For ∈D, d i Save location i ∈L. Similarly, the mapping layer fetches data partitions from a given L and outputs the constructed set of data partitions.

[0045] The chain layer receives a set of storage locations from the mapping layer and creates a transaction x:τ l ∈X^. The chain layer also encapsulates transactions x:τ l Given ∈X^, parse x into a set of caches, which the chain layer can encrypt with a ciphertext to preserve the privacy of the caches.

[0046] 3 is a sequence diagram of an example of data persistence storage. The data persistence storage protocol according to an example is as follows. 1) A data source identifies itself to an authority, provides data, and requests authorization. 2) The authority approves data in response to a request from a data source and encrypts the data with a symmetric key κ. Furthermore, to optimize encryption performance, the authority ties the symmetric key κ to a public key pk s Encrypt with. 3) The authority stores the encrypted data and the encrypted symmetric key in the distributed ledger and receives storage information from the distributed ledger indicating where the data is stored. 4) The authority interacts with the aggregator to issue verifiable credentials that prove that the data source is the data owner. 5) The authority sends stored information and verifiable credentials to the data source, which receives and retains them.

[0047] <Data Acquisition> FIG. 4 is a sequence diagram of data acquisition according to an example. As a premise, let C and S be a consumer group and a data source group, respectively. A consumer c∈C with DID c.id aggregates data from a data source group S'⊆S (where |S'|>1) according to a data specification Ψ. A data source s (∀s∈S') has a verifiable credential ν s Assume that the data source is accepted by authority A(s). For simplicity, Fig. 4 shows the protocol executed by one data source, but other data sources follow the same protocol. An example data acquisition protocol is as follows:

[0048] 1) Consumer c receives a request from aggregator A c , and issues an aggregation request including S' and Ψ to the controller of . 2) Aggregator A c The controller of S issues an RPC to the mediator to collect transactions x:τ such that x[srcIds]={s.id|s∈S'}. c Determine that ∈X̂. 3) A data source s (∀s∈S′) requests an authority o = A(s) to admit consumer c if and only if s.id∈x[srcIds] for x:τc∈X̂. 4) An authority o validates a request from a data source s by checking that there exists a x:τc∈X̂ such that s.id∈x[srcIds]. 5) If authority o rejects the request from data source s, the protocol ends, otherwise it proceeds to the next step. 6) Authority o communicates with aggregator A o , and create an approval transaction x:τ such that x[s]=s.id and x[c]=c.id. e Determine that ∈X̂. 7) A data source s allocates local space to collect data d from the distributed ledger, decrypts it if it is encrypted, encrypts it with a symmetric key κ, and shares the symmetric key κ with a public key pk c auth Encrypt with. 8) If the data source s is ε e (d, κ) and ε e (κ,pk c auth ) to the distributed ledger to obtain the stored information m. 9) A data source s is aggregator A. s Interact with the controller and set x[vc]=ε e (ε e (ν s ,sk s auth ),pk c auth ) and x[storage]=ε e (m,pk c auth ) for a stored transaction x:τ s Determine that ∈X̂. 10) Aggregator A c The connector of {x|x:τ s ∈X^} and derive the private key sk c auth Decoded ε e(ν s ,sk s auth ) to the authenticator. 11) Aggregator A c The authenticator of ε d (ε e (ν s ,sk s auth ),pk s auth )(credentialSubject)Authenticates a data source s by verifying that [id]=s.id, verifies data ownership according to Lemma 1, and finds x:τ such that x[s]=s.id ∧ x[c]=c.id. e Verify approval by authority o by checking the existence of ∈X^. 12) If aggregator A c If the authenticator of fails to either authenticate the data source s or verify the ownership of the data, the protocol ends, otherwise it proceeds to the next step. 13) Aggregator A c The connector of ε d (x[storage],sk c auth ) based on the decoded m e (d, κ) and ε e (κ,pk c auth ) to fetch the 14) Aggregator A c The connector of ε d (ε e (d,κ),ε d (ε e (κ,pk c auth ),sk c auth )) passes the decrypted data to the processor. 15) Aggregator A c The processor in transforms d according to Ψ and returns the processed data to the consumer c.

[0049] The above data retrieval protocol assumes the use of a distributed ledger, but in some cases, the use of a distributed ledger may not be desirable due to concerns about efficiency and cost. In such cases, a self-managed storage managed by a specific administrator can be used instead of a distributed ledger. Such an off-chain data retrieval protocol is described below. FIG. 5 is a sequence diagram of an example of off-chain data retrieval.

[0050] 1) Consumer c receives a request from aggregator A c Then, it issues an aggregation request including S', Ψ, and a random number r to the controller of 2) Aggregator A c The controller of notifies the data source s∈S' of r and opens port z to the connector. 3) A data source s (∀s∈S') sends a request to an authority o=A(s) e (r,sk s auth ) to request that consumer c be granted permission. 4) If authority o rejects the request from data source s, the protocol ends, otherwise it proceeds to the next step. 5) Authority o assigns Ω=ε to data source s e (ε e (r,sk s auth ),sk o auth ). 6) A data source s allocates local space and collects data d from a data center (storage), decrypts it if it is encrypted, and encrypts the data with a symmetric key κ and shares the symmetric key κ with a public key pk c auth Encrypt with. 7) If the data source s is ε e (d, κ) and ε e (κ,pk c auth ) to the data center (storage) to obtain stored information m. 8) If the data source s is ε e (εe (ν s ,sk s auth ),pk c auth ), ε e (m,pk c auth ), and Ω to aggregator A c Send to port z of connector. 9) Aggregator A c The connector of the private key sk c auth Decoded ε e (ν s ,sk s auth ) and Ω to the authenticator. 10) Aggregator A c The authenticator of ν s Authenticate the data source s by verifying that (credentialSubject)[id]=s.id, verify the data ownership according to Lemma 1, and ε d (ε d (Ω,pk νs(issuer) auth ),pk s auth ) to verify the approval of authority o. Here, s =ε d (ε e (ν s ,sk s auth ),pk s auth ). 11) If aggregator A c If none of the authenticators are successful in all validations, the protocol ends, otherwise it moves to the next step. 12) Aggregator A c The connector of ε d (x[storage],sk c auth ) based on the decoded m e (d, κ) and ε e (κ,pk c auth ) to fetch the 13) Aggregator A c The connector of ε d (ε e (d,κ),ε d (ε e (κ,pk c auth ),sk c auth )) passes the decrypted data to the processor. 14) Aggregator A c The processor in transforms d according to Ψ and returns the processed data to the consumer c.

[0051] <Security> Next, we will explain the security of the decoder 100 by presenting a lemma. Note that detailed proofs of each item will be omitted.

[0052] (Lemma 1) Completeness of ownership A data source s ∈ S claims to be the owner of some data d if it can demonstrate the following about a verifiable credential issued by an authority o ∈ O: ·ν(credentialSubject)[id]=s.id ·ν(credentialSubject)[claim]=Η(d) ·ν△proof=S v (ν(proof)[value],ν(proof)[key]) Here, H:{0,1} * →{0,1} l is a hash function of fixed length l.

[0053] (Lemma 2) Resolvability of DIDs When the DID of an entity e∈E is propagated, R(e) is always I if δ<|{n|F(x,n)=T,n∈N}| / |N| is satisfied in the distributed ledger L. e Or evaluates to the empty set.

[0054] Lemma 1 and 2 lead to the following security properties for the decoder 100:

[0055] (Characteristic 1) Authenticity of data Data d provided by a data source s ∈ S is endorsed by an authority o and is authentic to a consumer c ∈ C if the data source s ∈ S presents a verifiable credential ν that satisfies the following condition: ·ν(credentialSubject)[id]=R(s)(id) ·ν(credentialSubject)[claim]=Η(d) ·ν(proof)[key]=R(o)(assert) ·ν△proof=S v (ν(proof)[value],ν(proof)[key]) ·δ<|{n|F(x,n)=T,n∈N}| / |N| ∃x:τ e ∈X^,x[s]=s.id∧x[c]=c.id

[0056] (Characteristic 2) Data Integrity In a data acquisition process in which a consumer c∈C requests data d that is proven to be owned by a data source s∈S by presenting a verifiable credential ν, if d' is the data decrypted by the connector, then it can be proven that d'=d when δ<|{n|F(x,n)=T,n∈N}| / |N|.

[0057] (Characteristic 3) Accuracy of access control A connector can disclose data d to a consumer c ∈ C that requests data d that is proven to be owned by a data source s ∈ S if and only if: ∃x c :τ c ∈X^,x c [s]=s.id∧x c [c]=c.id ∃x s :τ s ∈X^,x s [vc]=ε e (ε e (ν s ,sk sauth ),pk c auth )∧x s [storage]=ε e (m,pk c auth ) Here, m is the storage information for the data d.

[0058] (Characteristic 4) Data confidentiality Data d that is proven to be in the possession of a data source s ∈ O through a verifiable credential issued by an authority o ∈ O can only be disclosed to: Data sources An authority o that requests data d from a data source s in order to issue a verifiable credential A connector that works for a consumer c∈C'⊆C (where property 3 holds for ∀c∈C')

[0059] (Characteristic 5) Anonymity The consumers C cannot proactively reveal the physical identities of the data sources S.

[0060] Effect According to the degator 100, the four assumptions a1 to a4 regarding reliability in the centralized model described above can be resolved.

[0061] (Resolution of a1) The introduction of the authority 30, which is an improved version of the issuer concept in SSI, eliminates a1. The authority 30 acts as a trusted entity for the consumer 20 by endorsing the data source 10. The guarantees provided by properties 1 and 2 ensure that a malicious entity cannot deceive the delegator 100 by falsely claiming data ownership or by forging data. Data ownership is always verified through verifiable credentials that are resistant to tampering. Note that the data source 10 can also endorse the data, in which case a1 applies.

[0062] (Resolution of a2) Problem a2 is eliminated by adopting an SSI-based identity management mechanism that allows data sources 10 to own and control their data. This mechanism allows data sources 10 to have ownership and control over their data. As described in the data retrieval protocol, data sources 10 and authorities 30 mutually grant data access rights to consumers 20 and enforce access control to prevent data misuse. Property 3 also ensures the accuracy of access control.

[0063] (Resolution of a3) Prioritizing data privacy by encrypting all sensitive information in communication in the aggregation protocol eliminates a3. The data being aggregated remains encrypted throughout the aggregation process. Data can only be disclosed by the respective data sources 10 prior to the aggregation protocol. Properties 4 and 3 also make data disclosure more limited. For example, in certain scenarios, such as scientific experiments, an authority 30 can obtain permission to disclose data provided by a data source 10 (e.g., an experimental subject) for research purposes. Thus, a3 is mitigated by considering cryptographic correctness as an additional assumption.

[0064] (A4 elimination) The data source 10 and the consumer 20 are distributed in a decentralized network, and only their DIDs are propagated to the public, eliminating a4. The authority 30 can know the physical identity of the data source 10 for the authorization process, and the data source 10 can reveal the physical identity of the consumer 20 for the permission process. However, the consumer 20 cannot proactively disclose the physical identity of the data source 10 based on property 5. Also, there is no direct mechanism for the degator 100 for an unrelated party to reveal the physical identity of an individual.

[0065] Moreover, the decentralized architecture of the degator 100 ensures high availability, especially in the on-chain acquisition protocol of Fig. 4. Although it is technically possible for an attacker to exploit the exposed physical network address to disrupt the normal functioning of the data source 10, due to the a4 lift, it would require significant effort to reveal the physical identity of the data source 10. Moreover, a physical entity can easily associate a new data source 10 that it owns with a new physical network address, thwarting malicious tracking attempts.

[0066] Example Next, an embodiment of the degator 100 will be introduced. Figure 6 is a diagram showing an embodiment of distributed data aggregation. In this embodiment, the degator 100 is applied to data aggregation in the field of brain science.

[0067] Neuroscience data, including electroencephalogram (EEG), magnetic resonance imaging (MRI), and magnetoencephalography (MEG), are typically under the control of the research institute that conducts the neuroscience experiment. In addition to neuroscience data, near-infrared spectroscopy (NIRS), electrocardiogram, physiological index data such as pulse, blood pressure, and respiration, event information such as event type, and audiovisual data such as video data are also under the control of the research institute. Although research institutes and experimenters generally have access to experimental data according to agreements, aggregating this data and sharing it with third parties poses challenges from technical and social perspectives. For example, if a research institute wants to share data collected with other research institutes that were not included in the prior agreement with the subjects, there are two options. The first option is to update contracts with all subjects to link their physical IDs to the data collected in the original experiment. This method raises concerns regarding data privacy and may violate research ethics. The second option is to share the data without explicit permission, which may result in legal issues and lawsuits.

[0068] However, there is a growing demand to aggregate and share such data for a variety of reasons, including maximizing the contribution of subjects and experimenters, improving the reproducibility of brain science research, providing a platform for testing new methods, and reducing the cost of new analyses, making the development of efficient data aggregation systems a top priority.

[0069] By applying the Degator 100 to data aggregation in the field of neuroscience, which has such challenges, subjects can manage their own data even after the experiment is over. As a result, third parties can aggregate data by directly requesting it from the subjects. Furthermore, subjects can have the autonomy to proactively share data with third parties that request it, after obtaining permission and authorization from the research institution.

[0070] In FIG. 6, a subject is an experimental participant who provides data for brain science research. An experimenter is an entity that collects data from subjects, such as a research institute or a company. A requester is a third party that requests data aggregation to obtain data. The subject, requester, and experimenter correspond to the data source 10, consumer 20, and authority 30 in the degator 100, respectively.

[0071] Authenticated subjects provide data securely through devices approved by the experimenter. The data provided by the subjects is persistently stored in a data center. The data center corresponds to the storage 40 in the degator 100. The experimenter interacts with the aggregator 50 to grant the requester permission to obtain the data.

[0072] Data persistence and data acquisition in the degator 100 are realized through three phases: an initialization phase, an experiment phase, and an authorization phase. In the initialization phase, each entity (subject, experimenter, and requester) interacts with the registry 55 in the aggregator 50 to generate a DID and propagate the DID. In the experiment phase, the data persistence protocol in Fig. 3 is implemented. In the authorization phase, the data acquisition protocol in Fig. 4 or Fig. 5 is implemented.

[0073] In the above-mentioned distributed data aggregation, an incentive mechanism may be introduced in which the requester pays the subjects and experimenters for providing and collecting data. The compensation here may include not only monetary compensation, but also social compensation such as the person publishing the fact that they downloaded the data, rating, supporting, and posting "likes" on SNS (Social Networking Service), and interdisciplinary value counted as the number of citations of the person's academic paper. In other words, when the requester obtains data from the subject through the data center, the requester pays at least one of the subject and the experimenter, and preferably both. For example, in step 13 in the example of Figure 4 and in step 12 in the example of Figure 5, when the connector of the aggregator fetches the encrypted data provided by the data source and stored in the data center, it issues an RPC to the mediator and confirms the transaction to pay the data source and the authority. This will enable subjects who provide data and experimenters who collect data to receive monetary compensation, social compensation, or interdisciplinary value, or a combination of these, which is expected to increase motivation to provide and collect data and encourage data aggregation.

[0074] As described above, the embodiment has been described as an example of the technology of the present invention. For this purpose, the attached drawings and detailed description have been provided. Therefore, among the components described in the attached drawings and detailed description, not only components essential for solving the problem but also components that are not essential for solving the problem in order to illustrate the above technology may be included. Therefore, just because those non-essential components are described in the attached drawings or detailed description, it should not be immediately recognized that those non-essential components are essential. In addition, since the above-mentioned embodiment is intended to illustrate the technology of the present invention, various modifications, substitutions, additions, omissions, etc. may be made within the scope of the claims or their equivalents. [Explanation of symbols]

[0075] 100 Degator (Distributed Data Aggregation Framework) 10 Data Sources 20 Consumer 30 Authority 40 Storage 50 Aggregators

Claims

1. A distributed data aggregation method in which a consumer aggregates data provided by a data source and stored in a storage through an aggregator, comprising: A first step in which an aggregator receives an aggregation request from a consumer and requests data from a data source; a second step in which the data source requests authorization of the consumer from the authority in response to a request from the aggregator; a third step in which the authority authorizes the consumer in response to a request from the data source; A fourth step in which the data source collects its own provided data from the storage, encrypts the encrypted data with the symmetric key, and uploads the encrypted data and the encryption key obtained by encrypting the symmetric key with the consumer's public key to the storage to obtain stored information; A fifth step in which the data source sends to the aggregator the encrypted credentials obtained by encrypting the credentials issued by the authority as proof of data possession and held by the data source with the private key of the data source and the public key of the consumer, and encrypted stored information obtained by encrypting the stored information with the public key of the consumer; a sixth step in which the aggregator decrypts the encrypted credential with the consumer's private key and the data source's public key, verifies the credential, and authenticates the data source and verifies proof of possession of the data based on the credential and authorization of the consumer by the authority; a seventh step of the aggregator fetching the encrypted data and the encryption key from the storage based on the stored information obtained by decrypting the encrypted stored information with the private key of the consumer; an eighth step in which the aggregator decrypts the encrypted data with a symmetric key obtained by decrypting the encryption key with the consumer's private key, converts the data into a predetermined format, and returns the data to the consumer; A distributed data aggregation method comprising:

2. a data source presenting its identity to an authority to request approval of the data it has provided; The authority approves the data provided in response to the request from the data source, encrypts the data with a symmetric key, uploads the encrypted data to the storage, and obtains the stored information, and issues a credential as proof of data ownership; The data source obtaining and maintaining stored information and credentials from the authority. The distributed data aggregation method according to claim 1 .

3. In the seventh step, the aggregator pays a fee to at least one of the data source from which the encrypted data is provided and the authority that issues a credential to the data source. The distributed data aggregation method according to claim 1 .

4. The storage is a distributed storage based on distributed ledger technology, In the first step, the aggregator finalizes a collection transaction including a distributed ID of a data source from which data is requested; In the third step, the authority aggregator confirms an authorization transaction including distributed ID correspondence information between the consumer requesting the data and the data source requesting the data; In the fifth step, the aggregator of the data sources finalizes the storage transaction including the encrypted credentials and the encrypted stored information.

4. The distributed data aggregation method according to claim 1, wherein the distributed data aggregation method comprises:

5. The storage is a self-managed storage managed by a specific administrator; In the first step, the aggregator receives a random number from the consumer and notifies the data source of the random number; In the second step, the data source requests the authority to authorize the consumer with an encrypted random number obtained by encrypting the notified random number with a private key of the data source; In the third step, the authority notifies the data source of the double-encrypted random number obtained by encrypting the encrypted random number with the private key of the authority; In the fifth step, the data source sends the double encrypted random number to the aggregator; In the sixth step, the aggregator verifies the authorization of the consumer by the authority by checking the double encrypted random number decrypted with the public key of the data source and the public key of the authority; 4. The distributed data aggregation method according to claim 1, wherein the distributed data aggregation method comprises:

6. A distributed data aggregation framework in which a consumer aggregates data provided by a data source and stored in a storage through an aggregator, an authority having a function of approving data provided in response to a request from a data source, uploading the encrypted data encrypted with a symmetric key to a storage to obtain stored information, and issuing a credential as proof of data ownership, and a function of authorizing a consumer in response to a request from the data source; a function of the data source presenting its own ID to the authority to request approval of the data it has provided, a function of acquiring and retaining stored information and credentials from the authority, a function of requesting permission from the consumer from the authority in response to a request from the aggregator, a function of collecting its own provided data from the storage, and uploading the encrypted data encrypted with a symmetric key and the encryption key obtained by encrypting the symmetric key with the consumer's public key to the storage to acquire the stored information, and a function of sending to the aggregator the encrypted credentials obtained by encrypting the credentials issued by the authority and held by the data source with the data source's private key and the consumer's public key as proof of data possession, and the encrypted stored information obtained by encrypting the stored information with the consumer's public key; the aggregator has a function of receiving an aggregation request from a consumer and requesting data from a data source, a function of verifying the credentials obtained by decrypting an encrypted credential with the consumer's private key and the data source's public key to authenticate the data source and also a function of verifying data possession proof based on the credentials and the consumer's permission by the authority, a function of fetching encrypted data and an encryption key from a storage based on stored information obtained by decrypting the encrypted stored information with the consumer's private key, and a function of decrypting the encrypted data with a symmetric key obtained by decrypting the encryption key with the consumer's private key, and returning the data converted into a predetermined format to the consumer; A distributed data aggregation framework comprising:

Images