Software Security and Engineering Practices

(CT-6662)

Chapter 8: UML and Security Extensions

Topics to be covered within this chapter
 Secure Systems Development with UML
The UML is a general-purpose visual modeling language that is intended to provide a
standard way to visualize the design of a system.
The Unified Modeling Language (UML) offers an unprecedented opportunity for high-
quality and cost- and time-efficient secure systems development:
 As the de facto standard in industrial modeling, a large number of developers
are trained in UML.
 Compared to previous notations with a user community of comparable size,
UML is relatively precisely defined.
 A variety of tools exist that provide the basic functionality required to use UML
(such as the drawing of UML diagrams).
• To exploit this opportunity, however, some challenges remain:
 One needs to adapt the UML to the application domain of security-critical systems
and advance its correct use in this application domain.
 One has to develop advanced tool support for secure systems development with
UML, such as automatic analysis of UML specifications with respect to security
requirements.
This requires dealing with conflicts between flexibility and unambiguity in the meaning
of UML models. This note aims to contribute to overcoming these challenges.
 …
• We present the UML extension UMLsec for secure systems development,
using the standard UML extension mechanisms.
• The possibility of a high degree of abstraction, and diagrams offering
different views of a system, allow the modeling of security-critical
components in the system context.
• One can automatically evaluate UML specifications for vulnerabilities using
the UMLsec tool support based on a formal semantics of a simplified core of
UML .
 …
A Need for Security
• Society and economies rely on computer networks for communication,
finance, energy distribution, and transportation.
• Attacks can threaten the economical and physical integrity of people and
organizations.
• Interconnected systems can be attacked anonymously and from a safe
distance.
• Networked computers need to be secure.

Problems
 Many flaws and possible sources of misunderstanding found in protocol or
system specifications, sometimes years after publication.
 Many vulnerabilities in deployed security-critical systems have been
exploited, sometimes leading to spectacular attacks.
 …
Causes
I-
• Designing secure systems correctly is difficult.
Even experts may fail:
– Needham-Schroeder protocol (1978)
– attacks found 1981 (Denning, Sacco), 1995 (Lowe)
• Designers often lack background in security.
• Security as an afterthought.
II -
„Blind“ use of mechanisms:
• Security often compromised by circumventing (rather than breaking)
them.
• Assumptions on system context, physical environment.
„Those who think that their problem can be solved by simply applying
cryptography don`t understand cryptography and don`t understand their
problem“ (R. Needham).
iii-
„Penetrate-and-patch“ (aka „banana strategy):
• insecure
• disruptive
 loose customer trust.
Goal: reduce number of flaws arising this way
 Model-Based Security Engineering with UML
Towards a solution of the problems mentioned – take an approach for model-
based security engineering using the UML.
• as represented in Fig. bellow, the idea is to
 first construct a model of a system, which should be as close to human intuition as
possible and is typically relatively abstract.
 In a second step, the implementation is derived from the model: either
 automatically using code generation, or
 manually, in which case one can still generate test sequences from the model to
establish conformance of the code regarding the model.
The goal is to increase the quality of the implemented code while keeping the
implementation cost and the time-to-market bounded.
 …
• For security-critical systems, this approach allows one to consider security
requirements from early of in the development process.
• Using the model-based approach, one can,
- firstly, establish that the system fulfills the relevant security requirements
on the design level, by analyzing the model.
- Secondly, one can check that the code is also secure by generating test
sequences from the model.

Why UML ?
• UML offers an opportunity as a notation for a high-quality model-based
development of security-critical systems that is feasible in an industrial
context:
 a UML specification may already be available for security analysis, or less
difficult to obtain than other notations.
 UML provides graphical, intuitive description techniques with multiple
views of a system through different kinds of diagrams.
It offers standard extension mechanisms (such as stereotypes, tags,
constraints, and profiles) which one can use to tailor the notation to a
specific application domain.
 …
 UML is relatively precisely defined,
 A variety of tools exist that provide the basic functionality required to use
UML, such as the drawing of UML diagrams.
Some challenges (as UML is object-oriented model):
- One needs to adapt the UML to the application domain of security-critical systems
- One has to develop advanced tool support for secure systems development
with UML, such as automatic analysis of UML specifications with respect to
security requirements.
• To overcoming these challenges, the UML extension UMLsec for
secure systems development is used.
 …
The UMLsec extension: Goals -
 allows one to evaluate UML specifications for security weaknesses on the
design level.
 Encapsulates established rules of prudent security engineering in the
context of a widely known notation, and thus makes them available to
developers who may not be security experts.
 Allows the developer to consider security requirements from early on in
the system development process, and
 Involves little additional overhead, since the UML diagrams can serve as
system documentation, which is always desirable to have, and sometimes
required (for example, for security certification).
 …
The UMLsec extension: Overview
• UMLsec is an extension to the Unified Modeling Language for integrating
security related information in UML specifications. This information can be
used for model-based security engineering.

• Recurring security requirements (such as secrecy, integrity, and authenticity)

are offered as specification elements by the UMLsec extension.
The properties are used-
- to evaluate diagrams of various kinds and
- to indicate possible vulnerabilities.
 One can thus verify that the stated security requirements, if fulfilled, enforce a
given security policy.
 One can also ensure that the requirements are actually met by the given UML
