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
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
