PaperlayerView exact revision on arXiv

Source-linked AI summary

HORNET: High-speed Onion Routing at the Network Layer

Chen Chen, Daniele Enrico Asoni, David Barrera, George Danezis, Adrian Perrig

arXiv:1507.05724v3cs.CR

TL;DR

HORNET addresses the need for scalable network-layer anonymity against pervasive surveillance. It carries protected session state in packets, enabling symmetric-cryptography forwarding without per-flow state. The system processes anonymous traffic at over 93 Gb/s, while its scope excludes targeted confirmation attacks and depends on network-layer anonymity assumptions.

  • Problem

    HORNET targets relationship anonymity against mass surveillance by preventing large-scale linking of communicating hosts.

  • Method

    HORNET carries encrypted per-session forwarding state in packets, allowing intermediate nodes to use symmetric cryptography without retaining per-flow state.

  • Results

    HORNET nodes process anonymous traffic at over 93 Gb/s while providing payload protection and defenses against attacks using multiple observation points.

  • Takeaways & Limitations

    HORNET demonstrates a network-layer path toward Internet-scale anonymity by combining high-speed forwarding with stronger security guarantees than earlier network-level schemes.

  • Takeaways & Limitations

    HORNET does not prevent targeted de-anonymization or flow-dynamics confirmation attacks against a small number of victims.

Abstract

from arXiv · show

We present HORNET, a system that enables high-speed end-to-end anonymous channels by leveraging next generation network architectures. HORNET is designed as a low-latency onion routing system that operates at the network layer thus enabling a wide range of applications. Our system uses only symmetric cryptography for data forwarding yet requires no per-flow state on intermediate nodes. This design enables HORNET nodes to process anonymous traffic at over 93 Gb/s. HORNET can also scale as required, adding minimal processing overhead per additional anonymous channel. We discuss design and implementation details, as well as a performance and security evaluation.

1. INTRODUCTION

HORNET addresses the performance and scalability limits of overlay anonymity networks by moving low-latency onion routing into the network layer. It combines payload protection and stronger security with stateless forwarding, achieving processing speeds close to high-end routers.

  • Tor supports low-latency anonymous communication but its overlay design requires per-connection state, limiting concurrent anonymous connections.
  • Earlier network-level schemes improve performance but weaken endpoint protection against distributed adversaries and rely on upper-layer payload protection.
  • HORNET provides payload protection and defends against attacks exploiting multiple network observation points while leveraging short underlying paths.
  • 93.5 Gb/s on a 120 Gb/s software router makes HORNET’s anonymous processing speed comparable to high-end commodity routers.
  • HORNET routers avoid per-flow state and expensive data-forwarding operations, allowing anonymous communication to scale.

2. PROBLEM DEFINITION

HORNET targets relationship anonymity against mass surveillance by hiding communication relationships at the network layer. Its scope excludes upper-layer identity exposure and targeted confirmation attacks.

  • HORNET aims to prevent large-scale linking of communicating hosts by adversaries conducting mass surveillance.
  • Sender anonymity hides the source from a public destination, whereas sender-receiver anonymity hides both endpoints’ locations.
  • The system conceals network location, while exposure through TCP sessions, credentials, or browser cookies remains out of scope.
  • The network model assumes nodes reveal only the next hop, with the destination disclosed only to the final node.
  • HORNET assumes privacy-preserving path and public-key retrieval, supported by an underlying architecture and verifiable key infrastructure.
  • The threat model includes compromised path nodes that observe traffic and can redirect, fabricate, replay, or modify packets.
  • HORNET does not prevent targeted de-anonymization or flow-dynamics confirmation attacks against a small number of victims.
  • Desired properties include path secrecy and integrity, no packet correlation, no session linkage, and payload secrecy with end-to-end integrity.

3. HORNET OVERVIEW

