Model Checking Techniques for Security Systems UML Sec Tool Framework 7/30/2009

1. Model Checking TechniquesforSecurity SystemsUML Sec Tool Framework7/30/2009 Maha B Abbey PhD Candidate

2. Model-based Security Engineering using UMLsec • Model-based Security Engineering • Approach for developing security critical software • Security requirements • secrecy, integrity, authenticity …. • Security assumptions • UML specification

3. Model-based Security Engineering

4. UMLSec tools framework

5. UMLSec and patterns • UMLsec can be used to specify and implement security patterns • is supported by dedicated secure systems development processes, in particular an Aspect-Oriented Modeling approach which separates complex security mechanisms (which implement the security aspect model) from the core functionality of the system (the primary model) in order to allow a security verification of the particularly security-critical parts, and also of the composed model. • [Jur04]

6. MetaSearch – Case Study • MetaSearch Engine • Simple point of access to search in all relevant information sources with a single query • Personalization capabilities • Storage of sources • Password for restricted sources • Source range • Non confidential such as general company announcements • Confidential documents such as protocols, development specifications … • Each employee has access depending on his/her level of access • Focus on security critical • Login • Store Login Information • functionality of storing the users’ credentials for access to restricted information sources. • Search • searching the selected sources with a specific query

7. Security-critical use cases ofMetasearch

8. Sub System Login • Sequence Diagram – dynamic model describing the functionality of the use case • Class Diagram - static models specifying the interacting entities • Deployment diagram - physical allocation

9. Class Structure of Use Case LOGIN EndUser – Central Class Represents user who wants to login using AuthenticateUser() method Invocation of this method is indicated by the dependency with the stereotype <<call>> Invocation requires secrecy, use of Stereotype <<critical>> with tag value {secrecy = (authenticateUser())} Integrity required for returned session cookie cs, protection indicated by tagged value {Integrity = ( sc )} AuthService – Central authentication server validate user session, authenticate user via interface AuthenticationService

10. Information Flow

11. EndUser – ClientPC AuthService – AuthServer Linked with stereotype <<encrypted>> Logical communication between the components indicated by dependencies stereotyped appropriately Physical Allocation

12. Attacker Model • attacker would have the following capabilities: • Plugging his notebook into the corporate LAN • would have full access to the enterprise’s intranet, • read, insert and delete packets • Access various network nodes …. Stereotype Threatsinsider() encrypted {delete} LAN {delete, read, insert, access}

13. Static Security Analysis • Analysis plug-in • Checks that the security requirements added into the UML diagrams using the stereotypes defined in the UMLsec extension are indeed supported by the design of the system. • Tool Output - secrecy and integrity are satisfied by the given model Name of the dependency: receive session cookie Stereotype of the communication link of the dependency ‘‘receive session cookie’’: encrypted Stereotype of the dependency: integrity => Satisfies the requirement of the stereotype ‘‘secure links’’. Name of the dependency: send login data Stereotype of the communication link of the dependency ‘‘send login data’’: encrypted Stereotype of the dependency: secrecy => Satisfies the requirement of the stereotype ‘‘secure links’’. => UML model satisfies the requirement of the stereotype ‘‘secure links’’. • If the communication link over which the send login data dependency is implemented is not encrypted but a simple Internet link, the tool would return both the information that this violates the secure links security policy with regards to the send login data dependency, and a modification of the submitted UML model where the secure links and send login data stereotypes are highlighted

14. logical connection between clientPC and authServer is based on an SSL-encrypted channel SSL handshake is executed in order to establish a secure connection the client sends his credentials to the authentication server the Client receives a session cookie in return. The authentication protocol is modeled as a UML sequence diagram and analyzed against the security requirements using another one of the analysis plugins in the UMLsec tool Framework, which makes use of the First-Order Logic automatic theorem prover E-SETHEO Security Analysis of the Authentication Protocol

15. C → AS : ClientHello (NC(i)) AS → C : ServerHello (NAS(j)) AS → C : Certificate (KAS) C → AS : ClientKeyExchange {pms}cK %-- Attackers Initial Knowledge --input_formula(previous_knowledge,axiom,(knows(k_as))). %-- Conjecture --input_formula(attack,conjecture,(knows(pms))) C and AS exchange nonces (random value) which are later used to generate shared secrets. AS sends its certificate to C. After C has validated this certificate, it generates a pre-master-secret pms and sends it to AS, enrcrypted with AS’s public key KASextracted from the certificate C and AS possess the shared secret pms. Attacker A cannot extract or manipulate pms by injecting his own data for example. Assuming that A is able to receive KAS, the automated theorem prover reports that the attack conjecture is not derivable from the axioms given the initial knowledge of A, which means that the protocol is secure with respect to the adversary model and the security requirements that were considered here Secrecy of pre-master secret

16. %-- Attackers Initial Knowledge --input_formula(previous_knowledge,axiom,(knows(inv(k_a)) & knows(k_a) & knows(k_as))). %-- Conjecture --input_formula(attack,conjecture,(knows(pms))) Assuming that a realistic adversary would have its own set of cryptographic keys (KA and KA-1) the UMLsec tool reports that the threat conjecture is derivable from the system assumptions, which means that A was able to extract pms. This is possible in the following scenario: When AS and C exchange KAS, A could replace KASwith his own key KA. C encrypts pms with KA, which can then be decrypted by A. the public key of the client has to be protected from manipulation, and this was not captured in the model. In order to model the protocol flow correctly, the entire certificate of AS has to be modeled in the message Certificate Realistic adversary model KA KA C A AS {pms}KA {pms}KA C A AS

