user vulnerability in directory data?
Nick Mathewson
nickm at freehaven.net
Wed Dec 6 22:49:48 UTC 2006
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
something.
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:
cached-status/*
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
authorities.
[Not sensitive AFAICT; everybody downloads the same network status
documents from the same authorities unless they have configured a
different set of authorities.]
cached-routers
cached-routers.new
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.)]
state
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
below).
- 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
place.]
- A short history of bandwidth usage, as produced in the router
descriptors.
[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.]
bw_accounting
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.]
control_auth_cookie
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.]
keys/*
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.]
fingerprint
Only used by servers. Holds the fingerprint of the server's
identity key.
[Not sensitive.]
router.desc
Only used by servers. Holds the most recently generate router
descriptor.
[Not sensitive.]
approved-routers
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?
hth,
--
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20061206/d1f3588d/attachment.pgp>
More information about the tor-talk
mailing list