[tor-dev] Hash Visualizations to Protect Against Onion Phishing

[George Kadianakis]

Hello,

this mail lays down an idea for a TBB UI feature that will make it slightly
harder to launch phishing attacks against hidden services. The idea is based on
hash visualizations like randomart [0] and key poems:

            -------------------
			|       o=.       |
			|    o  o++E      |
			|   + . Ooo.      |
			|    + O B..      |
			|     = *S.       |
			|      o          |
			|                 |
			|                 |
			|                 |
            -------------------

The idea came up during a discussion with Jeff Burdges in CCC camp.
This is a heavily experimental idea and there are various unresolved research
and UX issues here, but we hope that we will motivate further study.

The aim is to make it harder to phish people who click untrusted onion links.
Think of when you click an onion link on a forum, or when a friend sends you an
onion URL.

The problem is that many people don't verify the whole onion address, they just
trust the onion link or verify the first few characters. This is bad since an
attacker can create a hidden service with a similar onion address very
easily. There are currently ready-made scripts that people have been using to
launch impersonation attacks against real hidden services.

The suggested improvement here is for TBB to provide additional visual
fingerprints that people can use to verify the authenticity of a hidden service.
So when TBB connects to a hidden service, it uses the onion address to generate
a randomart or key poem and makes them available for the user to examine.

Here is an experimental mockup just to illustrate the idea:

    https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png

The idea is that you hash (or scrypt!) the onion address, and then you make a
visualization using the hash output. This forces the phishing attacker to
generate a similar onion address _and_ similar hash visualizations. We assume
that this will be harder to do than simply faking a similar onion address, which
increases the startup cost for such an attacker.

This is the basic concept. Now, here are some thoughts:

- What hash visualizations can we use here?

  The SSH randomart is an obvious idea, and we can even have it colored since we
  are not in a terminal.

  Then we have the key poem idea, which generates a poem from a key. I don't
  think this is used by a deployed system currently.

  Then we could imagine music-based hash fingerprints, where the onion address
  corresponds to a small tune that is played when you visit an onion.

  Then there are even more crazy ideas like the "Dynamic Security Skins"
  paper [1]. So for example, TBB could generate a unique UI theme for each
  hidden service.
  
- Of course, none of the above ideas is perfect. Actually most of them suck.

  For example, when it comes to randomart, many people are colorblind to some
  degree and most people are not good at recognizing subtle color differences.

  Furthermore, given a randomart, it's easy [2] to generate similar
  randomarts. However we hope that most of those similar randomarts will not
  correspond to a public key that is similar to the original one. 

  When it comes to key poems, given even a moderately sized dictionary leads to
  pretty big poems. We are talking about poems of 24 random words, which is not
  something that most people can remember.

  Much more research needs to be done here.

- Even though all these techniques are flawed in some way or another, we hope
  that by deploying them we increase the cost of the attacker.

  If a few of these techniques are implemented, a phishing attacker will have to
  spend time generating similar visualizations, because she does not know
  whether the user actually looks at them and which one the user prefers.

  Also, this feature only requires a TBB addon/patch and no modifications to the
  Tor protocol whatsoever, which makes it slightly easier to prototype and
  experiment with.

- On the other hand, this might be a terrible idea for multiple reasons.

  From the UX perspective, it will confuse people who don't expect to see crazy
  visuals or poems on their browser. Our hope here is that this feature will be
  hidden by most users, and will only be used by people who understand it.
  However, this exact logic is what causes bad UI.

  Also, from a security perspective this might encourage people to not spend
  time to verify the whole onion address (currently 16 chars, but will be
  extended to 54 chars or so with prop224), and instead rely on the stupid
  randomart.

  Some real UX research needs to be done here, before we decide something terrible.

- Finally, a positive thing with this idea is that it nicely complements
  directories of onion addresses like search engines and human-memorable
  systems. In the future, people who visit the same onion address using a search
  engine all the time, will have an extra way of verifying its authenticity.

In any case, this is just a crazy pants idea, so please send your feedback to
make it more useful, or to kill it completely!

Cheers!~

[0]: http://undeadly.org/cgi?action=article&sid=20080615022750
     http://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf

[1]: http://www.eecs.berkeley.edu/~tygar/papers/Phishing/Battle_against_phishing.pdf

[2]: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf