680 likes | 700 Views
Delve into the comprehensive overview of IAIK, a leader in secure VLSI design. Explore their research on cryptography, e-government, and formal methods for design and verification, led by renowned experts. Understand their innovative work in property synthesis and EU projects COCONUT and DIAMOND.
E N D
Aspects of Property Synthesis An Overview of IAIK’s Background and Current Work on the Topic
Overview • Who We Are & What We Do • Property Synthesis in a Nutshell • From Strategies to Circuits • Synthesis with Uninterpreted Functions • Other Work in Our Group
TUG – Who We Are Graz University of Technology. Departments: Architecture Civil Engineering Mechanical Engineering and Economic Sciences Electrical and Information Engineering Technical Mathematics and Technical Physics Technical Chemistry, Chemical Process Engineering, Biotechnology Department of Computer Science. Institutes: Information Systems and Computer Media Knowledge Management Foundations of Computer Science Semantic Data Amalysis / Knowledge Discovery Visual Computing Computer Graphics and Knowledge Visualization Software Technology Applied Information Processing and Communications (IAIK)
IAIK – Who We Are IT Security & Correctness ~60 researchers 3 professors: Roderick Bloem ReinhardPosch Vincent Rijmen Affiliates: SIC – Foundation Secure Information and Communication, founded by IAIK A-SIT – Center for Secure Information Technology
What We Do Secure & Correct Systens Secure & Correct Systens Secure & Correct Systens VLSI e-government VLSI e-government Cryptography Cryptography
Cryptography Secure & Correct Systens Secure & Correct Systens Lead: Prof Vincent Rijmen • Design and Analysis of Ciphers (AES) • Design and Analysis of Hash Functions • Grøstl submitted to the NIST SHA-3 competition • SHA-1 Analysis • Implementation of Cryptographic primitives VLSI e-government VLSI e-government Cryptography Cryptography Cryptography
VLSI Secure & Correct Systens Secure & Correct Systens Lead: Manfred Aigner • Application-specific crypto hardware • RFID • Hardware Implementation of Cryptographic Algorithms (“AES on a Grain of Sand”) • Implementation Attacks (sidechannel, fault injection, etc): • Vulnerability Analysis • Design Styles & Methodologies for Attack Resistance • Security Protocols for RFID • Instruction Set Extensions (embedded systems) VLSI e-government VLSI VLSI e-government Cryptography Cryptography
e-Government Secure & Correct Systens Secure & Correct Systens Lead: Herbert Leitold • Austrian citizen card • Electronic identity • Electronic signature • Official signature (Amtssignatur) • Interoperability of e-identities (STORK) • Electronic delivery (legally binding) • Authenticated work flows • Modules for Online Applications (MOA) VLSI e-government e-government VLSI e-government Cryptography Cryptography
Secure & CorrectSystems (SCoS) Secure & Correct Systens Secure & Correct Systens Secure & Correct Systens Lead: Roderick Bloem • Java Crypto Toolkit (commercial) • Implementation of Java Crypto Extensions, CCE-certified • Ciphers, hash functions, signature schemes, key management • Current focus: XML-Security (W3C), XAdES (also interoperability testing (ETSI)), ECC, CAdES • Formal Methods • Verification and Debugging • Correct by Construction • Network Security • Trusted Computing VLSI e-government VLSI e-government Cryptography Cryptography
Formal Methods for Design & Verification • Roderick Bloem • Lead • Karin Greimel • Theory of Property Synthesis • Georg Hofferek • Practical Aspects of Property Synthesis • Robert Könighofer • Spec Debugging & Program Repair
EU Project COCONUT (2008-2010) Synthesizing circuits from specs • No more coding! • Efficient synthesis • Effective specifications • Robustness • Spec debugging • Transaction-level synthesis • Applications to debugging Design Intent Specification Implementation Synthesis Check
EU Project DIAMOND (2010-2012) • Automated location and correction techniques • Transaction Level (“Software” Model) • Implementation Level (RT or Gate Level) • Implementation of a reasoning framework • word-level techniques • formal, semi-formal techniques • dynamic techniques
Synthesis Flow Write down Properties of System (in formal way) Find Winning Strategy (if one exists) Build Combinational Functions adhering to Strategy
Open (Reactive) Systems • Infinite Sequence of Inputs • Infinite Sequence of Outputs • Examples: • Bus Arbiter • Lift Controller • Traffic Lights • … System Outputs Inputs
Mealy Machine System Combinational Logic Inputs State (Memory/Flipflops) Outputs
Properties • A property describes a subset of all possible input/output traces of a system • “The traffic lights will show green infinitely many times for all directions.” • “The signals ack1andack2 will never be high at the same time.” • “Whenever the button is pushed, the lift will eventually arrive at the respective floor.” • Can be formalized in different ways • LTL Formulas • Büchi Automata • … • “What to do” vs. “How to do it”
The Game Point of View • 2 Players • Environment (Inputs) • System (Outputs) • State • Memory • “Rules” and Winning Condition • Defined by Properties
Example: Tic Tac Toe • Goal (for Player 2):Make three O in a line, or prevent Player 1 from having three X in a line. X X O O X O X O X
Strategy • Maps a state of the game to a set of conforming moves X X X X X X X O O O O O O O O O O O O O X X X X X X X
Winning Strategies • Player wins, if she adheres to strategy • Computed using Game Graph • Example: Tic Tac Toe • Win: If you have two in a row, play the third to get three in a row. • Block: If the opponent has two in a row, play the third to block them. • Fork: Create an opportunity where you can win in two ways. ... … • Empty Side: Play an empty side. http://en.wikipedia.org/wiki/Tic-tac-toe
Strategies Represented as Relations Combinational Logic • Relation • Represented Symbolically (BDDs) • More Freedom than Functions System Combinational Logic State (Memory/Flipflops) All Inputsto CombinationalLogic All Outputsof CombinationalLogic
Freedom in Relations Fixed Output, No Freedom “Don’t Care”: 1 0 – = 1 0 0, 1 0 1 Multiple Vertices, Not Expressible with Don’t Cares.
Solving Relations • Problem:Given a Boolean relation, find a compatible (multi-output) Boolean function, which is minimal with respect to some cost function (e.g. gate count). • Our Relations are large many compatible functions • Use freedom in a meaningful way • Share common sub-functions
Simple Cofactor Approach For each output do: • Abstract other outputs • Find cofactors w.r.t. output • Remove redundant variables (*) • Compute care-set • Minimize positive cofactor w.r.t. care-set • Substitute output in relation with computed function f p n [R. Bloem et al., “Specify, Compile, Run: Hardware from PSL“, COCV’07]
Resubstitution Loss of freedom for o2 and o3 1 1 1 1
Circuit Construction • Strategy and compatible functions are represented as Binary Decision Diagrams (BDDs) • BDDs can easily be dumped into a network of multiplexers
Overview • DAC’04 Recursive Conflict-Solving Approach [Baneres et al.] • Other Minimization Methods • Minato-Morreale’sIrredundant Sum-of-Products Algorithm • Generalized Version of ISoP • Caching to Increase Sharing of Sub-Functions • Combining the Above
DAC’04 Recursive Approach • Based on:D. Baneres et al., “A Recursive Paradigm to Solve Boolean Relations”, DAC’04 • Basic Idea: • Resubstituting outputs takes away freedom • Freedom decreases with each output bad for minimization • Minimize outputs independently, resolve conflicts (if any) recursively • Branch & Bound Algorithm, with arbitrary cost function
Independent Output Minimization Input: Relation R, inputs I, outputs O F = 1 foreach o in O do: R’ = exists O\o . R F = F * (o <-> Minimize(R,o)) // no resubstitution C = F * not(R) // check for conflicts if C != 0: (X, y) = pickConflict(C) (R1, R2) = Split(R, X, y) // divide & conquer Recursively solve R1, R2 • 0 1 • 1 0 • 0 • 0
Our Results with the DAC’04 Approach • Complete Search Infeasible • Depth-First Search (Recursion Limit) • Breadth-First Search (Call Limit) • Quick Solution (Cofactor Approach)after using up resources • No significant improvements over initial solution (so far) • Maybe bad choice of conflicts • Use Minato-Morreale algorithm instead of cofactor approach (not implemented in our tool yet)
Incompletely Specified Functions Don’t-Care-Set ON-Set OFF-Set ON-Set of Completely Specified Function
Lattice of Functions f1 > f2 Upper Bound (ON-Set + DC-Set) f15 f1 f2 f11 f12 f13 f14 f1 , f2 incomparable f5 f6 f7 f8 f9 f10 f2 f1 Interval f1 f2 f3 f4 = ON-Set of function f1 = ON-Set of function f2 f0 Lower Bound (ON-Set)
Minato-Morreale Algorithm • Irredundant Sum-of-Products:No single literal or cube can be deleted to keep the function. • Recursive Procedure:ISoP = v’ * ISoP0 + v * ISoP1 + ISoPd • Starts with Incompletely Specified Function [S. Minato, “Fast generation of irredundant sum-of-products forms from binary decision diagrams“, SASIMI’92]
Minato-Morreale Algorithm (2) • Given: Incompletely Specified Function (ON, DC) • In each step:Find literal v and ISFs for ISoP0, ISoP1, ISoPd, such that ISoP = v’ * ISoP0 + v * ISoP1 + ISoPdlies in the intervall[ON, ON+DC]. • Recur on ISoP0, ISoP1, ISoPd
Finding ISoP0 Given: Upper and Lower Bound of ISoP: Cofactors of Upper Bound: Cofactor of Lower Bound: Uv’ Uv U Lv’ L Minimum set which must be multiplied by v’: Interval for ISoP0: Uv Uv’ ISoP0 Lv’ Lv’ – Uv All diagrams show ON-Sets only!
Finding ISoP1, ISoPd • ISoP1: similar to ISoP0, with opposite cofactors • ISoPd: Lower Bound for ISoPd: U ISoP0 Upper Bound for ISoPd: ISoP1 L ISoPd Uv’ Uv Interval for ISoPd:
Terminal Cases of Recursion • L = 0 • U = 1 • L = U f15 f11 f12 f13 f14 f5 f6 f7 f8 f9 f10 f1 f2 f3 f4 f0
Circuit Construction Along the Way ISoP = v’ * ISoP0 + v * ISoP1 + ISoPd v AND ISoP0 OR ISoP AND ISoP1 ISoPd
Generalization of ISoP-Algorithm • ISoP splits off one literal v at a time: ISoP = v’ * ISoP0 + v * ISoP1 + ISoPd • Instead:Split off arbitrary (simple) function f ISoP = f’ * ISoP0 + f * ISoP1 + ISoPd • How to choose good divisors (for intervals)? • E.g. Kernels, Co-Kernels, … of lower bound? • Preliminary results are not promising
Caching Intermediate Results • Given interval [L, U], check whether a function f: L ≤ f ≤ U has already been “built”. Reuse Wire f15 f11 f12 f13 f14 v AND ISoP0 OR ISoP f5 f6 f7 f8 f9 f10 AND ISoP1 f1 f2 f3 f4 ISoPd f0
Cache Issues • Memory Constraints • Cannot save all intermediate results • Cache Policy: Which ones to delete? • “Smaller” functions have higher reuse probability? • Efficient Cache Lookup • 2 comparisons needed to check whether function is in an interval • Minimize function comparisons • How can this be done?
Simulation-Based Lookup • Don’t Store Functions, Use “Signatures” • Random Input Vectors Corresponding Outputs • Compact in Memory • Quick Comparison (Bit-Vectors) • Candidate function must have • at least as many 1s as the lower bound of interval • not more 1s than the upper bound of interval • Discard candidate function on first violation of above property • False Positives • Reconstruct Functions on Demand cf. [A. Mishchenko, “FRAIGs: A unifying representation for logic synthesis and verification”, Tech Report, 2005]
What is an Uninterpreted Function? • A function…(obviously) • Possibly n-ary • Mapping input value(s) to output value • ... which is uninterpreted. • i.e., we do not know/care about its “internals” • But: functional consistency • for n-ary function: f f(a) a
What is a controller? inputs • ControllerversusDatapathare like: • Driverversus Car • MusicianversusPiano • … • Datapath • includes: • memory • arithmetic components • adders • multipliers • … • other data manipulating stuff Controller control signals status signals outputs
Motivation: Pipelined Microprocessor Registers / Memory c1 c2 cn Controller