Using Secure Coprocessors to Protect Access to Enterprise and Ad Hoc Networks

1. Using Secure Coprocessors to Protect Access to Enterprise and Ad Hoc 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 from 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 updating node’s software • Expected to become common in a few years • Cisco’s Network Admission Control (NAC) • some routers with proprietary protocols commercially available • Microsoft’s Network Access Protection (NAP) • TCG’s Trusted Network Connect (TNC) • some architecture documents out, but important details outside charter 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, Dell, and others Jose' Brustoloni

6. TPM v. 1.1b secure coprocessor block diagram Jose' Brustoloni

7. 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 privileged users → Security association root tripping • How to keep node under its owner’s control? • Danger of software lock-in → Sealing-free attestation confinement Jose' Brustoloni

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

9. How to fit many measurements into a small TPM • TPM contains only a limited number of Platform Configuration Registers (PCRs) for storing measurements • TPM 1.1: 16 PCRs, each 160 bits long • PCRs are initialized to known value at boot time • Measurement agent (MA) stores a measurement in a PCR by • concatenating current value of PCR with measurement, • computing secure hash (SHA-1) of concatenation, and • storing the result into PCR • MA also records measurement in TPMS (Trusted Platform Measurement Store), which contains the measurement log: • each record contains module name, version, supplier name or URL, and actual measurement of each software module in chain of trust • stored in ordinary, unprotected memory outside TPM • tampering revealed by inconsistency with PCRs inside TPM • infeasible to alter TPMS and maintain consistency with PCR Jose' Brustoloni

10. 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 • A trusted third party previously verified that a compliant secure coprocessor is bound to node and issued a certificate that gives secure coprocessor’s public key • Node’s operating system sends measurement log (with each software component’s secure hash), quote, and certificate to challenger • Challenger verifies certificate, log, and quote Jose' Brustoloni

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

12. Our solution: Bound Keyed Attestation • Combine attestation with Diffie-Helman to generate shared secret • Cryptographically bind secret with tunnel’s keys → Guarantee that attestation and tunnel endpoints are the same Jose' Brustoloni

13. BKA protocol Jose' Brustoloni

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

15. Security association root tripping • Privileged users (e.g., 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

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

17. 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 (for use in enterprise LANs) • IKE on Racoon (for use in IPsec-based virtual private networks) • FreeRADIUS server, Racoon VPN server 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

18. Authentication and authorization latency and projected throughput – PEAPv2 • 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

19. Authentication and authorization latency and projected throughput – IKE Jose' Brustoloni

20. Extension to ad hoc networks • Mobile ad-hoc networks have many important applications ... • military, emergency response, impromptu meetings, home automation • network quickly self-organizes without any infrastructure • ... but is very hard to deploy securely ... • How do I know your computer/network will not disrupt/infect/betray mine? • routing attacks • viruses and worms • physical capture Jose' Brustoloni

21. Can’t we “simply” authenticate nodes? • Securely establishing another mobile node’s identity is difficult ... • set-up of public keys or shared keys and friend lists in each node can be problematic if network large or membership dynamic • nodes may belong to different jurisdictions • nodes can be compromised (e.g., by loss, theft, or defection) • ... andinsufficient: • urban warfare: coalitions with friendly locals • can locals’ computers be trusted for routing packets? • civil defense and private citizens: response to major disasters • supplier visiting a client / friend visiting a home • will your computer infect my network’s computers? • paramedics and home or body networks: response to medical emergencies • will my medical data be secure in your device? Jose' Brustoloni

22. Our approach • Use secure coprocessors as unifying methodology for hardening ad-hoc networks against attacks • secure attestation of node configuration • data sealing • Such that protocols and applications, e.g. • routing and forwarding • leader election • storage of private data inherit essential security properties with little modification, cost, or performance impact Jose' Brustoloni

23. Contribution: AdHocSec • Security layer between layers 2 and 3 • Protects anything running above it (e.g., routing, forwarding, leader election, applications) • data integrity • confidentiality • unicast replay protection Jose' Brustoloni

24. Layering Jose' Brustoloni

25. Frame format Jose' Brustoloni

26. Key-management goals • Guarantee that a node can join an ad-hoc network only if node has an acceptable configuration • configuration deemed acceptable because does not allow users to attack the network • configuration change automatically causes node to leave ad-hoc network • Guarantee that unauthorized users cannot access protected data stored in a node by subverting the node’s configuration • data encrypted with keys that are available only if configuration not tampered with Challenge: attestation latency Jose' Brustoloni

27. Distributed attestation Jose' Brustoloni

28. Attested Merger Jose' Brustoloni

29. Performance • Implemented algorithms on ns-2 simulator • 50 nodes • 1500 x 300 m area • speed between 0 and 20 m/s (45 mi/hr) • DSR Jose' Brustoloni

30. Latency for global key agreement Jose' Brustoloni

31. Latency distribution Jose' Brustoloni

32. Overhead Jose' Brustoloni

33. Impact on routing performance Jose' Brustoloni

34. Related work • TPM drivers, TCG Software Stack implementations are insufficient • do not prevent tampering with configuration after boot time • do not close network connection or files whose access depends on previous configuration • Bear/Enforcer • no attestation, vulnerable to tampering by root, bootable from floppy only • TcgLinux • does not prevent tampering – simply guarantees that future attestations reveal tampering • does not prevent or detect interactive snooping on secret data (e.g., keys) • no data sealing • Cisco’s Network Admission Control/Microsoft’s Network Access Protection • Protect access to enterprise networks only, vulnerable to spoofing • TCG’s Trusted Network Connect • Protects access to enterprise networks, not ad-hoc • Necessary operating system modifications (e.g., for sealing) outside charter Jose' Brustoloni

35. Ongoing work • Also extending this work for protection of intellectual property in collaborative design • companies collaborating on a project could greatly improve productivity by sharing their designs • but reluctant about what collaborators will do with disclosed data – e.g., leak to a competitor • our approach: • bind usage policies to documents • send copies only to configurations trusted to honor sender’s usage policies • funded by NSF Center for e-Design Jose' Brustoloni

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