Introduce randommess in keypress timings
Alternatively all keystrokes could be done with fixed timing. The point is that no individual pattern should be discernable. There are more subtle aspects, such as jitter from perfectly regular timing, which could identify the machine/browser being used. With added randomness, such jitter would be harder to discern. Also, you would ideally not want eavesdroppers to know that you are obfuscating your keystrokes, and obfuscating via randomness, as opposed to fixed timing, would help with that. There are quite a few companies selling keystroke dynamics products as an authentication factor. There are also various efforts, such as one started at Stanford a few years ago, to monitor all aspects of a person's input, for continuous background authentication. Not sure how that one's going. Keystroke dynamics normally works on a short chosen phrase. The latter stuff is more ambitious and extends that to arbitrarily long text, along with grammatical patterns, etc. There is nothing new here. After evaluating several products for a company I worked for, I built a keystroke dynamics product myself -- it was less work than going through the pain of registering for a trial of their software! It was never used, for the same reason that kd is not used much -- it's more trouble than it's worth. It worked as well as any of the products being sold. Though a key down or key up event from the Windows operating system has a timestamp in it (the OS will not give you more than a certain accuracy, but it's adequate), that timestamp is discarded and not available in Javascript. My Javascript solution calls for a new Date as soon as it captures a key event. People selling this stuff say that as there is too much potential lag between the key event and the time thus associated, Javascript is not good. The best thing is something like an ActiveX plugin or a native client in C that can capture the timestamp from the OS. The next best thing was touted as Flash. However, mine worked very well. If anyone is interested I will describe in simple terms how one tests the keystroke vectors, and some of the challenges. mn
On 06/10/15 21:15, Michael Nelson wrote:
Alternatively all keystrokes could be done with fixed timing. The point is that no individual pattern should be discernable. There are more subtle aspects, such as jitter from perfectly regular timing, which could identify the machine/browser being used. With added randomness, such jitter would be harder to discern. Also, you would ideally not want eavesdroppers to know that you are obfuscating your keystrokes, and obfuscating via randomness, as opposed to fixed timing, would help with that.
My first thoughts were to use fixed timing but quickly realised that for fixed timing to work, EVERYONE using a keyboard/mouse would have to have their firmware modified otherwise your fixed timing would identify you just as surely as your genuine timing patterns. The randomness will also make each user appear as many different users - not just hiding existing users but giving the impression that there are many more users out there than truly exist (increasing the size of the haystack).
There are quite a few companies selling keystroke dynamics products as an authentication factor. There are also various efforts, such as one started at Stanford a few years ago, to monitor all aspects of a person's input, for continuous background authentication. Not sure how that one's going. Keystroke dynamics normally works on a short chosen phrase. The latter stuff is more ambitious and extends that to arbitrarily long text, along with grammatical patterns, etc. There is nothing new here.
After evaluating several products for a company I worked for, I built a keystroke dynamics product myself -- it was less work than going through the pain of registering for a trial of their software! It was never used, for the same reason that kd is not used much -- it's more trouble than it's worth. It worked as well as any of the products being sold.
Though a key down or key up event from the Windows operating system has a timestamp in it (the OS will not give you more than a certain accuracy, but it's adequate), that timestamp is discarded and not available in Javascript. My Javascript solution calls for a new Date as soon as it captures a key event. People selling this stuff say that as there is too much potential lag between the key event and the time thus associated, Javascript is not good. The best thing is something like an ActiveX plugin or a native client in C that can capture the timestamp from the OS. The next best thing was touted as Flash. However, mine worked very well.
This is exactly why modifying the firmware would be better than running software either within the OpSys or on top of it - by the time your software gets a look at the keystroke timing then another 'driver' etc could already have seen it. It is surprising to know that Javascript is fast enough not to have an impact on system performance when monitoring the keystroke timing!
If anyone is interested I will describe in simple terms how one tests the keystroke vectors, and some of the challenges.
Would be interesting to read this as there are probably many things I hadn't even considered, thanks :)
mn
On Tue, Oct 06, 2015 at 09:45:00PM +0100, oshwm wrote:
The randomness will also make each user appear as many different users - not just hiding existing users but giving the impression that there are many more users out there than truly exist (increasing the size of the haystack).
Are you sure adding randomness is undetectable? I would expect for pure physical reasons there is some general pattern in the typing of humans - some key pairs are faster, others are slower depending on the layout of keys.
On 07/10/15 06:37, Georgi Guninski wrote:
On Tue, Oct 06, 2015 at 09:45:00PM +0100, oshwm wrote:
The randomness will also make each user appear as many different users - not just hiding existing users but giving the impression that there are many more users out there than truly exist (increasing the size of the haystack).
Are you sure adding randomness is undetectable?
I would expect for pure physical reasons there is some general pattern in the typing of humans - some key pairs are faster, others are slower depending on the layout of keys.
In which case you'd need access to a lot of studies on these kinds of things in order to create more human timing with a degree of randomness. Hence why I said to MN that I'd welcome more detail on how the monitoring/attacks work so that I could change from my current simplified view of the issue to a more sophisticated one :) I guess you'd ideally have keyboard layout profiles for every locale so that you could emulate multiple locations rather than tying the fake user profile to a single country.
On Wed, Oct 07, 2015 at 07:29:28AM +0100, oshwm wrote:
In which case you'd need access to a lot of studies on these kinds of things in order to create more human timing with a degree of randomness. Hence why I said to MN that I'd welcome more detail on how the monitoring/attacks work so that I could change from my current simplified view of the issue to a more sophisticated one :) I guess you'd ideally have keyboard layout profiles for every locale so that you could emulate multiple locations rather than tying the fake user profile to a single country.
This might greatly decrease your score on fast keyboard navigated javascript game, say claiming to be capture ;) btw, in the subject is "mm" typo, joke or something else?
On 07/10/15 08:08, Georgi Guninski wrote:
On Wed, Oct 07, 2015 at 07:29:28AM +0100, oshwm wrote:
In which case you'd need access to a lot of studies on these kinds of things in order to create more human timing with a degree of randomness. Hence why I said to MN that I'd welcome more detail on how the monitoring/attacks work so that I could change from my current simplified view of the issue to a more sophisticated one :) I guess you'd ideally have keyboard layout profiles for every locale so that you could emulate multiple locations rather than tying the fake user profile to a single country.
This might greatly decrease your score on fast keyboard navigated javascript game, say claiming to be capture ;)
Surely we are way too serious ppl for javascript games :D
btw, in the subject is "mm" typo, joke or something else?
Ha ha, just noticed that, maybe we've been focusing on the wrong issue :D
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in. Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp. Travis On Wed, Oct 7, 2015, 5:14 AM Georgi Guninski <guninski@guninski.com> wrote:
On Wed, Oct 07, 2015 at 08:59:56AM +0100, oshwm wrote:
btw, in the subject is "mm" typo, joke or something else?
Ha ha, just noticed that, maybe we've been focusing on the wrong issue :D
Indeed, introducing RandomMess might border with steganography in some implementations ;)
On 07/10/15 14:25, Travis Biehn wrote:
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in.
Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp.
Fair point, has anyone ever produced a peer agreed priority ordered list of privacy and anonymity threatening devices or software etc classified with either solved/not solved? It's a simple stupid question and I probably know the answer but is it something needed so that globally all activists/coders/etc can work through it?
Lovely, I'm interested in the insanity that would ensue from trying to get 'these populations' to agree on priorities for development efforts. -Travis On Wed, Oct 7, 2015 at 10:21 AM, oshwm <oshwm@openmailbox.org> wrote:
On 07/10/15 14:25, Travis Biehn wrote:
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in.
Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp.
Fair point, has anyone ever produced a peer agreed priority ordered list of privacy and anonymity threatening devices or software etc classified with either solved/not solved?
It's a simple stupid question and I probably know the answer but is it something needed so that globally all activists/coders/etc can work through it?
-- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus <https://plus.google.com/+TravisBiehn>
On Wed, Oct 07, 2015 at 01:25:35PM +0000, Travis Biehn wrote:
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in.
Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp.
IMHO "gentlemans" may be offending/sexism to female ladies on this list (if any). "get drunk" may not work for japanese/chinese and possibly others who do not score on drinking well ;)
Is this a troll? Are you assuming I mean gentleman in a male centric context (you filthy 'genderist' you)? Perhaps I reserve the honorific for hermaphroditic crabs, and was only addressing them - as they make the best developers of privacy software (evidently.) -Travis On Wed, Oct 7, 2015 at 11:58 AM, Georgi Guninski <guninski@guninski.com> wrote:
On Wed, Oct 07, 2015 at 01:25:35PM +0000, Travis Biehn wrote:
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in.
Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp.
IMHO "gentlemans" may be offending/sexism to female ladies on this list (if any).
"get drunk" may not work for japanese/chinese and possibly others who do not score on drinking well ;)
-- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus <https://plus.google.com/+TravisBiehn>
On Wed, Oct 7, 2015 at 9:25 AM, Travis Biehn <tbiehn@gmail.com> wrote:
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in.
Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp.
Agreed that booze etc is potential. As is participating in foreign native language or orthagonal idea forums to you... since mimicry will modify your standard self. But only to the extent you do not adopt standard alter self. Couple with kernel keyboard driver parameters and it would seem a win.
Arduinos can do HID these days, probably wouldn't be hard to hack up a little USB that MITMs your keyboard and relays keys to the computer with random delay. Advantage: less obvious even to someone who's totally compromised the machine, so you could use at web cafes and the like. On 8 October 2015 08:02:01 IST, grarpamp <grarpamp@gmail.com> wrote:
On Wed, Oct 7, 2015 at 9:25 AM, Travis Biehn <tbiehn@gmail.com> wrote:
Normalizing / randomizing is fine. Anonymity sticks out, hasn't learned to blend in.
Keyboard timing is way down the list gentlemans. If you want to avoid it, get drunk every time you use a webapp.
Agreed that booze etc is potential. As is participating in foreign native language or orthagonal idea forums to you... since mimicry will modify your standard self. But only to the extent you do not adopt standard alter self. Couple with kernel keyboard driver parameters and it would seem a win.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Dnia czwartek, 8 października 2015 03:02:01 grarpamp pisze:
Agreed that booze etc is potential.
/thread -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147
participants (7)
-
Cathal (Phone) -
Georgi Guninski -
grarpamp -
Michael Nelson -
oshwm -
rysiek -
Travis Biehn