The Role of Trustworthy Computing to Build Future Secure Internet Architectures

Transcription

1 The Role of Trustworthy Computing to Build Future Secure Internet Architectures Adrian Perrig Network Security Group ETH Zürich

2 Overview Trusted Compu-ng Overview Cuckoo a7ack Secure rou-ng and BGP with trusted compu-ng TrueNet: Secure fault localiza-on SCION: Isola-on- based Future Internet Architecture proposal 2

3 Central Message Trusted compu-ng mechanisms enable fundamentally new proper-es On host: protect code & data even from admin In distributed applica-ons: simple data verifica-on based on code that produced it Trusted compu-ng mechanisms provide new primi-ves to build secure system However: Proper-es only hold locally

4 Isolated Execution Environment (IEE) Execu-on environment that is defined by code S execu-ng on a specific plaporm Code is iden-fied based on cryptographic hash H(S) PlaPorm is iden-fied based on TPM creden-als App OS App IEE execu-on protected from any other code S DMA Devices (Network, Disk, USB, etc.) CPU, RAM TPM, Chipset

5 Basic Trusted Computing Primitives Create isolated execu-on environment (IEE) Create data that can only be accessed within isolated environment Remote verifica-on of IEE Establish secure channel into IEE Externally verify that output O was generated by S on input I running within IEE

6 Basic Trusted Computing Primitives How to create IEE? How to remotely verify IEE? How to establish a secure channel into IEE? How to externally verify that output O is from S s computa-on on input I within IEE?

7 TPM Background The Trusted PlaPorm Module (TPM) is a dedicated security chip Contains a public/private keypair {K Pub, K Priv } Contains a cer-ficate indica-ng that K Pub belongs to a legi-mate TPM Not tamper- resistant

