This is a discussion on collecting inter-keystroke timings within the lucky.openbsd.tech forums, part of the OpenBSD category; --> Hey, Supposing I was interested in collecting inter-keystroke timings on Unix for the purposes of biometric authentication, what would ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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. -- 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 |