Presentation is loading. Please wait.

Presentation is loading. Please wait.

Using Secure Coprocessors to Protect Access to Enterprise Networks Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh

Similar presentations


Presentation on theme: "Using Secure Coprocessors to Protect Access to Enterprise Networks Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh"— Presentation transcript:

1 Using Secure Coprocessors to Protect Access to Enterprise Networks Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh jcb@cs.pitt.edu Joint work with Haidong Xia and Jayashree Kanchana

2 Jose' Brustoloni 2 May 3, 2005 Motivation ♦ Attackers can easily bypass firewalls and VPNs:  laptop computers infected on a trip  telecommuting from home computers shared with children or cybercafés  rogue modems  rogue wireless access points

3 Jose' Brustoloni 3 May 3, 2005 Previous proposed solutions ♦ Verify node’s configuration before accepting node in network ♦ Node sends list with node’s software configuration and versions to a network server ♦ Server may accept node’s configuration or confine node to restricted network that allows only updating node’s software ♦ Expected to become common in a few years  Cisco’s Network Admission Control (NAC)  Microsoft’s Network Access Protection (NAP)  Many other similar initiatives

4 Jose' Brustoloni 4 May 3, 2005 Continuing vulnerability ♦ Malicious node can spoof list with node’s software configuration and versions ♦ How can network server be sure of node’s configuration?

5 Jose' Brustoloni 5 May 3, 2005 Secure coprocessors ♦ Trusted Computing Group (TCG) has standardized secure coprocessors (TPM) for just this type of problem ♦ Low cost ($4) ♦ Present in increasing number of computers from IBM, HP, and others

6 Jose' Brustoloni 6 May 3, 2005 Our contributions 1. How to integrate secure coprocessors with network protocols? ♦ Straightforward answer is vulnerable to man-in-the-middle (MITM) attacks → Bound Keyed Attestation (BKA) 2. How to integrate secure coprocessors with operating system? ♦ Straightforward answer is vulnerable to buggy components other than the kernel → TCB prelogging ♦ Straightforward answer is also vulnerable to tampering by root → Security association root tripping 3. How to keep node under its owner’s control? ♦ Danger of software lock-in → Sealing-free attestation confinement

7 Jose' Brustoloni 7 May 3, 2005 Authenticated boot Core Root of Trust for Measurement = BIOS boot block TPM Measurement Agents e.g., daemons and configuration files

8 Jose' Brustoloni 8 May 3, 2005 Attestation ♦ Challenger sends nonce to node ♦ Node’s operating system asks node’s secure coprocessor to sign quote (software digests currently stored in coprocessor) ♦ Signature uses private key generated within coprocessor ♦ Some authority previously verified that compliant secure coprocessor bound to node and signed certificate with coprocessor’s public key ♦ Node’s operating system sends software log, quote, and certificate to challenger ♦ Challenger verifies certificate, quote, and log

9 Jose' Brustoloni 9 May 3, 2005 MITM attack against attestation authentication server MITM conformant host nonce quote tunnel (e.g. TLS)

10 Jose' Brustoloni 10 May 3, 2005 Our solution: Bound Keyed Attestation ♦ Combine attestation with Diffie-Helman to generate shared secret ♦ Bind secret with tunnel’s keys → Attestation and tunnel endpoints are the same

11 Jose' Brustoloni 11 May 3, 2005 BKA protocol

12 Jose' Brustoloni 12 May 3, 2005 TCB prelogging ♦ Trusted Computing Base (TCB):  anything that could compromise node’s security  includes kernel, configuration files, daemons, root setuid applications ♦ How can we be sure that TCB is measured? ♦ Our solution: use TCB list (itself part of TCB) ♦ Kernel:  Prelogs items in TCB list into secure coprocessor at boot time  Measures these items, as well as any daemons and root setuid applications, at open or exec time  In case of discrepancy, logs it into secure coprocessor and breaks any security associations that depend on the TCB list

13 Jose' Brustoloni 13 May 3, 2005 Security association root tripping ♦ Root can change configuration after boot time  e.g., sysctl, ifconfig ♦ Our solution: If user insists in logging in as root: 1. Drop any security associations that depend on TCB list  e.g., destroy keys necessary for network access 2. Log event into secure coprocessor  node will need to reboot before regaining access

14 Jose' Brustoloni 14 May 3, 2005 Sealing-free attestation confinement ♦ Secure coprocessor also enables sealing data such that data retrieval is possible only when platform has the same configuration ♦ Danger of software lock-in: software seals to itself node owner’s data  can’t use competing applications  may lose data if software provider disappears ♦ Our solution:  Operating system supports attestation but not sealing  Integrate attestation only with intranet access control protocols, which typically cannot cross firewalls

15 Jose' Brustoloni 15 May 3, 2005 Experimental results ♦ Implemented all mechanisms on FreeBSD 4.8 running on IBM ThinkPad T30 with 1.8 GHz Pentium 4 and TPM 1.1b secure coprocessor ♦ BKA integrated with PEAPv2 / 802.1x on Open1x and FreeRADIUS ♦ FreeRADIUS ran on Dell computer with 2.4 GHz Pentium 4 without secure coprocessor ♦ TCB prelogging, security association root tripping, and sealing- free attestation confinement have negligible impact on FreeBSD 4.8 boot latency or run-time performance

16 Jose' Brustoloni 16 May 3, 2005 Authentication and authorization latency and projected throughput PEAPv2PEAPv2 + LOGPEAPv2 + BKA Latency (ms)67882822 Projected throughput (supplicants/min) 26502510519 LOG is a NAC-like protocol, vulnerable to spoofing BKA latency dominated by secure coprocessor’s quote time (2.5 s) Throughput with BKA can be easily increased by using multiple authentication servers

17 Jose' Brustoloni 17 May 3, 2005 Related work ♦ NAP, NAC, TNC ♦ Bear ♦ TcgLinux ♦ Microsoft’s NGSCB / Intel’s LT ♦ Terra

18 Jose' Brustoloni 18 May 3, 2005 Conclusions ♦ Firewalls and VPNs are not enough ♦ Several commercial proposals to authenticate nodes’ configuration are vulnerable to spoofing ♦ Secure coprocessors can block spoofing, but have challenges of their own ♦ We introduced several new solutions to these challenges:  Bound Keyed Attestation  TCB prelogging  Security association root tripping  Sealing-free attestation confinement ♦ Experiments show that our techniques have acceptable overhead


Download ppt "Using Secure Coprocessors to Protect Access to Enterprise Networks Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh"

Similar presentations


Ads by Google