Extending UML to include Security Constraints for

Embedded Systems

A Thesis submitted to the Graduate School

Of
The University of Cincinnati
In partial fulfillment of the requirements for the degree of

Master of Science
In the
Department of Electrical and Computer Engineering
Of the
College of Engineering and Applied Sciences

February 2016

By
Hitesh K Das

Committee Chair: Dr. Carla Purdy

i
 ABSTRACT

Embedded systems have become a part of our daily life. Increasingly, many applications are

integrated into a single system. The architecture has become very complex. These applications

are used in vehicles, mobile phones, and military and medical fields. Today one of the major

concerns of embedded systems is security. Security leaks in information systems may lead to

financial issues but compromise of security in embedded systems can have disastrous results. It

may lead to big accidents, sometimes resulting in deaths. It can put the safety of a nation at risk.

Hence security aspects should be considered along with the functional properties of a system. It

is always a good practice to consider the security features during the initial stages of design. It

will help the designers to assess the potential dangers of security hazards from the beginning of

the design phase.

Unified Modeling Language (UML) can be used to describe the specifications and design

of an application. It is very suited for embedded applications as it supports object-oriented

modeling. Therefore it is reasonable to add security concerns while using UML to design

complex embedded systems. Research has been going in this area and designers have proposed

several UML extensions to address security issues. The aim of the thesis is to define a

specification and design process based on existing UML diagrams which incorporates basic

security requirements including user identification, secure content, secure storage, secure

network access, secure communication, availability and tamper resistance. This approach tries to

address the security concerns in all stages of embedded system specification and design.

ii
iii
 ACKNOWLEDGEMENTS

I would like to thank and express my gratitude to my thesis advisor, Dr. Carla Purdy for her
guidance and support throughout my research. Her valuable inputs and passionate participation
steered me in the right direction.

I am indebted to Dr. George Purdy and Dr. Wen-Ben Jone for their consent to be on my Master's
thesis committee panel. I am grateful for their time and consideration.

Finally, I would like to acknowledge the constant encouragement of my parents, family, and
friends. This research would not have been possible without their invaluable support. Thank you.

Hitesh Kumar Das

iv
 Table of Contents

1. INTRODUCTION..............................................................................................................1

2. BACKGROUND ................................................................................................................3

2.1 Requirements for specifying and modeling embedded systems ..................................3

2.2 Hardware/software co-design process .........................................................................4

2.3 Motivation to use UML as the modeling language .....................................................5

2.4 Need for security in embedded systems ....................................................................11

2.4.1 Previous work ......................................................................................................... 13

2.5 Need for a generic UML security profile ..................................................................19

3. DESIGN FOR SECURITY .............................................................................................21

3.1 Proposed design.........................................................................................................22

3.2 Examples for implementation....................................................................................33

4. IMPLEMENTATION: CASE STUDIES ......................................................................34

4.1 Modern automobiles ...................................................................................................34

4.2 Remote monitoring of implantable medical devices (IMDs) .....................................52

4.3 Automatic payment system for toll roads ...................................................................68

4.4 Summary.....................................................................................................................77

5. CONCLUSIONS AND FUTURE WORK .....................................................................78

6. REFERENCES .................................................................................................................80

v
List of Figures
2.1 Hardware/software co-design process [19]..........................................................................5
2.2 Ports, protocols and protocol roles [2].................................................................................7
2.3 An abstract state machine [2]...............................................................................................7
2.4 UML-SPT profile structure [4]............................................................................................9
2.5 MARTE’s hierarchical structure [6]..................................................................................10
2.6 Basic security requirements of an embedded system [10].................................................12
2.7 Secure links usage [11]......................................................................................................14
2.8 Security-critical use cases of Metasearch [14]...................................................................15
2.9 SecureUML metamodel [20].............................................................................................16
2.10 UMLpac integrated into UML class design [15]..............................................................17
2.11 Use case diagram with security stereotype [12]...............................................................18
2.12 Activity diagram with security stereotype [12]................................................................18
2.13 Proposed security profile [16]...........................................................................................19
3.1.1.a Use case diagram for User Identification module (graphical) ........................................24
3.1.1.b Use case diagram for User Identification module (verbal) .............................................24
3.1.2.a Use case diagram for other security requirements (graphical) ........................................25
3.1.2.b Use case diagram for other security requirements (verbal) ............................................26
3.1.3.a Use case diagram for problem detection module (graphical) .........................................27
3.1.3.b Use case diagram for problem detection module (verbal) ..............................................27
3.2 Class diagram for a secured system..................................................................................29
3.3.1 Sequence diagram (I)........................................................................................................31
3.3.2 Sequence diagram (II).......................................................................................................32
4.1 Basic ECUs and the I/O channels of a modern automobile [23].......................................35
4.1.2.1.a Use case diagram for User Identification in an automobile (graphical) ........................37
4.1.2.1.b Use case diagram for User Identification in an automobile (verbal) .............................37
4.1.2.2.a Use case diagram for ECUs and CAN bus (Driver’s perspective) (graphical) ..............38
4.1.2.2.b Use case diagram for ECUs and CAN bus (Driver’s perspective) (verbal) ..................39

vi
4.1.2.3.a Use case diagram for ECUs and CAN bus (Mechanic’s perspective) (graphical) ........40
4.1.2.3.b Use case diagram for ECUs and CAN bus (Mechanic’s perspective) (verbal) .............41
4.1.2.4.a Use case diagram for ECUs and CAN bus (Valet’s perspective) (graphical) ................42
4.1.2.4.b Use case diagram for ECUs and CAN bus (Valet’s perspective) (verbal) ....................43
4.1.2.5.a Use case diagram for problem detection module (graphical) ........................................44
4.1.2.5.b Use case diagram for problem detection module (verbal) .............................................44
4.1.3 Class diagram of ECUs and CAN bus for a modern vehicle (Driver’s perspective).......45
4.1.4.1 Sequence diagram for ABS and CAN bus (Driver’s perspective)...................................46
4.1.4.2 Sequence diagram for Cruise Control and CAN bus (Driver’s perspective)...................47
4.1.4.3 Sequence diagram for mechanic......................................................................................48
4.1.4.4 Sequence diagram for EPS and CAN bus (Valet’s perspective).....................................49
4.1.4.5 Sequence diagram for BCM and CAN bus (Valet’s perspective)...................................50
4.1.4.6 Sequence diagram for automobile problem detection module........................................51
4.2.1.1 Examples of Implantable Medical Devices (IMD) [27]..................................................52
4.2.1.2 Wireless communication between IMD and Base station [28]........................................53
4.2.2.1.a Use case diagram for IMD user modification module (graphical) ................................55
4.2.2.1.b Use case diagram for IMD user modification module (verbal) .....................................55
4.2.2.2.a Use case diagram for IMD monitoring (PHCP’s perspective) (graphical) ....................56
4.2.2.2.b Use case diagram for IMD monitoring (PHCP’s perspective) (verbal) .........................57
4.2.2.3.a Use case diagram for IMD monitoring (Nurse’s perspective) (graphical) ....................58
4.2.2.3.b Use case diagram for IMD monitoring (Nurse’s perspective) (verbal) .........................59
4.2.2.4.a Use case diagram for IMD monitoring (Manufacturer’s perspective) (graphical) ........60
4.2.2.4.b Use case diagram for IMD monitoring (Manufacturer’s perspective) (verbal) .............61
4.2.2.5.a Use case diagram for problem detection module (graphical) ........................................62
4.2.2.5.b Use case diagram for problem detection module (verbal) .............................................62
4.2.3 Class diagram for IMD monitoring...................................................................................63
4.2.4.1 Sequence diagram for IMD monitoring (PHCP’s perspective).......................................64
4.2.4.2 Sequence diagram for IMD monitoring (Nurse’s perspective)........................................65