17. AS → C : Certificate (Sign KCA-1(KAS:: AS)) C → AS :ClientKeyExchange ({pms}fst(ExtKCA(CK))) C now sends pms only if the following condition holds [snd (ExtKCA (cK)) = AS] %-- Attackers Initial Knowledge --input_formula(previous_knowledge,axiom,(knows(k_ca) & knows(inv(k_a)) & knows(k_a) & knows(k_as))). %-- Conjecture --input_formula(attack,conjecture,(knows(pms) )) to model the certificate correctly, KASis concatenated with AS (the name of AS) and signed by an independent Certificate Authority CA The tool now reports that the threat conjecture cannot be derived from the logical assumptions on the system, which means that no attack of the kind under consideration could be found and that pms is secure regarding this kind of attacks. Based on pms, C and AS can now independently compute a symmetric session key. This session key consists mainly of a hash over the concatenation of a master secret with the before exchanged nonces Model Of Certificate

18. AS → C : ReturnCookie ({cookie}SKAS ) %-- Attackers Initial Knowledge --input_formula(previous_knowledge,axiom,(knows(k_ca)& knows(inv(k_a)) & knows(k_a) & knows(k_as))). %-- Conjecture --input_formula(attack,conjecture,(knows(cookie))) Once AS has validated C’s authentication information, it generates a session cookie cookie and sends it, encrypted with its symmetric session key SKAS, to C the UMLsec tool reports that the attack conjecture can be derived from the system assumptions, which indicates that A was able to read cookie, that is, it is not secure as A knows the public keyKAS of AS, it could catch the message ClientKeyExchange containing pms and send a modified pre master secret pms to AS. AS now computes its symmetric session key based on pms and sends the session cookie cookie encrypted with this session key. As A and AS both compute the same sessionkeys based on pms, A is able to decrypt the messageReturnCookie Secure Exchange of the Session Cookie

19. C → AS : SendAuthData ({uid :: pwd}SKC) %-- Attackers Initial Knowledge --input_formula(previous_knowledge,axiom,(knows(k_ca)& knows(inv(k_a)) & knows(k_a) & knows(k_as))). %-- Conjecture --input_formula(attack,conjecture,(knows(pwd) )) C now sends AS his authentication credentials encrypted with the symmetric session key SKC the tool reports that the attack conjecture is not derivable from the axioms, pwd is secure with respect to the adversary model and the security requirements that were considered Secure Exchange of the User Password

20. Secure Exchange of the User Password • To avoid this situation, it has to be guaranteed that pms cannot be modified by A • the model of the protocol has to guarantee that the message ReturnCookie is only sent from AS to C in case the pre master secret pms was not modified. This is achieved in the SSL specification by two Finished-messages which are exchanged at the end of the SSL handshake and contain a message authentication code (MAC) over all prior exchanged messages • C → AS : ClientFinished (MacSKC(handshake_messages)) • AS → C : ServerFinished (MacSKAS(handshake_messages)) • The exchange of cookie is guarded by the following condition connected to message ReturnCookie: • [DecSKAS (cH) = handshake_messages] • where cH ::= ClientFinished1.

21. Next Step • Jur proving SSL properties • How attack happen in a particular scenario? • Present SSL protocol with other method and comparison (the model checker NuSMV integrated into the execution environment of RSML-e) • Authentication/SSL Pattern? How about authorization? • Is the Application secure? Not only SSL part. • Go backward – Metasearch as a requirements for an application. Follow Dr. Fernandez methodology with this use case. What part of the methodology model checking can be useful? (ex: financial application) what is the benefits of formalization/model checking? Specific patterns to be used. Can a pattern be described in a certain way to be able to be model checked? • Apply same methodology to the pattern (XML firewall) use cases. Use cases: Define filter in rule, actual filtering, filtering in/out, reorder rules … with attacks that can happen in use cases. What can go wrong? • Dr Fernandez will send the XML paper and filter pattern firewall. • Idea of the application development, apply to a pattern • Demo UMLSec tool framework • 1) Abstract Authentication pattern (prove the more abstract patterns) • 2) Password authentication pattern • 3) SSL Authentication pattern • Each pattern can have different attacks

22. Some References [Che02] Hao Chen, David Wagner, “MOPS: an infrastructure for Examining Security Properties of Software”, CCS’02 [Jur05] J. Jurjens, “Sound Methods and Effective Tools for Model-based Security Engineering with UML”, 27th International Conference on Software Engineering (ICSE 2005), ACM, 2005, 322--331. [Fer06a] E. B. Fernandez, M.M. Larrondo-Petrie, T. Sorgente, and M. VanHilst, "A methodology to develop secure systems using patterns", Chapter 5 in "Integrating security and software engineering: Advances and future vision", H. Mouratidis and P. Giorgini (Eds.), IDEA Press, 2006, 107-126. [Bes07] B. Best, J. Jurjens and B. Nuseibeh, Model-based Security Engineering of Distributed Information Systems using UMLsec, Procs. 29th International Conference on Software Engineering (ICSE 2007), ACM, 2007, 581—590 [Jur04] J. Jürjens. Secure Systems Development with UML.Springer-Verlag, 2004. [Cho07] Yunja Choi: "Early Safety Analysis: from Use Cases to - Component-based Software Development", in Journal of Object Technology, vol. 6, no. 8, September - October 2007, 185-203 http://www.jot.fm/issues/issue_2007_09/article4.

23. Feedback