Secure unattended decryption
I know it's sort of a contradiction in terms, but hear me out: The case I'm looking at is a High Availability environment hosting a database. The database is comprised of many Unix files, encrypted via AES, on shared storage. If the node accessing the database loses enough of its redundant hardware that it can no longer function as the database server, control must failover to the secondary node. Since the client systems are the priority, the goal is the shortest downtime possible. The encryption key for the databases is stored on-disk, encrypted with PGP (Gnupg specifically). At first startup, it's no big deal to have the DBA enter a passphrase to start the database server. Once a failover occurs, though, time is of the essence. Since paging someone to come enter a passphrase can take 15 minutes or more after-hours, I'm trying to come up with a feasible way to allow the second node to access the encrypted databases without human intervention, with the ultimate goal that if somebody does somehow walk out with the storage containing the databases, there will be no way to gain access to the data. I was thinking this could be done using gpg-agent, and entering the passphrase when the server starts up (and the failover can happen arbitrarily, months or even years after the machine boots). The problem I've encountered is that there doesn't appear to be a way to cache the passphrase infinitely. (I read some documentation that said that passing -1 to the cache-ttl parameters would work, but it doesn't). I've considered setting the cache-ttl parameters to large values (i.e. two weeks) and requiring the DBA to re-enter the passphrase once a week. This isn't ideal, but it's better than nothing. Does anybody here have any experience with this sort of situation? I realize that anything short of requiring a user with the passphrase at the terminal is inherently less secure, but uptime is king, and I'm looking for an "as secure as possible while not requiring human intervention in the event of a failover". -- Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure unattended decryption
On 3/18/2010 7:50 AM, Daniel Eggleston wrote: > ..., with the ultimate goal > that if somebody does somehow walk out with the storage containing the > databases, there will be no way to gain access to the data. Physically walk out? You could use some full disk encryption instead. And a lock on the server room door helps. ;-) Hypothetically? Like someone hacking ssh or nfs or something? Like you said, it's a bit of a contradiction. Now someone can just hack the nodes. (Or even the clients that are accessing the nodes. But they could probably do that now.) How specifically do you imagine someone stealing the data? signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure unattended decryption
On Thu, Mar 18, 2010 at 10:37 AM, Grant Olson wrote: > On 3/18/2010 7:50 AM, Daniel Eggleston wrote: > > ..., with the ultimate goal > > that if somebody does somehow walk out with the storage containing the > > databases, there will be no way to gain access to the data. > > Physically walk out? You could use some full disk encryption instead. > And a lock on the server room door helps. ;-) Hypothetically? Like > someone hacking ssh or nfs or something? Like you said, it's a bit of a > contradiction. Now someone can just hack the nodes. (Or even the > clients that are accessing the nodes. But they could probably do that > now.) > > How specifically do you imagine someone stealing the data? > > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > Well, the data theft truly is hypothetical - you see, the data will be stored on a SAN, so physical theft is an extremely minor probability (but still one that must be considered). Physical security will differ from client to client, since it will be implemented without my supervision. Full-disk encryption still requires that the DBA enter a passphrase at the time of mounting the disks and doesn't solve anything (and is less cross-platform, there may be many different flavors of Unix including HP-UX, AIX, and Linux); and encryption of just the databases allows the database application to optimize block-sizes (which differs from file to file based on the data types being stored). Hacking the nodes will be a risk regardless - anybody gaining root is game over, anyway. Once the database is mounted and accessed, PGP will no longer be required; what I am trying to accomplish is entering the PGP an arbitrarily long time before actually using it (i.e. infinite). In reality, this is a business requirement more than a philosophical one. The concern is : a) an unprivileged user with server access should not be able to access the actual database files (OS permissions) but, assuming they managed to gain access, the data should be useless. b) a hardware admin, if they manage to bypass physical security and walk out with the SAN, the data contained should be useless. Of course, somebody knows the passphrase, and there is an element of trust, but that's not really what's on trial here - as I said, it's a business requirement that stems from responsibility to clients. Thanks for the interest; I'm hoping somebody has done something similar to this in the past with regards to the unattended failover. -- Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure unattended decryption
Am 18.03.2010 12:50, schrieb Daniel Eggleston: [...] > > The encryption key for the databases is stored on-disk, encrypted with > PGP (Gnupg specifically). At first startup, it's no big deal to have the > DBA enter a passphrase to start the database server. Once a failover > occurs, though, time is of the essence. Since paging someone to come > enter a passphrase can take 15 minutes or more after-hours, I'm trying > to come up with a feasible way to allow the second node to access the > encrypted databases without human intervention, with the ultimate goal > that if somebody does somehow walk out with the storage containing the > databases, there will be no way to gain access to the data. I was > thinking this could be done using gpg-agent, and entering the passphrase > when the server starts up (and the failover can happen arbitrarily, > months or even years after the machine boots). > > The problem I've encountered is that there doesn't appear to be a way to > cache the passphrase infinitely. (I read some documentation that said > that passing -1 to the cache-ttl parameters would work, but it doesn't). > I've considered setting the cache-ttl parameters to large values (i.e. > two weeks) and requiring the DBA to re-enter the passphrase once a > week. This isn't ideal, but it's better than nothing. [...] You could create an encrypted partition/lvm volume/loopback device and put the key on it in plaintext. On boot-up, the DBA enters the password to unlock and mount the partition. After this, the key is protected by filesystem permissions. If someone walks out with the harddisk, all he has is an encrypted partition. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure unattended decryption
On 3/18/2010 11:59 AM, Daniel Eggleston wrote: > Full-disk encryption still requires that the DBA enter a > passphrase at the time of mounting the disks and doesn't solve anything > (and is less cross-platform, there may be many different flavors of Unix > including HP-UX, AIX, and Linux); and encryption of just the databases > allows the database application to optimize block-sizes (which differs > from file to file based on the data types being stored). > > Hacking the nodes will be a risk regardless - anybody gaining root is > game over, anyway. Once the database is mounted and accessed, PGP will > no longer be required; what I am trying to accomplish is entering the > PGP an arbitrarily long time before actually using it (i.e. infinite). > Not sure exactly what sort of database you're using, but gpg (to my knowledge) doesn't do block-level/random access. You can't just mount the database, stop using pgp, and write a block here and a block there. You need to use gpg to encrypt the whole file on each write and decrypt on each read. If you've got an uber-database on a SAN where there's lots of reads and writes, and DBA's are tuning block size and what not, it seems like the wrong tool for the job. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure unattended decryption
On 3/18/2010 2:43 PM, Grant Olson wrote: > On 3/18/2010 11:59 AM, Daniel Eggleston wrote: > > Not sure exactly what sort of database you're using, but gpg (to my > knowledge) doesn't do block-level/random access. You can't just mount > the database, stop using pgp, and write a block here and a block there. > You need to use gpg to encrypt the whole file on each write and decrypt > on each read. If you've got an uber-database on a SAN where there's > lots of reads and writes, and DBA's are tuning block size and what not, > it seems like the wrong tool for the job. > But if that is what you want to do: http://www.gnupg.org/faq.html#q4.14 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
FLISOL 2010 Costa Rica
Hello: I am Esteban Monge, I live in Costa Rica and help the Red Costarricense de Software Libre (RCSL). Sorry for my english... but I need help. The day of FLISOL (April 24, 2010) we want make a little web conference about GPG, the idea is make a little demo to firm mails o encrypt a transmission (very simple, because only we have 60 minutes), I want the presence of one GPG developer, if possible that speak spanish, but this is not a problem, I can find one traductor. I will use DimDim for the remote transmission, It is a little project to bring web conferences based in OpenSource, the expositor must have web cam and microphone. Thanks for your attention and great job. Original spanish text... Soy Esteban Monge de Costa Rica y colaboro para la Red Costarricense de Software Libre (RCSL). El día del FLISOL (24 de abril del presenta año) queremos dar una "charla técnica" de GPG, mi idea es hacer un pequeño demo de como hacer una firma para adjuntar en correo o encriptar comunicaciones (es algo muy simple solo se dispone de una hora), pero además de eso me gustaría contar con la presencia de algún desarrollador de GPG que pueda tener disposición para hacerlo y que lo haga en español... si no es posible en ese idioma veré como conseguir un traductor (es lo de menos). La persona no va a tener que estar presente, si tiene disponible un micrófono y una webcam sería posible que nos de la charla por medio de DimDim, un sitio web que utiliza software libre para hacer video conferencias (tiene dos modalidades una de pago y otra gratuita). La charla mas que toda seria introductoria y que explique un poco la historia de GPG, mas o menos que dure 20 minutos para usar los restantes en el demo de como hacer la firma. Les agradezco su atención y colaboración. -- http://nuevaeracr.blogspot.com Linux user number 478378 Linux machine number 386687 Tec. Esteban Monge Marín Tel: (506) 8379-3562 “No habrá manera de desarrollarnos y salir de la pobreza mientras los pocos negocios grandes de nuestro medio se entreguen a las economías foráneas y nosotros nos quedemos con solo negocios de pobre, mientras en vez de ser propietarios de nuestro propio país nos convirtamos en un ejército de empleados del exterior” José Figueres Ferrer, 1952. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Secure unattended decryption
Yea, I don't need to have it entered automatically at boot time (if that's possible, I've just thrown all semblance of true security out the window). All I was looking for is a way to have gpg cache the passphrase for an indefinite amount of time; and a human can enter the passphrase at boot. It sounds like gpg is probably not more qualified than any other encryption tool for this job, because the solutions thrown out here are quite feasible without gpg. On Thu, Mar 18, 2010 at 7:04 PM, Philipp Gühring wrote: > Hi Daniel, > > > I'm trying > > to come up with a feasible way to allow the second node to access the > > encrypted databases without human intervention, with the ultimate goal > > that if somebody does somehow walk out with the storage containing the > > databases, there will be no way to gain access to the data. > > Yes, exactly. So you have to bind the encryption key geographically to > your server-room. > > There are several possible ways to do this: > > You can use a USB Crypto-Token on a 3 meter USB cable, where the Crypto > Token is behind a wall in a second room (that is secured differently > from the server room), the cable goes through a small hole in the wall, > but does not allow to pull the token through the wall, and the other end > of the cable is plugged into the server in the serverroom. If an > attacker wants to take the server+storage from the server room, he has > to unplug the USB token, and can't take it with him, since it's not in > the same room. > > Another mechanism is Routing Security: > You setup full-disk encryption the primary server. In the bootloader / > initial ramdisk, you setup a SSH server on a special port. You make sure > that it isn't easily visible for a user on the screen when booting. > You then take a client, which could be on a second server somewhere else > in the building, or somewhere on the internet, and you make sure that > you have a somewhat physically secured routing infrastructure. The > client automatically regularly tries to contact the SSH server on the > fixed IP address that is routed to your datacenter/server. If it > succeeds to connect to the boot-SSH server, it automatically remotely > enters the private key / passphrase to decrypt the harddisk. > This way, if an attacker walks out with your server, he would also have > to walk out with the routed IP space, so that he can boot it up again. > It only boots automatically if it is in the right place. > > You can get some inspiration here, but I would not suggest to use it as is: > http://www.debian-administration.org/articles/579 > > > Best regards, > Philipp > > -- Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 13 Mar 2010 20:05:21 + MFPA wrote: >> I can't speak for other people, but I can for me. Take >> > a look at the UIDs on my key, which is >> > 0xC7C66ADF3DB6D884. And also, take a look at my master >> > key 0x2188A92DF05045C2 that I signed the other key >> > with. > >> > Each of those e-mail addresses on my keys are ones that >> > were already associated with my real name. I had given >> > each of those addresses to family, friends, associates, >> > businesses, or a combination of them. Not one of those >> > accounts had given me any anonymity, and each had been >> > shared outside of people I knew personally. > >> > By uploading a key with those addresses on it, does >> > that mean I gave up privacy that I already had? No. > > It looks to me as if the answer is "yes." Unless each person who had > one of your email addresses already knew the other addresses before > seeing them on your key, they now have extra information about you. > And the addresses have jumped from "shared outside of people [you] > knew personally" to published in a universally-accessible location. > However minor/negligible or unimportant you may consider it, that's a > reduction in privacy. You are, of course, assuming all of my contacts know what PGP is, how to use a keyserver, and have fetched and examined my key. Although I have potentially disclosed my e-mail addresses to the whole world, my actual disclosure has been less than had I posted those e-mail addresses to a web page or handed a copy of my key UIDs to whomever. But you know what? I don't care. I created those UIDs with the belief that if I shared them with one person, I shared them with the world. I intentionally made that information public, which is different from accidental disclosure. Also the use of a keyserver in my case was good, because I don't have any means of distributing my key electronically other than by e-mailing my key to every person that may request it. So a keyserver fits the way I want to work. - -Paul - -- Privacy is good. Use PGP. +-+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +-+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLox97AAoJEJhBiuhgbQLIgEAL/1hXd6DAMcX+goDdipUMt1Yd 5dqnSKbGsC0Rp9Ewa2aZTPzfb4AyAdhjugp+2oX17+47Ijz8CgRP5iCSzEwhW6gl JqKWrKL13f88vN97iauBI/TYiUoEBpMFvreYlu0X8g7qGK9WN1ul4SfFUNaBbXJt /OXfACs7PbSUSN8XvqprOHV+p9uAFNpLIjIYpKZpt4GzhjIF7ifg7fBSw8VdXXBI qahG0c6OqFBU10kJgZlHOM+ZSoqlS9B3M3DR54DLmgwNOhzFkOu5lgOpURY9FrZP 4XYt5hasn/FapiUh5qk8A0QRSLrXUyM7jgntK6KwIFHmurss+eyZRfxBnzveVVbR M2WM9k+AyQnpWwjpxeAR2qQAAjljBDj5TuAEYwlXw6dBb/eQAUcr3SmEdSUDx9BV Q2x37xMN5191xEYqVjNT5FtQko2wGCFSA4qWRbvi+DXV0KVGbTW1N2FBXLtQS1Gc QtndM+4MIf9UkLMnUYJriDnQmgOPiQmJAJzi8gnhuQ== =hLHd -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
