From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout.rz.uni-frankfurt.de (mailout.rz.uni-frankfurt.de [141.2.22.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 15 Apr 2010 01:54:57 +0200 (CEST) Received: from smtpauth.cluster.uni-frankfurt.de ([10.2.22.4] helo=smtpauth3.rz.uni-frankfurt.de) by mailout.rz.uni-frankfurt.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1O2CQ5-0004Qb-3K for dm-crypt@saout.de; Thu, 15 Apr 2010 01:54:57 +0200 Received: from [141.2.119.133] by smtpauth3.rz.uni-frankfurt.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1O2CPf-0007wp-TC for dm-crypt@saout.de; Thu, 15 Apr 2010 01:54:31 +0200 Message-ID: <4BC655BA.20706@whgl.uni-frankfurt.de> Date: Thu, 15 Apr 2010 01:54:34 +0200 From: Sven Eschenberg MIME-Version: 1.0 References: <20100412171540.GA3138@tansi.org> <20100412175856.GA12353@fancy-poultry.org> <20100413154850.GA19142@tansi.org> <20100413193831.GA8772@fancy-poultry.org> <4BC4CC14.6080408@redhat.com> <20100414153050.GA3966@tansi.org> <4BC60CB2.8030902@gmail.com> <20100414233054.GC9776@tansi.org> In-Reply-To: <20100414233054.GC9776@tansi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] avoid keyloggers: enter password with mouse (virtual keyboard) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Last time I checked, cyptsetup did support reading the passphrase from STDIN. Quoting the man page, cause I am lazy: NOTES ON PASSWORD PROCESSING From a file descriptor or a terminal: Password processing is new-line sensitive, meaning the reading will stop after encountering \n. It will process the read material (without newline) with the default hash or the hash given by --hash. After hashing, it will be cropped to the key size given by -s. From stdin: Reading will continue until EOF (so using e.g. /dev/random as stdin will not work), with the trailing newline stripped. After that the read data will be hashed with the default hash or the hash given by --hash and the result will be cropped to the keysize given by -s. If "plain" is used as an argument to the hash option, the input data will not be hashed. Instead, it will be zero padded (if shorter than the keysize) or truncated (if longer than the keysize) and used directly as the key. No warning will be given if the amount of data read from stdin is less than the keysize. even --keyfile=- is supported (by the way) and behaves slightly different than reading directly from STDIN. Just my 2 cents. -Sven Arno Wagner schrieb: > On Wed, Apr 14, 2010 at 08:42:58PM +0200, Olivier Sessink wrote: >> Arno Wagner wrote: >> >>> Maybe tell us a bit more about your scenario? >> - the hardware is not under our control, > > Ok, I see your problem. > >> - the users are only slightly security aware >> - a bootable USB stick is provided to the users, which has everything >> encrypted (except for /boot for obvious reasons) > > Ok, so basically open, but it takes a bit of effort to > get it open, namely to capture the passphrase. > >> because the hardware is not under our control we won't get 100% security >> (I don't believe in 100% security anyway). So we try to avoid the most >> common threats (most of them cybercrime related). Software botnets, >> trojans etc. on the computer are defeated because we boot the hardware >> from our own image. I think most of our users are enough security aware >> that they should keep the USB stick secured (but I'm afraid not all of >> them, so modifications to /boot is an issue). > > And a modified /boot will basically result in a broken system. > >> But physical attacks like security camera's, keyloggers etc. are still >> possible. So we try to make them harder. I don't think our users are >> enough security aware to detect a hardware keylogger (they won't even >> notice that the usb plug is slightly larger than normal). That's why a >> virtual keyboard would make things harder. > > Well, while I do not really think the virtual keyboard will help > to a larger degree, it may still raise security a bit. > > In order to implement it, implement a virtual keyboard (e.g. > using TK with Perl/Python) and have it give the passphrase > to cryptsetup. Integrating a virtual keyboard into cryptsetup > is really not the UNIX way and very bad software design, as it > increases complexity significantly without need. The virtual > keyboard should be a separate tool. > > What I do not see in the current cryptsetup though, is an > option to read the passphrase from stdin, file or named pipe. > That would be a reasonable extension IMO. > > Arno