D.3.2 Threat Analysis

(1)

uTRUSTit

– Usable Trust in the Internet of Things

Project Reference: 258360

FP7-ICT (Area: ICT-2009-1.4 Trustworthy ICT)

Project Duration: 1 Sep 2010 – 31 August 2013

D.3.2 Threat Analysis

SEARCH-LAB

Final Version

Authors:

Dániel Petró (SEARCH-LAB) György Vesztergombi (SEARCH-LAB)

Lothar Fritsch (NR)

Version: 1.0 Date: 30/04/2011

Dissemination level: (PU, PP, RE, CO): PU

(2)

Abstract

The aim of the uTRUSTit project is to test and research user trust perception in the Internet of Things (IoT). Its two main outcomes are, on the one hand, a set of guidelines for development of trustable IoT and, on the other hand, a prototype framework demonstrating the project’s findings, called ‘Trust Feedback Toolkit’. The work behind them builds on current and foreseen IoT capabilities, an analysis revealing the major threats to the IoT, and the user feedbacks and tests, refining the results in an iterative manner. This document is a report on the threat analysis.

Setting off from the Definition of User Scenarios [D2.2], our goal was to reveal threats – i.e. events endangering the IoT from security and privacy point of view. First, assets were

collected, protection of which defines security in this context. Then, examination of use cases provided proper, while misuse cases revealed improper – possibly malicious – ways of usage, the latter leading to the threats themselves.

The scope of the analysis was on the threats that can be mitigated via user involvement. They should eventually be communicated to the user in a digestible way. Basis of this work is also outlined in this document, and will be carried forward through the specification and the implementation of the Trust Feedback Toolkit, also using the findings of the test phases. To be able to come to generally usable results, we created a general IoT architecture model, focusing on security. Not only did this model clarify the typical threats and the possible control objectives but also provided a reference to which future IoT threat analyses would be able to be aligned.

Consequently, this deliverable gives an essential input both to the Trust Feedback Toolkit and the trust-enhancing developer guidelines.

(3)

1. Introduction

1.1 Background

In the threat analysis phase we first identified and collected the assets (software, hardware and data) of the system using a systematic approach; assuring that security of the assets was the basis for further analysis.

Security objectives (requirements) were assigned to assets using the CIA (Confidentiality, Integrity, and Availability) model:

Confidentiality means that the asset (or information about the asset) must only be accessible by authorized parties.

Integrity means that the asset must not be modifiable; in case of software, it must not deviate from normal operation.

Availability means that the asset must be ready for use whenever it is needed.

Not all objectives are important for all assets. Where appropriate other security requirements

– missing from the CIA model – were pointed out (e.g.: non-repudiation1).

We began the threat modeling process by defining misuse cases – negative scenarios describing the ways the system should not work. We examined how the standard use cases defined in the [D2.2] document could be subverted, endangering the system’s assets. We then collected the threats discovered during the modeling process. From the threat descriptions we elaborated associated control objectives, focusing on those that required user interaction.

1.2 Scope of this Deliverable

This deliverable is part of Task 3.2 Security Implications. Security of IoT was approached using CIA (Confidentiality, Integrity, and Availability) analysis for determining relevant threats. Giving an appropriate technical answer tackling any identified threat is essential for security of IoT systems; therefore the goal of this task was to identify the threats and define the control objectives in a way that can be translated to users in a human-digestible way. Where occasion arose for user feedback it was brought to the fore. It is paramount to make these responses comprehensive and intelligible to the end user. As this will be covered in detail in further deliverables we restricted ourselves to pointing out these opportunities. Our main focus lay on threat identification and assessment.

1_{Non-repudiation refers to a state where the maker of a statement or document will not be able to deny the} validity of it.

(6)

1.3 Overview

Threats can be determined as incorrect behavior or usage of a system, endangering security or privacy of it or the data it handles. This document collects typical threats to the Internet of Things, and suggests control objectives that are tied to user involvement and user trust

perception. Our main input is the Definition of User Scenarios [D2.2], demonstrating typical use case examples, thus providing major security issues that commonly arise.

In Chapter 2 (Security Objectives) we collect assets, i.e. parts of the IoT that are most likely to be targeted by malicious attackers. Then, in Chapter 3 (Security Model of the IoT) we compile the common properties of the assets found and the redundancies of the foreseen related measures to create a general security model for the IoT. The assets are complemented in the threat modeling parts (Chapter 4 and 5 – Generic IoT Threat Modeling and Scenario Specific Threat Modeling) by use cases (meaning normal usage and behavior of a certain system) and misuse cases (abnormal usage and behavior of the system, typically as a part of an attack). We then derive the threats and define control objectives for mitigation in Chapter 6 (Collected Threats and Control Objectives) and finally lay down the basis of adaptation of our results to the uTRUSTit Trust Feedback Toolkit. The document then concludes with summarizing the benefits and future usability of the findings.

(7)

2. Security Objectives

The goal of this section is to unveil the assets that are to be protected in each scenario case. Assets are identified to drive the analysis process and provide guidance to the specification of security requirements in order to investigate threats [SAMM]. We differentiate four kinds of assets: data assets, software assets, hardware assets and miscellaneous assets. For practical reasons, we first identified the assets in each sub-scenario then grouped them under the scenarios where they belong. We analyzed potential threats and security problems in relation to the assets. During this process it turned out that findings – uncovered in one scenario – applied to multiple scenarios and could be subjected to generalization.

2.1 Assets of the Smart Home Environment

The Smart Home Environment is a subset of the IoT, localized in space, providing services in a household. Devices in the Smart Home are federated into a network and furnish means for entertainment, monitoring of appliances, controlling of house components and other services. Each sub section will elaborate one particular application domain that may be encountered in this environment.

2.1.1 Scenario 1: Trusted Smart Home Services

Assets relating to smart door entry and exit management (including surveillance camera); medicine management and control; and movement tracking are presented in this section. A detailed description of this and further scenarios can be found in [D2.2].

2.1.1.1 Data Assets

Sensitive user data can take several forms:

 Data stored on the end user devices (such as the content of address books), or

 Data typed by the user (such as phone numbers or SMS messages);

 Data stored in databases (such as personal data of ticket purchasers);

 Data transmitted over a communication medium (such as location data).

