Integrating Security Protocols in Scenario-based Requirements

Speciﬁcations

Thorsten Koch

, Sascha Trippel

, Stefan Dziwok

and Eric Bodden

Fraunhofer IEM, Germany

Paderborn University, Germany

Paderborn University & Fraunhofer IEM, Germany

Keywords:

Scenario-based Requirements Engineering, Security Protocols, Simulative Validation.

Abstract:

Software-intensive systems such as internet services, factories, or vehicles are characterized by complex func-

tionality and strong interconnection. This interconnection leads to a high risk of cyber-attacks. To reduce this

risk, software-intensive systems must fulﬁll various security requirements and integrate security mechanisms

such as security protocols. Security protocols ensure secure communication between and within software-

intensive systems. However, the application of security protocols could negatively impact other parts of the

systems (e.g., its communication behavior) since the protocols introduce further messages and computing-

intensive operations to the system’s behavior. Therefore, the development of software-intensive systems needs

to cover functional and security aspects. This paper presents a model- and scenario-based requirements engi-

neering approach to integrate security protocols in application-speciﬁc requirements speciﬁcations systemati-

cally. Thereby, requirements engineers with limited security knowledge can integrate established and validated

security protocols in their application to increase the security. In particular, our approach provides parameter-

izable templates for security protocols and references these templates in other speciﬁcations. Furthermore, it

provides the simulative validation of the requirements speciﬁcation. We show that our approach is applicable

in practice through a case study involving application scenarios from the automotive domain and established

security protocols.

1 INTRODUCTION

Software-intensive systems have become prevalent

in our daily lives and are characterized by complex

functionality and strong interconnection. However,

the widespread use of software-intensive systems in-

creases the risk of cyber-attacks signiﬁcantly. Thus,

security has become one of the most critical risks

for the world’s population (World Economic Forum,

2021) and one of the grand challenges in the ﬁeld of

model-driven engineering (Bucchiarone et al., 2020).

Attacks on technical systems like industrial con-

trol systems or automotive systems pose a high

risk since malfunctions caused by security incidents

can lead to life-threatening accidents. For exam-

ple, (Miller and Valasek, 2015) conducted an attack

on the Jeep Cherokee and were able to remotely con-

trol the vehicle and manipulate the brakes and the mo-

tor control.

To cope with the complex requirements on func-

tionality and security, the development of software-

intensive systems requires rigorous requirement engi-

neering as detecting and ﬁxing defects in subsequent

development phases causes costly iterations.

Scenario-based approaches enable requirements

engineers to specify what the system under devel-

opment may, must, or must not do during its ex-

ecution (Harel, 2001). The resulting requirements

speciﬁcation provides an intuitive representation of

the system’s behavior (Hassine et al., 2010) and is

easy to understand for people with modeling experi-

ence (Abrahão et al., 2013). However, although secu-

rity is a signiﬁcant concern in developing software-

intensive systems, scenario-based approaches cur-

rently only address functional and safety require-

ments. In addition, requirements engineers usu-

ally have limited security knowledge (Dziwok et al.,

2021), which can lead to severe vulnerabilities in the

system.

We presented a formal, model- and scenario-

based requirements engineering approach for the

speciﬁcation and analysis of requirements on the

Koch, T., Trippel, S., Dziwok, S. and Bodden, E.

Integrating Security Protocols in Scenario-based Requirements Speciﬁcations.

DOI: 10.5220/0010783300003119

In Proceedings of the 10th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2022), pages 15-25

ISBN: 978-989-758-550-0; ISSN: 2184-4348

message-based communication behavior of software-

intensive systems using Modal Sequence Diagrams

(MSDs) (Holtmann et al., 2016).

Based on MSDs, we developed the Security Mod-

eling Proﬁle enabling the speciﬁcation of security

protocols in a scenario-based manner (Koch et al.,

2020). Security protocols are used to secure the

communication between two or more communication

partners (Schneier, 2015). However, security proto-

cols must be designed, implemented, and integrated

correctly in the application. Using the Security Mod-

eling Proﬁle, security engineers can specify security

protocols and verify whether the security protocol ful-

ﬁlls the desired security requirements by means of a

security model checker. However, the speciﬁed and

veriﬁed security protocols were not integrated yet into

a requirements speciﬁcation for an arbitrary applica-

tion; instead, requirements engineers have to model

the security protocols from scratch for each applica-

tion.

To address the problem, this paper presents an

approach to systematically integrate existing security

protocols speciﬁed by means of the Security Model-

ing Proﬁle in a scenario-based requirements speciﬁ-

cation. Therefore, we reduce the manual effort for

a requirements engineer to use established and vali-

dated security protocols in his application. Further-

more, requirements engineers with limited security

knowledge can use security protocols to increase the

security of their application. In particular, this ap-

proach encompasses the speciﬁcation of parameteri-

zable templates for security protocols and referencing

templates in the scenario-based functional require-

ments speciﬁcation. Furthermore, we extend the play-

out algorithm (Harel and Marelly, 2003), a simulative

validation technique for MSDs, to validate whether

the introduction of a security protocol causes any de-

fects in the other requirements.

To evaluate our approach, we conduct a case study

using two application scenarios from the automotive

domain. Furthermore, we use ﬁve different secu-

rity protocols from SPORE (the security protocols

open repository) (Clark and Jacob, 2002)—among

others—the Needham-Schroeder Public-Key proto-

col. Within our case study, we show that our approach

is applicable and useful in practice.

The remainder of the paper is structured as fol-

lows. In the next section, we introduce the fundamen-

tals of this paper. Section 3 presents our approach for

reusable security protocols. In Section 4, we conduct

a case study to evaluate our approach. Then, Section 5

covers related work. Finally, Section 6 concludes this

paper with a summary and an outlook on future work.

2 MODAL SEQUENCE

DIAGRAMS (MSDs)

This section presents the basic concepts of Modal Se-

quence Diagrams (MSDs) (Holtmann et al., 2016).

The presented concepts have been implemented in the

SCENARIOTOOLSMSD tool suite

. In Section 2.1,

we introduce the overall structure of an MSD speciﬁ-

cation. Afterward, Section 2.2 presents the basics of

the MSD semantics. Then, Section 2.3 describes the

