expressive Internet Architecture Security Concepts

Transcription

1 expressive Internet Architecture Security Concepts Adrian Perrig Peter Steenkiste, Dave Andersen, David Eckhardt, Sara Kiesler, Jon Peha, Srini Seshan, Marvin Sirbu, Hui Zhang Carnegie Mellon University Aditya Akella, University of Wisconsin John Byers, Boston University Bruce Maggs, Duke June 1, 2015, MIT

2 Narrow Waist of the Internet Key to its Success! Has allowed Internet to evolve dramalcally! But now an obstacle to addressing challenges: Applications Internet Protocol Link Technologies No built- in security New usage models a challenge content and services, not hosts Hard to leverage advances in technology in network Limited interaclons between network edge and core! But where do we get started?

3 Three Simple Ideas! DesLnaLons are hosts Typing supports mullple deslnalon types Principals can be: hosts, but also content, services, etc. Matches applicalons, reduced complexity and overhead! No network level security Intrinsic security offers authenlcity of endpoint Does not rely on external configuralons, data bases,.. Accountability, address agility,! One way of reaching deslnalon Flexible addresses offer diverse delivery oplons Include both intent and fallback address Evolvability, network diversity, fault recovery, mobility,.. 4

4 Multiple Principal Types! Associated with different forwarding seman.cs Support heterogeneity in usage and deployment models! Hosts XIDs support host- based communicalon who?! Service XIDs allow the network to route to possibly replicated services what does it do? LAN services access, WAN replicalon,! Content XIDs allow network to retrieve content from anywhere what is it? OpportunisLc caches, CDNs,! Set of principal types can evolve over Lme 5

5 Intrinsic Security in XIA! XIA uses self- cerlfying idenlfiers that guarantee security properles for communicalon operalon Host and service ID are a hash of its public key correct deslnalon and accountability (AIP) Content ID is a hash of the content correctness Does not rely on external configuralons! Intrinsic security is specific to the principal type! Useful to manage addresses securely and for bootstrapping e- e security solulons! Many other oplons, e.g., CID variants, non- PKI, 6

6 Flexible Addressing: DAGs Support Scoping and Fallbacks Client side Server- side domain hierarchy CID S NIS S HID S 7

7 Main Security Properties! Trust management How to set up trust relalons, roots of trust! AuthenLcity / integrity AuthenLcaLon of user, host, domain, service, content! AuthenLcaLon and Accountability Both authorizalon and deterrence, respeclvely! Secrecy of idenlty, anonymity, privacy Sender / receiver privacy if desired! Availability CommunicaLon availability (hosts and services) Finding nearby contents and services Defenses against DoS aeacks

8 Overview! Global trust architecture IsolaLon domains PKI for roulng PKI for services, domains PKI for endhosts Intrinsic security for CID, SID! Control plane security! Data plane security! Anonymity and privacy 9

9 Non-Scalability of Trust! As the Internet has grown to encompass a large part of the global populalon, not everyone trusts everyone else on the Internet any more! The heterogeneity of global environment complicates enlty authenlcalon infrastructures Relevant in this context: authenlcalon of roulng updates, DNS replies, TLS cerlficates! Two models for trust roots for authenlcalon Monopoly model Oligarchy model 10

10 Monopoly Model for Trust Root! Single root of trust (i.e., root public key) that is globally accepted to authenlcate enlles! Examples: RPKI for BGPSEC or DNSSEC rely on a public key that forms root of trust All AS cerlficates or DNS records are authenlcated based on root of trust! Problems EnLre world needs to agree on enlty to hold root of trust Single point of failure Inefficient revocalon / update mechanisms 11

11 Oligarchy Model for Trust Root! Numerous roots of trust that are globally accepted to validate enlles! Example: TLS PKI relies on > 1000 roots of trust TLS cerlficate accepted if signed by any root of trust! Problems Single point of failure: any single compromised root of trust can create any bogus TLS cerlficate RevocaLon / update is handled through OS or browser sokware update 12

12 Proposed Approach: Isolation Domains! ObservaLon: subset of the Internet can agree on roots of trust " form IsolaLon Domain with that root of trust! AuthenLcate enlles within each IsolaLon Domain! Users & domains can select IsolaLon Domain based on root of trust! Also supports modern log- based PKI approaches: CT, AKI, ARPKI,! Challenge: retain global verifiability 13