Such data may be valuable and important to the user.

Passkey

The passkey grants the Smart Home’s owner and authorized persons access to the apartment.

 Confidentiality: The passkey must be protected: it must not be accessible by anyone unless

authorized by the user.

(8)

 Authentication:

o The passkey must be linked to an uTRUSTit device’s owner by some means, in order

to ensure that only authorized persons may enter the residence. This can be ensured by biometrical authentication or by requiring an additional PIN code that must be supplied on key operations.

o Upon key revocation and key reissue, care must be taken to avoid issuing a key to

an unauthorized person. This consideration stems from the scenario where a caretaker loses a key and requests a replacement. By resorting to social

engineering, the passkey issuer may be targeted using a “spear phishing” attack tricking him to issue a key to a malicious adversary. The adversary may impose as a caretaker who lost his keys.

Location Data Gathered by Tracking

Location data provide information on the whereabouts of the device to a system or a third party that processes them. Location data are usually GPS coordinates of the device itself, but can also be derived from known distances from points previously located. As a device with the capability to transmit location data (e.g. mobile phone) can often be associated with one person (its owner) the information has high relevance to privacy issues.

 uTRUSTit device’s location data: Locations arising from tracking the device displacement

should be protected from unauthorized access.

Camera Feed

Cameras are common parts of security systems, and are usually installed near entrance gates or doors to monitor people entering or leaving. The provided picture and the recorded footage are instrumental in preventing residents or users of a building from unwanted visitors.

Consequently, protection of camera feed has both relevance to privacy and security.

 Confidentiality: Camera feed must be kept from unauthorized eyes.

2.1.1.2 Software Assets

Beside data considered as sensitive, security measures may also relate to software, protection of which are important to maintain desired security and privacy. Often, software assets mean nothing else but the security system functionality itself, integrity of which is of high

importance.

Medical Cabinet Inventory and Medical Records

In [D2.2], an intelligent medical cabinet is introduced, which stores and keeps track of the medicines of its users. Wide usage is expected of such services in the future, however, they bring up issues of protecting sensitive data, and the software that handles it.

 Confidentiality: Privacy of medical cabinet inventory data must be protected. Only

(9)

 Integrity: Tampering by unauthorized personnel and corruption of data must be avoided. Corruption of inventory may further lead to malfunction of the Medical Cabinet, and may induce it to dispense wrong types of medication.

 Availability: Deletion of database or unavailability due to denial of service (DoS) [DOSRFC]

attacks must be avoided.

Camera Driver Software

To maintain the integrity and confidentiality of the camera feed, camera driver software must also be protected.

 Availability: Camera feed must be available – the user should be informed about its status.

 Integrity: Camera driver software must not be compromised.(Exploit scenario: replay

attack2)

 Authentication: Only authorized persons shall be able to access the camera for

configuration.

Smart Door Driver

Compromising the door’s driver software may lead to abnormal behavior or denial of service of the door.

 Integrity: Integrity of smart door needs to be protected.

2.1.1.3 Hardware Assets

Similarly to software assets, improperly protected hardware can also serve as an entrance point for attackers.

Surveillance Camera

Camera hardware protection must fulfill the following requirements:

 Integrity: Tampering must be avoided.

 Availability: Disabling or otherwise blocking of signal must be avoided.

Door Control Mechanism

Smart door’s hardware protection must fulfill:

 Integrity: Compromising door locking and door status detection mechanism must be

avoided.

2_{In this case replay attack means recording footage of a legitimate visitor, which is later played back to deceive} the user when an unauthorized entry is attempted.

(10)

2.1.2 Scenario 2: Trusted Smart Home Entertainment Management

In the Smart Home Entertainment section of [D2.2], a media center is described, which is used by each member of the family owning it. Common usage of the media center needs proper access control and data protection. Below are described the associated assets.

2.1.2.1 Data Assets

Media Player Content (audio/ video/games)

The content uploaded to the media player must fulfill the confidentiality requirement:

 Confidentiality: Data stored on media center must be protected from disclosure. This

includes protection of the directory system and the content of the stored files. An access control policy must be enforced to regulate access to system resources.

Access Control Credentials

The media center may be controlled by obtaining appropriate credentials.

 Integrity: delegated credentials must be protected from tampering.

Access Control Management Subsystem

The credentials are delegated via the Access Control Management Subsystem.

 Authentication: Only authorized users shall be able to delegate access rights for the media

center.

Media Controller

The media center is controlled using the media controller.

 Authentication: Only authorized users shall be able to control the media center.

2.1.3 Scenario 3: Inventory of Things in the Smart Home

The Inventory of Things is a service enabling the user to monitor every device and data flow in a Smart Home, including internal and outbound communication. It is an important and

practical feature which also enhances user trust perception significantly.

2.1.3.1 Data Assets

Outgoing Data

Managing privacy properties of outbound data flow, while keeping device functions operational, means an important privacy challenge.

(11)

 Confidentiality: Data stored on devices of the Smart Home federation3 must be protected. Outbound communication is only permitted to authorized partners. The number and type of devices residing in the Smart Home federation must be kept confidential.

2.2 Assets of the Smart Office Environment

The second major domain of use case scenarios is the Smart Office Environment. The Smart Office brings in a more complex access privilege and confidentiality structure, complemented by the idea of uncontrolled environment, where we will know little about the trustworthiness of the devices.

2.2.1 Scenario 1: Project Meeting

In the project meeting scenario, a meeting room is present where local and remote

participants negotiate. The room is fully equipped with intelligent devices that assist typical tasks in the course of the meeting: including remote participants, printing handouts or projecting presentations held locally or remotely.

2.2.1.1 Data Assets

Smart Office Data

Offices typically handle a great deal of confidential information. Security measures must fulfill the following criteria:

 Confidentiality: Confidentiality of office data must be protected.

 Integrity: Integrity of the data must be kept.

 Authorization: Access control to data objects must be enforced. Only authorized users may have access to office data.

Personal Contact Information of Project Participants

Raising privacy issues typically, personal contact information security must fulfill:

 Confidentiality: Data Fragments of the personal profile must be protected. Only fragments selected by the profile owner may be visible to authorized partners.