vii
4.2.4.3 Sequence diagram for IMD monitoring (Manufacturer’s perspective)...........................66
4.2.4.4 Sequence diagram for IMD problem detection module...................................................67
4.3 Automatic Payment System at a Toll Station [30].............................................................68
4.3.2.1.a Use case diagram for toll station and driver authorization (graphical) ..........................70
4.3.2.1.b Use case diagram for toll station and driver authorization (verbal) ...............................70
4.3.2.2.a Use case diagram for toll station functions (graphical) .................................................71
4.3.2.2.b Use case diagram for toll station functions (verbal) ......................................................72
4.3.2.3.a Use case diagram for problem detection module (graphical) ........................................73
4.3.2.3.b Use case diagram for problem detection module (verbal) .............................................73
4.3.3 Class diagram for automatic payment system at toll station.............................................74
4.3.4.1 Sequence diagram for toll station automatic payment (modified from [30])..................75
4.3.4.2 Sequence diagram for problem detection at toll station...................................................76

viii
List of Tables

1 UMLsec stereotypes [11]........................................................................................................13

2 Sample stereotype [12]............................................................................................................17
3 ECUs of a modern car: respective functionalities and possible CAN bus choices [24] .........35
4 Summary of implementing the proposed design strategy for case study examples.................77

ix
1. INTRODUCTION

An embedded system is a combination of computer software and hardware designed to serve

a specific purpose. Applications are embedded within a device that consists of hardware which

may contain electrical or mechanical components. Usually these kinds of applications are

achieved with microcontrollers embedded in various systems. Our lives are surrounded with

embedded systems performing different tasks in our homes, offices, cars, etc. Embedded system

is an evolving domain. With the rapid change in technology, the design processes of these

applications have become more complex. More and more applications are integrated within the

systems to make our daily lives easy. These applications need to meet their functional and non-

functional requirements. The embedded systems should meet the specifications in terms of

timeliness, security, reusability, reliability, etc. The understanding and development of

embedded systems has prime importance in the advancement of this technology. Different

object-oriented and component based methods are utilized to develop the real-time embedded

systems in order to meet the constantly evolving specifications. In particular, “technological

advances that have spurred the development of these electronic systems have also ushered in

seemingly parallel trends in the sophistication of security attacks” [10].With the emergence of

embedded systems, security concerns have increased. Insecure systems can lead to disastrous

results. Therefore it has become important to design secure embedded applications which can

resist different kinds of attack techniques. Security features should be considered along with

other design metrics like power, performance and area. It is imperative that the security aspects

be dealt with during the design and specification phase of the application.

1
 The use of the Unified Modeling Language (UML) [9] for embedded software

development is one of the important and emerging trends in the design process for embedded

systems. UML uses graphical notation to represent various object-oriented systems and

applications. UML provides multiple diagrams to design a system from several perspectives,

thereby making the system specification phase easier and more flexible [1]. The rich notations in

UML help in system documentation, capturing requirements and defining initial architecture.

UML employs extension mechanisms (profiles) to satisfy specific application domains. It

implements stereotypes (which extend the UML meta-classes), tagged values and constraints to

build different UML profiles. But there are very few UML profiles that address security issues.

No profile comprehensively addresses these issues. The goal of this thesis is to showcase an

approach to security concerns in UML design. The design process will cover features like user

identification, secure content, secure storage, secure network access, secure communication,

availability and tamper resistance.

2
2. BACKGROUND

Today, we are surrounded by increasing numbers of embedded applications. Our

sophisticated life is the result of an ever evolving process of developing embedded systems.

Many applications are integrated to fulfil new functionalities.

2.1 Requirements for specifying and modeling embedded systems

Marwedel explains that the following features should be represented by an embedded system

model [13].

• Hierarchies should be used for better understanding of the relations between different

components within a system. Behavioral hierarchies represent system behavior and

structural hierarchies show the physical composition of the system.

• Component-based design helps the designers to predict the behavior of the whole

system after understanding the function of each component.

• The models should specify the concurrencies of a real-time distributed embedded

system.

• There should be proper communication and synchronization among the components

for smooth sharing of resources.

• Timing-requirements should be captured in the specification.

• The event-handling features should be explicitly described to understand the reactive

nature of the systems.

• The models should exhibit exception-oriented behavior to handle the exceptions

efficiently.

• Programming language elements should be available.

3
 • The executability of the specification should be verified.

• The specification should be able to support the design for large systems. Object-

oriented methodology should be available in the model.

• It would help to have domain-specific models. The effort for developing specification

techniques and tool support will decrease.

• Specifications should be readable by both humans and computers.

• The models should be portable and flexible. There should not be any dependency on a

specific hardware platform.

• These models should have provisions to support non-standard I/O devices.

• The non-functional properties like fault-tolerance, size, extendibility, expected lifetime,

power consumption, weight, disposability, user friendliness, etc. should be defined in the

models.

2.2 Hardware/software co-design process

The design of an embedded system involves both software and hardware modeling. The

co-design diagram is shown in Figure 2.1 [19]. The process begins with the system specification

stage where the system requirements are outlined. At the next stage, it is divided into basic

blocks called granules. The cost metrics for implementing hardware and software are determined

in the cost estimation step. The next stage, the hardware/software partitioning phase, details the

mapping of different components to hardware and software. The specification refinement stage

transforms the system specification into software and hardware specifications. The co-synthesis

phase results in a set of application-specific integrated circuits (ASICs) and assembler programs

for the processors. The final simulation of the ASICs with the processors is done in the co-

4
simulation stage. The whole process continues until the performance constraints are met and the

cost of the design is acceptable. The embedded design life cycle is also described by Berger [17].

Figure 2.1: Hardware/software co-design process [19]

2.3 Motivation to use UML as the modeling language

With passing time, the architecture of a real-time embedded system gets complex as more

applications are integrated to perform multi-tasks. It is always a good practice to develop an

abstract model of the system in early phase of design for a better understanding of requirements

5
and specifications of the project. The properties of a system can be studied without getting into

the stage of coding. A modeling language should help a designer to understand the complexity

and assist in analyzing the functional and non-functional properties of the system. Hence it is

essential to adopt object oriented modeling in the real-time domain where different modules can

be reused. UML, being a graphical object-oriented modeling language is best suited for this job.

The potential usages of system the system being designed are captured in use cases. UML is

standardized and supports predictive, quantitative analysis through its real-time profiles. UML

has its built-in extensibility mechanisms (stereotypes, tag values, and profiles) which allows it to

be used in a specific domain or a particular application [3]. The continuous changing trend of

embedded systems has made the designers to come up with different kinds of UML profiles to

suit their specifications and needs. An existing model within a UML profile can be refined using

the concept of stereotype [8]. Some of the UML profiles are discussed below.

The Rational Software Corporation addressed the issue of complexities of real time

embedded system architectures in late 90s by proposing a real-time profile known as UML-RT

[2]. This profile utilized its own set of constructs to assist the software design process. These

constructs were derived from the real-time object oriented modeling language (ROOM) [18].

The built-in extensibility mechanisms of UML were used in the constructs. The constructs were

divided into two groups:

Structure Modeling: There are three main components for modeling structure - capsules, ports

and connectors [2]. Capsules are the communicating objects which send and receive messages

through ports. A capsule may be composed of many other capsules presenting a hierarchical

structure. The ports are interconnected through connectors. Each port is assigned a protocol

which decides whether a flow of signal between connected ports is valid or not.

6
 Figure 2.2: Ports, protocols and protocol roles [2]

The protocol takes care of the complex communication method. Figure 2.2 [2] shows an example

of a single port named b belonging to capsule class CapsuleClassA.

Behavior Modeling: The behavior modeling is done using finite state machines and represented

using UML state diagrams. A single state machine may contain other finite state machines. The

transition in the state machine is triggered when it receives a message. Actions can be linked

with changes of a state [3]. Figure 2.3 [2] represents an abstract state machine (i.e., more

specifics are necessary before using it for a real-world purpose).

Figure 2.3: An abstract state machine [2]

7
The UML-RT profile is appropriate for capturing the behavior of the system and can support

