DataProtector & Web3Mail: The Tech Behind the Tools

iExec recently unveiled new developer tools to address the use case of ‘Privacy-Enhancing Marketing’. These tools are the iExec DataProtector and iExec Web3Mail. These developer tools, existing as simple-to-use npm code packets, aim to revolutionize the way DApps handle data privacy and communication. This article will deep-dive into the technical functions of DataProtector and Web3Mail.

iExec DataProtector

The iExec DataProtector is a tool designed to protect user data by utilizing an encryption mechanism and managing access rights through smart contracts. Data owners can grant permission to applications, enabling them to use data — without actually disclosing the data itself.

This tool is an efficient solution for handling data; it bundles and simplifies iExec dataset functionalities such as data encryption and access rights management. Furthermore, DataProtector facilitates the retrieval of all protected data associated with a specific owner or a specific data schema (see below an example of data schema). It also provides the user with the capability to revoke one or all access rights to data. In other words, data owners have the ability to dynamically manage and control access permissions, which ensures robust security and privacy of their data, with a user-friendly tool.

In the iExec ecosystem, a dataset is a Non-Fungible Token (NFT) used as a governing mechanism for confidential data. In the iExec Marketplace, dataset providers create and sign ‘datasetorders’ which specify the governance of the dataset, e.g. which Dapp can use the dataset. In DataProtector, data owners define higher-level access rules that are automatically translated into datasetorders.

DataProtector can easily be integrated into any software project (Quick start) to make protected data seamlessly accessible to authorized Confidential Computing applications.

DataProtector relies on:

1/ a DataProtector smart contract that interacts with DatasetRegistry smart contract to create dataset;

2/ a DataProtector subgraph, an off-chain server that continually observes events on blockchain, and then stores, indexes, and retrieves data protected by DataProtector, and uses the following components of iExec protocol:

• The DatasetRegistry smart contract to create/mint the corresponding dataset associated with the protected data
• the PoCo smart contract to manage access rights
• the iExec Marketplace to share orders
• the Secret Management Service (SMS) to store the users’ secrets

The six functions of DataProtector

1/ protectData encrypts users’ data and records ownership on a smart contract.

To protect his data, a user calls the protectData function by providing the data data as input. Optionally, the user can also specify a name for the data, which will be public information and remain unencrypted. If no name is provided, it is assigned as “Untitled”.

Here, an example of a data object:

data:
{
email: 'example@gmail.com',
SMTPserver: {
port: 5000,
smtp_server: 'smtp.gmail.com'
}
}

In this example, the data object consists of two keys: email and SMTPserver. The value of email is example@gmail.com. The value of SMTPserver comprises two other key/value pairs: port with the value 5000 and smtp_server with the value smtp.gmail.com.

Then, the protectData function runs the following steps:

1. Extract the data schema, i.e. the different key and type of each value. Here, the corresponding data schema of the previous data example:

dataSchema:
{
"email": "string",
"SMTPserver": {
"port": "int",
"smtp_server": "string"
}
}

2. Create an archive of data which is seen as a folder. In this folder, a file is created for each key. The type of each file matches the type of the corresponding key and the file contains the corresponding value specified in the data. It is possible to have sub-data that correspond to the sub key/value pairs of a key. This key is created as a folder in which a file is created for each sub-key/value pair. The global folder is zipped into an archive.

Here, the corresponding archive of the previous data example:

Example: right part to include

This tree structure allows you to protect any type of data such as files, text, image, and more. Additionally, the resulting archive can be easily uploaded to any storage platform, facilitating data storage and retrieval processes.

3. Generate an encryption key and encrypt the archive. The AES-256-CBC standard encryption scheme is used in this encryption. Then, the encrypted archive is pushed into the IPFS public storage.

4. Send to the DataProtector smart contract the data schema along with classic datasets creation arguments:

