End-to-End Encryption (E2EE)

When storing data with CSPs, cloud customers usually have to accept the risk of security incidents and failures related to modifications and loss of stored data. More than that, customers can never be sure that write-serializability (WS), i.e., consistency among updates, and read-freshness (RF), i.e., requested data always being fresh as of the last update, are always respected. And what is more important, even if customers are aware of data modifications or loss of data, they cannot prove to third parties when the cloud is to blame for WS or RF violations. On the other hand, the cloud provider itself cannot disprove false accusations.

In order to offer to customers secure storage solution and allow them to not only detect but also prove violations related to modification and loss of stored data, Secure Storage capability in SPECS is implemented by the E2EE security mechanism which provides the following functionalities:

  • Client-side encryption enforcing confidentiality and integrity (I).
  • Detection and proof of violations related to WS and RF.
  • Backup of stored data.

With the backup service we ensure that in case of detected WS/RF violations, the database is either restored from the backup or the REST API is moved from the primary storage site to the backup. In this case the backup replaces the role of the primary target service. In this way we ensure that any corrupted or missing data (caused either by WS/RF violations or failures on the main database) can be to some extent retrieved or replaced. And by “to some extent” we mean that the database can be restored to the state of the last backup. Any data lost or corrupted between two backups cannot be recovered.

While E2EE could be with some limited functionality used independently from SPECS, it is the SPECS platform that provides the functionality to:

  • Automatically deploy E2EE components according to the SLA (deploying the virtual machines with all the required E2EE components according to the security properties selected by user).
  • Detect violations out of the monitoring events generated by E2EE monitoring.
  • Choose the remediation action (like moving the REST API form the primary storage site to the backup) after the analysis of the monitoring events.
  • Trigger the remediation actions.

  • As described in CloudProof paper [1] (on top of which the E2EE mechanism has been built), WS and RF are monitored and proved with so called attestations, which are signed messages that bind the clients to the requests they make and the cloud to a certain state of the data. With every request (through the get or put interface), clients and cloud exchange attestations. Every get/put request is associated with an attestation.

    Before SPECS After SPECS
    • No open source solution available supporting WS and RF security properties.
      • Open source solution available supporting WS and RF security properties.
      • The E2EE mechanism is equipped with remediation functionality and thus an automatic incident response is enabled.
      • CloudProof auditor has been extended to be able to distinguish between different types of attacks.

    The source code for E2EE mechanism can be found at:

    References

    [1] R. A. Popa, J. Lorch, D. Molnar, H. Wang, L. Zhuang. “Enabling Security in Cloud Storage SLAs with CloudProof.” Usenix Technical Conference 2011.

    Contact & Feedback: XLAB, info@xlab.si