CIS 4615 meeting -*- Outline -*- * Overview of UMLSec These notes are based on the book: J. Jurgens, Secure Systems Development with UML, Springer, 2005, mostly chapter 3. ------------------------------------------ UMLSec Overview Extension to Unified Modeling Language (UML) for specification of security in detailed designs Focuses on: - network security for systems - uses of cryptography Features: - Can specify some aspects of physical security - Tool support www-secse.cs.tu-dortmund.de/carisma/ Website: www-secse.cs.tu-dortmund.de/secse/pages/ research/UMLsec/index_en.shtml Book: Jan Jurjens. Secure Systems Development with UML. Springer-Verlag, Berlin, 2005. www.springer.com/us/book/9783540007012 ------------------------------------------ ... the book can be read from the link when at UCF or on the VPN ** Problems Addressed ------------------------------------------ WHY SYSTEM/PROTOCOL DESIGN? Need an overview of the detailed design - check against requirements - see how components compose Deadly Sin #21: - Using Cryptography Incorrectly esp. creating your own protocol Shamir (1999): strong crypto doesn't matter, if it is used incorrectly or if the system has other weaknesses However: ------------------------------------------ ... novel system designs may require novel protocols! so it's helpful to have tool support to get it right Q: Why not just build a system and try penetration testing? The assets may be gone by the time you can patch it, it's much more expensive (about 200 x more expensive). ** approach ------------------------------------------ GOALS AND APPROACH Goal: tool for - formal specification and - automated verification of detailed designs at component level Approach: - model both the system and - model makes various assumptions such as: - encrypted data cannot be decrypted - certain links are secure - what an attacker can do - specify security properties at a high level with UML stereotypes e.g., <>, > - specify constraints (in OCL) - can generate code or tests from model ------------------------------------------ Q: Can one do verification based on informal design documents? No. Q: Why specify detailed designs? early in the software cycle, allows splitting of work among components Formal treatment also allows for refinement to be used & verified. ... the attacker e.g., the attacker can read, delete, or modify certain things Why model the attacker? To completely understand the problem i.e., to avoid implicit assumptions To specify what attacks are being defended against To be able to do (formal) proofs or (informal) arguments ** elements of UMLSec *** stereotypes ------------------------------------------ STEREOTYPES Drawn from a list (p. 51) Label parts of UML diagrams Add security-specific information: - assumptions about physical system <>, <>, <> - security requirements about structure <> or about data values <> - security policies <>, <> ------------------------------------------ The security policies are shorthands for constraints that the diagram must fulfill *** physical security using deployment diagrams ------------------------------------------ DEPLOYMENT DIAGRAMS FOR CONTEXT AND PHYSICAL SECURITY Goal: describe how system parts fit together for operation and maintenance Shows: processing nodes (boxes) and components that run on them, and connections Nodes are shown as "perspective cubes" with software deployed inside them ------------------------------------------ Q: What are these like? Network models, from our threat modeling experience ... |------------------------------------------------------------| <> {adversary=default} /--------------------/ |---------------| /--------------------/| | :Router | | :Customer || | | |<> || | Distrib.jar | | {adversary=default}|| < /->| | | |-----------| || /-------/ | | | | Browser | ||---/ <> | | | |-----------| |/ |---------------| |--------------------/ ^ / <> V /------------------------------------------------/+ /------------------------------------------------/ | | :ServerFarm <> | | | +-------------+ +--------------+ | | | | :Server0 | | :Server(N-1) | | | | | | | | | | | | Reserve.jar | ... | Reserve.jar | | | | | | | | | | | +-------------+ +--------------+ | / | |/ +------------------------------------------------/ | | <> | <> /-----v-------/| / / | |-------------| | | :Database | | |<>|/ +-------------/ |------------------------------------------------------------| *** cryptographic techniques **** symmetric and asymmetric cryptography Q: Is this review from CIS 3360? ------------------------------------------ SYMMETRIC CRYPTOGRAPHY Uses a single secret key both to encrypt and decrypt messages Advantages: + can be fast Disadvantages: - both parties must know the key Examples: AES ------------------------------------------ ------------------------------------------ PUBLIC KEY CRYPTOGRAPHY Based on hard to compute problems: - integer factorization - etc. Uses 2 keys, each can be used to Keys play different roles: public key (K): -1 private key (K ): ------------------------------------------ ... both encrypt and decrypt ... K: encrpyts messages verifies signatures can be given to everyone ... K^-1: decrypts messages creates signatures must be secret! Q: How can we use this to send messages securely? Encrypt with the receiver's public key. Q: How does signing work? Compute a hash of the message, called a "digest" then encrypt the hash with sender's private key, verification involves computing the digest (hashing) and decrypting the signature with the sender's public key then comparing the two digests. Or the message itself can be used as the digest. **** notations ------------------------------------------ Cryptographic Expressions from: R. Needham and M. Schroeder. "Using encryption for authentication in large networks of computers." CACM 21(12):993-999, Dec. 1978. Notation: K is a cryptographic key K is a I -1 K is a I {M} is message M K Ext (X) is K Sign (M) is message M K M1::M2 is message M1 ------------------------------------------ ... public key for I (I is name of an instance) ... private key for I ... encrypted with K ... the encrypted expression X extracted using key K ... signed with K ... concatenated with M2 *** statechart diagrams ------------------------------------------ STATECHART DIAGRAMS for state-based control of objects or components Rounded rectanges represent Arrows represent labeled with event[guard]/action events are operation calls or returns guards are boolean expressions actions may be call() or send() solid circle representing circle with solid circle inside representing ------------------------------------------ ... states ... transitions ... starting state ... final state the guard must be true for the transition to take place ------------------------------------------ EXAMPLE STATECHART DIAGRAM For the router: ------------------------------------------ ... (-----------------------) o --> ( entry/ i:=(i+1) mod N ) --| ( Routing ) | (-----------------------) | ^ book(m) / \--------------/ /xmit(m) *** sequence diagrams ------------------------------------------ SEQUENCE DIAGRAMS Boxes representing Vertical thin boxes repesent Arrows repesent Example: ------------------------------------------ ... instances (processes or threads) ... computation (time goes down the page) thick where instance is active ... messages (calls, sends) from one component (at tail) to another (at head) +----------+ +-----------+ +------------+ | C:Client | | R: Router | |S_i: Server | +----------+ +-----------+ +------------+ ++ ++ ++ || || || ||book({N_j}_K_R,K_C,Sign_KC^-1(C,K_C))|| ||------------>|| || || ||xmit(N'',K_C,Sign_KC^-1(C,K_C)) || ||--------------->|| || || || || return({Sign_{K_S_i}^-1(k_j::N')}_K', [snd(Ext_K'(cc)) = K'] || Sign_{K_CA}^-1(S_i::K_S_i)) ||<------------------------------|| || || || ++ ++ ++ N'' ::= Ext_K_R^{-1}(book_1) N' ::= xmit_1 K' ::= xmit_2 cc ::= xmit_3 **** activity diagrams like Petri nets ------------------------------------------ ACTIVITY DIAGRAMS Special cases of statecharts that specify Example ------------------------------------------ ... concurrency/parallelism o | v ========= / | \ / | \ (c)|(r)|(s_i) where there are statecharts for c:client, r:router, s_i:server ** UML Machine semantics ------------------------------------------ EXECUTION MODEL Components communicate by links, from the deployment diagram. Components modeled by functions that follow the specification, each has an input queue of messages and an output queue of messages, both of which are connected to links Links modeled by queues of messages Behavior of specification S, [[S]] 0. Deliver some messages in link queues to input queues. 1. Select some messages in input queues, of components C_i, these are the input events for the C_i. 2. Have the selected components, C_i, each process the input events as each C_i has specified 3. Place any outputs on the corresponding link queues 4. Adversary can delete/modify/insert messages in link queues, according to its capabilities. ------------------------------------------ This is a simulation of the system at an abstract level It assumes that the components satisfy their specificaions ------------------------------------------ BEHAVIOR AND REFINEMENT def: A UML machine is a UML specification def: A *behavior of a UML machine* is Can there be several possible behaviors? When does a machine, T, refine a given S? def: T is a delayed refinement of S if ------------------------------------------ ... a sequence of states and associated inputs and outputs (link queues) ... Yes, it is nondeterministic, in general. So the meaning of a UML specification is the set of all its behaviors. ... When all the behaviors of T are behaviors of S. no extra behaviors, but can have fewer (be more deterministic) Q: Why can't T have more behaviors? these might violate security properties Q: Why can T have fewer behaviors? Can be more deterministic, stricter security ... T is a refinement of S as long as some internal actions are removed. So a delayed refinement can be slower (exchange more messsages). Q: Why do we care about refinement? ** modeling adversaries ------------------------------------------ MODELING ADVERSARIES In general, can give a UML specification for some specific behavior. Normally based on abstract threats: which are actions on messages (in links) and which is an action on a node. State of an adversary is its knowledge, K A ------------------------------------------ ... delete, read, insert, ... access "access" allows the attacker to delete, read, or insert messages on a node's queues and on the link queues connected to it. (note network focus) ------------------------------------------ MOST GENERAL ADVERSARY MACHINE An adversary of the given type that has the most nondeterminism ------------------------------------------ Q: Why is the most nondeterminism intersting? most possible ways to affect security Q: Why is that such an adversary intersting? if the system is secure against it, then it is secure against a refinement of the adversary ** stereotypical security properties *** secrecy ------------------------------------------ <> A system S preserves the secrecy of data d against an adversary of type A if Example: S preserves secrecy of a message m if it only sends out {m} K and keeps K secret. ------------------------------------------ ... during execution of S with an adversary of type A that has no prior knowledge of d, the adversary cannot come to know d. This definition doesn't prevent implicit information flows Q: What about a system S that receives a session key K encrypted with S's public key, and then sends {m} encrypted with K? No, if the adversary can insert messages, since the key K could have come from the adversary. Yes, if the adversary cannot insert messages. *** integrity ------------------------------------------ <> def: Let E be a set of acceptable values for a variable v. Then a system S *preserves the integrity of v* if ------------------------------------------ ... the value of v is always undefined or a value in E. This just means that the attacker cannot alter v. The "variable" can be any attribute. One can take E to be the set of values minus the adversary's initial knowledge. *** authenticity ------------------------------------------ <> Idea: track the origin of all data = component which first produced it def: A system S *preserves authenticity of v* if the origin of v's value is ------------------------------------------ ... always the component that first produced it. A more precise definition can be given based on the queues in the model. Q: If we have authenticity of messages, do we also have integrity? Yes, because then the attacker never inserts messages Q: When does integrity imply authenticity? When the identity of the sender of the message is part of the message! *** freshness ------------------------------------------ FRESH def: Let D be a subsystem instance or object. Then an atomic value *d is fresh in D* if if d only appears in the overall diagram in D. ------------------------------------------