Play-out algorithm, an automatic validation technique

for MSDs. Finally, Section 2.4 explains the Security

Modeling Proﬁle as an extension to MSDs that en-

ables the speciﬁcation and analysis of security prop-

erties on the communication behavior.

2.1 Structure of MSD Speciﬁcations

An MSD speciﬁcation is structured by means of MSD

use cases. Each use case encapsulates requirements

on the communication behavior to be provided by the

system under development. Therefore, an MSD use

case encompasses the participants involved in a self-

contained situation and a set of MSDs specifying the

requirements on the communication behavior.

To illustrate the concepts of MSDs, we use the

EBEAS (Holtmann et al., 2016), an advanced driver

assistance system from the automotive domain, as a

running example. EBEAS is supposed to reduce the

risk of rear-end collisions. Figure 1 depicts a self-

contained situation in which the vehicle leading de-

tects an obstacle in front and has to perform an emerg-

ing brake. To avoid a rear-end collision, leading in-

forms the vehicle ego about an emergency brake.

In an MSD speciﬁcation, UML classes provide

reusable types for all MSD use cases. These types are

used to deﬁne the structure of the system under devel-

opment and its environment. Environment objects are

annotated with the stereotype «Environment» (e.g.,

Environment in Figure 1). Moreover, the UML classes

deﬁne operations used as message signatures and de-

ﬁne which messages can be received by a participant

in an actual MSD. For example, the class diagram in

Figure 1 depicts the two classes Environment and Ve-

hicle. The class Environment encompasses the opera-

tion emcyBraking.

A UML collaboration (dashed ellipse in Figure 1)

speciﬁes the roles participating in a particular use

case. The roles are typed by the UML classes and

used as lifelines in an MSD. For example, the collab-

oration in the middle of Figure 1 encompasses the role

ego that has an abstract syntax link type to the class

Vehicle.

http://scenariotools.org/projects2/

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

EmergencyBraking

class [Package] EmergencyBraking::Typesclass [Package] EmergencyBraking::Types

obstacle()

emcyBrakeWarning()

standstill()

Vehicle

obstacle()

emcyBrakeWarning()

standstill()

Vehicle

emcyBraking()

Environment

emcyBraking()

Environment

«Environment»

env: Environment

«Environment»

env: Environment

leading: Vehicleleading: Vehicle

ego: Vehicleego: Vehicle

type

msd EmcyBrakeTriggeringmsd EmcyBrakeTriggering

obstacle()

emcyBrakeWarning()

emcyBraking()

«Environment»

env: Environment

«Environment»

env: Environment

ego: Vehicleego: Vehicleleading: Vehicleleading: Vehicle

represents

signature

Figure 1: MSD Speciﬁcation Excerpt for the Scenario

Emergency Braking of the EBEAS.

Based on the UML classes and the collaboration,

a set of MSDs speciﬁes the requirements on the com-

munication behavior between the roles involved in the

MSD use case. For example, the bottom diagram

in Figure 1 depicts such an MSD. An MSD encom-

passes lifelines and MSD messages. These messages

are associated with a sending and a receiving lifeline

and an operation signature. For example, the MSD

message emcyBrakeWarning is associated with the

equally named operation signature of the class Vehicle

by means of the abstract syntax link signature. MSD

messages sent from environment objects are called

environment messages, whereas MSD messages sent

from system objects are called system messages.

2.2 MSD Semantics

An MSD progresses as message events occur in a

system at runtime or in an object system during the

simulative validation by means of the play-out algo-

rithm (Harel and Marelly, 2003).

A message event is uniﬁed with an MSD mes-

sage if the event name equals the message name and

if the sending and receiving lifelines of the message

are bound to the sending and receiving objects of the

message event.

When a message event occurs that is uniﬁable

with the ﬁrst message in an MSD, an active MSD is

created. The active MSD progresses when other mes-

sage events occur that are uniﬁable with the subse-

quent MSD messages. This progress is captured by

the cut, which marks the locations of the passed MSD

messages for every lifeline. If the cut is in front of an

MSD message on its sending and receiving lifelines,

the MSD message is enabled. If the cut reaches the

end of an active MSD, the active MSD is terminated.

Each MSD message has a temperature and an ex-

ecution kind. The temperature of a message can be

hot or cold. The temperature is used to distinguish

between provisional (cold) and mandatory (hot) be-

havior depicted by blue and red arrows in Figure 1.

The semantics of a hot message is that other messages

speciﬁed by the MSD are not allowed to occur. For

example, the MSD messages emcyBrakeWarning and

emcyBraking in Figure 1 are hot, whereas the others

are cold. The execution kind of a message can ei-

ther be executed or monitored depicted by solid and

dashed arrows in Figure 1. An executed message indi-

cates that the message must eventually occur, whereas

a monitored message can but does not need to occur.

For example, the MSD message obstacle and stand-

still are monitored, whereas the others are executed.

A violation occurs in an MSD if a message event

occurs that is uniﬁable with a speciﬁed message but

not enabled in this MSD. If a violation occurs, the

active MSD is terminated. Based on the execution

kind and temperature of a cut, we can deﬁne different

types of violations.

• If a violation occurs in a cold cut (i.e., all enabled

messages are cold), it is a cold violation, which

does not violate the requirements.

• If a violation occurs in a hot cut (i.e., at least

one enabled message is hot), it is a hot violation,

which violates the requirements.

• If a violation occurs in an executed cut (i.e., at

least one enabled message is executed), it is a live-

ness violation, violating the requirements.

2.3 Play-out Algorithm

The play-out algorithm (Harel and Marelly, 2003) en-

ables the validation of an MSD speciﬁcation. While

simulating selected execution paths of the system un-

der development, the play-out algorithm ﬁnds defects

regarding the consistency and correctness of the re-

quirements speciﬁcation.

In the beginning, the system waits for environ-

ment events to occur. If an environment event occurs,

MSDs are activated whose initial event is uniﬁable

with the environment event. Next, the play-out al-

gorithm chooses non-deterministically one of the en-

abled system events and executes it if this does not

lead to a hot violation in another MSD. The process is

repeated until there are no active MSDs. The system

then waits for the next environment event. In case of

a hot violation, the algorithm terminates.

Integrating Security Protocols in Scenario-based Requirements Speciﬁcations

