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

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

[Olivier Sessink]

Hi all,

several disk encryption products feature a virtual keyboard, so users
can use the mouse to enter the password which makes keyloggers
useless. Has anyone ever tried something like that with cryptsetup?

regards,
   Olivier

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

[Arno Wagner]

You can do this by having cryptsetup read the passphrase
from stdin and attach such a virtual keyboard to stdin.

However as a keylogger has to be root and root can read
the encryption key from memory, it is pretty useless
security-wise.

Arno

On Mon, Apr 12, 2010 at 05:10:13PM +0200, Olivier Sessink wrote:
> Hi all,
> 
> several disk encryption products feature a virtual keyboard, so users
> can use the mouse to enter the password which makes keyloggers
> useless. Has anyone ever tried something like that with cryptsetup?
> 
> regards,
>    Olivier
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Richard Zidlicky]

On Mon, Apr 12, 2010 at 05:10:13PM +0200, Olivier Sessink wrote:
> Hi all,
> 
> several disk encryption products feature a virtual keyboard, so users
> can use the mouse to enter the password which makes keyloggers
> useless. 

it does not make keyloggers useless, only requires slightly different manipulation
to the system.

You get the best safety if you have encrypted root and swap and boot off
a CD which contains your kernel and ramdisk. There is no keylogger unless
you did burn it on the CD.

Guaranteeing the integrity of the boot media is extremely important and
afaics only physical security of the media helps here.

Richard

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

[Heinz Diehl]

On 12.04.2010, Arno Wagner wrote: 

> However as a keylogger has to be root and root can read
> the encryption key from memory, it is pretty useless
> security-wise.

Seems it's an hardware keylogger he meant..

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

[Olivier Sessink]

Arno Wagner wrote:
> You can do this by having cryptsetup read the passphrase
> from stdin and attach such a virtual keyboard to stdin.
> 
> However as a keylogger has to be root and root can read
> the encryption key from memory, it is pretty useless
> security-wise.

I meant a hardware keylogger, sorry I didn't clarify that.

Olivier

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

[Arno Wagner]

On Mon, Apr 12, 2010 at 07:58:56PM +0200, Heinz Diehl wrote:
> On 12.04.2010, Arno Wagner wrote: 
> 
> > However as a keylogger has to be root and root can read
> > the encryption key from memory, it is pretty useless
> > security-wise.
> 
> Seems it's an hardware keylogger he meant..

If he has a hardware Keylogger on his system, somebody
did physically manipulate his machine and all bets
are off anyways. There may, e.g., now be a webcam in his
ceiling, recording whatever is on his screen.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Heinz Diehl]

On 13.04.2010, Arno Wagner wrote: 

> If he has a hardware Keylogger on his system, somebody
> did physically manipulate his machine and all bets
> are off anyways.

Of course. 

So this boils down to the fact that a software keyboard is useless :-)
If somebody had physical access to the machine, there will be no
way to detect any backdoors, and if somebody had been able to install a
software keylogger, this person has already gained root access to the machine
and could simply have read the master key from memory or whatever, you
name it.

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

[Milan Broz]

On 04/13/2010 09:38 PM, Heinz Diehl wrote:
> On 13.04.2010, Arno Wagner wrote: 
> 
>> If he has a hardware Keylogger on his system, somebody
>> did physically manipulate his machine and all bets
>> are off anyways.
> 
> Of course. 
> 
> So this boils down to the fact that a software keyboard is useless :-)
> If somebody had physical access to the machine, there will be no
> way to detect any backdoors, and if somebody had been able to install a
> software keylogger, this person has already gained root access to the machine
> and could simply have read the master key from memory or whatever, you
> name it.

I just remember schoolbook example with "software keyboard" where 
such keyboard was used to enter PIN using mouse.

Instead of sending the key scan code back to hidden logger program,
it simply send rectangular areas on screen (screenshot) centered to
mouse clicks...
So attacker can easily read pin code from these few-bytes small pictures
of visual keyboard:-)

Milan

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

[Olivier Sessink]