13 SCION Isolation Domains (ISD)! SCION IsolaLon Domain requirements Region which can agree on a common root of trust Set of ISPs to operate IsolaLon Domain Core to manage ISD! Root of trust and Autonomous Domain (AD) cerlficates! Manage core path and beacon servers Other ISDs need to agree to connect as peers or as a provider in case of hierarchical ISD! Open research issue exactly how to best structure ISDs: polilcal and legal issue arise Possible parllon is along geographical regions 14

14 Trust Root Management! Each ISD manages their own trust roots Used to create per- AD cerlficates AD cerlficates used to verify beacon messages! Trust Root ConfiguraLon (TRC) file serves as root of trust for ISD TRC file specifies public keys of trust root and policy for TRC file update Thresholds enable revocalon and re- authenlcalon of new TRC files Beacon messages quickly disseminate new TRC files! Requirement: ISDs cross- sign TRC files 15

15 Trust Root Config (TRC): ISD Root-of-Trust! Each ISD has a TRC file Each AD is verified based on trust roots in TRC ISD EU TRC file version N A cert E cert CA1 cert Update: 2 out of 3 Sigs with keys of TRC version N- 1 EU TD1 ISD Core CH ISD Core { B cert }K A - 1 { CH ISD TRC }K A

16 TRC File Update! New TRC file version N+1 signed by threshold number of keys from version N! Beaconing process distributes new TRC file ISD EU TRC file version N A cert E cert CA1 cert Update: 2 out of 3 Sigs with keys of TRC version N- 1 ISD EU TRC file version N+1 A cert E cert CA1 cert Update: 2 out of 3 Sigs with keys of TRC version N EU TD1 ISD Core 17

17 Routing PKI! Per- ISD TRC file enables heterogeneous trust roots! TRC file update mechanism enables efficient update and revocalon Tens of seconds to update / revoke roots of trust network- wide! ObservaLon: network architecture should provide mechanism for updalng trust roots! RouLng PKI cannot have circular dependencies between roulng message verificalon and end- to- end communicalon 18

18 Overview! Global trust architecture IsolaLon domains PKI for roulng PKI for services, domains PKI for endhosts Intrinsic security for CID, SID! Control plane security! Data plane security! Anonymity and privacy 19

19 Why We Need a Better Service PKI! Security of the weakest link Security breach of a single CA " Compromise security of sites protected by any other CA! On- path aeacker can perform Man- in- the- Middle (MitM) aeack! CA stalslcs from EFF SSL Observatory, ,482 CA public keys trustable by Microsok or Mozilla 651 organizalons! MSR SV PKI project [HotOS 2013] 1500 intermediate CA cerlficates issued (signed by root CAs) 20

20 Man-in-the-Middle (MitM) Attack Normal case Browser (3) Hello (4) Key K D, Cert KD Domain D Adversary obtains fraudulent cerlficate Aeacker (1) Key K D (2) Cert KD = { D.com, K D } K - 1 CA Cer.ficate Authority Man- in- the- Middle aeack (1) Key K D (2) Cert KD = { D.com K D } K - 1 CA Cer.ficate Authority Browser (1) Hello (SSL/TLS session) (4) Key K D, Cert KD Aeacker (2) Hello (SSL/TLS session) (3) Key K D, Cert KD Domain D

21 CA BREACH EVENTS! Jan 2001: false Microsok AcLveX cerlficate issued by Verisign! 2010: VeriSign hacked, successfully and repeatedly VeriSign aeacks were revealed in a quarterly U.S. SecuriLes and Exchange Commission filing in October 2011! Mar 2011: aeack on Commodo reseller Several fraudulent cerlficates were issued: mail.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, login.live.com Suggested that aeack originated from Iranian IP address! Aug 2011: DigiNotar, a Dutch CA, improperly issued a cerlficate for all Google domains to an external party Claim: 250 cerlficates for an unknown number of domains were released Iranian government spied on Iranian cilzens' communicalons with Google during the month of August 2011! Oct 2011: Stuxnet used compromised cerlficates from 2 Taiwanese CAs! Dec 2012: EGO uses erroneously issued TurkTrust cerlficate! Possibly a large number of CA breaches are concealed 22

