Liberate Your Servers: A Decentralized Content Compliance Validation Protocol

Abstract

Content compliance validation provides a formal and secure procedure for applications (like emails or social networks) to determine how an intended action can be carried out. By conducting the validation against predefined policies, only compliant content is allowed to be delivered. Unfortunately, current solutions suffer from multiple issues such as intensive server-side overheads, intransparency and centralization.

To address these drawbacks, we propose DeCCV, the first decentralized content compliance validation protocol for real-world applications. In our work, the application requires to transparently declare its validation policies (${{\textbf {Policy}}^\textsf {Cont}_\textsf {VAL}}$) on the blockchain. Meanwhile, we outsource the resource-intensive validations to multiple decentralized off-chain validation nodes, which verify user’s content locally and issue the proofs (signatures) accordingly. Therefore, the burden of server-end workloads is minimized to merely signature-based verification. Moreover, a dedicated incentive mechanism is proposed to motivate high accountability of validation participants. DeCCV is platform-friendly that can be compatible with most real-world applications. We fully implement DeCCV for Gmail, Twitter and Dropbox to show its versatility.

Appendices

A Detailed Interactions of DeCCV

The detailed interactions among system participants are shown in Fig. 3. The numbered procedures correspond with the high-level interactions (described in Fig. 1). Note that the transmitted data objects between protocol actors are encrypted over a secure channel. Meanwhile, the incentive interfaces, including penalties, disputes and payouts etc., are not depicted in Fig. 3 as these actions can be triggered whenever any misbehavior is detected.

B Secure Communication Handshake Performance

DeCCV purses a confidentiality-preserving tunnel, and we utilize the latest version of TLS in our experiments. As discussed in Sect. 2.2, a full handshake process is divided into key exchange phase and authentication phase. In our experiment, the time consumption of these two procedures is 487ms and 671ms, respectively. Note that TLS is not the only design choice in practical for achieving transport protection. In Appendix C.1, we will discuss the considerations towards more design choices of communication protection.

C Discussions

In this section, we provide the discussions with respect to transport protection, a future direction toward a more fine-grained economic reward mechanism, and the generalizability of our protocol.

Fig. 3.

The interactions of DeCCV.

1.1 C.1 Secure Communication Design Choices

In DeCCV, we adopt TLS protocol as a channel protection method among system parties. In practice, the feasible approaches are not limited to it. For instance, a dynamic secret sharing scheme [29, 30, 37, 40, 41, 43] is regarded as an alternative that DeCCV can employ a recently proposed secret sharing scheme [40] for communication encryption. Concretely, with dynamical secret sharing, ${{\textbf {App}}}$ can first generate a key pair (${pk_{\textsf {Apps}}}$, ${sk_{\textsf {Apps}}}$), hardcode ${pk_{\textsf {Apps}}}$ into the blockchain for an arbitrary user to encrypt his content, and distribute the associated ${sk_{\textsf {Apps}}}$ to the key management committee members (i.e., a dedicated group of committee members to withhold the key). Once receiving an encrypted content from a user, each ${{\textbf {Node}}_\textsf {VAL}}$ will contact key management committees, then recover the ${sk_{\textsf {Apps}}}$, and decrypt the content for validation. We emphasize that secret sharing is seen as an alternative approach for transport protection. In particular, the proposed incentive mechanism could also applied to those key management members. In terms of performance, TLS is more resource-efficient when the number of key management members is beyond four. Moreover, since ${{\textbf {Node}}_\textsf {VAL}}$ and key management committees involve massive communications, TLS is deemed a more secure approach. We will keep track on the emergence of more effective transport protection schemes.

1.2 C.2 Towards A Fine-Grained Reward Design

Recall Sect. 5.2, with the increase in the number of registration, ${{\textbf {Node}}_\textsf {VAL}}$ would compete against each other to provide better validation services. Currently, we set the amount of rewards for each honest behavior as a fixed value. One possible improvement is making such the mechanism more fine-grained. For instance, as the computation consumption should vary in the size of user’s contents and the complexity of App’s policies, we could link the amount of reward to the size of requested content and the workloads of policy validations. More interestingly, ${{\textbf {App}}}$ and ${{\textbf {Node}}_\textsf {VAL}}$ could transparentize their reward fees and service commissions, respectively, which would create a better service market. We will leave such the design direction as future work.

1.3 C.3 Generalizability

In Appendix C.1, different techniques for transport protection are able to be switched in our system based on the security and performance considerations. In addition, we stress that DeCCV is platform-agnostic with regards to blockchains and real-world applications. Although ${{\textbf {Contr}}_\textsf {App}}$ is deployed on Ethereum platform in our experiments, the policy declaration and incentive design can be easily implemented on other blockchains that have similar smart contract capabilities [21, 26, 27]. Meanwhile, any real-world application which requires regulating the delivered contents can take advantage of DeCCV to filter out non-compliant contents. All an ${{\textbf {App}}}$ owner needs to do is policy declaration and smart contract deployment. We expect to see the possibility of collaboration with more real-world companies.