1 / 52

Defining and Enforcing Hardware Security Requirements 14 Oct 2011

Defining and Enforcing Hardware Security Requirements 14 Oct 2011. CDR Mike Bilzor mbilzor@nps.edu. =. ?. Challenge. Can we define, and then enforce , security requirements in hardware designs?. Agenda. Research Goals Malicious Inclusion Threat to Processors

dandre
Download Presentation

Defining and Enforcing Hardware Security Requirements 14 Oct 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Defining and EnforcingHardware Security Requirements14 Oct 2011 CDR Mike Bilzor mbilzor@nps.edu

  2. = ?

  3. Challenge Can we define, and then enforce, security requirements in hardware designs?

  4. Agenda • Research Goals • Malicious Inclusion Threat to Processors • Existing Techniques for Detecting Malicious Inclusions • Proposed Method • Main Ideas • Details • Experimental Demonstration • Analysis • Summary

  5. Research Goals

  6. 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

  7. 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 three-dimensional fabricated chips • Characterize themethod's algorithmic complexity, and analyze its soundness and completeness

  8. Processor Threat

  9. Processor Threat • Customers in DoD need trustworthy processors for high-assurance 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]

  10. 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

  11. Existing Methods forDetecting Malicious Inclusions

  12. 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

  13. 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

  14. Proposed Method:Observations and Main Ideas

  15. 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]

  16. 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

  17. Proposed Method:Details

  18. 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

  19. Basic Method Workflow Processor Architectural Specification:Behavioral Requirements and Restrictions Mapping ofRequirements 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) ) ) }); PSL Assertions ProcessorImplementation:HDL Design "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; ... Synthesizable HDL "Checkers" Processor ImplementationWith Checkers Built In Monitor Layer Target Layer Fabricated3D-IC Simulation Fabrication FPGAEmulation

  20. 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

  21. Example PSL Assertion • “assert always ( bnext[2 to 3](c) )” • The assertion holds on this execution trace, or input 0 1 2 3 4 5 6 7 8 9 10 11 12 b c

  22. 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

  23. Parse PSL Assertion Exampleassert always ({a ; d}) @ (rose(clk)); Parsing ToolsP-L-Y (Python Lex-Yacc) Graphviz • Rewrite RulesThere are 39 total rewrite rules, which reduce the formulas to a small number of "base cases" to implement in automata format

  24. Construct and Combine Automata {a ; b} | {c ; d} c ; d a ; b ; d ; c b a

  25. 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 q1 q0 always @ (posedge clk) begin q1 <= q0 && a; q2 <= (q1 && c) || (q0 && b); end c hold q2 b

  26. Tool Comparison [Boule08, Fin07]

  27. Demonstration

  28. 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

  29. 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

  30. 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.

  31. 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

  32. 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 MatchingFailure CheckerModules

  33. 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 [Hicks10, Jin08, Zhang11]

  34. Analysis

  35. 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.

  36. 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

  37. 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)

  38. Lifecycle Coverage Comparison [Hicks10, Banga10, Bilzor10a]

  39. 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 Convert Automaton to HDL Checker Convert Base Case Formulato Automaton Rewrite Rules

  40. 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: PotentialExponentialIncrease

  41. 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

  42. Summary

  43. 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

  44. 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

  45. 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

  46. Defining and EnforcingHardware Security Requirements9 Sep 2011 CDR Mike Bilzor mbilzor@nps.edu

  47. 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] 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. • [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.

  48. 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.

More Related