Model-based Security Engineering: Models vs. Code Jan Jrjens - PowerPoint PPT Presentation

Model-based Security Engineering: Models vs. Code Jan Jürjens Department of Computing The Open University, GB http://www.umlsec.org

Challenge: Security Security is holistic property: • Attackers often circumvent (not: break) mechanisms. • Transform (in)secure components to secure systems ? „Those who think that their problem can be solved by simply applying cryptography don`t understand cryptography and don`t understand their problem“ (B. Lampson / R. Needham). Jan Jürjens, Open University: Model-based Security Engineering 2

Model-based Security Engineering Idea: Extract models Requirements from artefacts in Weave Analyze development and in against use of software. (UML) Models Verify. Gener. Code-/ Reverse Configurations Testgen. Engin. Configure Source Code  Tool-supported, theoretically sound, efficient automated security design & analysis. Jan Jürjens, Open University: Model-based Security Engineering 3

Secure System Lifecycle Security External Static Penetration requirements review analysis testing (tools) Risk-based Abuse Risk Security Risk Security tests cases analysis breaks analysis Requirements Design Test Code Test Field and use cases plans results feedback Model-based Security Engineering [McGraw 2003] Design: Encapsulate prudent security engineering rules. Analysis: Formally based, automated, efficient tools. Note: emphasis on high-level requirements. Jan Jürjens, Open University: Model-based Security Engineering 4

Model-based Security with UMLsec Extension of the Unified Modeling Language (UML) for secure systems development. • evaluate UML models for security • encapsulate established rules of prudent secure engineering • make available to developers not specialized in secure systems • consider security requirements from early design phases, in system context • can use in certification Jan Jürjens, Open University: Model-based Security Engineering 5

UMLsec Insert recurring security requirements, adversary scenarios, security mecha- nisms as predefined markers. Use associated logical constraints to verify specifications using model checkers and ATPs based on formal semantics. Ensures that UML specification enforces the relevant security requirements wrt Dolev-Yao type adversaries. [FASE01,UML02,FOSAD05,ICSE05] Jan Jürjens, Open University: Model-based Security Engineering 6

Example: Crypto-based Distributed System A B Adversary m(x) m(x) [arg b,1,1 = x] return({z} k ) return({y::x} z ) Attacker may … • control system parts, Adversary k -1 , y, x • know data in advance, {z} k, z knowledge: • intercept messages, (cf. [Dolev, Yao 1982]) • delete messages, • inject messages. Jan Jürjens, Open University: Model-based Security Engineering 7

Security Analysis in First-order Logic Approximate adversary knowledge set from above: Predicate knows(E) meaning that adversary may get to know E during the execution of the system. E.g. secrecy requirement: For any secret s , check whether can derive knows(s) from model-generated formulas using automatic theorem prover. [ICSE05] Jan Jürjens, Open University: Model-based Security Engineering 8

Cryptographic Expressions I Exp : quotient of term algebra generated from sets Data , Keys , Var of symbols using • _::_ (concatenation), head(_) , tail(_) • (_) -1 (inverse keys) • { _ }_ (encryption) • Dec_( ) (decryption) • Sign_( ) (signing) • Ext_( ) (extracting from signature) under equations … Jan Jürjens, Open University: Model-based Security Engineering 9

Cryptographic Expressions II ∀∀ E,K. Dec K -1 ({E} K )=E ∀∀ E,K. Ext K (Sign K -1 (E))=E ∀∀ E 1 ,E 2 . head(E 1 ::E 2 )=E 1 ∀∀ E 1 ,E 2 . tail(E 1 ::E 2 )=E 2 • Associativity for :: . Write E 1 ::E 2 ::E 3 for E 1 ::(E 2 ::E 3 ) and fst(E 1 ::E 2 ) for head(E 1 ::E 2 ) etc. Can include further crypto-specific primitives and laws (XOR, …). Jan Jürjens, Open University: Model-based Security Engineering 10

Example: Translation to Logic knows ( N ) ∧ knows ( K C ) ∧ knows ( Sign K C -1 (C::K C ) ) ∧ ∀ init 1 ,init 2 ,init 3 . [ knows ( init 1 ) ∧ knows ( init 2 ) ∧ knows ( init 3 ) ∧ snd ( Ext init 2 (init 3 ) ) = init 2 ) knows ( {Sign K S -1 (…)} … ) ∧ [ knows ( Sign… )] ∧ ∀ resp 1 ,resp 2 . [ … ) ... ] ] Jan Jürjens, Open University: Model-based Security Engineering 11

