[infinispan-dev] Proposal - encrypted cache

Thu Jul 5 04:51:59 EDT 2018

Just stumbled upon:
https://blog.acolyer.org/2018/07/05/enclavedb-a-secure-database-using-sgx/

Perhaps using enclaves could be a way to secure in-memory data (especially
having in mind that we can use off-heap). Adding mandatory TLS +
Authentication would make Infinispan very secure.

On Tue, Nov 29, 2016 at 10:24 AM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> With your explanation I think I get it now...
>
> So from my point of view, I would assume that we *can't* trust the
> servers. But with TLS we *can* trust the communication channel.
>
> Does this makes sense now?
>
> On Mon, Nov 28, 2016 at 4:07 PM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
>
>> On 28 November 2016 at 07:21, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>> > Hey Sanne!
>> >
>> > Comments inlined.
>> >
>> > Thanks
>> > Sebastian
>> >
>> > On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero <sanne at infinispan.org>
>> > wrote:
>> >>
>> >> Hi Sebastian,
>> >> you're opening a very complex (but interesting!) topic.
>> >>
>> >> As the paper you linked to also reminds, it's extremely hard to
>> >> implement such a thing without "giving away" lots of useful metadata
>> >> to a potential attacker. It's an interesting paper as they propose a
>> >> technique to maintain query capabilities while not having the full
>> >> data readability, yet as other papers which I've seen before it's both
>> >> complex to implement, and leaves some questions unanswered; in this
>> >> case they seem to "just" not being able to camouflage the data access
>> >> patterns, which is pretty good but according to some experts really
>> >> not enough to keep the decryption keys safe.
>> >>
>> >> The typical problem is that if the server has no clue about the
>> >> encrypted blobs at all we won't be able to query it. However there's
>> >> ongoing research (like this one?) about being still able to run
>> >> queries on behalf of key-owning clients, identify a subset of the
>> >> data, e.g. a *naive* example: if you know the data structure and can
>> >> tell which section contains the "encrypted surname", then a client
>> >> could query for identical matches on the "encrypted surname"; however
>> >> this naive approach is critically flawed such as you might be able to
>> >> extract the encryption keys by analysing the statistical frequency of
>> >> signatures and run a dictionary attack, e.g. you might have a good
>> >> guess about which surname is expected to be the most commonly used.
>> >> You'll need salting techniques combined within the query capabilities,
>> >> e.g. MAC (message authentication codes) but these either require you
>> >> to trust the database (are we going in circles?) or expose you to
>> >> other forms of attack.
>> >
>> >
>> > Yes, you are correct. Not being able to query the server is a very
>> serious
>> > problem. But preventing a potential attacker from analyzing your
>> > communication seems very easy to be solved - just use TLS to encrypt
>> > connection between the client and the server.
>>
>> Maybe I misunderstood the "requirements" of your proposal. My answer
>> was based on the assumption that the client wouldn't trust the
>> servers, for example a client wanting to store sensible data in a
>> "database as a service" platform, having a third party provide the
>> service.
>> If you use TLS during communication, it implies you don't trust the
>> communication channels but somewhat trust the server. You might as
>> well just use TLS and then not store the data in encrypted form, or
>> share the encryption access with the servers?
>>
>> Thanks,
>> Sanne
>>
>>
>> >
>> > So I think the main challenge is how to perform a search operation
>> through
>> > an encrypted data set...
>> >
>> >>
>> >>
>> >> While it's obvious that this introduces some limitations on search
>> >> capabilities on the fields of the value, you might also have similar
>> >> problems just on the keys. For example you might not be able to use
>> >> any form of affinity which takes advantage of some domain specific
>> >> knowledge, or just about do anything useful beyond the pure
>> >> "key/value" capabilities which are extremely limited.
>> >> Besides, even the fact that the "key" doesn't change over time might
>> >> be critical: it means you can't use salting on the key, which again
>> >> introduces dictionary attacks by merely observing the frequency of
>> >> operations.
>> >>
>> >> Even if you're prepared to give up on all those features and accept
>> >> some limitations to just encrypt it all on the client, the "grid"
>> >> needs nevertheless to be considered a trusted party; given the large
>> >> amount of data and access patterns, the data grid has so much insight
>> >> on both data and access patterns, that I doubt it can be properly
>> >> secured.
>> >
>> >
>> > Granted. If a potential attacker had access to the machine hosting an
>> > Infinispan Server (e.g. could do a memory snapshot), the encryption
>> > algorithm would need to "survive" statistical analysis.
>> >
>> >>
>> >>
>> >> I'm not sure we have the right engineering skills to develop such a
>> >> system, we'd need at least to brush up on existing research in this
>> >> field, of which I'm not aware there being any "full solution" unless
>> >> you give a good amount of trust to the database..
>> >
>> >
>> > There's a database called CryptDB:
>> >
>> http://bristolcrypto.blogspot.com/2013/11/how-to-search-on-encrypted-data-in.html
>> >
>> > I haven't looked into the research papers yet but if we had to trust any
>> > database we should pick something like that.
>> >
>> >>
>> >>
>> >> I'd love it if someone could explore this more, but be aware that it's
>> >> not as easy as just enabling encryption on the client.
>> >
>> >
>> > I totally agree. Thanks a lot for pointing all those useful aspects!
>> >
>> >>
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>
>> >>
>> >>
>> >> On 25 November 2016 at 12:32, Sebastian Laskawiec <slaskawi at redhat.com
>> >
>> >> wrote:
>> >> > Hey!
>> >> >
>> >> > A while ago I stumbled upon [1]. The article talks about encrypting
>> data
>> >> > before they reach the server, so that the server doesn't know how to
>> >> > decrypt
>> >> > it. This makes the data more secure.
>> >> >
>> >> > The idea is definitely not new and I have been asked about something
>> >> > similar
>> >> > several times during local JUGs meetups (in my area there are lots of
>> >> > payments organizations who might be interested in this).
>> >> >
>> >> > Of course, this can be easily done inside an app, so that it encrypts
>> >> > the
>> >> > data and passes a byte array to the Hot Rod Client. I'm just thinking
>> >> > about
>> >> > making it a bit easier and adding a default encryption/decryption
>> >> > mechanism
>> >> > to the Hot Rod client.
>> >> >
>> >> > What do you think? Does it make sense?
>> >> >
>> >> > Thanks
>> >> > Sebastian
>> >> >
>> >> > [1] https://eprint.iacr.org/2016/920.pdf
>> >> >
>> >> > _______________________________________________
>> >> > infinispan-dev mailing list
>> >> > infinispan-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >> _______________________________________________
>> >> infinispan-dev mailing list
>> >> infinispan-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20180705/5579868e/attachment-0001.html 