jelena mirkovic (usc) peter reiher (ucla) building accountability into the future internet in proc....
TRANSCRIPT
JELENA MIRKOVIC (USC)PETER REIHER (UCLA)
Building Accountability into the Future Internet
In Proc. IEEE NPSec, 2009
Speaker: Yun Liaw
Nuggets of Wisdom for Accountability
07/21/09Speaker : Yun Liaw
2
Accountability mandates perfect identification of actors
Identification of sources must be cheap enough to be universal
Traffic filtering should occur as close to the sources as possible
It is desirable that servers can identify malicious clients before having any interaction with them
Contribution and Overview
07/21/09Speaker : Yun Liaw
3
Identify Spoofing Elimination: Lightweight unspoofable signature
Reducing Unwanted Traffic: Capability scheme built on top of unspoofable identities
Client reputation system
Identity Spoofing Elimination
07/21/09Speaker : Yun Liaw
4
Solution: To attach an unspoofable source signature to each packet
Mechanism: Trapdoor hash function with inversion property
Trapdoor Hash Functions
07/21/09Speaker : Yun Liaw
5
Hash key (public key): HKTrapdoor key (Private key): TKOne-way trapdoor hash function: h( )
Cheap to compute h(x) by knowing HK Collision free If TK is known, it is easy to find collision
Using Trapdoor Hash Functions for Identity Spoofing Elimination
07/21/09Speaker : Yun Liaw
6
1. Source publishes HK and the verification token V. And also enumerates sending packets with an increasing sequence number.
2. Verifiers store HK and V to verify the source. And also keep a short record of sequence numbers to prevent replay attacks
Using Trapdoor Hash Functions for Identity Spoofing Elimination
07/21/09Speaker : Yun Liaw
7
3. The source use any hash function to compute a hash m over the packets and the sequence number, then use the trapdoor key TK to find r so that h(m,r) = V+SEQp. The packet’s signature is r
4. Verifiers check the packet’s signature by calculating the hash over (m, r)
Using Trapdoor Hash Functions for Identity Spoofing Elimination
07/21/09Speaker : Yun Liaw
8
Source Verifier
Public Key HK, Verification Token V
m: the hash of packet contentr: the signature of the packet that can be found by TK
Packet, Seq. Number, m, rh(m,r) = V+SEQp
Verifier use HK to compute if h(m,r) = V+SEQp
And check Seq. Number to prevent replay attacks
Verifier stores HK, V to perform following verification
Scalability and Cost
07/21/09Speaker : Yun Liaw
9
Hierarchical signature scheme Each host signs its packet by the proposed approach When the packets leave the source AS, the border router
verifies the host-level signature and replaces it by the AS-level signature
In case of some untrusted ASes that do not verify host, the capability scheme could restrict the traffic from these Ases
Header space: total of 256 bits (including “ticket”)
Computing Cost Signing: 5 modular exponentions Verification: One hash operation
Key Management
07/21/09Speaker : Yun Liaw
10
Update of V and HK: Once per day via a push from the source to a representative node in the AS
Representative node: A server or router that updates the new key information to all other routers in the same AS
Bootstrapping Key Exchange for Peering Ases
Use traditional public-key approach for key exchange
ASes exchange the public key using out-of-band communication as they establish a peering relation
Reducing Unwanted Traffic
07/21/09Speaker : Yun Liaw
11
Destination-Generated Ticket Scheme1. Client issues a ticket request with server ticket to a
server2. Server generates a client ticket T = {sID, sAS, cID,
type=‘client’, lastValidTime, Sh) Sh = sign(sID, sAS, cID, type=‘client’, lastValidTime)
3. Server’s border router verify Sh and replaces it with AS-level signature
4. The client attaches T and Sas to each packet5. The routers on the path validate the freshness and the
ticket T
The validity of ticket should be short-lived – expected for several seconds
Building Client Reputations
07/21/09Speaker : Yun Liaw
12
Client-based reputation system: Be used for servers to issue ticket
Whether the ticket should be issued
To prioritize the ticket request handling
Client-Based Reputation System
The system collects reports from servers about client who have misbehaved The report contains client’s identity and the context of the
misbehavior Example: Worm traffic with a rate of x scans to port y per
second
Each report need to be accompanied with a traffic sample for proving the report context
The report from a server must be authenticated
The client that was a object of a bad report should be notified by the system
The system would aggregate the report into a reputation score
07/21/09Speaker : Yun Liaw
13
Client-Based Reputation System
Short-term reputation system Giving a higher weight to recent reports and
discounting old ones
Are used by servers to accept redeemed clients’ traffic during normal operation
Long-term reputation system Using all reports submitted in a recent and long time
interval
Are used during an attack, which leads to dropping of redeemed clients’ traffic
07/21/09Speaker : Yun Liaw
14
Deployment of Reputation System
Peer-to-peer design Each AS deploys a local reputation center
Reputation centers propagate reports or reputation scores
Compromised reputation center A center’s peer can monitor its updates and vouch for
correct score calculation
A server may need to contact several reputation centers for an update to minimize the risk of lying
07/21/09Speaker : Yun Liaw
15
Deployment of Reputation System
The overhead of reputation system communication May be large due to large-scale security incident, such
as worm attack A server should aggregate all its report within some
interval into a combined report
The distribution of reputation scores Periodically download by reputation users (server) Push by center when numerous bad reports indicate a
large-scale Internet incident
07/21/09Speaker : Yun Liaw
16
Related Work
Spoofing Elimination Passport, SPM
Unwanted Traffic Handling TVA, SIFF: Route-dependent DoS limiting architecture
Routers mark packets on route to destination, if destination accepts the communication, it would return the marks to the source as the “ticket”
Route-dependent architecture is invalid when route changes
Inflict collateral damage when ticket-request flooding
Client Reputations
07/21/09Speaker : Yun Liaw
17
Future Works
Implementation
PKI (for bootstrapping)
Issue of handling packets that come from malicious sources: indemnification system
Algorithms for computing reputation score
07/21/09Speaker : Yun Liaw
18
Comments
This is a conceptual paper which introduce some useful thoughts for enhance accountability
No concrete analysis or system implementation
Still have much issues to breakthrough
07/21/09Speaker : Yun Liaw
19