Using Secure Coprocessors to Protect Access to Enterprise Networks

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. 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 Jose' Brustoloni

3. 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 Jose' Brustoloni

4. Continuing vulnerability • Malicious node can spoof list with node’s software configuration and versions • How can network server be sure of node’s configuration? Jose' Brustoloni

5. 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 Jose' Brustoloni

6. Our contributions • How to integrate secure coprocessors with network protocols? • Straightforward answer is vulnerable to man-in-the-middle (MITM) attacks → Bound Keyed Attestation (BKA) • 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 • How to keep node under its owner’s control? • Danger of software lock-in → Sealing-free attestation confinement Jose' Brustoloni

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

8. 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 Jose' Brustoloni

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

10. 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 Jose' Brustoloni

11. BKA protocol Jose' Brustoloni

12. 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 Jose' Brustoloni

13. 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: • Drop any security associations that depend on TCB list • e.g., destroy keys necessary for network access • Log event into secure coprocessor • node will need to reboot before regaining access Jose' Brustoloni

14. 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 Jose' Brustoloni

15. 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 Jose' Brustoloni

16. Authentication and authorization latency and projected throughput • 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 Jose' Brustoloni

17. Related work • NAP, NAC, TNC • Bear • TcgLinux • Microsoft’s NGSCB / Intel’s LT • Terra Jose' Brustoloni

18. 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 Jose' Brustoloni