feat: POD encryption

[jeswr]

Feature description:

The team I am currently working with is looking to encrypt data stored in their CSS server so that sysadmins etc. cannot read private POD data.

Is this kind of feature road mapped for the community server at all (as far as I'm aware some closed source solutions like the ESS have this - but there are no opensource implementations).

Either way - do you have thoughts on approaches to implement this should our team wish to build their own components for encryption?

[joachimvh]

It is not immediately planned but there are some potential options of what could be done.

First of all, a solution might be to use disk encryption so all data written on disk automatically gets encrypted.

The component responsible for storing resources on disk is the FileDataAccessor. One option could be to create a new Data Accessor that wraps around that accessor and encrypts the data stream before passing it to the FileDataAccessor. This would still leave the metadata unencrypted though. If that is also necessary a new Data Accessor that replaces the FileDataAccessor would be needed that mostly does the same but encrypts data before calling fs.

I wonder if in those cases it is an issue that encryption and decryption is completely done server side. Because that means the encryption/decryption keys also have to be on the server which means a sysadmin might also be able to access those making the entire encryption moot. If that is also relevant, the safest way would be for users to encrypt their data before storing it in a pod, potentially with a client that does this.

I am not a security expert though so there might be details I'm missing there.

[jeswr]

I wonder if it is possible to write an encryption/decryption component that can be used both here and in the Comunica Engine so both options are implemented at once.

That way you get server side encryption if it is bundled here as a new data accessor - and it becomes user side encryption if it is used as a parser/serializer in Comunica (i.e. bus-rdf-dereference -> bus-parse-encrypted -> bus-parse-rdf).

@rubensworks - any thoughts on this?

[rubensworks]

@jeswr Yeah, definitely makes sense to also include this in the Comunica framework.

Instead of encypting/decrypting server-side (for the issues raised by @joachimvh), it might indeed also make sense to do all of this client-side, with the introduction of a new encrypted RDF serialization (some work might already exist here). Downside will be that the server won't be able to do any more introspection into the data, which will break content negotiation etc. So not 100% sure that this is the way to go.

[joachimvh]

1 component that can be directly plugged in as both a data accessor here, and as a parser/serializer in Comunica seems unfeasible as the requirements of those interfaces differ quite a bit. It might be possible to create a data accessor that gets injected with a non-specific serializer, and then plug that common encryption module in there. But if we only keep the generic parts that is probably going to be a very small module that just encrypts an input stream and decrypts an output stream.

[jeswr]

some work might already exist here

This seems to be the latest work in the space http://semantic-web-journal.net/system/files/swj1895.pdf
followed by https://link.springer.com/chapter/10.1007/11574620_24

[rubensworks]

Let me also ping @skirrane, she might also be interested in this.