Segshare: Secure Group File Sharing in the Cloud Using Enclaves

2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)

SeGShare: Secure Group File Sharing in the Cloud using Enclaves

Benny Fuhry Lina Hirschoff Samuel Koesnadi Florian Kerschbaum SAP Security Research SAP Security Research SAP Security Research University of Waterloo Karlsruhe, Germany Karlsruhe, Germany Karlsruhe, Germany Waterloo, Canada

Abstract—File sharing applications using cloud storage are in- ness. Based on these schemes, cryptographically protected file creasingly popular for personal and business use. Due to data pro- sharing systems were proposed [10], [16], [19]–[22]. The main tection concerns, end-to-end encryption is often a desired feature drawback of such systems is that users gain plaintext access of these applications. Many attempts at designing cryptographic solutions fail to be adopted due to missing relevant features. We to the file key. To achieve immediate permission revocation, present SeGShare, a new architecture for end-to-end encrypted, it is necessary to re-encrypt the corresponding file with a new group-based file sharing using trusted execution environments key. Depending on the scheme, this involves expensive cryp- (TEE), e.g., Intel SGX. SeGShare is the first solution to protect tographic operations and the new key has to be distributed to the confidentiality and integrity of all data and management many users. The problem is more severe on immediate group files; enforce immediate permission and membership revocations; support deduplication; and mitigate rollback attacks. Next to membership revocation, as many files require re-encryption. authentication, authorization and file system management, our This becomes a critical problem if members are removed and implementation features an optimized TLS layer that enables added frequently [23]. high throughput and low latency. The encryption overhead of our In recent years, researchers propose solutions that use a implementation is extremely small in computation and storage trusted execution environment (TEE) for secure file sharing resources. Our enclave code comprises less than 8500 lines of code enabling efficient mitigation of common pitfalls in deploying code systems [24]–[27]. TEEs provide an isolated environment to TEEs. — an enclave — to protect code and data in an untrusted environment. A TEE called Intel SGX [28]–[33] is integrated I. INTRODUCTION into (most) modern Intel CPUs and used by all of these In many applications, users want to share files with a group approaches. A-SKY [24] and IBBE-SGX [25] are based on of other users. For instance, employees of a company want cryptographic access control schemes and also suffer from to share files with colleagues. One option is to distribute user’s access to plaintext file keys. Nexus [26] proposes a the files to each group member individually. A better option client-side enclave, which is a severe drawback due to the is a local or remote central repository to store the files heterogeneity of end-user devices. and manage access control. A convenient remote repository We propose and implement SeGShare, a solution supporting is a cloud-based file sharing service as it can reduce cost, group file sharing in large and dynamic groups. SeGShare increase availability and enable seamless multi-device access is TEE-based without using a cryptographic access control to files. Many commercial vendors provide such a service, e.g., scheme. Via tokens, users authenticate themselves to the Google Drive [1], Dropbox [2], or WeTransfer [3]. However, enclave and establish a secure channel with it, which is used data at cloud services could be accessed by unauthorized for all subsequent communication. On every user access, the parties or exposed by internal attackers [4]–[6]. Frequently, enclave checks encrypted access control policies to enforce company policies prohibit to upload files to an untrusted cloud read and/or write access on files. Immediate permission or provider [7]. membership revocations only require an inexpensive modifi- Some cloud providers, e.g., MEGA [8] or Sync.com [9], cation of an encrypted file. Users can upload arbitrarily large encrypt files client-side using file keys and store these keys files through the secure channel directly into the enclave. If the protected with the user’s password. They also enable group upload is granted, the enclave encrypts the files with a random file sharing by encrypting file keys with a group key, which is key using probabilistic authenticated encryption and stores the encrypted with the public key of each group member. How- files in the untrusted environment. On each granted file request, ever, this does not scale well for large groups as an additional the file is decrypted inside the enclave and sent to the user key is required for each group member. Furthermore, files have over the secure channel. SeGShare separates authentication to be re-encrypted on permission or membership revocations. and authorization using identity information in the tokens. MEGA and Sync.com use so-called Hybrid Encryption As long as the identity information is preserved, no further (HE) [10] with public-key management to enforce access change is necessary if a user’s token is replaced or if a user control. Besides HE, many cryptographic schemes have been has different tokens for multiple devices. A comprehensive proposed [11]–[18] to improve access control policies regard- list of SeGShare’s features not mentioned so far is presented ing, e.g., key distribution, the number of keys, and expressive- in Table II. Among others, it protects the confidentiality and

978-1-7281-5809-9/20/$31.00 ©2020 IEEE 476 DOI 10.1109/DSN48063.2020.00061 integrity of all data and administration files; supports data Memory Isolation. In the current version, SGX dedicates deduplication; and mitigates rollback attacks. 128 MB of the system’s main memory (RAM) for the so-called This combination of features is not met by any related Processor Reserved Memory (PRM). All code and data in the work (see Table III) and we agree with the authors of A- PRM are encrypted while residing outside of the CPU and SKY [24], who state that “given the memory and computa- decrypted and integrity checked when the data is loaded into tional limitations of SGX enclaves (e.g., trusted computing the CPU. All other software on the system, including privi- base (TCB) size, trusted/untrusted transition latency), it is far leged software such as OS, hypervisor, and firmware, cannot from trivial to develop such a proxy service able to scale and access the PRM. The OS can swap out enclave pages and SGX sustain a high data throughput, considering dynamic access ensures integrity, confidentiality and freshness of swapped-out control operations.” The key to achieve a high throughput pages, but paging comes with a major performance overhead. under dynamic groups is that SeGShare does not require com- Every program using SGX consists of an enclave and an plex cryptographic operations on permission or membership untrusted part, and the host process can invoke the enclave changes. Besides that, we build an efficient SGX-enabled TLS only through a well-defined interface. stack, use switchless enclave calls for all network and file Attestation. SGX has a remote attestation feature, which traffic, and the enclave requires only a small, constant size allows verification of code integrity and authenticity on a buffer for each request. remote system. This verification is done by hashing (called The main contributions of SeGShare are: measuring in SGX terminology) the initial code and data • New architecture for efficient, end-to-end encrypted loaded into the enclave. The authenticity of the measurement group file sharing supporting large and dynamic groups as well as the fact that the measurement originates from a using a server-side TEE, e.g., Intel SGX. benign enclave is ensured by SGX’s attestation feature (refer • First file sharing system combining confidentiality and to [28] for details). The measurement can be provided to an integrity of all data and administration files; immediate external party to prove the correct creation of an enclave. revocations without expensive re-encryptions; data dedu- Furthermore, the remote attestation feature allows to establish plication; rollback protection; and separation of authenti- a secure channel between an external party and an enclave. cation and authorization. This secure channel can be used to deploy sensitive data, e.g., • Latency average of 2.39 s and 2.17 s to upload and cryptographic keys, directly into the enclave. download a 200 MB file — faster than a plaintext storing Data Sealing. Inherently, SGX enclaves are stateless, i.e., Apache WebDAV server in the same setup. Latency all of its contents are lost when the enclave is destroyed. To under 170 ms for membership and permission operations, preserve data for multiple enclave runs, SGX offers data seal- independent of file sizes, stored files in total, number of ing. This process uses a sealing key to encrypt and integrity- group members, number of user permissions, and groups protect data. Afterwards, the data can be stored outside of the sharing a file. enclave in untrusted memory, and only an enclave with the • Storage overhead of only 1,06% for encrypted storage same sealing key can unseal the data. of a file shared with more than 1000 groups containing Protected File System Library. This library is shipped with 200 MB plaintext data. the Intel SGX SDK and provides a subset of the regular C • SGX-enabled, optimized TLS implementation. file API, e.g., file creation, file writing, and file reading. On • Enclave with only 8441 lines of code, reducing the write, data is separated into 4kB chunks, the data’s integrity potential for security-relevant implementation errors, un- is ensured with a Merkle hash tree variant, and each chunk intended leakages, hidden malware, and side-channel is encrypted with AES-GCM before it is stored in untrusted leakages. memory. When file chunks are loaded back into the enclave, the confidentiality and integrity is verified. The encryption key II. BACKGROUND can be provided manually, or it can be derived automatically First, SeGShare uses a TEE, more specifically Intel SGX, from the sealing key. At any point, only one file handle can to provide an end-to-end secure file sharing system. Second, be open for writing, but many handles for reading. the stored files are encrypted with probabilistic authenticated Switchless Calls. A primary performance overhead of SGX encryption. Third, we use a specific file system model. In this applications are switches into and out of an enclave, because section, we review these three concepts. state has to be saved and restored. SGX’s SDK supports switchless calls, a technique to reduce this overhead. Calls into A. Intel Software Guard Extensions (SGX) the enclave are replaced by writing tasks into an untrusted Intel SGX is an instruction set extension that is available buffer and enclave worker threads asynchronously perform in Intel Core processors since the Skylake generation and the task. Calls out of the enclave are written into a separate Intel Xeon processors since the Kaby Lake generation making untrusted buffer and untrusted threads perform the tasks. it a widely available TEE. It provides a secure, isolated processing area, an enclave, which guarantees confidentiality B. Probabilistic Authenticated Encryption (PAE) and integrity protection to code and data, even in an untrusted PAE provides confidentiality, integrity, and authenticity of environment [28]–[33]. encrypted data. PAE Enc takes a secret key SK, a random

