1 / 19

Supporting Security at the Gate Level: Opportunities and Misconceptions

Supporting Security at the Gate Level: Opportunities and Misconceptions. Tim Sherwood UC Santa Barbara. Sketchy Assumption # 1.

tommy
Télécharger la présentation

Supporting Security at the Gate Level: Opportunities and Misconceptions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting Security at the Gate Level:Opportunities and Misconceptions • Tim Sherwood UC Santa Barbara

  2. Sketchy Assumption #1 • Anything that doesn’t run x86, or an existing general purpose operating system, or allow the full generality of a systems we have today, is not important.

  3. Software Everywhere • critical infrastructure increasingly connected to the web (200,000 ICD/year in US alone)ability to run windows is not a bar for archiecture

  4. Flight Control Network Passenger Network Doing it “right” today is expensive • Boeing 787 has shared ARINC 629 bus “The proposed architecture of the 787 […] allows new kinds of passenger connectivity to previously isolated data networks connected to systems that perform functions required for the safe operation of the airplane. Because of this new passenger connectivity, the proposed data network design and integration may result in security vulnerabilities from intentional or unintentional corruption of data and systems critical to the safety and maintenance of the airplane.” FAA, 14 CFR Part 25 [Docket No. NM364] • High-Assurance Systems need to be verifiably: Secure, Reliable, and Predictable

  5. Assurance Evaluation Complexity • RedHat Linux: Best Effort Safety (EAL 4+) • $30-$40 per LOC • Integrity RTOS: Design for Formal Evaluation (EAL 6+) • $1,000 per LOC • More evaluation of process, notend artifact • Need ways to understand the artifact • Lots of great work already here at the software layer • Why should hardware people get involved?

  6. Hardware Scaling • The Good: Processing Capabilities are Scaling • more cores / chip • faster performance through speculation, prediction, caching, parallelism • allows for deeper system integration, custom functionality, and more feature rich software to run everywhere • The Bad: Increasingly Coupled Subsystems • predictors, caches, buffers, parallelism lead to complex timing variations and complicated “definitions of correctness” • systems are increasingly coupled • The Ugly: System Complexity Growing • evaluation complexity growing dramatically • Architectures are working AGAIST us here Core Core Predictors andHidden State Special PurposeLogic / Interconnect

  7. Sketchy Assumption #2 • All hardware is fully correct, it is software only that is the problem! • Reality: • Definition of correct is hard. Any model of what the machines does is wrong ( ISA, simple models ) • Processors have bugs • How do we know what the effect of the hardware implementation will have on software properties?

  8. Properties Cross Abstractions Applications Language Compiler/OS Security Properties Instruction Set Microarchitecture Security, Realtime, and Safety properties are a function of interactions across levels of abstraction make evaluation, debugging, optimization, and analysis very difficult Logic Gates

  9. SketchyAssumption #3 • Well, it is impossible to say anything about the system properties (including software) at the hardware level. Especially if there are bugs. • Reality: • Hardware sits below all of the software system definition. • Provides a way to unify timing channels, implicit flows, explicit flows • Sound but not perfectly precise, you give things up due to the semantic gap • Basic science required!

  10. Lease Unit 0 1 Timer PC Memory Hardware Design for Software Security Verification Applications timer expired? Restore PC +4 Language 0 PC jump target 1 Compiler/OS old value InstrMem SoundInformation FlowAnalysis Hardware/SoftwareDesign for Verifiable Security Predicates Security Properties Reg File Data Memory Instruction Set high low R2 throughdecode R1 Microarchitecture Logic Gates

  11. Formalization of Information Flow • Trusted vs. Untrusted Tasks • Trusted: processes which are critical to the correct functionality of the space vehicle systems • Untrusted: mission processes, diagnostics, anything whose malfunction will not cause a vehicle loss • Enforce the property of non-interference: • Verify information never flows from high to low. • Untrusted information is never used to make critical (trusted) decisions nor to determine the schedule (real-time) • Technique for general lattice policies • e.g. Secret = High, Unclassified = Low passenger router X avionics

  12. a a b b b a t t o o t Formalizing Information Flow • Automatically generate logic that tracks labels • Tracking Logic is compositional • Captures timing channels, and real time constraints • Security Constraints can be expressed and hardware assertions MohitTiwari, Hassan Wassel, BitaMazloom, Shashidhar Mysore, Frederic Chong, and Timothy Sherwood. Complete Information Flow Tracking from the Gates Up Proceedings of the 14th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), March 2009. Washington, DC Jason Oberg, Wei Hu, Ali Irturk, MohitTiwari, Timothy Sherwood and Ryan Kastner Theoretical Analysis of Gate Level Information Flow Tracking, Proceedings of the 47th Design Automation Conference (DAC), June 2010.

  13. s s b a a a a b b s s b t t t t s s o o o t Shadow Logic Composition

  14. Sketchy Assumption #4 • Look at all those gates! Gate level techniques will kill your performance and efficiency! • Reality: • You only need hardware to help with dynamic checks. • This shadow hardware can be used for static analysis

  15. GLIFT Verification Flow Abstract Design Augmented Design Digital Design U U * * labeled inputs abstract inputs ** clock clock U T U T * * ** test inputs 10 10 state state 01 clock a a L L 2. Augmentation 1. Abstraction T U 1011 a L state * 1 ** abstract output labeled output ** 10 state input T U * 1 Information flow lattice Specification of unknown bits output • This is analysis, what about design?

  16. Brief History • Rev 1: Provable properties (but miserable to program) • Rev 2: Execution Leases • Rev 3: Full prototype system (with partitionable caches, pipelining, IO, etc.) • Rev 4: Multiprocessor with NoC • Rev 5: ???

  17. Cross-University Laboratory forTrustworthy Embedded Systems Analysis Applications Metodi , Aerospace Irvine, NPS Bultan, UCSB Verification Huffmire, NPS Compiler/OS Hardekopf, UCSB Chong, UCSB Language Sherwood, UCSB Kastner, UCSD Logic Gates Architecture

  18. Thank you to the students! • Ali Irturk, BitaMazloom, Cynthia Irvine, Dejun Mu, Hassan Wassel, Jason Oberg, Jonny Valamehr, MohitTiwari, VineethKashyap, Wei Hu, Xun Li, Ying Gao, Varun Jain

More Related