CIS 6614 meeting -*- Outline -*- * Alloy Analysis Tool Goal is to explain how a formal methods tool can help find bugs in difficult situations, like the logical problems in cashier as a service ** What is the Alloy Analysis Tool ------------------------------------------ WHAT IS ALLOY? Tool for: - domain modeling - abstractly investigating designs - systematic testing, within a size limit ------------------------------------------ for investigating designs can: ... - specify properties - check that design has them - visualize examples - look for counterexamples ** Ideas behind Alloy ------------------------------------------ APPROACH USED BY ALLOY - Everything is a relation (or an atom) - General logic - Check specified properties using bounded search for counterexamples - Technique used is SAT solving ------------------------------------------ Q: Isn't SAT exponential? Yes, in the general case, but there are pretty efficient techniques, so can investigate on a small scale ------------------------------------------ SMALL SCOPE HYPOTHESIS "Most flaws in models can be illustrated by small instances" - Daniel Jackson ------------------------------------------ Quote from p. 15 of Software Abstractions by Daniel Jackson ... Based on experience Flaws arise from "shapes being handled incorrectly" (so size makes no difference) But this isn't strictly speaking valid ** Semantics of Alloy *** Atoms ------------------------------------------ ATOMS Atoms are: - just names, i.e. modeling abstractions ------------------------------------------ ... - indivisible (have no smaller parts) - immutable (have no properties that change over time) - uninterpreted (have no built in properties) *** All values are relations because in Alloy, atoms are never values, only relations are! ------------------------------------------ ALL VALUES ARE RELATIONS Universe is n-ary relations Relations model: - all data types including: - sets - scalars - tuples -- structures in space and time N-ary Relations are: sets of n-tuples (of atoms) No distction between: - a scalar - a singleton set - a unary tuple - a relation Columns identified by position (not names) Example: Binary relation from names to addresses module relationBasics sig Name, Addr {} one sig Book { addr: Name -> lone Addr } pred show(){} run show ------------------------------------------ ... sets are unary relations ... scalars are unary relations with 1 element (i.e., math: a set with 1 tuple of 1 element) ... tuples formed as products of scalars, using -> e.g., n0->a0 (math: as a set containing 1 tuple) ... a, {a}, (a), vs. {(a)} Try the example, with Alloy, from the file relationBasics.als and use the visualizer and "Show new solution", from the Instance menu, to see more Note that sig declares a signature, i.e., the name of a set ... example relation, where n0,n1 are atoms (of type Name), a0, a1 are atoms (of type Addr): book = {(n0,a0),(n1,a1)} in math. notation book = { n0->a0 in book, n1->a1 in book } in Alloy notation (In this example, there can be more names that aren't mapped to addresses, but not names that map to more than one address Note that the different names can be mapped to the same address) **** views of relations ------------------------------------------ VIEWS OF RELATIONS Can think in these styles: - predicate calculus: all n:Name, a1, a2: Addr | n->a1 in Book.addr and n->a2 in Book.addr implies (a1 = a2) - navigational: all n: Name | lone Book.addr[n] - relational: all n: Name | lone n.Book.addr ------------------------------------------ these are in the file relationStyles.als note that Book.addr[n] is parsed as (Book.addr)[n] for the navigational style one can also write: lone n.(Book.addr) since that is equivalent to Book.addr[n] similarly for the relational style one can write: lone Book.addr[n] **** relational join ------------------------------------------ RELATIONS AND DOT JOIN (.) Key operator is dot (.) where s.t (or t[s]) is the join of the last column of s with the first column of t If (s1->s2->...->sN-1->sN) in s and (t1->t2->...->tM) in t then (s1->s2->...sN-1->t2->...tM) in s.t iff sN = t1 used for: - relational join - field navigation - function composition - function application ------------------------------------------ Q: How is the join of binary relations defined? ------------------------------------------ SPECIAL CASES OF JOIN For binary relations, as in set theory: (a,c) in (R . S) <==> exists b :: (a,b) in R and (b,c) in S. When F is functional, A is unary: A.F = F[A] = {(b)| (a,b) in F, a in A } ------------------------------------------ ------------------------------------------ JOIN IN ALLOY module joining sig S, T{} assert basicJoinProperty { all s1:univ, s2: univ, t1: univ, t2: univ | let sTuple = s1 -> s2 { let tTuple = t1 -> t2 { (s1-> t2) = sTuple.tTuple iff (s2 = t1) // note: // sTuple.tTuple = tTuple[sTuple] } } } check basicJoinProperty ------------------------------------------ Checking this takes a about 4 seconds (the first time) (faster the next time, due to JVM optimizations) (on an Intel i7-1065G7 CPU @ 1.3GHz with 16 GB RAM) Q: What happened to s2 and t1? they are omitted from the answer ------------------------------------------ WHY USE RELATIONS? Easy to understand: - Relations directly model: graphs, functions - Relations are first order, so tractable to analyze - Uniform syntax ------------------------------------------ *** General logic ------------------------------------------ NO SPECIALIZED LOGIC No special cases in logic for: - state machines, - traces, - synchronization, - concurrency, - etc. ------------------------------------------ *** Analysis via bounded search for counterexamples ------------------------------------------ ANALYSIS VIA BOUNDED SEARCH Experience shows that: - most assertions are wrong - most counterexamples are small So analyzer tests: - completely within a small bound ------------------------------------------ Q: What do we mean by testing completeley within a small bound? If there is a counterexample of a given size or smaller, then the analysis will find it. In essence, the analyzer is searching for counterexamples (bugs) in small scopes. ** extended example ------------------------------------------ MODELING THE E-COMMERCE PAPER'S ATTACKS Want to formally model attacks in: Rui Wang, Shuo Chen, XiaoFeng Wang, and Shaz Qadeer. How to Shop for Free Online -- Security Analysis of Cashier-as-a-Service Based Web Stores. In IEEE Symposium on Security and Privacy, 2011, pp. 465-480. doi: 10.1109/SP.2011.26 ------------------------------------------ *** domain modeling ------------------------------------------ DOMAIN MODELING module logicalProblems open util/ordering[Time] as TO open util/ordering[State] as SO sig Time {} sig Value {} sig OnlineEntity {} sig TStore, CaaS, Attacker extends OnlineEntity {} sig Message { sender, receiver: OnlineEntity, val: Value }{ sender != receiver } sig Signed extends Message { signedBy: OnlineEntity } sig State { sent: Message -> Time } // initial state of the system pred init [t: Time] { State.sent.t = none } pred step[t: Time, pre: State, m: Message, post: State, t2: Time] { lt[t,t2] => (pre.sent.t + m) = post.sent.t2 } fact traces { init [first] all t: Time-last | let t2 = t.next | all m: Message | all s,s2: State | s2 in s.next and m in s.sent.t => step [t, s, m, s2, t2] } pred show() {} run show ------------------------------------------ Describe this including: - modules - test it out with pred show() {} run show for 5 // note bound *** modeling an attack We'll start with the first, simplest attack, from fig 4 of the paper ------------------------------------------ MODELING AN ATTACK Want traces to show the attack, then look to see if there is a trace where security property violated Steps: - Model domains involved: - Online Entities modeled as Sigs - Attacker, - TStore, - CaaS - Messages fields: - sender, receiver, value - signed messages (a subtype) - identity of the signer - extract properties with functions e.g., originator of value - States - sequence of messages sent ------------------------------------------ Q: What do signatures correspond to? sets, possibly with named fields classes in OOP ------------------------------------------ ATTACK AS FACT ABOUT STATES module eCommerceFig4Better open logicalProblems as LP fact { all t0: LP/Time | init[t0] and let t1a = t0.next | let t1b = t1a.next | let t2a = t1b.next | let t2b = t2a.next | let t3a = t2b.next | let t3aa = t3a.next | let t3ab = t3aa.next | let t3b = t3ab.next | all s0: LP/State | let s1a = s0.next | let s1b = s1a.next | let s2a = s1b.next | let s2b = s2a.next | let s3a = s2b.next | let s3aa = s3a.next | let s3ab = s3aa.next | let s3b = s3ab.next | all m1a,m1b,m2a,m2b,m3a,m3aa,m3ab,m3b: Message | m1a.sender = LP/Attacker and m1a.receiver = LP/TStore and m1b.sender = LP/TStore and m1b.receiver = LP/Attacker and m2a.sender = LP/Attacker and m2a.receiver = LP/CaaS and m3a.sender = LP/Attacker and m3a.receiver = LP/TStore and m3aa.sender = LP/TStore and m3aa.receiver = LP/CaaS and m3ab.sender = LP/CaaS and m3ab.receiver = LP/TStore and m3b.sender = LP/TStore and m3b.receiver = LP/Attacker and step[t0,s0,m1a,s1a,t1a] and step[t1a, s1a, m1b, s1b, t1b] and step[t1b,s1b,m2a,s2a,t2a] and step[t2a, s2a, m2b, s2b, t2b] and step[t2b,s2b,m3a,s3a,t3a] and step[t3a, s3a, m3aa, s3aa, t3aa] and step[t3aa,s3aa,m3ab,s3ab,t3ab] and step[t3ab, s3ab, m3b, s3b, t3b] => s1a.sent.t1a = m1a and s1b.sent.t1b = m1a+m1b and s2a.sent.t2a = m1a+m1b+m2a and s2b.sent.t2b = m1a+m1b+m2a+m2b and s2b.sent.t2b = m1a+m1b+m2a+m2b+m3a and s3a.sent.t3a = m1a+m1b+m2a+m2b+m3a+m3aa and s3aa.sent.t3aa = m1a+m1b+m2a+m2b+m3a+m3aa+m3ab and s3ab.sent.t3ab = m1a+m1b+m2a+m2b+m3a+m3aa+m3ab+m3b } pred show{} run show for 10 Time, 8 LP/Value, 3 LP/OnlineEntity, 8 LP/Message, 6 LP/State ------------------------------------------ Explain the bounds and try some out... *** formulating security properties Q: What security policies should be enforced? need to model who controls what How to know when paying? Try to formulate and check those in Alloy Analyzer