477 initialization vector IV and a plaintext value v as input no further change is necessary if a user’s authentication token and returns a ciphertext c. PAE Dec takes SK and c as is replaced or if a user has different authentication tokens for input and returns v iff v was encrypted with PAE Enc under multiple devices. the initialization vector IV and the secret key SK. With a Table I presents an overview of our access control model. random initialization vector per encryption, AES-128 in GCM A user u ∈ U is assigned to one group g ∈ G or multiple mode [34] can be used as a PAE implementation. groups. Additionally, each user u is part of its default group C. File System gu, i.e., a group that only contains u. Each g has a group owner (GO), which initially is the user u adding the first member to We use a generic file system model that fits to various g. GOs can change group memberships (rG) and extend the operating system (cf. [35]). A file system (FS) is composed of group ownership (rGO) to other groups. Every f ∈ FS has at files (FC ) and directories (FD). We also denote the former as least one file owner (FO), which initially is the user uploading content files and the latter as directory files as both are stored a file or creating a directory. For any file f and group g, the FO C ∈ C in files. Each f F contains a linear array of bytes that can extend the file ownership (rFO) and set file permissions D ∈ D can be read and written. Each f F is a collection of files (rP ). The permissions can either be a combination of read and/or further directories, and it stores a list of all its children. (pr) and write (pw), or access can be denied (pdeny). As a The directories form a tree with a root directory file (fDr )at result, a user’s permissions depend on the permissions of all ∈ the root of the tree. The parent directory of each f FS is groups he is member of. The main benefit of group-based specified by its parent in the tree. permission definitions is that a membership update is sufficient Each fD has a directory name. The directory name of fDr to provide or revoke a user’s access to many files instead of is defined as “/”, and all other directory names are flexible changing the permissions of all affected files individually. FOs excluding the character “/”. Each fD has a path that is can define that a file f ∈ FS should inherit permissions from specified by its location in the directory tree hierarchy: the its parent (rI ). This enables, for example, central permissions path is the concatenation of all directory names in the tree management of multiple files: create a directory, set the desired from fDr to fD delimited and concluded by “/”. Each fC has permissions for the directory, add files to the directory, and a filename, and fC ’s path is the concatenation of the path of define that the files should inherit permissions. its parent directory and its filename.

III. DESIGN CONSIDERATIONS TABLE I: SeGShare’s access control model. In this section, we first describe an ideal file sharing system Element Description to illustrate the features we expect from such a system, to introduce notation, and to introduce a formal access control U Set of individual users u model. Then, we describe the attacker model. Based on those G Set of individual groups g; each user u has a default group gu steps, we deduce a set of functional, performance and security P Set of individual permissions p ∈{pr,pw, objectives. Finally, we present related work showing that no pdeny} existing solution fulfills these objectives. FC Set of stored individual content files fC FD Set of stored individual directory files fD A. Ideal File Sharing System FS File system FS = FC ∪ FD ⊂ × ( ) ∈ A file system owner (FSO) has many users (U). Those rG U G u, g rG: user u is member of group g ⊂ × × ( ) ∈ users want to share files via a file sharing system hosted at a rP P G FS p, g, f rP : group g has permission p for file f cloud provider. The FSO has an authentication service, which rI ⊂ FS f ∈ rI : file f inherits permissions from provides an authentication token with identity information its parent to all users. W.l.o.g., we use a certificate authority (CA) rFO ⊂ G × FS (g, f) ∈ rFO: group g owns file f as authentication service and certificates as authentication rGO ⊂ G × G (g1,g2) ∈ rGO: group g1 owns group g2 tokens throughout this paper. To use the system, users only have to store the authentication token. They use this token for authentication while establishing a secure channel with We also expect the following features from the service. an enclave running at the cloud provider. Without any spe- (1) Immediate revocation, i.e., file permission or membership cial hardware, users use the established secure channel for updates, especially revocations, are enforced instantly without the following requests: create/update/move/download/remove time-consuming re-encryptions of files f ∈ FS. (2) A constant files; create/list/move/remove directories; set file/directory per- number of ciphertexts for each f ∈ FS, independent of missions for an individual user or a group; create groups; permissions and group memberships. (3) Confidentiality and and change group memberships. All requests do not require integrity protection of all content files, the file system struc- interaction with other users and authorization is done with ture, permissions, existing groups, and group memberships. the identity information contained in the authentication token, (4) Storage space reduction by deduplicating files and using which leads to a separation of authentication and authorization. the same encrypted files for different groups. (5) Rollback As a result, as long as the identity information is preserved, protection for individual files and the whole file system.

