Subject: Re: terminal handling: collecting inter-keystroke timings
To: Travis H. <solinym@gmail.com>
From: Daniel Carosone <dan@geek.com.au>
List: tech-kern
Date: 10/24/2005 17:54:19
--de1H0RjRxOSdb4we
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 24, 2005 at 01:56:11AM -0500, Travis H. wrote:
> Supposing I was interested in collecting inter-keystroke timings on
> Unix for the purposes of biometric authentication, what would be a
> clean way of doing so?

Probably a kqueue on the tty with timing data in the events returned.

> Ideally any mechanism would be flexible enough that I could have it
> deliver me timings between key-down, key-up-to-key-down, or up/down to
> up/down timings.  And it should be efficient enough that it can
> deliver most of them unprocessed to some userland collector daemon
> which does the filtering of outliers and whatnot.

tty won't get you that, you'd need to do that in the device-specific
keyboard driver, or perhaps wskbd at best. also won't work over the
network, except for X events, and then with timing artifacts that
likely make it useless anyway.

> A secondary use of this would be to characterize/quantify the amount
> of entropy available from keystroke timings, given that they are
> quantized and enqueued (in hardware) several times on their way to the
> kernel.

There's some of this in rnd already, though the estimator is not
really useful or valid.  Contributions and improvements welcome.=20

> Since I'm on the subject, a related project I had in mind would be
> hacking the keyboard to do its raster-scan in a pseudo-random order
> that was synchronized with the terminal driver such that the signal on
> the wire was, if not encrypted, at least scrambled enough to be
> difficult to convert back into plaintext.  What would this involve on
> the kernel side?

Cute idea, but I doubt it's possible, or if it is that it's useful.
I'm pretty sure this is all within the keypad itself, and not visible
to the driver; the line to the pckbd controller on the long cable is
just serial events.  You probably need a new keyboard chip, both to do
the randomised scanning and to do encryption on the serial line - and
even then it might not help you much.

--
Dan.

--de1H0RjRxOSdb4we
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDXJMrEAVxvV4N66cRAqbNAKDdQeq6GNXzUIFkIQN+iQaMsoyVnQCgmDap
GgGJNs5jIwEsBDN6J/Vfna8=
=oabU
-----END PGP SIGNATURE-----

--de1H0RjRxOSdb4we--