2010/4/13 Milan Broz <mbroz@redhat.com>:
> On 04/13/2010 09:38 PM, Heinz Diehl wrote:
>> On 13.04.2010, Arno Wagner wrote:
>>
>>> If he has a hardware Keylogger on his system, somebody
>>> did physically manipulate his machine and all bets
>>> are off anyways.
>>
>> Of course.
>>
>> So this boils down to the fact that a software keyboard is useless :-)
>> If somebody had physical access to the machine, there will be no
>> way to detect any backdoors, and if somebody had been able to install a
>> software keylogger, this person has already gained root access to the machine
>> and could simply have read the master key from memory or whatever, you
>> name it.
>
> I just remember schoolbook example with "software keyboard" where
> such keyboard was used to enter PIN using mouse.
>
> Instead of sending the key scan code back to hidden logger program,
> it simply send rectangular areas on screen (screenshot) centered to
> mouse clicks...
> So attacker can easily read pin code from these few-bytes small pictures
> of visual keyboard:-)

1) a hardware keylogger costs about $100,-, can be ordered on many
places, and requires no technical expertise whatsoever. A hardware
keylogger is 100X easier than software modifications, or a
hardware-mouse-sniffer (I've never seen them)

2) we have protected ourselves from software modifications already
(boot from USB). So a hardware keylogger is our biggest threat.

3) most virtual keyboards I have seen are randomly positioned on the
screen, so you really need a well-positioned camera to capture the
password (which, again, is much more complex than a hardware
keylogger, requires a lot of technical expertise).

Olivier

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

[Arno Wagner]

On Wed, Apr 14, 2010 at 03:11:50PM +0200, Olivier Sessink wrote:
> 2010/4/13 Milan Broz <mbroz@redhat.com>:
> > On 04/13/2010 09:38 PM, Heinz Diehl wrote:
> >> On 13.04.2010, Arno Wagner wrote:
> >>
> >>> If he has a hardware Keylogger on his system, somebody
> >>> did physically manipulate his machine and all bets
> >>> are off anyways.
> >>
> >> Of course.
> >>
> >> So this boils down to the fact that a software keyboard is useless :-)
> >> If somebody had physical access to the machine, there will be no
> >> way to detect any backdoors, and if somebody had been able to install a
> >> software keylogger, this person has already gained root access to the machine
> >> and could simply have read the master key from memory or whatever, you
> >> name it.
> >
> > I just remember schoolbook example with "software keyboard" where
> > such keyboard was used to enter PIN using mouse.
> >
> > Instead of sending the key scan code back to hidden logger program,
> > it simply send rectangular areas on screen (screenshot) centered to
> > mouse clicks...
> > So attacker can easily read pin code from these few-bytes small pictures
> > of visual keyboard:-)
> 
> 1) a hardware keylogger costs about $100,-, can be ordered on many
> places, and requires no technical expertise whatsoever. A hardware
> keylogger is 100X easier than software modifications, or a
> hardware-mouse-sniffer (I've never seen them)

It is also about 10'000 times easier to find. 

> 2) we have protected ourselves from software modifications already
> (boot from USB). So a hardware keylogger is our biggest threat.

As an attacker with physical access can modify your boot
USB device contents or replace the device in the first place.
Adding a software keyboard sniffer is easy with that.

> 3) most virtual keyboards I have seen are randomly positioned on the
> screen, so you really need a well-positioned camera to capture the
> password (which, again, is much more complex than a hardware
> keylogger, requires a lot of technical expertise).

But physically getting to your computer to place, and, more important
later retrieve, a hardware keylogger is easy? 

I still think your security analysis is invalid. For example, why 
not attach the keyboard cable in such a way that placing a hardware 
keylogger in it gets very hard, e.g. needs cable cutting? If your 
attackers have no technical expertise, that would reliable defeat 
them. This can be as easy as gluing the keyboard connector in, or 
fixing it in place with hard to open cable ties.

Maybe tell us a bit more about your scenario?

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Olivier Sessink]

Arno Wagner wrote:

> Maybe tell us a bit more about your scenario?

- the hardware is not under our control,
- 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)

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).

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.

Olivier

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

[Arno Wagner]

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
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Sven Eschenberg]

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

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

[Milan Broz]

On 04/15/2010 01:30 AM, Arno Wagner wrote:
> 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.