478 B. Attacker Model access. HE requires public-key management, e.g., by a PKI, to We consider the CA trusted, i.e., it securely creates certifi- establish a trusted connection between users and public keys. cates for users and securely provisions them. All users know Identity Based Encryption (IBE) [11], [12], [48] allows to and trust the CA, more specifically its public key, which is use arbitrary strings as public key for each user. given in many corporate environments. An attacker controlling Attribute Based Encryption (ABE) [13], [14], [49] enables multiple users should only have permissions according to the fine-grained access control by defining a set of attributes for union of permissions of the individual controlled users. At users and files. Files can only be decrypted if a defined number the cloud provider, we assume a malicious attacker, i.e., an of attributes match [13], the policy defined in the user’s attacker that does not need to follow the protocol and tries secret key matches the ciphertext’s attribute [14], or the policy to gain as much information as possible. Only the enclave defined in the ciphertext matches the user’s attributes [49]. data and code are protected by a TEE and not accessible The idea of Broadcast Encryption (BE) [15], [16], [50] by the attacker. The code is assumed not to have intentional is that a broadcaster encrypts messages, sends them via a data leakage and it contains a hard-coded copy of the CA’s broadcast channel, and only a permitted subset of users is public key. All other software is controlled by the attacker. able to decrypt the messages. BE can be used for file sharing As a result, she can monitor and/or change data on disk by considering the files as messages and the file system or in memory; rollback individual files or the whole file as broadcast channel. BE schemes have various tradeoffs system; send arbitrary requests to the enclave; view all network regarding private key, public key and ciphertext size, but no communications; and monitor communication between the scheme is constant in all sizes. untrusted and trusted software part. We do not protect the Identity-Based Broadcast Encryption (IBBE) [17], [18], [51] number of files, the file sizes, and the file access pattern. is a combination of IBE and BE. Messaged are encrypted We note that research has shown that SGX is vulnerable to under a public key for receivers that are identified by an various side-channel attacks, e.g., timing attacks [36], cache arbitrary string, and receivers can decrypt messages with their attacks [37], or page faults [38]. Other research mitigates side- private keys if their identity is part of the receiver set. As with channel attacks [39]–[41], detects side-channel attacks [42], or BE schemes, IBBE schemes are not constant in all keys. proposes a data oblivious file system [43]. Side-channel attacks File Sharing Systems. Cryptographically protected file and mitigations are orthogonal to our research and thus, we sharing systems use the just presented cryptographic access do not consider them further. Hardware attacks and Denial of control mechanisms and enrich them to file systems with, Service (DoS) are out of scope. e.g., key regression [19], integrity proofs [20], and data C. Design objectives deduplication [22]. Some TEE-based file sharing systems also use the cryptographic access control mechanisms to design an Based on the ideal file sharing system and the attacker anonymous file sharing system [24] or an IBBE scheme with model, Table II shows the functional, performance and security reduced encryption complexity [25]. NEXUS [26], Pesos [27] objectives that we expect from a secure and flexible file sharing and SeGShare are not based on the cryptographic access system. control mechanisms. D. Related Work All file sharing systems that are based on a cryptographic Conceptually, TEE-based key-value stores [44]–[47] are re- access control mechanism use HE or a combination of HE lated as they also use enclaves to authenticate users; to receive and IBE, ABE, BE, or IBBE. This, e.g., allows to remove and send encrypted data over a secure channel; and to guar- the public-key management, reduces the number of keys, antee confidentiality and integrity of data stored in untrusted and/or increase the expressiveness of access control policies. storage. However, they do not support the (overwhelming) However, permitted users gain plaintext access to the file key majority of objectives defined in Table II. Especially they do on each file access. Therefore, the following process has to be not support data sharing and dynamic (user- or group-based) executed to enforce immediate permission revocation: a new access control, which is the main focus of this paper. file key is generated, the file is re-encrypted with the new key, In the remainder of this section, we discuss related file the new key is encrypted for each user or group still having sharing systems, which we distinguish between pure crypto- access. On membership revocation, the just mentioned process graphically protected and TEE-supported file sharing systems. has to be performed for every file the group has access to. In Table III, we present to which extent those systems fulfill Objective P3 is not fulfilled by those file sharing systems. the defined objectives. If applicable, the table shows on which Additionally, Garrison et al. [23] state that (1) most IBE cryptographic access control mechanisms the systems are schemes are pairing-based, which is an order of magnitude based on. In the following, we first describe those mechanisms slower than public-key encryption used at HE, (2) ABE and then discuss highlights of Table III. incurs substantially higher costs than IBE, even for simple Cryptographic Access Control Mechanisms. A simple access control policies, (3) existing schemes for proxy re- access control mechanism is Hybrid Encryption (HE): a file is encryption [52], [53] do not solve the problem, and (4) crypto- encrypted with a unique, symmetric file key, and the file key graphic access controls lead to prohibitive computational cost is encrypted with the public key of each user that should have for practical, dynamic workloads.

479 TABLE II: Expected functional (Fx), performance (Px) and security objectives (Sx).

obj. Description obj. Description F1 File sharing with individual users / groups P3 File permissions / group membership revocations do not F2 Dynamic permissions / group memberships require re-encryption of content or directory files F3 Users set permissions P4 Constant number of ciphertexts for content and directory files F4 Separate read and write permissions P5 Different groups can access the same encrypted file F5 Users (and administrators) do not need special hardware S1 Protect confidentiality of content files / file system F6 Non-interactive permission / membership updates structure / permissions / existing groups / group memberships F7 Multiple file owners / group owners S2 Protect integrity of content files / file system structure / F8 Separation of authentication and authorization permissions / existing groups /group memberships F9 Deduplication of encrypted files S3 End-to-end protection of user files F10 Permissions can be inherited from parent directory S4 Immediate revocation P1 Constant client storage S5 Protection against rollback of individual files / whole file system P2 Group-based permission definition

TABLE III: Classiﬁcation of SeGShare and related work based on objectives deﬁned in Table II. The symbols represent that an objective is supported ( ), partially supported ( ), not supported ( ), or not part of the design (–). Note that some objectives in Table II have multiple sub-objectives separated by /, which are also used in this table.

based system F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 P1 P2 P3 P4 P5 S1 S2 S3 S4 S5 on Pure Cryptographically Protected File Sharing Systems [10] HE /– /– /– /– /– – / / /–/– / / /–/– / [19] HE /– /– /– /– /– – / / /–/– / /–/–/– / [16] BE /– /– /– /– /– – / / /–/– / / /–/– / [23] IBE, ABE / / / / / / / / / / / / / / [20] BE /– /– /– /– /– – /–/ /–/– /–/ /–/– /– [22] ABE /– /– /– /– /– – / / /–/– / / /–/– / TEE-Supported File Sharing Systems [24] HE / / / / / / / / / / / / / / [25] IBBE / / / / / / / / / / / / / / [26] / / / / / / / / / / / / / / [27] / / / / / /–/ / / /–/ / / / SeGShare / / / / / / / / / / / / / /

Only Pesos [27] does support multiple file owners and IV. SEGSHARE DESIGN no system supports multiple group owners (F7). Only In this section, we discuss SeGShare’s design based on NEXUS [26] and Pesos [27] separate authentication and the components illustrated in Fig. 1. This design fulfills most authorization (F8). Deduplication of encrypted files (F9) is objectives presented in Table II. Any remaining objectives are only supported by REED [22], and no system supports permis- fulfilled by extensions discussed in the next section. We start sion inheritance (F10). Almost all cryptographically protected with the setup phase in which trust is established between file sharing systems do not support group-based permission users and the cloud provider, followed by the runtime phase definition (P2). Therefore, each objective related to groups is in which user requests are processed. not part of their design. Only the approach from Garrison et al. [23] and Pesos [27] support that different groups can A. Setup: Establish Trust between Users and Enclave access the same encrypted file (P5), which can significantly The setup phase of SeGShare establishes bilateral trust reduce the required storage for files shared with different between each user u ∈ U and the enclave running at the cloud groups. Only NEXUS [26] protects the confidentiality and provider. This phase is only executed once, and the established integrity of the file system (S1 and S2). Half of the systems trust is the basis for the end-to-end security of user files. perform immediate revocation (S4), and all others propose Establish user trust in enclave. The CA’s certificate service lazy-revocation, i.e., re-encryption is deferred until the next component connects to the untrusted certification component, file update. This opens a window of opportunity for security one external interface of SeGShare, to perform remote attes- breaches, as a revoked user can still access all files that are tation of the enclave (see Section II-A). The CA’s public key not updated. No related work provides a rollback protection for is hard-coded into the enclave. Thus, if the CA receives the individual files and the whole file system, which is enforced expected measurement, it is assured to communicate with an at every point in time (S5). enclave that was built specifically for this CA. During remote attestation, the CA establishes a secure channel that ends at the

480 User User Cloud Provider Application SeGShare Server SeGShare Enclave TLS TLS Request File Root Interface Interface Handler Manager Key Priv. Client File Key Cert. Certification Certification Access File Component Component Control Manager

