Class 7 Network Protection and Digital Currency CIS 755: Advanced Computer Security Spring 2015 Eugene Vasserman eyv/CIS755_S15

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

Initialization/authentication

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

Source routing with capabilities

B, dataS3S2S1 B

S3

S2

S1

A

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 )

Questions?

Reading discussion

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

What is eCash?

MerchanteWallet

Wallet

Exchanger

Exchanger

Properties of eCash

• Unforgeability

• Non-reusability

• Anonymity–Untraceability–Unlinkability

Comparisons

• eCash versus–Cash–Credit cards–Micropayments

• Motivations– Like cash, but digital!

Applications of eCash

• Online payment– Lower processing costs than credit cards

• Micropayments–Content–Advertising replacement–New business models

Challenges

• Double-spending

–What is it?

–Why is it a problem?

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

Key Players

Broker

WitnessClient

Merchant

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

Broker

Client

Hi

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)!

Commit

Witness

Client

OK

OK

Payment

Client

Merchant

Witness

Payment Key Points

• “Bare coin”– Includes secret extractable information– Signed by broker

OK

Redeem

Broker

Merchant

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 I

Broker

WitnessClient

Merchant

Summary II

• What stops collusion?

• What happens if compromised:–Broker?–Merchant?–Witness?–Client?

Questions?

Reading discussion