As mentioned in other mail, it can read passphrase from stdin,
also keyfile is supported.

But for these types of applications is better use libcryptsetup,
you can better control which buffer contain passphrase so you can
wipe it. Also locking of memory (avoid to swap out memory
with sensitive data) is better controlled through library then
in some shell script.

An example of code snip to open LUKS device is here
http://code.google.com/p/cryptsetup/issues/detail?id=58&can=1#c1

Milan

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

[test532]

It's good to see that you have come to your senses Arno.

> 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
> 

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

[Arno Wagner]

On Thu, Apr 15, 2010 at 08:24:54AM +0200, Milan Broz wrote:
> On 04/15/2010 01:30 AM, Arno Wagner wrote:
> > 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.
> 
> As mentioned in other mail, it can read passphrase from stdin,
> also keyfile is supported.

Ah, for some reason I thought this was a raw keyfile. Of 
course 'keyfile' does not mean keyfile, but file with the 
passphrase in case of LUKS. And for plain dm-crypt, the 
passphrase is the (not yet hashed) key. Temporary confusion
on my side.
  
> But for these types of applications is better use libcryptsetup,
> you can better control which buffer contain passphrase so you can
> wipe it. Also locking of memory (avoid to swap out memory
> with sensitive data) is better controlled through library then
> in some shell script.

True, if you want reasonable security. 
 
> An example of code snip to open LUKS device is here
> http://code.google.com/p/cryptsetup/issues/detail?id=58&can=1#c1

Thanks.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Arno Wagner]

On Thu, Apr 15, 2010 at 03:50:56AM -0400, test532@codingninjas.org wrote:
> It's good to see that you have come to your senses Arno.

I never lost my senses. "a bit more secure" usually does not
justify the effort needed here. It is still basically easy to 
hack and has far bigger problems than password entry.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Richard Zidlicky]

On Thu, Apr 15, 2010 at 01:30:54AM +0200, Arno Wagner wrote:
> On Wed, Apr 14, 2010 at 08:42:58PM +0200, Olivier Sessink wrote:
> > Arno Wagner wrote:
> > 

> 
> Well, while I do not really think the virtual keyboard will help
> to a larger degree, it may still raise security a bit. 

what would help a litle bit more in this scenario is getting the password
from a smartcard with a nice fully encrypted challenge response protocol.

Richard

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

[Vladimir Giszpenc]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

> On Thu, Apr 15, 2010 at 01:30:54AM +0200, Arno Wagner wrote:
> > On Wed, Apr 14, 2010 at 08:42:58PM +0200, Olivier Sessink wrote:
> > > Arno Wagner wrote:
> > >
> 
> >
> > Well, while I do not really think the virtual keyboard will help
> > to a larger degree, it may still raise security a bit.
> 
> what would help a litle bit more in this scenario is getting the password
> from a smartcard with a nice fully encrypted challenge response protocol.
> 
> Richard

Some smart cards can't store passwords, but...

Using a smart card with a private key to decrypt and using the public key to encrypt instead of a password would go a long way to
making LUKS more secure.

This would allow me to encrypt a drive with someone's public key without having to share a password (or a separate key file).

Note that I am talking about encrypting the master key in a LUKS partition and not the whole drive using dm-crypt.

This would obviously require a change to the LUKS header format, but I think it would be very useful.  

Encrypting a key file is not the same as it requires me to either partition the (USB) drive (with the key file on a separate
partition) or send it some other way.

Basically, all possible authentication/authorization mechanisms should be available.  If for some reason, I want to encrypt/decrypt
my drive using an iris scan, it should be possible.  Passwords are weak and are only something you know.

I realize that most people don't have an iris scanner on their laptop, but a bunch already have finger print scanners so what I am
describing is not that farfetched.  


Vlad

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3720 bytes --]

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

[Jan]

Arno Wagner <arno@...> writes:
> 
> On Wed, Apr 14, 2010 at 08:42:58PM +0200, Olivier Sessink wrote:
> > Arno Wagner wrote:
[...]

> Well, while I do not really think the virtual keyboard will help
> to a larger degree, it may still raise security a bit. 

It raises security to the NECESSARY level in the following scenarios:

