Trusted Hardware:
Can it be Trustworthy?
Design Automation Conference
5 June 2007
Cynthia E. Irvine
Naval Postgraduate School
Karl Levitt
National Science Foundation
What is Security?
Enforce polices to protect information
Confidentiality
Prevent reading by unauthorized individuals
Integrity
Prevent unauthorized modification or corruption
Ensure that information is available when needed
Trusted vs Trustworthy
Many systems are trusted to enforce information
security policies
Depended upon to “do the right thing”
Unfortunately
Most systems are not very trustworthy
Not compliant with stated protection functionality
The Paranoia Factor
Most engineers care about functionality
Does the system work as specified?
Is performance good?
Is it robust against failures
Security engineers worry about exploitation
Asymmetric threat: advantage adversary
Unspecified functionality
Careless operational practices
Threats
Developmental
Failure to meet specifications
Insertion of trap doors
Operational
Poorly designed interfaces  user errors
Unauthorized information flows via system metadata
 covert channels
Insecure configurations
Making Systems Trustworthy
(for developers)
Know what policy you want to enforce
Formalize it, develop proofs of consistency and
maintenance of secure state
Develop a lifecycle approach to address
developmental and operational threats
Follow the secure lifecycle plan!
Sounds easy takes enormous will power!
Is it Trustworthy? (for customers)
Don’t just believe vendor claims
Ask for third-party assessment
Assessment should include
Check of secure lifecycle process
Check of system refinement
Model to code
Check that requirements were met
Vulnerability analysis
Analysis of functional and penetration testing
Review of user and administrator guidance
for completeness
Trusted System Requirements
Maintain a domain for its own execution that protects
it from external interference or tampering
Maintain process isolation through the provision of
distinct address spaces under its control
Be internally structured into well-defined largely
independent modules
Modules designed such that the principle of least
privilege is enforced
The interface completely defined and all protection-critical
elements of the identified
More Requirements
Designed and structured to use a complete, conceptually
simple protection mechanism with precisely defined semantics
This mechanism shall play a central role in enforcing internal
structuring of the protection-critical elements and of the system
as a whole
Incorporate significant use of layering, abstraction and
data hiding
Direct significant system engineering toward minimizing
complexity and excluding modules that are not
protection-critical
Developmental Approach
Assurance Requirements Today
Configuration Management
Life Cycle Support
Development
Architectural Design
Functional Specification
Implementation Representation
Trusted Initialization
High Level Design
Low Level Design
Representation Correspondence
Security Policy Modeling
Guidance Documents
Testing
Vulnerability Assessment
Trusted Delivery
Questions for HW Developers
Are the threats the same?
What are the parallels for system development and
for trusted hardware?
How do you know that what is specified is what is
encoded on the device?
Can formal methods help?
Cynthia Irvine
Naval Postgraduate School
[email protected]
Karl Levitt
National Science Foundation
[email protected]