Overview

Function

• Trusted data exchange is implemented based on DID. Users who participate in data exchange must have DIDs. For details, see Distributed Identity (OBT).
• Trusted data exchange involves two main data structures: data sets and data orders. Data sets contain data description and access control information (attributed-based encryption policies). Data orders contain data application and review information.
• Trusted data exchange supports three modes: application-authorization, proactive sharing, and fine-grained access control, as described in Exchange Modes.
  

  You can choose from multiple storage services to store the encrypted data to be exchanged. The one calling the API is responsible for storing ciphertexts to publicly accessible storage devices.

Roles

Trusted data exchange involves two roles: data owner and data applicant. Each user can be both an owner and an applicant.

Exchange Modes

• Application-authorization, which is illustrated in Figure 1.
  • The data owner calls the API used to release a data set to encrypt plaintext user data and register and release data description information.
  • The data applicant calls the API used to apply for a data set to invoke a chaincode to trigger the application-authorization process.
  • The data owner decides whether to authorize or reject the application based on the application information and the applicant's DID and VC information.
  Figure 1 Application-authorization
  
• Proactive sharing, which is illustrated in Figure 2.

  The API used to proactively sharing data sets is a combination of the APIs used to release and authorize data sets. The data owner releases a dataset to the blockchain and authorizes an applicant to decrypt the dataset. The authorized applicant can then directly decrypt the dataset. Other users can obtain the data description information by calling the APIs used to query a specific dataset and the dataset list, and then obtain the data decryption permission through the application-authorization process.

  For details about the APIs, see "Data Set Management" and "Data Order Management".

  Figure 2 Proactive sharing
  
• Fine-grained access control, which is illustrated in Figure 3.
  

  Attribute-based encryption (ABE) achieves fine-grained, attribute-level access control for data exchange. Each data set is configured with an appropriate, owner-defined sharing policy. Data applicants with sufficient attributes are allowed to access the ciphertext.

  Fine-grained access control is implemented through ciphertext-policy ABE (CP-ABE). The policy is embedded in the ciphertext and the attribute is embedded in the user key.

  • Each data owner initializes its own master public key and private key only once.
  • When a data applicant needs to use some data, the applicant applies to the owner of the data for a user key. If attributes do not change, the applicant only applies for a user key once.
  • With a user key and sufficient attributes, the data applicant can asynchronously decrypt all data released by the data owner at any time as required.
  • For details about the APIs, see "Attribute-based Encryption Key Management".
  Figure 3 Fine-grained access control
  
  

  Basic concepts:

  • Attribute: An attribute describes the association between an entity and its nature.
  • Policy: A policy is a combination of attribute sets and logical relationships. A policy is defined by the data owner and embedded in the ciphertext. For example, the policy "age>26 && gender=man" indicates that the age must be greater than 26 and the gender must be man.
  • ABE master key: An ABE master key consists of a master public key (MPK) and a master secret key (MSK). They are owned by the data owner and are used to encrypt data and generate a user (data applicant) key.
  • User key: A data applicant applies to data owners for a user key after submitting a set of attributes to the data user. A user key contains the user attribute information and is used to decrypt a ciphertext.