0
Generic, Decentralized, Unstoppable Anonymity: The Phantom Protocol DEFCON 16 Presentation Magnus Bråding 2008
Short Author Presentation <ul><li>Magnus Bråding </li></ul><ul><ul><li>Swedish security researcher (Fortego Security)
10+ years in the security business
Central contributor and driving force behind w oodmann.com reverse engineering community </li></ul></ul>
Project Background (why is this interesting?) <ul><li>Big upswing in anti-online privacy measures recent years </li></ul><...
Private organizations tracking users and sites by misc illegal means
ISPs tracking and throttling arbitrary traffic
Data retention laws
Wiretapping laws (FISA / FRA)
Draconian laws for tracking and punishing P2P users </li><ul><li>ACTA and French laws to ban P2P users from the Internet
ISPs being forced to police the traffic of their users </li></ul><li>Abuse and misuse of global network blacklists, referr...
Dictatorships and other regimes with oppressed people censoring and tracking Internet use on an increasingly larger scale
Recent EU law proposal to register, track and regulate all bloggers! </li></ul></ul>
Project Background (why is this interesting?) <ul><li>A huge upcoming demand for anonymity seems unavoidable!
Existing anonymization solutions are in many ways not well suited for this upcoming demand and the circumstances surroundi...
There is no real “standard” for anonymization, like BitTorrent is for P2P
A perfect opportunity to get it right with a new solution, from the start! </li></ul>
Goals of the Project <ul><li>To be a good reference for future work within the field of anonymization
To inspire further discussion about the optimal requirements for the future anonymization demand
To be a starting point and inspiration for the design and development of a global de facto standard for generic anonymizat...
Not  to be a complete detailed specification ready to be implemented, but rather to be built upon </li></ul>
Limitations <ul><li>The protocol is designed to work in any network environment as long as no single attacker is able to e...
The protocol also contains built-in countermeasures to protect against attackers that are only able to monitor  parts  of ...
Further Assumptions and Directives <ul><li>Arbitrary random peers in the network are assumed to be compromised and/or adve...
CPU power, network bandwidth, working memory and secondary storage resources are all relatively cheap, and will all be ava...
Limitations of This Presentation <ul><li>Only an overview
Much more details in the white paper </li></ul><ul><ul><li>http://www.fortego.se/phantom-paper.pdf </li></ul></ul>
Design Goals
Design Goal Overview <ul><li>Very important with  well thought-out design goals, this is at least half the work in any suc...
The design goals are stipulated with the requirements and demand of today and the future in mind </li></ul>
Design Goal Overview <ul><li>Eight primary design goals: </li></ul><ul><ul><li>Complete decentralization
Maximum DoS resistance
Theoretically secure anonymization
Theoretically secure end-to-end encryption
Complete isolation from the ”normal” Internet
Protection against protocol identification
High Traffic Volume and Throughput Capability
Generic, Well-Abstracted and Backward Compatible </li></ul></ul>
Design Goal #1: Complete Decentralization <ul><li>No central or weak points can exist </li></ul><ul><ul><li>They  will  be...
Technically (DoS attacks, takedowns etc) </li></ul></ul></ul><ul><li>Both ownership and technical design must be decentral...
Design Goal #2: Maximum DoS Resistance <ul><li>The only way to stop a decentralized system without any legal owners is to ...
It only takes one weakness, so defensive thinking must be applied throughout all levels of the design </li></ul>
Design Goal #3: Theoretically Secure Anonymization <ul><li>Nothing should be left to chance
No security by obscurity
All anonymization aspects should be able to be expressed as a risk probability or a theoretical (cryptographic) proof </li...
Design Goal #4: Theoretically Secure End-to-End Encryption <ul><li>Confidentiality is not only important by itself, but al...
Design Goal #5: Isolation from the &quot;Normal&quot; Internet <ul><li>Users should not have to worry about Internet crime...
An isolated network is necessary to be able to enforce end-to-end encryption for generic traffic
Using an isolated network has many advantages, but not so many disadvantages in the end
Out-proxies to the ”normal” Internet can still be implemented on the application level, selectively </li></ul>
Design Goal #6: Protection against Protocol Identification <ul><li>Many powerful interests will lobby against a protocol l...
The harder it is made to positively identify the usage of the protocol, the harder it will be to track, throttle and block...
Design Goal #7: High Volume / Throughput Capacity <ul><li>The traffic volume for ”normal usage” of the Internet increases ...
More or less high speed / throughput is necessary for many Internet applications
Popularity will be proportionally related to transfer speed and volume
Anonymity is directly related to popularity </li></ul>
<ul><li>A generic system is practically always superior to a specific system in the long run
A well-abstracted system allows for efficient, distributed design and implementation
A system compatible with all pre-existing network enabled applications will get a much quicker takeoff and community penet...
A Bird’s-Eye View
The Basic Idea ! IP address of  α   = 5.6.7.8 ! IP address of  β   = 1.2.3.4 ? IP address of  β   = ??????? ? IP address o...
More About the Idea Each anonymized node prepares its own ”routing path”, which is a series of nodes ready to route connec...
Routing Paths Each anonymized node decide the size and composition of their own routing paths, affecting both the strength...
High Level Design
Routing Path - Generalization Anonymized node Intermediate node Arbitrarily many more intermediate nodes Terminating inter...
Routing Tunnels Anonymized node Intermediate node Arbitrarily many more intermediate nodes Terminating intermediate node W...
Routing Tunnels Anonymized node Intermediate node Arbitrarily many more intermediate nodes Terminating intermediate node S...
AP Addresses <ul><li>” Anonymous Protocol” addresses
Equivalent to IP addresses in their format
Upcoming SlideShare
Loading in...5
×