You have a fully encrypted system on your USB stick like privatix 
(see http://www.mandalka.name/privatix/index.html.en ) and you are 
sitting in an internet cafe. There's a hardware keylogger installed 
on that the PC you use. You lose your USB stick, maybe you even 
forget it in the internet cafe (this happens)! 

Or: 

You have a curious husband/roomate how knows you are using privatix to stay
private. He knows where you keep the USB stick. He installs a hardware keylogger
because to get access to your data. Jealous husbands are common. 

> 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.

[In some later answer to that thread someone said cryptsetup could even read
from stdin.]

Unfortunately I'm not able to implement this, because I'm just a windows user
how uses privatix for sake of security. Nevertheless I believe it is quite hard
to get a virtual keyboard running at boot time with mouse support and all. I
have a different proposal for the method to enter the password:

On the screen might appear a list of all letters etc. with a random number next
to it. This might look like this:

A 5   a 56
B 23  b 4
C 7   c 8
...

If the user wants to enter "B" for example, he would just type in 23. The random
numbers could be exchaned randomly after every letter that was "typed". This way
the hardware keylogger would get a bunch of numbers without any meaning. If all
letters don't fit on the srceen, onle could have something like

LOWERCASE 85

By entering the random number 85 one would arrive at the table with the
lowercase letters.

I think this could easyly be implemented in cryptsetup as an option to enter the
pasword. Unfortunately I'm not able to do that. Could the project perhaps set
that as one of it's goals?

I'm grateful for answers, 
Jan

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

[Arno Wagner]

On Tue, Oct 04, 2011 at 03:02:55PM +0000, Jan wrote:
> Arno Wagner <arno@...> writes:
> > 
> > On Wed, Apr 14, 2010 at 08:42:58PM +0200, Olivier Sessink wrote:
> > > Arno Wagner wrote:
> [...]
> 
> > Well, while I do not really think the virtual keyboard will help
> > to a larger degree, it may still raise security a bit. 
> 
> It raises security to the NECESSARY level in the following scenarios:
> 
> You have a fully encrypted system on your USB stick like privatix 
> (see http://www.mandalka.name/privatix/index.html.en ) and you are 
> sitting in an internet cafe. There's a hardware keylogger installed 
> on that the PC you use. You lose your USB stick, maybe you even 
> forget it in the internet cafe (this happens)! 
> 
> Or: 
> 
> You have a curious husband/roomate how knows you are using privatix to stay
> private. He knows where you keep the USB stick. He installs a hardware keylogger
> because to get access to your data. Jealous husbands are common. 
> 
> > 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.
> 
> [In some later answer to that thread someone said cryptsetup could even read
> from stdin.]
> 
> Unfortunately I'm not able to implement this, because I'm just a windows user
> how uses privatix for sake of security. Nevertheless I believe it is quite hard
> to get a virtual keyboard running at boot time with mouse support and all. I
> have a different proposal for the method to enter the password:
> 
> On the screen might appear a list of all letters etc. with a random number next
> to it. This might look like this:
> 
> A 5   a 56
> B 23  b 4
> C 7   c 8
> ...
> 
> If the user wants to enter "B" for example, he would just type in 23. The random
> numbers could be exchaned randomly after every letter that was "typed". This way
> the hardware keylogger would get a bunch of numbers without any meaning. If all
> letters don't fit on the srceen, onle could have something like
> 
> LOWERCASE 85
> 
> By entering the random number 85 one would arrive at the table with the
> lowercase letters.

This is a reasonable design design. However it assumes a terminal
of a certain height (or at least a possibility to _query_ height).
It could leave users stuck, for example when all they have is
two lines or another small number. This could happen on appliances
with LCDs for example.

So I would add a possibility to bypass and enter the passphrase 
verbatim, to have a fallback. As your UI takes only
numbers and ENTER, say, the x-Key could be used to get
into passphrase mode.
 
> I think this could easyly be implemented in cryptsetup as an option to enter the
> pasword. Unfortunately I'm not able to do that. Could the project perhaps set
> that as one of it's goals?

And again, wrong approach from an architecture point of view. 
This belongs into an external tool, that could be connected to 
cryptsetup via stdin or wrap the call.

Other than that, I think this would be a neat add-on, but not a
cryptsetup core project. Something like zuluCrypt (but easier
to do ;-)

Side note: We might think about adding a link-list for
such projects.

Side note 2: A virtual keyboard does not need a mouse. You can use 
arrow-keys. You still need some terminal-interface, like from
ncurses. 

Side note 3: All this only helps to a limited degree. A PC 
with keylogger might just also have a video-grabber (or 
cheap HD camera) pointed at the screen.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Heinz Diehl]

On 04.10.2011, Jan wrote: 

> You have a fully encrypted system on your USB stick like privatix 
> (see http://www.mandalka.name/privatix/index.html.en ) and you are 
> sitting in an internet cafe. There's a hardware keylogger installed 
> on that the PC you use. You lose your USB stick, maybe you even 
> forget it in the internet cafe (this happens)! 
[.....]

Privacy on a machine outside of your control is a no-go.
There are by far more options to get access to your data if
somebody other than yourself has admin/root access to the machine
you're using. A simple script which does a copy of anything inserted
will do it. Or the admin himself logged in from another machine, and
many more...

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

[Jan]

Arno Wagner <arno@...> writes:

> On Tue, Oct 04, 2011 at 03:02:55PM +0000, Jan wrote:
> > Arno Wagner <arno@...> writes:
> Other than that, I think this would be a neat add-on, but not a
> cryptsetup core project. Something like zuluCrypt (but easier
> to do)
> 
> Side note: We might think about adding a link-list for
> such projects.

Whom could I encourage to realize such a project?


> Side note 3: All this only helps to a limited degree. A PC 
> with keylogger might just also have a video-grabber (or 
> cheap HD camera) pointed at the screen.

Heinz Diehl <htd@...> writes:

> Privacy on a machine outside of your control is a no-go.
> There are by far more options to get access to your data if
> somebody other than yourself has admin/root access to the machine
> you're using. A simple script which does a copy of anything inserted
> will do it. Or the admin himself logged in from another machine, and
> many more...

Tools like privatix (see http://www.mandalka.name/privatix/index.html.en )
are designed for MOBILE use to make internet cafes a SAFER place. This 
does not mean such systems offer perfect security. 

Booting your own OS safes you from "software attacks" like the ones 
Heinz Diehl mentioned (is this right?). Thus the "only" remaining thread 
comes from the hardware side. It seems to me the most COMMON thread there 
are hardware keyloggers. I thinks hardware based video-grabbers are not 
that common (what do you think?). They need a lot of disk space, don't they? 
In my scenario the attacker would need a hardware video-grabbers AND a 
hardware keylogger, I think this should be unlikely in common internet cafes, 
while a keyloger alone is likely. 

HD camera pointed at the screen don't seem such a threat to me since in 
internet cafes you can often turn the screen or move your body close to it, 
so its content is hard to see for others. 

My point is I want to be protected agains the likely threads, not the unlikely. 
If I have very very sensitive data, I agree, that using an internet cafe is 
no good. 

Originally I was looking for a rather safe way to use my gnuPG-key in 
internet cafes or foreign computers.

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

[Arno Wagner]

On Tue, Oct 04, 2011 at 09:42:45PM +0000, Jan wrote:
> Arno Wagner <arno@...> writes:
> 
> > On Tue, Oct 04, 2011 at 03:02:55PM +0000, Jan wrote:
> > > Arno Wagner <arno@...> writes:
> > Other than that, I think this would be a neat add-on, but not a
> > cryptsetup core project. Something like zuluCrypt (but easier
> > to do)
> > 
> > Side note: We might think about adding a link-list for
> > such projects.
> 
> Whom could I encourage to realize such a project?
>
> > Side note 3: All this only helps to a limited degree. A PC 
> > with keylogger might just also have a video-grabber (or 
> > cheap HD camera) pointed at the screen.
> 
> Heinz Diehl <htd@...> writes:
> 
> > Privacy on a machine outside of your control is a no-go.
> > There are by far more options to get access to your data if
> > somebody other than yourself has admin/root access to the machine
> > you're using. A simple script which does a copy of anything inserted
> > will do it. Or the admin himself logged in from another machine, and
> > many more...
> 
> Tools like privatix (see http://www.mandalka.name/privatix/index.html.en )
> are designed for MOBILE use to make internet cafes a SAFER place. This 
> does not mean such systems offer perfect security. 

Well, yes. The question is whether an internet Cafe installing
a hardware keylogger will not do some extra things that render
privatix security entirely compromised. A software keylogger is
alredy defeated by the clean boot, going to the extra trouble
to install a hardware keylogger requires some (small) real 
commitment from the attacker.

> Booting your own OS safes you from "software attacks" like the ones 
> Heinz Diehl mentioned (is this right?). Thus the "only" remaining thread 
> comes from the hardware side. It seems to me the most COMMON thread there 
> are hardware keyloggers. I thinks hardware based video-grabbers are not 
> that common (what do you think?). They need a lot of disk space, don't they? 
> In my scenario the attacker would need a hardware video-grabbers AND a 
> hardware keylogger, I think this should be unlikely in common internet cafes, 
> while a keyloger alone is likely. 

Well, I agree that it is more effort. But going though the output
from a keylogger already is significant effort.
 
> HD camera pointed at the screen don't seem such a threat to me since in
> internet cafes you can often turn the screen or move your body close to
> it, so its content is hard to see for others.
> 
> My point is I want to be protected agains the likely threads, not the
> unlikely.  If I have very very sensitive data, I agree, that using an
> internet cafe is no good.

I really don't know. If it is just the spare-time project of the
Internet Cafee owner, you might be right. If it is the project
of the secret police, recording the video off the cable is 
conveivable, although a bit more expensive than the about $80
for the hardware keylogger.

> Originally I was looking for a rather safe way to use my gnuPG-key in 
> internet cafes or foreign computers.

And yes, it is safer. It is still not very safe.

As to who could do it, no idea. It is not very hard to do,
but requires some Linux knowledge. It should possibly also be 
done in C to be usable early during boot and in an initrd.

Personally, I could do it, but I have other projects, sorry.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Jan]

Arno Wagner <arno@...> writes:

> I really don't know. If it is just the spare-time project of the
> Internet Cafee owner, you might be right. If it is the project
> of the secret police, recording the video off the cable is 
> conveivable, although a bit more expensive than the about $80
> for the hardware keylogger.

Usually it sould be a spare time project, since I choose the internet cafe at
random and video grabber cost about $170 (see http://www.keydemon.com/ ). It
would be nice to be protected against hardware keyloggers at least with the
software I proposed. I know some C basics. In case I find some time, where could
I get the mentioned linux knowledge?

Originally I wanted to find a way to use my GnuPG key in internet cafes savely.
Since as you pointed out, even with the software I proposed, there is no
"absolute" security. Here's my pragmatical solution:

0. Use privatix.
1. Protect against hardware keyloggers with the software I proposed to defeat
the "most common" thread.
2. Use TWO GnuPG keys with the following user-IDs:
   
   "My Name 
   (very safe, your email reaches 
    me at my save PC at home only) 
   <myaddress@gmx.de>",
   
   "My Name 
   (not completely safe, your email reaches 
    me in unsecure internet cafes and at home) 
   <myaddress@gmx.de>"

3. Have two privatix USB sticks, one for at home, the other for internet cafes
etc. The first one never leaves my home.

This way people who want to send me an encrypted email can decide for hemselves
which level of security their message needs. If they chose the second key at
east internet providers cannot read the content of the email and send
personalized advertisments etc. 

Another question:
When I plug in my USB stick in an internet cafe, boot from it and have
decrcypted it, is there a hardware mechanism known to you that could
automatically copy the DECRYPTED contents of my stick? I think that's unlikely
since the decryption takes place in the OS, ist that right?

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

[Arno Wagner]

On Wed, Oct 05, 2011 at 09:37:01AM +0000, Jan wrote:
> Arno Wagner <arno@...> writes:
> 
> > I really don't know. If it is just the spare-time project of the
> > Internet Cafee owner, you might be right. If it is the project
> > of the secret police, recording the video off the cable is 
> > conveivable, although a bit more expensive than the about $80
> > for the hardware keylogger.
> 
> Usually it sould be a spare time project, since I choose the internet cafe
> at random and video grabber cost about $170 (see http://www.keydemon.com/
> ).  It would be nice to be protected against hardware keyloggers at least
> with the software I proposed.  I know some C basics.  In case I find some
> time, where could I get the mentioned linux knowledge?

A C on Linux tutorial should be enough then. 

Minimal process:

1. Write C-Programm with editor (of your choice, 
   examples: joe, vi, emacs)
2. gcc -o <program> <sourcefile>.c

This is for a single source file. Should be enough.

For screen output, just do a complete screen rewrite 
line-wise with the "poor man's teminal clear" (write 
25 or 50 emtpy lines). 

You can get c library help either from the GNU info pages
("info libc") or often from the commandline "man 3 <command>",
e.g. "man 3 printf". The "3" refers to section 3 of tha 
manual which is the C library. You may have to install the
C library documentation package.

Attacheing a command via its STDIN is a bit more tricky,
but can be done with "popen".
An example is here:

  http://stackoverflow.com/questions/70842/execute-program-from-within-a-c-program

As usual, Google is your friend, just add "linux" to the
C query.
 
> Originally I wanted to find a way to use my GnuPG key in internet cafes
> savely.  Since as you pointed out, even with the software I proposed,
> there is no "absolute" security.  Here's my pragmatical solution:
> 
> 0. Use privatix.
> 1. Protect against hardware keyloggers with the software I proposed to
> defeat the "most common" thread.
> 2. Use TWO GnuPG keys with the following user-IDs:
>    
>    "My Name 
>    (very safe, your email reaches 
>     me at my save PC at home only) 
>    <myaddress@gmx.de>",
>    
>    "My Name 
>    (not completely safe, your email reaches 
>     me in unsecure internet cafes and at home) 
>    <myaddress@gmx.de>"

Make sure the second one is clearly marked as not-that-secure, as
the sender has to choose which one to use.

> 3. Have two privatix USB sticks, one for at home, the other for internet
> cafes etc.  The first one never leaves my home.
> 
> This way people who want to send me an encrypted email can decide for
> hemselves which level of security their message needs.  If they chose the
> second key at east internet providers cannot read the content of the email
> and send personalized advertisments etc.
> 
> Another question:
> When I plug in my USB stick in an internet cafe, boot from it and have
> decrcypted it, is there a hardware mechanism known to you that could
> automatically copy the DECRYPTED contents of my stick? I think that's unlikely
> since the decryption takes place in the OS, ist that right?

Nothing standard. The best bet IMO would be to fake the boot
using a VM and then read the key from the VM's memory. You
are right that decryption is done in the PC, the data that 
goes over USB is still encrypted.

I would say that besides the faked boot via VM, you do not need
to worry about it in your scenario. And to fight the faked boot, 
do a full power cycle with wall socket unplug, not just a reset.
Presenting such a faked boot takes some effort though.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Jan]

Thanks for all the helpful answers,
Jan

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

[Ma Begaj]

2011/10/4 Heinz Diehl <htd@fancy-poultry.org>:
> On 04.10.2011, Jan wrote:
>
>> You have a fully encrypted system on your USB stick like privatix
>> (see http://www.mandalka.name/privatix/index.html.en ) and you are
>> sitting in an internet cafe. There's a hardware keylogger installed
>> on that the PC you use. You lose your USB stick, maybe you even
>> forget it in the internet cafe (this happens)!
> [.....]
>
> Privacy on a machine outside of your control is a no-go.
> There are by far more options to get access to your data if
> somebody other than yourself has admin/root access to the machine
> you're using. A simple script which does a copy of anything inserted
> will do it. Or the admin himself logged in from another machine, and
> many more...


that is not true. two factor authorization solves this problem pretty easy.

I am using barada on my machines for SSH and it is working pretty great.
http://barada.sourceforge.net/

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

[Ma Begaj]

2011/11/30 Ma Begaj <derliebegott@gmail.com>:
> 2011/10/4 Heinz Diehl <htd@fancy-poultry.org>:
>> On 04.10.2011, Jan wrote:
>>
>>> You have a fully encrypted system on your USB stick like privatix
>>> (see http://www.mandalka.name/privatix/index.html.en ) and you are
>>> sitting in an internet cafe. There's a hardware keylogger installed
>>> on that the PC you use. You lose your USB stick, maybe you even
>>> forget it in the internet cafe (this happens)!
>> [.....]
>>
>> Privacy on a machine outside of your control is a no-go.
>> There are by far more options to get access to your data if
>> somebody other than yourself has admin/root access to the machine
>> you're using. A simple script which does a copy of anything inserted
>> will do it. Or the admin himself logged in from another machine, and
>> many more...
>
>
> that is not true. two factor authorization solves this problem pretty easy.
>
> I am using barada on my machines for SSH and it is working pretty great.
> http://barada.sourceforge.net/


s/authorization/authentication/

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

[Arno Wagner]

On Wed, Nov 30, 2011 at 03:22:50PM +0100, Ma Begaj wrote:
> 2011/10/4 Heinz Diehl <htd@fancy-poultry.org>:
> > On 04.10.2011, Jan wrote:
> >
> >> You have a fully encrypted system on your USB stick like privatix
> >> (see http://www.mandalka.name/privatix/index.html.en ) and you are
> >> sitting in an internet cafe. There's a hardware keylogger installed
> >> on that the PC you use. You lose your USB stick, maybe you even
> >> forget it in the internet cafe (this happens)!
> > [.....]
> >
> > Privacy on a machine outside of your control is a no-go.
> > There are by far more options to get access to your data if
> > somebody other than yourself has admin/root access to the machine
> > you're using. A simple script which does a copy of anything inserted
> > will do it. Or the admin himself logged in from another machine, and
> > many more...
> 
> 
> that is not true. two factor authorization solves this problem pretty easy.

It seems to until you look more closely. Current attacks
on online-banking demonstrate the attack. The only way around 
that is basically to delegate all interaction to a device
the attacker did not have access to. Everything else just 
increases attackert effort, but is still feasible.
 
> I am using barada on my machines for SSH and it is working pretty great.
> http://barada.sourceforge.net/

What has "working well" to do with "being secure"? Not a lot, I
would say. If the machine you do this one has been pepared
to hijack ssh-sessions, it can easily look over all your stuff
without you ever knowing and install a backdoor on the machine
you logged in to. This is a practical attack, even if it causes
some effort on the attacker's side. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Ma Begaj]

2011/11/30 Arno Wagner <arno@wagner.name>:
> On Wed, Nov 30, 2011 at 03:22:50PM +0100, Ma Begaj wrote:
>> 2011/10/4 Heinz Diehl <htd@fancy-poultry.org>:
>> > On 04.10.2011, Jan wrote:
>> >
>> >> You have a fully encrypted system on your USB stick like privatix
>> >> (see http://www.mandalka.name/privatix/index.html.en ) and you are
>> >> sitting in an internet cafe. There's a hardware keylogger installed
>> >> on that the PC you use. You lose your USB stick, maybe you even
>> >> forget it in the internet cafe (this happens)!
>> > [.....]
>> >
>> > Privacy on a machine outside of your control is a no-go.
>> > There are by far more options to get access to your data if
>> > somebody other than yourself has admin/root access to the machine
>> > you're using. A simple script which does a copy of anything inserted
>> > will do it. Or the admin himself logged in from another machine, and
>> > many more...
>>
>>
>> that is not true. two factor authorization solves this problem pretty easy.
>
> It seems to until you look more closely. Current attacks
> on online-banking demonstrate the attack. The only way around
> that is basically to delegate all interaction to a device
> the attacker did not have access to. Everything else just
> increases attackert effort, but is still feasible.
>
>> I am using barada on my machines for SSH and it is working pretty great.
>> http://barada.sourceforge.net/
>
> What has "working well" to do with "being secure"? Not a lot, I
> would say. If the machine you do this one has been pepared
> to hijack ssh-sessions, it can easily look over all your stuff
> without you ever knowing and install a backdoor on the machine
> you logged in to. This is a practical attack, even if it causes
> some effort on the attacker's side.

there is no absolute security on other people's machine but two
factor authentication is a secure solution against keylogger attacks
and I was pointing to that.