22 How to Resolve these Vulnerabilities?! CerLficate RevocaLon List (CRL)! Online CerLficate Status Protocol (OCSP)! Short- lived cerlficates! PerspecLves, Convergence! DANE! CerLficate Pinning!! New approach: log to make aeacks publicly visible Google: CerLficate Transparency EFF: Sovereign Keys 23

23 CERTIFICATE TRANSPARENCY (CT)! CerLficate logs Read- and append- only logs (similar to a Lmestamping server) Merkle Hash Tree (MHT) to implement log Entry = SSL/TLS cerlficate Periodically appends new entries and signs the root (Signed Tree Head)! Upon receiving a cerlficate chain from domain or CA Log verifies the cerlficate Log issues Signed CerLficate Timestamp (SCT)! Promise to add the new cerlficate to the MHT Cert K = { D.com K} K - 1 CA Browser (5) Hello (6) Key K, cert K, SCT Domain D (1) Key K (4) Cert K, SCT Cer.ficate Authority (3) SCT (2) Key K, cert K Cer.ficate Log

24 SECURITY OF CT! How CT improves security Browser would require SCT for opening conneclon Browser contacts log server to ensure that cerlficate is listed in log! Consequence Aeack cerlficate would have to be listed in public log Aeacks become publicly known " deterrence! Advantage Deployable, CT log already up and running No change to domain s web server required! Disadvantage MitM aeack slll proceeds (but can be detected externally) Browser slll needs to contact Log eventually to verify that cerlficate is listed in log Current CT does not support revocalon 26

25 AKI GOALS! Reduce trust in any single component (e.g., CA, log server) Reduce aeack surface, no single point of failure Handle legilmate key and cerlficate management events Gracefully handle catastrophic events (e.g., domain key loss/ compromise) Enable Domain to create own security policies / levels of security! Address adversarial events CA private key compromise Domain private key compromise Make aeacks visible! Support legilmate events that are indislnguishable from malicious events Switch to different CAs! Possibly to stop using a compromised CA LegiLmate re- crealon of a key pair aker private- key loss! May look like an impersonalon aeempt 28

26 AKI ENTITIES! Set of enlles audit each other s operalons and disseminate misbehavior if detected Client (browser) establishes TLS conneclons with Domain (server) Cer.ficate Agency (CA) cerlfies domains public keys Integrity Log Server (ILS) logs domains cerlficates and makes them publicly available! Maintains Integrity Tree Hash tree of all the registered certs in lexicographical order " Quick to verify the absence of an entry Validators monitor ILS operalons and disseminate misbehavior! Download enlre ILS data & perform consistency checks! Misbehavior detected " disseminate the informalon 30

27 AKI INTEGRITY TREE! Lexicographically sorted hash tree Efficient representalon of the current state of all domains Leaf validalon requires log(n) entries + root only Quickly verify absence of an entry Independent validators can check integrity of enlre data structure Hash chaining of tree: temporal reconstruclon of all operalons! ILS_UP: interval between 2 tree updates At every ILS_UP, ILS finalizes and commits next Integrity Tree D contacts ILS for signed root and hash tree verifica.on nodes ILS_UP! 32

28 AKI OVERVIEW (registralon) 2 is sent to each ILS 5 is sent to at least one ILS from ILS_LIST 7 is sent to any Validator AKICert={Cert 1 Cert 2 } AKICert {promise} K - 1 ILS {OK, } K - 1 V A.com (K A, K - 1 A ) Browser Cert 1 ={A.com, K A } K - 1 CA1 Cert 2 ={A.com, K A } K - 1 CA2 CA 2 CA 1 (K CA1, K - 1 CA1 ) 1 2 {Yes/No} K - 1 ILS {OK, } K - 1 V ClientHello {Add AKICert} K - 1 A {promise} K - 1 ILS Verify AKICert {promise} 8 K - 1 ILS Validator Validator (K V, K - 1 V (K ) V, K - 1 V ) Verifies Cert and ILS verificalon informalon CA monitors AKICert {Is A.com in the log?} 6 ILS ILS (K ILS, K - 1 ILS (K ) ILS, K - 1 ILS ) K - 1 CAx Root Verifies AKICert Adds/Removes AKICert Creates proofs of these aclons

29 AKI OVERVIEW (confirmalon) 1 is sent to at least one ILS from ILS_LIST 3 is sent to any Validator CA 2 CA 1 (K CA1, K - 1 CA1 ) CA monitors AKICert AKICert {Root, h} K - 1 ILS {OK, } K - 1 V A.com (K A, K - 1 A ) Browser 1 3 {OK, } K - 1 V ClientHello {Confirm AKICert} K - 1 A {Root, h} K ILS Verify AKICert {Root, h} K - 1 ILS 4 Validator Validator (K V, K - 1 V (K ) V, K - 1 V ) Verifies ILS confirmalon ILS ILS (K ILS, K - 1 ILS (K ) ILS, K - 1 ILS ) Root Verifies AKICert Adds/Removes AKICert Creates proofs of these aclons

30 INTERESTING CHALLENGE! How to prevent malicious events that appear indislnguishable from legilmate events?! Example 1: trusted CA compromise Domain trusts CA1, CA1 is compromised, domain switches to CA2 Aeacker issues new cerlficate for domain using CA2! Example 2: domain private key compromise Domain is compromised, loses access to its private key, registers a new cerlficate with CA1 Aeacker issues new cerlficate for domain through CA1 36

31 CERTIFICATE UPDATE RULES! Cool- off periods (COP) introduce delay for suspicious operalons (only in case of catastrophic events!) 37

32 ARPKI: ATTACK-RESILIENT PKI! Problem: AKI is highly complex, with many potenlal cases Domain key compromise CA, ILS, validator compromise OperaLon with many ILSes, validators Different interleavings of messages, operalons! Without formal verificalon, we cannot ensure consideralon of all cases! ARPKI: Extension of AKI with formal verificalon using Tamarin security protocol verificalon tool David Basin, Cas Cremers, Ralf Sasse, Pawel Szalachowski performed most of the verificalon 38

33 39

34 40

35 Endhost PKI! Link to a device joining a network Mutual authenlcalon: host and AD Ties in with AD- level trust establishment! Variant: mobile network! Work in Progress 41

36 Joining Network! When a device joins a network we need a handshake that includes: Service discovery, including network layer services Agreement on services Mutual authenlcalon! Requirements include: Works in diverse environments: wired/wireless, corporate/hotspot/home, Efficient, e.g., for high mobility scenarios Example: vehicular networks 42

37 Intrinsic Security in XIA! XIA uses self- cerlfying idenlfiers that guarantee security properles for communicalon operalon Host and service ID are a hash of its public key correct deslnalon and accountability (AIP) Content ID is a hash of the content correctness Does not rely on external configuralon! Intrinsic security is specific to the principal type! Useful to manage addresses securely and for bootstrapping end- to- end security solulons! Many other oplons, e.g., CID variants, non- PKI, 45

38 XIA Example: Retrieving Content Service Content Host ID: ID: Nearest From Same Anywhere as Instance Today Service SID Content CID Host HID SID CID Content CID Content CID Content CID Content CID Content CID Content CID Service SID CID 46

39 Using Intrinsic Security! Useful for efficient authenlcalon within a limited temporal scope, e.g., during a session Not a replacement for PKI or other authenlcalon mechanisms! Examples of using intrinsic security: Changing addresses for mobile users Rebinding of addresses for replicated services CIDs for content (has longer Lme scale) 47

40 Example: Finding a Mobile Device NID H NID S SID HID NID S! Rendez- vous point keeps track of localon of its users Can take many forms: home network, global service, hot spot provider, DNS,! Rendez- vous point forwards packets to mobile device, e.g., SYN! Mobile device sends signed change of address to peer Based on applicalon endpoint - SID SID Signed Change of address Internet NID home Home Loca Lon Loc Svc Signed Change of address NID foreign 48

41 Overview! Global trust architecture! Control plane security SCION secure beacons! Data plane security! Anonymity and privacy 49

