Anonymity and traceability in cyberspace

189 Pages·2005·1.65 MB·English

Technical Report
UCAM-CL-TR-653
ISSN 1476-2986
Number 653
Computer Laboratory
Anonymity and traceability
in cyberspace
Richard Clayton
November 2005
15 JJ Thomson Avenue
Cambridge CB3 0FD
United Kingdom
phone [phone]
http://www.cl.cam.ac.uk/
(cid:13)c 2005 Richard Clayton
This technical report is based on a dissertation submitted
August 2005 by the author for the degree of Doctor of
Philosophy to the University of Cambridge, Darwin College.
Technical reports published by the University of Cambridge
Computer Laboratory are freely available via the Internet:
http://www.cl.cam.ac.uk/TechReports/
ISSN 1476-2986
Anonymity and traceability in cyberspace
Richard Clayton
Summary
Traceability is the ability to map events in cyberspace, particularly on the Internet,
back to real-world instigators, often with a view to holding them accountable for
their actions. Anonymity is present when traceability fails.
I examine how traceability on the Internet actually works, looking first at a classical
approach from the late 1990s that emphasises the rˆole of activity logging and report-
ing on the failures that are known to occur. Failures of traceability, with consequent
unintentional anonymity, have continued as the technology has changed. I present
an analysis that ascribes these failures to the mechanisms at the edge of the net-
work being inherently inadequate for the burden that traceability places upon them.
The underlying reason for this continuing failure is a lack of economic incentives for
improvement. The lack of traceability at the edges is further illustrated by a new
method of stealing another person’s identity on an Ethernet Local Area Network
that existing tools and procedures would entirely fail to detect.
Preserving activity logs is seen, especially by Governments, as essential for the
traceability of illegal cyberspace activity. I present a new and efficient method
of processing email server logs to detect machines sending bulk unsolicited email
“spam” or email infected with “viruses”. This creates a clear business purpose for
creating logs, but the new detector is so effective that the logs can be discarded
within days, which may hamper general traceability.
Preventing spam would be far better than tracing its origin or detecting its trans-
mission. Many analyse spam in economic terms, and wish to levy a small charge
for sending each email. I consider an oft-proposed approach using computational
“proof-of-work” that is elegant and anonymity preserving. I show that, in a world
of high profit margins and insecure end-user machines, it is impossible to find a
payment level that stops the spam without affecting legitimate usage of email.
Finally, I consider a content-blocking system with a hybrid design that has been
deployed by a UK Internet Service Provider to inhibit access to child pornography.
I demonstrate that the two-level design can be circumvented at either level, that
content providers can use the first level to attack the second, and that the selectivity
of the first level can be used as an “oracle” to extract a list of thesites being blocked.
Although many of these attacks can be countered, there is an underlying failure that
cannot be fixed. The system’s database holds details of the traceability of content,
as viewed from a single location at a single time. However, a blocking system may
be deployed at many sites and must track content as it moves in space and time;
functions which traceability, as currently realized, cannot deliver.

