1. Class 7 Network Protection and Digital Currency CIS 755: Advanced Computer Security Spring 2015 Eugene Vasserman http://www.cis.ksu.edu/~eyv/CIS755_S15/

2. Administrative stuff Unofficial mid-semester evaluation Monday office hours moving to 2:30 (will be 2:30 – 4) starting March 23 rd – Except no office hours on March 23 rd :( Don’t accidentally come to class next week :) Quiz after class

3. (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

4. 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. … … … … … … … … Transport Network Data Link Physical Transport Network Data Link Physical Network Router MAC PHY

5. 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…

6. 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

7. 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

8. Initialization/authentication

9. 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?

10. 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?

11. Protection layer controller Capability provider Maintains global network view to compute routes Processes link state updated from authenticated switches Dynamically reprograms switches

12. 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

13. Source routing with capabilities B, data S3 S2 S1 B S3 S2 S1 A

14. 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

15. Capabilities Require no payload Onion-wrapped Encrypted/MACed IV to prevent topology inference Principal names in capability incorporate both identity and route (sanity checks)

16. 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!

17. 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

18. Performance Tested using real network traces DC can handle typical enterprise network load using a desktop box – Multi-DC configuration untested O(n 2 ) 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

19. 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

20. 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 ) http://portal.acm.org/citation.cfm?id=1096536.1096541

21. Questions? Reading discussion

22. 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/e cash-icdcs07.pdf

23. What is eCash? Merchant eWallet Wallet Exchanger

24. Properties of eCash Unforgeability Non-reusability Anonymity – Untraceability – Unlinkability

25. Comparisons eCash versus – Cash – Credit cards – Micropayments Motivations – Like cash, but digital!

26. Applications of eCash Online payment – Lower processing costs than credit cards Micropayments – Content – Advertising replacement – New business models

27. Challenges Double-spending – What is it? – Why is it a problem?

28. Double-spending Chaum, 1982 – Centralized online agent Offline double-spending detection – Chaum – 1988 Revocable anonymity – Problem! Brands - 1993 – Tamper-proof agent/device (online)

29. Problem Statement Design an eCash scheme that provides – Anonymity – Real-time double-spending protection – Decentralization – No trusted hardware – No client security deposit – Practical/deployable

30. Key Players Broker WitnessClient Merchant

31. 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

32. Witnesses Challenges Who chooses witnesses? – Bank Anonymity loss – Client Collaboration, load balancing/fairness Incentives Fairness

33. Withdrawal Broker Client Hi

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

35. Commit Witness Client

36. OK Payment Client Merchant Witness

37. Payment Key Points “Bare coin” – Includes secret extractable information – Signed by broker

38. OK Redeem Broker Merchant

39. Security Properties Provably untraceable and unlinkable Provably secure against forgery and re-use

40. Complexity Analysis Overhead – Should be dominated by network times ExpHashSigVerComm Withdrawal Client12401 2 Broker3100 Payment Client0301 3 Witness7621 Merchant7603 Deposit Merchant0000 1 Broker6401 Renewal Client12501 2 Broker9400

41. 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

42. 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

43. Future work Performance – Convert to OpenSSL call blocks Firefox extension – Payment tag plus Java extension to implement client-side crypto

44. Summary I Broker WitnessClient Merchant

45. Summary II What stops collusion? What happens if compromised: – Broker? – Merchant? – Witness? – Client?

46. Questions? Reading discussion