If you ask Clement, it was quite a challenge to run one of the small JVM variant within the enclave. We would need a specific support at the VM level to do some piece of code within the enclave while others are not.
On Thu 18-07-05 10:51, Sebastian Laskawiec wrote: >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 <slask...@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 <sa...@infinispan.org> >> wrote: >> >>> On 28 November 2016 at 07:21, Sebastian Laskawiec <slask...@redhat.com> >>> wrote: >>> > Hey Sanne! >>> > >>> > Comments inlined. >>> > >>> > Thanks >>> > Sebastian >>> > >>> > On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero <sa...@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 <slask...@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@lists.jboss.org >>> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> _______________________________________________ >>> >> infinispan-dev mailing list >>> >> infinispan-dev@lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > >>> > >>> > >>> > _______________________________________________ >>> > infinispan-dev mailing list >>> > infinispan-dev@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> >_______________________________________________ >infinispan-dev mailing list >infinispan-dev@lists.jboss.org >https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev