Advanced Deanonymization Attacks | Hacker News Reader

Advanced Deanonymization Attacks

whonix.org

139 pointsashitlerferad30 comments

"the timings of and between key presses are unique to each person". I wonder if there are more of these "features" and how many would take to build up a online profile of an user consistent regardless of the hardware used.

Thankfully I already switch to the hunt-n-peck method when using a public computer, access point, or VPN. Now I just need to learn Dvorak...

Such that you can be tracked by your hunt-n-peck timings?

Yeah. I bet there aren't many hunt-n-peck Dvorak typists in the world. It should be easy to determine.

Sure, that would be an issue. They tend to vary quite a bit more than my regular typing though. And I often go weeks or months without hunt-n-pecking, so it's really not a practiced method with a consistent timing.

Surely unique timings would still be unique using Dvorak.

Surely. But that assumes they consider the possibility I'm using Dvorak. And if I switch which keyboard layout I'm using it'll help more. (But honestly that's likely to be too much bother and I wouldn't follow through with that practice.)

So I saw that their planned "fix" was to introduce random latency to the key presses to hide the true timings, but does that really help anything?

When it comes to timing attacks in things like decryption or password comparisons, I thought random latency was a pointless addition as it only requires a bit more sampling before you can pull the underlying differences out.

Does it work in this instance just because the numbers involved are a few magnitude less would be with something like network requests?

I would have thought the same. However instead of adding random latency, one could have a buffer, that only allows a couple of fixed output rates (eg, 150,160,...,300 CPM), when typing. This would probably be quite annoying to type on though :-)

The best solution would probably be to have the HTML input field not fire events for key down.

It's fairly easy to create a div which behaves the same way as a HTML input field, and there are other ways. Ultimately I think you'd have to not fire key events, period.

Agreed, you'd have to fire string input rates, and defer the underlying update until either enough buffer has entered to warrant a mid-point sync, or input has paused for a decent length of time. (say 10s)

For 'hardened' browsers I'd recommend a visual indication of this timeout (a pie chart which completes like a clock at a fixed rate while paused is the first concept that I think of).

Yes, making it appear constant is the only real solution, if the attacker has access to multiple traces and is able to use some statistical tools.

But this still suppose that the attack is carried over the network. If the attacker can, e.g., monitor the electrical activity of the physical keyboard, then it's another thing entirely.

Ironically tho' delays between keypresses is an excellent source of entropy! So there is a circular dependency here which could be unravelled.

http://www.securiteam.com/securitynews/5UP0D2AAUK.html

Because of this, it is possible to measure keypress AND key release timings _very precisely_, for any console user of a machine we have an unprivileged account on.

Interestingly, Coursera uses these timings to authenticate that it is really you taking a quiz for one of their courses.

Most of the Coursera courses I took gave quizzes that were mainly multiple choice, this limiting the availability of a keystroke-corpus to identify the user.

Curious if this has changed recently to warrant this comment as the last course I took was a while ago.

Yeah, they're still multiple choice. They have you type a phase before you take the quiz.

At the start of the course they have you type the phrase once or twice to get your cadence and then take your picture afterwards.

I think the best solution for this would be to have a browser plugin take in key presses for input fields and pass it on the to field whenever there is a > 1 sec break in typing, or a tab is hit, etc.

Reading your comment and looking at the proposed solutions, it made me think of an interesting browser plugin, and wonder how it could affect this issue, or if it could even potentially solve it to a certain degree.

Wasavi. It's a plugin to emulate a small vim-like window on top of text-fields. You just Ctrl+Enter and it opens up, and when you save it (like vim with :wq or ZZ) it populates the field beneath it. It's quite interesting. I wonder if taking this approach to the extreme wouldn't make a difference? If all text fields were abstracted from the website and then the text sent in one stream, for all users.

I unfortunately do not possess the knowledge to understand if this is plausible or absurd, but wanted to at least discuss it publicly.

Edit: Wasavi on Github: https://github.com/akahuku/wasavi

This behavior does also exist for those accustomed to Vimperator, Pentadactyl or It's All Text plugins, but opening your default editor outside of the browser.

Edit 2: Wasavi supports many text input fields (including passwords), and can be configured to be enabled automatically on field focus.

Follow up: I went to one of the proposed websites that demonstrate deanonymization and tried the Wasavi method on their text fields. This is the message I've got:

Unable to enrol with your keystroke dynamics.

So yes, I'm adding this to my security toolkit.

Edit: Test https://www.keytrac.net/en/tryout

>> https://phabricator.whonix.org/T542 >> Attack summary: the timings of and between key presses are unique to each person. They are actively used in the wild to track individuals with extreme accuracy and leads to complete unmasking.

Holy sh*t

This is actually a very classical example of "side-channel". If you like this kind of things, I suggest you read (at least the beginning of) Silence on the wire, by Michal Zalewski.

This has been well-known for a long time. It's also much easier to circumvent than they project. Write your message somewhere, copy it, and paste it elsewhere in a single keystroke.

I have suggested a similar approach in a comment above but instead using a browser plugin with an overlay text editor or one that enables you to use your default text editor in a server/client model.

That's a wonderful idea. I think that all HTML inputs should fork your $VISUAL.

I didn't know about whonix recently. I actually discovered its existence in the table of contents of the latest 2600 (summer 2016, 33:2). I didn't get the time to read it yet.

How does it compare to Tails?

https://www.whonix.org/wiki/Comparison_with_Others

Tails is easier to set up, but Whonix is more secure. It compartmentalizes the Tor and anonymizing software away from the browser and other applications. To break Tor on Whonix, somebody would need to break the hypervisor (which is possible, but strictly more work than breaking Tor without breaking the hypervisor.)

I just ran the quick 3 min key press timing test. It was able to identify me with 99.08% accuracy and identify someone else using the same credentials as a 0% chance it was me...

SCARY

My coworker was identified as 98% similar. That disturbs me a bit more since I thought my typing style was more unique!

Reply on news.ycombinator.com