On 11/10/2018 06:44, Paul Chubb wrote:
Hi thanks for the responses. I try not to do crypto for the very
reasons you raise - i simply don't know enough and your (good) pointed
questions have demonstrated that.
Context:
We are trying for GDPR and other privacy law compliance. We probably
need to meet GDPR, US requirements, Australian requirements, Japanese
requirements and UK requirements. The data is not hugely critical. It
contains names and exercise metrics. It doesn't contain credit card
details or anything above the level of names. I don't think it
contains addresses but probably does contain names of recognizable
organisations which could provide a tuple for identification purposes
if the data was compromised.
A mysqldump of the db in production at present is around 170Gb however
that is text based and we are using a binary solution based on percola
xtrabackup so the final size should be smaller for the current time.
The documentation on this by the backup software provider is very
simplistic and simply pipes the stream of data through openssl and
then gzip:
mariabackup --user=root --backup --stream=xbstream | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.gz.enc
There are thousands of posts that do similar and in non-crypto circles
it is the accepted way of doing things. That was my starting point.
I am not using a password but generating keys. The symetric key is
generated by "openssl rand -hex 32" which I have read is suitable. The
Nonce or IV is generated by "openssl rand -hex 16". These values are
used once and then kept for decryption of that file. They in turn are
encrypted before storing - see below.
The two keys are held in ram while the backup occurs. They are applied
to openssl using the -K and -iv switches. They are then written out to
disk. encrypted with a list of public RSA keys and the original
deleted from disk. I then package it all up and delete the intervening
encrypted files leaving me with an archive with the encrypted backup
and several copies of the nonce and key each encrypted by different
people's public keys.
The backup regime has not been decided as yet. I expect it will be
something like a full backup per week and then either incrementals or
differentials on the other days. I expect that the fulls will be kept
for 30 days and the deltas for 14days. The database backups will sit
on a secured server disk which in turn will be backed up by the
hosting provider with whatever process and rotation they use.
I would expect that headers in the backup stream would be predictable,
whether they provide a good enough attack surface I don't know. In
addition the clients of course know their data that may also provide
an attack surface. Finally I have included an encrypted file with a
known plain text phrase. Based on your comments, this will probably
not get into production but provides an easy way for testing and
debugging to check that things are encrypted or not.
The kind of statements that prompted my question was:
https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup
whose comments suggest that openssl should never be used for
production purposes.Their suggestion was GnuPG which isn't suitable
for this purpose because it does password/key management that assumes
a desktop/laptop environment and manual process. I also looked at
ccrypt and mcrypt but then went back to openssl.
Cheers Paul
On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni
<openssl-users@xxxxxxxxxxxx <mailto:openssl-users@xxxxxxxxxxxx>> wrote:
On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
> - Data recovery from an encrypted backup is tough. With CBC, one
bit goes
> astray and you've lost everything after that.
No, a 1 bit error in CBC ciphertext breaks only the current block,
and introduces a 1 bit error into the plaintext of the next block.
After that, you're back in sync.
But yes, indeed "openssl enc" offers little integrity protection.
One should probably break the data into chunks and encrypt and MAC
each chunk with the MAC covering the chunk sequence number, and
whether it is the last chunk.
I have not tested it with your huge data sizes, but I have had a lot of
success with the following pipeline which avoids a number of security
pitfalls by using higher levelOpenSSL commandline features:
BackupCmd | \
openssl smime -sign -binary -nodetach -signer SomeDir/mycert.pem \
-inkey SomeDir/mycert.key -outform DER | \
gzip -n -9 | \
openssl smime -encrypt -binary -out backup.enc -outform DER -aes256 \
SomeDir/restorecert.pem
Where mycert.pem is a certificate issued to the system being backed up
by an internal company CA (also used for intranet https servers) and
restorecert.pem is another such certificate where the private key is
available only to restore procedures.
A feature of this pipeline is that backups can be reencrypted with a
different key / mechanism without ruining the integrity signature, and
can also be recompressed with a better compression algorithm in the same
way.
Another feature is that the server being backed up does not need to know
the decryption key (restorecert.key), while the server doing restores or
backup verifications does not need to know the integrity signing key
(mycert.key).
Dealing with the risk of not being able to decrypt a corrupted backup is
handled by having more than one backup, just like the risk of completely
loosing a backup (fire, flood, ...).
Special note: Because the openssl smime (and openssl cms) signature
verify commands do not have an option to verify signatures as of some
past date (such as the date a backup was made) my restore scripts have
to run openssl under the "faketime" utility to make openssl think it is
being run on the day the backup was made.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