HORNET moves session state from intermediate nodes into protected packet headers, enabling symmetric-cryptography forwarding without per-session node state. Its setup, data transmission, and rendezvous designs support efficient anonymous communication, with nested headers doubling header size.

  • HORNET offloads session state to end hosts, embedding it in packets so each intermediate node extracts its forwarding state during processing.
  • A Forwarding Segment encrypts each node’s next hop, shared key, and expiration time, hiding this state from unauthorized parties.
  • One DH exchange occurs per session, while data packets use symmetric cryptography; setup requires O(n) propagation delay instead of Tor’s O(n^2).
  • A single-round Sphinx setup uses two packets to establish shared keys and collect forwarding segments along forward and backward paths.
  • During data transmission, the source prepends an AHDR and onion-encrypted payload, and each node retrieves its state, decrypts, and forwards the packet.
  • For hidden endpoints, a public rendezvous point relays traffic using nested AHDRs, while the source and destination remain unaware of each other’s locations.
  • Nested AHDRs allow any node to serve as a rendezvous point and support choosing a closer point, but double the header size.
  • Setup packets carry nested Sphinx packets and FS payloads, whereas data packets carry AHDRs and onion-encrypted payloads after a common header.

4. FORMAL PROTOCOL DESCRIPTION

The formal protocol defines HORNET’s cryptographic notation, path and packet structures, initialization, Sphinx-based setup, and forwarding-segment construction. These components let nodes process protected forwarding state without retaining per-flow state.

  • 4.1 Notation: HORNET’s notation fixes a 128-bit security parameter, path bounds, forwarding-segment sizes, cryptographic primitives, and forward or backward path terminology.
  • 4.1 Notation: The protocol uses common headers, Sphinx headers and payloads, FS payloads during setup, anonymous headers for data, and onion payloads for contents.
  • 4.2 Initialization: The source anonymously obtains forward and backward paths and verifies on-path public keys before generating a per-session Diffie-Hellman key pair.
  • 4.3 Setup Phase: Two setup packets traverse both paths and let intermediate nodes append encrypted forwarding segments without learning or modifying earlier segments.
  • 4.3.1 Sphinx Overview: Sphinx processing establishes one symmetric key per path node, enabling header integrity checks, onion payload decryption, and next-hop routing.
  • 4.3.2 Forwarding Segment: A forwarding segment contains a shared secret, routing segment, and expiration time, protected by a node-specific pseudorandom permutation key.
  • 4.3.3 FS Payload: The fixed-length FS payload adds new segments at the beginning while preserving secrecy, integrity, and concealment of path length and node position.
  • 4.3.3 FS Payload: FS payload initialization uses pseudorandom bits divided into blocks whose size combines a forwarding segment with a MAC.

2. D places the FS payload Pf of P➊into the Sphinx payload SPb

HORNET constructs anonymous headers from forwarding segments collected during setup, then uses them to route onion-encrypted data in both directions with symmetric cryptography.

  • Data transmission: Each data packet carries an anonymous header and onion-encrypted payload, allowing intermediate nodes to retrieve session state and process traffic using only symmetric cryptography.The anonymous header contains forwarding segments while the payload is processed hop by hop.
  • Header construction: The source constructs forward and backward anonymous headers from forwarding segments and shared keys collected during setup.The forward header enables source-to-destination transmission, while the backward header is sent in the first data packet for return traffic.
  • Header processing: Intermediate nodes verify header integrity and expiration, recover routing information and keys, then emit a processed header for the next hop.PROC_AHDR performs these operations and forwards the transformed header onward.
  • Payload processing: Forward payloads are onion-encrypted with one layer per path node, whereas backward payloads are re-encrypted hop by hop before the source removes the layers.The destination lacks the backward-path keys, so it begins the return direction with one layer and nodes add further layers.
  • Header construction: HORNET’s nested anonymous-header construction can double protocol-header bandwidth because the resulting header length becomes 2r instead of r.This cost arises when an AHDR contains a nested AHDR.

5. SECURITY ANALYSIS

HORNET’s security analysis proves correctness, integrity, wrap-resistance, and security under cryptographic assumptions, including negligible adversarial advantage in the stated games.

  • Security analysis: HORNET’s formal analysis targets correctness, integrity, wrap-resistance, and security as sufficient properties for ideal onion routing.The analysis also addresses de-anonymization and denial-of-service defenses.
  • Integrity: With much less than 2^k work, an adversary can traverse r + 1 honest nodes only with negligible probability.The proof sets the fixed upper bound to Q = r + 1 and derives a contradiction from the assumed forgery.
  • Wrap-resistance: With substantially less than 2^k work, an adversary can produce a wrapped message accepted by an uncompromised node only with negligible probability.The argument reduces successful generation of the required forwarding segment and secret to a negligible-probability event.
  • Security: The security game gives an adversary only negligible advantage in distinguishing packets associated with two alternative paths through an honest node.The proof replaces permutation, generator, and MAC outputs with randomness across a sequence of games.

