Slide 1

CDR Mike Bilzormbilzor@nps.eduDefining and EnforcingHardware Security Requirements14 Oct 2011

Welcome. We begin with a few high-level motivating questions.12

Suppose someone hands you a processor. Does it have a backdoor? Is there any hidden functionality? Is it secure, and what does secure mean, anyway?

23

Now someone hands you a processor design. Does it match the architectural specification? Is there any extra, hidden functionality?

34

=?Finally, someone hands you a fabricated chip and a processor design. Does the chip faithfully implement the design? Does it contain anything extra? How do you know?

4ChallengeCan we define, and then enforce, security requirements in hardware designs?5AgendaResearch GoalsMalicious Inclusion Threat to ProcessorsExisting Techniques for Detecting Malicious InclusionsProposed MethodMain IdeasDetailsExperimental DemonstrationAnalysisSummary6Research Goals7Research GoalsExamine and categorize previously demonstrated processor Malicious InclusionsDevelop a methodology whereby the stated security requirements of a processor architecture can be translated into runtime enforcement mechanisms that are integrated into the processor implementationDevelop tools for automating the translation from a specified security requirement into an enforcement mechanism

8Research GoalsDemonstrate the methodology on a general-purpose processor model, including detection of malicious inclusions that are similar to those in real-world and academic examplesDescribe how the methodology can be implemented in simulation, FPGA emulation, and in traditional and three-dimensional fabricated chipsCharacterize themethod's algorithmic complexity, and analyze its soundness and completeness9Processor Threat10Processor ThreatCustomers in DoD need trustworthy processors for high-assurance applicationsClassified 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]11China, Taiwan, KoreaU.S. companies becoming "fabless" design onlySome companies have a reputation for stealing designs (IP)

11Microprocessor ThreatSome 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 demonstrations2008: 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

12We can see from these examples that,\especially for customers with high-assurance applications, there is a need to define and enforce hardware security requirements.12Existing Methods forDetecting Malicious Inclusions13Malicious 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

14Existing MethodsPhysical AnalysisDestructive AnalysisVery expensive, very slow, destructive to sample chipPower and Timing AnalysisDetects large-scale changes well, but not small onesDoesn't detect malicious changes made in the design phase

Design AnalysisFunctional EquivalenceReference design could itself have a malicious inclusionRarely Used / Unused Circuit IdentificationFalse positives and false negatives

15Proposed Method:Observations and Main Ideas16We believe that, instead of defining security strictly in terms of whether two processors are equivalent or not, we can adopt a more constructive approach. Our method is based on the following observations.16Observations, Main IdeasA 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 it17[Schn00]Observations, Main IdeasThe 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 runtimeThis ability spans simulation, FPGA emulation, and fabrication18So how might we do that?18Proposed Method:Details19Method DescriptionMap 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 fabrication20Processor Architectural Specification:Behavioral Requirements and RestrictionsProcessorImplementation:HDL DesignPSL Assertions"Checker Generator"Synthesizable HDL "Checkers"Processor ImplementationWith Checkers Built In Simulation

Target LayerMonitor Layer FPGAEmulationFabricated3D-ICFabricationMapping ofRequirementsmodule SERE3 (clk, reset, c, b, a, holds);always @(posedge clk, posedge reset)begin if (reset) begin SERE3_q0 ( { 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) ) ) });Basic Method WorkflowThe question we would like to answer is: does a particular processor implementation violate any restrictions stated in the text of the processor's architectural manual?21The Property Specification LanguageDerives 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

22Example PSL Assertion assert always ( b next[2 to 3](c) )

The assertion holds on this execution trace, or input23

bc0 1 2 3 45 6 7 8 9 10 11 12PSL Checker-GeneratorsFormal Checkers (FoCs): IBM, early 2000sMBAC: Boule, Zilic, 2006-presentPSL rewrite rulesAutomata-based methodHDL checker constructionpsl2hdl: NPS, 2011Implementation of Boule-Zilic method, plus:Full boolean-layer representation and simplificationsDFA minimizationMulti-language output (VHDL and Verilog)PSL parse tree generationAnalysis of algorithmic complexity, soundness and completeness

24Parse PSL Assertion25Exampleassert always ({a ; d}) @ (rose(clk));Parsing ToolsP-L-Y (Python Lex-Yacc)GraphvizRewrite RulesThere are 39 total rewrite rules, which reduce the formulas to a small number of "base cases" to implement in automata formatConstruct and Combine Automata26a ; bba ;c ; ddc ;{a ; b} | {c ; d}Convert Automaton to HardwareConstruction based on circuit model of an automatonStates are modeled by flip-flops, all transitions occur on clock cycles27q0q1q2holdabcalways @ (posedge clk)begin q1 )Suffix implication, overlapping (|->)

68Applications69

Target LayerMonitor LayerFabricated 3D-IC

FPGA Emulation

Fabrication Simulation

70From Requirements to AssertionsExample Requirement: "special registers may only be modified if the CPU is in supervisor mode" Source: OpenRISC Architecture p. 21-3, Table 4-2Source: OpenRISC Architecture p. 20

Assertion: "assert always {spr_we ; spr_we} |-> SM;"(change from special register write enable from low to high, overlapping suffix implication, Supervisor Mode)

Note: important requirements could be missing, and some requirements may be implied, ambiguous, or incompletely stated in the architecture documents. Our method relies on the behavioral requirements being stated as clearly and completely as possible.71Requirements to AssertionsExample Requirement: Supervisor mode is only entered from User Mode on reset startup, or on exception entry.Source: OpenRISC Architecture p. 338, The OpenRISC 1000 provides two execution modes: user and supervisor. Processes run in user mode and the operating system kernel runs in supervisor mode.Source: OpenRISC Architecture p. 252, Processing of exceptions begins with a rise to supervisor mode.Source: Specification for or1200, p. 24, The Reset signal, when asserted high, immediately resets all flip-flops inside or1200. When de-asserted, or1200 will start the reset exception.Not stated: "Under no other circumstances does the processor enter Supervisor Mode."Assertion: "assert always {A_SM; A_SM } |-> (except_start || rst);" 72From Assertions to CheckersParse PSL assertionApply rewrite rules until formula has only "base case" operatorsAutomata conversion:Implement simple automata at the leaves of the parse treeMoving up the parse tree from the leaves, combine the automata from child nodes, using various combination techniquesThe root of the tree will end up with a single "checker" automatonAutomata use boolean expressions for edges; inputs represent signal assignments in the designConvert checker automaton to HDL representationHDL checker will output a "hold" or "fail" signal 73[Boule08]From Assertions to CheckersChecker-generator takes an automaton as input, automatically constructs an HDL module (VHDL, Verilog) with input signals, local signals, synchronous assignments, and outputsThe module can be immediately added as a design file. Example:74module S2 (clk, reset, d, b, c, a, holds);

input clk, reset; input d, b, c, a; output holds; reg S2_q0, S2_q2, S2_q5, S2_q4, S2_q7, S2_q6;

// Original assertion = assert always ({{a [* 0 to 1] ; b [* 0 to 2] } : { c [* 0 to 1] ;d}}) @ (rose(clk)); // Rewritten assertion = assert {[+]} |-> ({{{[* 0 ] | {a}} ; {[* 0 ] | {b} | {b ; b}}} : {{[* 0 ] | {c}} ; d}}) @ (rose (clk)) ;

always @(posedge clk, posedge reset)begin if (reset) begin S2_q0