[systemd-bugs] [Bug 84434] New: systemd-ask-password should implement keyboard randomisation as a countermeasure to keyloggers

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sun Sep 28 13:56:03 PDT 2014


https://bugs.freedesktop.org/show_bug.cgi?id=84434

          Priority: medium
            Bug ID: 84434
          Assignee: systemd-bugs at lists.freedesktop.org
           Summary: systemd-ask-password should implement keyboard
                    randomisation as a countermeasure to keyloggers
        QA Contact: systemd-bugs at lists.freedesktop.org
          Severity: enhancement
    Classification: Unclassified
                OS: All
          Reporter: calestyo at scientia.net
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: general
           Product: systemd

Hey.

A nice feature for systemd-ask-password would be a trivial but effective
measure against keyloggers.


The applications should randomly permute the mapping of keys every time a
password is queried and display the mapping from the characters/keys, pressed
on the input device, to those which are actually used in the password.

An example would be this.
> Key mappings:
>   character used for the password: ABCDEF0123456789$/;
>   character pressed on the device: ;E48AD05F29$7C/61B3
> Please enter your passpharse:

Of course one would need to extend this to all usable characters.
Pheraps the number of valid input characters should be configurable, i.e. that
the user specifies which keyboardlayout is used and the valid characters are
automatically deduced from that and/or that the user can give a textfile, which
simply contains all the valid passphrase characters.

Further, the randomisation MUST take place each time the passphrase is
requested, so it should not only happen once per session or once the system
boots,... and especially it should also happen on each retry!
If not, it might again be possible for an attacker that has a keylogger in
place to make statistical attacks.

And it should be asserted, that only high quality entropy is used for the
randomisation, especially since much of these password queries may happen
during boot (e.g. dm-crypt) and urandom may not yet be well enough sed.
If /dev/random blocks, than ask-password should really print a message that the
user should generate entropy, just as e.g. gnupg does during key generation.


Now what's the benefit from all this?
Even if an attacker has a hardware (or software) keylogger in place, he won't
know the random mapping of the keys.
So he only logs the length of the password and the statistical distribution of
the keys - if the password is well enough, the latter shouldn't matter and
there isn't much that can be done against the former[0].

This is especially handy in scenarios like this: Using a gpg encrypted key for
dm-crypt/LUKS.
If the attacker can log the passphrase, it's useless to him since a) it's
randomised and b) he doesn't automatically have the gpg-encrypted key.
And even if he get's the gpg-encrypted key, he still only has a passphrase
which was valid only once for that specific mapping.

The downside is of course, that it takes longer for a user to enter his
passphrase, but since the whole thing should be just optional, it doesn't
really matter.


[0] Well there is one way around that, which could be implemented as a further
option:
To ignore any additional characters at the end of the passphrase, e.g. if we
have the mappings from the example from above, and the real password would be:
AFFE123
the user would need to enter:
;DDA5F2
but could also enter
;DDA5F2ajdk
or
;DDA5F2sijk2jrlsdf
or
;DDA5F2394573021xkkglAlf

The downside of course is, that either systemd-ask-password would need to know
the correct length of the passphrase in order to throw away the rest, or that
the program where it feeds the passphrase into (and which knows the
passphrase), also supports ignoring the extra characters.
In practise though, many programs work with hashed passphrases, so the correct
length would need to be given.
This may be done in a separate random mapping step though, e.g.
actual: 0123456789_
   key: 4_860392157
Enter the password length:

A user could now enter something like:
272735
ask-password should only take everything up to excluding the first occurrence
of "_" (which is the key 2 in the above mapping) as the real length, so in the
above example
2 would map to 7
7 would already be the first "_" and everything afterwards is ignored.
So the length of the password would be 7 (which is just the length of the above
"AFFE123".

The trick with the additional 72734 and the "ignore everything after the first
_" is to prevent that the attacker can find out how many digits the length of
the passphrase has.
With:
2
alone, he'd know that the length is something between [0; 9], which may already
help a lot in brute force or statistical attacks
But with
272735
he only knows that the length is something between [0; 999999], which doesn't
really help anymore.



Cheers,
Chris.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140928/93b90982/attachment.html>


More information about the systemd-bugs mailing list