2.4 Security Modeling Proﬁle

The Security Modeling Proﬁle (Koch et al., 2020)

introduces an extension to the MSD proﬁle to en-

able the speciﬁcation of security requirements on the

communication behavior. Therefore, the proﬁle pro-

vides stereotypes to specify various security primi-

tives (e.g., encryption or digital signatures).

Figure 2 depicts an excerpt of the MSD speciﬁ-

cation for the Needham-Schroeder Public-Key proto-

col (Lowe, 1996). The security protocol enables mu-

tual authentication between two participants. For this

purpose, the security protocol relies on a trusted key

server, which stores and distributes the public keys of

all participants.

msd Needham-Schroeder Key Exchange & Authentificationmsd Needham-Schroeder Key Exchange & Authentification

client: Clientclient: Client

trustedServer:

TrustedThirdParty

trustedServer:

TrustedThirdParty

server: Serverserver: Server

sendPublicKey (

pubKey = pubKeyS,

reqId = “server“)

requestPublicKey (

ownId = “client“,

reqId = “server“)

«asymmetric_encryption»

pubKey = pubKeyC

privKey = privKeyC

«asymmetric_encryption»

pubKey = pubKeyC

privKey = privKeyC

helloServer (

nonce = “...“,

ownId = “client“)

client: Client

trustedServer:

TrustedThirdParty

server: Server

sendPublicKey (

pubKey = pubKeyS,

reqId = “server“)

requestPublicKey (

ownId = “client“,

reqId = “server“)

«asymmetric_encryption»

pubKey = pubKeyC

privKey = privKeyC

helloServer (

nonce = “...“,

ownId = “client“)

msd Needham-Schroeder Key Exchange & Authentification

client: Client

trustedServer:

TrustedThirdParty

server: Server

sendPublicKey (

pubKey = pubKeyS,

reqId = “server“)

requestPublicKey (

ownId = “client“,

reqId = “server“)

«asymmetric_encryption»

pubKey = pubKeyC

privKey = privKeyC

helloServer (

nonce = “...“,

ownId = “client“)

Needham-Schroeder Participants

client: Clientclient: Client

trustedServer:

TrustedThirdParty

trustedServer:

TrustedThirdParty

server: Serverserver: Server

Needham-Schroeder Participants

client: Client

trustedServer:

TrustedThirdParty

server: Server

class [Package] Needham-Schroeder::Typesclass [Package] Needham-Schroeder::Types

+ helloServer(

nonce: String,

ownId: String

)

- «privateKey»

privKeyS: String

+ «publicKey»

pubKeyS: String

Server

+ helloServer(

nonce: String,

ownId: String

)

- «privateKey»

privKeyS: String

+ «publicKey»

pubKeyS: String

Server

+ sendPublicKey(

pubKey: String,

reqId: String

)

- «privateKey»

privKeyC: String

+ «publicKey»

pubKeyC: String

Client

+ sendPublicKey(

pubKey: String,

reqId: String

)

- «privateKey»

privKeyC: String

+ «publicKey»

pubKeyC: String

Client

+ requestPublicKey(

ownId: String,

reqId: String

)

TrustedThirdParty

+ requestPublicKey(

ownId: String,

reqId: String

)

TrustedThirdParty

class [Package] Needham-Schroeder::Types

+ helloServer(

nonce: String,

ownId: String

)

- «privateKey»

privKeyS: String

+ «publicKey»

pubKeyS: String

Server

+ sendPublicKey(

pubKey: String,

reqId: String

)

- «privateKey»

privKeyC: String

+ «publicKey»

pubKeyC: String

Client

+ requestPublicKey(

ownId: String,

reqId: String

)

TrustedThirdParty

«asymmetric_encryption»

pubKey = pubKeyS

privKey = privKeyS

«asymmetric_encryption»

pubKey = pubKeyS

privKey = privKeyS

Figure 2: MSD Speciﬁcation Excerpt for the Needham-

Schroeder Public-Key protocol (using the Security Model-

ing Proﬁle).

The MSD for the Needham-Schroeder Public-Key

protocol, depicted at the bottom of Figure 2, contains

the three lifelines client: Client, trustedServer: Trust-

edThirdParty, and server: Server. The client: Client

sends the message requestPublicKey to the trusted-

Server: TrustedThirdParty to obtain the public key

of the server: Server. The trustedServer: Trust-

edThirdParty replies to the request and sends the cor-

responding public key to client: Client (cf. sendPub-

licKey in Figure 2). According to the protocol spec-

iﬁcation, this message must be asymmetrically en-

crypted. Therefore, we applied the stereotype «asym-

metric_encryption» to the message sendPublicKey.

The stereotype has the two properties pubKey and

privKey, which are necessary to express information

for the encryption and decryption of the message. In

the example depicted in Figure 2, the property pub-

Key is set to pubKeyC and the property privKey is set

to privKeyC of the class Client, respectively.

To enable the veriﬁcation of security protocols

speciﬁed by the Security Modeling Proﬁle, we con-

ceived a model transformation from the enriched

MSD speciﬁcation into the security model checker

ProVerif (Blanchet, 2001). In addition, the transfor-

mation generates all relevant queries that the model

checker shall verify to decide whether the protocol is

secure w.r.t. conﬁdentiality and authentication.

Furthermore, they extended the MSD semantics

such that the play-out algorithm can validate MSD

speciﬁcations using the Security Modeling Proﬁle. In

particular, they extend the deﬁnition of message uniﬁ-

cation (cf. Section 2.3) and validate whether the same

cryptographic primitives (e.g., stereotypes of the Se-

curity Modeling Proﬁle) are applied to the message

event and the corresponding message. Furthermore,

the properties of the stereotypes of the message and

the message event must be the same. For example, a

message event that is uniﬁable with an enabled mes-

sage but does not have the same cryptographic primi-

tives leads to a violation.

3 INTEGRATION APPROACH

This section introduces our approach for integrating

security protocols into scenario-based requirements

speciﬁcations. First, we present our modeling ap-

proach to specify reusable security protocols and their

application in scenario-based requirements speciﬁca-

tions. Second, we describe the adaptation of the play-

out algorithm to enable the simulative validation of

the resulting scenario-based requirements speciﬁca-