specification of the system.
 UMLsec encapsulates knowledge on prudent security engineering and thereby
makes it available to developers who may not be expert in security.
 …
• The extension is given in form of a UML profile using the standard UML
extension mechanisms.
- Stereotypes are used together with tags to formulate security
requirements and assumptions on the system environment.
- Constraints give criteria that determine whether the requirements are met
by the system design, by referring to a precise semantics.

• Here we focus on providing a core profile that includes the main security
requirements.
 Using UML for Security
Lets consider a small part of the UMLsec notation to highlight the UMLsec
approach, considering a simplified model of an Internet-based business
application as a running example.

• A central idea of the UMLsec extension is to define labels for UML model
elements, the so-called stereotypes, which,
when attached, add security-relevant information to these model elements.
This security-relevant information can be of the following kinds:
 Security assumptions on the physical level of the system, such as the
«Internet» stereotype.
 Security requirements on the logical structure of the system (such as the
«secrecy» stereotype) or on specific data values (such as the «critical»
stereotype).
 Security policies that system parts are supposed to obey, such as the «fair
exchange», «secure links», «data security», or «no down-flow» stereotypes.
  UML Diagrams for Security Requirement

 Security Requirements Capture with Use Case Diagrams

 Secure Business Processes with Activity Diagrams
 Physical Security Using Deployment Diagram
 Security-Critical Interaction with Sequence Diagrams
 Secure States Using Statechart Diagrams
 ...
 Security Requirements Capture with Use Case Diagrams
• Use case diagrams are commonly used to describe typical interactions
between a user and a computer system in requirements elicitation.
- They may also be used to capture security requirements.
Example, Fig. , shows a use case diagram describing the following situation:
- a customer buys a good from a business.
- The trade should be performed in a way that prevents both parties from
cheating. - This requirement is included in the diagram by adding a
stereotype «fair exchange» to the subsystem containing the use case diagram.
 …
 Secure Business Processes with Activity Diagrams
• Activity diagrams can be used -
 to model workflow and to explain use cases in more detail
 to make security requirements more precise.
Example, Fig. bellow, explains the use case in more detail by giving the business
process realizing the above two use cases.
- The requirement «fair exchange» is now formulated by referring to the
activities in the diagram.
- The actions listed in the tags {start} and {stop} should be linked in the sense
that if one of the former is executed then eventually one of the latter will be.
This property can be checked automatically.
This would entail that, once the customer has paid,
- either the order is delivered to the customer by the due date, or
the customer is able to reclaim the payment on that date.
 …
.
 …
 Physical Security Using Deployment Diagram
Deployment diagrams are used to describe the physical layer of a system.
- use them to check -
. whether the security requirements on the logical level of the system are
enforced by the level of physical security, or
- whether additional security mechanisms (such as encryption) have to be
employed.
• Continuing with the example, the business application is part of an e-
commerce system, … realized as a web application.
The payment transaction involves transmission of data to be kept secret
(such as credit card numbers) over Internet links.
This information on the physical layer and the security requirement is
reflected in the UML model in Fig. bellow.
Use the stereotype «secure links» to express the demand that security
requirements on the communication are met by the physical layer.
More precisely, for each dependency stereotyped «secrecy» between
subsystems or classes on different nodes n, m, and any communication link
between n and m with some stereotype s, the threat scenario arising from
the stereotype s with regard to an adversary of a given strength should not
violate the secrecy requirement on the communicated data.
 …

We not that in the given diagram, this constraint associated with the
stereotype «secure links» is already violated when considering standard
adversaries, because plain Internet connections can be eavesdropped easily,
and thus the data that is communicated does not remain secret.
For this adversary type, the stereotype «secure links» is thus applied wrongly
to the subsystem.
This can be pointed out automatically by the UMLsec tools.
 …
 Security-Critical Interaction with Sequence Diagrams
Sequence diagrams are used to specify interaction between different parts of a
system. Using UMLsec stereotypes, we can extend them with information giving
the security requirements relevant to that interaction.
For example, this enables one to see whether cryptographic session keys
exchanged in a key exchange protocol remain confidential from possible
adversaries.
• example, based on the security analysis in the previous subsection, lets
create a secure channel for the sensitive data that has to be sent over the
untrusted networks, by making use of encryption.
As usual, we first exchange symmetric session keys for this purpose.
Let us assume that, for technical reasons, we decide not to use a standard
and well-examined protocol such as SSL but instead a customized key
exchange protocol such as the simplified one in Fig. bellow.
The goal is to exchange a secret session key K, using public key 𝐾𝐶 and 𝐾𝑆 ,
which is then used to encrypt the secret data S before transmission.
Here,
*M+𝐾 is the encryption of the message M with the key 𝐾,
𝑆𝑖𝑔𝑛 𝐾 M is the signature of the message M with K, and
:: denotes concatenation.
 …
.
 …
• Note : the UMLsec model of the protocol given in Fig. above is similar to
the traditional informal notation. In that notation, the protocol would be
written as follows:
𝐶  𝑆 : N𝑖 , K 𝐶 , 𝑆𝑖𝑔𝑛𝐾−1 (𝐶 ∷ 𝐾𝐶 )
𝐶