CA Certification Service Server Key Memb. Group File ACL Cert. Pair List List Trusted Untrusted Fig. 1: SeGShare architecture. trusted certification component. This channel is used for the create/update a file; get file content or directory listing; set following message exchanges: (1) the CA requests a certificate file/directory permission for a group; and add/remove a user signing request (CSR); (2) the enclave generates a temporary to/from a group. Remember that each user is part of its default key pair and provides the CA with a CSR containing the group, and thus, permission requests also applies for individual public-key of the temporary key pair; and (3) the CA generates users. A request used to define that a file should inherit its and signs a server certificate and provides it to the enclave. The permissions is described in Section V-B. We do not discuss enclave checks the certificate’s validity. On success, it persists the following requests for brevity, but their implementation the server certificate in untrusted memory, seals the key pair is straightforward: remove file/directory; move file/directory; (see Section II-A), and triggers the trusted TLS interface to update ownership of file/directory; update group ownership; update its server certificate. The CA can request a new CSR and delete group. and subsequently replace the server certificate at any time. Notably, the user application does not require any special During runtime, the users receive the server certificate on hardware (F5), and it only needs to store a client certificate every connection. As the CA checks the validity of the enclave and the corresponding private key, independent of cloud stored and the users trust the CA, the users only have to verify the files, permissions or group memberships (P1). server certificate with the CA’s public key to be sure that TLS Interface. The TLS interface is partitioned into an they communicate with a trusted SeGShare enclave. Notably, untrusted and trusted part (inside the enclave). The untrusted remote attestation is not necessary. TLS interface terminates the network connection (e.g., TCP), Establish enclave trust in users. For each user u ∈ U,the because the enclave cannot perform I/O. All TLS records are CA validates u’s identity and provides a client certificate to u. forwarded to the trusted TLS interface, which first performs This certificate contains identity information, e.g., a user ID, the TLS handshake using the most recent server certificate. a mail address, and/or a full name. User u can check that the Next, it decrypts/encrypts all incoming/outgoing TLS records. certificate is signed by the trusted CA as u knows CA’s public As such, the trusted TLS interface is the endpoint of a secure key. During the TLS handshake, u’s applications present u’s channel from the user application to the enclave. client certificate to the enclave, which validates the certificate Request Handler. The request handler component parses using the CA’s public key. On success, the enclave can be sure each incoming request, checks the syntax, uses the identity that it communicates with a valid user of the system. information in the client certificate to allocate the request B. Runtime: Requests and Responses to a user u, and processes requests as outlined in Algo. 1. During processing, it uses internal operations (see Table IV), Each request starts and each response ends at a user appli- which are provided by the access control and file manager cation. Therefore, we introduce this component of SeGShare components described in the following sections. first and then explain which parts of the processing are done by the other components. SeGShare achieves separation of authentication and autho- User Application. The user application links the users’ lo- rization (F8) by allocating u based on the identity information cal file systems to the remote file system at the cloud provider. in the client certificate and using u for authorization decisions. For this link, it establishes a connection to SeGShare’s second Furthermore, the combination of operations outlined in Algo. 1 external interface, the untrusted TLS interface. This interface allow a user to share a file or directory with individual users is used to establish a secure TLS connection directly to the (using their default groups) and groups (F1, P2), dynamically trusted TLS interface. Details about the two TLS interfaces change permissions and group memberships (F2, F3), set are discussed in the next section. separate read and write permissions (F4). None of the listed After a TLS handshake, the user application can send operations requires any interaction with other users (F6). requests to the enclave. In the design section, we only Updates of file and group ownerships are not listed, but the discuss the following requests in detail: create a directory; operations only require a straightforward update of rFO and

481 Algorithm 1 SeGShare’s external requests.

User u wants to create a directory at path1 User u wants to get file content if toFile(path)=f ∈ FC function put fD(u, path1); and directory listing if toFile(path)=f ∈ FD path2 = parent(path1) function get(u, path) if isDir(path1) and !exists f(path1) and exists f( if auth f(u, pr, toFile(path)) then path2) then return PAE Dec(SKf , read(path)) ( ( )) if path2 == ”/” or auth f u, pw, toFile path2 then User u wants to set permission p for group g for file at path updateRel(rFO,rFO ∪ (gu, toFile(path1))) ( ) ( ) function set p u, path, g, p write path1,”” if auth f(u,””, toFile(path)) then con ← PAE Dec(SKf2 , read(path2)) updateRel(rP ,rP ∪ (p, g, f)) write(path2, PAE Enc(SKf2 ,IV,con+ path1)) User u1 wants to add user u2 to group g User u wants to create or update a file at path1 with content function add u(u1,u2,g) con1 ( ) ( ) if !exists g g then function put fC u, path1,con1 updateRel(G, G ∪ g) path2 = parent(path1) updateRel(rG,rG ∪ (u1,g)) if !isDir(path1) and ((path2 == ”/”) or (exists f(path2) if auth g(u1,g) then and auth f(u, pw, toFile(path2)))or(exists f(path1) and updateRel(g, g ∪ u2) auth f(u, pw, toFile(path1)))) then if !exists f(path1) then User u1 wants to remove user u2 from group g

con2 ← PAE Dec(SKf2 , read(path2)) function rmv u(u1,u2,g)

write(path2, PAE Enc(SKf2 ,IV,con2 + path1)) if auth g(u1,g) then updateRel(rFO,rFO ∪ (gu, toFile(path1))) updateRel(g, g \ u2)

write(path1, PAE Enc(SKf1 ,IV,con1))

TABLE IV: SeGShare’s handling of internal operations. and access control checks (internal operations auth f and Operation Description auth g). For both tasks, it uses the file manager components to read and write the required relations. This component is ← ( ) f toFile path Get file f corresponding to path path key to enable dynamic groups without re-encryption. path2 ← parent(path1) For path path1, get parent directory’s path path2 File Managers. The trusted and untrusted file manager write(path, con) Create or update file at path path components handle all files stored in untrusted memory. The with content con trusted file manager component encrypts/decrypts the content con ← read(path) Read file at path path of all files that should be written/read with PAE Enc/PAE {0 1}← ( ) , exists f path Check if file with path path exists, Dec using a unique file key SKf per file. The file key is i.e., ∃f ∈ FS: toFile(path)=f derived from a root key SKr, which the trusted file manager {0, 1}←exists g(g) Check if group g exists, i.e., ∃g2 ∈ generates and seals (see Section II-A) on the first enclave start G: g == g2 {0, 1}←isDir(path) Check if file with path path is a and unseals on subsequent enclave starts. All encrypted data is directory i.e., ∃f ∈ FD : toFile( passed/received to/from the untrusted file manager component, path)==f which handles the actual memory access (internal operations c ← PAE Enc(SK,IV ,v) Encrypt value v under the initializa- read and write). tion vector IV and key SK with PAE v ← PAE Dec(SK,c) Decrypt the ciphertext c under key The file managers handle the following file types: SK with PAE ∈ {0 1}← ( ) 1) Each f FS is stored as a regular file. , auth f u, p, f Check if user u has permission p ∈ on file f, i.e., ∃g :(u, g) ∈ rG ∧ 2) For each f FS, an ACL file is stored under f’s path ((p, g, f) ∈ rP ∨ (g, f) ∈ rFO) appended with a suffix, e.g., “.acl”. This ACL stores f’s {0, 1}←auth g(u, g2) Check if user u is allowed to change access permissions (rP ) and file owners (rFO). group g2, i.e., ∃g1 :(u, g1) ∈ rG ∧ 3) One group list file stores all present groups (G) (g1,g2) ∈ rGO 4) For each user u ∈ U, a member list file stores u’s group updateRel(r1,r2) Update relation r1 to r2 memberships (rG) and also keeps track of u’s group ownerships (rGO). The first two types are stored in the so-called content store, rGO. This also allows to set multiple owners (F7). Note that the latter two in the group store. The files in the content store SeGShare is optimized for dynamic groups, but it is inefficient are stored in dictionaries according to the structure given by to remove a complete group as the member list of each user their paths. A root directory file stores a list of first level has to be checked and possibly modified. children. The files in the group store are stored flat and a root Access Control. The access control component is respon- directory file stores a list of all contained files. This separation sible for relation updates (internal operation updateRel) in two stores adds an extra layer of security and improves the