8 How to Create IEE? AMD / Intel late launch extensions Secure Loader Block (SLB) to execute in IEE SKINIT / SENTER execute atomically Sets CPU state similar to INIT (so` reset) Enables DMA protec-on for en-re 64 KB SLB Sends [length bytes of] SLB contents to TPM Begins execu-ng at SLB s entry point SLB SKINIT SENTER

9 How to Remotely Verify IEE? V S Nonce N Nonce N S N S N S N Means H(S) and N are signed by plaporm key

10 Secure Channel to IEE V S Nonce N S N, K Nonce N S N, K Gen {K, K - 1 } Encrypt K (secret) Encrypt K (secret)

11 O=S(I) within IEE? V S Nonce N, Input I S N, I, O Nonce N, Input I S N, I, O O=S(I)

12 The Cuckoo Attack Bryan Parno, The Cuckoo A7ack, HotSec Problem: how can we ensure that a7esta-on originates from correct host?

13 Bootstrapping Trust with a TPM Module 1 Module 2 conf BIOS Boot Loader OS Kernel BIOS App 1 App 2 Apps TPM PCRs K Priv Hardware So`ware 13

14 Bootstrapping Trust with a TPM Nonce Trustworthy! K Pub Module 1 Module 2 conf Guarantees Guarantees freshness key App 1 originated from a real TPM BIOS Boot Loader OS Kernel Apps App 2 TPM a7ests TPM to the so`ware PCRs K Priv Sign (, K ) Priv Nonce

15 The Cuckoo Attack Trustworthy! Nonce Guarantees freshness TPM a7ests to the so`ware Nonce Guarantees key originated from a 15 real TPM Sign (, K ) Priv Nonce K Pub

16 What went wrong? An a7esta-on says that a TPM vouches for a so`ware state, but not which TPM Sign (, K ) Priv Nonce Sign (, K ) Priv Nonce K Pub K Pub

17 Assumptions Assump-ons for building secure systems Verifier has correct public keys No hardware a7acks Isolated code has no vulnerabili-es Observa-ons So far, trusted compu-ng does not prevent local physical a7acks However, prevents remote a7acks which are most frequent a7acks

18 Application: Secure Routing Challenge: Malicious routers distribute bogus rou-ng informa-on Observa-ons If receiving router R knows route update U was created by code S, then U must be correct If S also contains verifica-on code that checks previous routers update, then en-re rou-ng path must be correct

19 Sample BGP Update Message R4 R9: C1, {AS1} R7 R11: C1, {AS1, AS2} R8 R15: C1, {AS1, AS2} R12 R16: C1, {AS1, AS2, AS3} R16 R1 R2 R6 R7 R11 R12 R3 R9 R13 R8 R5 R4 R10 R15 R14 C1 C2 C3 19

20 Secure BGP Update Message C1 AS1: {C1, AS1} KC1-1 R4 R9: {C1, AS1} KC1-1, [AS1], {AS1, AS2} KAS1-1 R7 R11: {C1, AS1} KC1-1, [AS1, AS2], {AS1, AS2} KAS1-1, {AS2, AS3} KAS2-1 R1 R2 R6 R7 R11 R12 R3 R9 R13 R8 R5 R4 R10 R15 R14 C1 C2 C3 20

21 Observations on Secure BGP Cryptographic mechanisms ensure append- only property of AS path Each BGP Update message that contains X ASes, also contains X+1 signatures and X+1 cer-ficates Different rou-ng protocols need different security mechanisms For each rou-ng protocol, o`en several secure versions exist Challenging to design secure rou-ng protocols

22 Trusted Computing Approach: Secure BGP Routers implement code S: Set up secure channels with peering routers, ensure that peering routers execute valid S Verify that received route update was generated by valid S (check O=S(I)) Append own AS# to incoming route updates and send new route updates to peering routers Observa-ons Single MAC verifica-on ensures correctness of en-re path! General mechanism to secure rou-ng protocol

23 What is Fault Localization? Problem defini-on Iden-fy faulty links during packet forwarding A7acker Model Drop, modify, misroute, or inject packets at data plane Challenges Selec-ve a7ack: break ping, traceroute, etc High overhead Slander & framing Only drop node 5 s ACKs Got it Got it Got it Got it Got it Source Dest 23

24 What is Fault Localization? Challenges (cont d) A7acks against sampling Forgery a7ack: break NePlow, Bloom Filter, etc Natural packet loss 100 pkts Source is not sampled, drop it! Got 100 Got 100 Got 100 Got 100 Got Only modify packets Dest 24

25 Why is Fault Localization Important? The current Internet Best effort, purely end- to- end Fault localiza-on enables: Data- plane accountability Intelligent path selec-on Linear path explora-on cost Worst case: 3 vs 2 3 trials Worst case: 2 3 Source Des-na-on 25

26 Design Goals Security Against drop, modify, inject, and replay packets Against mul-ple colluding nodes Efficiency Low detec-on delay Low storage, communica-on and computa-on overhead Provable bounds Upper bound of damage without being detected Lower bound of forwarding correctness if no fault detected 26

27 Previous Fault Localization Approaches Theore-cally proven high overhead per- source key storage (some-mes per- path state)! Cannot globally share Fault Localiza-on results Delayed failure recovery, inconsistent rou-ng tables Node 5 is malicious! Mallory Fundamental reason: Lack of trust rela-onship Alice Bob 27

28 How Trusted Computing can Help Bootstrapping trust of code among nodes Remote a7esta-on and isola-on code integrity Sealed storage data secrecy I expect Bob to be: So store: H( ) signed H( ) Alice R u Bob? Bob Data sealed by P; accessible only when H(P) is correct 28

29 Opportunities and Challenges Transi-vity of verifica-on A chain of 1- hop verifica-ons provide end- to- end verifica-on per- neighbor state & key storage source A7est to the en-re network stack? command- line input and configura-on! large Trusted Compu-ng Base (TCB)! Code isn t modified Code is bug- free Large TCB == low security dest 29

30 TrueNet Goals Minimize the TCB small piece of code can be more trusted efficient a7esta-on without compromising performance Approach Do not a7est to of network stack A7est to behavior of network stack 1- hop monitoring module (MM): monitor behavior, in TCB 30

31 TrueNet Overview Setup secure channel between MMs neighboring MMs share secret keys (per- neighbor only!) Secret keys sealed to the MMs MM Opera-ons and fault localiza-on Packets go through each MM m N SA [m, N SA ]K SA m N AB SA [m, N AB SA ]K AB SA Router S Router A Auth ACK Sam Alice 1- hop Router B Bob Network Stack Network Stack Network Stack 31

32 TrueNet Overview Trustworthy compu-ng to protect packet processing packets go through and leave footprints in each Monitoring Module (MM) comparing footprints between neighboring MMs enables fault localiza-on Router S Router A Router B Router C MM S MM A MM B MM C Network Stack Network Stack Network Stack Network Stack 32

33 Secure Channel Secure channel between MMs neighboring MMs share secret keys (per- neighbor only!) Secret keys sealed to the MMs authen-cated communica-on; footprint cannot be forged Logical protected path Router S Router A Router B Router C MM S MM A MM B MM C Network Stack Network Stack Network Stack Network Stack Actual path 33

34 Send a packet Receive a packet Forward a packet Secure Channel m N SA [m, N SA ]K SA m N AB [m, N AB ]K AB Router S Router A Router B MM S MM A MM B Network Stack Network Stack Network Stack 34

35 Implementation A TrueNet router architecture App App Router OS Hypervisor MM CPU Subsystem Switch Fabric RAM Computation Module Hardware TPM MAC Module Trusted Untrusted Network Interface... Network Interface Network Interface We implement the MAC Module in so`ware 35

36 Applications Accountable packet monitoring Global sharing of FL results Assist secure topology and path discovery Resource alloca-on and per- flow monitoring can provide guaranteed throughput and delay Level separa-on in routers, separate MM for each level 36

37 Evaluation Prototype (w/ TrustVisor): li7le computa-on overhead Storage measurement and comparison Key Storage Overhead (# keys) Other Schemes TrueNet Worst TrueNet Average ATT Sprint L3 Verio VSNL Tele (India) stra I2 Storage Overhead (bytes) 1e+09 1e+08 1e+07 1e ATL CHI HOU KAN Stat. FL Monitoring State Stat FL Key Storage Overhead TruNet Overhead LA NYC SLC SEA WAS Avg 37

38 However Both TC- BGP and TrueNet assume that trusted HW is not tampered with Does not hold in an Internet sezng! Remote malicious ISPs exist Approach: Global network isola-on architecture Define Trust Domains, which provide enforceable accountability 38

39 SCION Architectural Goals High availability, even for networks with malicious par-es Communica-on should be available if a7acker- free path exists Explicit trust for network opera-ons Minimal TCB: minimize trusted en--es for any opera-on Strong isola-on from untrusted par-es Operate with mutually distrus-ng en--es No single root of trust Balanced route control for ISPs, receivers, senders No circular dependencies during setup: enable rebootability Simplicity, efficiency, flexibility, and scalability 39

40 SCION Architecture Overview Trust domain (TD)s Isola-on and scalability Enforceable accountability Path construc-on Path construc-on beacons (PCBs) Path resolu-on Control Explicit trust Route joining (shortcuts) Efficiency, flexibility PCB PCB PCB Source TD TD Core path srv S: blue paths D: red paths Des-na-on 40

41 SCION Trust Domain Decomposition TD1 Core TD2 Core TD Core Interconnect TD 4 Core TD 3 Core Trust Domain Boundary

42 Conclusion Trusted compu-ng mechanisms enable new ways to build secure applica-ons Examples TC- BGP only requires single MAC computa-on to verify en-re rou-ng update, while S- BGP requires O(N) signature verifica-ons TrueNet enables efficient fault localiza-on based on trusted compu-ng primi-ves However, network isola-on architecture is needed to prevent remote HW- based a7acks