𝑆 𝐶 : {𝑆𝑖𝑔𝑛𝐾−1 (𝐾𝑗 ∷ 𝑁𝑖 )} K , 𝑆𝑖𝑔𝑛𝐾−1 (𝑆 ∷ 𝐾𝑆 )

𝑆 𝐶 𝐶𝐴

𝐶  𝑆 :{ 𝑆𝑖 }K ,
𝑗
• One can again use stereotypes to include important security requirements
on the data that is involved.
 Here, the stereotype «critical» labels classes containing sensitive data
and has the associated tags {secrecy}, {integrity}, {authenticity}, and
{fresh} to denote the respective security requirements on the data.
- The constraint associated with «data security» then requires that these
requirements are met with respect to the given adversary model.
- We assume that the standard adversary is not able to break the
encryption used in the protocol, but can exploit any design flaws that may
exist in the protocol, for example by attempting so-called “man-in-the-
middle” attacks.
 …
 Secure States Using Statechart Diagrams
Statechart diagrams, can be used to specify security requirements on the
resulting sequences of states and the interaction with the object’s environment.
• Lets assume that for privacy reasons, it should remain secret how much
money a customer spends at the website.
- We thus consider the simplified specification of the customer account object
in Fig. bellow.
-The object has a secret attributes money containing the amount of money
spent so far by a given customer.
- It can be read using the operation rm() whose return value is also secret,
and
increased by placing an order using the operation wm(x).

If the object is in the state ExtraService since the amount of money spent
already is over 1000, there is special functionality offered at the website
providing the customer with complementary extra services. There is an
associated operation rx() to check whether this functionality should be
provided. In the specification shown in Fig., this operation is not assumed to be
secret.
 …
• Now we use the stereotype «no down-flow» to indicate that the object
should not leak out any information about secret data, such as the money
attribute.
• Unfortunately, the given specification violates this requirement, since
partial information about the input of the secret operation wm() is leaked
out via the return value of the non-secret operation rx().
Thus the model carries the stereotype illegitimately.
 Security Engineering
• Communication over open, unprotected networks is often prone to attacks.
- In the case of the Internet, it is relatively easy to read or delete messages
that are exchanged, or to insert other messages.
- In wireless networks, it is even easier at least to read or insert messages, in
physical proximity of the network.
• Secure communication over untrusted networks thus requires specific
mechanisms such as encryption and cryptographic protocols.
- A cryptographic protocol is a description of a message exchange, which
includes cryptographic data, for establishing a secure relationship between
the protocol participants, such as a secure communication channel.
Cryptographic protocols are very difficult to design and prone to very subtle
errors.
• Apart from attacking the communication links in a distributed system, an
adversary may also try to directly attack the physical system nodes, if physical
access is possible.
• In systems, where adversaries may get in possession of security-critical nodes
(for example, if adversaries may be system users), one often uses specially
protected hardware such as smart-cards assumed to be tamper-proof.
 …
• The model-based security engineering approach approached here has been
designed for object-oriented and component-oriented systems.
In particular, object-orientation is suitable as a conceptual basis for secure
systems:
- They are equipped with a general mechanism for controlling access to
data, namely method calls, and
offer information hiding by encapsulating data in objects.

• A security policy summarizes the protection requirements of a system.

- some important security requirements and concepts are listed here:
 Fair Exchange  Authenticity
 Non-repudiation  Freshness
 Role-based Access Control  Secure Information Flow
 Secure Communication Link  Guarded Access
 Secrecy and integrity
 …
 Unified Modeling Language (UML)
The Unified Modeling Language (UML) is the de facto industry standard for
specifying object-oriented software systems, also suitable for component-
oriented systems.
It is a graphical language that may be used to specify architectural and
behavioral aspects of software.
• UML diagrams describe various views on different parts of a system design.
There are several kinds of diagrams, describing different aspects of a system
at varying degrees of abstraction. Here, we use the following kinds:
 Use case diagrams
 Class diagrams
 Statechart diagrams (or state diagrams)
 Sequence diagrams
 Activity diagrams
 Deployment diagrams
 Subsystems (a certain kind of packages)
 collaboration diagrams
 component diagrams
 …
 Use case diagrams - describe an abstract view of the functionality
offered by a system by specifying typical interactions with the user. They
are often used in an informal way for negotiation with a customer before
a system is designed.
 Class diagrams - define the static class structure of the system: classes
with attribute, operations, and signals and relationships between classes.
On the instance level, the corresponding diagrams are called object
diagrams.
 Statechart diagrams (or state diagrams) - give the dynamic behavior of
an individual object or component: events may cause a change in state or
an execution of actions.
 Sequence diagrams - describe interaction between objects or system
components via message exchange, in particular method calls.
 Activity diagrams - specify the control flow between several
components within the system, usually at a higher degree of abstraction
than statecharts and sequence diagrams. They can be used to put objects
or components in the context of overall system behavior or to explain use
case in more detail.
 …
 Deployment diagrams - describe the mapping of the system
components to the physical structure of the system.
 Subsystems (a certain kind of packages) - integrate the information
between the different kinds of diagrams and between different parts of
the system specification.
In addition to sequence diagrams, there are collaboration diagrams, which
present similar information. Also, there are component diagrams, presenting
part of the information contained in deployment diagrams.
 …
 Use Case Diagrams
 …
 Class Diagrams
 …
 Statechart Diagrams
 …
 Sequence Diagrams
 …
 Activity Diagrams
 …
 Deployment Diagrams
 Subsystems