The Phantom Protocol: Generic, Decentralized, Unstoppable Anonymity

1,397

Published on

The Phantom anonymity protocol was designed in 2008 by Swedish security researcher Magnus Bråding to provide anonymity optimized for the current conditions and needs of average internet users. The design goal was feasibility for mass adoption as a de facto internet anonymization standard. This goal differentiates it from other anonymization protocols such as TOR, which have seen only limited adoption among the masses. The Phantom protocol designer hopes to change this situation and provide secure anonymity to everyone, including non-technical people.

The protocol was first presented publicly by Magnus Bråding at the IT security and hacking conference DEFCON 16 in Las Vegas 2008.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,397
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
33
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "The Phantom Protocol: Generic, Decentralized, Unstoppable Anonymity"

  1. 1. Generic, Decentralized, Unstoppable Anonymity: The Phantom Protocol DEFCON 16 Presentation Magnus Bråding 2008
  2. 2. Short Author Presentation <ul><li>Magnus Bråding </li></ul><ul><ul><li>Swedish security researcher (Fortego Security)
  3. 3. 10+ years in the security business
  4. 4. Central contributor and driving force behind w oodmann.com reverse engineering community </li></ul></ul>
  5. 5. Project Background (why is this interesting?) <ul><li>Big upswing in anti-online privacy measures recent years </li></ul><ul><ul><li>Huge pressure from media companies
  6. 6. Private organizations tracking users and sites by misc illegal means
  7. 7. ISPs tracking and throttling arbitrary traffic
  8. 8. Data retention laws
  9. 9. Wiretapping laws (FISA / FRA)
  10. 10. Draconian laws for tracking and punishing P2P users </li><ul><li>ACTA and French laws to ban P2P users from the Internet
  11. 11. ISPs being forced to police the traffic of their users </li></ul><li>Abuse and misuse of global network blacklists, referring to ”child porn”, while in reality being much more arbitrary censorship
  12. 12. Dictatorships and other regimes with oppressed people censoring and tracking Internet use on an increasingly larger scale
  13. 13. Recent EU law proposal to register, track and regulate all bloggers! </li></ul></ul>
  14. 14. Project Background (why is this interesting?) <ul><li>A huge upcoming demand for anonymity seems unavoidable!
  15. 15. Existing anonymization solutions are in many ways not well suited for this upcoming demand and the circumstances surrounding it
  16. 16. There is no real “standard” for anonymization, like BitTorrent is for P2P
  17. 17. A perfect opportunity to get it right with a new solution, from the start! </li></ul>
  18. 18. Goals of the Project <ul><li>To be a good reference for future work within the field of anonymization
  19. 19. To inspire further discussion about the optimal requirements for the future anonymization demand
  20. 20. To be a starting point and inspiration for the design and development of a global de facto standard for generic anonymization
  21. 21. Not to be a complete detailed specification ready to be implemented, but rather to be built upon </li></ul>
  22. 22. Limitations <ul><li>The protocol is designed to work in any network environment as long as no single attacker is able to eavesdrop all participating nodes in a correlated fashion, or directly controls a large majority of all nodes in the network </li></ul><ul><ul><li>Such an attacker will still never be able to see what participating nodes are talking about though, only who they are communicating with
  23. 23. The protocol also contains built-in countermeasures to protect against attackers that are only able to monitor parts of the network </li></ul></ul>
  24. 24. Further Assumptions and Directives <ul><li>Arbitrary random peers in the network are assumed to be compromised and/or adverse
  25. 25. CPU power, network bandwidth, working memory and secondary storage resources are all relatively cheap, and will all be available in ever increasing quantity during coming years and thereafter </li></ul><ul><ul><li>Thus, wherever a choice must be made between better security or better performance / lower resource consumption, the most secure alternative should be chosen (within reasonable bounds, of course) </li></ul></ul>
  26. 26. Limitations of This Presentation <ul><li>Only an overview
  27. 27. Much more details in the white paper </li></ul><ul><ul><li>http://www.fortego.se/phantom-paper.pdf </li></ul></ul>
  28. 28. Design Goals
  29. 29. Design Goal Overview <ul><li>Very important with well thought-out design goals, this is at least half the work in any successful project!
  30. 30. The design goals are stipulated with the requirements and demand of today and the future in mind </li></ul>
  31. 31. Design Goal Overview <ul><li>Eight primary design goals: </li></ul><ul><ul><li>Complete decentralization
  32. 32. Maximum DoS resistance
  33. 33. Theoretically secure anonymization
  34. 34. Theoretically secure end-to-end encryption
  35. 35. Complete isolation from the ”normal” Internet
  36. 36. Protection against protocol identification
  37. 37. High Traffic Volume and Throughput Capability
  38. 38. Generic, Well-Abstracted and Backward Compatible </li></ul></ul>
  39. 39. Design Goal #1: Complete Decentralization <ul><li>No central or weak points can exist </li></ul><ul><ul><li>They will be targeted </li><ul><li>Legally
  40. 40. Technically (DoS attacks, takedowns etc) </li></ul></ul></ul><ul><li>Both ownership and technical design must be decentralized </li></ul><ul><ul><li>Open/community owned design & source code </li></ul></ul>
  41. 41. Design Goal #2: Maximum DoS Resistance <ul><li>The only way to stop a decentralized system without any legal owners is to DoS it
  42. 42. It only takes one weakness, so defensive thinking must be applied throughout all levels of the design </li></ul>
  43. 43. Design Goal #3: Theoretically Secure Anonymization <ul><li>Nothing should be left to chance
  44. 44. No security by obscurity
  45. 45. All anonymization aspects should be able to be expressed as a risk probability or a theoretical (cryptographic) proof </li></ul>
  46. 46. Design Goal #4: Theoretically Secure End-to-End Encryption <ul><li>Confidentiality is not only important by itself, but also directly important to anonymity! </li></ul><ul><ul><li>Eavesdropped communication is highly likely to contain information of more or less identifying nature at some point! </li></ul></ul><ul><li>Even if someone would monitor and correlate all traffic at all points in the entire network, they should not be able to see what is communicated, no matter what </li></ul>
  47. 47. Design Goal #5: Isolation from the &quot;Normal&quot; Internet <ul><li>Users should not have to worry about Internet crimes being perpetrated from their own IP address
  48. 48. An isolated network is necessary to be able to enforce end-to-end encryption for generic traffic
  49. 49. Using an isolated network has many advantages, but not so many disadvantages in the end
  50. 50. Out-proxies to the ”normal” Internet can still be implemented on the application level, selectively </li></ul>
  51. 51. Design Goal #6: Protection against Protocol Identification <ul><li>Many powerful interests will lobby against a protocol like this, both to lawmakers and ISPs (who are already today filtering traffic)
  52. 52. The harder it is made to positively identify the usage of the protocol, the harder it will be to track, throttle and block it </li></ul>
  53. 53. Design Goal #7: High Volume / Throughput Capacity <ul><li>The traffic volume for ”normal usage” of the Internet increases every day
  54. 54. More or less high speed / throughput is necessary for many Internet applications
  55. 55. Popularity will be proportionally related to transfer speed and volume
  56. 56. Anonymity is directly related to popularity </li></ul>
  57. 57. <ul><li>A generic system is practically always superior to a specific system in the long run
  58. 58. A well-abstracted system allows for efficient, distributed design and implementation
  59. 59. A system compatible with all pre-existing network enabled applications will get a much quicker takeoff and community penetration, and will have a much larger potential </li></ul>Design Goal #8: Generic, Well-Abstracted and Backward Compatible
  60. 60. A Bird’s-Eye View
  61. 61. The Basic Idea ! IP address of α = 5.6.7.8 ! IP address of β = 1.2.3.4 ? IP address of β = ??????? ? IP address of α = ??????? β α
  62. 62. More About the Idea Each anonymized node prepares its own ”routing path”, which is a series of nodes ready to route connections and data for it If two anonymized nodes want to communicate, it is done by creating an interconnection between their individual routing paths α β
  63. 63. Routing Paths Each anonymized node decide the size and composition of their own routing paths, affecting both the strength of anonymity provided by them, and their maximum throughput capacity β α
  64. 64. High Level Design
  65. 65. Routing Path - Generalization Anonymized node Intermediate node Arbitrarily many more intermediate nodes Terminating intermediate node α
  66. 66. Routing Tunnels Anonymized node Intermediate node Arbitrarily many more intermediate nodes Terminating intermediate node Whenever the anonymized node wants to establish a connection to another node, a ”routing tunnel” is set up inside the already existing routing path Such a routing tunnel is set up relatively quick, and will then be connected to another routing tunnel inside another routing path, to form a complete anonymized connection α
  67. 67. Routing Tunnels Anonymized node Intermediate node Arbitrarily many more intermediate nodes Terminating intermediate node Such a routing tunnel is set up relatively quick, and will then be connected to another routing tunnel inside another routing path, to form a complete anonymized connection α β
  68. 68. AP Addresses <ul><li>” Anonymous Protocol” addresses
  69. 69. Equivalent to IP addresses in their format
  70. 70. Equivalent to IP addresses in functionality, with the exception that they allow communication between two peers without automatically revealing their identity
  71. 71. Backward compatible with IP applications </li></ul>
  72. 72. The Network Database <ul><li>Equivalent to the routing tables of the ”normal” Internet
  73. 73. Distributed and decentralized database based on DHT (Distributed Hash Table) technology </li></ul><ul><ul><li>Proven technology
  74. 74. Automatic resilience to constantly disappearing and newly joining nodes
  75. 75. Automatic resilience to malicious nodes of some kinds </li></ul></ul><ul><li>The network nodes are the database </li></ul>
  76. 76. Design Details
  77. 77. Secure Routing Path Establishment First, the nodes that will constitute the routing path are selected by the anonymized node A set of temporary ”helper nodes” are then also selected All the selected nodes are then ordered into a sequence The selection of the order of nodes in the sequence must obey the following rules: <ul><li>No two X-nodes can be adjacent to each other
  78. 78. A Y-node should be located in one end of the sequence
  79. 79. A number of Y-nodes equal to the total number of X-nodes minus one, should be located adjacent to each other in the other end of the sequence
  80. 80. One end of the sequence should be chosen at random to be the beginning of the sequence </li></ul>X X X Y Y Y Y Y Y 2 Y 4 Y 1 Y 8 X 5 X 7 X 3 Y 6 α
  81. 81. Secure Routing Path Establishment A ”goodie box” is prepared for each node, by the anonymized node Y 1 Y 2 X 3 Y 4 X 5 Y 6 X 7 Y 8 α
  82. 82. Secure Routing Path Establishment Another round is started, with a new goodie box for each participating node Y 1 Y 2 X 3 Y 4 X 5 Y 6 X 7 Y 8 X 3 X 5 X 7 α
  83. 83. Secure Routing Path Establishment Repeat The routing path is now securely established! α
  84. 84. The Goodie Box <ul><li>The routing path construction certificate </li></ul><ul><li>IP and port of next, and IP of previous node </li></ul><ul><li>Random IDs of next/previous node connections </li></ul><ul><li>Communication certificate of next/previous nodes </li></ul><ul><li>Seeds and params for dummy package creation </li></ul><ul><li>Seeds and params for stream encryption keys </li></ul><ul><li>Flags </li></ul><ul><li>A secure hash of the entire (encrypted) setup package array in currently expected state </li></ul><ul><li>A secure cryptographic hash of the (decrypted) contents of the current setup package </li></ul><ul><li>A signed routing table entry, for the AP address associated with the routing path </li></ul>Second round extras:
  85. 85. Secure Routing Tunnel Establishment (outbound) = = The anonymized node wants to establish a connection to a certain AP address It begins by sending a notification package through the routing path α
  86. 86. Secure Routing Tunnel Establishment (outbound) = = ! A new set of connections are created for the tunnel, and a reply package is sent through these The reply package enables the anonymized node to derive the keys of all the intermediary nodes, while it is impossible for any of them to derive any key with it themselves α
  87. 87. Secure Routing Tunnel Establishment (outbound) The anonymized node informs the exit node of the desired AP address to connect to The exit node performs the connection, and confirms a successful connection back to the anonymized node α
  88. 88. Secure Routing Tunnel Establishment (outbound) Repeat The connection is fully established at both ends, and the application layer can now start communicating over it! α
  89. 89. Secure Routing Tunnel Establishment (inbound) = = = ! An incoming connection request arrives to the entry node of the routing path The entry node sends an initialization package to the anonymized node The initialization package enables the anonymized node to immediately derive the keys of all the intermediary nodes, while it is impossible for any of them to derive any key with it themselves α β
  90. 90. Secure Routing Tunnel Establishment (inbound) = = = A new set of connections are created for the tunnel, and a reply package is sent through these The entry node confirms the connection to the external peer α β
  91. 91. Secure Routing Tunnel Establishment (inbound) It then confirms a successful connection back to the anonymized node α β
  92. 92. Secure Routing Tunnel Establishment (inbound) Repeat The connection is now fully established at both ends, and the application layer can start communicating over it! To achieve symmetry with outbound connections though, a dummy package is first sent over the tunnel This symmetry is important! α β
  93. 93. Secure End-to-End Encryption <ul><li>Once a full anonymized end-to-end connection has been established between two peers, double authenticated SSL can be used over it, as a final layer of encryption / authentication
  94. 94. The used certificates can be stored in the network database, in the individual entries for each AP address </li></ul>
  95. 95. IP Backward Compatibility <ul><li>Identical format and functionality of IP </li></ul><ul><ul><li>Address format
  96. 96. Port semantics
  97. 97. Connection semantics </li></ul></ul><ul><li>Binary hooks for all common network APIs </li></ul><ul><ul><li>No need for any application author assistance
  98. 98. No need for any application source code
  99. 99. The application won’t even know that its anonymized </li></ul></ul><ul><li>The common Internet DNS system can be used
  100. 100. Simple to start supporting IPv6 and similar too </li></ul>
  101. 101. The Network Database <ul><li>Contains separate tables </li></ul><ul><ul><li>Node IP address table, with associated info
  102. 102. Node AP address table, with associated info </li></ul></ul><ul><li>The database can be accessed through a specific strict API
  103. 103. Voting algorithms, digital signatures and enforced entry expiry dates are used on top of the standard DHT technology in some cases, to help enforce permissions and protect from malicious manipulation of database contents and query results
  104. 104. Resilient to ”net splits” </li></ul>
  105. 105. Manual Override Command Support <ul><li>Powerful emergency measure </li></ul><ul><ul><li>Protection against DoS attacks
  106. 106. Restoration after possible more or less successful DoS attacks
  107. 107. Protection against known malicious nodes </li></ul></ul><ul><li>Signed commands can be flooded to all clients </li></ul><ul><ul><li>Many DHT implementations natively support this feature
  108. 108. Commands signed by trusted party, e.g. project maintainers etc
  109. 109. Verification certificate hard coded into the client application </li></ul></ul><ul><li>Only commands for banning IP addresses, manually edit the network database etc, never affecting client computers!
  110. 110. No real worry if signing keys would leak or be cracked </li></ul><ul><ul><li>A minor update of the client could immediately be released, with a new key (verification certificate) hard coded into it, problem solved </li></ul></ul>
  111. 111. High-Availability Routing Paths
  112. 112. Aftermath
  113. 113. Legal Aspects & Implications <ul><li>File sharing example: </li></ul><ul><ul><li>Today: Lawsuits based on people connecting to a certain torrent
  114. 114. Lawsuits based on people using a certain file sharing program / protocol
  115. 115. Lawsuits against endpoints in anonymization networks
  116. 116. Lawsuits against routers on the Internet?
  117. 117. Lawsuits based on people using a generic anonymization protocol
  118. 118. Lawsuits based on people using cryptography?
  119. 119. Lawsuits based on people using the Internet? </li></ul></ul>
  120. 120. Legal Aspects & Implications <ul><li>License trickery? </li></ul><ul><ul><li>A license for the main specification, saying that a certain EULA must accompany all implementations of the protocol
  121. 121. The EULA in turn, would say that through using the protocol implementation in question, the user: </li></ul></ul><ul><ul><ul><li>Understands and agrees to that no node in the anonymous network can be held responsible for any of the data that is being routed through it, due to the simple fact that the user neither has any control over what such data may contain, nor any possibility whatsoever to access the data itself
  122. 122. Agrees to not use the protocol implementation to gather data that can or will be used in the process of filing a lawsuit against any of the network users that are just routing data </li></ul></ul></ul><ul><ul><li>Probably won’t work in many ways and several countries, but still an interesting line of thought to be investigated further </li></ul></ul>
  123. 123. Review of Design Goals <ul><li>Review of our eight original design goals: </li></ul><ul><ul><li>Complete decentralization
  124. 124. Maximum DoS resistance
  125. 125. Theoretically secure anonymization
  126. 126. Theoretically secure end-to-end encryption
  127. 127. Complete isolation from the ”normal” Internet
  128. 128. Protection against protocol identification
  129. 129. High Traffic Volume and Throughput Capability
  130. 130. Generic, Well-Abstracted and Backward Compatible </li></ul></ul>
  131. 131. Review of Design Goal #1: Complete Decentralization <ul><li>The protocol design has no central points, or even nodes that are individually more valuable to the collected function of the anonymous network than any other
  132. 132. Thus there are no single points of the network to attack, neither technically nor legally, in order to bring down any other parts of the network than those exact ones attacked </li></ul>
  133. 133. <ul><li>DoS resistance has been a concern during the entire design process, and has limited possible attack vectors substantially
  134. 134. Can always be improved though
  135. 135. Must continue to be a constant area of concern and improvement for future development </li></ul>Review of Design Goal #2: Maximum DoS Resistance ( )
  136. 136. Review of Design Goal #3: Theoretically Secure Anonymization <ul><li>All involved risk probabilities can be expressed in terms of other known probabilities
  137. 137. All security is based on cryptography and randomness, never on obscurity or chance
  138. 138. Hopefully no gaping holes have been left to chance, but review and improvements are of course needed, as always in security </li></ul>
  139. 139. Review of Design Goal #4: Theoretically Secure End-to-End Encryption <ul><li>All data is encrypted in multiple layers with well-known and trusted algorithms, protecting it from all other nodes except the communicating peers
  140. 140. All connections are wrapped by SSL, so the protection from external eavesdroppers should under all circumstances be at least equivalent to that of SSL </li></ul>
  141. 141. Review of Design Goal #5: Isolation from the &quot;Normal&quot; Internet <ul><li>It is impossible to contact and communicate with any regular IP address on the Internet from inside the anonymous network
  142. 142. The network can therefore not be used to anonymously commit illegal acts against any computer that has not itself joined and exposed services to the anonymous network, and thus accepted the risks involved in anonymous communication for these services </li></ul>
  143. 143. Review of Design Goal #6: Protection against Protocol Identification <ul><li>SSL connections are used as an external shell for all connections used by the protocol, and by default they also use the standard web server SSL port (tcp/443)
  144. 144. Thus, neither the port number nor any of the contents of the communication can be directly used to distinguish it from common secure web traffic
  145. 145. There are of course practically always enough advanced traffic analysis methods to identify certain kinds of traffic, or at least distinguish traffic from a certain other kind of traffic, but if this is made hard enough, it will take up too much resources or produce too many false positives to be practically or commercially viable </li></ul>
  146. 146. Review of Design Goal #7: High Volume / Throughput Capacity <ul><li>There is no practical way for a node to know if it is communicating directly with a certain node, or rather with the terminating intermediate node of one of the routing paths owned by this node
  147. 147. Intermediate nodes will never know if they are adjacent to the anonymized node in a path or not
  148. 148. Thus, single point-to-point connections between two nodes on the anonymous network, without any intermediate nodes at all (or with very few such), can be used while still preserving a great measure of anonymity, and/or ”reasonable doubt” </li></ul>
  149. 149. <ul><li>The protocol supports arbitrary network communication, i.e. generic anonymization
  150. 150. The protocol design is abstracted in a way that each individual level of the protocol can be exchanged or redesigned without the other parts being affected or having to be redesigned at the same time
  151. 151. The protocol emulates / hooks all TCP network APIs, and can thus be externally applied to any application that uses common TCP communication </li></ul>Review of Design Goal #8: Generic, Well-Abstracted and Backward Compatible
  152. 152. Comparison with Other Anonymization Solutions <ul><li>Advantages of Phantom over TOR </li></ul><ul><ul><li>Designed from the ground up with current and future practical anonymization needs and demand in mind
  153. 153. Compatible with all existing and future network enabled software, without any need for adaptations or upgrades
  154. 154. Higher throughput
  155. 155. No traffic volume limits
  156. 156. Isolated from the ”normal” Internet
  157. 157. End-to-end encryption
  158. 158. Better prevents positive protocol identification
  159. 159. Not vulnerable to ”DNS leak” attacks and similar </li></ul></ul>
  160. 160. Comparison with Other Anonymization Solutions <ul><li>Advantages of Phantom over I2P </li></ul><ul><ul><li>Compatible with all existing and future network enabled software, without any need for adaptations or upgrades
  161. 161. Higher throughput
  162. 162. End-to-end encryption
  163. 163. Better prevents positive traffic analysis identification </li></ul></ul>
  164. 164. Comparison with Other Anonymization Solutions <ul><li>Advantages of Phantom over anonymized P2P </li></ul><ul><ul><li>Less likely to be target of “general ban”
  165. 165. The generic nature of Phantom opens up infinitely much more potential than just binding the anonymization to a single application or usage area </li></ul></ul>
  166. 166. Known Weaknesses <ul><li>If all the nodes in a routing path are being controlled by the same attacker, this attacker can bind the anonymized node to the entry/exit node </li></ul><ul><ul><ul><li>No data can still be eavesdropped though, only what AP addresses it communicates with can be concluded
  167. 167. One very important detail is that it will be very hard for the attacker to conclusively know that its nodes actually constitute the entire path, since the last attacker controlled node will never be able to determine if it is actually communicating with the anonymized node itself, or with just yet another intermediate node in the routing path
  168. 168. The algorithms for routing path node selection can be optimized to minimize the risk of such a successful attack </li></ul></ul></ul>
  169. 169. Known Weaknesses <ul><li>If an attacker monitors the traffic of all nodes in the network, it will be able to conclude the same thing as in the previous weakness, without even having to doubt where the routing paths end </li></ul><ul><ul><ul><li>This has been stated as a limitation from the start though
  170. 170. Some anonymization protocols try to counter such attacks by delaying data and sending out junk data, but this goes against the high throughput design goal of Phantom </li></ul></ul></ul>
  171. 171. Known Weaknesses <ul><li>Individual intermediate nodes in a routing path could try to communicate their identity to other non-adjacent attacker controlled intermediate nodes in the same routing path, by means of different kinds of covert channels </li></ul><ul><ul><ul><li>Examples of such covert channels could be information encoding using timing or chunk size for communicated data
  172. 172. Could be countered to some degree by micro delays and data chunk size reorganization in intermediate nodes, but very hard to defend against completely
  173. 173. Again though, very hard for the attacker to conclusively know where in the path its nodes are located, since they will never be able to determine if they are communicating with another intermediate node or not, or even the direction of the path </li></ul></ul></ul>
  174. 174. Current State of the Project <ul><li>White paper ( http://www.fortego.se/phantom-paper.pdf ) </li></ul><ul><ul><li>An initial suggestion for requirements and design of the next generation anonymization protocol
  175. 175. Not a complete specification ready for immediate implementation, although quite detailed and comprehensive </li></ul></ul><ul><li>Presentation ( http://www.fortego.se/phantom-pres.ppt ) </li></ul><ul><ul><li>This presentation, provides good overview and contains some visualizations etc that are not in the white paper </li></ul></ul><ul><li>Google Code project ( http://code.google.com/p/phantom ) </li></ul><ul><ul><li>Code trunk (no code yet)
  176. 176. Discussion group
  177. 177. Wiki
  178. 178. Blog </li></ul></ul>
  179. 179. Summary, and Future of the Project <ul><li>The Internet, and its users, are in an increasingly bigger need of a good anonymization solution, meeting the requirements of today and beyond
  180. 180. The Phantom project aims to provide such a solution
  181. 181. The Phantom project so far has had the main goals of: </li></ul><ul><ul><li>Exploring the optimal requirements for such an anonymization solution
  182. 182. Providing examples of solutions for problems related to such a thing
  183. 183. Inspiring discussions about the design of such a system
  184. 184. Being the starting and central point for the emergence of an open de facto standard for free, secure and ubiquitous Internet anonymization </li></ul></ul><ul><li>The next phase of the Phantom project would be to discuss and stipulate the final protocol specification, and subsequently implement it </li></ul><ul><ul><li>This phase needs the help and collaboration of several knowledgeable and dedicated people – are you one of them?
  185. 185. Join in on the project site! </li></ul></ul><ul><ul><li>http://code.google.com/p/phantom </li></ul></ul>
  186. 186. Questions / Discussion If you come up with a question later on, feel free to ask me over a beer, or to contact me by email! [email_address]
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×