[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Encrypted Repositories. . .?

From: Thomas Harold <tgh_at_tgharold.com>
Date: 2007-06-21 06:29:32 CEST

Michael Williams wrote:
> Perhaps I'm asking the wrong question(s)? Basically I want to know the
> following:
> -- Can an application (regardless of OS) support encryption of all its
> activities -- disk writing, memory access, etc. without the need for the
> OS to dictate an encrypted environment?

Short answer - no. The long answer - encryption is easy, key management
is a royal PITA and near impossible to secure. (For most encryption
systems, assuming that the encryption algorithm isn't fundamentally
flawed, systems are typically cracked due to poor key management.)

I think you and your team need to spend some time with "Secrets and
Lies" by Bruce Schneier. "Practical Cryptography" may also be worth
reading, but may be too in-depth. The issue of why the svn:// protocol
has to store passwords in plain-text also applies (and why some of use
choose to use only svn+ssh:// URLs).

At this point, I see only a few possible solutions for you.

First, you need to put a monetary value on the source code if disclosed
to a third party. Just like when deciding how big the budget is for
backups and disaster recovery, you need to decide just how much you need
to spend to protect this asset. If you can't make a business case for
getting a dedicated server at a secure co-location or leased-box data
center, then the source code is not really worth protecting to the Nth
degree. And at some point, you need to have an administrator that you
can trust to have physical access to the box (or else you need to do it
yourself at a physical location that you have control over).

Second, an encrypted file system that gets mounted at boot-up (or before
being able to access the SVN repository) is the only solution that is
going to meet your needs. When you boot the box - you'll need to
provide the key for the file system before the O/S can mount it. This
means either typing it in at the keyboard or SSH'ing and entering the
passphrase that protects the encryption keys. As long as the box is
running, you're relying on file system permissions to protect the
repository. If someone swipes the box, all they get is a paperweight.

Again, with encrypted file systems - key management is the weak link.
Allowing the OS to mount the drive automatically gives anyone with root
access (or physical access to the box) the ability to get at the files.
  Which is why mounting encrypted drives has to be a manual process
where someone gives the server the key by hand.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 21 06:30:13 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.