…
 …
 UML Extension Mechanisms
UML offers three main “light-weight” language extension mechanisms:
stereotypes, tagged values, and constraints.
Here, we do not consider the “heavy-weight” approach using meta-model
extensions.
 Stereotypes define new types of modeling elements extending the semantics
of existing types or classes in the UML meta-model.
- Their notation consists of the name of the stereotype written in double angle brackets
«», attached to the extended model element.
- This model element is then interpreted according to the meaning ascribed to the Sender
object in Fig. bellow.
The earlier restriction that at most one stereotype can be assigned to any model element
has been dropped since UML 1.4.
 A tagged value is one way of explicitly defining a property is by attaching a
tagged value to a model element.
- A tagged value is a name–value pair, where the name is referred to as the tag.
- The corresponding notation is {tag=value} with the tag name tag and a corresponding
value to be assigned to the tag.
-Tags can define either data values, so-called Data Tags, or references to other model
elements, so-called Reference Tags.
- If the value is of type Boolean, one usually omits {tag=false}, and writes {tag} instead of
{tag=true}.
An example for a tagged value is the {secrecy} tag with value the set {d} associated with
the «critical» stereotype attached to the Sender object in Fig. below.
.
 …
• Another way of adding information to a model element is by attaching
constraints.
- These constraints have to be fulfilled by the relevant diagram part. As an example,
the «data security» stereotype in Fig. above, has an associated constraint.

• Stereotypes can be used to attach tagged values and constraints as pseudo-

attributes of the stereotyped model elements.
- They are called pseudo-attributes because their semantics is outside the
scope of the UML definition.
- All model elements labeled by a particular stereotype receive the
corresponding values and constraints in addition to the attributes,
associations, and superclasses that the element has in the standard UML.
This usage is new from UML 1.4.
 …
• To construct an extension of the UML one collects the relevant definitions of
the stereotypes, tagged values, and constraints into a profile, which is a
stereotyped package (alternatively, the use of so-called prefaces).
A profile:
 Identifies a subset of the UML meta-model,
 Gives “well-formedness rules”, that is a set of constraints, for this subset,
 Gives a semantics in natural language beyond that given by the
identified subset , and
 Lists common model elements.
 Examples for UML extensions include the UML Profile for Software
Development Processes, the UML Profile for Business Modeling, and
extensions for real-time and frameworks.
  Analyzing Model: Notation, Formal Semantics
 Analyzing UML Models
• In the definition of the UMLsec profile, we need to
- formulate constraints on the UML models that model security
requirements that can be rather subtle.
To check them mechanically, one needs to refer to an analyzable model of
the behavioral semantics of the used fragment of UML.
• In the following, we define and explain those properties of such a model
which we need for formalizing the constraints in the UMLsec profile.
• For security analysis, the security-relevant information from the security-
oriented stereotypes is then incorporated.
• The complete behavioral semantics of the fragment of UML is given in
Chaps. 7&8. in R1 book.
 …
 Notation
We assume the usual definitions from elementary set theory and logic.
ℕ is the set of non-negative integers,
ℕn the set of non-negative integers up to and including n, for any n ∈ ℕ.
𝒫(X) is the set of subsets of a set X.
Given a sequence (or list) 𝑙 = (𝑙1 , 𝑙2 , 𝑙3 , …), we write
head(𝑙) for its head 𝑙1 and
tail(𝑙) for its tail (𝑙2 , 𝑙3 , …).
write [] for the empty list, in particular for the empty string.
 A multi-set (or ba𝑔) is a set which may contain multiple copies of an element,
with notation {{ }} instead of the usual brackets. For example,
{{ 1,1,1,1,1,1,1,1,1,1 }} is the multi-set consisting of ten copies of the element 1.
 For two multi-set M and N ,
M⊎N denotes their union and M\N the subtraction of N and M.
 For a multi-set M and a set X, we write M↘X for the multi-set of those elements
in M, preserving their cardinalities, that are also elements of X.
- Intuitively, in M↘X, all elements except those in X are filtered out.
 write 𝑀 ⊆ 𝑁 for two multi-sets M, N if M↘ 𝑁=M.
 write 𝑀 for the set of elements in the multi-set M, and
⋕M for the number of elements in M.
 …
 Outline of Formal Semantics
In UML, both objectives and system components can communicate by exchanging
messages from a given set Events.
-The arrival of such a message is called an event.
-They consist of the message name from a given set MsgNm, and possibly
arguments to the message.
 Message names may be prefixed with object or subsystem instance names from
a given set UMNames.
 The arguments are assumed to be elements of a given set Exp of expressions.
(An example for such a set is defined in Sect. Modeling Cryptography ).
 Each object or component may receive messages in an input queue and
release messages to an output queue.
 Thus in this model, every object or subsystem instance Ο has associated multi-
set 𝒊𝒏𝑸𝒖𝑶 , called the input queue, and 𝒐𝒖𝒕𝑸𝒖𝑶 , called the output queue.
 Here, formal semantics models sending a message msg=op(exp1 ,…, expn ) ∈
