Re: Mitigating Dangers of Compromised Anonymity
I'd like to suggest that while this may be fun, usability and getting millions of users to see that remailers are useful to them is a more useful goal. The anonymity set provided by the current extant systems is too small to protect anyone against anyone who is willing to kill or disapear people as part of their attacks against the remailers. Oh, yeah, and incidentally, if you build this system, the attacker can simply add a bit of rubber hosing to their remop elimination program. Adam On Fri, Aug 30, 2002 at 06:14:32PM -0700, Meyer Wolfsheim wrote: | Operating an anonymity service or providing privacy enhancing | technologies to the public poses potential risks to the provider if | sufficiently motivated entities wish to prevent the availability of such | technology. | | In particular danger are individuals whose meatspace identity and nyms are | not publicly linked. If the attacker is able to compromise a nym and | silence the individual in meatspace, other anonymity providers and the | general public will have no way of knowing that this has occurred. | | This is information that is important to the public (who will want to know | if a remailer's operator has disappeared, though his remailer is still | operating) and to the other operators (who may be next.) | | Given the practice of remops hiding their identities, it would be somewhat | difficult to connect the sudden tragic death of a quiet computer | programmer in Arkansas with the abrupt silence of the operator of a | remailer in New York, whose ID is unknown to all but a very few.[1] | | Given the necessity of providing on-going administration for a remailer | server, and the lack of a viable IP-level anonymity system, a remop's | identity is almost surely known to any attacker who can observe network | traffic. Operating a remailer while concealing one's name from the general | public makes it easier for this attacker to hide one's disappearance from | the public, or delay their knowledge. Still, there are many compelling | reasons to operate an anonymity service or provide anonymity software | without revealing one's name. It would be desirable for a remop to be able | to do so without putting himself at greater than normal risk. | | Discussions with some members of the remailer operator community [2] have | lead me to propose the following "I am alive" monitoring system for | anonymous members. Although it was designed with remailer operators in | mind, this system could benefit other groups which face problems similar | to the ones described above (such as human rights workers and people with | Muslim-sounding last names who have recently emigrated to America). | | | "I'm not Dead Yet" | | 1. This system assumes that a stable, reliable monitoring server can be | operated in a fixed location on the Internet. | | The server stores a list of email addresses it is monitoring, a public PGP | key for each nym, and a datestamp "s" (which is a number in seconds) for | each nym. | | The server is configured with an "allowed silence period" variable "T", | which is an integer equal to the number of days a monitored member may be | without contact with the server and still be considered safe. | | 2. Users add themselves to the system by sending a signed administrative | request to the server's email address and providing the public key to be | used. Updates to the personal information for that nym can only be changed | by further administrative email requests signed by the same key. | | 3. The monitoring server publishes a unique random nonce each day on its | website and posted to USENET (in a suitable place such as | alt.privacy.anon-server). | | The server will store a rolling list of nonces and their issuance date for | the duration of T. | | 4. Members being monitored obtain this nonce, sign it with the key held by | the server, and submit an "I am alive" notification. | | 5. Upon receipt of this notification, the server resets the datestamp s | equal to the nonce issuance time. | | 6. If age of s (present time in seconds minus s) for any nym entry reaches | (T-3)*86400, the nym address is pinged with a message -- "Are you alive?". | If the nym's owner were alive and had simply forgotten to check in, he | could respond within three days to avoid a false alert. | | 7. If the age of s reaches T*86400, a "Missing Nym" alert is issued, | either to all of the other members of the monitoring service, a separate | alerts list, or a public forum. | | 8. The missing nym owner can declare a false alert by checking in through | the normal fashion. (There's an application for reputation tracking on | nyms who cry wolf). | | Notes: | | a) Nym owners will wish to communicate with the monitoring server | through anonymous remailers, as to avoid revealing their identities to the | monitoring system. | | b) This system makes no distinction between nyms and true names. It can | monitor email addresses of either. This could provide a useful system even | if one is not using a real nym. | | c) The PGP keys supplied to the nym server for purpose of ID verification | should be signing-only keys not used for any other purpose. This will | eliminate justification for a legal or quasi-legal entity to seize the | key. If a member is in the position to have his keys demanded from him, | it will be obvious that this is only being done for one purpose: so that | the public can be tricked into thinking he is alive and free (when | presumably he will not be.) This should aid him in his decision to comply | or not. | | | -MW- | | -- | | [1] Anonymity software developers who publish their products anonymously | are also potentially at risk. RProcess, the author of a popular Windows | remailer client and a Mixmaster-compatible Windows remailer server | suddenly "disappeared" from alt.privacy.anon-server a little over two | years ago. His absence was noticed almost immediately, because he had been | involved in several discussions and a major project at the time of his | disappearance -- but had he been a remailer operator or a developer with | little direct interaction with the public, he may have not been missed. | | [2] Peter Palfrader, Roger Dingledine, Len Sassaman, and Eric Arneson | contributed suggestions to this system. Bill Stewart provided the initial | suggestions. | -- "It is seldom that liberty of any kind is lost all at once." -Hume
On Fri, 30 Aug 2002, Adam Shostack wrote:
I'd like to suggest that while this may be fun, usability and getting millions of users to see that remailers are useful to them is a more useful goal.
I agree, although I fail to see how working on this would interfere with that goal in any way.
The anonymity set provided by the current extant systems is too small to protect anyone against anyone who is willing to kill or disappear people as part of their attacks against the remailers.
I find this disbelievable. I suspect there are many groups which do not have the capability of defeating the remailer system who would still like to see it eliminated. Willingness to kill or disappear people isn't necessarily tied to technical capability, though I agree that entities which can defeat the remailer network without "disappearing" anyone are unlikely to pose a threat to the remops. If our goal is to make remailers harder to defeat, however, beforehand might be the right time to address the problem of "missing remailer operators." (Incidently, I could see this having uses outside the remailer operator world.)
Oh, yeah, and incidentally, if you build this system, the attacker can simply add a bit of rubber hosing to their remop elimination program.
To pry the signing key out of the victim? That's a personal "how much torture can I take" question for the victim to ask himself. He knows he'll be permanently disappeared after coughing up the private key. In many cases also it might be far harder to rubber-hose someone than simply cause an "accident". -MW-
participants (2)
-
Adam Shostack
-
Meyer Wolfsheim