482 performance as file, directory, and permission operations are • Add a content file to the content store as presented in independent of group operations. Section IV-B with the slight modification that the content The content of ACLs, member lists, and the group list file is not filled with the actual file content but with are kept sorted. Thus, a permission update only requires one hName (comparable to symbolic links in file systems). decryption of the corresponding ACL, a logarithmic search, For each request to a content file, the trusted file manager one insert or update operation, and one encryption of the accesses the file in the content store and follows the indirection ACL. Membership updates require the same operations on one to the file in the deduplication store. member list file and (in some cases) on the group list file. Our server-side deduplication is different to any scheme Thus, permission and membership revocations do not require presented in related work: plaintext data is deduplicated and re-encryptions of content and directory files (P3), and they only a single copy is encrypted. This is possible because the are performed immediately (S4). Each f ∈ FS is stored in enclave has access to the file keys. Notably, the scheme also one encrypted file and f is accompanied by one encrypted supports deduplication of data belonging to different groups ACL file. Thus, the number of ciphertexts is constant for and immediate membership revocation without re-encryption. each content and directory file (P4). Obviously, the same encrypted content or directory file can be accessed by different B. Inherited Permissions groups (P5). The confidentiality and integrity of content files, Permissions for any file f ∈ FS can be inherited from a par- permissions, existing groups, and group memberships are ent directory (F10) with the following extension of SeGShare. protected by encrypting the corresponding files with PAE (S1, The user application and request handler are extended with a S2). new request to add/remove f to/from the inherit relation (rI ). The access control component only allows the file owner to ex- V. S EGSHARE EXTENSIONS ecute such requests, and the trusted file manager adds/removes In this chapter, we first present extensions of SeGShare that an inherit flag to/from f’s ACL file. If the inherit flag is not fulfill the remaining objectives: data deduplication, inherited set in f’s ACL file, access control checks for f are performed permissions, filenames and directory structure hiding, individ- by auth f as defined in Table IV. Otherwise, a permission p1 ual file rollback protection, and file system rollback protection. defined for a group g on f has precedence over a permission We also present SeGShare replication and file system backups. p2 defined for g on f’s parent. In other words, if fp is f’s The combination of extensions is only discussed if it is not parent and the inherit flag is set, auth f uses the following straightforward. predicate: ∃g :(u, g) ∈ rG ∧ ((p, g, f) ∈ rP ∨ ((p, g, f) ∈ ∧ ( ) ∈ ) ∨ ( ) ∈ ) A. Data Deduplication rP p, g, fp rP g, f rFO . The goal of data deduplication is to save storage cost by C. Hide Filenames and Directory Structure only storing a single copy of redundant objects, which can ei- To protect the confidentiality of the file system structure ther be files [54], [55] or blocks. Blocks can be further divided (S1), this extension hides all filenames and the directory in fixed-size [56] or variable-size [57] blocks. Deduplication structure. A change of the trusted file manager is sufficient: can be done client-side, i.e., users ask the server if a file is before passing a path to the untrusted file manager, it calculates already present and only upload the whole file if necessary, or the path’s HMAC using SKr and converts the HMAC to its server-side, i.e., users always upload and the server performs hexadecimal representation. As a result, all files are stored deduplication. in a flat directory structure at a pseudorandom location. Note SeGShare is compatible with all mentioned deduplication that SeGShare stores the original path in the directory files. alternatives. In the following, we propose a mechanism for Therefore, directory listing is still possible. file- and server-based deduplication, because it does not require additional client-side processing, prevents client-side D. Rollback Protection for Individual Files attacks [58], [59], and has the smallest leakage of the server- The trusted file manager encrypts the content of all files with side approaches [60]. PAE, and thus guarantees confidentiality and integrity on each Data deduplication is enabled in SeGShare (F9) by introduc- file individually. However, an attacker can perform a rollback ing a third store, denoted as deduplication store, and modifying attack on each encrypted file, i.e., the attacker uses an outdated the trusted file manager. For each uploaded content file, the version of an encrypted file to replace the current version. Not trusted file manager performs the following steps: preventing such a rollback can have severe consequences, e.g., • Temporarily store the file in the deduplication store under an old member list could enable a user to regain access to files a unique random name. for which the permissions were previously revoked. • Calculate an HMAC over the file’s content using the root This extension uses a Merkle hash tree [61] variant to key SKr. prevent rollbacks of individual files (S5) and to protect the • Convert the HMAC to a hex string hName. integrity of the file system structure (S2). For brevity, we only • If no file with the name hName is present in the dedu- describe how to protect files in the content store, but protecting plication store, rename the temporary file to hName. the group store (and deduplication store) is a straightforward Otherwise, remove the temporary file. adaption. Each content file, ACL, and empty directory file is

483 represented by a leaf node of the Merkle tree, and each other to be updated for every level of the tree. However, for leaf file directory file is represented by an inner node. Each leaf node validation, it is sufficient to recalculate and compare a single stores a hash that is a combination of hashes over the file path bucket hash per tree level, which only requires an access to and the file content. Each inner node stores a hash that is a all files in the same bucket. combination of the hash of all children (content files, ACLs and directory files), a hash over the directory path and a hash E. Rollback Protection for Whole File System over the directory content (children list). Even with the protection from Section V-D, an attacker can Before encryption, the trusted file manager prepends the still rollback the whole file system. The key to mitigate this content of content files, ACLs, and directory files with the rollback is to protect the root hash against rollbacks as it combined hashes, and after decryption, reads the hashes from represents a state of the complete file system. Based on TEE there. As each file stores its own hash, we denote each functionality, we propose two solutions to protect the root hash file representing a leaf node, inner node, sibling node, and and with it prevent rollbacks of the whole file system (S5). child node as leaf file, inner file, sibling file, and child file First, if the TEE offers a protected memory that can only respectively. The tree’s root hash is stored in the root directory be accessed by a specific enclave and is persisted across file, which we denote as root file in this section. Note that the restarts, it is sufficient to write/read the root hash into/from individual file rollback protection does not protect a rollback this memory, instead of storing it in the root file. Second, if the of the root file, which we consider a rollback of the whole file TEE offers a monotonic counter that can only be accessed by system for which a mitigation is presented in the next section. a specific enclave and is persisted across restarts, we propose Fig. 2 shows a hash tree for an example file system. the following. On each file update, the trusted file manager increments the TEE’s monotonic counter and writes the new

/ H0=H(/) counter value into the root file before encryption. On validity D/, D.acl H(D/,D.acl) H1 H2 checks of the root hash, it compares the TEE’s monotonic counter with the counter value stored in the root file. /D/ /D.acl H1=H(/D/) H2= F, F.acl P1 H(F,F.acl) H11 H12 H(/D.acl) H(P1) The group store’s and deduplication store’s root hash have to be protected by the same mechanism to protect the rollback /D/F /D/F.acl H11= H12= of all permissions and deduplicated files, respectively. path path H(/D/F) H(C) H(/D/F.acl) H(P2) C P2 SGX provides monotonic counters, but the current im- content cont. plementation has issues [63], e.g., increments are slow and Fig. 2: Example of a file system (left) and its corresponding the counter wears out fast. Until a better hardware-based ⊕ hash tree (right). denotes the concatenation of hashes. monotonic counter is available, one can use ROTE [63]. LCM [64] is a completely different approach, but it requires Normally, on a leaf file update or addition, its hash and all periodic interactions with the majority of users. hashes on the path to the root file need to be updated. This requires to access all sibling files and to combine their hashes. F. SeGShare Replication Also, on a leaf file read, a validation is performed starting from As we show in our evaluation section, SeGShare has a this file to the root file always accessing all sibling files. We very low latency. Nonetheless, it might be necessary to deploy propose two modifications to optimize this process: First, we SeGShare on multiple application servers if many users want replace all individual hashes and the combination of hashes by to use the file sharing service. Assuming that all enclaves so-called multiset hashes [62]. They allow the calculation of a access the data from one central data repository, two changes one-way hash of an individual value; combine multiple hashes are necessary: (1) the untrusted file manager must be extended to a fixed-size bit string, independent of the order of hashes; to access data from the central data repository, and (2) all to add/remove elements incrementally and efficiently; and to enclaves need access to the same root key SKr. check the equality of two multiset hashes efficiently. We refer The first change is only an implementation issue and thus, to [62] for details and a security proof that is based on the we only discuss the second in detail. In the following, we hardness of breaking the underlying pseudorandom functions. denote enclaves that already have SKr as root enclaves and the This modification improves leaf file updates or additions, others as non-root enclaves. We propose that the CA tasks one because it allows updates of the hash of each inner file by enclave with the generation of SKr during the provisioning of subtracting the hash of the no longer valid child file and to the server certificate. The CA provides all other enclaves with add the new hash, without accessing any sibling file. Second, addresses of root enclaves during the same process. Each non- depending on the number of child files, each inner file stores root enclave randomly selects one root enclave and performs multiple bucket hashes and one main hash. The bucket hashes remote attestation with it. If the measurements of both enclaves store a combination of child files’ main hashes, whereby a are equal, the non-root enclave is assured to communicate with hash over the child files’ path determines the used bucket, and another enclave that was compiled for the same CA, as the the main hash stores a combination of the hashed file path, CA’s public key is hard-coded. During remote attestation, a the hashed file content, and its bucket hashes. This change secure channel is established and the root enclave transfers slightly deteriorates update performance as two hashes have SKr over it.

