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_at_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

3
Previous proposed solutions

• Verify nodes configuration before accepting node
  in network
• Node sends list with nodes software
  configuration and versions to a network server
• Server may
• accept nodes configuration, or
• confine node to restricted network that allows
  updating nodes software
• Expected to become common in a few years
• Ciscos Network Admission Control (NAC)
• some routers with proprietary protocols
  commercially available
• Microsofts Network Access Protection (NAP)
• TCGs Trusted Network Connect (TNC)
• some architecture documents out, but important
  details outside charter

4
Continuing vulnerability

• Malicious node can spoof list with nodes
  software configuration and versions
• How can network server be sure of nodes
  configuration?

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

6
TPM v. 1.1b secure coprocessor block diagram
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 owners control?
• Danger of software lock-in
• ? Sealing-free attestation confinement

8
Authenticated boot
Core Root of Trust for Measurement BIOS boot blo
ck
Measurement Agents
TPM
e.g., daemons and configuration files
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

10
Attestation

• Challenger sends nonce to node
• Nodes operating system asks nodes 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
  coprocessors public key
• Nodes operating system sends measurement log
  (with each software components secure hash),
  quote, and certificate to challenger
• Challenger verifies certificate, log, and quote

11
MITM attack against attestation
nonce
authentication server
conformant host
MITM
quote
tunnel (e.g. TLS)
12
Our solution Bound Keyed Attestation

• Combine attestation with Diffie-Helman to
  generate shared secret
• Cryptographically bind secret with tunnels keys
• ? Guarantee that attestation and tunnel endpoints
  are the same

13
BKA protocol
14
TCB prelogging

• Trusted Computing Base (TCB)
• anything that could compromise nodes 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

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

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 owners data
• cant 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

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

18
Authentication and authorization latency and
projected throughput PEAPv2
Step PEAPv2 PEAPv2LOG PEAPv2BKA
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 coprocessors
  quote time (2.5 s)
• Throughput with BKA can be easily increased by
  using multiple
• authentication servers

19
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
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

21
Cant we simply authenticate nodes?

• Securely establishing another mobile nodes
  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 networks computers?
• paramedics and home or body networks response to
  medical emergencies
• will my medical data be secure in your device?

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

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

24
Layering
25
Frame format
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
  nodes configuration
• data encrypted with keys that are available only
  if configuration not tampered with
• Challenge attestation latency

27
Distributed attestation
28
Attested Merger
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

30
Latency for global key agreement
31
Latency distribution
32
Overhead
33
Impact on routing performance
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
• Ciscos Network Admission Control/Microsofts
  Network Access Protection
• Protect access to enterprise networks only,
  vulnerable to spoofing
• TCGs Trusted Network Connect
• Protects access to enterprise networks, not
  ad-hoc
• Necessary operating system modifications (e.g.,
  for sealing) outside charter

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 senders usage policies
• funded by NSF Center for e-Design

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