Re: USB key requirement.
Dan Serban wrote: > On Wed, 12 Jan 2011 04:46:41 -0800 (PST) > Emanoil Kotsev wrote: > >> >> >> --- On Tue, 1/11/11, Dan Serban wrote: >> >> >> > >> > I figured that after the root partition is mounted (nfs), I >> > would have >> > an init.d script that would work its magic.. if it's there, >> > allow the >> > continuation of the boot sequence (load gdm and other >> > non-essential >> > services). All I would require is to match against an >> > encrypted key >> > without user intervention. >> >> In fact if using PXE you don't really pay attention on security - I'm >> wondering what good means the usb key in this case. > > Well, not exactly, PXE simply boots the system. I can understand your > point if you're talking about the data that travels over the wire. > Well that's fine, it needs to be physically accessed by a machine that > is "allowed", if allowed, then the USB key also needs to check out to > continue the boot sequence. Hence why I was asking to do such a > thing. It's low security, but it requires my car keys to be at home > with me to actually use this machine. USB key, plus a login sounds > good enough. So if someone found out my username/password, they'd > still need the key to be present and matched to a specific workstation. well I would unplug the network cable and provide another bootfile to the device to boot from. wan't be too hard. >> >> I would put a customized initrd file on the usb and boot from there >> >> > >> > > Q: Do you have a keyboard and is it desirable to use >> > it on boot time? >> > > Or you want just to plugin and if the right usb is >> > inside the boot >> > > will go on. you can do this after the system has >> > already booted and >> > > you can access the usb from the diskless station. >> > >> > Second option, no keyboard interaction is required in my >> > mind. If you >> > miss having the usb stick inserted, then to move forward, >> > hit the reset >> > button. >> >> In your mind or in the specific case? >> > > There is no specific case as I'm just inquiring about the possibility > of doing such a thing. there is a specific case, which is your case. I can not reveal specific details, about my job, but in your case it does not make sense to use a usb key for security in my opinion. there should be another safety mechanism to prevent using the device. > >> >> > > Q: have you heard of security >> > > dongles >> > > "http://www.naturela-bg.com/index.php?categ=&page=itm&lang=en&id=45&pid=&p="; >> > > >> > >> > I have heard of them, but I don't personally understand the >> > actual >> > difference of a specialized key, versus a usb block device >> > with an >> > encryption file on it. >> >> Well this is exactly what you are trying to do - the one link I >> posted I was the first that popped up in google and supports linux. >> >> This is not a USB stick but a piece of hardware you plug in on the >> usb slot. You can do much more (programs can be banned from starting >> etc) >> >> anyway over PXE (TFTP) everything is open and security is pretty week >> - I don't think a USB stick is really necessary to secure something. > > It's not to secure anything, it's to ensure I'm present, or the key > actually is physically present. I don't want to modify _any_ data > through the key at all. but any one could boot the device with an ordinary live-usb linux, no? > >> What happens if the user plug ins instead your USB stick a normal >> live USB ubuntu i.e. It will boot, the NFS shares can be mounted >> (cause you authenticate on system level) and the sense of some >> security is gone. > > Well, the key would be checked right after the block device is > mounted. NFS or local is irrelevant no? How can you drop to a shell > after the block device is mounted and the first S01 asks for the key to > be inserted? by booting with a live-usb or modifying your boot command line parameters > >> With PXE boot you have to use other security methods I think. >> > > PXE is just the boot method. The only reason I mentioned it, is to > draw the complete picture. The block device is irrelevant, the fact > that I depend on a local DHCP/TFTP/NFS server to function means nothing > regarding physical access. It's simply a physical limitation. The NFS > share it's booting from is encrypted. If you know how to physically > type in my username and password, you'd still need my key to do so. > Otherwise I can't think of another way to add some semblance of > security/obscurity. Neither tftp nor nfs are secure. This is my point. I thought one can only export directory in nfs. How is it encrypted? the easy way in my opinion I would use a live-usb and modify it so that it opens ssh tunnel to your server. The you have 2 option either use local X or login to the server. a better way in my opinion I would use an open network from a DMZ to offer the bootfile (tftp with readonly and no login) and vpn in a second network to mount the nfs. So I would create a custo
Re: USB key requirement.
On Wed, 12 Jan 2011 04:46:41 -0800 (PST) Emanoil Kotsev wrote: > > > --- On Tue, 1/11/11, Dan Serban wrote: > > > > > > I figured that after the root partition is mounted (nfs), I > > would have > > an init.d script that would work its magic.. if it's there, > > allow the > > continuation of the boot sequence (load gdm and other > > non-essential > > services). All I would require is to match against an > > encrypted key > > without user intervention. > > In fact if using PXE you don't really pay attention on security - I'm > wondering what good means the usb key in this case. Well, not exactly, PXE simply boots the system. I can understand your point if you're talking about the data that travels over the wire. Well that's fine, it needs to be physically accessed by a machine that is "allowed", if allowed, then the USB key also needs to check out to continue the boot sequence. Hence why I was asking to do such a thing. It's low security, but it requires my car keys to be at home with me to actually use this machine. USB key, plus a login sounds good enough. So if someone found out my username/password, they'd still need the key to be present and matched to a specific workstation. > > I would put a customized initrd file on the usb and boot from there > > > > > > Q: Do you have a keyboard and is it desirable to use > > it on boot time? > > > Or you want just to plugin and if the right usb is > > inside the boot > > > will go on. you can do this after the system has > > already booted and > > > you can access the usb from the diskless station. > > > > Second option, no keyboard interaction is required in my > > mind. If you > > miss having the usb stick inserted, then to move forward, > > hit the reset > > button. > > In your mind or in the specific case? > There is no specific case as I'm just inquiring about the possibility of doing such a thing. > > > > Q: have you heard of security > > > dongles > > > "http://www.naturela-bg.com/index.php?categ=&page=itm&lang=en&id=45&pid=&p="; > > > > > > > I have heard of them, but I don't personally understand the > > actual > > difference of a specialized key, versus a usb block device > > with an > > encryption file on it. > > Well this is exactly what you are trying to do - the one link I > posted I was the first that popped up in google and supports linux. > > This is not a USB stick but a piece of hardware you plug in on the > usb slot. You can do much more (programs can be banned from starting > etc) > > anyway over PXE (TFTP) everything is open and security is pretty week > - I don't think a USB stick is really necessary to secure something. It's not to secure anything, it's to ensure I'm present, or the key actually is physically present. I don't want to modify _any_ data through the key at all. > What happens if the user plug ins instead your USB stick a normal > live USB ubuntu i.e. It will boot, the NFS shares can be mounted > (cause you authenticate on system level) and the sense of some > security is gone. Well, the key would be checked right after the block device is mounted. NFS or local is irrelevant no? How can you drop to a shell after the block device is mounted and the first S01 asks for the key to be inserted? > With PXE boot you have to use other security methods I think. > PXE is just the boot method. The only reason I mentioned it, is to draw the complete picture. The block device is irrelevant, the fact that I depend on a local DHCP/TFTP/NFS server to function means nothing regarding physical access. It's simply a physical limitation. The NFS share it's booting from is encrypted. If you know how to physically type in my username and password, you'd still need my key to do so. Otherwise I can't think of another way to add some semblance of security/obscurity. > regards > > > > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110113163316.58ad6...@ws82.int.tlc
Re: USB key requirement.
Stefan Monnier wrote: > Real smartcards probably don't work the way I described, but I hope it > gives you some idea of how a smartcard can be different from a plain USB > mass storage holding a secret key. smart card is really different, but the idea is the same - implemented in the dongles, only it applies to a local computer ... when you don't want to enter passwds all the time etc. The suggestion to use the UID of the disk (or partition) as authentication is enough for you I guess. Also I would put it in the initrd. If the user had a keyboard s/he could hack it, so that's why I've asked why do you need this? Perhaps it's really better to use usb smart card for authentication or the dongles mentioned before regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/igkrum$rk...@dough.gmane.org
Re: USB key requirement.
--- On Tue, 1/11/11, Dan Serban wrote: > > I figured that after the root partition is mounted (nfs), I > would have > an init.d script that would work its magic.. if it's there, > allow the > continuation of the boot sequence (load gdm and other > non-essential > services). All I would require is to match against an > encrypted key > without user intervention. In fact if using PXE you don't really pay attention on security - I'm wondering what good means the usb key in this case. I would put a customized initrd file on the usb and boot from there > > > Q: Do you have a keyboard and is it desirable to use > it on boot time? > > Or you want just to plugin and if the right usb is > inside the boot > > will go on. you can do this after the system has > already booted and > > you can access the usb from the diskless station. > > Second option, no keyboard interaction is required in my > mind. If you > miss having the usb stick inserted, then to move forward, > hit the reset > button. In your mind or in the specific case? > > Q: have you heard of security > > dongles > > "http://www.naturela-bg.com/index.php?categ=&page=itm&lang=en&id=45&pid=&p="; > > > > I have heard of them, but I don't personally understand the > actual > difference of a specialized key, versus a usb block device > with an > encryption file on it. Well this is exactly what you are trying to do - the one link I posted I was the first that popped up in google and supports linux. This is not a USB stick but a piece of hardware you plug in on the usb slot. You can do much more (programs can be banned from starting etc) anyway over PXE (TFTP) everything is open and security is pretty week - I don't think a USB stick is really necessary to secure something. What happens if the user plug ins instead your USB stick a normal live USB ubuntu i.e. It will boot, the NFS shares can be mounted (cause you authenticate on system level) and the sense of some security is gone. With PXE boot you have to use other security methods I think. regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/43634.99072...@web161208.mail.bf1.yahoo.com
Re: USB key requirement.
>> The eToken is basically a smartcard that plugs into USB. > I still don't really understand the difference apart from it containing > a key that I match against. Which is in essence what I was asking to > do with a USB block device which looks much cheaper than the eToken. Typically, the difference is that it's not just a key you can read, but instead the key is kept hidden inside the smartcard and you can only ask the smartcard to use the key. Think of it this way: you can ask the smartcard to decrypt some encrypted data you provide, and if it succeeds, it proves to you that it knows the secret key. But you can't directly read the secret key, which means you can't easily copy the smartcard. Real smartcards probably don't work the way I described, but I hope it gives you some idea of how a smartcard can be different from a plain USB mass storage holding a secret key. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvipxuyd94.fsf-monnier+gmane.linux.debian.u...@gnu.org
Re: USB key requirement.
On Tue, 11 Jan 2011 22:52:06 +0100 deloptes wrote: > > > > > My case is different in the sense that I'm not decrypting my block > > volumes, just halting a boot sequence. > > > > There is something wrong with the setup of your case. > > If you are doing a diskless boot from a share ... how could you use a > device (usb or something else) to authenticate before the system has > booted? The idea with the GPG/PGP key is not bad, but it won't help > you for the setup with the USB drive. > I figured that after the root partition is mounted (nfs), I would have an init.d script that would work its magic.. if it's there, allow the continuation of the boot sequence (load gdm and other non-essential services). All I would require is to match against an encrypted key without user intervention. > Q: Do you have a keyboard and is it desirable to use it on boot time? > Or you want just to plugin and if the right usb is inside the boot > will go on. you can do this after the system has already booted and > you can access the usb from the diskless station. Second option, no keyboard interaction is required in my mind. If you miss having the usb stick inserted, then to move forward, hit the reset button. > Q: have you heard of security > dongles > "http://www.naturela-bg.com/index.php?categ=&page=itm&lang=en&id=45&pid=&p="; > I have heard of them, but I don't personally understand the actual difference of a specialized key, versus a usb block device with an encryption file on it. > regards > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011043824.008ce...@ws82.int.tlc
Re: USB key requirement.
> > My case is different in the sense that I'm not decrypting my block > volumes, just halting a boot sequence. > There is something wrong with the setup of your case. If you are doing a diskless boot from a share ... how could you use a device (usb or something else) to authenticate before the system has booted? The idea with the GPG/PGP key is not bad, but it won't help you for the setup with the USB drive. Q: Do you have a keyboard and is it desirable to use it on boot time? Or you want just to plugin and if the right usb is inside the boot will go on. you can do this after the system has already booted and you can access the usb from the diskless station. Q: have you heard of security dongles "http://www.naturela-bg.com/index.php?categ=&page=itm&lang=en&id=45&pid=&p="; regards -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/igije8$nd...@dough.gmane.org
Re: USB key requirement.
On Mon, 10 Jan 2011 13:45:29 + Darac Marjal wrote: > On Sun, Jan 09, 2011 at 09:42:03PM -0800, Dan Serban wrote: > > So, I'm currently switching my 9 workstations around the house to > > diskless boot. They mount nfs shares that reside on top of an > > encrypted raid server. This is all fine and good. > > > > What I'd like to do: > > > > On a specific workstation, on boot, i'd like to require that a > > specific usb memory stick be inserted in the system. ie. one that > > contains a key which will allow the boot process to continue. > > > > Can this be done? If so, what should I use to make it less than > > easy to decipher? > > > > Maybe a GPG encoded text file that matches against a plain text one? > > (that's insecure)... > > > > I don't know. Do any of you have any suggestions? > > If the requirement can be relaxed to be some other sort of USB device, > you could look at something like this: > http://www.etokenonlinux.org/et/HowTos/eToken_and_LUKS > > The eToken is basically a smartcard that plugs into USB. I still don't really understand the difference apart from it containing a key that I match against. Which is in essence what I was asking to do with a USB block device which looks much cheaper than the eToken. > > If it has to be a USB Mass Storage device, try this: > http://binblog.info/2008/12/04/using-a-usb-key-for-the-luks-passphrase/ > This I've already done with my server, the usb key is inserted into the server to allow it to boot (with the key), what I was asking was for a method to halt a diskless boot (or one with a disk) if a specific USB key wasn't available. So my thoughts went to Vendor ID, serial number, and also a key to compare against on the root filesystem. My case is different in the sense that I'm not decrypting my block volumes, just halting a boot sequence. > Remember, Google is your friend. > My google-fu is weak. All I run into is stuff like you've suggested so far, and how to install debian via a USB key. Nothing like what I want. > > > > > > -- > > To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact > > listmas...@lists.debian.org Archive: > > http://lists.debian.org/20110109214203.09dce...@ws82.int.tlc > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110110173629.7c54a...@ws82.int.tlc
Re: USB key requirement.
On Mon, 10 Jan 2011 14:07:31 -0600 Hugo Vanwoerkom wrote: > Dan Serban wrote: > > So, I'm currently switching my 9 workstations around the house to > > diskless boot. They mount nfs shares that reside on top of an > > encrypted raid server. This is all fine and good. > > What is a workstation like? > > Hugo > I hope I understood your question. The workstations are diskless, ie. no data on them whatsoever, so they boot via PXE and mount their root partitions on an internal server with encrypted volumes (which use the usb key method to startup). > > > > > What I'd like to do: > > > > On a specific workstation, on boot, i'd like to require that a > > specific usb memory stick be inserted in the system. ie. one that > > contains a key which will allow the boot process to continue. > > > > Can this be done? If so, what should I use to make it less than > > easy to decipher? > > > > Maybe a GPG encoded text file that matches against a plain text one? > > (that's insecure)... > > > > I don't know. Do any of you have any suggestions? > > > > > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110110173028.605bb...@ws82.int.tlc
Re: USB key requirement.
On Mon, 10 Jan 2011 11:46:04 +0200 Andrei Popescu wrote: > On Du, 09 ian 11, 21:42:03, Dan Serban wrote: > > So, I'm currently switching my 9 workstations around the house to > > diskless boot. They mount nfs shares that reside on top of an > > encrypted raid server. This is all fine and good. > > > > What I'd like to do: > > > > On a specific workstation, on boot, i'd like to require that a > > specific usb memory stick be inserted in the system. ie. one that > > contains a key which will allow the boot process to continue. > > > > Can this be done? If so, what should I use to make it less than > > easy to decipher? > > > > Maybe a GPG encoded text file that matches against a plain text one? > > (that's insecure)... > > Maybe libpam-ssh can be used for this? > Thanks for your suggestion, it made me search through the pam packages and pam-usb looks like it might do the job. Although, it doesn't seem to do exactly as I had hoped (allow the system to boot if the USB stick is inserted) it's a good start. > Regards, > Andrei -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110110172901.538ff...@ws82.int.tlc
Re: USB key requirement.
Dan Serban wrote: So, I'm currently switching my 9 workstations around the house to diskless boot. They mount nfs shares that reside on top of an encrypted raid server. This is all fine and good. What is a workstation like? Hugo What I'd like to do: On a specific workstation, on boot, i'd like to require that a specific usb memory stick be inserted in the system. ie. one that contains a key which will allow the boot process to continue. Can this be done? If so, what should I use to make it less than easy to decipher? Maybe a GPG encoded text file that matches against a plain text one? (that's insecure)... I don't know. Do any of you have any suggestions? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/igfou3$pr...@dough.gmane.org
Re: USB key requirement.
On Du, 09 ian 11, 21:42:03, Dan Serban wrote: > So, I'm currently switching my 9 workstations around the house to > diskless boot. They mount nfs shares that reside on top of an > encrypted raid server. This is all fine and good. > > What I'd like to do: > > On a specific workstation, on boot, i'd like to require that a specific > usb memory stick be inserted in the system. ie. one that contains a > key which will allow the boot process to continue. > > Can this be done? If so, what should I use to make it less than easy > to decipher? > > Maybe a GPG encoded text file that matches against a plain text one? > (that's insecure)... Maybe libpam-ssh can be used for this? Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
USB key requirement.
So, I'm currently switching my 9 workstations around the house to diskless boot. They mount nfs shares that reside on top of an encrypted raid server. This is all fine and good. What I'd like to do: On a specific workstation, on boot, i'd like to require that a specific usb memory stick be inserted in the system. ie. one that contains a key which will allow the boot process to continue. Can this be done? If so, what should I use to make it less than easy to decipher? Maybe a GPG encoded text file that matches against a plain text one? (that's insecure)... I don't know. Do any of you have any suggestions? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110109214203.09dce...@ws82.int.tlc