Smart Pen Content (Secure Notes)

Smart pen, which represents a typical device in the Smart Office, holding sensitive data, must also meet the confidentiality criterion:

3

(12)

 Confidentiality: Contents stored on the smart pen must be protected. Only transmission to “paired” (i.e. associated via a code exchange) devices shall be allowed.

Context Assigned to Project Participant

The context is a set of access privileges assigned to a user for a given time period. Access may relate to devices, services, entrances in an office that are restricted to privileged users. Context raises the following security problems:

 Confidentiality: Confidentiality of context data must be protected.

 Integrity: Context must be protected from corruption.

 Elevation of Privilege Threat: Malicious visitors should not be able to obtain higher access privileges by tampering with the context descriptors.

Shared Data (Remote Participant’s Work Area)

An office project meeting may involve participants who connect and hold presentations remotely. To display files (e.g., presentation slides) residing on the remote participant’s laptop to the other meeting participants, data sharing is required. The work area where the remote participant holds its files must be protected conforming to the following criteria:

 Confidentiality: Confidentiality of the work area must be maintained, unauthorized copying must not be allowed.

 Integrity: Work area must be protected from corruption.

 Authorization: Only operations conforming to a security policy may be performed on the shared data object.

Location Data/ Tracking History/ Position Data

Similarly to the Smart Home scenario, location data raises privacy issues and thus should fulfill the following:

 Confidentiality: Logging history (smart doors) should only be stored if allowed by tracked person. Private data related to persons should be kept confidential and not logged without authorization

2.2.2 Scenario 2: Smart Break Room

The smart break room represents the uncontrolled environment where, as opposed to the Smart Home and the Smart Office’s meeting room, the devices are of different, possibly untrustworthy origins (e.g., vending machines in a metro station). This field therefore presents a special case from security point of view, and will be represented by a break room at the office with different vending machines placed therein. A high emphasis will be put on e-payment, being a typical and critical problem area in the situations covered in this section.

(13)

2.2.2.1 Data Assets E-payment Account

Effective security management of account data has high influence to user trust perception.

 Confidentiality: Confidentiality of account data must be protected.

 Integrity: Balance and transactions must be protected, both from malicious users on the inside, as well as attackers from the outside trying to effect transfers to their own advantage.

The main software components in this scenario are the e-payment applications on the uTRUSTit device and the vending machine software communicating with each other.

E-payment Client on uTRUSTit Device

 Integrity: The software component responsible for e-payment must be protected.

E-payment Application on Vending Machine

 Integrity: The software application responsible for handling e-payment transactions must be protected.

2.2.3 Scenario 3: Inventory of Things in the Smart Office

Same consideration apply here as in section 2.1.3 describing Inventory of Things in the Smart Home.

2.3 Assets of the E-voting

A community, described in the e-voting scenarios [D2.2], employs this technology to reach a common consensus. Several aspects of e-voting are explored, that include delegation of voting rights and voting from a remote location in the scenario descriptions. In addition to typical security objectives, a number of other requirements need to be considered special to this application domain. The relevant assets are enumerated in the following sub-sections.

2.3.1 Scenario: E-voting system for Owners of Apartments in an

Apartment building

Only registered users are allowed to vote. Only one vote is admitted per person, but multiple delegation of voting credentials is possible. The voting database should be auditable, in the sense that it should be possible to prove that voting policy has been adhered to it. Additionally, voting should be anonymous. Information linking a vote cast to a voter should not be

(14)

2.3.1.1 Data Assets Voting Credentials

Voting credentials play a role in delegating voting rights to another person. From user

scenarios it can be elicited that voting rights can be transferred by people entitled to take part in the voting process. Once voting credentials have been transferred, the recipient is allowed to retransfer voting rights to a third party. This establishes a chain of credentials. The person at the terminal link of the chain can prove his entitlement at the voting station by presenting this chain of credentials.

Tracking of credentials could be for example implemented using digital signatures. The originator could generate a certificate stating that he transfers voting rights to his chosen candidate, and then sign it digitally.

 Integrity: Integrity of voting credentials needs to be protected. Failure to adhere to this

security objective may result in spoofing attacks.

 Non-repudiation: Voting credentials should be protected against repudiation attempts. I.e.,

the fact that credentials were transferred should not be deniable.

Cast Vote

 Confidentiality: Anonymity of voter must be protected, in the sense that his choice should

be kept secret.

 Integrity: Integrity of cast vote must be protected, ruling out falsification of voting results.

Voting Application

The voting application accepts votes from registered participants either from a local terminal or over a secured remote connection. It checks voter credentials, accepts the vote, enforces the voting policy and stores the result in its database.

 Integrity: Integrity of this resource must be protected.

 Confidentiality: Confidentiality of databases of this application must be guaranteed.

 Availability: The availability of local and remote voting service needs to be guaranteed.

Remote Voting Client

This application is used for voting remotely. It needs to be installed on the user’s device. First it contacts the remote voting server then it authenticates the voter. Upon successful

authentication it downloads the ballot, which the user is then able to inspect. Finally it transmits the cast vote back to the server.

 Integrity: Integrity of remote voting client must be protected.

 Availability: The system must not fail during voting.

(15)

2.3.1.3 Hardware Assets Voting Terminal

This device is used for voting in person. The voter interacts directly with this device. The terminal displays the ballot, and registers the choices. The cast vote is transmitted to the voting application.

 Integrity: Integrity of voting terminal needs to be protected.

 Availability: The voting terminal should be available during the vote.

2.4 Conclusion

In this chapter we performed an analysis of the data, software and hardware assets for the different use case scenes and scenarios. These assets are expected to be the main targets of a malicious attack.

The following step in a classic threat analysis is threat modeling which builds on the identified assets and derives the use cases (appropriate usage) and the misuse cases (inappropriate usage, exploiting assumed or real vulnerability of the system) that finally lead to threats. However, to achieve generally applicable results, we need an architectural model of the IoT that goes beyond current IoT implementations. As this chapter already revealed a high redundancy between the different threats and protective requirements, there is a good basis to build such a model upon. We expect it to also be a useful abstraction for future, yet unseen forms of the Internet of Things.

(16)

3. Security Model of the IoT