Analysis Check whether can derive knows(s) e.g. using e-Setheo. Surprise: Yes !  Protocol does not preserve secrecy of s . Why ? Use Prolog- based attack generator. Jan Jürjens, Open University: Model-based Security Engineering 12

Man-in-the-Middle Attack Jan Jürjens, Open University: Model-based Security Engineering 13

The Fix e-Setheo: Proof that knows(s) not derivable. Note completeness of FOL (but also undecidability). Jan Jürjens, Open University: Model-based Security Engineering 14

Security Analysis: Model or Code ? Model: + earlier (less expensive to fix flaws) + more abstract  more efficient - more abstract  may miss attacks - programmers may introduce security flaws - even code generators, if not formally verified Code: + „the real thing“ (which is executed)  Do both ! Surprise: Essentially no existing work (eg for crypto prots) ! Jan Jürjens, Open University: Model-based Security Engineering 15

Code Analysis vs. Model Analysis Options: • generate code from models  currently not available in general • generate models from code  next slides • create models and code manually and verify code against models  later in this talk Jan Jürjens, Open University: Model-based Security Engineering 16

Models from Code Generate control flow graph (e.g. aicall (Absint)). Transform to state machine: trans(state,inpattern,condition,action,nextstate) where action can be outpattern or localvar:=value. [ASE05,ASE06] Jan Jürjens, Open University: Model-based Security Engineering 17

Real Life Challenges … Jan Jürjens, Open University: Model-based Security Engineering 18

Experiences Can generate behavioral models from code (e.g. CFGs). Problem: too concrete  understanding + automated verification hard (even with annotations). Constructing abstract specifications from practical software is manually intensive. Jan Jürjens, Open University: Model-based Security Engineering 19

Code Analysis vs. Model Analysis Options: • generate code from models  currently not possible in general • generate models from code  challenging • create models and code manually and verify code against models  next slides Jan Jürjens, Open University: Model-based Security Engineering 20

Verify Code against Models Assumption: Have textual specification. Then: • construct interface spec from textual spec • analyze interface spec for security • verify that software satisfies interface spec Jan Jürjens, Open University: Model-based Security Engineering 21

[with David Model vs. Implementation Kirscheneder ] „meaning“ „meaning“ compare meaning! Defined during Backtrace model creation assignments Sent and received data Elements of connections Find Has Implement Implement -ation Equal? -ation .java Abstract model Jan Jürjens, Open University: Model-based Security Engineering 22

r Example: Interface spec of SSL p q g I) Identify program points: value ( r ), receive ( p ), guard ( g ), send ( q ) II) Check guards enforced Jan Jürjens, Open University: Model-based Security Engineering 23

Implementation of SSL: Identify Values Jan Jürjens, Open University: Model-based Security Engineering 24

public void write(OutputStream out) throws IOException { ... out.write(randomBytes); … } 2nd parameter of Random constructor Identify: randomBytes called by ClientHello.write() (in message ClientHello) public void write(OutputStream out) 2nd parameter of ClientHello constructor throws IOException { ... random.write(out); ... } ClientHello(… , Random random, ) via Handshake.write() { ... this.random = random; ... } initialized in SSLSocket.doClientHandshake() ClientHello clientHello = new ClientHello(..., clientRandom ,...); initialization of the used Random object Random clientRandom = new Random(..., session.random.generateSeed(28) ); „meaning“ class SecureRandom (specified in: FIPS 140-2,RFC 1750) of package java.security Function: generateSeed Jan Jürjens, Open University: Model-based Security Engineering 25

Automate this Sending Messages using patterns ProtocolVersion.write() Random.write() traverse CFG Handshake.write() call of OutputStream. write() ClientHello.write() SSLSocket.doClientHandshake() Jan Jürjens, Open University: Model-based Security Engineering 26

p Checking Guards Guard g enforced by code? q g a) Generate runtime check for g at q from diagram: simple + effective, but performance penalty. b) Testing against checks (symbolic crypto for inequalities). [ICFEM02] c) Automated formal local verification: conditionals between p and q logically imply g (using ATP for FOL). [ASE06] Jan Jürjens, Open University: Model-based Security Engineering 27