[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: user vulnerability in directory data?

On Wed, Dec 06, 2006 at 03:46:41PM -0600, Arrakistor wrote:
> Hello all,
> I  would like to know what data is kept in the data directory which is
> downloaded and created by the tor process. I have been discussing with
> roger  on  the deletion of dir data between torpark usages. My concern
> is  what  the  directory  data  may  indicate about the user, or if it
> contains sensitive information.

Here's what Tor stores in the data directory.  I've tried to annotate
the security implications of stuff, but I might have missed

A few general notes before I start:
- I'm assuming an adversary who discovers the contents of the data
  directory, but who can't change them without being detected.  If the
  attacker can alter files on the user's HD or USB drive, he's
  probably won.
- In addition to notes on sensitivity, every file will additionally
  leak the time at which it was last modified.
- If you're very concerned about this stuff, it isn't enough to delete
  the files; data recovery works.  Secure deletion isn't terribly
  reliable either without kernel support.

Here are the files:

    The most recently downloaded network status document for each
    authority.  Each file holds one such document; the filenames are
    the hexadecimal identity key fingerprints of the directory

    [Not sensitive AFAICT; everybody downloads the same network status
    documents from the same authorities unless they have configured a
    different set of authorities.]

    These files hold downloaded router statuses.  Some routers may
    appear more than once; if so, the most recently published
    descriptor is used.  The ".new" file is an append-only journal;
    when it gets too large, all entries are merged into a new
    cached-routers file.

    [Probably not sensitive.  As above, everybody downloads
    descriptors from the same routers, unless you have a nonstandard
    configuration (e.g., you've enabled FetchUselessDescriptors.)]

    A set of persistent key-value mappings.  These are documented in
    the file.  These include:
       - The current entry guards and their status.
         [Somewhat sensitive; this could be used by a roving attacker
         with eavesdropping capability.  I'm working on a patch to tie
         this stuff to IP, but that has security implications of its
         own that need to be worked through.]

       - The current bandwidth accounting values (unused so far; see

       - When the file was last written
         [Slightly sensitive; reveals a time when the user was using
         Tor.  Still, so does the mtime on all of the files, so it's
         not terribly useful.]

       - What version of Tor generated the state file
         [Probably not harmful in practice: an adversary who can get a
         copy of your state file can probably also look at your Tor
         binary, assuming you're carrying them around in the same

       - A short history of bandwidth usage, as produced in the router
         [Probably not sensitive, but unnecessary for non-servers.
         I'll restrict this to servers in the next release unless
         somebody tells me a good reason why not.]

    Used to track bandwidth accounting values (when the current period
    starts and ends; how much has been read and written so far this
    period).  Soon to be obsoleted by state.  Only used when
    bandwidth accounting is enabled.

    [Probably not sensitive; all the traffic analysis attacks I know
    about require comparatively fine-grained information about timing
    and volume.  "How many bytes did Tor write this week" is probably
    not terribly secret for most people.]

    Used for cookie authentication with the controller. Regenerated on
    startup.  See control-spec.txt for details.  Only used when cookie
    authentication is enabled.

    [Sensitive while Tor is running, but an attacker who can read your
    private files while Tor is running can probably win anyway.]

    Only used by servers.  Holds identity keys and onion keys.

    [This is very sensitive: if an attacker gets a copy of this
    directory, he can impersonate the server.  I'd like to add support
    for encrypting this stuff or storing it remotely in the future,
    but that would require some redesign.  See dir-voting.txt if
    you're interested.]

    Only used by servers.  Holds the fingerprint of the server's
    identity key.

    [Not sensitive.]

    Only used by servers. Holds the most recently generate router

    [Not sensitive.]

    Only used by directory authorities.  Holds a list of approved and
    invalidated routers.

    [Not sensitive.]

These are the files I found on a cursory glance through the code.
There may be more; please ask about any you may happen across.

> Roger has indicated that it may indeed
> be  a  concern  for  users, but I do not know to what extent or why. I
> have  emailed  Roger  on  this  subject  twice  but  have  received no
> response.  I  personally was not under the opinion that tor subscribed
> to  security through obscurity, so I ask again for this information to
> be released.

Please forgive the delay; things have been very busy here in Boston
for the last few days.  We do not in fact subscribe to security
through obscurity; our C code is public, but we recognize that not
everybody can read C, and so we try to make our documentation as
complete as we can.  This stuff should definitely go in the
documentation. Perhaps somebody could write up the above email for the
"FILES" section of the Tor manpage?

Nick Mathewson

Attachment: pgpOSEWNFjTc8.pgp
Description: PGP signature