484 SeGShare replication is also useful for file system owners, this problem via streaming, i.e., users send and receive small, which might be afraid to lose access to their files, because fixed-size chunks and the enclave processes one chunk at a SKr is only accessible by a single enclave. With the proposed time, which also includes storage operations. Thus, the enclave method, SKr is contained inside trusted enclaves at all time, only requires a small, constant size buffer for each request. but still usable on multiple replicas. VII. EVALUATION To combine the whole file system rollback protection and SeGShare replication, it is necessary to use a non-local pro- A. Security Evaluation tected memory or monotonic counter for each store. We note In this section, we focus on SeGShare’s main security that locking problems and data storage replication is beyond objective: end-to-end protection of user files (S3). The basis the scope of this paper. for S3 is SeGShare’s setup phase and mutual authentication during runtime (see Section IV-A): the trusted CA securely G. File System Backup provisions certificates only to valid SeGShare enclaves and SeGShare supports file system backups in a straightforward users, SeGShare enclaves only accept users with a valid manner: the cloud provider only has to copy the files on disk. certificate, and users only send files to an enclave, which can Backup restoration depends on the enclave that handles the present a valid certificate. Based on this trust, a TLS channel is restored data. If the enclave is the same that wrote the files in established between user applications and SeGShare enclaves the first place, it poses the required decryption key. Otherwise, protecting all messages in transit. The enclave code has the SeGShare replication process described in Section V-F is plaintext access to messages and file contents, but the enclave necessary. protects the processing and processed data. The enclave also Restoration becomes more complicated if the whole file enforces authorizations according to our access control model system rollback protection is active, because it might be (see Table I), which enforces that an attacker is restricted to necessary to restore an old state. We propose that the CA the union of permissions of the users under her control. As can send a signed reset message to the enclave for this case. discussed in the design and extensions sections, the enclave The enclave checks the validity of the message’s signature, protects the integrity and confidentiality of all files stored in reads the stored hashes from the root files of the various untrusted storage (S1, S2), enforces revocations immediately stores, recalculates the root hashes, and compares the hashes. (S4), and mitigates rollbacks (S5). Overall, user files are Assuming a successful check and the monotonic counter based protected in transit, during processing, and during storage. rollback solution, the enclave overwrites the stored monotonic We note that SeGShare’s security hinges on a trusted counter with the TEE’s current monotonic counter. enclave, which we assume in our attacker model. Still, we kept the enclave code as small as possible, as this reduces the VI. IMPLEMENTATION probability of security-relevant implementation errors, unin- Our prototype is implemented in C/C++ using the Intel tended leakages, hidden malware, and side-channel leakages. SGX SDK (version 2.5). The prototype follows the WebDAV Besides the Intel SGX SDK, the enclave has only 8102 lines standard [65], which is an extension to the HTTP standard of code, and 2376 of these are due to our TLS implementation, designed for the management of changes and permissions to which can be replaced by a formally verified version [74]. web resources. WebDAV makes the prototype compatible with existing clients on Android [66], iOS [67], Windows [68], B. Performance Evaluation Mac [68], and Linux [69]. The secure channel to transfer In this section, we discuss experiments regarding messages is established with TLSv1.2 using the ECDHE- SeGShare’s latency for upload and download, membership RSA-AES256-GCM-SHA384 cipher suite, and the MSet- addition and revocation, permissions addition and revocation, XOR-Hash construction [62] is used for multiset hashes. We and rollback protection. We end the section with a discussion implemented the filename and directory structure hiding and about SeGShare’s storage overhead. All latency measurements the rollback protection for individual files extensions. are performed with two machines hosted at Microsoft Azure: The prototype tackles three performance problems. First, a a client with 8GiB RAM and 2 vCPU cores of an Intel main performance bottleneck is the TLS stack. Unfortunately, Xeon CPU E5-2673 v4 @ 2.30GHz located in the central US publicly available SGX-enabled TLS stacks [70], [71] are region, and an SGX-enabled server with 16 GiB RAM and mainly designed for embedded scenarios and do not provide 4 vCPU cores of an Intel Xeon E-2176G CPU @ 3.70GHz the desired performance. Intel only provides an SGX opti- located in the east US region. The latencies are measured mized version of OpenSSL’s cryptographic library, without from a request start to response end at the user application networking capabilities. Our prototype combines Intel’s cryp- and presented as mean of 100 runs with a 95% confidence tographic library with the network part of OpenSSL (version interval (in plots). Sending and processing is interleaved due 1.1.1c) [72]. Second, switches into and out of the enclave have to our streaming technique and hence, we do not present the a high overhead [73]. To mitigate this problem, our prototype pure network latency of each request. uses switchless calls (see Section II-A) for our TLS library In the first experiment, we upload and download files with and for Intel’s Protected File System Library. Third, SGX has sizes from 1MBto 200 MB to SeGShare. For the baseline, we restricted protected memory space. Our prototype addresses execute the same test with two TLS-enabled — but plaintext

485 storing — WebDAV servers: Apache HTTP Server (version have access. For these operations, only permissions in the ACL 2.4) [75] and nginx (version 1.17.8) [76]. Fig. 3 shows that file are accessed, and thus, the latency is independent of the uploads and downloads of a 200 MB file, on average, take number of group memberships |rG|, |FS|, |rI |, |rFO|, |rGO|, 2.39 s and 2.17 s for SeGShare, 4.74 s and 2.62 s for the and the file sizes. The latency depends logarithmically on the Apache server, and 1.84 s and 0.93 s for the nginx server. number of groups having access, but Fig. 4 shows that this Overall, the upload and download performance of SeGShare dependency is again negligible in the total latency. is in between the two plaintext WebDAV servers. In the last latency experiment, we evaluate the overhead of SeGShare’s individual file rollback protection extension with the following measurement for x ∈ [0, 14]. As preparation, we upload (2x − 1) 10 kB files to SeGShare according to two different directory structures: (1) directories are organized as a binary tree and each leaf contains one file and (2) all files a stored flat under the root. Then, we measure the upload and download of one additional 10 kB file. Fig. 5 shows that due to our optimizations, the overhead introduced for uploads is negligible in the total latency. The minimal, average download Fig. 3: Mean latency of 1000 up-/downloads with different file latencies for directory structure (1) and (2) are 111.65 ms and sizes. 111.65 ms. Even for 16,384 files, the average latency only increases to 115.93 ms and 121.95 ms. In the second experiment, we measure the latency to add/revoke a user to/from his first group. These membership operations only affect the member list file of the user. Therefore, they are independent of the number of permissions |rP |, stored files |FS|, inherit flags |rI |, file owners |rFO|, group owners |rGO|, and the file sizes. Furthermore, they are also independent of the number of members the group had before, because the member list file contains only the group memberships of the user. On average, it takes 154.05 ms and 153.40 ms for additions and revocations, respectively. In the third experiment, we measure the latency of Fig. 5: Mean latency with enabled and disabled individual file adding/revoking a user to/from a group if the user is al- rollback protection extension and different directory structures. ready a member of several groups. Again, only the member list file is affected, and the latency is independent of The storage overhead for each file f ∈ FS depends on |rP |, |FS|, |rI |, |rFO|, |rGO|, and the file sizes. However, the f’s ACL file and the overhead introduced by Intel’s Protected latency now depends logarithmically on the number of the File System Library for both files. Remember that the size user’s group memberships, because a logarithmic search is of an ACL file depends on the number of file owners and necessary to insert or remove a group membership into or group permissions, and the library uses a Merkle tree with from the member list file. Even up to 1000 group member- 4kB nodes. Our prototype uses 32 bit for the number of ships, Fig. 4 shows that this dependency is negligible in the file owners and the inheritance flag, and 32 bit for each file mean latency, which is between 150.29 ms and 150.92 ms for owner and group permission. For an ACL with up to 95 and additions, and 150.11 ms and 151.13 ms for revocations. 1119 entries, a 10 MB plaintext file requires 10.11 MB and 10.15 MB encrypted storage, respectively. This corresponds to a relative storage overhead of 1.12% and 1.48%. A 200 MB plaintext file requires 202.09 MB and 202.13 MB encrypted storage corresponding to 1.05% and 1.06% overhead.