Analysis of the scenarios produced a set of common features that appeared in most scenarios. In this section we will present a model characterizing the IoT from a security perspective. The scenarios worked out in the document [D2.2] envision the possible applications of the IoT that may be of relevance in the near future. In order to analyze these systems, some architectural assumptions must be made about them. Since no predefined IoT architectural model exists to date that encompasses all possible application domains, we need to use an architectural model that is general and non-restrictive for our investigations.

Figure 1 – Security model of IoT

(the inferior numbers show the way of delegated credentials)

Our primary concern is with security and trust, so the presented model only describes the IoT from the security perspective. We tried to make the security assumptions explicit that were implicit in the D2.2 scenarios [D2.2]. The basic actors and interactions were abstracted and formulated into one model.

We further assumed that security mechanisms deployed in the IoT will follow and extend classic security design principles as described in [SALTZ].

(17)

3.1 Elements of the IoT

In this section every element of the security architecture presented in Figure 1 will be presented and explained in detail. The possible interactions between these elements will be described in Section 3.2: Operation Primitives.

3.1.1 IoT Federation

The central element is the IoT federation, analogous to private clouds [SECLOU], which consists of a set of IoT enabled devices connected into a sub-network. Networks are delimited by a trust boundary, formed by sharing a circle of trust or by linking to a chain of trust. They form a local network of things, associated with a person, location or a facility. Some of the resources might be shared among many users with loosely overlapping or distinct trust roots. Prominent examples featured in the D2.2 scenarios are the Smart Office and Smart Home.

3.1.2 Shared Resources

The shared resources that are managed by the federation stake holders reside inside the federation. Shared resources may be data structures or services provided by the federation. Examples of shared data:

 Contact lists;

 Medical records;

 Presentation files of remote worker;

 Contents of secure pen.

Shared services are exemplified by:

 Smart door unlocking mechanism;

 Printer, Projector in the Smart Office.

Access to shared resources is regulated by a security policy down to a fine granularity.

Visibility, read-write authorization and specific sets of operations regulate interaction with the shared resources. Only entities with appropriate credentials may interact with shared

resources and only in specific authorized modes.

3.1.3 Credentials

Access to shared resources requires appropriate clearance levels. Operations requiring a higher clearance level require authorization from the federation owner. Authorization may be granted by giving credentials. In some use cases it is permissible to further delegate access privileges to another party. The credentials are part of the context managed by the uTRUSTit device.

3.2 Operation Primitives

(18)

 Access Privilege Delegation/ Revocation: Entities are granted access rights to protected resources and services. These rights are implemented as credentials which must be safeguarded by the entity. Presenting the credentials enables the entity to carry out operations inside the trust boundary. Some applications allow the outside entity to delegate access rights to a third party. For example the passkey to a smart door embodies an instance of an access privilege which may be shared by multiple persons.

The inverse operation of granting access rights is access revocation. After revocation the access privileges are no longer valid and cannot be used to gain access.

 Authentication: In order to gain acceptance by a federation, or to access shared resources proof of identity may need to be presented. The entity presents proof of its identity which is validated by a federation component. If the provided proof is satisfactory the entity is recognized by the system.

 Connecting to a Federation: This operation is performed when a device gains acceptance into a federation and is granted a specific set of credentials that regulate its interactions with the rest of the federation. Connecting a secure pen to a smart phone, enabling transfer of data, is an example. The two devices constitute a federation.

 Shared Resource Access: Reading and writing data to a shared resource, or performing operations on a shared resource are abstracted by this operation primitive.

(19)

4. Generic IoT Threat Modeling

In this section potential threats endangering the general IoT architecture are enumerated. Every basic operation, introduced in section 3.2, is analyzed for weaknesses. Use cases and misuse cases are employed to illustrate and model threats for security investigations [MUC]. Use cases describe the normal flow of events that the user encounters most of the time. Misuse cases are based on use cases and strive to describe execution flows that differ from regular patterns.

The actors appearing in the use cases and misuse cases are introduced in the listing below:

 Infrastructure or federation owner: The person responsible for managing the infrastructure

or permanent federation that is referred to in the use case. Specific examples are smart homes and smart offices.

 IoT entity: Components of an IoT network are denoted by this general term. IoT entity may

refer to an IoT enabled device, such as a smart phone or to a software component providing a service in an IoT network.

 Misuser: A person that is using the facilities of an IoT system in unexpected, non-standard

ways. The intentions of a misuser may be either benign, his or her actions resulting from lack of familiarity or accident, or malicious. In the latter case he or she may intentionally try to make use of unexpected behaviour to gain some advantage.

 Exploiter: A person with significant technical knowledge and hacking skills, intent on

subverting a protected system.

The following sections will go through common use cases. One or more misuse cases will be presented for each, detailing an alternate execution flow, deviating from the intended use of the original use case.

4.1.1 Access Privilege Delegation / Revocation

These operations deal with issuing and revoking access rights to protected resources and systems. Granting of voting credentials, passkey issuance and granting of access rights are common examples.

The inverse operation is revoking this access privileges. Revoking invalidates previously granted access rights.

4.1.1.1 Use Cases

Name Access Privilege Delegation

Description Actor delegates privileges to third party

Precondition Actor has access delegation privilege

(20)

Actor creates delegated credentials Actor issues credential

Actor Federation owner or party owning delegated credentials

4.1.1.2 Misuse Cases

Name Delegation from unsafe location

Description Actor issues passkey remotely over unsafe network connection

Precondition Actor has access delegation privilege themselves

Assumption Exploiter is able to eavesdrop on key delegation protocol

Actor Exploiter

Assets Delegated access credentials

Name Access rights granted to unauthorized candidate

Description Misuser is granted access rights by the federation either by way of

delegation or directly

Precondition Delegator has sufficient privileges to perform this operation

Assumption Misuser is able to impersonate a legitimate access requesting

entity

Actor Misuser

Name Credential corruption

Description Credentials are corrupted by exploiter to gain extra privileges

Precondition Exploiter receives access credentials from authorized source

Assumption –

(21)

Name Forced access revocation

Description Access issuer is tricked into revoking legitimately granted access

rights

Precondition Misuser is able to contact access issuer

Assumption –

Actor Misuser