Contents
1 In the beginning 11
1.1 Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Published work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Work done in collaboration . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Traditional traceability 17
2.1 Four steps to traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.1 Step 1: establish an IP address . . . . . . . . . . . . . . . . . 18
2.1.2 Step 2: establish the owner of the IP address . . . . . . . . . . 18
2.1.3 Step 3: establish the user account . . . . . . . . . . . . . . . . 19
2.1.4 Step 4: locate the user . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Classical problems with traceability . . . . . . . . . . . . . . . . . . . 26
2.2.1 Problems with step 1: establishing the IP address . . . . . . . 26
2.2.2 Problems with step 2: establishing the address owner . . . . . 28
2.2.3 Problems with step 3: establishing the user account . . . . . . 28
2.2.4 Problems with step 4: locating the user . . . . . . . . . . . . . 30
2.3 Traceability in the wider world . . . . . . . . . . . . . . . . . . . . . 30
2.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1 Traceability manuals . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.2 Tracing DoS and DDoS attacks . . . . . . . . . . . . . . . . . 35
2.4.3 Survivability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.4 The Freiburg privacy diamond . . . . . . . . . . . . . . . . . . 36
2.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5
6
3 Traceability failures 39
3.1 Dynamic connections . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.1 Network Address Translation . . . . . . . . . . . . . . . . . . 40
3.1.2 Dynamic Host Configuration Protocol . . . . . . . . . . . . . . 41
3.1.3 Data retention and validity . . . . . . . . . . . . . . . . . . . 41
3.2 New connection technologies . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.1 Traceability of 802.11 wireless . . . . . . . . . . . . . . . . . . 42
3.2.2 Traceability of ADSL . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3 Traceability of cable modems . . . . . . . . . . . . . . . . . . 44
3.3 Is CLI really trustworthy? . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Generic CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Forged CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Are logs all they’re cracked up to be? . . . . . . . . . . . . . . . . . . 49
3.4.1 Picking out the IP address . . . . . . . . . . . . . . . . . . . . 49
3.4.2 Log folding and other artifices . . . . . . . . . . . . . . . . . . 50
3.5 Confusing responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.1 Hijacking IP address space . . . . . . . . . . . . . . . . . . . . 51
3.5.2 Incorrect BGP announcements . . . . . . . . . . . . . . . . . . 53
3.5.3 Misleading traceroute . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.4 “Anonymous” Internet Relay Chat (IRC) . . . . . . . . . . . . 55
3.5.5 Preloading traceability information . . . . . . . . . . . . . . . 56
3.5.6 Establishing the source of email . . . . . . . . . . . . . . . . . 57
3.5.7 Misleading reverse DNS for email . . . . . . . . . . . . . . . . 58
3.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4 Hiding on an Ethernet 63
4.1 Machine identification on an Ethernet . . . . . . . . . . . . . . . . . . 63
4.1.1 Ethernet frames . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.1.2 Address Resolution Protocol . . . . . . . . . . . . . . . . . . . 65
4.1.3 Collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Previous work on identity spoofing . . . . . . . . . . . . . . . . . . . 66
4.3 How to hide on an Ethernet . . . . . . . . . . . . . . . . . . . . . . . 68
Contents 7
4.4 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.1 The Ethernet PHY . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.2 Implementing a MAC in an FPGA . . . . . . . . . . . . . . . 70
4.4.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5 Experimental results . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.6 Time limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.7 How firewalls can make collisions unnecessary . . . . . . . . . . . . . 81
4.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5 Extrusion detection 87
5.1 Traceability and spam . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2 The general approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Historical background . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5 Processing email logs . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.5.1 Email log contents . . . . . . . . . . . . . . . . . . . . . . . . 93
5.5.2 Using delivery failures to detect bulk email . . . . . . . . . . . 93
5.6 Avoiding “false positives” . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.1 Actual heuristics for detecting spam . . . . . . . . . . . . . . . 95
5.7 Heuristics that detect mass-mailing malware . . . . . . . . . . . . . . 96
5.7.1 Spotting email loops . . . . . . . . . . . . . . . . . . . . . . . 97
5.7.2 Leveraging other people’s detectors . . . . . . . . . . . . . . . 98
5.8 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6 Proof-of-work doesn’t work 103
6.1 Tackling spam through economics . . . . . . . . . . . . . . . . . . . . 103
6.2 Proof-of-work systems . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.1 Hashcash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.2 Avoiding a dependence upon processor speed . . . . . . . . . . 105
6.3 Quantitative analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.3.1 Estimating email volumes . . . . . . . . . . . . . . . . . . . . 106
6.3.2 The problem of mailing-lists . . . . . . . . . . . . . . . . . . . 107
6.4 How much work must be proved? . . . . . . . . . . . . . . . . . . . . 108
6.4.1 Analysis by considering the economics of spamming . . . . . . 108
6.4.2 Analysis by considering access to insecure machines . . . . . . 111
6.5 Variability in sending rates . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7 The BT ‘CleanFeed’ system and the failings of traceability 115
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2 Content-blocking systems . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2.1 Packet dropping . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2.2 DNS poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2.3 Content filtering . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.2.4 Existing content-blocking schemes . . . . . . . . . . . . . . . . 120
7.3 Design of the CleanFeed system . . . . . . . . . . . . . . . . . . . . . 120
7.4 Circumvention of the CleanFeed system . . . . . . . . . . . . . . . . . 122
7.4.1 Identifying the IWF and CleanFeed . . . . . . . . . . . . . . . 122
7.4.2 Evading CleanFeed . . . . . . . . . . . . . . . . . . . . . . . . 126
7.4.3 Circumvention by content providers . . . . . . . . . . . . . . . 131
7.4.4 Related work on evasion . . . . . . . . . . . . . . . . . . . . . 133
7.5 Attacking CleanFeed . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.5.1 Blocking legitimate content . . . . . . . . . . . . . . . . . . . 137
7.6 Real-world experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.6.1 Legal issues when experimenting upon CleanFeed . . . . . . . 139
7.6.2 Using CleanFeed as an oracle to list illegal websites . . . . . . 140
7.6.3 Countering the oracle attack . . . . . . . . . . . . . . . . . . . 143
7.7 Brightview’s WebMinder system . . . . . . . . . . . . . . . . . . . . . 144
7.8 The failings of traceability . . . . . . . . . . . . . . . . . . . . . . . . 145
7.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8 Conclusions and future work 149
Annotated bibliography 153
Glossary 183
Acknowledgements
No programme of PhD work is ever done alone and so I must start by acknowledging
the help and assistance of many people.
My supervisor Ross Anderson initially suggested that I might enjoy leaving indus-
try behind and returning, after nearly thirty years, to Cambridge. His help and
encouragement has been invaluable throughout. My previous employers at Demon
Internet (Thus plc) have also been entirely supportive. Phil Male has kept me on
as a consultant; this led directly to some of the work I describe. Andrew Bangs,
Simon Edwards, Clive Feather, James Hoddinott, Alex Kiernan, Chris King and
many other colleagues have ensured that I had the information I needed and that I
remained grounded in addressing real problems.
Elsewhere in industry, I’ve been assisted by many others of whom I will pick out
Andrew Hilborne and Keith Mitchell for their assistance in recalling the start of
traceability as an accurate process, but there have been many others whose observa-
tions I report in this thesis. Other colleagues from law enforcement and government
have assisted my understanding of the issues from their side of the fence, and they
provide some of the anecdotes and examples that I present. I specially note Paul
Bayer, Tony Hutchings and Simon Watkin, but there are many others as well.
David Greaves, Simon Moore, Sergei Skorobogatov and James Srinivasan have con-
tributed hardware and advice to assist with my Ethernet collision design, and Ben
Laurie helped with the DNS needed for the testing of email header reading skills.
My co-authors on academic papers, Ross Anderson, Mike Bond, George Danezis,
Markus Kuhn, Ben Laurie, Andrei Serjantov and Ellis Weinberger have of course
contributed greatly to my grasp of the subject of Computer Security, the topic into
which Traceability seems to fit best. In addition, there have been countless valuable
discussions with Jon Crowcroft, Stephen Lewis, Steven Murdoch and all the other
members of the Computer Security group; not forgetting the sadly missed Roger
Needham and David Wheeler.
I’ve also been much assisted by my two partners, one business, one life, Chris Hall
and Chris Taylor. I would never have finished without their support.
Although I was initially “self-funded”, since October 2003 I have been employed on
the Cambridge Massachusetts Institute project “The Design and Implementation of
Third Generation Peer-to-Peer Systems” and I am grateful for this assistance.
Finally, I owe a great debt to those who have prooofread this thesis and the papers
on which some of it is based. These include Ross Anderson, George Danezis, Simson
Garfinkel, TonyHutchings, StephenLewis, TylerMooreandStevenMurdoch. Allof
the remaining errors are of course my responsibility, but at least they have spotted
numerous other howlers before anyone else read it.
10