ObliviSync: Practical Oblivious File Backup and Synchronization

Oblivious RAM (ORAM) protocols are powerful techniques that hide a client's data as well as access patterns from untrusted service providers. We present an oblivious cloud storage system, ObliviSync, that specifically targets one of the most widely-used personal cloud storage paradigms: synchronization and backup services, popular examples of which are Dropbox, iCloud Drive, and Google Drive. This setting provides a unique opportunity because the above privacy properties can be achieved with a simpler form of ORAM called write-only ORAM, which allows for dramatically increased efficiency compared to related work. Our solution is asymptotically optimal and practically efficient, with a small constant overhead of approximately 4x compared with non-private file storage, depending only on the total data size and parameters chosen according to the usage rate, and not on the number or size of individual files. Our construction also offers protection against timing-channel attacks, which has not been previously considered in ORAM protocols. We built and evaluated a full implementation of ObliviSync that supports multiple simultaneous read-only clients and a single concurrent read/write client whose edits automatically and seamlessly propagate to the readers. We show that our system functions under high work loads, with realistic file size distributions, and with small additional latency (as compared to a baseline encrypted file system) when paired with Dropbox as the synchronization service.Comment: 15 pages. Accepted to NDSS 201

To Share or Not to Share in Client-Side Encrypted Clouds

With the advent of cloud computing, a number of cloud providers have arisen to provide Storage-as-a-Service (SaaS) offerings to both regular consumers and business organizations. SaaS (different than Software-as-a-Service in this context) refers to an architectural model in which a cloud provider provides digital storage on their own infrastructure. Three models exist amongst SaaS providers for protecting the confidentiality data stored in the cloud: 1) no encryption (data is stored in plain text), 2) server-side encryption (data is encrypted once uploaded), and 3) client-side encryption (data is encrypted prior to upload). This paper seeks to identify weaknesses in the third model, as it claims to offer 100% user data confidentiality throughout all data transactions (e.g., upload, download, sharing) through a combination of Network Traffic Analysis, Source Code Decompilation, and Source Code Disassembly. The weaknesses we uncovered primarily center around the fact that the cloud providers we evaluated were each operating in a Certificate Authority capacity to facilitate data sharing. In this capacity, they assume the role of both certificate issuer and certificate authorizer as denoted in a Public-Key Infrastructure (PKI) scheme - which gives them the ability to view user data contradicting their claims of 100% data confidentiality. We have collated our analysis and findings in this paper and explore some potential solutions to address these weaknesses in these sharing methods. The solutions proposed are a combination of best practices associated with the use of PKI and other cryptographic primitives generally accepted for protecting the confidentiality of shared information

Optimal Checkpointing for Secure Intermittently-Powered IoT Devices

Energy harvesting is a promising solution to power Internet of Things (IoT) devices. Due to the intermittent nature of these energy sources, one cannot guarantee forward progress of program execution. Prior work has advocated for checkpointing the intermediate state to off-chip non-volatile memory (NVM). Encrypting checkpoints addresses the security concern, but significantly increases the checkpointing overheads. In this paper, we propose a new online checkpointing policy that judiciously determines when to checkpoint so as to minimize application time to completion while guaranteeing security. Compared to state-of-the-art checkpointing schemes that do not account for the overheads of encrypted checkpoints we improve execution time up to 1.4x.Comment: ICCAD 201