Hey,
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?
Would I have to hack up the terminal code, add some data structures,
some ioctls to query and reset them, etc. or is there some more elegant way
of going about it? Perhaps I could write something that sits between
the terminal driver and the process which normally receives user input
first, and pipes it to that process instead of letting it inherit a fd
to the tty?
I'd like to be able to do it with (ttys attached to?) network sockets
as well, so that I could test out the applicability of it to remote
users.
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.
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.
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?
Any thoughts on the matter would be much appreciated. I apologize in
advance if these questions convey an ignorance of terminal handling,
or if the right answer is "do it in userspace"; I couldn't immediately
think of a transparent way of doing so (and scheduling delays could
impact the timings in very significant ways).
--
http://www.lightconsulting.com/~travis/ -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
"Travis H." <[email protected]> writes:
> I'd like to be able to do it with (ttys attached to?) network sockets
> as well, so that I could test out the applicability of it to remote
> users.
One issue here is Nagle--you'll definitely want to turn that off, and
I don't think you can do it from the server side. Also, I think SSH
does its own batching of keystrokes, to decrease the overhead of the
crypto encapsulation. So this part seems like a hard problem without
a cooperating client.
>
> 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.
You're not going to be able to do that with network connections, only
locally attached keyboards.
-Doug
On Llu, 2005-10-24 at 02:46 -0500, Travis H. wrote:
> 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.
The keyboard layer abstracts out up/down events, repeat key
functionality and extensions in the normal case. You can put the
keyboard into raw mode and do the work yourself (X does this) and then
feed the results to an application using a pseudo-terminal (see man
openpty).
For networks you are somewhat screwed as the network protocols have
their own timing info and most (telnet, ssh etc) don't pass key up/down
info and batch characters when appropriate. X events might be usable
this way.
> 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?
Write a new keyboard driver for the new keyboard you've built. PC
hardware can't do it but we already support keyboard drivers for a
variety of devices and PDAs which are different to the PC world.