42 Secure Control Plane! XIA support different types of XIA idenlfiers, which require roulng protocols XIDs generally have XID- specific requirements! All protocols share the roulng PKI for security! XIA supports two models for inter- domain roulng: deslnalon and path based DesLnaLon: based on network IDs and tradilonal roulng protocols, e.g., path vector Path: Scion provides stronger path guarantees 50

43 SCION Secure Routing and Forwarding! Goals RouLng protocol can tolerate malicious ADs, malicious routers, erroneous configuralons No black hole aeacks: malicious enlty cannot aeract traffic or influence traffic that does not flow through it SeparaLon of control and data plane! AssumpLon: Trust Root ConfiguraLon (TRC) file is distributed within isolalon domain 51

44 Beaconing for Route Discovery! Periodic Path ConstrucLon Beacon (PCBs) Scalable & secure disseminalon of path/topological informalon from core to edge K- wise mull- path policy- constrained flood to provide mullple paths TD1 Core

45 SCION Forwarding (Data Plane)! Domains register paths at DNS- like server in ISD Core! End- to- end communicalon Source fetches deslnalon paths Source path combined with deslnalon path forms end- to- end path Packet contains forwarding informalon! Advantages TD1 Core Balanced route control Isolates forwarding from roulng Transparent forwarding No forwarding table at routers Enables mull- path path server

46 Path Construction and Usage! Path ConstrucLon Beacon (PCB) construclon: PCB 1 = < T exp Int 1 O 1 S 1 > Opaque field O 1 = MAC K ( T exp Int 1 ) Signature S 1 = { PCB 1 } K TD1 Co! PCB 2 = < T exp Int 1 O 1 S 1 Int 2 Int 3 O 2 S 2 > Opaque field O 2 = MAC K ( O 1 T exp Int 12 Int 3 ) Signature S 2 = { PCB 2 } K! AD receiving PCB 2 : Verify signatures Use opaque fields O 1 O 2 to send packet to ISD Core 54

47 Overview! Global trust architecture! Control plane security! Data plane security mctls: TLS and middleboxes OPT: source authenlcalon and path validalon! Anonymity and privacy 55

48 Increased Use of EncrypLon due to Privacy Concerns Mobile, South America Wired, Europe % HTTPS % HTTPS Aug 2013 Nov 2013 Feb 2014 May 2014 Aug Apr 2012 Jan 2013 Oct 2013 Jul 2014

49 But This Involves Tradeoffs! Use of TLS locks out middleboxes, which is oken a good thing, but! Some middleboxes are useful and users want them! Caching and compression can save significant bandwidth for provider or user Also: virus scanning, packet pacing, parental filters,! How do we allow encryplon and the use of (trusted) in- network funclonality I.e., communicalon involving more than 2 parles 57

50 TLS + Middleboxes? TLS WAS DESIGNED FOR EXACTLY 2 PARTIES: No mechanism to authenticate middleboxes. Client has no guarantees past first hop. Middleboxes have full read/write access.

51 Design Requirements! Keep TLS properles, but extend them to all parles: EnLty authenlcalon Data secrecy Data integrity! Control and visibility: end- points can control what data can be seen or modified by each middlebox Minimize privileges of each middlebox 59

52 Key Ideas! MulLple encryplon contexts: Each context has key for readers, writers and endpoints; can be given seleclvely to parles Sender picks encryplon context for each record! Contributory keys: Client and server contribute half of each context key! Upcoming Sigcomm: mull- context TLS (mctls): Enabling Secure In- Network FuncLonality in TLS David Naylor, Kyle Schomp, Maeeo Varvello, Ilias LeonLadis, Jeremy Blackburn, Diego Lopez, KonstanLna Papagiannaki, Pablo Rodriguez Rodriguez, Peter Steenkiste 60

53 Source Authentication and Path Validation! Path validalon enables receiver to check if packet exactly followed intended AD- level path! Source authenlcalon enables routers to authenlcate sender and packet content! Lightweight Source AuthenLcaLon and Path ValidaLon by Kim et al., Sigcomm

54 Basic Path Validation S R 1 R 2 D! Set up shared secret keys Using, R 1 checks path has been followed so far Using, R 1 creates a proof for R 2 that it has seen the packet Using, R 1 creates a proof for D as well 63

