dovecot - Mar 2020 - At rest encryption (with protected crypto keys)

Hi,



As stated on the Dovecot documentation, at rest encryption is possible
[1]. However, these keys are present on the system itself and are
unprotected. Therefore, if a system is compromised, the attacker has
access to the encrypted mail and the keys. There is no security benefit
in that situation, except for hoping that the attacker doesn't
understand that this is happening and how.

Nextcloud does this a bit better. A key is used to encrypt user data as
well [2]. However, that key is protected with the user's password. When
the user logs in and requests data, the user's password unlocks the key
and data can be read and written safely. This also takes into account
password changes. Files don't need to be encrypted again, the
encryption key is simply re-encrypted with the new user's password.

How does the Dovecot community see this? Is at rest encryption needed
in times of increased security and privacy problems? I think it is a
must, just like 2FA, but that's a different story.

I think the current possibility of at rest encryption is not well
applied enough. Is this something that's on the agenda to improve? Or
am I missing something? Is there a better way of doing this?



[1] 
https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/#mail-crypt-plugin
[2] https://nextcloud.com/encryption/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200324/ee04cdbd/attachment.sig>

On Tue, 24 Mar 2020, Kees de Jong wrote:
> As stated on the Dovecot documentation, at rest encryption is possible
> [1]. However, these keys are present on the system itself and are
> unprotected. Therefore, if a system is compromised, the attacker has
> access to the encrypted mail and the keys. There is no security benefit
> in that situation, except for hoping that the attacker doesn't
> understand that this is happening and how.
>
> Nextcloud does this a bit better. A key is used to encrypt user data as
> well [2]. However, that key is protected with the user's password. When
> the user logs in and requests data, the user's password unlocks the key
> and data can be read and written safely. This also takes into account
> password changes. Files don't need to be encrypted again, the
> encryption key is simply re-encrypted with the new user's password.
>
> How does the Dovecot community see this?
The answer depends on how much security you want, and what you assume
an eavesdropper has access to.

The protection described in the second paragraph is merely an extension
of the first, where secrecy is implemented on the server side.  If the
system is compromised, it only takes several strategic placement of
code to intercept the secret parts and unravel the entire workings.
It may require expertise, but in theory, it's falls prey to the dishonest
administrator or skilled attacker.

A stronger form is client-side encryption: the key and encryption is done
on the client side, then only the encrypted data is transferred to the server.
The Nextcloud (or Dropbop) example is to have a encrypted FS on
the client side (e.g. VeraCrypt) and the whole container is sync'd
on the storage side (the server).  At no point does the server side ever
get to see keys.

Joseph Tam <jtam.home at gmail.com>