VIII. CONCLUSION In this paper, we introduce SeGShare — an end-to-end encrypted, group file sharing solution supporting large and dynamic groups using trusted execution environments (TEE), Fig. 4: Mean latency of addition and revocation of group e.g., Intel SGX. SeGShare protects the confidentiality and memberships and group permissions (x-Axis: number of mem- integrity of content files, the file system structure, permissions, berships/permissions before operation). existing groups, group memberships. Among other features, it enforces immediate permission and membership revocations; In the fourth experiment, we measure the latency of supports deduplication; mitigates rollback attacks; and pro- adding/revoking a group permission if several groups already vides separation of authentication and authorization.

486 REFERENCES [26] J. B. Djoko, J. Lange, and A. J. Lee, “NEXUS: Practical and Secure Access Control on Untrusted Storage Platforms using Client-side SGX,” in Proceedings of the 49th IEEE/IFIP International Conference on [1] Google, “Google Drive: Free cloud storage for personal use,” https: Dependable Systems and Networks, ser. DSN, 2019. //www.google.com/intl/en ALL/drive/, 2020. [27] R. Krahn, B. Trach, A. Vahldiek-Oberwagner, T. Knauth, P. Bhatotia, and [2] Dropbox, “Dropbox,” https://www.dropbox.com, 2020. C. Fetzer, “Pesos: Policy enhanced secure object store,” in Proceedings [3] WeTransfer B.V., “WeTransfer,” https://wetransfer.com, 2020. of the 13th EuroSys Conference, ser. EuroSys, 2018. [4] I. i. c. w. D. Protenus, “Protenus 2019 Breach Barometer,” https://www. [28] I. Anati, S. Gueron, S. P. Johnson, and V. R. Scarlata, “Innovative protenus.com/2019-breach-barometer, 2019. technology for CPU based attestation and sealing,” in Workshop on [5] A. Ng and M. Serrels, “Capital one data breach involves 100 Hardware and Architectural Support for Security and Privacy, ser. million credit card applications,” https://www.cnet.com/news/ HASP, 2013. capital-one-data-breach-involves-100-million-credit-card-applications/, [29] V. Costan and S. Devadas, “Intel SGX explained,” IACR Cryptology 2019. ePrint Archive, 2016. [6] B. Krebs, “Breach at cloud solution provider [30] M. Hoekstra, R. Lal, P. Pappachan, V. Phegade, and J. Del Cuvillo, pcm inc,” https://krebsonsecurity.com/2019/06/ “Using innovative instructions to create trustworthy software solutions,” breach-at-cloud-solution-provider-pcm-inc/, 2019. in Workshop on Hardware and Architectural Support for Security and [7] “How does your organization treat file sharing services like box, drop- Privacy, ser. HASP, 2013. box, google drive, etc?” https://www.reddit.com/r/sysadmin/comments/ [31] Intel, “Intel Software Guard Extensions Programming Reference,” https: a2u5x3/how does your organization treat file sharing, 2018. //software.intel.com/sites/default/files/managed/48/88/329298-002.pdf, [8] MEGA, “MEGA,” https://mega.nz, 2020. 2014. [9] Sync.com Inc, “Sync Secure Cloud Storage — Privacy Guaranteed,” [32] Intel Corporation, “Intel® software guard extensions (Intel® SGX),” https://www.sync.com, 2020. https://software.intel.com/sites/default/files/332680-002.pdf, 2015. [10] E. Goh, H. Shacham, N. Modadugu, and D. Boneh, “SiRiUS: Securing [33] F. McKeen, I. Alexandrovich, A. Berenzon, C. V. Rozas, H. Shafi, Remote Untrusted Storage,” in Proceedings of the 10th Network and V. Shanbhogue, and U. R. Savagaonkar, “Innovative instructions and Distributed System Security Symposium, ser. NDSS, 2003. software model for isolated execution,” in Workshop on Hardware and [11] A. Shamir and D. Chaum, “Identity-based cryptosystems and signature Architectural Support for Security and Privacy, ser. HASP, 2013. schemes,” in Proceedings of the 5th International Conference on Ad- vances in Cryptology, ser. CRYPTO, 1985. [34] M. Dworkin, “Recommendation for block cipher modes of operation: Galois/counter mode (GCM) and GMAC,” National Institute of Stan- [12] D. Boneh and M. Franklin, “Identity-based encryption from the weil dards & Technology, Tech. Rep., 2007. pairing,” in Proceedings of the 21st International Conference on Ad- vances in Cryptology, ser. CRYPTO, 2001. [35] A. S. Tanenbaum and H. Bos, Modern operating systems. Pearson, 2015. [13] A. Sahai and B. Waters, “Fuzzy identity-based encryption,” in Proceed- ings of the 24th International Conference on Advances in Cryptology, [36] N. Weichbrodt, A. Kurmus, P. Pietzuch, and R. Kapitza, “AsyncShock: ser. EUROCRYPT, 2005. Exploiting synchronisation bugs in Intel SGX enclaves,” in European [14] V. Goyal, O. Pandey, A. Sahai, and B. Waters, “Attribute-based encryp- Symposium on Research in Computer Security, ser. ESORICS, 2016. tion for fine-grained access control of encrypted data,” in Proceedings of [37] F. Brasser, U. Muller,¨ A. Dmitrienko, K. Kostiainen, S. Capkun, and the 13th ACM Conference on Computer and Communications Security, A. Sadeghi, “Software grand exposure: SGX cache attacks are practical,” ser. CCS, 2006. in Proceedings of the 11th USENIX Conference on Offensive Technolo- [15] A. Fiat and M. Naor, “Broadcast encryption,” in Proceedings of the 14th gies, ser. WOOT, 2017. Cryptology Conference, ser. CRYPTO, 1994. [38] Y. Xu, W. Cui, and M. Peinado, “Controlled-channel attacks: Determin- [16] D. Boneh, C. Gentry, and B. Waters, “Collusion resistant broadcast istic side channels for untrusted operating systems,” in Proceedings of encryption with short ciphertexts and private keys,” in Proceedings of the 2015 IEEE Symposium on Security and Privacy, ser. S&P, 2015. the 25th Cryptology Conference, ser. CRYPTO, 2005. [39] D. Gruss, J. Lettner, F. Schuster, O. Ohrimenko, I. Haller, and M. Costa, [17] C. Delerablee,´ “Identity-based broadcast encryption with constant size “Strong and efficient cache side-channel protection using hardware ciphertexts and private keys,” in Advances in Cryptology, ser. ASI- transactional memory,” in Proceedings of the 26th USENIX Security ACRYPT, 2007. Symposium, ser. USENIX Security, 2017. [18] R. Sakai and J. Furukawa, “Identity-based broadcast encryption,” IACR [40] S. Crane, A. Homescu, S. Brunthaler, P. Larsen, and M. Franz, “Thwart- Cryptology ePrint Archive, 2007. ing cache side-channel attacks through dynamic software diversity.” [19] M. Kallahalla, E. Riedel, R. Swaminathan, Q. Wang, and K. Fu, “Plutus: in Proceedings of the 22nd Network and Distributed System Security Scalable secure file sharing on untrusted storage.” in Proceedings of the Symposium, ser. NDSS, 2015. 2nd USENIX conference on file and storage technologies, ser. FAST, [41] S. Shinde, Z. L. Chua, V. Narayanan, and P. Saxena, “Preventing page 2003. faults from telling your secrets,” in Proceedings of the 11th ACM [20] R. A. Popa, J. R. Lorch, D. Molnar, H. J. Wang, and L. Zhuang, on Asia Conference on Computer and Communications Security, ser. “Enabling security in cloud storage slas with cloudproof,” in Proceedings ASICACCS, 2016. of the 11th USENIX Annual Technical Conference, ser. ATC, 2011. [42] S. Chen, X. Zhang, M. K. Reiter, and Y. Zhang, “Detecting privileged [21] K. E. Fu, “Group sharing and random access in cryptographic storage side-channel attacks in shielded execution with dej´ a´ vu,” in Proceedings file systems,” Master’s thesis, Massachusetts Institute of Technology, of the 2017 ACM on Asia Conference on Computer and Communications 1999. Security, ser. ASICACCS, 2017. [22] J. Li, C. Qin, P. P. C. Lee, and J. Li, “Rekeying for encrypted dedu- [43] A. Ahmad, K. Kim, M. I. Sarfaraz, and B. Lee, “Obliviate: A data plication storage,” in Proceedings of the 46th IEEE/IFIP International oblivious file system for Intel SGX,” in Proceedings of the 25th Annual Conference on Dependable Systems and Networks, ser. DSN, 2016. Network and Distributed System Security Symposium, ser. NDSS, 2018. [23] W. C. Garrison, A. Shull, S. Myers, and A. J. Lee, “On the practicality [44] S. Brenner, C. Wulf, D. Goltzsche, N. Weichbrodt, M. Lorenz, C. Fetzer, of cryptographically enforcing dynamic access control policies in the P. Pietzuch, and R. Kapitza, “Securekeeper: Confidential zookeeper cloud,” in Proceedings of the 2016 Symposium on Security and Privacy, using Intel SGX,” in Proceedings of the 17th International Middleware ser. S&P, 2016. Conference, ser. Middleware, 2016. [24] S. Contiu, S. Vaucher, R. Pires, M. Pasin, P. Felber, and L. Rveillre, [45] M. Bailleu, J. Thalheim, P. Bhatotia, C. Fetzer, M. Honda, and “Anonymous and confidential file sharing over untrusted clouds,” K. Vaswani, “SPEICHER: Securing LSM-based key-value stores using arXiv.org, 2019. shielded execution,” in Proceedings of the 17th USENIX Conference on [25] S. Contiu, R. Pires, S. Vaucher, M. Pasin, P. Felber, and L. Rveillre, File and Storage Technologies, ser. FAST, 2019. “IBBE-SGX: Cryptographic group access control using trusted execution [46] L. Chen, J. Li, R. Ma, H. Guan, and H. Jacobsen, “EnclaveCache: A environments,” in Proceedings of the IEEE 48th Annual IEEE/IFIP secure and scalable key-value cache in multi-tenant clouds using Intel International Conference on Dependable Systems and Networks, ser. SGX,” in Proceedings of the 20th International Middleware Conference, DSN, 2018. ser. Middleware, 2019.

