Automounting an encrypted disk, without prompting for a password.

[theweaselking]

So I've got this USB disk, and a server running backups to the USB disk.

I want:
#1: The USB disk to be encrypted, so it requires a password (NOT a certificate or keyfile, if possible) to be mounted on any other computer.
#2: The USB disk to automatically be mounted on windows startup, without a user logging in, without anyone being prompted for a password, on THIS computer.

The professional paranoids who make TrueCrypt provide me with a host of options, but unfortunately not this option. The closest they come is a System Favourite Volume, which does exactly what I want *as long as the boot disk is, itself, encrypted*. And the problem with THAT is that a reboot then requires a password in order for the machine to come back up, which is not desirable in a server machine.

So!

What other options are out there?

EDIT: There are backup programs that can write to AES256-encrypted zip files, on a nonencrypted disk. That's maybe kinda sorta good enough? But I'd rather the whole disk be garbage without a password.

Comments

[pappy-legba.livejournal.com]

I assume you're aware of the command-line version of truecrypt and its /p flag, but it can't solve this problem.

I'm puzzled by the situation that would create this requirement, but you're probably exasperated enough about it without having to explain them again.

[theweaselking.livejournal.com]

#1: I want backups that aren't broken by a server reboot, for example from Windows Update.
#2: I want a server that boots on it's own without intervention, for example from Windows Update
#3: I want to be able to take the USB disk offsite (and replace it with a second disk) to allow for offsite backups that do not compromise the contents of the backups if the disk is lost or stolen or something.
#4: I want to be able to restore those backups on a different system in case of fire, motherboard failure, explosion, Grey Goo, or moose.

[pappy-legba.livejournal.com]

I think your moose coping strategies may be inadequate.

So.. write a batch/script that uses command-line Truecrypt to mount the file, then use one of the various tricks to run that script as a service so it executes before login.

[theweaselking.livejournal.com]

... yeah, that could work.

Requires storing the passphrase in plain text, but we've pretty much already given up on worrying about this if the HOST machine is compromised.

[pappy-legba.livejournal.com]

Aye, it's not perfect.

I don't know if there's any intelligent way to pipe data from encrypted storage to, say, a command line. Even if there was, it would be only a provide a small obstacle to an intruder, since one could rewrite the script/alter the target file to intercept the password. But then again, if the host is compromised they don't need the password-- they can read straight off the auto-mounted disk, yes?

[duskwuff.livejournal.com]

For the machine to be able to mount the drive without user input, it has to have the encryption key stored in some readable format. Whether that's a password, a key file, or a bag of chicken bones, it's some form of plain text anyway.

[skington.livejournal.com]

Yes, this. I'm confused as to why certificates etc. are undesirable - surely it would be a better thing to have a given certificate, key, or what have you, associated with the physical machine in question, that could be revoked or removed, rather than the machine having a copy of the plaintext password that controls everything?

Obviously once you've plugged the drive physically into the machine in question, to some degree all bets are off. Still, I'd prefer a solution where you could have multiple keys allowed to decrypt the backups, and you could say "OK, still let me read the contents of the drive, but don't let the (suspected or known to be hacked) machine with this key do anything".

[duskwuff.livejournal.com]

There's no way to do that with only an ordinary hard disk — they're just dumb data stores; they can't verify a certificate before allowing it to be used.

[theweaselking.livejournal.com]

What you do there is have software that checks the key/cert before decrypting the file. Windows disk encryption, a Truecrypt container, etc etc.

[duskwuff.livejournal.com]

If you can't trust the computer, the software running on it can't be trusted to check the certificate either. Such a "certificate" would just be a complicated way of representing a plaintext password.

[theweaselking.livejournal.com]

But we're not discussing a case where you can't trust the computer. Or at least I wasn't, but I can see how that could be what you meant in this thread.

[duskwuff.livejournal.com]

By "the computer", I mean "whatever computer happens to have gotten a copy of the certificate". If one computer can pass the checks and extract the password, another one can just as easily ignore the checks and extract the password anyway.

[theweaselking.livejournal.com]

It took me until this point to realise we've been talking right past each other and you're discussing the possibility of cert revocation mattering to stop the use of a compromised cert, versus "certificate as passphrase"

[theweaselking.livejournal.com]

Why a certificate/keyfile is less desirable:
* Because needing a specific key that cannot be reproduced if lost is less good than needing a password that can be typed in again.
* Because there's no easy way that I know of to say "any key signed by this authority is good"

And fundamentally:
* the purpose of this is not to protect the data from a hacker compromising the normal machine, it's to protect the disk itself from being read while offsite, except in the case of someone who knows the passphrase using this disk in a disaster recovery situation. The "sensitive" data is stored unencrypted on the host machine, and is available to the host machine while running. We're just trying to stick a nice big roadblock in the face of someone who steals the offsite backup disk.

[kafziel.livejournal.com]

The only thing I can think of is automating the login process on this computer, but that's pretty insecure if anyone can get access to your startup scripts.

[sbisson.livejournal.com]

I'd suggest that the answer is going to be a self-encrypting drive.

[theweaselking.livejournal.com]

Problem: No New Hardware. But a good thought.

[nsanity-au.livejournal.com]

Sadly this is the only way I see actually achieving this goal without introducing other risks.

What is your backup software of choice - given no new hardware costs, I assume this means alternate paid backup software is out too.

[jsbowden.livejournal.com]

I blame mhoye:

http://www.theverge.com/2013/3/4/4064574/nins-head-like-a-hole-mashed-with-call-me-maybe-is-perfect

[theweaselking.livejournal.com]

Doesn't play, even with scripting enabled. And I can't see a link to the player in the source.

Got a different link?

[theweaselking.livejournal.com]

Found it on Soundcloud. And, uh. Wow.