SAFE - A Clean-Slate, Secure Computing Platform Approved for Public Release; Distribution Unlimited. Cleared for Open Publication on 06/11/14. AFRL Safe and Secure Systems and Software Symposium (S5). Dayton, Ohio USA, June 12, 2014 Presenter: Greg Sullivan, BAE Systems, [email protected]with the University of Pennsylvania, Harvard University, and Northeastern University
26
Embed
SAFE - A Clean-Slate, Secure Computing Platform€¦ · SAFE - A Clean-Slate, Secure Computing Platform . Approved for Public Release; Distribution Unlimited. Cleared for Open Publication
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SAFE - A Clean-Slate, Secure Computing Platform
Approved for Public Release; Distribution Unlimited. Cleared for Open Publication on 06/11/14.
AFRL Safe and Secure Systems and Software Symposium (S5).
• SAFE Prehistory • SAFE Vision • SAFE Design • SAFE Status • What next? • Summary
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 2
Computer History • Smaller, cheaper, faster • Pervasive
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 3
Did I mention security? No.
SAFE History
Cyber Insecurity
It’s bad.
It’s going to get worse. SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 4
SAFE History
Not Solutions P4I – “Perimeter Protection, Patch, and Pray”
Do you feel safer now? SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 5
Probably not. What’s the I?
SAFE History
Status Quo: Deadlock • Computer architecture: smaller, cheaper, faster
– Even if add security features to hardware, languages and OS broken – Complex (Baroque memory subsystem to support multicore, etc.)
Backwards compatibility constraints – “Raw, seething bits” – no (secure) metadata on which to base security
• Programming languages: Security features subverted by vulnerable OS, poor HW support
• Operating systems: huge installed base. Security features easily subverted by insecure base. Extremely difficult to formalize and verify (due to PLs, memory model, etc.)
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 6
A vulnerability at any level seems to subvert the security of the entire system.
SAFE History
Stuck in a local maximum
SAFE Vision Clean Slate • Take “Clean Slate” mandate seriously • Deliberately explore unexplored regions
• Fast domain crossing – Gates: a single mechanism for
updating current authority
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 10
Trade Silicon for Security
0x 1 F A B C 0 1 2 3 0x 2 3 4 0 0 0 1 2 3 0 8
Atomic Group 08 = “Pointer to Frame of memory”
Fat Pointer Encoding of Addresses “Pointer is to memory starting at 0xABC of size 123” (notional).
Label (only readable in Tag Manager) Secrecy: Bob or Alice can read Integrity: Endorsed by WebServer
One Indivisible Atom – Three Parts
SAFE Design
Checks at Every Instruction
• So now, what is this? • Check that R2 is a pointer (atomic group 08)
– Also check that R1 is an integer, and R2+R1 < bounds *R2
• The tag points to a structure that requires that Alice authority be installed to access the value – Check authority register of machine
• The tags are sent to the Tag manager, which checks access and calculates tag for result
• For example [Alice or Bob] + [Alice] ⇒ [Alice]
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 11 Trade Silicon for Security
0x 1 F A B C 0 1 2 3 0x 2 3 4 0 0 0 1 2 3 0 8 offp R1 R2 PC R2
SAFE Design
Efficient Fat Pointers • Compact encoding
– 64bit word for a 46bit address • Force alignment; floating-point
like length – 3% memory fragmentation
• Hardware bounds check – Operates in parallel with
other units, like ALU – Rules out buffer overflows
• Pointer as capability – Can only address segment
if given pointer
12 SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons.
CCS 2013
SAFE Design
TMU Cache • Tag Management Unit caches access+IFC
queries
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 13
FPGA 2013
SAFE Design
Process Tags in Parallel
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 14
Trade Silicon for Security No need to trade speed for security
SAFE Design
SAFE Microarchitecture
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 15
Running on an FPGA
SAFE Design
SAFE Zero Kernel Operating System • Automatic memory management • No shared memory between threads • Principals, Authorities, and Tags (PAT) server • Least privilege OS components
– only allocator can forge pointer
– only scheduler can set current thread ptr.
– only PAT server can deref tags as pointers
– etc. SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons.
16
SAFE Design
Encapsulation via Gates, Threads Gates: • Single HW mechanism to
Require crypto and some sort of “canonicalization”
What’s Next
SAFE Next, Continued
• Adding TMU to conventional processor – “PUMP” (Programmable Unit for Metadata
Processing) papers
• Verification work on micro policies – Based on PUMP work
• Use LLVM compiler infrastructure – Conventional language ⇒ SAFE via Tempest – Breeze (or Tempest) ⇒ Intel or ARM
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 21
What’s Next
SAFE Scenarios • Three overall scenarios:
1. SAFE as “pillars of trust” in e.g. SOUND-enhanced distributed system
2. SAFE “secure data processor” as front-end to database 3. SAFE for embedded systems
• Glucose monitor • Smart phones. E.g. Project Ara at Google
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 22
What’s Next
SOUND Cloud Un-
SAFE SAFE
Un-SAFE
Un-SAFE
Un-SAFE
Un-SAFE
SAFE Data Store
SAFE preserves information flow
labels and enforces policies
Network
SAFE
SAFE
SAFE – The Case for Clean Slate • Hardware can immediately guarantee:
– no buffer overflows – no code injection
• Software-defined rules, with hardware support, can securely, and with good performance, implement: – Control flow integrity (no ROP) – Mandatory access control – Information flow control (secrecy, taint, provenance,
per user, etc.) • Formal methods can achieve an extremely high degree of
confidence in security, backed up by hardware
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 23
Summary
Stop Complaining. Do Something. • Stop whining about the difficulty of fixing current systems
(in fact, they are impossible to fix) • We know how to design and build extremely secure
systems, at the expense of silicon but not performance: • Hardware interlocks for universal security • Hardware-mediated software-defined information flow
and access control policies • Formal verification to prove correct adherence to
policies • It is imperative that we push forward
• The payoff in increased security is huge • The loss due to the inevitable exploitation of
conventional systems would be unfathomable
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 24
Summary
SAFE: Clean Slate HW, PL, OS
System Services (device drivers,
networking, storage)
User Programs
Memory Manager / GC
TMU Manager Scheduler IPC
HardWare (written in Bluespec)
SAFE Processor
TMU Rule Cache
Stock TPM
UserWare (written in
Breeze)
ConcreteWare (in Tempest, Assembly)
Breeze Compiler
Proofs
Formal Semantics
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 25
http://www.crash-safe.org/
SAFE AFRL S5, 6/12/2014 Non-Technical Data - Releasable to Foreign Persons. 26