4.1.2 Authentication

During the authentication process credentials are checked in order to grant access to protected resources and services. A widespread form of authentication involves entering a login name and passphrase. More sophisticated opportunities include biometric checks and public key infrastructure based protocols employed, for providing proof of identity.

4.1.2.1 Use Cases

Name Authentication procedure

Description Entities (devices) situated outside of the trust boundary need to

authenticate themselves to access protected resources

Precondition Actor was granted access credentials and is able to access the IoT

system

Success flow

 Actor presents access credentials

 Credentials are checked by a system component

 If credentials are valid, access is granted

Actor IoT Entity

4.1.2.2 Misuse Cases

(22)

Description Actor attempts to access resource with malformed access credentials.

Precondition Actor is able to address the shared resource

Assumption –

Actor Misuser

Assets Shared Resource

Name Resource profiling

Description A federation resource profiles authentication transactions to build

a profile of movements and service usage

Precondition

 Parts of the resource network run profiling software

 The authentication token is linkable to prior transactions

Assumption –

Actor Misuser or owner of resource infrastructure

Name Unnecessary identification

Description The actor’s identity leaks out upon an authentication or

interaction with resources or infrastructure

Precondition

Actor is able to address the shared resource. Actor has identifying credentials or implicitly identifying information (device ID, MAC address, etc.)

Assumption –

Actor Misuser or infrastructure owner

4.1.3 Shared Resource Access

(23)

accessible. Most operations in the IoT may be formulated using this concept: sending data to a printer, using e-payment, exchanging contact information are some prime examples.

4.1.3.1 Use Cases

Name Shared resource

Description Actor performs operation on shared resources

Precondition Actor is in possession of required access credentials

Success flow

 Actor authenticates himself at the component responsible for

protecting this resource

 Actor requests access to one or more shared resources for a

specific operation

 The access controller checks if operation is valid

 Operation is allowed to proceed

Actor IoT Entity

4.1.3.2 Misuse Cases

Name Unauthorized shared resource operation

Description Actor executes unauthorized operation on a shared resource

Precondition Actor is able to access that shared resource

Assumption –

Actor Misuser

Name Unsecure network access

Description Actor accesses a shared resource over unsecure connection

Precondition Actor has access privileges to that shared resource

Assumption –

(24)

4.1.4 Connecting to a federation

The process of adding a device to a network of IoT devices, sharing a circle of trust, is termed federation. After federation the device is able to interact more closely with other members in the federation. Example: Remote worker connects to a Smart Office infrastructure. After federation office services – printer, projector, etc. – become accessible.

4.1.4.1 Use Cases

Name IoT Device joins a federation

Description An IoT device (e.g. laptop, smart phone, secure pen) is joined to a

federation.

Precondition –

Success flow

 The identity of the device is established

 The federation checks the credentials of the joining device if

necessary

 If it is deemed fit to join the federation, the device is handed a

set of credentials that allow it to perform operations on a set of federation owned resources

Actor IoT Entity

4.1.4.2 Misuse Cases

Name Connection attempt with improper authentication

Description

Actor attempts to subvert authentication checks by

 Imposing as another entity

 Using malformed authentication credentials

The actor’s goal is to gain acceptance for his device by the federation as a legitimate entity

Precondition Actor reaches the authentication interface of the cloud

Assumption –

(25)

Name Federation attempt over insecure communication link

Description Actor attempts to connect to the IoT federation over an

unsecured connection

Precondition Actor disposes over valid connection credentials to the IoT

federation.

Assumption –

Actor Misuser

Name Confusion of federation candidate

Description

The actor attempts to join a device to the federation, but confuses the device with another candidate. The federation invitation is sent to the wrong device as a result

Precondition Multiple devices are available for selection

Assumption –

Actor Federation owner

General misuse cases to the IoT have been scrutinized in this chapter. Threats derived from this analysis will be summarized in chapter 6 along with threats collected by examining specific scenarios in the following chapter.

(26)

5. Scenario Specific Threat Modeling

The use cases described in this chapter are taken from scenarios described in [D2.2]. Misuse cases that are already covered by general IoT misuse cases are not covered in detail. Only a reference to the generalized case is given. To gain an overview on which threat applies to which scenario, consult the overview matrix given at the end of Chapter 6.

5.1 Threat Modeling in the Smart Home Environment

This section encompasses scenarios occurring in the Smart Home environment. Smart door entry and exit management, medical cabinet management and control, and management and control of IoT networks connected to a Smart Home are examined.

5.1.1 Smart Door

The smart door extends traditional door functionalities with remote controlling ability and the capability to grant access to persons providing a passkey. Furthermore it is linked with a location tracking device that can be activated upon leaving the Smart Home perimeter.

5.1.1.1 Use Case for Smart Door Authentication

Name Smart door authentication

Description Visitor enters apartment using passkey

Precondition Visitor has a valid passkey

Success flow

 Visitor presents his entry credentials to the smart door

 The smart door controller authenticates the visitor

 The smart door controller unlocks the door

Actor Visitor (e.g. healthcare personnel)

5.1.1.2 Misuse Case for Smart Door Authentication

Name Passkey disclosure

Description

Healthcare personal tries to enter another unrelated smart door using the passkey, thereby disclosing information about it to a third party

(27)

door

Assumption –

Actor Misuser

Assets Passkey

5.1.1.3 Use Case for Door Locking Mechanism

Name Door lock check

Description Door lock checking mechanism safeguards the smart door

Precondition –

Success flow

 Door lock mechanism checks status

 If left open transmits notification

Actor Infrastructure owner

5.1.1.4 Misuse Case for Door Locking Mechanism

Name Door left intentionally open

Description Actor intentionally leaves door open

Precondition –

Assumption –

Actor Misuser

Assets Door Control Mechanism

5.1.1.5 Misuse Case: Denial of Service

Name Denial of Service against smart door

(28)

Precondition Attacker is able to access smart door driver

Assumption –

Actor Insider

Assets Smart Door Driver

5.1.2 Surveillance Camera

The surveillance camera is part of the security perimeter, protecting the Smart Home

environment. Working in conjunction with the smart door it monitors visitors appearing before the smart door requesting admittance.

5.1.2.1 Use Cases

