Slides - University of Pittsburgh

Download Report

Transcript Slides - University of Pittsburgh

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:
laptop computers infected on a trip
 telecommuting from home computers shared with
children, or from cybercafés
 rogue modems
 rogue wireless access points

Oct. 25, 2006
Jose' Brustoloni
2
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)
Oct. 25, 2006  some architecture Jose'
Brustoloni
3
documents
out, but important details

Continuing vulnerability
♦
Malicious node can spoof list with node’s
software configuration and versions
♦
How can network server be sure of
node’s configuration?
Oct. 25, 2006
Jose' Brustoloni
4
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
♦
Oct. 25, 2006
Jose' Brustoloni
5
TPM v. 1.1b secure coprocessor block diagram
Oct. 25, 2006
Jose' Brustoloni
6
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
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
♦
Oct. 25, 2006
Jose' Brustoloni
7
Authenticated boot
Core Root
of Trust for
Measurement
=
BIOS
boot
block
Measurement
Agents
TPM
e.g., daemons and configuration files
Oct. 25, 2006
Jose' Brustoloni
8
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

Oct. 25, 2006
Jose' Brustoloni
9
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
Oct. 25,
2006
Jose' Brustoloni
certificate
to challenger
10
♦
MITM attack against attestation
conformant
host
nonce
MITM
quote
authentication
server
tunnel (e.g. TLS)
Oct. 25, 2006
Jose' Brustoloni
11
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
Oct. 25, 2006
Jose' Brustoloni
12
BKA protocol
Oct. 25, 2006
Jose' Brustoloni
13
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
Oct. 25, 2006
Jose' Brustoloni
14
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:
1.
2.
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
Oct. 25, 2006
Jose' Brustoloni
15
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
Oct. 25, 2006
Jose' Brustoloni
16
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 sealingfree attestation confinement have negligible impact on FreeBSD
4.8 boot latency or run-time performance
Oct. 25, 2006
Jose' Brustoloni
17
Authentication and authorization
latency and projected throughput – PEAPv2
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
• 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
Oct. 25, 2006
Jose' Brustoloni
18
Authentication and authorization
latency 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
Oct. 25, 2006
Jose' Brustoloni
19
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

Oct. 25, 2006
Jose' Brustoloni
20
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?

Oct. 25, 2006
Jose' Brustoloni
21
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
Oct. 25, 2006
Jose' Brustoloni
22
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
Oct. 25, 2006
Jose' Brustoloni
23
Layering
Oct. 25, 2006
Jose' Brustoloni
24
Frame format
Oct. 25, 2006
Jose' Brustoloni
25
Key-management goals
1.
Guarantee that a node can join an ad-hoc network
only if node has an acceptable configuration


2.
configuration deemed acceptable because does not allow
users to attack the network
configuration change automatically causes node to leave adhoc 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
Oct. 25, 2006
Jose' Brustoloni
26
Distributed attestation
Oct. 25, 2006
Jose' Brustoloni
27
Attested Merger
Oct. 25, 2006
Jose' Brustoloni
28
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
Oct. 25, 2006
Jose' Brustoloni
29
Latency for global key agreement
Oct. 25, 2006
Jose' Brustoloni
30
Latency distribution
Oct. 25, 2006
Jose' Brustoloni
31
Overhead
Oct. 25, 2006
Jose' Brustoloni
32
Impact on routing performance
Oct. 25, 2006
Jose' Brustoloni
33
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

Oct. 25, 2006
Jose' Brustoloni
34
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

Oct. 25, 2006
Jose' Brustoloni
35
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
Oct. 25, 2006
♦
36