Re: Key management using a USB key
On Tuesday 08 March 2005 10:46, David Härdeman [EMAIL PROTECTED] wrote: o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? It seems that this part of your message hasn't been addressed. The best thing to do regarding encryption (IMHO) is to have an encrypted root file system. Boot from a USB device and have an initrd use dm-crypt to decrypt the root file system. A password is not adequate on it's own (anything you can remember can be brute-forced). Get a key from /dev/random and maybe have a password as well. The root file system can contain keys for /home and other file systems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Key management using a USB key
Hi David, o Other issues? it might also be interesting to take a look at a OpenPGP Smartcard. I am experimenting with such a card at the moment and they are quite cool. On [1] you can take a look at the features. A HOWTO for those cards will be available in the next days. o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? I know of someone who set up a solution so the crypto partitions will not be mounted if the smartcard is not plugged in. With best wishes, Matze 1. http://www.fsfe.org/card/ -- Join the Fellowship and protect your freedom! (http://www.fsfe.org) signature.asc Description: Digital signature
Re: Key management using a USB key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Am Do den 17. Mär 2005 um 14:13 schriebst Du:
o Especially on laptops, it might be interesting to also encrypt all of
/home and/or other parts of the harddrive to make the data unusuable
without the USB key. But how to integrate this with the other
requirements?
I know of someone who set up a solution so the crypto partitions will
not be mounted if the smartcard is not plugged in.
I made such a solution using cfs for my own laptop. I do that by
mounting a encrypted dir and then setting $HOME to the new home.
Unfortunable not all applications take care for $HOME. Most important
gimp or pan and some other.
I only do crypthome newhome to use it. The directory can be generated
by:
gpg --gen-random 2 16 | gpg --symmetric key.gpg
gpg key.gpg | cmkdir -b -- newhome
mv key.gpg newhome/..p
Here how I did this (part of .bashrc):
cryptmount()
{
if [ X$1 == X ]; then
echo Please specify a directory!
return 1
fi
if [ -d /crypt/$1 ]; then
echo Directory still mounted!
return 0
fi
if _testcrypt $1 $1.gpg; then
CDIR=$1
CPWFILE=$1.gpg
elif _testcrypt .$1 .$1.gpg; then
CDIR=.$1
CPWFILE=.$1.gpg
elif _testcrypt $1 $1/..p; then
CDIR=$1
CPWFILE=$1/..p
elif _testcrypt .$1 .$1/..p; then
CDIR=.$1
CPWFILE=.$1/..p
elif _testcrypt $HOME/$1 $HOME/$1.gpg; then
CDIR=$HOME/$1
CPWFILE=$HOME/$1.gpg
elif _testcrypt $HOME/.$1 $HOME/.$1.gpg; then
CDIR=$HOME/.$1
CPWFILE=$HOME/.$1.gpg
elif _testcrypt $1; then
CDIR=$1
CPWFILE=
elif _testcrypt .$1; then
CDIR=.$1
CPWFILE=
elif _testcrypt $HOME/$1; then
CDIR=$HOME/$1
CPWFILE=
elif _testcrypt $HOME/.$1; then
CDIR=$HOME/.$1
CPWFILE=
else
echo File $1 not found!
return 1
fi
if [ X$CPWFILE == X ]; then
cattach $CDIR $1
else
gpg $CPWFILE | cattach -- $CDIR $1
fi
return $?
}
crypthome()
{
cryptmount $1 || return 1
sleep 1
until [ -d /crypt/$1 ]; do
sleep 1
done
cd /crypt/$1 herehome
echo Home directory chaged to /crypt/$1.
}
Regards
Klaus Ethgen
- --
Klaus Ethgenhttp://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED]
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iQEVAwUBQjmSvZ+OKpjRpO3lAQKZgAgAg4u6ybSUfCCPMHm00fYSzsn+rLwi+/wp
h4m+W+vwdpPczYlkTxIKkmzLHXMdv0qnsUa37kijU4KdaVOvxQbsCcWdI3Z5yw9Q
lheUU06Zm6YNCJlm30Vavb+hhCxK1jGLrIAwb5AxeE4dtdBAGifjzauF9ilwOooN
Tq7Wqh27kn+v8VTsWzsqoLCBSLnn4YSnGHtTVqhkCiFWt6kMgiqzVcBLBfXdktIl
xKjNTE9Zn534G3yKcrxXY4SuUmANt+fliSt7WPPfXDgt8u6YG5cCpJQTjjXivTaC
4pm7IvpMpcY6bSqgDr5gZzeJ8tHEA7FKJOQjLFVBMelJ4Yz1EEE4PQ==
=zhfn
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Eric Dorland wrote: An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). gnupg 1.4 (as in sid) supports OpenPGP cards like the one I'm presently using (bought from g10code). The form factor is Chipcard-Reader+Chipcard, but it's there. Kind regards Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hi matthias, On Tue, Mar 15, 2005 at 08:02:34AM +0100, Matthias Urlichs wrote: - when gnupg releases an official version 2, james uploads a new gnupg that replaces the previous source package (or would it have to have the same name?), and generates all binary packages. That has been agreed to. i didn't see anything to that regard in the wnpp bug... do you have a pointer to somewhere that i could verify that? also, what about the library issue? assuming james is okay with it and there isn't some kind of library dependency issue, i'd gladly sponsor a gpg-agent. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi,
sean finney:
That has been agreed to.
i didn't see anything to that regard in the wnpp bug... do you have
a pointer to somewhere that i could verify that?
I talked with elmo about it in Barcelona, last December.
He basically said that, as long as it's understood that he gets the
package back once gnupg2 is released, he has no problem with it.
FWIW, Ubuntu already has the package, in essentially the same form I've
been uploading it to Debian last week. Guess who Ubuntu's ftpmaster is...
also, what about the library issue?
Which library issue? AFAIK the packages co-exist nicely.
assuming james is okay with it and there isn't some kind of library
dependency issue, i'd gladly sponsor a gpg-agent.
Umm, s/sponsor/push it through NEW already, dammit/ ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Key management using a USB key
hi, On Wed, Mar 16, 2005 at 01:39:44AM +0100, Matthias Urlichs wrote: also, what about the library issue? Which library issue? AFAIK the packages co-exist nicely. istr trying to build gpg-agent from the upstream source but the configure script would fail because i didn't have the appropriate version of one of the gpg-related libraries. the source package seems to build debs okay though, so at least i have something to play with... however, don't you think it's a little pre-emptive to have a gnupg2 binary package when they haven't yet released gnupg version 2? this smacks of the infamous redhat gcc release... assuming james is okay with it and there isn't some kind of library dependency issue, i'd gladly sponsor a gpg-agent. Umm, s/sponsor/push it through NEW already, dammit/ ;-) ah, sorry, can't help there. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi, David Hrdeman wrote:
o gpg-agent support in the same manner as ssh-agent would be neat. I
understand that this requires gnupg 2.0 though.
While gpg-agent is built from the gnupg 2.0 sources (a development
snapshot of which is currently sitting in the NEW queue ...), the agent
itself is perfectly useable with gnupg 1.2.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote: o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. While gpg-agent is built from the gnupg 2.0 sources (a development snapshot of which is currently sitting in the NEW queue ...), the agent itself is perfectly useable with gnupg 1.2. then i'm wondering why someone hasn't packaged it already :) sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi,
sean finney:
On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote:
o gpg-agent support in the same manner as ssh-agent would be neat. I
understand that this requires gnupg 2.0 though.
While gpg-agent is built from the gnupg 2.0 sources (a development
snapshot of which is currently sitting in the NEW queue ...), the agent
itself is perfectly useable with gnupg 1.2.
then i'm wondering why someone hasn't packaged it already :)
Because extracting it from gnupg2 source is *work*, and a package was
available for ages on my own server anyway.
Hopefully it'll be out of NEW sometime before Sarge...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Re: Key management using a USB key
Hi Sean! sean finney [EMAIL PROTECTED]: On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote: o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. While gpg-agent is built from the gnupg 2.0 sources (a development snapshot of which is currently sitting in the NEW queue ...), the agent itself is perfectly useable with gnupg 1.2. then i'm wondering why someone hasn't packaged it already :) Your fingers lie on a bloody wound. ;-) There was ITP #187548 for newpg, but was closed last summer. Please reopen it and make a package for newpg to make KMail-Users happy. see: Bug #280175 If you have not enough time, would you sponsor such package? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpzLYL0Ym2sL.pgp Description: PGP signature
Re: Key management using a USB key
* David Härdeman wrote: [...] o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. Should be no problem with quintuple-agent. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hi, On Mon, Mar 14, 2005 at 02:19:46PM +0100, Erik Schanze wrote: Your fingers lie on a bloody wound. ;-) There was ITP #187548 for newpg, but was closed last summer. aha. Please reopen it and make a package for newpg to make KMail-Users happy. If you have not enough time, would you sponsor such package? i would be willing to do so only if james thought it was okay (it's his package, so it's his call). i think what would need to be done would be something along the lines of: - create a source package gnupg2 - gnupg2 *only* produces package(s?) for the peripheral binar(y|ies) - when gnupg releases an official version 2, james uploads a new gnupg that replaces the previous source package (or would it have to have the same name?), and generates all binary packages. james: thoughts? also, istr seeing something about gnupg2 needing a new version of some library already present in debian. if that's the case, i don't think this will fly at all. that said, there's nothing wrong with hosting binary packages somewhere else and if you do so without breaking my system i'll try them and build support for gpg-agent into the keyloader scripts. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
Hi, sean finney wrote:
- create a source package gnupg2
exists
- gnupg2 *only* produces package(s?) for the peripheral binar(y|ies)
a binary for gnupg2 exists too, with a warning that it's not for public
consumption
- when gnupg releases an official version 2, james uploads a new gnupg
that replaces the previous source package (or would it have to have
the same name?), and generates all binary packages.
That has been agreed to.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Wednesday 09 March 2005 01:42, David Härdeman wrote: So the revocation could even be stored in cleartext on the usb key, unless I'm mistaken? Depending on the strength of the crypto/passphrase protecting your key, this could lead at least to a DOS if the revocation is publicised without compromising your keys. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Key management using a USB key
On Tue, 8 Mar 2005, sean finney wrote: you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. Prodding. :) Moreover I'd suggest to send the result of it as patch to the gpg package for inclusion into /usr/share/doc/gpg/examples . Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
* David Pashley | Ideally I want to keep the disk formatted as vfat so it is usable on | other operating systems and use an ext2 loopback filesystem. Getting the | system to mount that is the hard part. You could partition the usb key and have a small partition for GPG/SSH keys and the rest for normal data transfers and stuff. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Wed, 2005-03-09 at 11:34 +0100, Tollef Fog Heen wrote: You could partition the usb key and have a small partition for GPG/SSH keys and the rest for normal data transfers and stuff. I was going to do the same, but picked up a rediculously cheap tiny USB key, and only use it for this purpose. Then I protect it with my life... I have a larger vfat key that I use for transfers etc too.. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. [...] It would be very interesting to hear how others manage this... Ok, based on the script from Sean Finney and the feedback from the others (thanks all!). I've written a rough draft of how *I* would like things to work. It's divided into three parts, and also requires the keychain tool[1]. The first file, is a simple udev rule which creates a /dev/cryptdisk node when the appropriate usb key is inserted (proper as decided by the various conditions which one can list in a udev rule). It can be placed in /etc/udev/rules.d/cryptkey.rules. Then, a script which is run after the appropriate device node is created or removed. This script is plopped into /etc/dev.d/block/cryptdisk.dev. This script mounts the drive, checks who it belongs to (by reading the keyowner file in the root dir of the USB key), mounts it again with the proper permissions for that user and then calls the third piece. The third script, which is run as the user who owns the key, loads the ssh keys from the usb key and into ssh-agent. The advantage is that this script can also be called from eg. .xsession to load keys from usb devices which were already present during boot. It also allows one to load keys even if X isn't running. The scripts are a bit rough at the moment, I wrote them in a hurry, but I'll clean them up a bit more later, I wanted to get something through the door. They work-for-me right now (loading keys, with ssh-askpass dialogue, and removing them when the usb key is removed). I'll work more on the scripts during the weekend (adding some of the TODO's, documentation). Regards, David [1] http://www.gentoo.org/proj/en/keychain/index.xml [2] http://www.hardeman.nu/~david/keyload/ PS Right now, the scripts are licensed under a david-owes-sean-a-pizza license =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On 07-Mar-05, 17:46 (CST), David H?rdeman [EMAIL PROTECTED] wrote: o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? While you might store the revocation certificate (RC) on *a* key, I certainly wouldn't store it on *the* key. If you lose the usb key with the gpg keys, you do want to be able to revoke them, right? Since the RCs are not something I need regularly, I put mine on a couple of CDs, and printed a copy (worst case). Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 2005-03-08 at 00:46 +0100, David Härdeman wrote: first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I use a very small USB key for my gnupg and ssh keys. I had created the .gnupg and .ssh directories in my home a long time ago, so I formatted the USB device as ext2, and copied the two directories to the USB device as ssh and gnupg. In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. So, when I stick the dongle into the USB slot, the drive is automatically mounted, and the symlinks point to my real key directories. When the key is out of the machine, my keys are safe offline. HTH Ben
Re: Key management using a USB key
On Tue, 2005-03-08 at 14:58 +, Ben Hill wrote: In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. It has to be said, this method isn't the most secure method by any means, and I'm interested to hear other's approaches. Cheers, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Op di, 08-03-2005 te 14:58 +, schreef Ben Hill: On Tue, 2005-03-08 at 00:46 +0100, David Hrdeman wrote: first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I use a very small USB key for my gnupg and ssh keys. I had created the .gnupg and .ssh directories in my home a long time ago, so I formatted the USB device as ext2, and copied the two directories to the USB device as ssh and gnupg. In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. So, when I stick the dongle into the USB slot, the drive is automatically mounted, and the symlinks point to my real key directories. When the key is out of the machine, my keys are safe offline. This is also approximately how I manage this (or did, my key broke yesterday and I haven't got a new one yet). The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 02:58:41PM +, Ben Hill wrote: In my home directory I create a symlink for /media/usbkey/ssh - ~/.ssh and /media/usbkey/gnupg - ~/.gnupg. One can also use the --home flag to gpg. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 It's sex! Sex is the game! Marriage is the penalty. --Andrew Wyke (Sleuth) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 04:07:02PM +0100, Wouter Verhelst wrote: The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. Lovely idea. No need for rebuilding the trust path in the USB key. -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 I'm a mog: half man, half dog. I'm my own best friend! --Barf (Spaceballs) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 2005-03-08 at 16:07 +0100, Wouter Verhelst wrote: The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. That's a nice idea. I might use that for the .ssh too, leaving known_hosts to be synchronized using another method. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Wouter wrote: Op di, 08-03-2005 te 14:58 +, schreef Ben Hill: So, when I stick the dongle into the USB slot, the drive is automatically mounted, and the symlinks point to my real key directories. When the key is out of the machine, my keys are safe offline. This is also approximately how I manage this (or did, my key broke yesterday and I haven't got a new one yet). The only difference is that, rather than symlinking ~/.gnupg, I symlink ~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which allows me to safely remove it while still mounted; my trustdb and public keyring are synchronized in other ways. Yep, exactly how I do it too. It works well - after all, you rarely (if ever) need to update the contents then. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop -- Vivek Dasmohapatra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Mar 08, 2005 at 14:58, Ben Hill praised the llamas by saying: On Tue, 2005-03-08 at 00:46 +0100, David Härdeman wrote: first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I use a very small USB key for my gnupg and ssh keys. I had created the .gnupg and .ssh directories in my home a long time ago, so I formatted the USB device as ext2, and copied the two directories to the USB device as ssh and gnupg. Ideally I want to keep the disk formatted as vfat so it is usable on other operating systems and use an ext2 loopback filesystem. Getting the system to mount that is the hard part. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, 2005-03-08 at 15:41 +, David Pashley wrote: Ideally I want to keep the disk formatted as vfat so it is usable on other operating systems and use an ext2 loopback filesystem. Getting the system to mount that is the hard part. I initially had my stuff stored on a VFAT partition, and that caused issues with file locks. I do have my entire ~/.ssh and ~/.gnupg on there, but if it were a read only link to the private key, that probably isn't an issue. -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 02:30:06AM -0500, sean finney wrote: well, me wanting to do things the right way it ended up being a pretty long script and i didn't think the list would appreciate random shell scripts flying around. but, i'll go ahead and put it online: http://www.seanius.net/linux/keyloader/usb-storage Thanks Sean and everyone else for contributing. Based on the above script and the suggestions from everyone else, I've got a basic idea of how I'd want this to work: o usb key contains a vfat filesystem with two special files, one names the user for the keychain, while the other is a storage file to be used as a loopback drive. o use the keychain script sean mentioned to keep one ssh-agent running per user no matter how many sessions (which has other advantages than those relating to usb key management). o when the usb key is inserted, the user is prompted for a password to the encrypted loopback file which is then mounted, the ssh keys within are fed to ssh agent, and the file is unmounted again. Pros: o the ssh key only exists in the memory of the ssh agent (except for a short time period when the loopback file is mounted) o hopefully, in combination with libpam-usb and/or libpam-mount, it would be possible to reduce the number of password prompts to one. o vfat filesystem means that the key is usable on most OS:es (as a normal data carrier) and that it can be easilly backed up and recreated. Meanwhile the loopback file allows for the features one expect in a unixy system such as proper permissions etc. Cons: o Only I've come up with so far is that there will be some dependencies which might not be available on any host computer. And that the keys wont be usable at all should one need to use them on a windows computer (if they are locked into a ext2-loopback file that is). Bonus stuff: o It would be a neat trick to have the keys which were once loaded from the usb key into the ssh agent automatically removed from the agent when the key is removed from the computer (meaning you could quickly yank the key, go for lunch, return, reinsert it and continue working). o gpg-agent support in the same manner as ssh-agent would be neat. I understand that this requires gnupg 2.0 though. o check both at insertion time and at first login time for the usb key (so that the key can be either inserted from boot or inserted during an existing session). I'll probably keep the main vfat partition mounted for access to general data stored on the key while it is inserted, a neat trick would then be to automatically remove the keys from the ssh agent which were once upon a time loaded I have started working on some scripts to do the above. Currently, they consist of three parts: o a udev rule file which gives a special device node to the usb key o a /dev/udev.d file which is run after the node is created that does the necessary root-level setup and then calls o a user-specific script which loads the keys (and prompts for necessary passwords) etc. I think this setup should allow all the bonus stuff to be implemented as well. The only real problem I've found so far is bug 290324 (http://bugs.debian.org/290324) which makes it hard to have user-mounted-dm-crypt-over-loopback-device goodness, and the patch attached to that bug seems to have bitrotted a bit. I'll get back to you when I have something real to show. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 07:29:20AM -0600, Steve Greenland wrote: On 07-Mar-05, 17:46 (CST), David H?rdeman [EMAIL PROTECTED] wrote: o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? While you might store the revocation certificate (RC) on *a* key, I certainly wouldn't store it on *the* key. If you lose the usb key with the gpg keys, you do want to be able to revoke them, right? Since the RCs are not something I need regularly, I put mine on a couple of CDs, and printed a copy (worst case). Sorry, I was being vague. I did of course intend to have the revocation certificates on the key in *addition* to alternative forms of storage. My concern was rather if there was any problems with this. As far as I can understand, all that a malicous persom who found the key could do with the revocation cert would be to revoke my gpg key right?...which would not be a problem as I would have to assume the worst and perform the revocation anyway should the usb key be lost. So the revocation could even be stored in cleartext on the usb key, unless I'm mistaken? Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hello, On Wed, Mar 09, 2005 at 01:38:22AM +0100, David Härdeman wrote: o when the usb key is inserted, the user is prompted for a password to the encrypted loopback file which is then mounted, the ssh keys within are fed to ssh agent, and the file is unmounted again. you could easily extend the script i wrote to unencrypt/loop-mount a filesystem-in-a-file without too much effort. prod me enough and i might do it myself. o hopefully, in combination with libpam-usb and/or libpam-mount, it would be possible to reduce the number of password prompts to one. you should only need a password for encrypted things. since the hotplug script runs as root you can have that take care of all the other details. so, as long as you have either an unencrypted ext2 filesystem-file with encrypted ssh-keys or vice versa, you should only need one password. Bonus stuff: o It would be a neat trick to have the keys which were once loaded from the usb key into the ssh agent automatically removed from the agent when the key is removed from the computer (meaning you could quickly yank the key, go for lunch, return, reinsert it and continue working). my script already does this. in fact, it's selective enough to leave other keys that it didn't load still in memory. this was a little tricky to accomplish, and is done by copying the public key into a temporary location (under /var/cache/keyloader/pubkeys/$USER), and when the device is removed those keys are passed to ssh-add -d. o check both at insertion time and at first login time for the usb key (so that the key can be either inserted from boot or inserted during an existing session). that would be nice, though a quick workaround is to remove and re-insert the key :). o a /dev/udev.d file which is run after the node is created that does the necessary root-level setup and then calls o a user-specific script which loads the keys (and prompts for necessary passwords) etc. better watch out where root and the user cross paths... sean -- signature.asc Description: Digital signature
Key management using a USB key
Hi all, first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. Things which I've considered so far: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? o Password entry, it's a hassle to enter 10 different passwords, what would be the best way to reduce the number of password entries? dm-crypt to mount an encrypted file on the USB key and then have the gpg and ssh keys unencrypted within? The login to X/console etc could then maybe be performed using libpam-usb [1] so that only the password for the dm-crypt filesystem is needed? o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? o Automagic setup. Hopefully, some scripts in conjunction with udev/hotplug/pmount/whatever could make everything just work (tm) when the key is inserted. o USB key removal, how should it be handled if the key is physically removed during a session? Maybe kill the agents and run xscreensaver until the key is reinserted... o Permissions, how are these handled when the key moves between systems where my userid might differ? o Other issues? It would be very interesting to hear how others manage this... Kind regards, David [1] http://bugs.debian.org/234134 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. sean -- signature.asc Description: Digital signature
Re: Key management using a USB key
On Tue, Mar 08, 2005 at 12:46:59AM -0500, sean finney wrote: On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Key management using a USB key
An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). * David H?rdeman ([EMAIL PROTECTED]) wrote: Hi all, first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. Things which I've considered so far: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? o Password entry, it's a hassle to enter 10 different passwords, what would be the best way to reduce the number of password entries? dm-crypt to mount an encrypted file on the USB key and then have the gpg and ssh keys unencrypted within? The login to X/console etc could then maybe be performed using libpam-usb [1] so that only the password for the dm-crypt filesystem is needed? o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? o Automagic setup. Hopefully, some scripts in conjunction with udev/hotplug/pmount/whatever could make everything just work (tm) when the key is inserted. o USB key removal, how should it be handled if the key is physically removed during a session? Maybe kill the agents and run xscreensaver until the key is reinserted... o Permissions, how are these handled when the key moves between systems where my userid might differ? o Other issues? It would be very interesting to hear how others manage this... Kind regards, David [1] http://bugs.debian.org/234134 -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Key management using a USB key
On Mon, 7 Mar 2005 21:52:31 -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Mar 08, 2005 at 12:46:59AM -0500, sean finney wrote: On Tue, Mar 08, 2005 at 12:46:46AM +0100, David Härdeman wrote: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. I would suggest putting the script in the Debian wiki. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Key management using a USB key
Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. Yep. Seconded. This is exactly what I was thinking while seeing this thread : let's watch it and learn how my fellow DD and Debian contributors handle this and improve the (certainly very bad) way I have to handle this myself. A few months ago, I got my hands on a few USB encryption keys (or whatever these things are callediKey stuff for instance) and imagined I could store sensitive data there. I look vaguely at things which are supposed to handle these in Linux (PC/SC stuff and such things)...but, well, this was quite obscure and I finally gave up. But I still have a few of these keys...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
hi, On Mon, Mar 07, 2005 at 09:52:31PM -0800, Steve Langasek wrote: i have a usb/hotplug/ssh-add script that loads an ssh key off of a usb stick, and removes it when the usb stick is removed. if you're interested i can send you a copy off-list. Any reason not to post it on-list? I was hoping to improve the security/usability of my own setup based on the best practices offered up in reply to this thread. well, me wanting to do things the right way it ended up being a pretty long script and i didn't think the list would appreciate random shell scripts flying around. but, i'll go ahead and put it online: http://www.seanius.net/linux/keyloader/usb-storage how it works: - plop the script in /etc/hotplug/usb/ - copy your public/private keys onto a usb disk, list them in ~/.keyloader (KEYS=key1 key2, read script comments for more info) - plug in the usb disk - ssh-add xterm (or ssh-askpass if you have it installed) pops up if it needs a passphrase, and your key is loaded - remove the disk - key is unloaded. i think the approach i take is fairly sound securitywise, but i'd appreciate someone else taking a look at it. also, i'm not sure whether it still works on 2.4 kernels, i haven't had a 2.4 machine to test on in a while. sean -- signature.asc Description: Digital signature