tions.

3.1 Modeling Approach

Security protocols can be used in different applica-

tions to ensure secure communication between the

participants involved in the application.

To avoid the redundant and error-prone task of

modeling the security protocol during the require-

ments engineering for a particular application, we

propose that the security protocol speciﬁcation is sep-

arated from the scenario-based requirements speciﬁ-

cation. Moreover, the scenario-based requirements

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

speciﬁcation should reference the security protocol as

depicted in Figure 3.

On a technical level, although the scenario-based

requirements speciﬁcation and the security protocol

are speciﬁed by means of MSDs, a scenario-based re-

quirements speciﬁcation cannot reuse the behavior of

the security protocol since both speciﬁcations rely on

different types that are used as roles in the MSD use

case and deﬁne the message that can be exchanged

between the roles.

Thus, to overcome this problem, the types of the

system under development must be related to the

types of the security protocol. Thereby, the security

protocol is adapted to the application context of the

system under development, and the speciﬁed types

can adopt the behavior of the security protocol types.

In Figure 3, we illustrate the initial situation using

our running example. The application scenario Emer-

gency Braking of the EBEAS, depicted in the MSD

speciﬁcation on the left side, is supposed to ensure

the encrypted communication between the two roles

leading: Vehicle and ego: Vehicle. Therefore, the re-

quirements engineer decides to execute the Needham-

Schroeder Public-Key protocol, depicted on the right

side. After the execution of the protocol, the two roles

know the public key of each other and can use it to se-

cure their communication (cf. emcyBrakeWarning in

Figure 3).

To adapt the security protocol to the application

context, the role leading: Vehicle has to substitute the

role client: Client; and the role ego: Vehicle has to

substitute the role server: Server (cf. arrows labeled

with represents in Figure 3). Furthermore, the prop-

erties that are used in the stereotypes to annotate that a

message is encrypted (e.g., in Figure 3) must also be

substituted by a property that exists in the scenario-

based requirements speciﬁcation.

One possible idea to relate the different classes

is the concept of UML Inheritance. Therefore, the

UML classes used as types of the scenario-based re-

quirements speciﬁcation extend the UML classes of

the security protocols. The scenario-based require-

ments speciﬁcation types inherit the operations and

properties, which enable their representative roles to

participate in the security protocol.

However, this solution has several drawbacks.

First, as depicted in Figure 3, multiple roles in

a scenario-based requirements speciﬁcation can be

typed by the same class. Thus, it would be unclear

which role of the scenario-based requirements speci-

ﬁcation takes which role in the security protocol. For

example, in Figure 3, the two roles leading and ego

are both typed by the class Vehicle. Second, if a role

of the scenario-based requirements speciﬁcation ex-

ecutes the same security protocol with different par-

ticipants, it might happen that the same properties of

a type must be used in different contexts and, thus,

would be overwritten. Therefore, it is necessary to

deﬁne an explicit relationship for properties.

To address these drawbacks, we conceived a

template-based modeling approach to adapt a security

protocol to the application context of a scenario-based

requirements speciﬁcation.

In the following, we present the extension to the

Security Modeling Proﬁle to enable the speciﬁcation

of security protocol templates. Afterward, we intro-

duce the approach to instantiate the templates within

a scenario-based requirements speciﬁcation.

3.1.1 Deﬁning Security Protocol Templates

Our template-based modeling approach relates struc-

tural elements of the scenario-based requirements

speciﬁcation to structural elements of the security

protocol. Thereby, the security protocol is adapted to

the application context. As a consequence, we intro-

duce the concept of template parameter. A template

parameter is added to those elements of the security

protocol that may be substituted by elements of the

application. There are two types of template parame-

ters: RoleTemplate and PropertyTemplate.

RoleTemplate: A security protocol encompasses at

least two participants, the protocol initiator and

the protocol responder. For example, in the secu-

rity protocol depicted in Figure 3, the role client:

Client initiates the protocol, and server: Server

responds to the initiation. Furthermore, a secu-

rity protocol can encompass other roles, e.g., a

trusted third party as in the Needham-Schroeder-

Key-Protocol.

To enable the substitution of the security proto-

col’s roles, we use the stereotype RoleTemplate

that can be applied to the roles of the UML collab-

oration. For example, in the security protocol de-

picted in Figure 3, we have applied this stereotype

to the two roles client: Client and server: Server.

PropertyTemplate: In a security protocol, roles

have prior knowledge that exists before the initial

communication and is essential to the execution

of the protocol. For example, in the security pro-

tocol depicted in Figure 3, the class Client typing

the role client: Client has the two properties privK-

eyC and pubKeyC to represent the public/private

key pair.

To enable the substitution of the security pro-

tocol’s roles, we introduce a stereotype Proper-

tyTemplate that can be applied to the properties

Integrating Security Protocols in Scenario-based Requirements Speciﬁcations

MSD Specification using a security protocol template

class [Package] EmergencyBraking::Typesclass [Package] EmergencyBraking::Types

MSD Specification specifying a security protocol template

msd EmergencyBrakingmsd EmergencyBraking

msd Needham-Schroeder Key Exchange & Authentificationmsd Needham-Schroeder Key Exchange & Authentification

client: Clientclient: Client

trustedServer:

TrustedThirdParty

trustedServer:

TrustedThirdParty

server: Serverserver: Server

sendPublicKey (

pubKey = pubKeyS,

reqId = “server“)

requestPublicKey (

ownId = “client“,

reqId = “server“)

«asymmetric_encryption»

pubKey = privKeyC

privKey = pubKeyC

«asymmetric_encryption»

pubKey = privKeyC

privKey = pubKeyC

client: Client

trustedServer:

TrustedThirdParty

server: Server

sendPublicKey (

pubKey = pubKeyS,

reqId = “server“)

requestPublicKey (

ownId = “client“,

reqId = “server“)

«asymmetric_encryption»

pubKey = privKeyC

privKey = pubKeyC

msd Needham-Schroeder Key Exchange & Authentification

client: Client

trustedServer:

TrustedThirdParty

server: Server

sendPublicKey (

pubKey = pubKeyS,

reqId = “server“)

requestPublicKey (

ownId = “client“,

reqId = “server“)

«asymmetric_encryption»