5.2 Passive De-anonymization

HORNET analyzes passive de-anonymization by addressing session linkage, flow correlation, path leakage, and timing-based position identification.

  • Session linkage: Fresh independently generated session keys make sessions from the same host cryptographically indistinguishable from sessions created by different hosts.Sessions are not tied to long-term host secrets or identifiers.
  • Packet correlation: Fixed-length padding and per-hop packet obfuscation prevent linking packets by observed bit patterns or packet sizes, though traffic analysis can still reveal a common flow.The cited passage distinguishes packet-level correlation from recognizing that one flow crosses observation points.
  • Path length and node position leakage: Constant-length padded anonymous headers and encrypted forwarding segments conceal path length and node position during data transmission.The setup phase provides the corresponding protection through Sphinx-based processing.
  • Timing for position identification: Timing measurements remain a relevant de-anonymization concern, with countermeasures based on observing return traffic or adding response delay.A malicious node may attempt to infer its position from network delays to the source or destination.
  • Flow correlation: Independent forward and backward forwarding segments make direct flow linkage non-trivial, but upper-layer traffic patterns may still support correlation.This limitation applies even when a node lies on both paths.

5.3 Active De-anonymization

HORNET protects forwarding state through encrypted, integrity-checked forwarding segments, while fixed-size padding creates a bandwidth trade-off.

  • Session state modification: Encrypted forwarding segments carry node state, and source-computed per-hop MACs protect those segments during data transmission.The authentication key for each MAC is contained within the corresponding forwarding segment.
  • Packet correlation: Using fixed-size padding improves resistance to packet-size correlation but increases bandwidth, with two or three payload sizes offered as a bandwidth-optimized alternative at reduced anonymity.The alternative trades lower bandwidth overhead for decreased anonymity.
  • Session state modification: Modifying a forwarding segment changes the decrypted authentication key into a pseudorandom value, preventing successful state modification under the construction’s security argument.Each segment is encrypted with a pseudorandom permutation keyed by a secret known only to its creator.

5.4 Payload Protection

HORNET protects data payload confidentiality with end-to-end encryption, but omits per-hop payload integrity checks for efficiency. End-to-end MACs still allow hosts to detect large-scale tagging attacks.

  • End-to-end encryption protects data-packet confidentiality when the destination is honest and the cryptographic primitives are secure.
  • HORNET omits per-hop MACs on payloads for efficiency and because destinations cannot create MACs using nodes’ source-only session keys.
  • End-to-end MACs protect payload integrity and make large-scale tagging attacks detectable by the end hosts.

5.5 Denial-of-Service (DoS) Resilience

HORNET avoids state-based DoS because packets carry all session state, but asymmetric setup cryptography leaves nodes exposed to computational DoS. Network-layer paths also constrain anonymity, with topology and path knowledge reducing anonymity-set sizes.

  • Asymmetric cryptography during setup makes HORNET vulnerable to computational DoS through attackers initiating many sessions.Clients can be required to solve cryptographic puzzles, or ISPs can restrict access to paying customers.
  • All session state is carried in packets, so HORNET nodes and rendezvous points require no per-session memory against state-based DoS.
  • Topology-bound network-layer paths constrain HORNET’s possible sources, making network-topology knowledge an unavoidable anonymity limitation.HORNET uses short paths from the underlying network architecture rather than global overlay-network rerouting.
  • For adversarial ASes four hops from a victim, the anonymity set exceeds 2^31 in 80% of cases, with a maximum of 2^32 IPv4 addresses.
  • Path knowledge sharply reduces anonymity: at four hops, sets are below 2^28 in 90% of cases and average 2^23, falling to 2^17 at seven hops.
  • HORNET protects path length and node position, unlike prior network-layer systems that fail to hide or only partially obscure path information.

6. EVALUATION