Name Surveillance Camera

Description Video feed of surveillance camera is used for remotely admitting

unexpected visitors

Precondition Actor has access to video feed

Success flow

 Visitor rings the bell

 Actor confirms visitor’s identity visually

 Actor admits visitor

Actor Smart door owner or trustee

5.1.2.2 Misuse Cases

Name Video Feed unavailable

Description

 Video feed is unavailable due to some malfunction of a system

component. Malfunction may arise from:

o HW/SW defect

o Tampering

o Denial of Service (DoS) Attack

(29)

Assumption –

Actor Misuser

Assets Surveillance camera, camera feed, camera driver

Name Unsecured camera feed

Description Camera feed is transmitted over unsecured channel

Precondition –

Assumption Eavesdropper is able to listen in on wireless communication or

otherwise tap the transmission

Actor Exploiter

Assets Camera feed

5.1.3 Medical Cabinet

Most threats pertaining to the medical cabinet revolve around the issue of protecting the privacy of the medical cabinet’s owner, by keeping the medical record safe. The most serious issues that may arise are safety related in nature and are considered out of scope for this evaluation. We will not consider sabotage by caretakers, deliberate confusion of medicaments or denial of service due to physical malfunction of the cabinet.

The medical record that is available implicitly by accessing the inventory of the medical cabinet constitutes a shared data resource in the Smart Home federation. Only actors with explicitly granted privileges may access it from the outside. All the threats regarding

delegation/revocation and shared resources outlined in sections 4.1.1 and 4.1.3 apply.

5.1.4 Location Tracking Information

Location tracking information is a shared resource belonging to the owner of the tracking device. The threats relating to the delegation of the access rights are general and are covered in section 4.1.1. General threats related to access of shared data are covered in section 4.1.3. Specific threats in this scenario relate to information leakage resulting from monitoring the traffic flow.

5.1.4.1 Use Cases

(30)

Description Tracking device periodically transmits position data

Precondition –

Success flow

 User leaves Smart Home

 Notification service is activated after preset threshold

 Location data is periodically transmitted to registered listeners

Actor Smart Home resident

5.1.4.2 Misuse Cases

Name Side channel information leakage

Description By monitoring the shape of the outgoing data traffic an attacker

can infer that the Smart Home owner has left the residence

Precondition Attacker is able to monitor data traffic between tracking device

and listeners

Assumption –

Actor Insider

Assets Location data

5.1.5 Trusted Smart Home Entertainment Management

The trusted Smart Home Entertainment Management center is a classic example of an access control system from a security perspective and fits the federation security model elaborated in Chapter 3. Authorized users are entitled to certain operations on shared resources if they possess appropriate clearance levels. For example a guest may have control over the Media center’s play functionality, and may have the ability to play music from a mobile device. On the other hand the guest may lack access to private data stored on the center.

Clearance levels are delegated using the general model described in section 3.2, dealing with IoT operation primitives.

5.1.6 Inventory of Things

Every device constituting the IoT federation of its owner is by default an asset that needs to be protected because of privacy considerations. The number of devices, their type and every piece of information leaving the federation boundary are to be kept private. Furthermore, shared resources hosted by the federation are also part of the list of entities that need to be kept

(31)

private by default, unless otherwise specified. Exempt from this requirement are devices whose main function requires them to be publicly visible and reachable.

Devices making up the IoT can be generalized as shared resources themselves in our security model. The specific threats in this area are:

 Unauthorized data transmission by IoT entity;

 Unauthorized access by outside entities.

Other general threats affecting shared resources are covered in section 4.1.3.

5.2 Threat Modeling in the Smart Office Environment

The Smart Office constitutes an IoT enabled environment, where traditional workplace

functionalities are facilitated by intelligent devices. Threats arising in such an environment are modelled in the following sub-sections.

5.2.1 Entry and Registration for the Meeting

In this scenario the participant is handed a context which is a synonym for credentials in our general security model. Using the credentials the participant obtains the means to use

components of the Smart Office infrastructure. Components map to shared resources, and the joining of the mobile device of the participant is an example of federation.

Threats relating to this scenario are identical to the general case described in section 4.1.4, dealing with connecting to a federation.

5.2.2 Exchanging Data with Other Project Members

Project members exchange contact information in this scenario. In this case the contact information is the shared resource that needs to be protected on the participant’s mobile device. Trusted parties are granted read access rights by credential delegation.

General threats pertaining to shared resource access and credential delegation are covered in section 4.1.1 and 4.1.3.

5.2.3 Connecting to the Smart Office Infrastructure

The participant makes use of the office infrastructure by connecting to the network and accessing the printer. Shared Resource access based on issued credentials is demonstrated in this scenario. Relevant threats are covered in section 4.1.3.

5.2.4 Remote Worker Connects to the Infrastructure

Observed from a higher architectural level no qualitative difference exists between the local and remote worker. Identical interfaces are used for credential checking and shared resource

(32)

access. Only the transmission medium is slightly modified. Instead of using only a local network, part of the data travels over public internet conduits.

The case where the remote worker uses the projector but does not want to back-up his or her file is also an example of shared resource usage. In this case the shared resource is part of the remote worker’s federation. The projector may access this data for presentation, but may not use it for other purposes, i.e. backup. Of course this requirement cannot be enforced by technological means, the remote worker has to place trust explicitly into the Smart Office infrastructure.

General threats relating to federation, delegation and shared resource access are discussed in section 4.

5.2.5 Taking Secure Notes

Most use cases arising in this scenario have been covered by the analysis described above. A major portion of the description is dedicated to the pairing of an uTRUSTit device and smart pen. This process is a modality of federation covered in section 4.1.4.

5.2.6 Smart Door

Smart office users are able to navigate the office complex by passing through smart doors. Communication is handled by uTRUSTit devices with the smart doors. If the presented credentials are satisfactory then the user is allowed to proceed.

Each door owns a counter which logs information about persons passing through them. In our model this corresponds to a shared data object owned by the Smart Office federation. From a security perspective no new issues arise. If the user has proper authorization he or she may modify the door’s settings to omit his actions from the data log. Related threats are covered in section 4.1.3.

The concern here is that the privacy of the user may be endangered by the logging mechanism.

5.2.6.1 Use Cases