pubKey = privKeyC

privKey = pubKeyC

Needham-Schroeder Participants

«RoleTemplate»

client: Client

«RoleTemplate»

client: Client

trustedServer:

TrustedThirdParty

trustedServer:

TrustedThirdParty

«RoleTemplate»

server: Server

«RoleTemplate»

server: Server

class [Package] Needham-Schroeder::Typesclass [Package] Needham-Schroeder::Types

+ helloServer(

nonce: String,

ownId: String

)

-«PropertyTemplate»

«privateKey»

privKeyS: String

+«PropertyTemplate»

«publicKey»

pubKeyS: String

Server

+ helloServer(

nonce: String,

ownId: String

)

-«PropertyTemplate»

«privateKey»

privKeyS: String

+«PropertyTemplate»

«publicKey»

pubKeyS: String

Server

+ sendPublicKey(

pubKey: String,

reqId: String

)

-«PropertyTemplate»

«privateKey»

privKeyC: String

+«PropertyTemplate»

«publicKey»

pubKeyC: String

Client

+ sendPublicKey(

pubKey: String,

reqId: String

)

-«PropertyTemplate»

«privateKey»

privKeyC: String

+«PropertyTemplate»

«publicKey»

pubKeyC: String

Client

+ requestPublicKey(

ownId: String,

reqId: String

)

TrustedThirdParty

+ requestPublicKey(

ownId: String,

reqId: String

)

TrustedThirdParty

obstacle()

emcyBrakeWarning()

emcyBraking()

standstill()

«Environment»

env: Environment

«Environment»

env: Environment

ego: Vehicleego: Vehicleleading: Vehicleleading: Vehicle

+ obstacle()

+ emcyBrakeWarning()

+ standstill()

- «privateKey»

privKeyVe: String

+ «publicKey»

pubKeyVe: String

Vehicle

+ obstacle()

+ emcyBrakeWarning()

+ standstill()

- «privateKey»

privKeyVe: String

+ «publicKey»

pubKeyVe: String

Vehicle

emcyBraking()

Environment

emcyBraking()

Environment

EmergencyBraking

«Environment»

env: Environment

«Environment»

env: Environment

ego: Vehicleego: Vehicle

leading: Vehicleleading: Vehicle

represents

Needham-Schroeder Key

Exchange & Authentification

refref

«SecurityProtocolReference»