simulation [1]. The execution details of a model can be defined using this profile. UML-RT

serves as the foundation for studies focused on schedulability of real-time software design

models. [3].

The OMG (Object Management Group, www.omg.org) adopted UML-SPT [4], the UML

profile to showcase Schedulability, Performance and Time in 2002. UML-SPT is a structure to

define attributes like time, quality of service, concurrency and resource [3]. It also supports

analytical and quantitative study of UML designs. It provides the user with a set of stereotypes

and tagged values to annotate the UML models and apply schedulability and performance

analysis to these models. Figure 2.4 [4] demonstrates the basic structure of a UML-SPT profile.

The UML-SPT profile is divided into a number of sub-profiles. The core of the profile is

represented by General Resource Modeling (GRM) Framework. The GRM consists of

RTresourceModeling (caters to quality of service and resource), RTConcurrencyModeling

(caters to concurrency modeling) and RTtimeModeling (caters to time and time-related

mechanisms modeling). The Analysis Modeling package consists of two profiles for

schedulability analysis (SAprofile) and performance analysis (PAprofile).

8
 Figure 2.4: UML-SPT profile structure [4]

UML-SPT profiles are extensively used in the research which involves projecting quantitative

analysis in the software development process.

When UML 2, the new version of UML came into existence, the SPT profile needed an

upgrade. The OMG proposed a new UML profile, MARTE (Modeling and Analysis of Real-

Time and Embedded systems) [5] for real-time embedded systems in 2005. MARTE helps the

UML modelers in modeling real-time and embedded (RTE) systems by providing them with a

set of domain specific extensions. Some of these extensions are associated with the non-

functional aspects of the applications. MARTE is represented as a hierarchy of profiles as shown

in Figure 2.5 [6].

9
 Figure 2.5: MARTE’s hierarchical structure [6]

The four components of MARTE foundations are:

NFP (Non-functional properties): This profile pertains to the non-functional aspects of UML

models.

Time: This profile defines the time and timing constraints of the application. The Time

extension supports logical, synchronous and chronometric models of time. [6].

GRM (Generic Resource Modeling): This profile pertains to the concepts required to develop

platforms for embedded systems. It has a wide range of resources which enables a user to

develop a variety of computing platforms.

10
 Alloc (Allocation Modeling): This profile represents the layer that allocates the functionality to

the different entities (time-related allocation or space related allocation).

After the foundations, MARTE is further divided into two categories of extensions: MARTE

design model and MARTE analysis model. The design model supports the ‘V’ model-based

design. The analysis model deals with the validation and optimization of the RTE applications.

Indira Jayaram [7] proposed some extensions to the MARTE design process by adding non-

traditional constraints like speed, power, size, weight, cost, reliability, security, controllability,

resistance to environmental conditions and safety.

2.4 Need for security in embedded systems

The modeling requirements [13] and the embedded co-design process [19] have not

mentioned an important feature of the embedded systems, i.e., security. “Today, security in one

form or another is a requirement for an increasing number of embedded systems, ranging from

low-end systems such as PDAs, wireless handsets, networked sensors, and smart cards to mid-

and high-end network equipment such as routers, gateways, firewalls, storage and web servers”

[10]. An embedded application should be resistant to any malicious security threats. Kocher et

al. represent the basic security requirements of an embedded system as shown in Figure 2.6 [10].

11
 Figure 2.6: Basic security requirements of an embedded system [10]

The basic security features like data integrity and confidentiality along with user authentication

facility should be included in these applications. These basic features are collectively known as

secure communications. Secure communications are essential in applications used in military,

automotive, medical, financial and sensing fields. User identification restricts the access to

authorized users only. Secure network access ensures that the device is authorized to access a

network or service. Embedded system availability is a critical factor while determining the

performance and quality of service. Secure storage and secure content ensure the protection of

sensitive data throughout its lifetime. The applications should be tamper resistant to withstand

any physical or logical attacks by any malicious entities.

Different security solutions like cryptographic algorithms have been proposed which can

encrypt and decrypt the sensitive data along with maintaining the data integrity. Symmetric

ciphers, asymmetric algorithms, and hashing schemes are some of the examples which combat

the network threats. The importance of embedded security needs to be realized at the design

stage. Security requirements like denial of service protection and content security need to be

included in the system architecture by the designers. The architectures should be flexible to

12
accommodate future security enhancements. The designers should aim for design for security

techniques wherein they can include the security features in the architecture, similar to the design

for testability feature. This added feature will make the designers aware of the security aspects of

an application in the early stage of the development.

2.4.1 Previous work

Some of the UML modelers have proposed UML profiles which take security concerns into

account. UMLSec [11] was specified by OMG to address security issues. Some of the

stereotypes of this profile are shown in Table 1 [11].

Table 1: UMLsec stereotypes [11]

Figure 2.7 shows an example of secure links usage using UMLsec [11]. UMLsec is a complex

profile and usually applicable to complex and big projects.

13
 Figure 2.7: Secure links usage [11]

The industrial usage of UMLsec method in the intranet of a German car manufacturer is

demonstrated in [14]. The meta search engine in the company, called as Metasearch, was used

for model-based security analysis. It was accessible to all the employees of the company for

various purposes. They could store confidential and non-confidential information. Confidential

documents like development specifications of car models or accessories need to be securely

accessed by employees. Figure 2.8 [14] shows the security-critical use cases of Metasearch. It

defined the security requirements for the applications. The new applications can use services like

user authentication and management of user roles and rights. It had three main use cases namely,

Login, Search, and Store login information. The use case Search serves the functionality of the

Metasearch, i.e., searching and accessing different information using different kinds of queries.

14
 Figure 2.8: Security-critical use cases of Metasearch [14]

SecureUML [20] employs the role-based access control (RBAC) model to annotate the

UML models to implement security features. Figure 2.9 [20] demonstrates the SecureUML

metamodel as an extension of the UML metamodel. New metamodel types like User, Role and

Permission and their inter-relations are introduced in this profile. The type ResourceSet defines

permissions and authorizations. A Permission connects a role to a ModelElement or a

ResourceSet. ActionType elements are used to categorize the permissions. It also defines the

semantics of the permissions. Action types also demonstrate the concepts of operation classes at

a higher abstraction level. A developer assigns the permissions using the Action types. The

ResourceType elements are used to define the set of action types intended for a particular

metamodel type. The attribute baseClass represents the connection to the metamodel. It also

holds the name of a stereotype. The AuthorizationConstraint forms an integral constituent of

access control policy of a particular application.

15
 Figure 2.9: SecureUML metamodel [20]

UMLpac [15] was proposed as one of the approaches for integrating security into UML class

design. It uses a stereotype construct, security package to showcase the security features in a

class diagram. The security package consists of stereotype attributes like Risk Factor, Security

Tile and Security Descriptor. The Risk Factor focuses on the high and the low-risk areas of a

design. It can be an integer, a string range or a probability value. The Security Tile separates the

specific security details from the UML class diagram. A security analyst outlines the secured

parts of a system using this feature. A Security Descriptor specifies the security categories

responsible for protecting a particular part of the application. It tells the kind of information

stored in a security tile. Figure 2.10 [15] shows an example of UMLpac.

16
 Figure 2.10: UMLpac integrated into UML class design [15]

In [12] an approach which is simpler than UMLsec and can be applied to medium and short

term projects is proposed. This method addresses the security concerns by modifying existing

UML diagrams and can be traced in different phases of the development cycle. It employs the

stereotypes to represent the security attributes. Some of the sample stereotypes are mentioned in

Table 2 [12].

Table 2: Sample stereotype [12]

This proposed method attaches stereotypes to use case diagrams and activity diagrams to include

security aspects. This ensures that security requirements are covered from the early stages of
17
development. Figure 2.11 and Figure 2.12 shows the proposed method [12]. This approach is

simple and does not require new UML diagrams.

Figure 2.11: Use case diagram with security stereotype [12]

Figure 2.12: Activity diagram with security stereotype [12]

The reasons for choosing MARTE to implement the security features are explained in [16].