Events from an object or subsystem instance 𝑆 to an object or subsystem
instance R as follows:
1. 𝑆 places the message R.msg into its multi-set 𝒐𝒖𝒕𝑸𝒖𝑺 .
2. A scheduler distributes the messages from output queues to the intended
input queues, while removing the message head. In particular, R.msg is
removed from 𝒐𝒖𝒕𝑸𝒖𝑺 and msg added to 𝒊𝒏𝑸𝒖𝑹
3. R removes msg from its input queue and processes its content.
 …
• At the level of single objects, behavior is modeled using statecharts or
sequence diagrams.
The internal activities contained as states of these statecharts can, for
example, be defined using statecharts or sequence diagrams.
• Using subsystems, one can then define the behavior of a system
component 𝐶 by including the behavior of each of the objects or
components directly contained in 𝐶, and by including an activity diagram
that coordinates the respective activities of the various components and
objects.
• Thus for each object or component 𝐶 of a given system, our semantics
defines a so-called UML machine ⟦𝐶⟧, which is a state machine that
communicates with its environment using messages.
 …
• The behavioral semantics ⟦𝐷⟧ of a statechart diagram 𝐷 models the run-to-
completion semantics of UML statecharts.
As a special case, this gives us the semantics for activity diagrams.
Any sequence diagram 𝑆 gives us the behavior ⟦𝑆. 𝐶⟧of each contained
component 𝐶.
• Subsystems group together diagrams describing different parts of a system:
a system component 𝐶 given by a subsystem 𝑆 may contain
subcomponents C1, …, Cn.
- These subcomponents may communicate through the communication links in the
corresponding deployment diagram.
- On the semantical level, each link has a corresponding link queue storing the
messages that are exchanged along the link while in transit.
 The behavioral interpretation⟦𝑆⟧ of 𝑆 is a UML Machine defined as follows:
1. It takes a multi-set of input events.
2. The events are distributed from the input multi-set and the link queues
connecting the subcomponents and given as arguments to the functions
defining the behavior of the intended recipients in 𝑆.
3. The output messages from these functions are distributed to the link
queues of the links connecting the sender of a message to the receiver, or
given as the output from ⟦𝑆⟧ when the receiver is not part of 𝑆.
 …
• When performing security analysis, after the last step, the adversary model
may modify the contents of the link queues in a certain way (explained in
Sect. Security Analysis of UML Diagrams).
• An execution of a UML subsystem S is then a sequence of states and the
associated multi-sets of input and output messages of ⟦𝑆⟧.
• In general, UML specifications may be non-deterministic, for example
because several transitions in a statechart diagram may be able to fire at a
given point in time.
• A subsystem T is a black box refinement of a subsystem 𝑆 if every
observable input/output behavior of T is also an input/output behavior of S.
T is a delayed black box refinement of 𝑆 if every observable input/output
behavior of T differs from an input/output behavior of 𝑆 only in that delays
may be introduced.
 …
 Modeling Cryptography
• We introduce some definitions to be used in modeling cryptographic data in
a UML specification and its security analysis.
• We assume a set Kes with a partial injective map ( )-1 : Keys  Keys.
 The elements in its domain, which may be public, can be used for
encryption and for verifying signatures.
 Those in its range, usually assumed to be secret, are used for decryption
and signing.
 We assume that every key is either an encryption or decryption key, or both:
- any key k satisfying k-1= k is called symmetric;
- the others are called asymmetric.
 We assume that the numbers of symmetric and asymmetric keys are both
infinite.
- We fix infinite sets Var of variables and Data of data values.
 We assume that Keys, Var, and Data are mutually disjoint and that the set
Data contains the names: UMNames ⋃ MsgNme ⊆ Data.
- Data may also include nonces, and other secrets.
 …
• A quotient of a term algebra under a given set of equations is derived from the term
algebra by imposing these equations, and those that can be derived from them, on the
terms.
Then the algebra of cryptographic expressions Exp is the quotient of the term algebra
generated from the set Var ⋃ Keys ⋃ Data with the operations:
 _: : _ (concatenation)
 head(-) and tail (-) (head and tail of a concatenation)
 *−+_ (encryption)
 𝒟ℯ𝒸_(−) (decryption)
 𝒮𝔦𝔤𝔫_(-) (signing)
 ℰ𝔵𝔱 _(-) (extracting from signature)
 ℋ𝔞𝔰𝔥(-) (hashing)
by factoring out the equations:
 𝒟ℯ𝒸𝑘 −1 ({𝐸}K ) = 𝐸(for all 𝐸 ∈ Exp and 𝐾 ∈ Keys)
 ℰ𝔵𝔱K (𝒮𝔦𝔤𝔫 𝑘 −1 (𝐸)) = 𝐸(for all 𝐸 ∈ Exp and 𝐾 ∈ Keys)
 and the usual laws regarding concatenation, head (), and tail () :