roleMap = {

roleParameter = client: Client,

roleArgument = leading: Vehicle

propertyMap = {

propertyParameter = privKeyC,

propertyArgument = leading.privKeyVe

}

«SecurityProtocolReference»

roleMap = {

roleParameter = client: Client,

roleArgument = leading: Vehicle

propertyMap = {

propertyParameter = privKeyC,

propertyArgument = leading.privKeyVe

}

«asymmetric_encryption»

pubKey = ego.pubKeyVe

privKey = ego.privKeyVe

«asymmetric_encryption»

pubKey = ego.pubKeyVe

privKey = ego.privKeyVe

«asymmetric_encryption»

pubKey = pubKeyS

privKey = privKeyS

«asymmetric_encryption»

pubKey = pubKeyS

privKey = privKeyS

Figure 3: The Scenario-based Requirements Speciﬁcation for the Application Scenario Emergency Braking is supposed to

integrate the Needham-Schroeder Public-Key protocol speciﬁed in another speciﬁcation. The SecurityProtocolReference in

the MSD EmergencyBraking depicts only an excerpt of the role and property mapping.

of the UML classes. For example, in the secu-

rity protocol depicted in Figure 3, we have applied

the stereotype to all properties of the two classes

Client and Server.

3.1.2 Referencing Security Protocol Templates

This section introduces our modeling approach for

referencing security protocol templates based on

UML InteractionUse (Object Management Group

(OMG), 2017, Clause 17). A UML InteractionUse

enables the reuse of existing interactions. However, a

UML InteractionUse does not allow to specify struc-

tural substitutions.

Thus, we extend the Security Modeling Proﬁle

proﬁle to specify the substitution of roles to roles and

properties to properties while specifying the Interac-

tionUse. Therefore, we create a new stereotype called

SecurityProtocolReference that extends the UML In-

teractionUse.

The stereotype SecurityProtocolReference inher-

its the property refersTo of type Interaction. This

property is used to specify the interaction that de-

ﬁnes the behavior of the security protocol. For exam-

ple, the SecurityProtocolReference in Figure 3 refers

to the MSD Needham-Schroeder Key Exchange & Au-

thentiﬁcation.

In addition to the inherited properties, the

stereotype SecurityProtocolReference encompasses a

Role2RoleMap. The Role2RoleMap is a list of type

Role2RoleMapEntry mapping the roles from the se-

curity protocol template to roles in the referencing

MSD. The list has at least two elements, the ini-

tiator and the responder of the security protocol.

The concrete mapping is speciﬁed in the data type

Role2RoleMapEntry. Therefore, the data type has two

properties: roleParameter and roleArgument. While

the roleParameter corresponds to a role in the secu-

rity protocol, the roleArgument captures a role of the

application context.

Apart from the two properties used to deﬁne the

role mapping, the Role2RoleMapEntry encompasses

a property called Property2PropertyMap. It is used to

map properties from the security protocol template to

properties in the referencing security protocol.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

For example, in the security protocol depicted

in Figure 3, the stereotype SecurityProtocolReference

speciﬁes an excerpt of the role and property mapping.

Here, the role client: Client of the security protocol is

substituted by the role leading: Vehicle. Furthermore,

the property privKeyC of the class Client is substituted

by the property privKeyVe of the class Vehicle.

3.2 Simulation Approach

We adapted the play-out algorithm of ScenarioTools

to support the modeling approach for the integration

of security protocols in scenario-based requirements

speciﬁcation presented in the previous section.

The adaptation is restricted to the evaluation of

the SecurityProtocolReference and the resolution of

its deﬁned properties. Apart from that, the algorithm

behaves as described in Section 2.3.

If the cut of an active MSD is immediately be-

fore the SecurityProtocolReference, it is directly eval-

uated. Therefore, the play-out algorithm resolves the

substitutions speciﬁed by the SecurityProtocolRefer-

ence and adds the messages deﬁned by the referenced

security protocol. The substitution process encom-

passes two steps. First, the play-out algorithm eval-

uates the role mapping and substitutes the role ac-

cordingly. For example, Figure 4, depicts the MSD

speciﬁcation after resolving the SecurityProtocolRef-

erence. Here, the role leading: Vehicle substitutes the

client: Client and the role ego: Vehicle substitutes the

server: Server. Furthermore, the role trustedServer:

TrustedThirdParty is added to the resulting speciﬁca-

tion since it is not part of any mapping. Note that it is

not relevant whether the lifelines of the security proto-

col template are part of the environment or the system.

Instead, the speciﬁcation kind is taken from the refer-

encing lifelines. As a result of the substitution, the

roles of the requirements speciﬁcation can now send

and receive the messages of the security protocol. Af-

terward, the play-out algorithm evaluates the property

mapping speciﬁed for each role mapping. All refer-

ences to this property in the security protocol speciﬁ-

cation are searched for and replaced by the new refer-

ence. This applies to message parameters as well as

to the references in the individual stereotypes of the

Security Modeling Proﬁle. After the two steps have

been completed, the play-out continues as described

in Section 2.3.

4 CASE STUDY

To evaluate the applicability and usefulness of our ap-

proach in practice, we conduct a case study based

msd EmergencyBraking With Security Protocolmsd EmergencyBraking With Security Protocol

obstacle()

emcyBrakeWarning()

emcyBraking()

«Environment»

env: Environment

«Environment»

env: Environment

ego: Vehicleego: Vehicleleading: Vehicleleading: Vehicle

refref

trustedServer:

TrustedThirdParty

trustedServer:

TrustedThirdParty

requestPublicKey (

ownId = “client“,

reqId = “server“)

Needham-Schroeder Key Exchange & Authentification

«asymmetric_encryption»

pubKey = leading.pubKeyVe

privKey = leading.privKeyVe

«asymmetric_encryption»

pubKey = leading.pubKeyVe

privKey = leading.privKeyVe

«asymmetric_encryption»

pubKey = ego.pubKeyVe

privKey = ego.privKeyVe

«asymmetric_encryption»

pubKey = ego.pubKeyVe

privKey = ego.privKeyVe

sendPublicKey (

pubKey = ego.pubKeyVe,

reqId = “server“)

Figure 4: MSD Speciﬁcation after the Template Substitu-

tion.

on the guidelines by (Kitchenham et al., 1995) and

(Runeson, 2012).

4.1 Case Study Context

We examine three evaluation questions (EQ):

EQ1: Does our approach enable the speciﬁcation of

security protocol templates for real-world security

protocols?

EQ2: Does our approach enable the use of security

protocol templates in a scenario-based require-

ments speciﬁcation?

EQ3: Does our approach enable the analysis of

scenario-based requirements speciﬁcations that

include security protocol templates?

For this purpose, we use the Needham-Schroeder

Public-Key protocol from our running example and

selected four other security protocols from SPORE

(the security protocol open repository) (Clark and

Jacob, 2002). The ﬁve security protocols present

a broad range of possible security protocols since

they use different cryptographic primitives. For ex-

ample, the Needham-Schroeder Public-Key protocol

uses asymmetric encryption, while the Andrew Se-

cure RPC uses symmetric encryption.

Furthermore, we model two application scenarios

from the EBEAS (cf. Section 2.1) that shall integrate

the ﬁve selected security protocols. The ﬁrst appli-

cation scenario is taken from the running example.

The second application scenario is similar but con-

tains two additional roles whose communication must

be encrypted.

The two application scenarios are sufﬁcient to

evaluate our approach for the following two reasons.

First, the use of the SecurityProtocolReference is in-

dependent of the application scenario. Here, it is

Integrating Security Protocols in Scenario-based Requirements Speciﬁcations

only essential to use different security protocols and,

thereby, to specify various substitutions by means of

the SecurityProtocolReference. Second, the simula-

tion of a SecurityProtocolReference is also indepen-

dent of the application scenario. Here, it is essential to

use the same protocol multiple times but also to sim-

ulate different protocols at the same time. The second

application scenario covers both cases.

In preparation of the case study, we implemented

a prototype of our approach based on SCENARI-

OTOOLSMSD tool suite.

4.2 Research Hypotheses

Based on our objective and evaluation questions, we

deﬁne the following three evaluation hypotheses:

H1: The ﬁve security protocols selected from

SPORE can be speciﬁed as security protocol tem-

plates using our extensions to the Security Model-

ing Proﬁle as presented in Section 3.1.1. We rate

the hypothesis as fulﬁlled if each security proto-

col can be speciﬁed as a security protocol tem-

plate using solely the approach presented in Sec-

tion 3.1.1.

H2: All security protocol templates can be refer-

enced in a scenario-based requirements speciﬁca-

tion. Therefore, all parameters speciﬁed by the

template must be substituted by model elements

of the scenario-based requirements speciﬁcation

using our approach presented in Section 3.1.2. We

consider H2 as fulﬁlled if all security protocol

templates can be used in the two scenario-based

requirements speciﬁcation correctly using our ap-

proach presented in Section 3.1.2.

H3: The references to the ﬁve security protocol tem-

plates can be evaluated correctly according to the

runtime semantics deﬁned in Section 3.2. We rate

H3 as fulﬁlled if the contents of the security pro-

tocol template are correctly inserted into the ref-

erencing scenario-based requirements speciﬁca-

tions during the simulative validation by means of

the play-out algorithm.

4.3 Hypothesis Validation

To validate our hypotheses, we use the prototypical

implementation of our approach based on the Scenar-

ioTools MSD tool-suite. First, we model the MSD

speciﬁcation for each security protocol template and

check whether our modeling proﬁle is sufﬁciently ex-

pressive. Second, we use the two application sce-

narios as scenario-based requirements speciﬁcations

and refer to the resulting security protocol templates.

Finally, we validate the scenario-based requirements

speciﬁcations, including the security protocol refer-

ence, through the play-out algorithm.

4.4 Analyzing the Results

The results of the case study are depicted in Table 1.

Using the extensions to the Security Modeling

Proﬁle, we were able to model all relevant informa-

tion for specifying the ﬁve security protocols as se-

curity protocol templates. Thus, we consider H1 as

fulﬁlled.

Furthermore, we speciﬁed the two exemplary

scenario-based requirements speciﬁcations. To ref-

erence the different security protocol templates, we,

ﬁrst, added the necessary properties to the speciﬁca-

tion. Second, we added the SecurityProtocolRefer-

ence and deﬁned the substitution following the ap-

proach presented in Section 3.2. For both speciﬁca-

tions, we were able to add new properties to the dif-

ferent types and, afterward, deﬁned the substitution

for all parameters of the referenced security protocol

template. Thus, we consider H2 as fulﬁlled.

Finally, we executed the MSD speciﬁcation that

references the security protocol template using our

adapted play-out algorithm. During the execution,

the SecurityProtocolReference was evaluated. Sub-

sequently, we observed that for each security proto-

col and simulation run the contents of the security

protocol template were inserted correctly in the ac-

tive MSD. Moreover, all messages were in the correct

order and were sent between the lifelines speciﬁed

as arguments to their original sending and receiving

lifelines. Furthermore, the properties were correctly

substituted and referenced where necessary. Thus, we

consider H3 as fulﬁlled.

To conclude the case study, the fulﬁlled hypothe-

ses indicate that our approach to speciﬁcation, usage,

and analysis of security protocol templates is applica-

ble and useful in practice.

4.5 Threats to Validity

The following facts threaten the validity of the case

study. First, we only modeled a selection of possi-

ble security protocols as security protocol templates.

So, we cannot generalize our results for all possible

security protocols. However, this threat is mitigated

because the selected security protocols are typical ex-

amples of a security protocol covering all aspects rel-

evant to security protocol templates. Second, the se-

curity protocol templates are only used by two exem-

plary scenario-based MSD speciﬁcations. This threat

is mitigated because the evaluation of a security pro-

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Table 1: Results of the Case Study.

Security Protocol H1 H2 H3

Modeling as Security

Protocol Template

Integration in

Application Scenarios

Validation of the

Resulting Speciﬁcation

Andrew Secure RPC ✓ ✓ ✓

Denning-Sacco Shared Key ✓ ✓ ✓

Difﬁe-Hellman Key Exchange ✓ ✓ ✓

Needham-Schroeder Public-Key ✓ ✓ ✓

Needham-Schroeder Symmetric-Key ✓ ✓ ✓

tocol template reference is independent of other parts

of the MSD speciﬁcation (cf. Section 3.1.2). Finally,

the case study was performed by the same authors that

developed the approach. Since the researchers might

be biased toward the developed approach, the case

study would be more signiﬁcant if other security ex-

perts had modeled the security protocol templates and

if requirements engineers had modeled the scenario-

based speciﬁcations.

5 RELATED WORK

Some approaches consider the speciﬁcation of secu-

rity mechanisms and their reuse in an application’s

requirements and design phase.

(Mouheb et al., 2009) propose an aspect-oriented

modeling approach to integrate security mechanisms

(e.g., security protocols like TLS) into software de-

sign models (e.g., UML Interactions). Therefore,

the authors present a UML proﬁle to specify secu-

rity mechanisms. This proﬁle introduces a transpar-

ent and automatic approach that weaves the security

mechanism into the design models. The approach is

similar to ours since the authors present an approach

to reuse security mechanisms that people with limited

security knowledge can use. However, while the au-

thors only consider the behavior of a security mecha-

nism, we also consider structural properties. Thereby,

we can better adapt the security mechanisms to the

context of the application. Furthermore, we provide a

simulative validation of the resulting speciﬁcation.

(Ray et al., 2004) present an approach to incorpo-

rate role-based access control (RBAC) policies into

the design of applications. The RBAC policies are

deﬁned independently of the application that has to

implement the policies. To bridge the gap between

the policy deﬁnition and the application design, Ray

et al. specify policies by means of UML diagram tem-

plates. These UML diagram templates can be used

to integrate application-speciﬁc policies into the de-

sign of the application. The approach is similar to

our approach since the authors present an approach

to reuse security mechanisms. Furthermore, both ap-

proaches enable the validation of the resulting speciﬁ-

cations. However, in contrast to our approach, Ray et

al. consider role-based access control and only con-

sider the speciﬁcation and analysis of structural mod-

els like UML class and object diagrams.

Furthermore, many approaches consider the mod-

eling of system and software security using UML

and SysML. For example, (Jürjens, 2002) propose

UMLSec as an model-driven approach for integrating

security-related information in UML speciﬁcations.

UMLSec encompasses a UML proﬁle for express-

ing security mechanisms, including secure informa-

tion ﬂow, conﬁdentiality, and access control.

(Lodderstedt et al., 2002) present SecureUML, a

UML-based modeling language for model-driven se-

curity. The approach enables the design and analysis

of secure, distributed systems by adding mechanisms

to model role-based access control. Furthermore, they

provide an automatic generation of access control in-

frastructures based on the speciﬁed models.

(Roudier and Apvrille, 2015) present SysML-Sec,

a modeling approach based on SysML to enable the

speciﬁcation of security aspects for embedded sys-

tems. They enhance SysML block and state machine

diagrams to capture security-related features. In con-

trast to the other two approaches, SysML-Sec also

covers safety-related features.

However, all these approaches mainly focus on ex-

tending the UML/SysML notations to reﬂect security

concerns better. In contrast, our approach addresses

the systematic reuse of existing security mechanisms.

Thereby, our approach separates the speciﬁcation and

application of security mechanisms and allows people

with limited knowledge to rely on these mechanisms

to secure their applications.

6 CONCLUSION

This paper presents an approach for the systematic in-

tegration of security protocols templates in scenario-

based requirements speciﬁcations. Therefore, we

Integrating Security Protocols in Scenario-based Requirements Speciﬁcations

contribute three building blocks. First, we extend the

UML-based Security Modeling Proﬁle with language

constructs enabling the speciﬁcation of security pro-

tocol templates. Second, we introduce an approach to

refer to such a security protocol template in scenario-

based requirements speciﬁcation based on the UML-

based scenario formalism MSD. Third, we extend the

simulative validation technique play-out to support

the security protocol templates.

Our approach enables requirements engineers to

adapt existing security protocols to their context and,

thus, integrate them systematically into their applica-

tion to increase security. In addition, the integration

makes the protocols accessible to people with little

security knowledge. Finally, the simulative valida-

tion enables requirements engineers to check whether

introducing security protocols has violated other re-

quirements.

Future work encompasses three aspects. First, we

plan to conduct a user study to evaluate whether our

modeling language is intuitive and easy to use for se-

curity engineers and requirements engineers. Second,

we want to collect typical security protocol templates

in a library. Requirements engineers could search

this library and select the protocol that best suits their

needs. Third, we want to improve the security model-

ing abilities of our methodology. Therefore, we want

to introduce the concept of misuse cases and make

them analyzable by means of the play-out algorithm.

ACKNOWLEDGEMENTS

This research has been partly sponsored by the project

"AppSecure.nrw - Security-by-Design of Java-based

Applications" funded by the European Regional De-

velopment Fund (ERDF-0801379).

REFERENCES

Abrahão, S., Gravino, C., Insfran, E., Scanniello, G., and

Tortora, G. (2013). Assessing the effectiveness of se-

quence diagrams in the comprehension of functional

requirements: Results from a family of ﬁve experi-

ments. IEEE Transactions on Software Engineering,

39(3):327–342.

Blanchet, B. (11-13 June 2001). An efﬁcient crypto-

graphic protocol veriﬁer based on prolog rules. In

Proceedings. 14th IEEE Computer Security Founda-

tions Workshop, 2001, pages 82–96. IEEE.

Bucchiarone, A., Cabot, J., Paige, R. F., and Pierantonio, A.

(2020). Grand challenges in model-driven engineer-

ing: an analysis of the state of the research. Software

and Systems Modeling, 19(1):5–13.

Clark, J. and Jacob, J. (2002). Security protocols open

repository.

Dziwok, S., Koch, T., Merschjohann, S., Budweg, B., and

Leuer, S. (2021). AppSecure.nrw Software Security

Study. https://arxiv.org/abs/2108.11752.

Harel, D. (2001). From play-in scenarios to code: an

achievable dream. Computer, 34(5):53–60.

Harel, D. and Marelly, R. (2003). Come, Let’s Play:

Scenario-Based Programming Using LSCs and the

Play-Engine. Springer.

Hassine, J., Rilling, J., and Dssouli, R. (2010). An evalu-

ation of timed scenario notations. Journal of Systems

and Software, 83(2):326–350.

Holtmann, J., Fockel, M., Koch, T., Schmelter, D., Bren-

ner, C., Bernijazov, R., and Sander, M. (2016).

The MechatronicUML Requirements Engineering

Method: Process and Language. Technical Report tr-

ri-16-351, Software Engineering Department, Fraun-

hofer IEM / Software Engineering Group, Heinz Nix-

dorf Institute.

Jürjens, J. (2002). UMLsec: Extending UML for Secure

Systems Development. In Jézéquel, J.-M., editor, The

uniﬁed modeling language, volume 2460 of Lecture

Notes in Computer Science, pages 412–425. Springer,

Berlin [u.a.].

Kitchenham, B., Pickard, L. M., and Pﬂeeger, S. L. (1995).

Case studies for method and tool evaluation. IEEE

Software, 12(4):52–62.

Koch, T., Dziwok, S., Holtmann, J., and Bodden, E.

(2020). Scenario-Based Speciﬁcation of Security Pro-

tocols and Transformation to Security Model Check-

ers. In Proceedings of the 23rd ACM/IEEE Interna-

tional Conference on Model Driven Engineering Lan-

guages and Systems, MODELS ’20, page 343–353,

New York, NY, USA. Association for Computing Ma-

chinery.

Lodderstedt, T., Basin, D., and Doser, J. (2002). Se-

cureUML: A UML-Based Modeling Language for

Model-Driven Security. In Jézéquel, J.-M., Huss-

mann, H., and Cook, S., editors, ≪UML≫ 2002

— The Uniﬁed Modeling Language, pages 426–441,

Berlin, Heidelberg. Springer Berlin Heidelberg.

Lowe, G. (1996). Breaking and ﬁxing the needham-

schroeder public-key protocol using fdr. In Goos, G.,

Hartmanis, J., Leeuwen, J., Margaria, T., and Steffen,

B., editors, Tools and Algorithms for the Construc-

tion and Analysis of Systems, volume 1055 of Lecture

Notes in Computer Science, pages 147–166. Springer

Berlin Heidelberg, Berlin, Heidelberg.

Miller, C. and Valasek, C. (2015). Remote exploitation of

an unaltered passenger vehicle. Black Hat USA.

Mouheb, D., Talhi, C., Lima, V., Debbabi, M., Wang, L.,

and Pourzandi, M. (2009). Weaving Security Aspects

into UML 2.0 Design Models. In Proceedings of the

13th Workshop on Aspect-Oriented Modeling, AOM

’09, page 7–12, New York, NY, USA. Association for

Computing Machinery.

Object Management Group (OMG) (2017). OMG Uniﬁed

Modeling Language (OMG UML) – Version 2.5.1.

OMG Document Number: formal/2017-12-05.

MODELSWARD 2022 - 10th International Conference on Model-Driven Engineering and Software Development

Ray, I., Li, N., France, R., and Kim, D.-K. (2004). Us-

ing Uml to Visualize Role-Based Access Control Con-

straints. In Proceedings of the Ninth ACM Symposium

on Access Control Models and Technologies, SAC-

MAT ’04, page 115–124, New York, NY, USA. As-

sociation for Computing Machinery.

Roudier, Y. and Apvrille, L. (2015). SysML-Sec: A

model driven approach for designing safe and se-

cure systems. In 2015 3rd International Conference

on Model-Driven Engineering and Software Develop-

ment (MODELSWARD), pages 655–664.

Runeson, P., editor (2012). Case study research in software

engineering: Guidelines and examples. Wiley, Hobo-

ken, N.J, 1st ed. edition.

Schneier, B. (2015). Applied Cryptography: Protocols, Al-

gorithms and Source Code in C. John Wiley & Sons

Incorporated, New York.

World Economic Forum (2021). Global risks 2021: Insight

report. World Economic Forum, Geneva, 16th edition

edition.

Integrating Security Protocols in Scenario-based Requirements Speciﬁcations