Is Sandstorm safe to deploy as a hosted VPS if I care about data privacy?

[Brendan Miller]

I was reading through all the materials on the website, but I couldn't find an answer to this question.

It seems that Sandstorm grains are still vulnerable to snooping from hackers or the government through the virtualization layer if I deploy it through a hosting company like AWS, Linode, etc. because they can inspect the memory and hard drive directly while a grain is in operation, correct?

It seems that unless I physically control access to my Sandstorm server that this kind of snooping is still possible. Please let me know if I understand correctly.

Also, I could not find documentation that indicated that grains are encrypted at rest. Are they? 

Thanks for the clarification. I think Sandstorm represents an important approach, but it seems like end-to-end encrypted systems are still needed for real data privacy.

Best,

Brendan

[Jacob Weisz]

You'd be correct, presently there is no storage encryption in Sandstorm. Someone who has access to the server presently can access anything on the server. Encryption is definitely something that is wanted in Sandstorm, but I suspect that at-rest encrypted storage was a particularly low priority when Sandstorm was focusing on enterprise sales, as that's a pretty uncommon requirement for that particular use case.

Encryption is mentioned in Blackrock's roadmap: https://github.com/sandstorm-io/sandstorm/tree/master/roadmap/blackrock

--

  Jacob Weisz

  goo...@jacobweisz.com

--

You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sandstorm-dev/ba3887b7-3002-407d-8843-a44124715fd3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kenton Varda]

Hi Brendan,

Right, it fundamentally isn't possible to prevent someone like AWS from snooping on what the server is doing. However, we can make it difficult, at least, by encrypting data at rest, especially with fine-grained encryption. This doesn't solve everything, but would force the provider to go well out of their way to snoop, rather than be able to pick things up passively. As Jake points out, we'd like to implement better fine-grained encryption eventually, but for now you will need to rely on full-disk encryption underneath Sandstorm.

With all that said, you should probably only run Sandstorm on infrastructure providers you trust. Many people run Sandstorm on a physical machine that they keep in their home, for example.

End-to-end encryption is great but solves a different set of problems from Sandstorm. If your app is fundamentally a point-to-point messaging system, then you can use e2e, and there are plenty of great apps to use for this without the need to run your own server. But for any use case that involves multiple parties collaborating on a common data set, the server probably needs to understand the content, thus e2e just doesn't work.

-Kenton

--

You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-dev+unsubscribe@googlegroups.com.

[alo...@gmail.com]

Just to be super clear, what you are asking for is not technically feasible for any software or system at this point.

https://en.wikipedia.org/wiki/Homomorphic_encryption

If you look at the "benchmarks" of the few available implementations, they seem slower then using an abacus?

Probably using one of the Linux encryption schemes would be a better fit then sandstorm rolling its own at least for file system encryption. Again you'd be totally vulnerable to the hosting provider snooping memory.

[Kenton Varda]

On Sun, Mar 26, 2017 at 1:53 PM, <alo...@gmail.com> wrote:

Just to be super clear, what you are asking for is not technically feasible for any software or system at this point.

https://en.wikipedia.org/wiki/Homomorphic_encryption

If you look at the "benchmarks" of the few available implementations, they seem slower then using an abacus?

Yeah, I'm aware of FHE but as you point out it's not practical for arbitrary computation. It's also unclear to me just how "arbitrary" modern FHE systems are. I remember looking at one system which called itself FHE because it could do "both" kinds of operations: addition and multiplication.

Probably using one of the Linux encryption schemes would be a better fit then sandstorm rolling its own at least for file system encryption.

Sandstorm can potentially provide much better encryption properties than are possible at the full-disk level. Specifically, we can encrypt each grain with a different key. We can then store the key itself encrypted by the master key/password of each user or system who is allowed to access the grain. So we'd be able to prove that, starting from rest, no one except the specific users who are supposed to have access to a grain can possibly decrypt the data. As a corollary, we can show that the infrastructure provider -- and even the Sandstorm server administrator -- can't possibly get access to a grain's data if the user never logs in again.

Using Linux FDE, on the other hand, would entail having a single master key for the whole system, which means the server admin can always decrypt all the data for all users. Assuming the Sandstorm server is always running, the infrastructure provider also always has the ability to steal the key from the running VM.

Note that I'm not a crypto noob -- I helped build the key management infrastructure at Google, including implementing a framework for fine-grained encryption key management. :)

FWIW, in Blackrock, since each grain actually gets its own virtual block device, it might actually make sense to use dm-crypt to implement the actual encryption at the per-grain level. However, there are some reasons to question whether this is the right solution:

- FDE is generally designed for the threat model of device theft. In this model, the attacker has no access to your drive until the point of theft, after which you avoid ever using your drive again (if you get it back at all, you wipe or destroy it). In this model, authentication is not necessary, and indeed most FDE doesn't implement authentication. Also each block typically has a static IV which is reused every time it is written. If the attacker can only see the *last* write, this is fine, but if the attacker can see the whole history of writes, depending on the crypto algorithm, this can be problematic.

- In Blackrock, the block device stack runs on the worker nodes, not on the storage nodes. This means the keys would need to be resident on worker nodes, where they could be compromised by a sandbox breakout. It would be somewhat nice if keys never touched worker nodes, so that a transient sandbox breakout cannot be escalated into persistent access.

All that said, I certainly don't want to invent new crypto to solve these issues, and I'm not sure if there's anything better out there that is ready-to-use.

-Kenton

[Brendan Miller]

Thank you all for your thoughtful and detailed replies. I can see Sandstorm is extremely valuable without meeting this level of data privacy requirement for many reasons.

I am also keeping tab on developments like matrix.org and riot.im as an new transport for end-to-end encrypted collaborative apps through use of a "double-ratchet" encryption system. This requires building new apps, which Sandstorm does not. 

https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last/

Best,

Brendan

On Sunday, March 26, 2017 at 11:20:17 AM UTC-7, Brendan Miller wrote: