LINTON SALMON - DARPA · 2019-10-21 · Potential methods to instantiate this approach: • Meta-data tagging: Allowed states restricted through data/instruction tagging/rules •

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


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


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


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


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


• 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


• 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


• 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


• “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


• 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


• 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


• 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


• 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


• 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



Documents

LINTON SALMON - DARPA · 2019-10-21 · Potential methods to instantiate this approach: • Meta-data tagging: Allowed states restricted through data/instruction tagging/rules •