Trusted Hardware: Can it be Trustworthy? Design Automation Conference 5 June 2007 Karl Levitt National Science Foundation Cynthia E. Irvine Naval Postgraduate School

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 Karl Levitt National Science Foundation