Re: [dm-crypt] avoid keyloggers: enter password with mouse (virtual keyboard)

[Sven Eschenberg <sven@whgl.uni-frankfurt.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