secure systems research group - fau model checking techniques for security systems uml sec tool...

Secure Systems Research Group - FAU

Model Checking Techniquesfor

Security Systems

UML Sec Tool Framework

7/30/2009

Maha B Abbey PhD Candidate


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


Model-based Security Engineering


UMLSec tools framework


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]


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


Security-critical use cases ofMetasearch


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


Class Structure of Use Case LOGIN

EndUser – Central Class Represents user who wants to loginusing AuthenticateUser() methodInvocation 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


Information Flow


Physical Allocation

• EndUser – ClientPC • AuthService – AuthServer• Linked with stereotype

<<encrypted>>• Logical communication

between the components indicated by dependencies stereotyped appropriately


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}


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 modelName of the dependency:

receive session cookieStereotype of the communication link

of the dependency ‘‘receive session cookie’’:encrypted

Stereotype of the dependency:integrity

=> Satisfies the requirement ofthe stereotype ‘‘secure links’’.

Name of the dependency:send login data

Stereotype of the communication linkof the dependency ‘‘send login data’’:encrypted

Stereotype of the dependency:secrecy

=> Satisfies the requirement ofthe 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


Security Analysis of the Authentication Protocol

• 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


Secrecy of pre-master secret

• 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 KAS extracted 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


Realistic adversary model

• %-- 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 KAS with 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

C A AS

C A AS

KA KA

{pms}KA {pms}KA


Model Of Certificate

• 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, KAS is 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


Secure Exchange of the Session Cookie

• 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 User Password

• 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

• 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.


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


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.


Feedback

secure systems research group - fau model checking techniques for security systems uml sec tool...

Documents

security patternsis

security verification

security aspect model

securitycritical parts

complex security mechanisms

composed model

primary model

stereotype invocation