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