[NBLUG/talk] Encrypting Files for Cloud Backup

Zack Zatkin-Gold zg at nblug.org
Sat Apr 16 13:12:18 PDT 2016


See, I told you guys that writing things down on paper was more secure!

Except maybe your passwords on Post-Its.

My two cents on the subject: local backups.  Don’t store backups in the cloud, and never send a backup over the Internet, or you’re just putting your data at risk of becoming compromised as Kyle pointed out.  There are really inexpensive portable (multi) terabyte drives that you can buy off of Amazon.  I bought one a year or so ago and it works great for me.  I have it setup through Time Machine on my Mac.  It claims to be encrypted and it requires a password to unlock.  *shrugs*  I’m not sure how well this idea scales for a large company though.

> On Apr 16, 2016, at 12:20, Kyle Rankin <kyle at nblug.org> wrote:
> 
> Most of the cloud encryption examples you gave (and most of the examples
> out there) talk a lot about encrypting data at rest. Many places tout that
> they encrypt at rest (and a lot of industries, mine included, REQUIRE that
> you encrypt sensitive data at rest). While I strongly advise you encrypt
> your personal computer's disk at rest, unfortunately encrypting data at
> rest on a cloud server is pretty worthless outside of pretty specific
> things it protects against.
> 
> What at rest encryption protects you against:
> 
> * An attacker removing hard drives from a server.
> * Salvaging decommissioned drives that weren't shredded.
> * Someone who steals your laptop when it's off. 
> 
> What it doesn't protect you against:
> 
> * Someone who snatches your running laptop from your hands.
> * Someone who snatches your suspended laptop (see "Cold boot attack").
> * Someone who hacks your computer and has remote access.
> * Someone with access to a server that has the encrypted disk mounted.
> 
> The fact is that for most servers, their 'at rest' encrypted drives are
> almost never at rest. For you to store files on them they have to be
> mounted and decrypted (and generally stay in that state). That means that
> not only are the decryption keys stored in RAM on that machine (which means
> anyone with root can get them), it means the data itself is readable in an
> unencrypted state as long as that volume is mounted.
> 
> Who can read your "server-side encrypted" files:
> 
> * Anyone who can get root access to that server.
> * Anyone who can become the system user the storage service runs as.
> * Anyone who can compel the cloud storage company to get them access to the
>  storage.
> 
> This last point is important because for all the controversy around Apple
> vs. FBI, people overlook that Apple had already granted the FBI full access
> to that person's iCloud storage.
> 
> Even if the provider uses some more sophisticated scheme than disk
> encryption at rest that encrypts file-by-file, someone with root on the
> server will at some point be able to get the decryption key from RAM when
> you access your storage, or simply intercept the file in its unencrypted
> state once it lands on the server but before it's encrypted.
> 
> By encrypting the files before you send them up to the storage, you can
> make sure that no one from the sysadmin who has root on that server, to the
> hacker who found a security hole, to the official with a warrant, can
> decrypt your files. The keys and the decryption are strictly in your
> control, which is where you want it.
> 
> -- 
> Kyle Rankin
> The North Bay Linux Users' Group
> http://nblug.org
> IRC: greenfly at irc.freenode.net #nblug 
> kyle at nblug.org
> 
> On Sat, Apr 16, 2016 at 08:30:33AM -0700, Omar Eljumaily wrote:
>> I'm not trying to start an argument about this.  I'm just really interested
>> in how IT infrastructure gets hacked.  Here's an example of a real life hack
>> that has had very serious repercussions for a firm and its clients.
>> 
>> http://www.techrepublic.com/article/no-1-thing-it-departments-can-learn-from-the-panama-papers-hack/
>> 
>> Mossack Fonseca seems to have not taken security very seriously, although
>> privacy should have been a huge issue for them.
>> 
>> Another example of a serious data theft I heard about was a financial
>> services firm keeping backups for their wealthy clients in a private home
>> safe.  It seems reasonable on the surface, but thieves broke into the home
>> and the first thing they took was the safe.  The thieves probably chucked
>> the most valuable item in the safe, the data, and went for currency or
>> gold/jewels, etc.  Not all thieves are that stupid, though.  Physically
>> securing data is one place where local, private storage will never be able
>> to compete with 24/7 patrolled clouds in terms of privacy.
>> 
>> Thanks,
>> 
>> Omar
>> 
>> 
>> On 4/16/2016 7:03 AM, Omar Eljumaily wrote:
>>> I've never heard of a server side cloud encryption hack.  Maybe you can
>>> give some examples.
>>> 
>>> 
>>> On 4/16/2016 6:33 AM, Aaron Grattafiori wrote:
>>>> 
>>>> Server side encryption isn't really a secure solution for most threat
>>>> models, including typical cloud backup scenarios.
>>>> 
>>>> Client side encryption is a better option, via something like duplicity,
>>>> although you then have to remember to backup the (strongly password
>>>> protected) encryption key somewhere.
>>>> 
>>>> -Aaron
>>>> 
>>>> On Apr 16, 2016 7:25 AM, "Omar Eljumaily" <omar at omnicode.com
>>>> <mailto:omar at omnicode.com>> wrote:
>>>> 
>>>>   Amazon seems to offer encryption through a setting. That may be
>>>>   easier than what you're attempting.
>>>>   https://aws.amazon.com/blogs/aws/new-amazon-s3-server-side-encryption/
>>>> 
>>>>   I use Google cloud, and they encrypt as a standard feature.
>>>>   https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#encryption-at-rest
>>>> 
>>>>   All Google Cloud Storage data are stored encrypted. For more
>>>>   information see Server-Side Encryption
>>>>   <https://cloud.google.com/storage/docs/concepts-techniques#encryption>.
>>>> 
>>>> 
>>>>   You can also provide your own encryption keys. For more
>>>>   information, see ``
>>>>   <https://cloud.google.com/storage/docs/gsutil/addlhelp/SecurityandPrivacyConsiderations#id1>gsutil
>>>>   help encryption
>>>>   </storage/docs/gsutil/addlhelp/SupplyingYourOwnEncryptionKeys>`_`.
>>>> 
>>>> 
>>>>   On 4/15/2016 7:35 PM, gandalf at sonic.net
>>>>   <mailto:gandalf at sonic.net> wrote:
>>>>>   Hey, thanks. This looks real good. I'll start digging into it
>>>>>   next week. I have even found a elaborate setup script just for
>>>>>   Amazon.
>>>>> 
>>>>>   On 2016-04-15 19:14, Aaron Grattafiori wrote:
>>>>>>   Checkout duplicity...
>>>>>>   On Apr 15, 2016 8:13 PM, <gandalf at sonic.net>
>>>>>>   <mailto:gandalf at sonic.net> wrote:
>>>>>> 
>>>>>>>   Well I just got something working and am setting it up to work
>>>>>>>   over
>>>>>>>   the weekend.
>>>>>>> 
>>>>>>>   tar -zcf - -C /backups/servers itdocs | openssl enc -aes-256-cbc
>>>>>>>   -salt -pass file:/etc/backups/key.bin | aws s3 cp -
>>>>>>>   s3://XXXXXXX/servers/itdocs.160415.tar.gz.aes
>>>>>>> 
>>>>>>>   I was able to reverse the command and have it create a fresh
>>>>>>>   itdocs
>>>>>>>   folder full of goodies in a tmp folder. The key.bin file is 2048
>>>>>>>   bytes of randomness:
>>>>>>> 
>>>>>>>   openssl rand -base64 2048 -out key.bin
>>>>>>> 
>>>>>>>   Is this any good? The sample I had only used 128 and I thought
>>>>>>>   2048
>>>>>>>   would be better.
>>>>>>> 
>>>>>>>   I don't know how good this all is as backup encryption, but it
>>>>>>>   looks like it should be as good as most. I'm not sure how it's
>>>>>>>   going
>>>>>>>   to handle the larger backups, but I guess I'll find out on
>>>>>>>   Monday.
>>>>>>>   It's set to do half Saturday morning and half Sunday morning.
>>>>>>> 
>>>>>>>   On 2016-04-15 18:46, Zack Zatkin-Gold wrote:
>>>>>>>   I was about to say -- usually when you see malloc errors in a
>>>>>>>   piece
>>>>>>>   of
>>>>>>>   software, it's because that software is unable to allocate more
>>>>>>>   memory!
>>>>>>> 
>>>>>>>   On Fri, Apr 15, 2016 at 9:19 PM, <gandalf at sonic.net> wrote:
>>>>>>>   I think I found the problem. The method works for large files but
>>>>>>>   openssl
>>>>>>>   loads the entire file into memory and hence it needs one gigabyte
>>>>>>>   of memory
>>>>>>>   available for every gigabyte of file. This method isn't going to
>>>>>>>   work to
>>>>>>>   encrypt a 500gig file and indeed breaks on my two gig test
>>>>>>>   backup.
>>>>>>> 
>>>>>>>   Anybody have any suggestions for encrypting very large backup
>>>>>>>   files?
>>>>>>> 
>>>>>>>   On 2016-04-15 15:41, gandalf at sonic.net
>>>>>>>   <mailto:gandalf at sonic.net> wrote:
>>>>>>> 
>>>>>>>   I was looking for a way to encrypt files using a key or keys and
>>>>>>>   found
>>>>>>>   this article:
>>>>>>> 
>>>>>>> 
>>>>>>   https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399
>>>>>> 
>>>>>>>   [1]
>>>>>>> 
>>>>>>>   I tied it out and it worked, but oddly when I moved the keys to a
>>>>>>>   different folder openssl said it couldn't find them. Of course I
>>>>>>>   adjusted the encryption/description commands to point to the
>>>>>>>   proper
>>>>>>>   files. I moved them back to /root and suddenly they work.
>>>>>>> 
>>>>>>>   Here's the command the article says to use to create keys:
>>>>>>>   openssl req -x509 -nodes -days 100000 -newkey rsa:2048 -keyout
>>>>>>>   MyCompanyBackupsPRIVATE.pem -out MyCompanyBackupsPublicCert.pem
>>>>>>>   -subj
>>>>>>>   '/'
>>>>>>> 
>>>>>>>   Here's one of the errors I got:
>>>>>>>   root at vault:/etc/backups/tmp# openssl smime -in
>>>>>>>   itdocs.160415.tar.gz.aes -decrypt -binary -inform DEM -inkey
>>>>>>>   ../MSRI-Backups-PRIVATE.pem | tar -zx -f -
>>>>>>>   Error reading S/MIME message
>>>>>>>   139777656317600:error:07069041:memory buffer
>>>>>>>   routines:BUF_MEM_grow_clean:malloc failure:buffer.c:159:
>>>>>>>   139777656317600:error:0D06B041:asn1 encoding
>>>>>>>   routines:ASN1_D2I_READ_BIO:malloc failure:a_d2i_fp.c:242:
>>>>>>> 
>>>>>>>   gzip: stdin: unexpected end of file
>>>>>>>   tar: Child returned status 1
>>>>>>>   tar: Error is not recoverable: exiting now
>>>>>>> 
>>>>>>>   Moved the pem files back to /root and everything works great.
>>>>>>>   Although
>>>>>>>   I find this reassuring I also find it disturbing as these keys
>>>>>>>   are
>>>>>>>   for
>>>>>>>   encrypting backups and they may have to be manually typed in on a
>>>>>>>   new
>>>>>>>   system and used to restore an offsite backup from a disaster. I'd
>>>>>>>   like
>>>>>>>   to know that I can put these keys in folder and use them to
>>>>>>>   decrypt
>>>>>>>   backups.
>>>>>>> 
>>>>>> 
>>>>>>   Links:
>>>>>>   ------
>>>>>>   [1]
>>>>>>   https://blog.altudov.com/2010/09/27/using-openssl-for-asymmetric-encryption-of-backups/#comment-399
>>>>>> 
>>>>>>   [2] http://nblug.org/cgi-bin/mailman/listinfo/talk
>>>>>> 
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk



More information about the talk mailing list