# Mutual off site storage security? [RESOLVED]

## -=GGW=- $ol!d $n4>|e

Hello, unsure whether this is best posted here or on OTW happy to move or remove and repost if this is the wrong section. 

My brother and I are thinking about secure ways to set up off-site storage for eachother. The baseline is a raid 1 NAS in eachothers homes that is externally visible. (were not tied to any hard drive format etc but would like for the enclosures to be fairly cheap and have redundant / reliable error checking and notification of any failure) 

We're both out of our element when trying to figure out how to encrypt the hard drives securely though. Ideally we would like to have a scenario where if one location is comprimised, those with access can not view the information hosted there as off-site storage for the other.

Any breadcrumbs to follow or suggestions would be welcome!   :Smile: Last edited by -=GGW=- $ol!d $n4>|e on Sat Apr 28, 2018 12:44 am; edited 1 time in total

----------

## bunder

Once zfs gets all the bugs worked out for encryption and raw send/receive, it might be a viable option... but it requires zfs on both sides.  I guess you could technically get the same done with tarballs and ecryptfs.

----------

## msst

 *Quote:*   

> Ideally we would like to have a scenario where if one location is comprimised, those with access can not view the information hosted there as off-site storage for the other. 

 

I am not really sure what you mean by this sentence. What do you mean with "one location is compromised?".

Do you want a user encryption that is totally independant of the root user on that system? This is not really possible with traditional means because as soon as the user is logged in remotely and accessing its encrypted stuff also root can read it one way or the other. You can set it up so that root cannot read it when the user is not logged in / not accessing the data. But the root user will always be able to place a trojan and intercept the next login, so compromised means compromised. Those with physical access can get your data if they can get you to unlock your data while they control the system.

The only way around this is to run the whole encryption on the user side and use the remote data storage only as a sort of container. e.g. you use a network file system (Whether nfs, samba, sshfs does not matter much) and mount a user-fs such as EncFs over it. This sure has both some speed and compatibility implications, but may work ok for you.

In this case even the root user on a compromised remote storage cannot see the content of what you are storing. They can see the files / size / modification dates however and also credentials you need to access the network-fs, but this is separate from the content encryption then, which runs entirely on the client side.

----------

## Hu

Please describe your threat model in more detail.  There are a few common scenarios:"Compromise" means that a standard burglar powers down and takes the storage.  He inspects it at a later date looking for personal information to use in furtherance of other crimes (identity fraud, blackmail, unauthorized access to existing financial accounts, etc.) or sells it to another criminal who will do so."Compromise" means that the location is raided by the government and the hardware is seized.  Prosecutors later search the drive for information used to incriminatethe owner of the hardware orthe owner of the data"Compromise" means an unauthorized individual gains remote (and likely undetected, at least for a few days) access to the fileserver, enabling him/her to upload/download any unprotected content at will.Scenarios 1 and 3 are the most popular, but have very different solutions.  Scenario 2 is a variant of scenario 1, but is harder to fight because of the non-technical resources that most governments can use.

----------

## szatox

I think the solution you want is "encrypt data on your end, send the encrypted version off-site"

This will keep you covered against most cases of compromised off-site, since access to the remote site only is not sufficient for the potential attacker to understand your data.

The downside is, encrypted data that can't be understood by the remote hardware can't be handled in any smart way, so you don't have many corners to cut for sake of efficiency.

----------

## -=GGW=- $ol!d $n4>|e

Apologies for the ambiguity of the question. Here's the scenario better explained.

The goal is to have storage that is 

1) Off-Site

2) Publicly Discoverable

3) encrypted

4) efficient to synchronize and access each file / document individually

5) has reasonable warnings of approaching hard drive failure and redundant copies

5) The storage is protected / reasonably resilient with respect to.

 - The case where the off site storage location is burgled

 - The case where a bad actor obtains access to the off site storage location and network traffic between

 - To some extent the case that the government seizes the off site storage.

Now I know because I reside in the U.S. its a false sense of security to think data is not obtainable by the government. I believe you can be charged for withholding evidence if you withhold the encryption key to encrypted data. There are also super computers the government may or may not have at it's disposal that may or may not be able to break standard encryption. However, being reasonable secure against external visibility would provide some barriers or protections in that the government force must both prove it is your storage beyond a reasonable doubt and prove that they have reasonable suspicion of the data there-in to warrant forced disclosure. Given the deterrence, it would be nice to be as protected against government intervention as possible

Also, I just want to add for the sake of it. There's nothing super nefarious about what I intend to store but I've become aware of how much self censorship I've been doing just talking through insecure channels to those I know online that the more secure I am in my data, the more true I'll be to my curiosities and ambitions. Just knowing my data is not safe affects what I store and that sucks!

Hopefully that clarifies things and thanks for the feedback so far. I've considered the encrypting locally and transferring to the remote destination however, in that instance. Talking at the scale of ~2Tb of data over consumer cable speeds, it's not very realistic / wouldn't be kept up to date in a reasonable time frame. I've considered hashing the file names and then encrypting the contents and sending each one of those but I'm unsure of what sort of security concerns that brings about or to what extent that weakens my encryption, It definitely lowers the starting entropy available for any encryption algorithm for each file.

I'm unaware of ZFS's buil't in encryption capabilities or the existing bugs but am digging into that now! For the most part I've stuck with ext4 prior to that reiserfs, prior to that ext3. I did a small stint of btfs but found it super unstable. So, as far as experimental fs are concerned, i'm very worried about data corruption.

----------

## 1clue

I hate to be "that guy" but have you considered dropbox.com?

----------

## msst

For most of the things you want any simple remote unix box with (full-)HD encryption and a ssh installation will do. Most linux based NAS can even do this easily.

 *Quote:*   

> 1) Off-Site
> 
> 2) Publicly Discoverable
> 
> 3) encrypted
> ...

 

Use ssh-fs to mount/access the drives. Convenient and the performance is even quite ok. Set this up via public-key auth then it is rock safe and fully automatic. There are also standalone clients to connect even from windows. rsync can run over ssh and sync this. unison can do sane two-way syncs.

 *Quote:*   

> 
> 
> 5) The storage is protected / reasonably resilient with respect to.
> 
> - The case where the off site storage location is burgled
> ...

 

No burglar has the time or sophistication to live-hack the box. Most police forces neither. Unless you get top priority by the FBI they will power down the thing and take it with them. The encrypted data is then inaccessible for them. The typical dm-crypt setups are cryptographically quite hardcore already. ssh over the network encryption also very save.

Only someone who spends serious time and effort to hack into the box live and obtain root access can get to the data. Or powering it down and inserting some trojan stuff into the boot process and waiting for you to power up again. Ask yourself if these scenarios are something you need to protect against. If so I would use encfs over ssh-fs stacked or similar. In that case only the security of your home box has to be guarded. The remote end is then only storing useless data chunks.

 *Quote:*   

>  I did a small stint of btfs but found it super unstable.

 

I am using btrfs widely now and the instabilities seem to be an unfortunate problem of the past.

----------

## gentoo_ram

There is a package called 'duplicity' that is designed to do the type of encrypted off-site storage I believe you are looking for.  I have used it in the past.  It supports incremental backups as well.

http://duplicity.nongnu.org

----------

## -=GGW=- $ol!d $n4>|e

thanks all for your feedback i've ended up going with the solution for msst for my on site backup and using duplicity for offsite. Really helps a lot to get feedback from you guys about what is actually sane.  :Smile: 

----------