The concept of specification of non-functional properties makes MARTE profile suitable for

implementation of security checks. It also supports schedulability and performance analysis. It

18
uses concepts in Generic Resource Modeling (GRM) and Hardware Resource Modeling (HRM)

which helps in supporting the security aspects. Figure 2.13 [16] shows the proposed security

profile.

Figure 2.13: Proposed security profile [16]

2.5 Need for a generic UML security profile

The UML security profiles discussed earlier mostly cater to a particular application. Many

security profiles introduce new metamodels and involve a lot of mathematical calculations

making them very complex to understand and implement in the design. Some of the designs are

only restricted to either use case diagrams or class diagrams. They are not comprehensive in

nature. The security features need to pass through all stages of embedded system development.

We need to have a design process which will implement security as an absolute requirement at

different stages of a project. Our objective to use the existing UML diagrams along with some

19
new symbols to highlight the basic security requirements in [10] without adding unnecessary

complexity.

20
3. DESIGN FOR SECURITY

Designers tend to treat security as an added feature to a design instead of considering it with

equal importance to functional features. This leads to a lot of security issues. Security should not

be considered as an afterthought. It is important to introduce the security details in the early

phases of the design. Security must be considered throughout all stages of development. Kocher

et al. state that an embedded system should have the basic security requirements like data

confidentiality, data integrity and user authentication [10]. The common security features from

an end-user perspective are:

User Identification: A selected set of authorized users should have access to the embedded

applications.

Secure Storage: The application data and content should be secured in the storage devices.

Secure Content: The digital content should have its digital rights protected.

Secure Communications: Secure communications ensure that the transmission of data

happens between the intended authorized users.

Secure Network Access: It ensures that only authorized users or devices may access the

network services.

Tamper Resistance: An embedded application should not be physically or logically altered

by any malicious unit or attacker thereby manipulating the functionality of the application.

Availability: There should not be any degradation of performance or quality of service due

to any malicious entity.

21
The embedded systems in military, medical, financial and automotive fields need secure

communication channels to avoid any security threats. Secure storage and content security are

also crucial to an embedded system. An end-to-end security solution needs to be developed for

such complex applications. Security aspects should be considered at both the device and network

levels as security is a fundamental part of the consistent working of the embedded applications.

3.1 Proposed design

This thesis aims to extend UML to include security constraints for embedded systems. This

specification and design process for security will handle the security vulnerabilities like

unauthorized data path access, wrong or malicious input and unauthorized access to output. It

will address the critical security requirements as outlined by Kocher et al. [10]. This proposed

design is based on different ideas and methods discussed in the background section. It extends

the basic standard UML diagrams (use case diagram, class diagram and sequence diagram) with

some new symbols to identify the security features of embedded systems.

Use case diagram:

Use case diagrams are used to denote the high-level requirements of the system. They also

define the internal and external influences on the system. They show the interactions between the

actors and the requirements. The use cases state the functionalities. In the proposed design, the

use case diagram is divided into three parts. The first part deals with the user identification

module where an actor needs to be authorized by the system in order to access its applications.

The authentication may be role based and the actor may be assigned some access level privileges

