ocis
ocis copied to clipboard
owncloud
Encryption with S3 Driver
Is your feature request related to a problem? Please describe.
I'd like to outsource the user data using an S3 Endpoint. I don't want to trust the storage provider.
Describe the solution you'd like
The S3 driver allows to specify an encryption key with which the data is encrypted before sending it to the data provider.
Describe alternatives you've considered
File-based encryption keys, Encryption at higher level.
Additional context
I don't think it is sensible to add encryption into the ocis driver, because the encryption key has to be on the same machine.
Our current plan is use the S3 storage encryption itself and not provide an additional encryption from the application. Most S3 storages allow encryption with external keys, etc. Does this help? If so, we would close here.
If my understanding of the S3 encryption is correct: In this case I'd still have to trust the storage provider to not save the key and decrypt my files. We have some files where data protection wants to limit every access possiblity.
I took a look to the software stack: Minio has an example for client side encryption, https://github.com/minio/minio-go/blob/master/examples/s3/putobject-client-encryption.go
So the main changes would be to implement a wrapper for blobstore that encrypts & decrypts the data, right?
I need more iformation @JustKiddingCode on what you want to achieve?
Like already written, simple encryption via S3 is possible.
More advanced concepts like SSE-C https://min.io/docs/minio/linux/administration/server-side-encryption/server-side-encryption-sse-c.html would mean that we need to shoulder the burden of key management and recovery features if user provided keys would be lost.
My scenario:
- Owncloud OCIS VM under our control.
- S3 storage is operated by different persons.
- We want to store files with very high confidentiality requirements.
- The files must be stored encrypted and even a rogue storage provider must not be able to decrypt the files.
- We are fine by owncloud ocis generating a key at storage initialisation and storing it.
and even a rogue storage provider must not be able to decrypt the files.
This is a very strict requirement and basically rules out SSE-C.
From https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html about SSE-C: With the encryption key that you provide as part of your request, Amazon S3 manages data encryption as it writes to disks and data decryption when you access your objects.
It basically leaves only client side encryption: https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html Amazon S3 does not play a role in encrypting or decrypting your objects.
Sorry to bump an old conversation, but I'm actually interested in this as well.
and even a rogue storage provider must not be able to decrypt the files.
This is a very strict requirement and basically rules out SSE-C.
This is not as high of a requirement for me; What I'd like to have if that is someone manages to access the S3 bucket (for instance from the WebUI), they'd still need the SSE-C key to decrypt the data.
I'm currently thinking about creating a proxy beween OCIS and my S3-compatible provider to inject the SSE-C key, but of course it would be way easier to just have it in OCIS.
If my understanding is correct, it shouldn't be extremely difficult (I think it should be enough to add 3 headers).
On where to store it, I think it could be treated in the same way the S3 credentials are currently treated (which I assume from the Helm chart, could be via environment variables)
There are even fancier ways to do this (for instance doing envelope encryption with the metadata like Constellation does), but that would become quite a bit of a change and perhaps it could be out of scope for OCIS.
Well, ended up writing a proxy to add 3 dummy headers lol https://github.com/Pandry/s3-ssec-proxy