- (𝐸1 ∷ 𝐸2 ) ∷ 𝐸3 = 𝐸1 ∷ (𝐸2 ∷ 𝐸3 ) (for all 𝐸1 , 𝐸2 , 𝐸3 ∈ Exp )
- head((𝐸1 ∷ 𝐸2 ) = 𝐸1 (for all expressions 𝐸1 , 𝐸2 ∈ Exp ) and
- tail((𝐸1 ∷ 𝐸2 ) = 𝐸2 (for all expressions 𝐸1 , 𝐸2 ∈ Exp such that there exists
no 𝐸, 𝐸′ with 𝐸1 = 𝐸 ∶: 𝐸 ′ ). For all other cases, head () and tail () are
undefined.
 …
For each 𝐸 ∈ Exp, we use the following abbreviations :
 fst (𝐸) ≝ head (𝐸)
 snd (𝐸) ≝ head (𝐭𝐚𝐢𝐥(𝐸))
 thd (𝐸) ≝ head(𝐭𝐚𝐢𝐥(𝐭𝐚𝐢𝐥(𝐸) ) )
We use this abstract model of cryptographic algorithms which abstracts away
the details on the level of bit sequences, in order to keep the mechanical
analysis feasible.
 This symbolic model for cryptographic operations, implies that we assume
cryptography to be perfect, in the sense that an adversary cannot “guess” an
encrypted value without knowing the decryption key.
 In particular, we assume that symmetric encryption is implemented in a way
that provides data integrity, for example using Message Authentication
Codes (MACs) , since “encryption without integrity-checking is all but
useless”.
Also, we assume that one can detect whether the correct key is used for
decryption.
 …
 Note also that our model captures the fact that security-critical data such as
keys and nonces are usually assumed to be independent :
This means that no equations should hold between them from which an
adversary could derive information, such as 𝐾=𝐾’ +1 for two different keys
𝐾, 𝐾’ ∈ Keys.
• Based on this formalization of cryptographic operations, important
conditions on security critical data (such as freshness, secrecy, integrity, and
authenticity) can then be formulated at the level of UML diagrams in a
mathematically precise way.
• In the following, we will often consider subalgebras of Exp.
- These are subsets of Exp which are closed under the operations used to define
Exp, such as concatenation, encryption, decryption, etc..
- For each subset 𝐸 of Exp there exists a unique smallest Exp-subalgebra ⟨𝐸⟩
containing 𝐸, which we call Exp-subalgerbara generated by 𝐸.
- Intuitively, it can be constructed from 𝐸 by iteratively adding all element in
Exp reachable by applying the operations used to define Exp above.
- It can be seen as the knowledge one can obtain from a given set 𝐸 of data by
iteratively applying publicly available operations to it and will be used to model
the knowledge an attacker may gain from a set 𝐸 of data obtained for example
by eavesdropping on Internet connections.
 …
 Security Analysis of UML Diagrams
Here, we explain the security analysis machinery underlying the UMLsec
approach.
• Our modular UML semantics allows a rather natural modeling of potential
adversary behavior.
- We can model specific types of adversaries that can attack different parts
of the system in a specified way.
- For example, an attacker of type insider may be able to intercept the
communication links in a company-wide local area network.
- We model the actual behavior of the adversary by defining a class of UML
Machines that can access the communication links of the system in a
specified way.
- To evaluate the security of the system with respect to the given type of
adversary, we consider the joint execution of the system with any UML
Machine in this class.
- This way of reasoning allows an intuitive formulation of many security
properties.
- Since the actual verification is rather indirect this ay, we also give
alternative intrinsic ways of defining security properties below, which are
more manageable, and show that they are equivalent to the earlier ones.
 …
• Thus for a security analysis of a UML subsystem specification, we need to
model potential adversary behavior.
- It should be possible to model specific types of adversaries that can attack different parts
of the system in a specified way.
- For this, we firstly define the set of abstract threats {delete, read, insert, access} arising
from a specification of the physical layer of a system.
- The delete, read, and insert threats mean that an adversary may delete, read or insert
messages on a communication link, respectively.
- The access threat represents the possibility that an adversary may directly access a
physical system node.
- We then assume a function Threats𝐴(𝑠) which takes an adversary type 𝐴 and a stereotype
𝑠 and returns a subset of {delete, read, insert, access}.
- In the context of UML, these functions arise from the specification of the physical layer of
the system under consideration using deployment diagrams.
- The idea is thus that Threats𝐴(𝑠) specifies the threat scenario associated with an adversary
type 𝐴 against a component or link stereotyped 𝑠.
- On the one hand, the threat scenario determines, which data the adversary can obtain by
accessing components; on the other hand, it determines, which actions the adversary is
permitted by the threat scenario to apply to the concerned links.
- From the abstract threats we derive the more basic concrete threats used for modeling
and analyzing the possible adversary Behavior.
 …
This is done by,
- firstly, requiring that an adversary needs to have access to the system part to be
attacked.
For example, to attack a wireless network, the adversary needs to be
in physical proximity.
- Secondly then, the access threat with respect to a node contained in this system
part is broken down to the atomic actions delete, read, and insert with respect to the
communication links connected to these nodes:
If an adversary can access a node, this means that he may delete, read or insert
messages on the communication links connected to this node.
- For a link or node 𝑥 in a deployment diagram in a UML subsystem specification 𝑆,
we thus define the set threatsS𝐴(𝑥) of concrete threats from adversaries of type 𝐴 to
be the smallest set satisfying the following conditions:
If each node 𝑛 containing 𝑥 carries a stereotype 𝑠𝑛 with access ∈ Threats𝐴(𝑠𝑛) then:
 For every stereotype 𝑠 attached to 𝑥, we have Threats𝐴(𝑠) ⊆ threatsS𝐴(𝑥) .
 If x is a link connected to a node that carries a stereotype 𝑡 with access ∈
Threats𝐴(𝑡) then {delete, read, insert} ⊆ threatsS𝐴(𝑥).
• Then we model the actual behavior of an adversary adv of type 𝐴 as a type
𝐴 adversary machine.
 …
Essentially, this is UML Machine which has the following data, where we give a
slightly simplified account sufficient to define the UMLsec notation and
semantics:
 A set of states State with a control state control ∈ State.
 A set of current adversary knowledge 𝐾𝐴 ⊆ Exp.
 For each possible control state 𝑐 ∈ State and set of knowledge 𝐾 ⊆ Exp,
we have:
̶ a set Deletec,K which may contain the name of any link 𝑙 with delete ∈
threatsS𝐴(𝑙),
̶ a set Insert c, K which may contain any pair (𝑙, 𝐸) where 𝑙 is the name of a link
with insert ∈ threatsS𝐴(𝑙), and 𝐸 ∈ 𝐾, and
̶ a set newState c, K ⊆ State of states.
The machine is executed iteratively from a specified initial state control ∶= control0
with an initial adversary knowledge 𝐾 ≔ 𝐾𝐴0 defined bellow, where each iteration
proceeds according to the following steps:
(1) The contents of all link queues belonging to a link 𝑙 with read ∈ threatsS𝐴(𝑙) are
added to 𝐾.
(2) The content of any link queue belonging to a link 𝑙 ∈ Deletecontrol, K is mapped
to ∅.
 …
(3) The content of any link queue belonging to a link 𝑙 is enlarged with all
expressions 𝐸 where (𝑙, 𝐸) ∈ Insertcontrol, K.
(4) The next control state is chosen non-deterministically from the set
newStatecontrol,K.
• The set 𝐾𝐴0 of initial knowledge of an adversary of type 𝐴 is defined to be
𝑝
the algebra of expressions generated by the sets 𝐾𝐴𝑎 and 𝐾𝐴 .
- Here, the set 𝐾𝐴𝑎 of accessible knowledge contains all data values 𝑣
given in the UML specification under consideration for which each node 𝑛
containing 𝑣 carries a stereotype 𝑠𝑛 with access ∈ Threats𝐴(𝑠𝑛 ).
𝑝
- In a given situation, the set 𝐾𝐴 of previous knowledge can be used to
give the adversary access to additional data supposed to be known
before start of the execution of the system, such as public keys.
• Note that an adversary 𝐴 able to remove all values sent over the link 𝑙,
represented by delete𝑙 ∈ threatsS𝐴(𝑙), may not be able to selectively
remove a value 𝑒 with known meaning from 𝑙.
For example, the messages sent over the Internet within a virtual private
network are encrypted.
 …
Thus, an adversary who is unable to break the encryption may be able to delete all
messages indiscriminately, but not a single message whose meaning would be
known to the adversary.
• For each UML subsystem 𝑆 and each adversary 𝐴, there exists a most general
adversary machine, also simply called the type 𝐴 adversary machine.
- It is the type 𝐴 adversary machine with the maximal amount of non-
determinism in each of its states.
- Instead of reasoning with respect to all type 𝐴 adversary machines, it is
sufficient to just consider the most general adversary machine, which is often a
simplification, and we will usually do this in the following.
• To evaluate the security of the system with respect to the given type of
adversary, we then define the execution of the subsystem 𝑆 in the presence of
an adversary of type 𝐴 as the UML Machine ⟦𝑆⟧𝐴 by extending the definition of
⟦S⟧ follows:
(1) A multi-set of input events is received.
(2) The events are distributed to the subcomponents.
(3) The output messages from the subcomponents are distributed.
(4) The most general type 𝐴 adversary machine is applied to the link queues as
detailed above.
 …
• Thus after each iteration of the system execution, the adversary may non-
deterministically change the contents of link queues in a way depending
on the level of physical security described in the deployment diagram.
• A subsystem 𝑇 is black-box refinement in presence of an adversary of type
𝐴 of a subsystem 𝑆 if every observable input/output behavior of an
execution of 𝑇 in the presence of an adversary of type 𝐴 is also an
input/output behavior of an execution of 𝑆 in the presence of an
adversary of type 𝐴.
𝑇 is a delayed black-box refinement in presence of adversary of type 𝐴 of
𝑆 if 𝑇 is black-box refinement in presence of an adversary of type 𝐴 of a
subsystem 𝑆, except that delays may be introduced in 𝑇.
 Important Security Opportunities with Models
 Important Security Properties
• One possibility to specify security requirements is to,
- firstly, define an idealized system model where the required security
property evidently holds. For example, all links and components may be
guaranteed to be secure by the physical layer specified in the deployment
diagram.
- Secondly, one would prove that the system model under consideration
is behaviorally equivalent to the idealized one, using a notion of
behavioral equivalence of UML models.
• Here, we consider an alternative way of specifying the important security
properties of secrecy, integrity, authenticity, and freshness which do not
require one to explicitly construct such an idealized system.
- We follow the standard approach by incorporating the attacker model.
- We also explain how to define secure information flow requirements.
 …

Next are discussed the following Important Security Properties:

 Secrecy
 Integrity
 Authenticity
 Freshness
 Secure Information Flow
 …
 Secrecy
• The formalization of secrecy used in the following relies on the idea that a
system specification preserves the secrecy of a pieces of data 𝑑 if the
system never sends out any information from which 𝑑 could be derived by
the adversary in interaction with the system.
Thus we come to the following definition.

Definition 3.1. We say that a UML subsystem S preserves the secrecy of an

expression 𝐸 from adversaries of type 𝐴 if 𝐸 does note appear in the
knowledge set 𝐾 of 𝐴 during any execution of ⟦𝑆⟧𝐴 .

𝑆 preserves the secrecy of a variable 𝑣 from adversaries of type 𝐴 if for

every expression 𝐸 which is a value of the variable 𝑣 at any point,
𝑆 preserves the secrecy of 𝐸 from adversaries of type 𝐴.
 …
 Integrity
• The property integrity can be formalized similarly:
if during the execution of the considered system, a system variable is
assigned a value different from the ones it is supposed to be, then the
adversary must have caused this variable to contain the value. In that
sense the integrity of the variable is violated.

Definition 3.2. Given a set 𝐸 ⊆ Exp of acceptable expressions, we say that a

subsystem 𝑆 preserves the integrity of an attribute 𝑎 with respect to 𝐸 from
adversaries for type 𝐴 with initial knowledge 𝐾 0 if during any execution of
⟦𝑆⟧𝐴 , at any point the attribute 𝑎 is undefined or evaluates to an element of
𝐸. If 𝐸 = Exp\ 𝐾 0 , we simply say that 𝑆 preserves the integrity of an
attribute 𝑎 from adversaries of type 𝐴 with initial knowledge 𝐾 0 .

• Intuitively, this notion is “dual” to that of secrecy, the sense that secrecy
prevents the flow of information from protected sources to untrusted
recipients, while integrity prevents the flow of information in the other
direction.
 …
 Authenticity
• To formalize message authenticity, we note that a message has its origin at
a system part if during any execution of the system, the message appears
at first at that part.
To provide authenticity then means to secure the information on the
message origin.

Definition 3.3. Suppose we are given attributes 𝑎 and 𝑜 in a subsystem 𝑆,

where 𝑜 is supposed to store the origin of the message stored in 𝑎. We say
that 𝑆 provides (message) authenticity of the attribute 𝑎 with respect to its
origin 𝑜 from adversaries of type 𝐴 with initial knowledge 𝐾 0 if during any
execution of ⟦S⟧A, at any point the value of the attribute 𝑎 appeared as a
subexpression first within the execution in outQu0, of all output queues and
link queues in 𝑆.

• Note that message authenticity is closely related to data integrity.

 …
 Freshness
Freshness of a value may mean the following two properties:
Unpredictability: An attacker cannot guess what its value was.
Newness: The value has never appeared before during the execution of
the system.
- Unpredictability of data is captured by considering a type 𝐴 of adversary
that does not include data in its set of previous knowledge 𝐾 0 .
- Freshness in the sense of newness requires an additional definition.

Definition 3.5. An atomic value data ∈ Data ∪ Keys in a subsystem 𝑆 is fresh

within a subsystem instance or object 𝐷 contained in 𝑆 if the value data
appears in the specification 𝑆 only in diagram parts specifying 𝐷, which are
called the scope of data in 𝑆.

• By the restriction in Definition 3.5, we only consider freshness of atomic

data 𝑑 ∈ Data ∪ Keys, not of compound expressions or variables. Note
that, different elements of Data ∪ Keys are independent . This is why it is
sufficient to require of fresh values that they do not appear in the
specification outside their scope, as in the above definition.
 …
 Secure Information Flow
• For this definition, one needs to assign to each piece of system data one of
two security levels: high, meaning highly sensitive/trusted, and low,
meaning less sensitive/trusted.
The notion is defined by referring to the sequences of input and output
values received and generated by the system, using the UML Machine
⟦S⟧A .
Given a set of messages 𝐻 and a sequence 𝑚 of events multi-sets, we
write:
 𝑚𝐻 for the sequence of event multi-sets derived from those in 𝑚 by
deleting all events the message names of which are not in 𝐻, and
 𝑚𝐻 for the sequence of event multi-sets derived from those in 𝑚 by
deleting all events the message names of which are in 𝐻.
 …
Definition 3.6. Given a subsystem 𝑆 and a set of high messages 𝐻, we say that:
 𝐴 prevents down-flow with respect to 𝐻 if for any two sequences i, j of
event multi-sets and any two output sequences 𝒐 ∈ ⟦S⟧A (i) and P ∈ ⟦S⟧A (j),
𝐢𝐻 = 𝐣𝐻 implies 𝒐𝐻 = 𝐩𝐻 and
 𝐴 prevents up-flow with respect to 𝐻 if for any two sequences i, j of event
multi-sets and any two output sequences 𝒐 ∈ ⟦S⟧A (i) and P ∈ ⟦S⟧A (j),
𝐢𝐻 = 𝐣𝐻 implies 𝒐𝐻 = 𝐩𝐻 .

• Intuitively, to prevent down-flow means that outputting a non-high (or low)

message does not depend on high inputs.
This can be seen as a rather stringent secrecy requirement for messages
marked as high.
• Conversely, to prevent up-flow means that outputting a high value does not
depend on low inputs. This can be seen as a stringent integrity requirement
for messages marked as high.