[Feature]: Encryption for data at rest

[gromain]

Feature detail

As highlighted in #359, it would be nice for Immich to support encrypting data per user on the storage medium, so that even the admin can't access them.

This would need a bit of work on both the server side but also in the clients. Encryption at rest could be activated globally or per user perhaps. This will incur a performance penalty, but I believe it's a very nice feature to have.

Platform

Server

[Nonobis]

bad idea for me ... Or only optional and with Big warning for admin ....
I think it's too risky for losing valuable pictures of familly or other type.

Even with backup...

[gromain]

The responsibility lies with the user to not forget their password in that case in my opinion. But of course, it's something that could be activated but would not be on by default.

I don't believe it's more risky in my opinion, sure you have to not lose your password (if it's used to derive the key, which is not a necessity, it could be in-app only and local to the device, each solution has its own drawbacks and advantages) but I don't see more ways to lose you pictures when encrypting data vs when not encrypting them.

There is a use case where you host Immich for family members or friends, but want to provide them with a privacy guarantee. There is currently no solution that would offer this kind of thing.

[zackpollard]

This is not something that we can facilitate without a huge overhaul of the application. Currently all processing of the assets are done on the server to determine geolocation, object detection, re-encoding, thumbnail generation, etc. In order to do encryption properly so the admin wasn't able to access the files, we would be required to do all of this on the client which for some features is simply no feasible. I would say that this is not in scope for now. I will discuss this with the dev team and if they agree I will close this issue.

[gromain]

The app could share the necessary metadata with the server for some of those features.

However, I think it's an important feature for a backup application to be able to secure the data (in addition to backing it up).

Object detection is a nice toy to have, but it's not an important feature of a photo backup application in my opinion. Another way to do this could be to deactivate the features that need the pictures to be stored in clear when encryption is activated for said account.

We are talking about sensitive personal data here and a breach in security in the server could expose the raw pictures to the internet (which is something likely until a proper assessment and pentest has been made on the code, as good as it may be).

[zackpollard]

We've discussed this internally and it's not something we are looking to implement. Although I agree with what you're saying about it providing additional security, the main focus of Immich is to provide these extra features and not just be a simple photo backup app. If we added this it wouldn't just be removing some features, all features except for viewing the photos would be gone. Thanks for the feature request but this is not within the scope of Immich for the foreseeable future

[gromain]

Thanks for your feedback.

[omidraha]

As far as I understand, the architecture of the app is the opposite of encryption.
While this feature will gradually become the most important.

Did you find a solution or similar apps for what you wanted? @gromain

[uhthomas]

I was just thinking about this today, and it would be nice but I came to a similar conclusion. It would be way too hard. It may be possible to encrypt some of the photos, but encrypting database entries and dealing with shared albums would be complicated. I would encourage users to instead encrypt their data at the block or file system level with LUKS or similar.

[gromain]

I think it was not clear in my initial proposal @uhthomas . Encryption of data at the block or fs level does not protect you against a nosy admin or against someone breaking into the server. Only protection this affords is against someone breaking into your house or datacenter, unplugging your server and leaving with it. IMO, much less likely to happen than someone finding a 0-day or an unpatched vulnerability on your server. Hence the devices E2EE request.

[gromain]

@omidraha no, not really unfortunately. Still looking for something viable. I thought Nextcloud would be OK, but not acceptable for my needs there (E2EE is not very functional).

[etnoy]

There is practically no way to protect users against a rouge admin

[haveachin]

People take photos of everything nowadays, like important legal and healthcare documents. I really want to emphasize the importance of this. Privacy is a basic right, even among your closest circle. Having a secure and easy way to back up images, especially for those not so tech-savvy, is a big deal. Immich checks all the boxes except for being private for all its users. The server admins of each instance have too much control. This opens the door for censorship and blackmail. E2EE could be a possible solution to this, even if this leaves users with less features when enabled. Users should at least be educated that their private images could be viewed by any user that has read access to the files on the server.

[uhthomas]

We really appreciate the concern of privacy and security, but it truly is out of scope for Immich. End-to-end encryption is fundamentally incompatible with how Immich works and is generally infeasible.

The best advice I can give is to run Immich on a device you trust with disk encryption and a secure network transport (TLS, VPN, etc).

As @etnoy highlighted, there really is not a great way to protect against malicious server administrators. Users with this level of concern for confidentiality should definitely not be uploading their private media to a server with such a level of distrust.

[etnoy]

There is no way to implement "e2ee" in a solution like immich. If you want e2ee in a media storage, put your photos in an encrypted zip file and put it on an SFTP server. You can't have galleries, browsing, metadata with e2ee