Inspection-Enforced
Internet Safety
M. Satyanarayanan
School of Computer Science
Carnegie Mellon University
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 1
The Wild West in 2005
The Internet is an unregulated free-for-all today
• no constraint on what you can connect
• no requirement of minimal safety
• no social imperative to obey security directives/upgrades
Consequence
• individual virtue (compliance) is not good enough
• innocent bystanders (i.e., all of us) can be hurt by negligence of others
• my OS or app vulnerabilities can help attacks on others
• a form of the “tragedy of the commons”
Just passing laws would not help
• no means of enforcement
• no provable way of establishing machine state after the fact
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 2
Coping with Older Forms of Risk
Automobiles
• negligence in maintaining my car can hurt you
• states define minimal safety standards
• regime of regular inspections by trusted entities
• enforceable laws and penalties for non-compliance
Similar approach for risks of other technologies
• aircraft (FAA inspectors)
• elevators (state/local inspectors)
Society does not expect/demand total elimination of risk
• recently-inspected car/plane/elevator could fail
• managing risk to tolerable levels is the key
• threat of after-the-fact discovery/punishment works
• simple tuning parameters to balance tradeoff: risk vs. social cost
frequency of inspection, thoroughness of inspection, competence of inspectors, …
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 3
Can This Work for the Internet?
At least two major obstacles
Time scale
• virus/worm attacks happen in seconds/minutes/hours
• not months/years!
• frequency of inspection will have to be at this time scale
Physical transport
• completely infeasible to transport hardware to inspectors
• equally infeasible to transport inspectors to hardware
• scale of problem is very large (embedded systems)
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 4
New Opportunity
Combine 3 technologies developed over the last decade
1. Cheap, efficient virtualization of hardware
• e.g. VMware, Xen, Intel VT platform
• encapsulate and capture entire machine state
2. Trusted hardware agents
• e.g. TPM from IBM, le Grande from Intel, TCG
• encrypt and digitally sign captured state (attestation)
• confidence that captured state matches reality
3. Cheap, efficient distributed storage
• content-addressable storage, DHTs, server-based systems
• transport and archive captured state for long term
• produce in a court room many years hence, if needed
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 5
Basic Idea
1. Require every Internet-connected piece of hardware to support
• virtualization
• tamper-proof trusted agent
2. Periodically capture entire state, encrypt and sign
3. Ship asynchronously to inspection sites
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 6
Grand Challenge
Can we show that Inspection-Enforced Internet Safety really works?
• not just demos in the lab
• research community lives in this world
• “eat your own dog food”
Convincing live demonstration & integration of our research
• provide basis for sane regulation/legislation of Internet
• demonstrate value of research investment to society
Large, multi-year, multi-institution R&D effort
• produce open-source software
• showcase CS research to the world
• inherently a collaborative, society-wide effort
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 7
Some Research Problems - I
Secure state capture
• how exactly to use TPM, TCG hardware?
• what additional hardware, OS support needed?
Scalability
• huge volume of captured state
• efficient transport, duplicate elimination, archival policies
Inspection frequency and completeness
• how often, adaptation to threat levels,
• eager vs. lazy, complete vs. probabilistic, game-theoretic analyses
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 8
Some Research Problems - II
Poorly-connected sites
• connectivity may be enough for attacks but not full state transport
• proxy-based trust, delegation?
Impact on usability
• how to minimize impact on users
• how to do all of this in the background
• small-footprint implementation
… many, many others …
©2005 M. Satyanarayanan
NSF Grand Challenges Sep 2005 - 9