Defining and Enforcing
Hardware Security Requirements
14 Oct 2011
CDR Mike Bilzor
mbilzor@nps.edu
2
3
=
?
4
Challenge
Can we define, and then enforce, security
requirements in hardware designs?
5
Agenda
•
•
•
•
Research Goals
Malicious Inclusion Threat to Processors
Existing Techniques for Detecting Malicious Inclusions
Proposed Method
•
•
•
•
Main Ideas
Details
Experimental Demonstration
Analysis
• Summary
6
Research Goals
7
Research Goals
• Examine and categorize previously demonstrated processor
Malicious Inclusions
• Develop a methodology whereby the stated security
requirements of a processor architecture can be translated
into runtime enforcement mechanisms that are integrated
into the processor implementation
• Develop tools for automating the translation from a specified
security requirement into an enforcement mechanism
8
Research Goals
• Demonstrate the methodology on a general-purpose
processor model, including detection of malicious inclusions
that are similar to those in real-world and academic examples
• Describe how the methodology can be implemented in
simulation, FPGA emulation, and in traditional and threedimensional fabricated chips
• Characterize themethod's algorithmic complexity, and analyze
its soundness and completeness
9
Processor Threat
10
Processor Threat
• Customers in DoD need trustworthy processors for highassurance applications
• Classified systems, weapons, aircraft
• Many processor/system designs incoporate third-party IP
• Very few advanced processors are manufactured in the U.S.
anymore [Adee08]
• Supply chain vulnernabilities: thousands of counterfeit
processors discovered by DoD [Grow08, King10]
11
Microprocessor Threat
• Some real-world reports [Adee08]
• 2007: Israel bombs a suspected Syrian nuclear facility, but Syrian
radars aren't functioning, reportedly disabled by a "kill switch"
• 2008: a European manufacturer reportedly designs a chip that can be
remotely disabled, and claims that French contractors have used the
chip in military equipment
• Academic demonstrations
• 2008: Yale researchers show how to modify an encryption processor
so that the encryption key is leaked through various channels [Jin08]
• 2009: Illinois researchers add two subversions to a processor [King09]
• Escalation of privilege attack, "shadow mode" attack
12
Existing Methods for
Detecting Malicious Inclusions
13
Malicious Inclusion (MI)
• Definition: an unauthorized, undocumented modification to a
piece of hardware, or hardware design unit, that circumvents
or subverts some portion of the hardware's functionality
14
Existing Methods
• Physical Analysis
• Destructive Analysis
• Very expensive, very slow, destructive to sample chip
• Power and Timing Analysis
• Detects large-scale changes well, but not small ones
• Doesn't detect malicious changes made in the design phase
• Design Analysis
• Functional Equivalence
• Reference design could itself have a malicious inclusion
• Rarely Used / Unused Circuit Identification
• False positives and false negatives
15
Proposed Method:
Observations and Main Ideas
16
Observations, Main Ideas
• A security policy specifies permitted and prohibited behaviors
• Malicious inclusions, in the examples seen to date, often
violate some behavioral restriction that is either stated or
implied in a processor's architectural specification
• If we can identify these behavioral restrictions in text
statements, it should be possible to express them formally, so
we can evaluate a particular processor's design against them
• Doing so can express a security policy, and may help us to
detect malicious inclusions that violate it
[Schn00]
17
Observations, Main Ideas
• The behavior of hardware systems can be expressed using
assertions, for example using the Property Specification
Language (PSL)
• Assertions are already used for functional verification, but can
also be used to describe behaviors that a processor's
designers feel should be prohibited
• The conversion of PSL assertions into equivalent synthesizable
"checkers" allows us to monitor hardware behavior, using
other hardware modules, at runtime
• This ability spans simulation, FPGA emulation, and fabrication
18
Proposed Method:
Details
19
Method Description
• Map behavioral restrictions from the architectural
specification into a set of PSL assertions
• Using a "checker-generator," create synthesizable hardware
modules, or "checkers," to evaluate the PSL assertions at
runtime
• Add the checker units (hardware modules) to the processor
design
• Evaluate the design under simulation and/or FPGA emulation
• If desired, leave the checkers in the processor for fabrication
20
Basic Method Workflow
Processor Architectural
Specification:
Behavioral Requirements
and Restrictions
Mapping of
Requirements
Processor
Implementation:
HDL Design
assert always ({ { ( ex_pc >= `A_IVT ) } | { rst !== 0 } | { `A_SM !== 0 } ||
{ ( except_start ; ex_pc < `A_IVT ) ; `A_RFE } });
assert always { ~ we_o } |-> ( { true ; true ; stable( `A_UART_OUT ) } );
assert always except_start -> ( (except_type > 0) && (except_type < 16) ) ;
assert always {(dtlb_done && ((~dcpu_we_i && ~supv && ~dtlb_ure) ||
(~dcpu_we_i && supv && ~dtlb_sre))) } |-> fault ;
assert always {(dtlb_done && ((dcpu_we_i && ~supv && ~dtlb_uwe) ||
(dcpu_we_i && supv && ~dtlb_swe))) } |-> fault ;
assert always ( {(mtxd_pad_o !== 4'h0)} |-> ( (WillTransmit) || (`A_SM === 1'b1) ||
(prev(eth_top.txethmac1.TxData[0]) != 1'bX)) );
assert always ( { stable(dvr_0[0]) } |-> ( (rst) || (`A_SM) );
assert always ({ ( if_insn === 32'hXXXXXXXX ) || ( ~ ( ( (if_insn[31:26] > 10) &&
(if_insn[31:26] < 17) ) || ( (if_insn[31:26] < 28) && (if_insn[31:26] > 21) ) ) });
"Checker
Generator"
module SERE3 (clk, reset, c, b, a, holds);
always @(posedge clk, posedge reset)
begin
if (reset) begin
SERE3_q0 <= 0;
SERE3_q3 <= 0;
...
Processor Implementation
With Checkers Built In
Synthesizable
HDL "Checkers"
Monitor Layer
Target Layer
Simulation
PSL
Assertions
FPGA
Emulation
Fabrication
Fabricated
3D-IC
The Property Specification Language
• Derives from linear temporal logic (LTL)
• Formalized in 2005
• Specifically designed for describing the behavior of hardware
designs
• Supports the most common hardware description languages,
like Verilog and VHDL
22
Example PSL Assertion
• “assert always ( b  next[2 to 3](c) )”
0
1
2
3
4
5
6
7
8
9
10
11
12
b
c
• The assertion holds on this execution trace, or input
23
PSL Checker-Generators
• Formal Checkers (FoCs): IBM, early 2000s
• MBAC: Boule, Zilic, 2006-present
• PSL rewrite rules
• Automata-based method
• HDL checker construction
• psl2hdl: NPS, 2011
•
•
•
•
•
•
Implementation of Boule-Zilic method, plus:
Full boolean-layer representation and simplifications
DFA minimization
Multi-language output (VHDL and Verilog)
PSL parse tree generation
Analysis of algorithmic complexity, soundness and completeness
24
Parse PSL Assertion
Example
assert always ({a ; d}) @ (rose(clk));
Parsing Tools
P-L-Y (Python Lex-Yacc)
Graphviz
Rewrite Rules
There are 39 total rewrite rules, which
reduce the formulas to a small number
of "base cases" to implement in
automata format
25
Construct and Combine Automata
{a ; b} | {c ; d}
c;d
a;b
a
;
b
c
;
d
26
Convert Automaton to Hardware
• Construction based on circuit model of an automaton
• States are modeled by flip-flops, all transitions occur on clock cycles
a
q
1
q
0
always @ (posedge clk)
begin
q1 <= q0 && a;
q2 <= (q1 && c) || (q0 && b);
end
c
hold
q
b
2
27
Tool Comparison
Questa Sim
synPSL
MBAC
psl2hdl
Parse All of PSL Simple Subset
✓
✓
✓
✓
Implement All Simple Subset
Assertions
✓
✓
✓
Create Synthesizable Checkers
✓
✓
✓
Implement Ranged SEREs
✓
✓
✓
✓
Generate Abstract Syntax Tree Output
Parse All of Underlying Flavor (Verilog)
Support Built-in Function Calls
DFA Minimization
✓
✓
some
some
some
partial
✓
Full Boolean-Layer Representation
✓
VHDL and Verilog Output
✓
[Boule08, Fin07]
28
Demonstration
29
Experiment Summary
• Implement open-source general-purpose processor
• Create "typical" MIs for it, knowing that some of them will
violate behavioral restrictions from the text in the processor's
architectural documents
• Demonstration Goals – show whether:
• The behavioral restrictions can be translated correctly into a set of PSL
assertions
• The PSL assertions can be converted into synthesizable hardware
"checkers" and added back into the design
• The checker modules can be created efficiently, in terms of time and
space required, using our checker-generator tool
• The checkers detect the malicious behaviors in question correctly,
when the MI triggers are active, with no false positives or negatives
30
MI-Detection Demonstration
• Platform: MINSOC system on chip, from OpenCores.org
• Has 32-bit or1200 CPU, MIPS-style instruction set, on-chip memory,
Ethernet, UART, debug support, and Wishbone bus
31
MI-Detection Demonstration
• Malicious Inclusions
•
•
#1: Allows a software process running in User Mode to escalate its
privilege level to Supervisor Mode. On-trigger and off-trigger are
each unique opcode/data combinations
•
#2: Leaks data from memory via the UART port, upon receipt of the
input trigger text “Get Data,” plus a memory location
•
#3: Disables the processor by commanding a "permanent" reset.
Triggered when input text “Shutdown” received at Ethernet terminal
Behavioral Requirements
•
Ten total requirements are mapped from specifications, and each is
implemented by one or more assertions.
32
Detections
• MI #1 (Supervisor Mode), when triggered, is detected
• MI #2 (Data Leak), when triggered, is detected
• MI #3 (Shutdown) is a disabling attack, is not detected, but it
is included for demonstration purposes
• There are no requirements in the OpenRISC architecture that it
violates
• When no MIs are triggered, all the checkers always "hold"
• A checker outputs "hold" or "fail"
• We also show that statement coverage in "infected" modules
is reduced when the MIs are not triggered, facilitating easier
manual analysis of a small portion of the design
33
Cross-Check
• All assertions were implemented using our checker-generator,
and matching "soft assertions" were also added to QuestaSim
• The output of all the checkers ("hold" or "fail") exactly
matched the semantics of the QuestaSim "soft assertions"
"Soft"
Assertions
Matching
Failure
Checker
Modules
34
Demonstration
• Though not adversarial, the demonstration:
• Employs the most advanced open-source general-purpose processor
design available
• Is only the second published MI-detection demonstration of its kind,
for a full general-purpose processor design
• Shows:
•
•
•
•
The architectural restrictions can be translated into PSL assertions
The assertions can be converted into synthesizable "checkers"
The checker modules can be created efficiently, using our tool
The checkers correctly detect the malicious behaviors in question, when
the MI triggers are active, with no false positives or negatives
35
[Hicks10, Jin08, Zhang11]
Analysis
36
Limitations: Cases Not Covered
• Absence or incompleteness of the requirements
• Limitations of the existing checker-generator techniques
• Current method restricted to PSL Simple Subset
• Some processor elements not well suited for the method
• Best example is memory elements (RAM); though they are
fundamentally circuits, the checker method is not efficient, since each
memory element would require a checker
• Use other techniques, like error correction, encryption, hashing, etc.
37
Limitations: Cases Not Covered
• Incompleteness of the checkers
• If the behavioral restrictions are clearly stated, but we omit checkers
from certain design units, the method implementation is incomplete
• After checkers are added, an MI is introduced and the
checkers are simultaneously subverted
• In this case, the attacker's task is made more difficult, but not
prevented
38
Strengths and Weaknesses
• Strengths
•
•
•
•
Early frame of reference (specification)
Persistence (checkers may be left in design)
Size (on average, checkers take up few hardware resources)
Compatibility (can be used in conjunction with obfuscation
techniques, as well as code coverage)
• Weaknesses
•
•
•
•
High level of effort – tedious to map requirements to assertions
Does not work efficiently with memory elements, only with logic
Adversary may subvert the checkers, too, if gaining later access
Not all requirements are dynamically enforceable (e.g., liveness
properties)
39
Lifecycle Coverage Comparison
40
[Hicks10, Banga10, Bilzor10a]
Soundness and Completeness
• PSL assertion to checker module
• obligation: given a PSL formula and an input word , according to
the PSL formal semantics,
if and only if the checker for holds
on input
• Formal equivalence under the PSL semantics for step 1, the rewrite
rules, was shown by Morin-Allory et al. using a PVS model[Morin10]
• We have constructed proofs for steps 2 and 3, and conclude that the
overall checker-generator method is sound and complete
Rewrite Rules
Convert Base
Case Formula
to Automaton
Convert
Automaton to
HDL Checker
41
Algorithmic Complexity
• Rewritten parse tree is traversed in DFS order: O(V+E) time
• Each automata combination algorithm for the base cases has
its own associated complexity, based on input automata size:
Potential
Exponential
Increase
42
Recommendations for Future Work
• Adversarial experiments
• Automate or semi-automate the translation of text-based
requirements into assertions
• Automate hierarchical completeness of checker installation
(when more than one checker is needed per requirement)
• Corporate partnership, commercial processor design
• Design a processor from inception with security-focused
requirements/assertions for each component
• Automated dependency analysis: "program slicing" for
VHDL/Verilog
43
Summary
44
Contributions
• A summary analysis of the processor malicious inclusion
examples published to date
• A novel, assertion-based process for formalizing security
requirements which derive from a processor's architectural
specification
• A method for dynamically enforcing processor security
requirements that is applicable across nearly all phases of
development, from simulation to fielded operation
• A demonstration, in a real general-purpose processor design,
of how the method can be used to detect some, though not
all, malicious inclusions
45
Contributions
• The most complete public-domain software tool for
generating synthesizable checkers, based on PSL assertions
• A description of the algorithmic complexity for each step in
the PSL checker-generator method, and arguments for its
soundness and completeness
• Summary: Yes, there is a method by which we can define, and
then dynamically enforce, some behavioral requirements in
hardware designs
46
Publications
• Published
• March 2011: International Conference on Information Warfare (ICIW '11),
Washington, DC (best Ph.D. student award)
• June 2011: IEEE International Symposium on Hardware-Oriented Security
and Trust (HOST '11), San Diego, CA
• Under Review
• DATE '12: Design, Automation, and Test Europe
47
Defining and Enforcing
Hardware Security Requirements
9 Sep 2011
CDR Mike Bilzor
mbilzor@nps.edu
References
•
[Adee08]
Sally Adee. "The Hunt for the Kill Switch," IEEE Spectrum, May 2008.
http://spectrum.ieee.org/semiconductors/design/the-hunt-for-the-kill-switch
•
[Abram09] Miron Abramovici and Paul Bradley. "Integrated Circuit Security – New Threats
and Solutions," CSIRW, April 2009.
•
[Agrawal10] Agrawal, Baktir, Karakoyunlu, Rohatgi, and Sunar. " Trojan Detection using IC
Fingerprinting," in Security and Privacy, IEEE Symposium on, (Oakland, CA, USA),
pp. 296–310, May 2007.
•
[Banga10] Banga and Hsiao. "Trusted RTL: Trojan Detection Methodology in Pre-Silicon
Designs," In Hardware- Oriented Security and Trust (HOST), IEEE International
Symposium on, pages 56–59, Anaheim, CA, USA, June 2010.
•
[Bilzor10]
•
[Bilzor10a] M. Bilzor, T. Huffmire, C. Irvine, and T. Levin. “Security Checkers: Detecting
Processor Malicious Inclusions at Runtime,” in IEEE International Symposium on
Hardware-Oriented Security and Trust, (San Diego, CA, USA), June 2010.
Bilzor. “3D Execution Monitor: Using 3D Circuits to Detect Hardware Malicious
Inclusions in General Purpose Processors,” in International Conference on
Information Warfare, (Washington, DC, USA), March 2011.
49
References
•
[Boule08]
Boule and Zilic. "Generating Hardware Assertion Checkers," Springer, 2008.
•
[Dav05]
Davis et al. "Demystifying 3D ICs: The Pros and Cons of Going Vertical," IEEE
Design & Test of Computers, November-December 2005.
•
[Eisner08] C. Eisner and D. Fisman. "A Practical Introduction to PSL," Springer, 2006.
•
[Fin07]
Findenig. "Behavioral synthesis of PSL assertions," Upper Austrian University of
Applied Sciences, Master’s thesis, 2007.
•
[Grow08]
Grow, Tschang, Edwards, and Burnsed. "Dangerous Fakes," Business Week, 2
October 2008.
•
[Hicks10]
Hicks, Finnicum, King, Martin, and Smith. "Overcoming an Untrusted Computing
Base: Detecting and Removing Malicious Hardware Automatically," Proceedings
of the 31st IEEE Symposium on Security & Privacy (Oakland), May 2010.
•
[Intel10]
Intel Corporation. "From Sand to Silicon: Making of a Chip," April 2010.
•
[Jin08]
Jin et al., "Experiences in Hardware Trojan Design and Implementation,"
Hardware-Oriented Security and Trust, IEEE International Workshop on, 2007.
•
[Karri10]
Karri, Rajendran, Rosenfeld, and Tehranipoor. "Trustworthy Hardware:
Identifying and Classifying Hardware Trojans," Computer, vol. 43, pp. 39–46,
October 2010.
50
References
•
[King09]
King et al. "Designing and Implementing Malicious Hardware," Proceedings of
the 1st USENIX Workshop on Large-Scale Exploits and Emergent Threats, pp. 1–8,
USENIX Association, 2008.
•
[King10]
King. "Fighting a Flood of Counterfeit Tech Products," Business Week, 1 March
2010.
•
[Lange07]
Lange. "Linear Time Logics Around PSL: Complexity, Expressiveness, and a Little
Bit of Succinctness," Lecture Notes in Computer Science 4703, pp. 90-104, 2007.
•
[McLean94] McLean. "A General Theory of Composition for Trace Sets Closed Under Selective
Interleaving Functions," Naval Research Laboratory, 1994.
•
[Morin10] Morin-Allory et al. “Validating assertion language rewrite rules and semantics
with automated theorem provers,” Computer-Aided Design of Integrated Circuits
and Systems, IEEE Transactions on, vol. 29, pp. 1436–1448, September 2010.
•
[Mys06]
Mysore et al. "Introspective 3D Chips.," International Conference on
Architectural Support for Programming Languages and Operating Systems
(ASPLOS). October 21-25, 2006. San Jose, CA.
•
[Schn00]
Schneider. "Enforceable Security Policies.," ACM Transactions on Information
and System Security, Vol. 3, No. 1, February 2000, pages 30-50.
•
[Sturton10] Sturton, Hicks, Wagner, and King. "Defeating UCI: Building Stealthy and
Malicious Hardware.," in Security and Privacy, IEEE Symposium on, Oakland, CA,
USA, May 2011.
51
References
•
[Tehr10]
Tehranipoor and Koushanfar. "A Survey of Hardware Trojan Taxonomy and
Detectio," IEEE Design and Test of Computers, vol. 27, issue 1, January/February
2010.
•
[TIC07]
Sharky. "DARPA TRUST in Integrated Circuits Program, Industry Day Brief,"
26 March 2007.
•
[Villa10]
John Villasenor. "The Hacker in Your Hardware," Scientific American, August
2010.
•
[Waks10]
Adam Waksman and Simha Sethumadhavan. "Tamper Evident Microprocessors,"
IEEE Security and Privacy, May 2010.
•
[Zhang11] Zhang and Tehranipoor. “Case Study: Detecting Hardware Trojans in Third-Party
Digital IP Cores,” in Hardware-Oriented Security and Trust (HOST), 2011 IEEE
International Symposium on, pp. 67–70, June 2011.
52