55 Retroactive-OPT! No key setup before packet forwarding! Only with suspected misbehavior, S and D set up keys to verify the previous packets key setup OPT Time Retroactive OPT key setup Time Start coward attack detection 65

56 Retroactive-OPT! No key setup before packet forwarding Only with suspected misbehavior, S and D set up keys for previous packets! Routers commit to a key during forwarding Reveal keys used later Wrong key or refusal to provide key " misbehavior 66

57 Efficiency on Routers! Dynamically re- creatable keys on the fly S selects parameters that routers use for key setup Parameters in packet header + local secret "! Constant computalon during forwarding, independent of path length 2 MAC operalons per packet 67

58 Retroactive-OPT Process! Each OPT node derives a key Parameters in packet header + local secret 1 " 1 S R 1 R 2 D Parameters 1 1 PVF MAC PVF 1 68

59 Retroactive-OPT Process! Each OPT node derives a key Parameters in packet header + local secret 1 " 1 S R 1 R 2 D Parameters 2 2 MAC PVF MAC 1 MAC PVF

60 Overview! Global trust architecture IsolaLon domains Secure PKI for roulng and services! Control plane security! Data plane security! Anonymity and privacy APIP: balance privacy and accountability LAP: Lightweight Anonymity and Privacy 70

61 Growing User Concern about Privacy! Fueled by personal experience and reports E.g., social networks, vendors, Snowden,! So more privacy is always beeer?! Privacy can be expensive Obvious example: strong anonymity using TOR More subtle costs associated with HTTPS! Privacy can lead to lack of accountability Address spoofing, DOS aeacks,! Can we balance the privacy and accountability? Rather than having to choose one over the other! Balancing Accountability and Privacy in the Network by Naylor, Mukerjee, Steenkiste, SIGCOMM

62 Source Addresses: Controlling Privacy versus Accountability! Source address are assumed to be essenlal but you can build a network without them! What are source addresses used for? Hard to balance Privacy and Accountability: Tor versus AIP Tussle controlled by on/off switch Return address IdenLfy sender Accountability Error reporlng Flow ID Used by: DesLnaLon Network 72

63 Accountability and Privacy! View source addresses as accountability addresses Uses AIP style accountability, but Accountability can be delegated to a service that takes responsibility for packet Return address can be (hidden) inside packet! Many details : nature of delegate, fate sharing, 73

64 Research Questions! How do sources efficiently brief accountability delegates! Who can be a delegate? Anybody versus only trusted parles! How to prevent aeacks against delegates No delegate, no conneclvity!! How to balance performance with security Checking introduces delays, overhead Balancing Privacy and Accountability, David Naylor, Maehew Mukerjee, Peter Steenkiste, ACM Sigcomm, August

65 Lightweight Anonymity and Privacy! Desired property: bridge latency gap between systems with strong anonymity proteclon and non- anonymous systems, efficient enough to protect all traffic by default! LAP: Lightweight Anonymity and Privacy by Hsiao et al., IEEE Security and Privacy 2012 or or? LAP- enabled network Where in the topology??????? 75

66 Proposed Approach: LAP Lightweight Anonymity & Privacy 1. Consider a relaxed yet praclcal aeacker model (a remote aeacker) to bridge the latency gap Explore a tradeoff between aeack class and latency 2. Network- layer approach to efficiently hide source address or or? LAP- enabled network Where in the topology??????? 76

67 LAP Insights! Anonymity: being unidenlfiable within a set of users The set is called an anonymity set 1. Hiding path info improves anonymity The aeacker cannot recover origin address from packet 2. Extending hidden path increases anonymity! SCION encrypted opaque fields provide topological anonymity 1 3 Sender Know is in sender AS1, 2, is IP, or in AS1, 3. S = S AS1 + AS2 + AS3 = AS- level topology (AS = Autonomous System) 77

68 Summary: Security Aspects of XIA! Much progress over the past 5 years; highlights: Internet- scale trust architecture: roulng, services, domains, endhost, content ARPKI: Aeack Resilient PKI designed, analyzed, and implemented Secure roulng and forwarding Middle- box friendly TLS OPT: Efficient Origin and Path Trace APIP: Privacy and accountability architecture LAP: Lightweight Anonymity and Privacy! Other aspects not covered: DDoS defense, fault localizalon, security policies, 78