LINTON SALMON - DARPA · 2019-10-21 · Potential methods to instantiate this approach: •...
Transcript of LINTON SALMON - DARPA · 2019-10-21 · Potential methods to instantiate this approach: •...
LINTON
PROGRAM MANAGER
SALMON
MTO/DARPA
Distribution Statement A – Approved for Public Release, Distribution Unlimited 2
SYSTEM SECURITY INTEGRATED THROUGH HARDWARE AND FIRMWARE (SSITH)
Develop hardware design tools to provide inherent security against hardware vulnerabilities that are exploited through software in DoD and commercial electronic systems.
TODAY: PATCH AND PRAY• *2800 vulnerability instances• 2800 software patches
FUTURE: SSITH• SSITH will protect against all 7
hardware classes
ELECTRONIC SYSTEMS NEED BETTER PROTECTION
*2015 MITRE-recorded hardware vulnerabilities (CVE)
Open VulnerabilityX Blocked Vulnerability
Blocked AttackOpen to Attack
Legend
4Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)
APPROACH: LIMIT THE HARDWARE TO ALLOWABLE STATES
Limiting the allowable state space makes securing the system much easier• Restriction of hardware states permits verification through exhaustive techniques such as formal
methods• It is critical to restrict the state space while maintaining system performance
Potential methods to instantiate this approach:• Meta-data tagging: Allowed states restricted through data/instruction tagging/rules• Obfuscation: Obscuring the state of instruction and memory usage• Formal methods: Use of mathematical proofs to define and limit acceptable states
5Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)
SECURITY IMPLEMENTED WITH ACCEPTABLE CSWAP IMPACT
SSITH will leverage recent technology advancements to find/develop more efficient ways to implement electronic system security in hardware as measured by CSWaP.
• Implementation in hardware allows more security capability• RSA public key operation: 2,310% better performance• ECC public key operation: 1,320% better performance
6Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)
SSITH PROGRAM PLAN
• TA-1: Novel hardware architecture and design tool development• Develop security architectures that protect against hardware vulnerabilities• Develop design tools that implement the security architectures being explored
• TA-2: Security evaluation and representation• Create and implement a security evaluation methodology for the pro• Define quantitative security metrics for hardware/firmware security
FY2021FY2019FY2018 FY2020
7Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)
SSITH will develop and refine hardware security concepts, instantiate those concepts in a set of SoC design tools, and demonstrate their effectiveness in hardware.
Team Technical Area
Technical Approach Principle Investigator
Charles Draper Lab 1 Enforcement of security through tagging Dr. Chris Casinghino
Columbia University 1 Formal methods verification of security Dr. Simha Sethumadhavan
Cornell University 1 Controlling information flow through tags Dr. Edward Suh
Lockheed Martin 1 ISA security extensions enforced by tags Mr. Jim Eiche
MIT 1 Formal methods description of security Dr. Adam Chlipala
SRI International 1 Principal of Least Privilege enforced by tags Dr. Peter Neumann
University of Michigan 1 Ensembles of moving target defenses and churning Dr. Todd Austin
UC San Diego 1 Context sensitive decoding andDNN anomaly detection Dr. Dean M. Tullsen
Galois 2 Security metrics and hardware representation Dr. Joe Kiniry
SSITH PROGRAM AWARDEES
8Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)
Distribution Statement “A” (Approved for Public Release, Distribution Unlimited)
JOSEPH
GALOIS
KINIRY
Portland, OR
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
BALANCING EVALUATION OF SYSTEM SECURITY PROPERTIES WITH INDUSTRIAL NEEDS
BESSPIN
THIS RESEARCH WAS DEVELOPED WITH FUNDING FROM THE DEFENSE ADVANCED RESEARCH PROJECTS AGENCY (DARPA).
THE VIEWS, OPINIONS AND/OR FINDINGS EXPRESSED ARE THOSE OF THE AUTHOR AND SHOULD NOT BE INTERPRETED AS REPRESENTING THE OFFICIAL VIEWS OR POLICIES OF THE DEPARTMENT
OF DEFENSE OR THE U.S. GOVERNMENT
• The BESSPIN team, led by Galois, must…• Help 8 teams• Spanning 21 companies and universities• Measure their 3 RISC-V CPUs• In order to use quantifiable, formal evidence• To balance security against power, performance, and area
• But how can we “measure” security?• What is a meaningful metric? What are its units?• How can we authentically measure security automatically?
The BESSPIN mission
A Balancing Act
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• Let’s reflect upon how hardware engineers work today… they...• ...want to use their own terminology• ...want to use their existing hardware design languages• ...know that runtime verification (testing a system, in simulation or
emulation) is the way to gain assurance• ...know that “formal” is a mysterious new promising tool
• And how about hardware firms?• IP reuse is mandatory to meet corporate product schedules• Deep knowledge of existing IP rarely exists
Reflections on hardware engineers and hardware firms
System Security Properties: The Engineer’s POV
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• SSITH focuses on 7 classes of vulnerabilities• Phase 1: (1) buffer errors, (2) permissions and privileges, and
(3) information leakage• Phase 2: (4) resource management and (5) crypto errors• Phase 3: (6) numeric errors and (7) code injection
• Existing descriptions of these classes are informal (NIST and MITRE documents, BlackHat and Defcon presentations, academic papers) or are pointwise examples (pieces of code with flaws)
A SSITH-centric focus on security
System Security Properties: The SSITH POV
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• Industrial priorities are time-to-market, cost, and features• DoD priorities also include correctness, security, robustness• System testing is the primary means by which the industry gains
assurance about the ok-ness of their systems• Buzzwords: unit testing, agile programming, devops
• Good enough for consumer electronics—we have been trained to expect devices to misbehave, crash, and be insecure
• Long term, not good enough for the DoD• “Program testing can be used to show the presence of bugs, but
never to show their absence!” -Dijkstra
Formal methods for secure hardware impacts both domains
Industrial and DoD Demands
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• “The real value of tests is not that they detect bugs in the code, but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code.” -Hoare
• We have chosen to formalize these vulnerability classes in a fashion that permits us to: (a) generate example weaknesses, and (b) automatically classify existing potentially flawed code
• The formalization is in Higher-Order Logic (HOL)• We use Literate PVS (a la Knuth) to write the human-readable and
machine-processable “BESSPIN Hardware Security Bible”
How to sneak proper formal methods into hardware security
Formal Methods
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• Use Product Line Engineering (PLE) and a systems architecture to describe and reason about a family of products
• Extract a systems architecture from a computer architecture• Extract a feature model from a systems architecture and a computer
architecture• Configure a systems architecture into a computer architecture• State correctness and security properties at the systems architecture level
using the nomenclature of security• Automatically refine such properties into the computer architecture and its
validation and verification test benches• Use verification and formal tools for hardware for assurance
How can hardware engineers write and understand security properties?
Applied Formal Methods
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• Extract a coherent systems architecture from any piece of hardware IP described with the Bluespec SystemVerilog, Chisel, SystemC, SystemVerilog, and Verilog HDLs
• Specify correctness and security properties at the systems architecture level and with respect to the system’s feature model
• Have an automated means by which to refine (i.e., compile) those properties to its associated computer architecture
• Implementation-level properties are...• Statically checked (e.g., by using JasperGold), or• Dynamically checked (e.g., by using the BESSPIN Security Verification
Factory)
Some of the tools we we are building to achieve SSITH’s goals
Methods, Tools, and Technologies
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• A feature model GUI permitting the exploration of, and reasoning about, the PPAS of all products derivable from a product line
• A systems architecture GUI permitting the exploration of, and reasoning about, an architecture’s PPAS
• GUI dashboards summarizing the state of the system, including PPAS design decisions and validation and verification evidence
Tools that help engineers make tradeoff decisions
Balancing Security against PPA
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• Industry will continue to care about time-to-market, cost, and features more than correctness and security• Ensure that the Galois BESSPIN Tool Suite helps industry reap the
benefits witnessed in applied formal methods for software and firmware: evidence-based PPAS balanced against design time, cost, and customer demand
• The DoD continues to have high correctness and security demands• Help entities tasked with building, evolving, or maintaining DoD
systems make wise evidence-based tradeoffs in correctness and security with formal assurance with negligible impact on cost and time
The BESSPIN project’s mission and its impact
Implications to the Industry and the DoD
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
• Security is not just about secure hardware• Secure hardware is not just about secure CPUs
• Security spans scales of hardware from IP cores to SoCs• Security spans system design from silicon to software
What is truly needed next is a DARPA program that spans I2O and MTO
and tackles end-to-end system security.
Security does not end at SSITH, it begins with SSITH
A Final Thought
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited
DISTRIBUTION STATEMENT A: Approved for Public Release, Distribution Unlimited