Automatic encryption of stored messages
Mikhail T.
mi+thun at aldan.algebra.com
Tue Apr 27 10:40:25 EDT 2010
Hello!
Is there a way to encrypt all of the Cyrus' user-specific files on the
disk? So that somebody breaking in -- or stealing the server -- has no
access to the messages (and other data) unless a user's password is also
available?
This is how I'd envision it:
* A somewhat secret "salt" and the location of a (memory-backed)
cyrus-only directory, such as /tmp/cyruspw, are set in a config-file.
* A user logs in using a pam-module, which creates a symlink such as
/tmp/cyruspw//user/ -> somehash(/salt/+/password+user/).
* Subsequent access to the user's files uses the above hash as the
key for user's messages, attachments, etc.
* New messages are stored unencrypted (or on a shared encrypted
partition) until the next time this user logs in. When he does,
his user-specific encryption begins in background.
* When the user disconnects, and all unencrypted messages are
encrypted, the user's entry is removed from /tmp/cyruspw until his
next login.
* A (rare) password-change will require all unencrypted messages to
be re-encrypted with the new hash -- until the re-encryption is
completed, the server will keep the old hash around (in a
different location, that would survive a system restart, such as
/var/cyrus/oldpw//user /->/ oldhash/) to provide access to the
not-yet-re-encrypted messages.
A fancier system could also provide for a "master password" to allow
message-recovery in case of the user forgetting their password (or a
law-enforcement subpoena). Some people may choose to not use this
feature in their setup...
I think, this ensures reasonable protection for the stored messages
without any cooperation from the MUA -- a stolen server (or a
decommissioned hard-drive) will not reveal user's e-mails. Also, each
user is assured, that their old emails are not accessible to anyone,
/when he isn't accessing them himself/.
This may be possible to do right now -- without changing the Cyrus' code
at all -- by using encrypted filesystems. Unfortunately, it means, each
user's files would have to reside on their own filesystem... The
proposed mechanism would provide a better way without /too much/
trouble. What do you think?
-mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20100427/92cd939d/attachment.html
More information about the Cyrus-sasl
mailing list