• DataProtector smart contract calls the DatasetRegistry smart contract to mint the corresponding dataset and broadcasts the data schema in a blockchain event.
• DataProtector subgraph observes this event and indexes the protected data.

5. Push the encryption secret key to the SMS.

6. Return to the user the protectedData and metadata values.

2/ grantAccess that authorizes an application to use users’ data without ever revealing the data itself.

A data owner uses the grantAccess function to authorize an application and a requester to access his or her protected data. This function takes as inputs protectedData, authorizedApp and authorizedUser that are the addresses of the protected data, the application and the user respectively. Then, the grantAccess function runs the following steps:

1. Create a datasetorder to set the governance rules, i.e. the access rights for authorizedApp and authorizedUser, signed by the owner of the dataset.
2. Publish datasetorder on the iExec Marketplace.
3. Return to the user the datasetorder.

3/ revokeAllAccessObservable that revokes all applications’ access to a specific protected data.

The revokeAllAccessObservable function is called by a data owner with the protectedData value and optionally, the authorizedApp filter and/or the authorizedUser filter. Then, the revokeAllAccessObservable function runs the following steps:

1. Query datasetorders to the marketplace and if provided, matches the filters.
2. For each datasetorder, it revokes datasetorder with a call to the PoCo smart contract that emits an event of this revocation. The Marketplace API observes this event and clears the corresponding order.
3. For each revoked access, it returns the datasetorder and the transaction signed by the owner that revokes this access.

4/ revokeOneAccess that revokes an application's access to a specific protected dataset.

The revokeOneAccess function is similar to the revokeAllAccessObservable function except that the revocation is for one access. A data owner calls revokeOneAccess with grantedAccess as input to initiate the revocation of this access. The grantedAccess value can be obtained from the fetchGrantedAccess function. Then, revokeOneAccess runs the following steps:

1. Request a revocation of the corresponding datasetoder to the PoCo smart contract that emits an event of this revocation. The Marketplace API observes this event and clears the corresponding order.
2. Return the datasetorder and the transaction signed by the owner that revokes the access.

5/ fetchProtectedData that retrieves encrypted data protected by DataProtector.

A user calls the fetchProtectedData function with optionally, an owner filter (to obtain only the encrypted data of a particular user) and/or a dataSchema filter (to retrieve the encrypted data with a specific schema). Then, the fetchProtectedData function processes the following steps:

1. Query the protected data to the DataProtector subgraph, optionally matching the filters.
2. Return to the user an array of the requested protected data, i.e. name, address, owner and schema of each protected data, optionally matching the filters.

6/ fetchGrantedAccess that provides the list of accesses granted on a specific protected data.

The fetchGrantedAccess function has a similar mechanism to the fetchProtectedData function except that the request is for the granted accesses of a given protected data. This request works as follows:

1. A user calls fetchGrantedAccess with protectedData as input. Optionally, the user can request only the authorized applications and/or the authorized requester by specifying the authorizedApp and authorizedUser filters respectively.
2. fetchGrantedAccess queries datasetorder matching the filters to the Marketplace API and returns an array of the all granted accesses.

Example use case: Web3Mail

Using DataProtector, Web3Mail is a tool for developers to create applications that enable sending an email to Ethereum account holders without knowing their email address. By leveraging this tool, end-users can eliminate the requirement of sharing their email address with multiple third parties, significantly mitigating the risks associated with data breaches and spam.

Web3Mail relies on DataProtector to protect email addresses and interact with the iExec protocol, the sendEmail DApp and mailjet service to send emails.

In the iExec Marketplace, application providers create and sign ‘apporders’ that specify the governance of the application, e.g. the fee for each execution of the DApp. In Web3Mail, the sendEmail DApp is already deployed and the corresponding apporder has been signed and published in the iExec Marketplace. The sendEmail DApp takes the subject and the content of the email as requester secrets and sends an email to the protected email address.

In the iExec protocol, the requester secrets are parameters only exposed to authorized applications inside enclaves and never leave them. In Web3Mail, only sendEmail DApp can access the subject and the content of emails.