(denoted by “#” symbol) based on different roles and protocols. An authorized actor has a “#”

symbol on its head. This user identification module extends to different modules of the system

22
ensuring that only authorized users with correct privileges access the system. The second part

shows the secure content and secure storage accessed through secure communications.

“Concentric shaded oval shapes” are used to denote secure content. A “shield” symbolizes secure

storage. The authorized actors may use the network using secure network access. The secure

access to the secure applications is denoted by “lock” symbols on the access lines. The third part

focuses on the problem detection module which is categorized into tamper detection and

availability issues like denial of service, degradation of performance and quality of service, etc.

Figure 3.1.1.a - 3.1.3.b show the proposed use case diagrams which cover the critical security

features.

23
 Figure 3.1.1.a: Use case diagram for User Identification module (graphical)

- Use Case Name:

User Identification
- Participating Actor:
User or any device/application
- Flow of events:
Actor authenticates itself with the system through “User Identification” module. The
authentication can be role based depending upon the system requirements. Different roles will
have different level of privileges. The actor will be assigned an access level privilege denoted
by “#” symbol based on different conditions. An unauthorized actor will have the minimum
level of privilege i.e. no privileges to access any secured content. The user identification
module will extend to other security critical modules of the system in order to ensure that these
modules are accessed by authorized users with proper privileges.
- Entry Condition:
Actor authenticates itself with the system through “User Identification” module.
- Exit Condition:
Actor is authorized with an access level privilege (#). An unauthorized actor will
have no access privileges.

Figure 3.1.1.b: Use case diagram for User Identification module (verbal)

24
Figure 3.1.2.a: Use case diagram for other security requirements (graphical)

25
 - Use Case Name:
Accessing Secured Content and Secured Storage using Secured Communication
- Participating Actor:
Authorized User or any device/application
- Flow of events:
Authorized actor inputs the assigned privilege level (#). The system compares the
privilege level of the actor with the privilege level of the secured storage area using security
protocols of the system. If the privilege level matches, then the actor is given the right to access
the secure storage area and the secure content. In case of a mismatch of the privilege level, the
actor is not allowed to access any of the secured content.
- Entry Condition:
Actor tries to access the secured storage area through secure communications.
Inputs the assigned privilege level (#).
- Exit Condition:
Based on the access level privilege (#), the system grants access to the identified
user/device (authorized actor) to use the secured storage area and access the secured content.
An unauthorized actor is denied any kind of access to the secured content and secured storage
area.

- Use Case Name:

Accessing Internet/Intranet based applications using Secured Network Access
- Participating Actor:
Authorized User or any device/application
- Flow of events:
Authorized actor accesses any internet or intranet based applications using the
system’s Secure Network Access protocols. These applications may access any other
applications within the system to fulfil some requirements.
- Entry Condition:
Authorized actor tries to access any internet or intranet based applications.
- Exit Condition:
The Secure Network Access protocols allows (or restricts) the actor to use the
network to access the application.

Figure 3.1.2.b: Use case diagram for other security requirements (verbal)

26
 Figure 3.1.3.a: Use case diagram for problem detection module (graphical)

- Use Case Name:

Problem Detection (Tampering activities and Availability issues like access
denial, performance degradation, etc.)
- Participating Actor:
System ADMIN
- Flow of events:
The problem detection components check other applications for any physical or
logical probing by any malicious entities. It alerts the system admin in case of any
tampering or side channel attacks. It also ensures that there is no degradation of
performance or quality of service. It handles issues like denial of service or buffer overflow.
- Entry Condition:
The problem detection application checks other modules.
- Exit Condition:
The System Admin is notified in case of any tampering or availability issues.

Figure 3.1.3.b: Use case diagram for problem detection module (verbal)

27
Class diagram:

The class diagram is an integral part of object oriented modelling. It is one way of defining

the structure of the system. In an embedded system a class may describe a hardware or software

module. A class diagram is shown in boxes connected to the system. Each box is usually divided

into three parts – class name, attributes and operations. In the proposed design, there is a user

identification class for authentication purposes. A class with secured content will have secure

operations preceded by a “#” symbol. Such operations are within a “shaded concentric box”.

Such classes may be annotated with “Secure Storage” where the secure content is stored in a

secured area. A security critical class is connected to the system through a secure communication

channel denoted by a “lock” symbol on the channels. A class may have both secure and unsecure

operations. Such classes will be termed as semi-critical security classes. The operations part will

be divided into secured and unsecured boxes. The connection lines to such classes will be

divided into two channels i.e., one is secured and the other one remains unsecured. Figure 3.2

shows the class diagram of the proposed design.

28
Figure 3.2: Class diagram for a secured system

29
Sequence diagram:

The sequence diagrams are used to show the flow of different activities within a system in a

visual manner. They represent the interaction between the instances of different classes and

components. Use cases are often explained by sequence diagrams, which show how objects in a

system communicate with each other. In the proposed design, a user or a device is authenticated

first before moving forward in the sequence. The secured objects (instances of secured classes)

are represented with thick concentric boxes and annotated with “Secure Storage” to show that

those objects are secure. The secure communication lines and secure network accesses between

the objects are represented by a “lock” symbol. Figure 3.3.1 represents the sequence diagram for

different functionalities. Figure 3.3.2 represents the sequence diagram for the problem detection

module. This module ensures the integrity of other modules. It alerts the System Admin in case

of any tampering or availability issues.

30
Figure 3.3.1: Sequence diagram (I)

31
Figure 3.3.2: Sequence diagram (II)

32
3.2 Examples for implementation of proposed design

Three systems were chosen to implement the proposed design for a better understanding.

The functioning of electronic component units (ECUs) of modern automobiles, remote

monitoring of implantable medical devices (IMD) and automatic payment system at toll station

serve our purpose. The implementations are explained in the next chapter.

33
4. IMPLEMENTATION: CASE STUDIES

The proposed methodology was implemented for three systems which have the potential for

security risks – modern automobiles, remote monitoring of Implantable Medical Devices (IMD)

and automatic payment system of vehicles at toll stations.

4.1 Modern automobile

Today’s automobiles are computerized and contain a myriad of computational units. These

complex digital units are controlled and monitored by millions of lines of code. The coordination

of these units is achieved through internal vehicular networks. These vehicles are no longer mere

mechanical devices, but computers with wheels. These digital components are known as

Electronic Control Units (ECUs). The ECUs have specific functionalities like engine control,

transmission, handling of doors and windows, brakes, lighting, entertainment, etc. Usually an

ECU consists of sensors and switches for detecting and/or modifying certain attributes like

pressure, temperature, voltage, speed, steering parameters, etc. The ECUs are interconnected by

a shared internal network bus called as the Controller Area Network (CAN) bus. The CAN bus

was able to do away with the large number of wires used to connect several ECUs. The ECUs

send and receive signals via CAN bus network. The signals are circulated in the CAN bus at all

times. The respective ECUs pick their desired signals from this network and perform their

intended functions accordingly. Figure 4.1 [23] shows different ECUs that exist on a modern

automobile. Some of the ECUs and their respective roles are described in Table 3 [24]. A

modern car may have up to 80 ECUs [25]. The embedded software of these ECUs is becoming

complex in order to achieve sophistication.

34
 Figure 4.1: Basic ECUs and the I/O channels of a modern automobile [23]

Table 3: ECUs of a modern car: respective functionalities and possible CAN bus choices [24]

35
 The pervasive monitoring and controlling by these computerized units has also increased the

potential security threats. A malicious entity who can infiltrate any ECU has the ability to take

control of the CAN bus, thereby accessing other important ECUs like the braking system and the

steering control. A modern car can be hacked, adversarially controlled and the driver made

powerless while the car is on the road. This is a dangerous situation which can lead to disastrous

consequences. Many researchers have raised security concerns over the control of the modern

cars. In 2010, some researchers affiliated with Center for Automotive Embedded Systems

Security (CAESS) in partnership with the University of Washington and the University of

California, San Diego demonstrated that they could hack a car wirelessly [21]. Charlie Miller

and Chris Valasek showed a successful remote hacking of a Jeep plying on a highway [22]. They

took control of the basic functions like air-conditioning, radio, windshield wipers, and

accelerator. They were able to play with the speed of the motor and disable the brakes. They

identified one vulnerable element and took control of the vehicle. They proved that carjacking is

now wireless. Therefore it has become increasingly important to consider the security aspects

during the early phases of the design of these computerized units. The designers and developers

should consider the security risks and vulnerabilities at an early stage of development.

Based on the proposed methodology, the use case diagrams is divided into three types –

use case for user identification, use cases for different classes of user and use case for problem

detection module. The use case diagrams cover some of the basic ECUs and their security

aspects. Each use case diagram for a user class shows the ECUs and their interaction with the

CAN bus. The CAN bus is a secured storage area denoted by a “shield” symbol. The ECUs are

secured content denoted by concentric oval shapes. The authorized user accesses the ECUs using

36
secure communications. The authorized driver or mechanic receives alerts in case of any

tampering activities or any other problem.

Figure 4.1.2.1.a: Use case diagram for User Identification in an automobile (graphical)

- Use Case Name:

User Identification
- Participating Actor:
Driver or Mechanic or Valet
- Flow of events:
One actor from the user classes authenticates itself with the vehicle through
“User Identification” application. The authentication extends to the ECUs and CAN bus.
Different users will have different privileges (#). A valet is supposed to have minimum
privileges.
- Entry Condition:
The user furnishes the identification details.
- Exit Condition:
The user is authenticated.

Figure 4.1.2.1.b: Use case diagram for User Identification in an automobile (verbal)

37
Figure 4.1.2.2.a: Use case diagram for ECUs and CAN bus (Driver’s perspective) (graphical)

38
 - Use Case Name:
Accessing different ECUs like ABS, Cruise control, Radio and infotainment
(Secured Content) using Secured Communication
- Participating Actor:
Authorized driver
- Flow of events:
Based on the assigned access level privilege (#), the authorized driver accesses
different ECUs like ABS, Cruise control, Radio and infotainment, etc. using secured
communication channel. The ECUs perform the desired functions after interacting with the
CAN bus through secure network access. However the driver will not have any access to
the CAN bus.
- Entry Condition:
The authorized driver accesses different ECUs based on the assigned access level
privilege (#).
- Exit Condition:
The ECUs perform the desired functions.

Figure 4.1.2.2.b: Use case diagram for ECUs and CAN bus (Driver’s perspective) (verbal)

39
Figure 4.1.2.3.a: Use case diagram for ECUs and CAN bus (Mechanic’s perspective) (graphical)

40
 - Use Case Name:
Accessing different ECUs like ABS, EPS, etc. and CAN bus (Secured Content)
using Secured Communication
- Participating Actor:
Authorized mechanic
- Flow of events:
Based on the assigned access level privilege (#), the authorized mechanic
accesses CAN bus and different ECUs like ABS, EPS, etc. and diagnoses the issues.
However the mechanic will not have any access to some of the ECUs like Radio and
Infotainment.
- Entry Condition:
The authorized mechanic accesses CAN bus and different ECUs based on the
assigned access level privilege (#).
- Exit Condition:
The mechanic detects the problem.

Figure 4.1.2.3.b: Use case diagram for ECUs and CAN bus (Mechanic’s perspective) (verbal)

41
Figure 4.1.2.4.a: Use case diagram for ECUs and CAN bus (Valet’s perspective) (graphical)

42
 - Use Case Name:
Accessing different ECUs like BCM, EPS, etc. (Secured Content) using
Secured Communication
- Participating Actor:
Authorized valet
- Flow of events:
Based on the assigned access level privilege (#), the authorized valet accesses
ECUs like BCM, EPS, and etc. using secured communication channel. However the valet
will not have any access to any other ECUs like Radio and Infotainment or Cruise control.
The valet will be given access to ECUs which will only assist in parking the vehicle.
- Entry Condition:
The authorized valet accesses different ECUs based on the assigned access level
privilege (#).
- Exit Condition:
The valet parks the vehicle.

Figure 4.1.2.4.b: Use case diagram for ECUs and CAN bus (Valet’s perspective) (verbal)

43
 Figure 4.1.2.5.a: Use case diagram for problem detection module (graphical)

- Use Case Name:

Problem Detection (Availability and Tampering issues)
- Participating Actor:
Authorized driver or authorized mechanic
- Flow of events:
The problem detection components check other ECU applications for any physical
or logical probing by any malicious entities. It alerts the driver in case of any tampering. It also
ensures that there is no degradation of performance or quality of service.
- Entry Condition:
The problem detection application checks other ECUs.
- Exit Condition:
The authorized driver or authorized mechanic is notified in case of any issues.

Figure 4.1.2.5.b: Use case diagram for problem detection module (verbal)

44
Figure 4.1.3 shows the class diagram for a modern automobile from a driver’s perspective. The

ECUs interact with the CAN bus using secured network access. The authorized driver accesses

the ECUs through secure communications.

Figure 4.1.3: Class diagram of ECUs and CAN bus for a modern vehicle (Driver’s perspective)
45
The following figures show the sequence diagram for different users. The ECUs interactions

with the CAN bus are demonstrated in those figures. Figure 4.1.4.6 shows the sequence diagram

for problem detection module.

46
 Figure 4.1.4.1: Sequence diagram for ABS and CAN bus (Driver’s perspective)

Figure 4.1.4.2: Sequence diagram for Cruise Control and CAN bus (Driver’s perspective)

47
Figure 4.1.4.3: Sequence diagram for mechanic

48
Figure 4.1.4.4: Sequence diagram for EPS and CAN bus (Valet’s perspective)

49
Figure 4.1.4.5: Sequence diagram for BCM and CAN bus (Valet’s perspective)

50
Figure 4.1.4.6: Sequence diagram for automobile problem detection module

51
4.2 Remote monitoring of implantable medical devices (IMDs)

Implantable medical devices (IMDs) are artificial medical devices which are implanted

inside human bodies surgically or medically to aid some of the organ functioning. The IMD may

be embedded totally or partially inside the human body depending upon the medical

requirements. These devices rely on electrical energy or another source of power which is not

generated by the human body [26]. These are microcomputers which consist of both hardware

and software components. Some commonly used IMDs as shown in Figure 4.2.1.1 [27] are

pacemakers, implantable cardiac defibrillators (ICD), cochlear implants, diaphragm stimulators,

implantable active drug administration device, etc.

Figure 4.2.1.1: Examples of Implantable Medical Devices (IMD) [27]

These IMDs monitor the physiological conditions of a human being for facilitating medical

treatments. The most important function of an IMD is to detect a life threatening condition in a

timely manner. Now it is possible to manage automatically health conditions like cardiac

52
arrhythmia (with the help of an ICD). An IMD can send vital patient information and receive

signals using wireless communication through an external IMD programmer. The programmer

can configure the IMD by sending commands wirelessly. It also queries IMD for diagnostic data

and parameters for patient therapy. Figure 4.2.1.2 [28] shows an example of an ICD with its

wireless base station. The base station can be mobile. The base station communicates with the

implanted device and the large central server system of the medical device company wirelessly.

Figure 4.2.1.2: Wireless communication between IMD and Base station [28]

These systems forward the patient’s health information to their health care practitioner for

monitoring and managing their treatment. Some IMDs are send-only devices, e.g. glucose

monitors. But IMDs like ICD are bi-directional. They can send and receive commands from the

programmer. A particular action can be initiated on the ICD externally. A heart patient can be

administered shocks remotely as and when required by the physician. Remote monitoring of such

devices has saved many lives.

53
 The flip side of this medical advance is that the communication paths utilized by IMDs for

information transaction are not secure. These paths can be hacked and utilized for notorious acts.

Many researchers are working to identify the weak links where the security of these systems can

be compromised. In 2011, a hacker named Barnaby Jack demonstrated the hacking of an insulin

pumps (within 300 feet radius) at a hacker conference [29]. He manipulated the amount of

insulin release remotely. This can lead to the death of a patient. The ICDs can be remotely

hacked and the configurations can be manipulated maliciously resulting in sudden death. The

vital signs data can be extracted by the unauthorized entities, thereby raising security and privacy

concerns. The human bodies which are embedded with IMDs are always at risk of cyber-attacks.

It is very important to consider the security concerns at an early stage of development while

designing the IMDs. A small loophole in these devices can result in many casualties. The remote

monitoring of IMDs needs to be secure and free of any kind of potential threat.

Based on the proposed methodology, the use cases are divided into three types – use case

for authentication, use cases for different users and use case for problem detection module. The

user identification module authenticates the user as the primary health care practitioner (PHCP)

or nurse or the manufacturer of the device. The IMD information has a “shield” symbol showing

that it is a secured storage area and the diagnostic data is a secured content. The patient will

receive notifications whenever there is any change in the settings or any IMD feature is enabled

or disabled. The patient is alerted if any tampering or denial of service issue is detected. The use

cases are shown in Figures 4.2.2.1.a - 4.2.2.5.b.

54
 Figure 4.2.2.1.a: Use case diagram for IMD user modification module (graphical)

- Use Case Name:

User Identification
- Participating Actor:
PHCP or Nurse or Manufacturer
- Flow of events:
Actor authenticates itself with the system through “User Identification” module.
The authentication can be role based (PHCP or Nurse or Manufacturer) depending upon the
system requirements. PHCP will have the highest level of privileges followed by Nurse and
then manufacturer. This authentication extends to other components of the system.
- Entry Condition:
Actor authenticates itself with the system through “User Identification” module.
- Exit Condition:
Actor is authorized as PHCP or Nurse or Manufacturer with an access level
privilege (#).

Figure 4.2.2.1.b: Use case diagram for IMD user modification module (verbal)

55
Figure 4.2.2.2.a: Use case diagram for IMD monitoring (PHCP’s perspective) (graphical)

56
 - Use Case Name:
Accessing IMD information and patient diagnostic data using Secured
Communication
- Participating Actor:
PHCP
- Flow of events:
Authorized PHCP inputs the assigned privilege level (#). The system compares
the privilege level of the PHCP with the privilege level of the IMD (secured storage) using
security protocols of the system. If the privilege level matches, then the PHCP is given the
right to access the IMD and the patient diagnostic data (secured content).

- Entry Condition:
Authorized PHCP tries to access the IMD (secured storage) through secure
communications. Inputs the assigned privilege level (#).
- Exit Condition:
Based on the access level privilege (#), the system grants access to the authorized
PHCP to use the main server and access the IMD. Then PHCP extracts the diagnostic data
from IMD.

- Use Case Name:

Accessing IMD remotely to update the settings using Secured Network Access
Accessing IMD remotely to enable or disable features using Secured Network
Access
- Participating Actor:
PHCP, Patient
- Flow of events:
Authorized PHCP accesses IMD remotely via main server using the system’s
Secure Network Access protocols. The PHCP updates the settings of the IMD remotely.
The PHCP can enable or disable some of the features of IMD remotely. Alerts are generated
when any settings is updated or any feature is enabled or disabled. Finally the patient is
notified with alerts.
- Entry Condition:
Authorized PHCP accesses the IMD remotely via main server using Secure
Network Access protocols.
- Exit Condition:
The patient receives notifications.

Figure 4.2.2.2.b: Use case diagram for IMD monitoring (PHCP’s perspective) (verbal)

57
Figure 4.2.2.3.a: Use case diagram for IMD monitoring (Nurse’s perspective) (graphical)

58
 - Use Case Name:
Accessing IMD information and patient diagnostic data using Secured
Communication
- Participating Actor:
Nurse
- Flow of events:
Authorized nurse inputs the assigned privilege level (#). The system compares the
privilege level of the nurse with the privilege level of the IMD (secured storage) using
security protocols of the system. If the privilege level matches, then the nurse is given the
right to access the IMD and the patient diagnostic data (secured content).

- Entry Condition:
Nurse tries to access the IMD (secured storage) through secure
communications. Inputs the assigned privilege level (#).
- Exit Condition:
Based on the access level privilege (#), the system grants access to the authorized
nurse to use the main server and access the IMD. Then the nurse extracts the diagnostic data
from IMD.

Figure 4.2.2.3.b: Use case diagram for IMD monitoring (Nurse’s perspective) (verbal)

59
Figure 4.2.2.4.a: Use case diagram for IMD monitoring (Manufacturer’s perspective) (graphical)

60
 - Use Case Name:
Accessing IMD information using Secured Communication

- Participating Actor:
Manufacturer
- Flow of events:
Authorized manufacturer inputs the assigned privilege level (#). The system
compares the privilege level of the manufacturer with the privilege level of the IMD (secured
storage) using security protocols of the system. If the privilege level matches, then the
manufacturer is given the right to access the IMD information (secured content).

- Entry Condition:
Manufacturer tries to access the IMD (secured storage) through secure
communications. Inputs the assigned privilege level (#).
- Exit Condition:
Based on the access level privilege (#), the system grants access to the authorized
manufacturer to use the main server and access the IMD. Then the manufacturer extracts the
IMD information.

Figure 4.2.2.4.b: Use case diagram for IMD monitoring (Manufacturer’s perspective) (verbal)

61
 Figure 4.2.2.5.a: Use case diagram for problem detection module (graphical)

- Use Case Name:

Problem Detection
- Participating Actor:
Patient
- Flow of events:
The problem detection components checks the IMD for any physical or logical
probing by any malicious entities. It alerts the patient in case of any tampering or side
channel attacks. It also ensures that the denial of service situation is avoided.
- Entry Condition:
The problem detection application checks IMD.
- Exit Condition:
The patient is alerted in case of any tampering and performance degradation
issues.

Figure 4.2.2.5.b: Use case diagram for problem detection module (verbal)

62
Figure 4.2.3 shows the class diagram for the secured remote monitoring of IMD. The secure

class contains the secure operations like extracting device details, patient data, modifying IMD

settings and enabling or disabling any IMD feature.

Figure 4.2.3: Class diagram for IMD monitoring

63
The following figures show the sequence diagrams for different users of IMD monitoring

system. The authorized user monitors IMD remotely using secure network access and secure

communication. Figure 4.2.4.4 shows the sequence diagram for problem detection.

Figure 4.2.4.1: Sequence diagram for IMD monitoring (PHCP’s perspective)

64
Figure 4.2.4.2: Sequence diagram for IMD monitoring (Nurse’s perspective)

65
Figure 4.2.4.3: Sequence diagram for IMD monitoring (Manufacturer’s perspective)

66
Figure 4.2.4.4: Sequence diagram for IMD problem detection module

67
4.3 Automatic payment system for toll roads

The payments at toll stations for vehicles are made automatic for smoother traffic flow and

reduced waiting times. Figure 4.3 [30] shows the automatic payment system at a toll station.

There is a camera installed at the toll station which detects the approaching vehicles. It scans and

reads the vehicle license plate and passes this information to a subsystem of the payment station.

The toll fee is determined for that vehicle and is sent to it using wireless communication. The toll

fee amount appears in the user interface (UI) of the vehicle for the driver. After accepting the

payment, the driver furnishes the credit card information. This credit card information is sent

wirelessly to the payment station and then the card transaction is done through a third party. The

driver is notified after the successful transaction.

Figure 4.3: Automatic Payment System at a Toll Station [30]

Although this payment system allows smooth traffic flow, there are security concerns over

the wireless communication channel. An attacker may hack one of these communication paths

(“payment station to vehicle” and “payment station to third party merchant”) and extract the

credit card details for malicious intentions. Therefore it is important to establish certain security

68
constraints for these communication channels at an early stage of designing the system. The

developers should include security shields for these systems to prevent hacking of information.

Based on the proposed methodology, the use case diagrams for this automatic payment

system is represented through Figure 4.3.2.1.a - 4.3.2.3.b. The user identification module

authenticates the toll station subsystem and the driver of the vehicle. The vehicle information is

stored in a secured storage area denoted by a “shield” symbol. The credit card information

module is denoted by concentric oval shapes which symbolize secure content. The driver of the

vehicle will receive notifications about the successful payment and the vehicle is allowed to pass

through that toll gate. The toll station manager is alerted if any tampering or access denial issue

is detected.

69
 Figure 4.3.2.1.a: Use case diagram for toll station and driver authorization (graphical)

- Use Case Name:

Driver and Toll station authorization (User Identification)
- Participating Actor:
Toll station subsystem, Driver
- Flow of events:
The driver authenticates itself with the vehicle. The vehicle also authorizes the
toll station subsystem through “User Identification” module. The subsystem provides the
station ID and location name to the vehicle. The vehicle checks the authenticity of the toll
station and then accepts the payment amount to be made. The authentications are extended
to other components of the system.
- Entry Condition:
The driver provides its ID and name to the vehicle authorization system. The toll
station subsystem sends its station ID and location name to the vehicle.
- Exit Condition:
The vehicle authorizes the driver and toll station subsystem.

Figure 4.3.2.1.b: Use case diagram for toll station and driver authorization (verbal)

70
Figure 4.3.2.2.a: Use case diagram for toll station functions (graphical)

71
 - Use Case Name:
Accessing Vehicle information
- Participating Actor:
Authorized toll station subsystem
- Flow of events:
Authorized toll station subsystem scans the license plate of the vehicle. The vehicle
information is extracted from the available sources after reading the number plate of the
vehicle.
- Entry Condition:
Authorized toll station subsystem scans and reads the license plate.
- Exit Condition:
The toll subsystem extracts information about the vehicle.

- Use Case Name:

Sending toll payment amount information using Secured Network Access
- Participating Actor:
Authorized toll station subsystem, Authorized driver
- Flow of events:
The authorized toll station subsystem processes the vehicle information and then
calculates the toll amount to be paid. It sends the payment information to the vehicle using
Secured Network Access. The driver gets the payment information through the User Interface
(UI) of the vehicle.
- Entry Condition:
The authorized toll station subsystem processes the vehicle information.
- Exit Condition:
The authorized driver of the vehicle receives the payment information through UI.

- Use Case Name:

Processing credit card information (Secured Content) using Secured
Communications and sending payment notifications
- Participating Actor:
Authorized toll station subsystem, Authorized driver
- Flow of events:
The authorized driver furnishes the credit card information using the secured
communications. The authorized toll station subsystem receives and processes the credit card
information through a third party merchant. Upon successful transaction of the credit card, the
driver is notified about it through UI and the vehicle is allowed to pass through the toll gate.
- Entry Condition:
The authorized driver provides the credit card details using secured
communications.
- Exit Condition:
The authorized driver of the vehicle receives the payment notification through UI.

Figure 4.3.2.2.b: Use case diagram for toll station functions (verbal)

72
 Figure 4.3.2.3.a: Use case diagram for problem detection module (graphical)

- Use Case Name:

Problem Detection (Access Denial and Tampering issues)
- Participating Actor:
Toll station Manager
- Flow of events:
The problem detection components check other components for any physical or
logical probing by any malicious entities. It alerts the toll station manager in case of any
tampering of any device. It also ensures that there is no degradation of performance or
quality of service. It handles access denial issues.
- Entry Condition:
The problem detection application checks other modules.
- Exit Condition:
The toll station manager is alerted in case of any tampering or availability
issues.

Figure 4.3.2.3.b: Use case diagram for problem detection module (verbal)

73
Figure 4.3.3 shows the class diagram for the automatic payment system at a toll station. The

authorized driver makes the payment using the credit card over the secure communication

channel. The card is processed and the vehicle is allowed to pass the toll gate after a successful

transaction.

74
 Figure 4.3.3: Class diagram for automatic payment system at toll station

Figure 4.3.4.1 shows the sequence diagram for different functions of a toll station subsystem.

The basic diagram is taken from [30] and then modified with security features. Figure 4.3.4.2

shows the sequence diagram for problem detection.

75
Figure 4.3.4.1: Sequence diagram for toll station automatic payment (modified from [30])

76
 Figure 4.3.4.2: Sequence diagram for problem detection at toll station

4.4 Summary

The proposed design was utilized in three examples to incorporate the security aspects, as

explained by Kocher et al. [10], in the design methodology. The following table is a summary of

different security features which were exhibited in the design of three systems. This

methodology only partially represents the security requirement of problem detection (i.e., tamper

resistance and availability) and hence more research work is needed in that area for a

comprehensive demonstration.

Examples User Secure Secure Secure Secure Tamper Availability

Identification Content Storage Communication network resistant
access
Modern Yes Yes Yes Yes Yes Partially Partially
Vehicle
IMD Yes Yes Yes Yes Yes Partially Partially
monitoring
Automatic Yes Yes Yes Yes Yes Partially Partially
payment at
toll station

Table 4: Summary of implementing the proposed design strategy for case study examples

77
5. CONCLUSIONS AND FUTURE WORK

Today security is a major concern area in embedded systems. It cannot be treated as an

afterthought or an additional feature to an application. Security issues in embedded applications

can lead to dangerous consequences. It has become increasingly important to address all the

possible security concerns at the beginning of the specification and design phase. Developers

need to be made aware of the vulnerabilities which can lead to security compromise. The basic

security requirements as stated by Kocher et al. [10] should be present in every embedded

system to ensure it will have adequate security. This thesis proposes a generic UML design for

addressing the security aspects defined in [10] - user identification, secure content, secure

storage, secure communication, secure network access, detecting tampering and availability

issues. This methodology is demonstrated using three examples - the functioning of ECUs in a

modern vehicle, remote monitoring of IMD, and automatic payment system at the toll stations.

The security features are shown in the use case diagrams, class diagrams and sequence diagrams

without adding unnecessary complexities. Some new symbols are introduced to the existing

UML diagrams to denote the security aspects.

This proposed generic security profile can be enhanced to incorporate the implications of

the security features on non-functional requirements like time and cost. These implications need

to be considered during the design for security phase. They can also support the definition of

adequate test procedures to ensure security features. Further work can be done to show problem

78
detection methods in a more comprehensive way. Future work may focus on issues such as side

channel attacks, denial of service, buffer overflow, physical and logical probing by malicious

entities, etc. More embedded applications need to be designed using this proposed methodology

in order to integrate more security features into the entire embedded systems development

process.

79
REFERENCES

[1] R. Chen, M. Sgroi, L. Lavagno, G. Martin, A. Sangiovanni-Vincentelli, and J. Rabaey,

“Embedded system design using UML and platforms,” In Forum on Specification and Design
Languages, (FDL '2002), September 2002

[2] B. Selic and J. Rumbaugh, “Using UML for modeling complex real-time systems,” March
1998, Whitepaper Available: www.objectime.com

[3] Abdelouahed Gherbi and Ferhat Khendek, “UML profiles for real-time systems and their
applications,” in Journal of Object Technology, vol. 5, no. 4, May–June 2006, pp. 149–169,
Available: http://www.jot.fm/issues/issue_2006_05/article5.pdf

[4] OMG, “UML profile for schedulability, performance, and time specification”, Version 1.0,
formal/03-09-01, September 2003, Available: http://www.omg.org/spec/SPTP/1.0/

[5] Sébastien Gérard, Julio Medina, and Dorina Petriu, “MARTE: A new standard for modeling
and analysis of real-time and embedded systems,” ECRTS, July 4-6 2007, Pisa, Italy,
Available: http://www.omgmarte.org/node/28

[6] Sébastien Gérard, François Terrier, Bran Selic, and Pierre Boulet, “MARTE, the UML
standard extension for real-time and embedded systems”, [Online], Available: https://www-
users.cs.york.ac.uk/~burns/papers/MARTE.pdf

[7] Indira Jayaram, “Adding non-traditional constraints to the embedded systems design
process,” M.S. thesis, University of Cincinnati, 2011

80
[8] Craig Larman, "Applying UML and patterns: UML class diagrams", Informit, Nov 2, 2009,
[Online] Available: http://www.informit.com/articles/article.aspx?p=1398623&seqNum=9

[9] UML, (2016, February 3) [Online] Available: http://www.uml.org/

[10] P. Kocher, R. Lee, G. McGraw, A. Raghunathan, and S. Ravi, “Security as a new dimension
in embedded system design,” Proc. 41st Design Automation Conf. (DAC), pp.753 -760, 2004

[11] Jan Jürjens, "UMLsec: Extending UML for secure systems development," In ≪ UML≫
2002—The Unified Modeling Language, pp. 412-425, Springer Berlin Heidelberg, 2002

[12] Vinh Xuan Tran, Ninh-Thuan Truong, and Anne T. A. Nguyen, “An approach to the
specification of security concerns” in UML, Robot Intelligence Technology & Applications 2012,
AISC 208, pp. 801-807

[13] Peter Marwedel, Embedded system design: Embedded systems foundations of cyber-
physical systems, Springer Science & Business Media, 2010

[14] Bastian Best, Jan Jürjens, and Bashar Nuseibeh, “Model-based security engineering of
distributed information systems using UMLsec,” ICSE 2007, 29th International Conference on
Software Engineering, IEEE, 2007

[15] Matthew J. Peterson, John B. Bowles, and Caroline M. Eastman, “UMLpac: an approach for
integrating security into UML class design,” In SoutheastCon, 2006, Proceedings of the IEEE,
pp. 267-272, IEEE

[16] Mehrdad Saadatmand, Antonio Cicchetti, and Mikael Sjödin, “On the need for extending
marte with security concepts,” International Workshop on Model Based Engineering for
Embedded Systems Design (M-BED 2011), 2011

[17] Arnold S. Berger, “Chapter 1: The embedded design life cycle,” Embedded Systems Design:
An Introduction to Processes, Tools, and Techniques,
Available: http://www.globalspec.com/reference/28434/203279/chapter-1-the-embedded-design-
life-cycle

81
[18] B. Selic, G. Gullekson, and P.T. Ward, Real-Time Object-Oriented Modeling, John Wiley
and Sons, 1994

[19] Ralf Niemann, “Hardware/software co-design for data flow dominated embedded systems,”
Springer Science & Business Media, Oct 31, 1998

[20] Torsten Lodderstedt, David Basin, and Jürgen Doser, "SecureUML: A UML-based
modeling language for model-driven security," ≪ UML≫ 2002—The Unified Modeling
Language, Springer Berlin Heidelberg, pp.426-441, 2002

[21] Keith Barry, “Can your car be hacked? Hack to the future”, Jul 2011, [Online] Article
Available: http://www.caranddriver.com/features/can-your-car-be-hacked-feature

[22] Andy Greenberg, "Hackers remotely kill a Jeep on the highway with me in it," Wired, Jul
21, 2015, [Online] Available: http://www.wired.com/2015/07/hackers-remotely-kill-jeep-
highway/

[23] Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham,
Stefan Savage, Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno,
"Comprehensive experimental analyses of automotive attack surfaces," In USENIX Security
Symposium, 2011

[24] Karl Koscher, Alexei Czeskis, Franziska Roesner, Shwetak Patel, Tadayoshi Kohno,
Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and
Stefan Savage, "Experimental security analysis of a modern automobile," 2010 IEEE Symposium
on Security and Privacy (SP), pp. 447-462, IEEE, 2010

[25] “Wikipedia: Electronic control unit”, (Accessed: 29th Jan 2016),

Available: https://en.wikipedia.org/wiki/Electronic_control_unit

[26] Finetech Medical, [Online] Available: http://finetech-medical.co.uk/en-

gb/products/whatisfunctionalelectricalstimulation/whatisanactiveimplantablemedicaldevice.aspx

82
[27] “Breakthrough in medicine: Pacemaker can now be charged wirelessly,” [Online]
Available: http://mostepicstuff.com/pacemaker-can-now-be-charged-wirelessly/

[28] “Medical monitoring & remote programming,” [Online]

Available: http://medicalremoteprogramming.blogspot.com/2011/06/hacking-grandpas-icd-why-
do-it.html

[29] Marc Goodman, “Who does the autopsy? The criminal implications of implantable medical
devices,” [Online]
Available: http://www.slate.com/articles/technology/future_tense/2015/03/implantable_medical_
devices_hacking_who_does_the_autopsy.html

[30] Mehrdad Saadatmand and Thomas Leveque, "Modeling security aspects in distributed real-
time component-based embedded systems," 2012 Ninth International Conference on Information
Technology: New Generations (ITNG), IEEE, 2012

83