Name Smart door counter

Description Smart doors logs passage events if not instructed otherwise.

Precondition –

Success flow

 Smart door is in logging state

 Office user instructs it to refrain from tracking his movement

(33)

Actor Smart door

5.2.6.2 Misuse Cases

Name Privacy breach

Description

Smart door logs user events:

 Either in spite of being instructed to do so

 Or because the office user is unaware of the privacy breach

Precondition User is free to navigate certain areas of the office complex

Assumption –

Actor Malicious office

Assets Private location data

Note that this misuse case is a special case of Resource Profiling detailed in section 4.1.2.

5.2.7 Smart Break Room

Communication takes place via NFC (Near Field Communication) between the purchaser’s mobile device and the vending machine. Communication between the banking software, vending machine and user’s device can make use of any arbitrary communication link.

Assuming that cryptographically sound technologies were employed to implement the system components, the major worry is the reliability of the vending machine [MULL08]. The

purchaser has to place trust into the vending machine that the right amount of money will be billed.

As mentioned in the Security Objectives chapter, integrity of transactions is also an important prerequisite for proper usage and user trust perceptions. The uTRUSTit project however focuses on threats that can be mitigated via user involvement, and as there are numerous solutions that already guarantee transaction safety, we assume that it is handled by commonly used standard procedures.

5.3 Threat Modeling in E-voting

Threats pertaining to the e-voting scenarios are elaborated in the following sub-sections. Multiple scenarios dealing with different aspects of e-voting are examined. Voting rights

delegation and remote voting cases are considered. Most security relevant facets coincide with those described in Chapter 4:Generic IoT Threat Modeling. These will be pointed out where

(34)

5.3.1 Voting for Someone Else

Transfer of voting rights is a special case of the general operation of delegating credentials. Threats relating to the general case of delegation and revocation are modeled in section 4.1.1.

5.3.2 Voting from Abroad

In this scenario the remote voter downloads an e-voting application from a location specified by the voting board.

Apart from general security considerations that arise from accessing shared resources (see section 4.1.3) another threat – modeled by a misuse case – needs to be considered (see below).

5.3.2.1 Use Cases

Name Installing e-voting application

Description Voter installs e-voting application

Precondition –

Success flow

 Voter is notified by the voting committee

 Voter downloads the application

 Voter installs the application

Actor Remote voter

5.3.2.2 Misuse Cases

Name Forged e-voting application

Description

Attacker sends an e-mail to remote voter in which he

impersonates the voting committee and supplies an alternative download location for the voting application. (This way he may be able to infect the remote voter’s machine with malware.)

Precondition Attacker is in the loop of the voting process and has knowledge of

the remote voter’s e-mail address

Assumption –

Actor Exploiter

(35)

5.3.3 Voting on the Options from Abroad

Two devices are involved in this scenario on the remote voter side. They are employed to determine and double-check the voting outcome. In order to accomplish this task the devices are required to exchange confidential data. The ballot is managed by a primary device running the e-voting application, but is transferred for closer inspection to a second device equipped with accessibility features. General threats pertaining to access and handling of shared resources are already covered in section 4.1.3.

5.3.4 Voting on the Options Locally

From a functional or security perspective this scenario is similar to the previous one. Data is exchanged between devices for accessibility reasons and credential delegation is at play enabling voting of an emissary.

As an introductory step, the voter checks the integrity of the voting terminal. Self-diagnosis is an important feature for such equipment but a feature the user has no additional control over.

(36)

6. Collected Threats and Control Objectives

The threats inferred in the previous chapters are enumerated below. General threats and specific threats are collected and presented in the list. Similar threats arising in different scenarios were merged. Control Objectives for threat mitigation are listed for each threat respectively.

T1 – Delegation from unsafe location

Delegation or revocation of access rights is a critical operation that should be carried out over a safe communication link. When carried out over an unsafe network medium, employing weak protocols, attackers may be able to eavesdrop on the ongoing communication. Furthermore an advanced attacker may be able to channel the communication flow through his proxy and perform a man-in-the-middle attack.

 Network status should be monitored in order to detect unsafe environments.

 Strong encryption techniques should be employed to protect integrity of transmitted

data.

T2 – Access rights granted to unauthorized entity

Access rights may be granted or delegated to an unauthorized actor if an attacker is able to subvert the delegation process. One way to do this may be done through social engineering, by sending targeted e-mails requesting for access rights. Coupled with data-mining from social web sites and other attacks this method can be effectively employed, as is demonstrated time after time in the security news.

 Access rights should only be granted to actors after verification of their identity.

 Phishing filters should be installed to prevent users from visiting malicious websites

imposing as legitimate entities.

 If no formal verification of identity possible, then user should be alerted before

granting access rights.

T3 – Corruption of access rights credentials

Depending on the chosen solution used for representing access right credentials certain options become available for an attacker. If the credentials are stored only on the user’s device they may be subject to manipulation by a malicious user. This can be used to gain extra privileges by tampering with the credential’s data structure.

 A secure design should be used to implement credential storage. When applicable,

credentials should be stored on a dedicated server and not on the user’s device, to avoid tampering by the user.

 Otherwise integrity of credentials should be protected by cryptographic means.

T4 – Forced access revocation

The person responsible for access rights delegation may be tricked into revoking the access rights of a legitimate user. This may be done by technical means, if a formal protocol is in

(37)

place handling revocation requests. By subverting the protocol a revocation can be triggered. Revocation might also be obtained using social engineering.

This threat can be carried out as the first step of an attack. For example a message is sent by the attacker to the access issuer that the caretaker has lost his uTRUSTit device. The access issuer revokes the access rights of the caretaker thereof. The psychological groundwork for granting access to a total stranger is laid now, and the attacker is in position to ask for access credentials.

 Revocation requests should only be accepted from trusted entities after verification

of their identity.

 If the above procedure is not applicable, then the validity of the request should by

double checked using another independent secure channel.

T5 – Malformed authentication credentials

An attacker tries to subvert the authentication module by sending specially crafted data structures in hope of exploiting a vulnerability in the software implementation. The data may be malformed, too short, too long or containing invalid symbols.

 Security critical components should undergo security testing before deployment.

 Standard security libraries should be used to meet common security needs. This

