1

I'm evaluating a cloud storage product. The marketing literature states it uses Cryptree. I pulled the paper and performed a quick read, but I don't see where Cryptree lends itself to confidentiality and integrity from semi-honest employees and legal attacks like National Security Letters.

In fact, I'm not sure what the security goals are because they are not succinctly stated. Section 1 Introduction does discuss three goals, but they are related to efficiency and design; and not security.

The abstract does say something about untrusted storage, but the term is never defined. So its not clear to me if the only thing untrusted is the access control mechanism for the remote or distributed file system. The abstract is reproduced below.

I've also read 2.1 Key Management in File Systems several times, but its not clear to me how confidentiality and integrity is achieved with semi-honest employees and legal attacks because the system is clearly using symmetric keys.

Question: Is Cryptree suitable for cloud storage when a requirement is confidentiality and integrity from employees and government?


I have not pulled the source code at this point, but I might need to to see some of the design and implementation details. I'm especially interested in what goes on with the node that represents the root of the tree (and other keys that are based upon it (re: key regression and key updating)).


I placed the question on InfoSec.SE because I think the security goals of the file system are in purview, and its closer to design and implementation. Please let me know if I should flag for migration to Crypto.SE, which tends to be more theoretical.


We present Cryptree, a cryptographic tree structure which facilitates access control in file systems operating on untrusted storage. Cryptree leverages the file system’s folder hierarchy to achieve efficient and intuitive, yet simple, access control. The highlights are its ability to recursively grant access to a folder and all its subfolders in constant time, the dynamic inheritance of access rights which inherently prevents scattering of access rights, and the possibility to grant someone access to a file or folder without revealing the identities of other accessors. To reason about and to visualize Cryptree, we introduce the notion of cryptographic links. We describe the Cryptrees we have used to enforce read and write access in our own file system. Finally, we measure the performance of the Cryptree and compare it to other approaches.

2
  • it's really going to depend on the regulations your are subject to.
    – schroeder
    Apr 24, 2015 at 18:31
  • @Schroeder - this could be a subjective question (which is bad). Rather than focusing on potential open-ended-ness, focus on the symmetric encryption/decryption key used to encrypt a file before its wrapped or encrypted under a public key. If that key is exposed, then the filesystem does not protect against semi-honest employees or providers colluding with government.
    – user29925
    Apr 24, 2015 at 18:37

2 Answers 2

1

I'm not familiar with Cryptree, but from reading the first page of the PDF I can see that it's basically a file encryption library. (Actually directory-tree encryption.) So the answer to your question is: it depends on where the decryption happens and where the keys are stored.

If the provider uses Cryptree internally but holds the keys and does the crypto itself, then the answer to your question is "no". The provider has access to all of your data. They've made it somewhat harder for a rogue employee to read your files, but it's not impossible, and they have the capability to hand over your data to a government if ordered to.

If the provider leaves the encryption up to you, and the API between you and the provider merely transmits encrypted file data, then the answer to your question is "yes", because it means the provider has no way to read your files. All they have are encrypted blobs that they don't have the keys for.

I'm basically giving you the same answer as Gilles, but hopefully in a clearer form.

0

You're asking the wrong question. Cryptree certainly can be used for cloud storage, but that's irrelevant for you, because you have requirements that not every cloud storage fulfills: you don't trust the cloud provider to maintain the confidentiality of your data.

Since you don't trust the cloud provider, what algorithms they use to store your data is irrelevant. You need a solution where all of the cryptography happens on the client end. To the cloud provider, your data will appear as opaque blobs. Furthermore, you should pick client-side software for the cryptography that is not provided by the cloud provider, since you don't trust them not to include a backdoor.

In the description of Cryptree, “storage” refers to the underlying storage for the filesystem — what would be the disk layer in a basic files-on-local-disk scenario. Cryptree is a filesystem layout, and the filesystem driver is part of the trusted base. You could use Cryptree locally if you wanted (but it may not be useful for you: its purpose is to store data from multiple principals, with protection managed by keys and not just by access rights).

6
  • @Giles - I'm not sure I agree with "... asking the wrong question". I have a product in front of me that provides cloud storage and effectively uses Cryptree for confidentiality, integrity and authenticity. Their marketing literature tells me that. That's where I have to begin. I'm not designing the solution. I simply have to answer the question, "Does Cryptree meet security goals".
    – user29925
    Apr 26, 2015 at 17:08
  • @jww You're still asking the wrong question. You're thinking “confidentiality”, but you should be thinking “confidentiality against ____”. Cryptree is relevant to confidentiality against the storage provider's other customers. You want confidentiality against the storage provider, which is a different matter. Apr 26, 2015 at 17:23
  • I provided the threats. They were semi-honest employees and a provider that colludes with government. Is the question not clear? What do you suggest I add (or take away)?
    – user29925
    Apr 26, 2015 at 17:47
  • 1
    @jww The question you're asking here is clear, but it's not the question you need to ask. I answered the question you needed to ask, by telling you that you need client-side encryption. To put it another way: you're asking if a certain material to build a wall is strong enough. And the answer is that this material is strong enough for many uses. But that doesn't help you because the wall is not where you need it to be. Apr 26, 2015 at 17:50
  • @Giles - I don't mean to sound rude, but that's not the question I asked. I'm not designing or building the solution. I am evaluating an existing product.
    – user29925
    Apr 26, 2015 at 17:54

You must log in to answer this question.