Upload
derrick-carpenter
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Class 7Network Protection and
Digital CurrencyCIS 755: Advanced Computer Security
Spring 2015
Eugene Vasserman
http://www.cis.ksu.edu/~eyv/CIS755_S15/
Administrative stuff
• Unofficial mid-semester evaluation
• Monday office hours moving to 2:30 (will be 2:30 – 4) starting March 23rd
– Except no office hours on March 23rd :(
• Don’t accidentally come to class next week :)
• Quiz after class
(Security) Problems with networking
• Many different systems– LANs, WANs, WLANs–Routers and switches–VLANs– Firewalls, gateways, VPNs
• Lots of work to configure independently• Enforcement at different layers– Each needs different security considerations
Layering (OSI 7-Layer Model)
• Application• Transport
– Lowest level end-to-end protocol
– Header generated by sender is interpreted only by the destination
– Routers treat transport header as part of the payload
• Network• Data link
4/54
App.App.
……
……
App.App.
……
……
TransportTransport
NetworkNetwork
Data LinkData Link
PhysicalPhysical
TransportTransport
NetworkNetwork
Data LinkData Link
PhysicalPhysical
NetworkNetwork
Router
MACMAC MACMAC
PHYPHY PHYPHY
Security goals
• Strict admission control• Topology hiding (why?)• Link-layer enforcement (below IP)– Less likely to unintentionally allow access
• Single trusted component• Simple management• Simple and fast revocation
Compare to Kerberos…
Potential solutions
• Self-configuring systems–Difficult to determine “correct” protection without
administrator intervention
• Gossiping security devices– Translations between rule-sets
• SANE uses a centralized infrastructure–Access control database–Automated rule generation and device
programming
The SANE approach
• Domain controller provides–Authentication service–Network service directory (NSD)–Protection layer controller
• Least-privilege approach (for enterprise)• Capability-based routing• SANE protocol header right after Ethernet• IPs used for wide-area, ignored locally
All roads lead to the DC
• DC is root of minimum spanning tree (MST)– Switches are the other nodes–Communication using distance vector (DV)• Like Ethernet
• Switches don’t learn network topology – they only see their neighbors in the tree–Can they misbehave in order to observe
topology?
DC: Bootstrapping topology info
• Communicate with nearest switches
• Compute shared keys• Receive topology updates• Repeat with next switch layer• Construct tree communication
capabilities• What can go wrong?
Protection layer controller
• Capability provider• Maintains global network view to
compute routes• Processes link state updated from
authenticated switches• Dynamically reprograms switches
Types of packets
• HELLO – discovery– Never forwarded, no authentication
• DC – capability (or revocation) request– Forwarded just to DC if no routing capability– Contains client authentication
• FORWARD – data packets (majority)– Capability, capability ID, expiration
• REVOKE– Capability ID, expiration, DC signature
What the switches do
• DC packets, revocation requests–Use tree (MST) to send to DC
• FORWARD packets–Check capability for validity• Semantically correct (valid MAC)• Not expired• Not revoked
– If valid, forward, otherwise discard
Capabilities
• Require no payload• Onion-wrapped• Encrypted/MACed• IV to prevent topology inference• Principal names in capability incorporate
both identity and route (sanity checks)
Backward compatibility
• Incoming and outgoing translation proxies• Capabilities are strictly richer than IP
infrastructure– Includes naming and addressing; can be
translated seamlessly by correct software
• Universal Plug-n-Play (UPnP)-like broadcast must be handled by DC– Increased load!
Tolerating horribleness
• What if a server “fails”?• A switch?• A gateway?• The DC?– Multiple DCs with multiple spanning trees– Byzantine consensus may be problematic in practice
• The physical network fabric?– Trees are fragile!
• Lots of recent work on centralized management controllers
Performance
• Tested using real network traces• DC can handle typical enterprise network load
using a desktop box– Multi-DC configuration untested
• O(n2) coordination messages may be a nasty surprise
• Switches need to be modified– Software-based forwarding almost impossible– Hardware-based crypto not easily upgradeable– Specific requirements unclear
Benefits
• Easier upgrades (may seem counter-intuitive)• Host [anti-]mobility• Transparent traffic rerouting– Logging– Transformation
• SSL, VPN
• Capabilities improve attack resistance• Built-in DoS resistance via revocation push-back– No coordination issues like Internet-wide schemes
Drawbacks
• Centralization can come back to bite you– Byzantine consensus can be costly
• Switches need to be updated• Incremental deployment requires “translator”
devices– “4D” features better incremental deployability
If you find this paper interesting I would strongly suggest reading “4D”
(http://portal.acm.org/citation.cfm?id=1096536.1096541 )
Who noticed problems?
• Corrections to eCash paper:–Published table incorrect–Number of communication rounds typo–Corrected paper at:
http://people.cis.ksu.edu/~eyv/papers/ecash-icdcs07.pdf
Applications of eCash
• Online payment– Lower processing costs than credit cards
• Micropayments–Content–Advertising replacement–New business models
Double-spending
• Chaum, 1982–Centralized online agent
• Offline double-spending detection–Chaum – 1988• Revocable anonymity– Problem!
• Brands - 1993– Tamper-proof agent/device (online)
Problem Statement
• Design an eCash scheme that provides–Anonymity–Real-time double-spending protection–Decentralization–No trusted hardware–No client security deposit–Practical/deployable
Witnesses
• Method to transform centralized entity into group of peers–Witnesses do online double-spending
detection
• Use merchants as witnesses–CCI assumption– Long-term presence assumption
• A coin is assigned uniquely to witness
Witnesses Challenges
• Who chooses witnesses?–Bank• Anonymity loss
–Client• Collaboration, load balancing/fairness
• Incentives
• Fairness
Withdrawal Key Points
• Witness selection based on h(bare coin) and witness list version/date
• Signature on witness assignment
• Broker does not know h(bare coin)!
Security Properties
• Provably untraceable and unlinkable
• Provably secure against forgery and re-use
Complexity Analysis
• Overhead– Should be dominated by network times
Exp Hash Sig Ver Comm
WithdrawalClient 12 4 0 1
2Broker 3 1 0 0
Payment
Client 0 3 0 1
3Witness 7 6 2 1
Merchant 7 6 0 3
DepositMerchant 0 0 0 0
1Broker 6 4 0 1
RenewalClient 12 5 0 1
2Broker 9 4 0 0
Implementation
• Proof of concept–Python 2.4–1200 lines of code in four modules
• Simplicity–REST (REpresentational State Transfer)
• Performance–Python crypto is less than stellar
Expiration Dates
• Two expiration dates:–After (1), coin:• Can be renewed• Can not be spent• Can not be deposited
–After (2), coin is completely useless
• Prevents broker coin database from growing too big
Summary II
• What stops collusion?
• What happens if compromised:–Broker?–Merchant?–Witness?–Client?