approach should be preferred over custom implementations, as developing security critical components is expensive and requires specialized expertise.

T6 – Unauthorized shared resource operation

An outside entity or an inner entity of the IoT federation attempts to carry out an operation on a shared resource it is not entitled too. E.g. it may have only read access and attempts a write operation. If the access control mechanism is not implemented correctly the attacker may be able to circumvent the necessary checks.

 Total mediation should be used, meaning that before every resource access the

access rights should be checked. Performing this check only on logon or first use is insufficient, as access rights may change between two access attempts.

T7 – Shared resource access over insecure connection

Access of shared resources over insecure connections endangers the confidentiality of the data flow and enables data theft or man-in-the-middle attacks.

 Strong encryption techniques should be employed to protect integrity of transmitted

data.

T8 – Federation attempt with improper authentication

When an entity connects to an IoT federation (e.g. Entertainment Center, Smart Office visitor) and is issued credentials that enable it to access resources within the system, than

(38)

misusers imposing as legitimate parties may access protected data or perform actions requiring elevated rights.

 Federation requests should only be accepted from entities after verification of their

identity.

T9 – Federation attempt over insecure communication link

Federation over insecure network may lead to eavesdropping which may be exploited further for data theft or identity theft.

 Strong encryption techniques should be employed to protect confidentiality of

transmitted data.

T10 – Confusion of federation candidate

If a device needs to be connected to an IoT federation than the possibility of confusion arises. If multiple similar devices are in the vicinity with similar characteristics, then the wrong device can be picked by error. The connecting entity obtains unwarranted access rights to the system.

 NFC based federation protocols should be employed to minimize the risk of

connecting mistakenly to another device.

 A feed-back loop should be established to ascertain identity of device needing

federation. For example flashing of a LED light on the device we wish to federate can provide a visual cue to increase trust in the operation.

 If above control objectives do not apply than the user should be notified before

proceeding with the operation.

T11 – Passkey disclosure

If a caretaker tries to use a passkey at a smart door, differing from the one it was issued for, then information about the passkey might be leaked. A malicious smart door owner might use this information to reconstruct the passkey.

 The stake holder should be notified that the passkey was potentially compromised.

Revocation of the passkey should be initiated.

T12 – Video feed outage

If the video feed of the camera is not available, due to sabotage or malfunction, then visitors cannot be verified remotely. This makes it easier to impersonate people who are familiar to the Smart Home owner and are admitted freely.

 Status of video feed should be monitored. Stake holders should be alerted in case of

status change.

(39)

Malicious visitor may leave the door intentionally open upon leaving the Smart Home. If the notification system can be additionally disabled then access to the Smart Home may be gained by unauthorized persons.

 The door should close automatically after a preset timeout.

T14 – Denial of service against smart door notification module

If a successful Denial of Service attack can be mounted against the smart door software controller or a subcomponent of it then notification alerts about the door open status can be suppressed. If this attack is combined with the previous one than access to the Smart Home can be obtained.

 Door monitoring system should be proofed against tampering and Denial of Service

attacks.

T15 – Side channel information leakage in position tracking

Information leakage occurs if a location tracking system which is implemented by periodical message bursts is activated right after its user leaves home. An attacker observing the data traffic may be able to detect the presence or absence of the periodic signal and infer whether the residence is vacant or not.

 Location data streams should be designed to avoid information leaks. There should

be no detectable difference in traffic shape between the two operation states. This can be implemented by always transmitting location data, regardless of whether the subject is indoors or outdoors. Another option is to transmit location data only on request of a polling agent.

T16 – Unauthorized data transmission

Unauthorized data sent by an entity of an IoT network may lead to a breach of privacy. Even the number or the different types of devices (inventory) constitute private data.

 Data traffic should be monitored by a firewall to protect privacy.

T17 – Forged e-voting application

In case an attacker is able to trick the unsuspecting remote voter to download an e-voting client from an unofficial location he or she may infect the targeted machine with malware. He or she may achieve this end by social engineering or by attacking the server hosting the download link. Possible attack strategies include SQL injection and XSS attacks.

 E-voting client should only be downloaded from verified locations.

 Phishing filters should be installed to prevent users from visiting malicious websites

imposing as legitimate entities.

T18 – Resource Profiling on Access

(40)

monitors the persons passing through it. Privacy is endangered by indiscriminate application of resource profiling.

 If a resource is storing privacy related information about an user, then it should

provide an interface where it is possible to check what kind of data is collected. In addition it should be possible to disable collection of data.

The table below shows the threat occurrences in the different use case scenarios of [D2.2].

D.3.2 Threat Analysis

uTRUSTit

D.3.2 Threat Analysis

SEARCH-LAB

Final Version

Authors:

Abstract

Table of Contents

1.

Introduction

1.1

Background

1.2

Scope of this Deliverable

1.3

Overview

2.

Security Objectives

2.1

Assets of the Smart Home Environment

2.1.1

Scenario 1: Trusted Smart Home Services

2.1.2

Scenario 2: Trusted Smart Home Entertainment Management

2.1.3

Scenario 3: Inventory of Things in the Smart Home

2.2

Assets of the Smart Office Environment

2.2.1

Scenario 1: Project Meeting

2.2.2

Scenario 2: Smart Break Room

2.2.3

Scenario 3: Inventory of Things in the Smart Office

2.3

Assets of the E-voting

2.3.1

Scenario: E-voting system for Owners of Apartments in an

Apartment building

2.4

Conclusion

3.

Security Model of the IoT

3.1

Elements of the IoT

3.1.1

IoT Federation

3.1.2

Shared Resources

3.1.3

Credentials

3.2

Operation Primitives

4.

Generic IoT Threat Modeling

4.1.1

Access Privilege Delegation / Revocation

4.1.2

Authentication

4.1.3

Shared Resource Access

4.1.4

Connecting to a federation

5.

Scenario Specific Threat Modeling

5.1

Threat Modeling in the Smart Home Environment

5.1.1

Smart Door

5.1.2

Surveillance Camera

5.1.3

Medical Cabinet

5.1.4

Location Tracking Information

5.1.5

Trusted Smart Home Entertainment Management

5.1.6

Inventory of Things

5.2