I'm writing keystoke dynamics identifcation as an assignment and I'm having trouble with storing data. I was instructed only to "don't keep raw data" as it should've been transformed. I wasn't told what form data should take to not be considered raw or how to transform it. Unfortunately I couldn't find any articles/publications that'd tell me either.

I am recording raw data as follows:

key | Pressed/Released | Time since last event
Z P 64
Z R 96
A P 88
P P 72
A R 9
P R 64
O P 88
O R 81

Then I process it by separate metrics: UpToUp, dwell, flight, interval and latency. Let's look at UpToUp data (they all output frequencies in the same format). Timings are calculated:

Z -> A: 169 (88+72+9)
A -> P: 64
P -> O: 169

Then grouped and counted:

[(64,1), (169,2)] or more general [("60-70",1), ("160-170",2)]

Keystroke recording can be of any length. If it were bigger, we'd get more diverse frequencies that'd be normally distributed .

I'm looking for confirmation or recommendation, whether these frequency countings can be transformed further, so it's more distant from raw data. As I said, I couldn't find any publication which would answer me.

With voice biometrics I came across FFT, but I couldn't find it in keystroke context.

  • 1
    How would such data leak exactly? Are you trying to prevent webpages from identifying the person behind the keyboard or is the keystroke data gathered in another way? With what you describe, the timing of the key-ups might still be unique, with keys only registering when you let them go. – J.A.K. Dec 30 '18 at 13:58
  • 1
    Leak is an example. My main concern is about good practices – wojteo Dec 30 '18 at 14:08
  • If the timing of both up and down were to leak directly (e.g. from a wireless keyboard), there is little you can do to prevent that. Only sending key-ups would seriously impact user experience, keys would only register when you let them go, creating a sluggish feel. It would also make holding a key down impossible. If you're ever storing keystroke data, don't store any timings. – J.A.K. Dec 31 '18 at 4:33
  • 1
    You have asked a question without proper definition. "How long is a piece of string?" What are the threats? In what form does the remaining data need to take? What transformations need to happen? "Enough" for what? I think that you need to define those things before anyone can come up with an answer. "all good practices should be employed" appears to be part of the assignment. Who deems that you have been successful in doing that? "Not keeping all the raw details" -- again, how do you know you have been successful? – schroeder Jan 3 '19 at 10:37
  • 1
    Your edit is a little better, but you do not explain how much of the original data needs to exist to process the data at a later time. Basically, you still have an undefined question. I would seriously ask your prof what they are talking about and what their criteria is. Always go back to stakeholders to verify the reqs and spec. – schroeder Jan 3 '19 at 13:53

As you mention, if you gather enough data, each key-feature pair will be well approximated by a gaussian distribution. In that case, instead of storing the timing counts ([(64,1), (169,2)]) or even the histograms ([("60-70",1), ("160-170",2)]`), you might want to consider storing the parameters of the inferred distribution - the average and the variance. Of course, that only works if your model can still work correctly from the inferred distribution.

Another thing to take in mind is to avoid storing short runs. Even if you store it in aggregated form, if you capture the moment when a user is typing a password, and the only keys that have valid distributions are 1, 5, 3, 4 and 2, that's not really ideal!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.