First of all, the Ethereum account holders use DataProtector to protect their email addresses and grant permission to other users to send them emails. An Ethereum account holder can specify a predetermined limit for accessing his protected email. Once this limit is reached, the account holder must call the grantAccess function of DataProtector to grant permission for further emails to be sent to him.

For each protected email, a dataset has been created and the corresponding datasetorder has been signed and published in the iExec Marketplace and indexed by the Graph.

Web3Mail comprises of two functions:

• fetchMyContacts that returns the list of Ethereum accounts whose owners have authorized to email them. A user calls the fetchMyContacts function that runs the following steps:

1. Send a request to the Marketplace API to recover the list of datasetorders for which the owners have granted permission to the user to access and utilize their protected dataset.
2. Request the corresponding protected datasets to the Graph.
3. Verify whether each dataset includes an email field, ensuring that the schema of each protected dataset matches with ‘email:string’.
4. Return to the user the list of valid contacts, including the protected dataset and owner addresses.

• sendEmail that sends an email to a user by knowing only the Ethereum account

A user invokes the sendEmail function to send an email to an authorized Ethereum account holder, who can be retrieved using the fetchMyContacts function. The user specifies the email subject emailSubject, the email content emailContent and the protected email address protectedData.

The sendEmail function creates and signs an order called ‘requestorder’ to request an execution of the sendEmail DApp. Therefore, the process of this function is similar to creating a request for a task in the iExec protocol.

In the iExec ecosystem, a task is an instance where computing power is required. The task is the execution of a deal between a datasetorder, an apporder, a requestorder and a workerpoolorder, indicating which workers are available for which category of tasks. In Web3Mail, a task is an execution of sendEmail DApp with the protected email as dataset, the email subject and the email content as requester secrets.

sendEmail processes the following steps:

1. Query the SMS to check the existence of the storage token. This token is used as an authentication token for the worker to upload the result of the task. This ensures that only the authorized worker is able to submit the task result.
2. Request the corresponding protected dataset to the Graph and verify whether each dataset includes an email field.
3. Request to the Marketplace API: The datasetorder of the protected email with the protectedData address, the apporder of sendEmail DApp, the workerpoolorder
4. Push emailSubject and emailContent as requester secrets (see iExec Technical Documentation for further details).
5. Create and sign a requestorder to request an execution of the sendEmail DApp with the emailSubject and emailContent as requester secrets. In the requestorder, the user can specify the price he is willing to pay for the execution of the task.
6. Notify the PoCo smart contract that there is an orders’ match between the apporder, datasetorder, workerpoolorder and requesterorder. Then, the PoCo smart contract: verifies and validates the match, emits an orders match and a notification to the scheduler of the workerpool, returns the dealid
7. Request to compute the corresponding task of the deal to the PoCo smart contract. The scheduler that has already watched the orders match and the notification from the PoCo smart contract initiates the task which triggers the sendEmail DApp execution.
8. Return the taskid to the user.

Limitations of these tools

DataProtector and so Web3Mail utilize the Confidential Computing (CC) developed by iExec. The SMS used in iExec CC is a centralized component in which users send their secrets, e.g. the secret key for encrypting data.

When a secret is received, the SMS creates a secure session within the CAS (Configuration and Attestation Service), pushes in the secret and grants the application associated with the requestorder to access it.

However, due to the centralized nature of the SMS, there exists a potential single point of failure. If either the CAS or the SMS undergo an update or is down, there is a risk of losing the stored secrets.

To address this concern, iExec is actively working towards decentralizing the SMS, thereby mitigating the aforementioned issue and enhancing overall system resilience.

It is important to note that Web3Mail utilizes Mailjet services, employing an intermediate email address to facilitate the sending of emails. The level of trust in Web3Mail is directly linked to the trust placed in both the mailjet service and iExec operating it and having the ability to access the email addresses and the email content.