487 [47] T. Kim, J. Park, J. Woo, S. Jeon, and J. Huh, “ShieldStore: Shielded [70] Fan Zhang, “mbedtls-SGX: a TLS stack in SGX,” https://github.com/ in-memory key-value storage with SGX,” in Proceedings of the 14th bl4ck5un/mbedtls-SGX, 2019. EuroSys Conference, ser. EuroSys, 2019. [71] wolfSSL Inc, “wolfSSL with Intel SGX,” https://www.wolfssl.com/ [48] B. Waters, “Efficient identity-based encryption without random oracles,” wolfssl-with-intel-sgx/, 2017. in Proceedings of the 24th International Conference on Advances in [72] The OpenSSL Project, “OpenSSL,” https://github.com/openssl/openssl, Cryptology, ser. EUROCRYPT, 2005. 2020. [49] J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-policy attribute- [73] S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe, based encryption,” in Proceedings of the 2007 IEEE Symposium on J. Lind, D. Muthukumaran, D. O’Keeffe, M. L. Stillwell, D. Goltzsche, Security and Privacy, ser. S&P, 2007. D. Eyers, R. Kapitza, P. Pietzuch, and C. Fetzer, “SCONE: Secure [50] D. Naor, M. Naor, and J. Lotspiech, “Revocation and tracing schemes for linux containers with intel SGX,” in Proceedings of the 12th USENIX stateless receivers,” in Proceedings of the 21st International Conference Symposium on Operating Systems Design and Implementation, ser. on Advances in Cryptology, ser. CRYPTO, 2001. OSDI, 2016. [51] K. He, J. Weng, J. Liu, J. K. Liu, W. Liu, and R. H. Deng, “Anonymous [74] K. Bhargavan, C. Fournet, M. Kohlweiss, A. Pironti, and P. Strub, identity-based broadcast encryption with chosen-ciphertext security,” in “Implementing tls with verified cryptographic security,” in Proceedings Proceedings of the 11th ACM on Asia Conference on Computer and of the 2013 IEEE Symposium on Security and Privacy, ser. S&P, 2013. Communications Security, ser. ASICACCS, 2016. [75] The Apache Software Foundation, “Welcome! - The Apache HTTP [52] A. Boldyreva, V. Goyal, and V. Kumar, “Identity-based encryption with Server Project,” http://httpd.apache.org/, 2020. efficient revocation,” in Proceedings of the 15th ACM Conference on [76] nginx, “nginx news,” http://nginx.org/, 2020. Computer and Communications Security, ser. CCS, 2008. [53] M. Green and G. Ateniese, “Identity-based proxy re-encryption,” in Pro- ceedings of the 5th International Conference on Applied Cryptography and Network Security, ser. ACNS, 2007. [54] J. R. Douceur, A. Adya, W. J. Bolosky, P. Simon, and M. Theimer, “Reclaiming space from duplicate files in a serverless distributed file system,” in Proceedings 22nd International Conference on Distributed Computing Systems, ser. ICDCS, 2002. [55] S. Keelveedhi, M. Bellare, and T. Ristenpart, “Dupless: server-aided encryption for deduplicated storage,” in Proceedings of the 22nd USENIX Security Symposium, ser. USENIX Security, 2013. [56] S. Quinlan and S. Dorward, “Venti: A new approach to archival storage,” in Proceedings of the 1st USENIX conference on file and storage technologies, ser. FAST, 2002. [57] A. Muthitacharoen, B. Chen, and D. Mazieres,` “A low-bandwidth network file system,” in Proceedings of the 18th ACM Symposium on Operating Systems Principles, ser. SOSP, 2001. [58] D. Harnik, B. Pinkas, and A. Shulman-Peleg, “Side channels in cloud services: Deduplication in cloud storage,” in Proceedings of the 2007 Symposium on Security and Privacy, ser. S&P, 2010. [59] F. Armknecht, C. Boyd, G. T. Davies, K. Gjøsteen, and M. Toorani, “Side channels in deduplication: Trade-offs between leakage and ef- ficiency,” in Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security, ser. ASIA CCS, 2017. [60] H. Ritzdorf, G. Karame, C. Soriente, and S. Capkun,ˇ “On information leakage in deduplicated storage systems,” in Proceedings of the 2016 ACM on Cloud Computing Security Workshop, ser. CCSW, 2016. [61] R. C. Merkle, “A digital signature based on a conventional encryption function,” in Conference on the theory and application of cryptographic techniques. Springer, 1987. [62] D. Clarke, S. Devadas, M. Van Dijk, B. Gassend, and G. E. Suh, “Incremental multiset hash functions and their application to memory integrity checking,” in 9th International Conference on the Theory and Application of Cryptology and Information Security, ser. ASIACRYPT, 2003. [63] S. Matetic, M. Ahmed, K. Kostiainen, A. Dhar, D. Sommer, A. Gervais, A. Juels, and S. Capkun, “ROTE: Rollback protection for trusted execution,” in Proceedings of the 26th USENIX Security Symposium, ser. USENIX Security, 2017. [64] M. Brandenburger, C. Cachin, M. Lorenz, and R. Kapitza, “Rollback and forking detection for trusted execution environments using lightweight collective memory,” in Proceedings of the 47th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, ser. DSN, 2017. [65] E. J. Whitehead and M. Wiggins, “WebDAV: IEFT standard for collab- orative authoring on the Web,” 1998. [66] Cx File Explorer, “Cx file explorer,” https://play.google.com/store/apps/ details?id=com.cxinventor.file.explorer, 2020. [67] Apple Inc., “Pages for iPad: Use a WebDAV server to store pages documents,” https://support.apple.com/kb/PH23552?viewlocale= en US&locale=en US, 2020. [68] South River Technologies, Inc., “WebDrive is the WebDAV Client that Works,” https://webdrive.com/webdav-with-webdrive/, 2020. [69] Free Software Foundation, Inc, “davfs2 - Summary,” http://savannah. nongnu.org/projects/davfs2, 2020.

488