HORNET’s evaluation measures forwarding latency, goodput, scalability, setup processing, path overhead, and the memory demands of stateful alternatives. The results show high throughput and stronger security trade-offs, while packet headers and path length constrain goodput and overhead.

  • Data forwarding performance: HORNET’s forwarding latency is 5% above LAP and Dovetail for 64-byte payloads but 71% higher for 1200-byte payloads, adding about 400 ns per packet on one core.The extra processing supports stronger security guarantees.
  • Goodput: For 1024-byte payloads, HORNET reaches 87% of LAP’s goodput while providing stronger security guarantees; for 40-byte payloads, its goodput is 32% below LAP and Dovetail.Larger path lengths increase header size and reduce goodput.
  • Scalability: 93.5 Gb/s is HORNET’s maximal aggregate forwarding throughput, with full 10 Gb/s per-port line rate through four cores and 6.8 Gb/s added per port thereafter.The measurement uses 7-AS-hop headers, 512-byte payloads, all 12 router ports, and uniform packet distribution.
  • Session setup performance: HORNET’s setup processing adds about 240 µs over data-packet processing, but this latency is incurred only once per session.The setup evaluation measures average per-node latency for the two session-setup packets.
  • Network evaluation: 99% of evaluated AS-level paths contain fewer than 7 ASes, with a mean length of 4.2, implying 201.6 bytes of average overhead for 128-bit security.The estimate uses 48 bytes per AS hop.
  • State scalability: A stateful design would require approximately 50 million circuits and almost 20 GB of memory on a 10 GbE edge router under the evaluated traffic assumptions.The estimate is based on about 1 million new flows per minute and at least 376 bytes per Tor circuit.

7. DISCUSSION

HORNET’s network-layer design supports anonymous communication across future Internet architectures while exposing explicit security trade-offs and deployment assumptions. It combines efficient path and state handling with defenses against several attacks, but does not prevent targeted confirmation attacks or provide session-level perfect forward secrecy by default.

  • Path acquisition: HORNET can obtain forward and backward paths through SCION path servers, PIR-based retrieval, or locally disseminated routing information in NIRA and Pathlets.PIR hides the requested destination from the path server but adds bandwidth, computation, and setup latency.
  • Deployment trade-offs: HORNET trades path length against anonymity because network-layer traffic redirection can enlarge end-host anonymity sets while deviating from valley-free routing.Upper- and lower-layer protections can further address topology-based, fingerprinting, and link-eavesdropping attacks.
  • Security limitations: HORNET cannot prevent targeted confirmation attacks when an adversary controls nodes near both endpoints, although scaling such attacks requires broad multi-ISP control and expensive flow analysis.Packet obfuscation, replay detection, and end-to-end MAC checks raise the operational difficulty of large-scale attacks.
  • Security limitations: HORNET does not provide perfect forward secrecy for sessions by default, because its efficiency-driven setup differs from Tor’s telescopic construction and reversible paths are not generally available.Perfect forward secrecy for communication contents remains possible through an ephemeral Diffie-Hellman key pair and refreshed destination secrets.

8. RELATED WORK

Related systems trade anonymity strength, latency, topology flexibility, and scalability in different ways. HORNET targets these trade-offs with network-layer forwarding, short paths, one-round-trip setup, and reduced relay and kernel processing.

  • Overlay anonymity systems: Mix networks provide strong resistance to active adversaries but incur high latency and computational overhead from asymmetric cryptography, batching, and mixing.Low-latency onion routing was developed to better support interactive traffic, while sharing vulnerabilities to confirmation and relationship-anonymity attacks.
  • Tor and HORNET: Tor provides replay protection, session perfect forward secrecy, and topology-independent global redirection, but its overlay design enables confirmation attacks by single compromised ASes.HORNET instead uses underlying short paths, one-round-trip setup, and avoids relay and kernel processing delays.
  • Network-layer and FIA systems: LAP and Dovetail offer network-layer low-latency anonymity but weaken endpoint protection against distributed adversaries and rely on upper-layer payload protection.Other FIA designs include a Tor-based network architecture without an Internet-scale solution for per-circuit state, and ANDaNA for NDN.

9. CONCLUSION

HORNET addresses pervasive surveillance with a scalable, high-speed onion-routing scheme for future Internet architectures. It processes anonymous traffic above 93 Gb/s without per-flow state, while small packet-header costs improve security without sacrificing high performance.

  • Conclusion: 93 Gb/s is the reported anonymous-traffic processing rate for HORNET nodes, which require no per-flow state and target Internet-scale anonymity.The conclusion frames HORNET as a minimal network-architecture mechanism for frustrating pervasive surveillance.
  • Conclusion: Small packet-header trade-offs improve HORNET’s security while retaining high performance.
  • Conclusion: HORNET is presented as a high-speed onion-routing scheme supported directly by future Internet architectures.
Loading 1507.05724v3…