[openssl-users] openssl commandline client use

Fri Oct 12 02:31:43 UTC 2018

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 at dukhovni.org <mailto:openssl-users at dukhovni.org>> 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