Upload
grady-lopez
View
25
Download
0
Embed Size (px)
DESCRIPTION
Using Secure Coprocessors to Protect Access to Enterprise and Ad Hoc Networks. Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh [email protected] Joint work with Haidong Xia and Jayashree Kanchana. Motivation. Attackers can easily bypass firewalls and VPNs: - PowerPoint PPT Presentation
Citation preview
Using Secure Coprocessors Using Secure Coprocessors to Protect Access to to Protect Access to
Enterprise and Enterprise and Ad Hoc NetworksAd Hoc Networks
Dr. José Carlos BrustoloniDept. Computer ScienceUniversity of [email protected] work with Haidong Xia and Jayashree Kanchana
Jose' Brustoloni 2Oct. 25, 2006
MotivationMotivation
♦ 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 3Oct. 25, 2006
Previous proposed solutionsPrevious 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 4Oct. 25, 2006
Continuing vulnerabilityContinuing 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 5Oct. 25, 2006
Secure coprocessorsSecure 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 6Oct. 25, 2006
TPM v. 1.1b secure coprocessor block diagramTPM v. 1.1b secure coprocessor block diagram
Jose' Brustoloni 7Oct. 25, 2006
Our contributionsOur 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
privileged users→ Security association root tripping
3. How to keep node under its owner’s control?♦ Danger of software lock-in→ Sealing-free attestation confinement
Jose' Brustoloni 8Oct. 25, 2006
Authenticated bootAuthenticated boot
Core Rootof Trust for
Measurement=
BIOSbootblock
TPM
Measurement Agents
e.g., daemons and configuration files
Jose' Brustoloni 9Oct. 25, 2006
How to fit many measurements How to fit many measurements into a small TPMinto 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 10Oct. 25, 2006
AttestationAttestation
♦ 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 11Oct. 25, 2006
MITM attack against attestationMITM attack against attestation
authenticationserver
MITMconformant
host
nonce
quote
tunnel (e.g. TLS)
Jose' Brustoloni 12Oct. 25, 2006
Our solution: Bound Keyed AttestationOur 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 13Oct. 25, 2006
BKA protocolBKA protocol
Jose' Brustoloni 14Oct. 25, 2006
TCB preloggingTCB 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 15Oct. 25, 2006
Security association root trippingSecurity 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: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
Jose' Brustoloni 16Oct. 25, 2006
Sealing-free attestation confinementSealing-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 17Oct. 25, 2006
Experimental resultsExperimental 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 18Oct. 25, 2006
Authentication and authorization Authentication and authorization latency and projected throughput – PEAPv2latency 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
Step PEAPv2 PEAPv2+LOG PEAPv2+BKA
TLS 39.6 ms [0.2] 39.9 ms [0.8] 38.0 ms [0.9]
LOG 24.4 ms [0.2]
BKA 2758 ms [263]
MS-CHAPv2 20.6 ms [0.5] 17.4 ms [0.2] 17.9 ms [0.2]
Binding 7.0 ms [0.2] 6.8 ms [0.2] 6.8 ms [0.1]
Total 67.2 ms [0.5] 88.4 ms [0.5] 2822 ms [263]
CPU busy 22.6 ms [0.2] 23.9 ms [0.2] 116 ms [10]
Projected throughput 2650 supp/min 2510 supp/min 519 supp/min
Jose' Brustoloni 19Oct. 25, 2006
Authentication and authorization Authentication and authorization latency and projected throughput – IKElatency and projected throughput – IKE
Step Unmodified IKE IKE + BKA
Phase 1 130.7 ms [52.4] 108.1 ms [0.6]
BKA 2486.1 ms [229.4]
Phase 2 1050.2 ms [10.7] 1037.3 ms [4.8]
Total 1180.9 ms [63.0] 3631.5 ms [228.4]
CPU busy 125.3 ms [0.9] 216.3 ms [1.1]
Projected throughput 428 clients/min 277 clients/min
Jose' Brustoloni 20Oct. 25, 2006
Extension to ad hoc networksExtension 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 21Oct. 25, 2006
Can’t we “simply” authenticate nodes?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)
♦ ... and insufficient: 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 22Oct. 25, 2006
Our approachOur 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 23Oct. 25, 2006
Contribution: AdHocSecContribution: 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 24Oct. 25, 2006
LayeringLayering
Jose' Brustoloni 25Oct. 25, 2006
Frame formatFrame format
Jose' Brustoloni 26Oct. 25, 2006
Key-management goalsKey-management goals
1. 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
2. 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 27Oct. 25, 2006
Distributed attestationDistributed attestation
Jose' Brustoloni 28Oct. 25, 2006
Attested MergerAttested Merger
Jose' Brustoloni 29Oct. 25, 2006
PerformancePerformance
♦ 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 30Oct. 25, 2006
Latency for global key agreementLatency for global key agreement
Jose' Brustoloni 31Oct. 25, 2006
Latency distributionLatency distribution
Jose' Brustoloni 32Oct. 25, 2006
OverheadOverhead
Jose' Brustoloni 33Oct. 25, 2006
Impact on routing performanceImpact on routing performance
Jose' Brustoloni 34Oct. 25, 2006
Related workRelated 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 35Oct. 25, 2006
Ongoing workOngoing 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 36Oct. 25, 2006
ConclusionsConclusions♦ 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