6.1 Process Steps to Generate IoT Architectures
-
Physical Entity view
-
Deployment view
-
Operational view
-
IoT Context view
-
IoT Domain Model
-
-
Functional view
-
Information view
-
Create Physical Entity view
-
Create IoT Context view
-
Requirements process
-
Derive other views
6.2 Compatibility with Other Architecting Methodologies
6.3 IoT Architecture Generation and Related Activities
6.3.1 Physical Entity View
-
Devices: the sensors/actuators needed and where are they situated; their relationship to the Physical Entity (directly mounted; touching; remote but in sight …), etc. Note that the device choice is influenced by the Physical Entity. In the recurring example, it is too expensive (in relation to the market price of the Physical Entity) to measure the temperature of each orchid. Instead, sensors that measure the air temperature are situated inside the cargo area. It is then assumed that the air temperature equals that of the orchids. In other words, the Physical Entity model also needs to include a sensing and/or an actuating model.
-
Information view: what physical quantities are monitored by the sensors; how are the quantities related to each other, etc.? In the recurring example the quantity that is handled by the system is the air temperature in the cargo area of the truck.
6.3.2 IoT Context View
-
“System scope and responsibilities
-
Identity of external entities and services and data used
-
Nature and characteristics of external entities
-
Identity and responsibilities of external interfaces
-
Nature and characteristics of external interfaces
-
Other external interdependencies
-
Impact of the system on its environment
-
Overall completeness, consistency and coherence”
6.4 Requirements Process and “Other Views”
6.4.1 Requirements Process
6.4.2 View Derivation
Create physical entity view | Create IoT context view | Requirement process | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
– | Domain-model analysis | Threat analysis | Requirements engineering | Choose tactics | Make design choices | Views mapping of requirements | Derive functional view | Derive information view |
Derive operation-al and deploy-ment view
| ||
Create Physical Entity View
|
–
| Overview of Physical Entities, properties one is interested in, and the basic relationships of the system entities and their properties. | |||||||||
Create IoT Context View
|
Domain-model analysis
| Defines what the Physical Entities in the IoT Context View are and how these entities relate to each other and what is to be done with them (sensing of properties, ..) | |||||||||
Requirement process
|
Threat analysis
| Overview of Physical Entities and the basic relationships of said Entities. | Overview of entities in the system and how they interact. Definition of system borders. | ||||||||
Requirements engineering
| Input for formulating requirements: overview of Physical Entities and the basic relationships of said Entities. | Input for formulating requirements: overview of entities in the system and how they interact. Definition of system borders. | Minimum list of security risks for which one has to formulate require-ments. First input on functional strategies for mitigating said risks. | ||||||||
Choose tactics
| |||||||||||
Make design choices
| Distribution of, property of, and physical connections between Physical Entities. | Distribution, grouping, and nesting of domain-model entities. | Minimum list of identified security risks with associated design choices. | Functional requirements→ introduce complementary functionalities according to the design choices so that also qualitative requirements are covered. | Chosen tactics. | ||||||
View mapping of requirements
| View requirements. | Mapping of design choices onto views. | |||||||||
Derive other views
|
Derive functional view
| Physical Entities and the basic relationships of said Entities. | Identified devices, resources, services, and Virtual Entities. | First input on functional strategies for mitigating said risks. | Functional requirements. | Design choices pertaining to the functional view. | Requirements that are (partially) mapped onto functions. | ||||
Derive information view
| Physical properties of interest. | Identified resources and Virtual Entities. | Impact of risks and identified mitigation strategies on information and data model. | Requirements related to information. | Design choices pertinent to information and data. | Identified FCs and the information to be exchanged between them. | |||||
Derive operational and deployment view
| Physical Entities and the basic relationships and distributions of said Entities. | Identified devices, resources, services, and users. | Implications of identified security risks on operation and deployment. | Requirements related to information. | Design choices pertinent to deployment and operation. | Indications on operation from interacttions view. | Information on life cycle, distribution, and hierarchy of information. |
Architecting activity | Architecting action | Pertinent ARM module | Type of activity | Guidance/information provided in ARM module |
---|---|---|---|---|
Create IoT context view | Domain-model analysis | IoT domain-model (Sect. 7.3) | Create an IoT domain model of the envisaged IoT system. Use information provided in the context view for an identification of system boundaries and system scope | The IoT domain model including a thorough discussion of all its entities |
Reference manual pertaining to the IoT Domain Model (Sect. 9.1) | In-depth information on the entities in the IoT Domain Model together with examples of how to model these entities and entire systems | |||
Requirement process | Threat analysis | Threat analysis (Sect. 4.1.7) | Perform a threat analysis for the envisaged system | List of system aspects to be taken into account during the threat analysis and what importance they carry |
Design choices (Sect. 4.1.8) | Link identified security risks to design choices for mitigation of said risks | Lists of design choices for mitigating security threats to IoT systems | ||
Requirements engineering | How to use unified requirements (UNIs) (Sect. 6.7) | Generation of system requirements | Insight of how the high-level UNIs can support the generation of system requirements | |
Choose tactics | Perspectives (Sect. 8.3) | Mapping of requirements onto qualities (a.k.a. perspectives) and identification of suitable tactics for how to address said qualities. These tactics can be understood as architectural “lines of attack” | Minimum set of perspectives and associated tactics | |
Make design choices | Design choices (Sect. 6.9) | By means of the tactics identified in the previous step, identify design choices for addressing the underlying qualitative requirements | Comprehensive taxonomy of tactics and associated design choices | |
View mapping of requirements | Perform first mapping of non-functional view requirements (and, where expedient, of qualitative requirements) onto the information view and the deployment and operational views | Overview of IoT-specific aspects of these views and how to model them | ||
Perform first mapping of functional requirements (and, where expedient, of qualitative requirements) to FCs. Identify interfaces needed | Description of FGs and FCs | |||
Derive other views | Derive functional view | Carrez et al. (2013) | Define basic functions, interfaces, and interactions for functional view | The Appendix Section provides exhaustive text on the FCs, related technical-use-case diagrams, descriptions of basic FC functions and high-level interfaces, as well as elementary interactions of FC and their basic functions (sequence charts) |
Chapter 10 “Interactions” | Define system-wide interactions of FCs | The Interactions Section provides examples of how such interactions can look like for a selected range of application scenarios | ||
Chapter 10 “Interactions” | Derive interaction patterns for prevailing usage scenarios | As briefly discussed in Sect. 8.2.2, the interaction viewpoint is an integral part of the functional view, but the IoT ARM is situated at a far too high level of abstraction in order to allow the definition of the functional interaction sequences at the reference-architecture level. In order to mitigate this systemic shortcoming of the IoT ARM, we decided to discuss some few usage scenarios of IoT systems that can shed at least some light on how such interaction patterns can look like, and they also provide inspiration for how such patterns might look like for the usages for which the concrete architecture is built | ||
Derive information view | Information view (Sect. 8.2.3 “IoT Information View”) | Define information and data model for all FGs and also for the exchange with applications and devices (see Sect. 8.2.3) | The IoT Information View provides several pieces of general information. First, it elaborates on general information descriptions (description of Virtual Entities service descriptions; associations between services and Virtual entities). Second, it elucidates the information handling of FCs both from an interaction- and from a interaction-scenario point of view. Third, it discusses the information life cycle | |
Derive operational and deployment view | Deployment & operational view (Sect. 8.2.4) | Define how to deploy and how to operate the system | This section discusses in depth how deployment of IoT systems. Since the deployment patterns vary a lot, this Section of course focuses on common topics and patterns. First, it identifies other views and device descriptions as viewpoints for the deployment. This aids in translating information in these views into actionable deployment knowledge. This Section also discusses the question of connectivity solutions and where to host the services. It also touches upon the important questions of information storage and service resolution | |
Derive deployment view | Carrez et al. (2013) | Define APIs for the implemented FCs | Carrez et al. (2013) provides definitions of high-level interfaces for all the FCs in the functional decomposition in Sect. 8.2.2 “IoT Functional View”. While these high-level interfaces are not equivalent to APIs, the information provided in Carrez et al. (2013) – (together with the sequence charts in the same Appendix) can be seen as a solid starting block for deriving APIs. More information can be found in the WP4 White Paper on Resolution Infrastructure Interface Binding (Bauer 2013), which describes a REST (Representational State Transfer) interface binding that was exemplarily defined based on the abstract interface specifications of the IoT Service Resolution and Virtual Entity Resolution FC found in Carrez et al. (2013) |
-
In Red: actions that are particular to the IoT-A architecting framework and that directly contribute to the architecture documentation;
-
In Orange: actions that are not unique to the IoT-A architecting process, but that enjoy an emphasis in the IoT-A framework;
-
In Green: other activities and documents that directly contribute to the architecture documentation;
-
In Blue: actions that are not unique to the IoT-A architecting process, but that enjoy an emphasis in the IoT-A framework
-
<<flow>>: information flow into a document.
6.5 IoT ARM Contributions to the Generation of Architectures
6.6 Minimum Set of Functionality Groups
-
Application Functionality Group
-
IoT Service Functionality Group
-
Communication Functionality Group
-
Device Functionality Group
6.7 Usage of Unified Requirements
6.7.1 Introduction
-
The Unified Requirement list should be seen as a basis and a living document. Although it tries to cover the whole spectrum of requirements families that could be applied to the IoT domain, it cannot be considered to be exhaustive, as, for instance, future regulation and legislation could impose requirements unforeseen at the time of publication. Additionally, Unified Requirements are often formulated on a quite high abstraction level (something largely avoided in concrete system’s requirement engineering), resulting in requirements that are, for instance, mapped onto one or several views and possibly perspectives (again, something that concrete system designers tend to avoid);
-
Formulation of requirements expressed by external or internal stakeholders (description field in the used Volere template) may sometimes apply directly to the IoT ARM (e.g. UNI.094 “The Reference Architecture shall support any IoT business scenario”), but in most cases they apply to a concrete system that can be implemented using the IoT ARM. In that latter case, they express characteristics on the system that the IoT ARM should enable to specify, meaning they require to be interpreted by the reader/system designer to see how they apply to their own case – hence the wording “the system shall …” generally used. Let us take for instance UNI.021 “The user shall be able to control the radio activity of the system”: depending on the actual usage of radio communication, on the role of the user and on the importance of controlling the radio activity of the system in the concrete architecture, this requirement may be dropped, or specialised. In any case reinterpreting Unified Requirements is necessary (more on this in the following);
-
Mapping to perspectives/views/functional groups and components is done on a lowest-common-denominator basis – e.g. it indicates which aspects are definitely impacted by a given Unified Requirement, but the reader should keep in mind that in certain (concrete system) specific cases, additional components may need to be considered. For instance, the Device Functionality Group is out of scope of the IoT ARM (see Figure “Functional-decomposition viewpoint” of the IoT Reference Architecture in Sect. 8.2.2.) and is therefore not listed in mapping of functional Unified Requirements, while it clearly needs to be considered when devising a concrete IoT system. Another instance is the lack of differentiation of the data plane vs. management plane in the IoT ARM, as this is a clear design choice (see Sect. 6.9).
-
As pointed out in the ARM document, Sect. 6.4 and for the reasons explained there, the categorisation of the UNIs does not fully match that of the IoT ARM process and one needs to map the UNI categories onto that of the process in order to utilise the UNIs for the generation of architectures. Table 6.3 below provides this mapping information.Table 6.3Translation table for UNI requirement types from and to IoT ARM requirement typesUNI requirement typeIoT ARM requirement typeIndicated byDesign constraintDesign constraint–Functional requirementView requirement–Non-functional requirementView requirementMapping of UNI onto a viewQualitative requirementMapping of UNI onto one or more Perspectives
6.7.2 Using Unified Requirements
6.7.2.1 Requirement Elicitation
6.7.2.2 System Specification
6.8 Threat Analysis
6.8.1 Elements to Protect
-
Transportation and logistics;
-
Smart home;
-
Smart city;
-
Smart factory;
-
Retail;
-
eHealth;
-
Energy (Smart Grid).
-
Physical person: This represents the human user. Threats affecting the human user are usually qualified as relating to ‘safety’ instead of ‘security’. Such threats may arise if a critical service is diverted or made unavailable by an attacker. An example for this is a malicious service that returns erroneous information, or even information specifically shaped to create hazardous situations. The eHealth scenario is the most critical concerning such attacks. Notice that the level of this criticality of course depends on the degree of automation. It is likely that most critical decisions will still require the involvement of a human operator;
-
Subject’s privacy: This element represents all information elements that a subject (either a user or a device) does not explicitly agree to make publicly available, or whose availability shall be restrained to a controlled set of other subjects;
-
Communications channel: The communication channel itself has to be protected. Common threats are attacks against the integrity of the data that are exchanged over the channel. Examples for such attacks are tampering and replay attacks. The communication channel shall also be protected against attacks aiming at the routing functionality of the underlying network (black hole, worm hole, depletion, etc.) (Mathur and Subbalakshmi 2007);
-
Leaf devices: IoT-A leaf devices represent the wide variety of IoT elements that are interconnected by the common IoT-A infrastructure. Tags, readers, sensors, and actuators are examples for leaf devices. Various protection schemes relevant to their object class capabilities are to be implemented. These schemes need to ensure the integrity of the software, hardware, and the location of these devices;
-
Intermediary devices: Intermediary devices provide services to IoT-A leaf devices and they also enable communication. A gateway designed to interconnect constrained and unconstrained domains is an example of such an intermediary device. Disabling or tampering critical intermediary devices can lead to denial-of-service attacks against the service infrastructure. Such attacks are within the scope of our analysis. However, attacks against specific intermediary devices that offer non-critical facilitating functions are outside the scope of our analysis and have thus to be considered case by case;
-
Backend services: Backend services represent server-side applicative elements (for instance data-collection server communicating with sensor nodes). Compromising this software or the devices they are deployed on generally represents a critical threat against specific application systems and has to be prevented;
-
Infrastructure services: Discovery, lookup and resolution services are very critical services as they provide worldwide fundamental functionalities to IoT systems. In the same way, security services (authorization, authentication, identity management, key management, and trust and reputation) are essential for a secure interaction between subjects (as defined above);
-
Global systems/facilities: This last category of elements to protect considers entire services in a global manner. For example, there might be a risk that an attack against the smart home scenario results in the complete disruption of the service, e.g. through the disruption of underlying communications between devices. The consequences of this resulting disruption can therefore be considered through this category.
6.8.2 Risk Sources
-
Identity spoofing means that a peer illegitimately uses the identity of another peer. Spoofing attacks can happen with respect to all kind of identifiers, irrespective of whether they are used to designate physical persons, devices, or communication flows;
-
Data tampering means that an attacker is able to alter the content of data exchanged between two or more peers. Data tampering may involve subtle attack schemes, wherein the attacker is able to trigger specific behaviours of recipients by finely modifying original data;
-
Repudiation relates to attacks in which an attacker performs illegitimate actions and may afterwards deny having performed them, such that other nodes are unable to prove that the attacker actually behaved maliciously;
-
Information disclosure means that information is disclosed to unauthorised peers. It is related to the existence of an authorisation model that defines for each information element a set of peers that are authorised to access it, possibly under some specific conditions;
-
Denial-of-service attacks are carried out for disabling a service offered to legitimate users (as opposed, for example, to more subtle schemes wherein the attacked service can be altered, e.g. making a search service return false results, without the legitimate users being able to notice it);
-
Elevation of privilege may occur in systems that feature different classes of users, each class being mapped to a specific set of rights. Illegitimate elevation of privilege occurs when an attacker manages to acquire rights that would normally only be granted to more privileged class(es). In the most critical case, an attacker may obtain administration rights for the entire system, or part of it, which means that the attacker may perform arbitrary actions on the elements the attacker has access to, thereby being able to destroy the system or entirely change its behaviour.
-
Non-human risk sources either global (flood, lightning, fire, electrical, heat) or local (individual device failure) are not considered. Only human risk sources are. Note that a human forging a faked device identity in order to impersonate another device fits within the category of “human risk”;
-
Among human risk sources, only theft/loss and hacker-initiated attacks are considered. Technical staff errors or accidents are not considered. In other words we are only addressing malicious attacks and not involuntary attacks.
Spoofing identity | Tampering with data | Repudiation | Information disclosure | Denial of service | Elevation of privilege | |
---|---|---|---|---|---|---|
Physical person | Attack alters data so that wrong data is supplied to a critical monitoring system | Human users might use unattended electronic devices without leaving a digital trace | A service critical for user’s safety is disabled | |||
Subject’s privacy | User’s identity is spoofed | Attacker gleans knowledge of user private parameters | ||||
User is involved in transactions with a malicious peer | Attacker gleans knowledge of user’s location | |||||
Communication channel | Alteration of the invocation of a service | Jamming wireless communication channels leads to local denial-of-service attacks that can be repudiated (no digital traces) | Attacker gains knowledge of sensitive exchange data | Attacker disrupts communications | Wrong authorisation information propagating from one server to another | |
Alteration of the return value upon service invocation | ||||||
Leaf devices | Loss or theft of physical device used for authentication | Attacker gains control of an actuator | Disclosure of device-configuration information | Attacker physically disables local leaf device | ||
Attacker alters leaf-device content so that a user will eventually be redirected to a malicious content | Device identification may divulge sensitive information, or may be linked so that it exhibit information about usage patterns, | Attacker physically disables remote leaf device | ||||
Attacker changes the association between a Virtual Entity and the corresponding Physical Entity | Attacker alters sensor device so that monitoring of a Physical Entity fails | Loss or theft of device containing private information | Attacker prevents proper communication to an actuator | |||
Intermediary devices | Compromised intermediary devices alter traversing data | Intermediary devices behave maliciously and clients are not able to report the fact | Information re-routing by intermediary device so that it ends up at an unintended destination | Assisting intermediary devices are no longer usable | ||
Backend Services | Usurpation of administrator role | Massive disclosure of collected data | Backend service is made unavailable | |||
Backend account hacked | ||||||
Infrastructure services | Attacker impersonates infrastructure services and compromises IoT functionalities and/or other dependent infrastructure services | Attacker poisons infrastructure databases and/or alters outgoing information | Disclosure of private services (existence & description) | Attacker denies legitimate users access to infrastructure services | ||
Disclosure of access policies | ||||||
Disclosure of Identities and cryptographic material | ||||||
Global systems/facilities | Massive disclosure of user information | Disruption of a global service |
6.8.3 Risk Assessment
Element to protect | Risk | D/R/E/A/D rating | Examples of causes | Mitigation and relevant design choices (for the latter see Sect. 6.9) |
---|---|---|---|---|
Physical person | Attack alters data so that wrong data is supplied to a critical monitoring system | H/L/M/L/L
enforce strong security | Data-integrity protection provided as part of protocol security. DC S.16: cryptographic protocols DC S.19: integrity protection obtained from authentication enforcement at link layer | |
Human users might use unattended electronic devices leaving no digital trace | L/L/H/L/L
enforce weak security | Addressable through proper (local/remote) user authentication scheme which is a feature of the Authentication Functional Component (see Sect. 8.2.2.7). DC S.1,3: ensure proper logging of authentication operations, e.g. through the use of a AAA (authentication, authorisation, and accounting) or a AAA-like system | ||
A service critical for user’s safety is disabled | H/M/M/L/L
enforce strong security | Critical services have to be protected through redundancy of their key elements. Malicious actions are prevented through dedicated access-control policies (security management). Communication medium between user and critical service has to be made robust against DoS attacks at all OSI layers DC S.5: restrained service access DC A.16–17: autonomous security | ||
User’s privacy | User’s identity is spoofed | L/H/H/L/M
enforce strong security | Credential theft Credential brute-forcing Registration procedure that is vulnerable to man-in-the-middle attack | Robust user-authentication procedure preventing man-in-the-middle attacks, with proper credentials management policy provided by Authentication Functional Component (see Sect. 8.2.2.7) DC S.1: authentication over encrypted channel DC S.10 avoid common crypto credentials; avoid reliance on symmetric crypto |
User is involved in transactions with a malicious peer | L/H/H/M/L
enforce strong security | Redirection to malicious content. The redirection may be caused by data tempering on communication channel or leaf node compromising (e.g. content of a tag is altered) | Trustworthy discovery/resolution/lookup system. Trustworthiness of the entire system is enabled through its security Functional Components (especially Authentication and Trust and Reputation (see Sect. 8.2.2.7), as well as its global resilience to intrusions (security by design) Resolution security DC S.1: authentication over encrypted channel | |
Attacker gains knowledge of user configuration | M/M/M/L/H
enforce strong security | User’s private information leakage through user’s characterisation as requiring certain data (and thus performing accordingly discovery, lookup, resolution of the corresponding services) User’s private information leakage through user’s characterisation as providing certain data. Traceability (this path, hence this user). | Enforcement of a robust pseudonymity scheme ensuring both anonymity and unlinkability of two successive data units; provided by the Identity Management Functional Component (see Sect. 8.2.2.7) DC S.10: encryption schemes, with a specific relevance of onion-routing-like encryption (best scheme with respect to anonymity support) DC P.1: temporary identity, more easily changed for unlinkability, hence privacy | |
Attacker gains knowledge of user’s location | L/H/M/L/H
enforce weak security | User’s location can be hidden through reliance on pseudonyms provided by the Identity Management Functional Component (see Sect. 8.2.2.7) DC P.1: temporary identity, more easily changed for unlinkability, hence privacy | ||
Communication channel | Alteration of the sent invocation of a service | L/L/M/L/L
enforce weak security | End-to-end integrity protection of service-access signalling (data integrity protection is provided as part of protocol security) DC S.1,3: service-based data integrity DC S.19: integrity protection obtained from authentication enforcement at link layer | |
Alteration of the return value upon service invocation | L/L/M/L/L
enforce weak security | End-to-end integrity protection of service-access signalling (data integrity protection is provided as part of protocol security) Service-based data integrity DC S.19: integrity protection obtained from authentication enforcement at a layer below the service | ||
Jamming wireless communication channels can lead to local denial-of-service attacks that can be repudiated | M/H/L/M/M
enforce medium security | Jamming denial-of-service attacks can be addressed through physical means: for instance, once the attack is detected localise and neutralise the jammer DC A.16–17: autonomous security could be enabled for detecting this attack | ||
Attacker gains knowledge of sensitive, exchanged data | M/L/M/L/L
enforce medium security | End-to-end confidentiality protection of exchanged data, offered through protocol security DC S.10: encryption schemes | ||
Attacker disrupts communications | M/H/L/H/L
enforce medium security | Various denial-of-service prevention schemes are available. Their applicability depends on the communication technology used (anti-jamming, enforced MAC, etc.). Schemes are offered through security-by-design of the communication stack DC A.16–17: autonomous security systems are generally able to deter denial-of-service attacks, however lightweight schemes are less powerful | ||
Wrong authorisation information propagating from one server to another | M/L/L/H/M
enforce medium security | Strong security for server-to-server communications that leverages individual’s credentials (e.g. certificates) instead of group keys, and allows for revocation (security by design, adequate management policies) | ||
Leaf device | Loss or theft of a physical device used for authentication | M/L/H/L/L
enforce weak security | Two-factor authentication, when applicable. This means that the gain of the physical device would not be enough for an attacker to pretend being a legitimate user and authenticate as such Cryptographic credentials should be themselves protected (PIN code, passphrase) DC S.1,3: authentication. Note that identification instead of authentication should not be applied | |
Loss or theft of physical device containing private information | M/L/H/L/L
enforce medium security | Physical protection of stored credentials (e.g. security vault) – readability of a device only upon fulfilment of certain conditions (e.g. known reader) | ||
Attacker changes the association between a Virtual Entity and the corresponding Physical Entity | M/L/M/H/L
enforce medium security | Wrong tag on a device | Secured discovery/resolution/lookup system A specific Design Choice for tamper-proof IDs is not provided for two reasons. First, one could realise it on a hardware-level by using tamper-proof hardware modules. Notice that hardware is out of scope for IoT-A (device level is not part of the RA). The second reason is that tamper-proof IDs can also be realised by a secure resolution system by means of Authentication and Authorisation which is already part of the RA and thus no Design Choice is needed | |
Attacker gains control of an actuator | Compromising resolution system M/M/M/L/M
enforce medium security | Proper authorisation scheme as offered by the Authorisation Functional Component (see Sect. 8.2.2.7) End-to-end integrity protection, provided as part of protocol security DC S.5: prevent compromise through access restriction DC A.16–17: reactive (autonomous) security in case of compromise | ||
Attacker alters leaf-device content so that a user will eventually be redirected to a malicious content | M/M/H/M/L
enforce medium security | Not specifically targeted. Addressable through a proper URI verification system on user device | ||
Attacker alters sensor device so that monitoring of a Physical Entity fails | L/M/L/L/H
enforce weak security | Not specifically targeted. Sensitive physical values may be monitored by a large number of sensors, or sensor integrity can be remotely verified | ||
Disclosure of device configuration information | L/L/L/L/H
enforce weak security | Not specifically targeted. Unlinkability between different actions of the same device, provided by the Identity Management Functional Component (see Sect. 8.2.2.7), will mitigate the criticality of this threat DC P.1: use of temporary identity to provide unlinkability | ||
Device identification | L/M/M/L/H
enforce medium security | Attacker bypasses in-place pseudonymity scheme and identifies a device as providing access to certain data | Adequate protection scheme requiring partial pre-knowledge of each other before a tag can be read by a reader (the tag will only answer to a “known” reader) | |
Attacker physically disables leaf device (local) | L/H/H/L/L
enforce weak security | Tag destruction | Not specifically targeted. Typically addressable through physical investigation (identify the attacker through traces left by the physical attack; e.g. triangulation of a destructive electromagnetic pulse) | |
Attacker physically disables leaf device (remote) | M/H/L/H/L
enforce weak security | Tag destruction by remote electromagnetic means | Not specifically targeted. Typically addressable through physical investigation | |
Attacker prevents proper communication to an actuator | M/H/L/M/L
enforce medium security | Denial-of-service detection/reaction scheme (security by design) | ||
Intermediary devices | Compromised intermediary devices alter data passing through | M/H/M/M/L | End-to-end security scheme provided by the Key Exchange and Management Functional Component (see Sect. 8.2.2.7), and enforced by the relevant protocol security function | |
enforce medium security | Remote monitoring of intermediary devices can be another means of dealing with this threat (identification of compromised devices)
DC S.10: end-to-end encryption
DC A.16–17: autonomous security | |||
Intermediary devices behave maliciously and clients are not able to report the fact | M/M/L/M/H
enforce weak security | Remote monitoring of intermediary devices Depending on the malicious action performed by intermediary devices, client nodes may mitigate it by applying end-to-end security schemes (Key Exchange and Management Functional Component + protocol security)
DC A.16–17: autonomous security | ||
Information re-routing by intermediary device | M/H/M/M/M
enforce medium security | End-to-end security scheme put in place by the Key Exchange and Management Functional Component (see Sect. 8.2.2.7), and enforced by the relevant protocol security function DC S.10: end-to-end encryption | ||
Assisting intermediary devices are no longer usable | L/M/H/H/L
enforce medium security | Exhaustion attacks | Denial-of-service detection/reaction scheme | |
Various specific attacks against the involved assistance mechanisms (e.g. no packet forwarding toward a routing service, replacing a received key fragment with garbage against a collaborative keying service…) | DC A.16–17: autonomous security | |||
Backend services | Administrator-role usurpation | H/M/L/H/L
enforce medium security | Administrator credentials disclosed/hacked/brute-forced | Not specifically targeted. Addressable through security management and credentials management policies |
Backend account hacked | M/M/L/H/M
enforce medium security | Not specifically targeted. Addressable through security management and credentials management policies | ||
Massive disclosure of collected data | H/M/L/H/L
enforce medium security | Not specifically targeted. Addressable through security management (databases) | ||
Backend service becoming unavailable | L/M/M/H/L
enforce medium security | DoS detection/reaction scheme DC A.16–17: autonomous security | ||
Attacker impersonates infrastructure services, compromising IoT functionalities and/or other dependent infrastructure services | H/M/L/H/M
enforce strong security | Prevention of impersonation techniques through proper use of authentication/authorisation procedures (enforced by the respective Authentication and Authorisation Functional Components (see Sect. 8.2.2.7) DC S.1,3: authentication | ||
Attacker poisons infrastructure databases (records corruption/addition) or alters outgoing information | H/H/L/H/M
enforce strong security | Proper authorisation scheme provided by the Authorisation Functional Component (see Sect. 8.2.2.7) mitigates this attack. Enforcement of a trust model (Trust and Reputation Functional Component (see Sect. 8.2.2.7) protects against blind acceptation of erroneous data DC S.5: service access control. Although this does not allow identifying corrupted data, it may help identifying and excluding the attacker | ||
Disclosure of private services (existence & description) | L/H/H/M/M
enforce medium security | Masking the belonging of multiple services to a single entity (unlinkability). This can be achieved by reliance on pseudonyms provided by the Identity Management Functional Component (see Sect. 8.2.2.7) DC P.1: mitigation through the use of temporary identifiers | ||
Disclosure of access policies | L/H/H/M/M
enforce medium security | Security management of infrastructure prevents global disclosure of access policies from the decision point to an unauthorised external attacker. Probe discovery of access policies by authorised, though compromised internal attackers are more subtle, and have to be dealt with through adaptive security (e.g., recognise a malicious pattern in the regular probing of security decision points) DC A.16–17: probing detection/reaction performed by autonomous security | ||
Disclosure of identities and cryptographic material | M/H/H/M/L
enforce strong security | Not specifically targeted – addressable through security management (databases) | ||
Attacker denies legitimate users access to Infrastructure Services | M/H/L/M/L
enforce medium security | Exclusion of the attacker, once identified as such through the Trust and Reputation security Functional Component (see Sect. 8.2.2.7) | ||
Massive disclosure of user’s personal information | H/L/L/H/L
enforce strong security | Secure storage of personal data with dedicated protection architecture (e.g. firewall diodes that let data flow in one direction only) and access control rules—this is part of security management | ||
Disruption of a global service | H/M/L/H/L
enforce strong security | Reliance on all security Functional Components (see Sect. 4.2.2.7) + proper security management This threat can also be addressed by multihoming. See DC P.3 (Replication of instances of Functional Components locally) and DC P.4 (Replication of instances of functional components in the cloud) |
6.8.4 Discussion
-
In the framework of IoT, special emphasis is put on one-to-one transactions wherein a service is accessed by a remote player. These transactions require a secure transaction set up. The service-access control involves in its most secure embodiments an authentication phase that can be based on various authenticating credentials. It has to be noted, though, that these authenticating credentials have to be mapped to an identity in order to fulfil their role. When the peer identity is not known prior to establishing a transaction, it has to be securely retrieved (resolved) from the resolution infrastructure. Likewise, the services themselves may need to be securely orchestrated;
-
Upon successful authentication, access control has to be enforced in order to bind all data units exchanged between two players to their respective authenticated identities. This takes usually the form of an authentication procedure being implemented as an authenticated key-exchange (AKE) protocol, and all subsequent messages exchanged between the same two players are then integrity protected by the AKE-obtained session key. Various protocols exist for doing so: at the network layer, the Host Identity Protocol Base Exchange (HIP BEX) and Internet Key Exchange (IKE) are AKE protocols and IPsec is the corresponding secure data transport protocol. At the transport layer, TLS handshake is an AKE protocol for subsequent (D)TLS exchanges. Various service-specific protocols can of course also be used. Eventually, all risks mitigated by integrity protections should rely on specific cryptographically protected access-control schemes;
-
In parallel with secure transaction set up and access-control-based integrity protection, protection against internal attacks requires a coherent arrangement of the associated cryptographic primitives which have to be based on an assessment of the attacker profile and capabilities. Many design choices proposes different embodiments that provide different security levels. For example the perfect forward secrecy property is theoretically a more secure one. However, this additional security property would prove worthwhile only for an attacker able to (and interested in) accessing data exchanged in the past (hence possibly obsolete) but that the attacker would nevertheless have stored under an encrypted form. Clearly, most of attacker models and data criticality do not fit within this attack scenario. If one decides to envision it, though, the same attacker capabilities should be assumed for all other risks.
6.9 Design Choices
6.9.1 Introduction
Architectural perspective | Architectural view |
---|---|
Evolution and interoperability | Functional |
Information | |
Availability and resilience | Deployment |
Performance and scalability | Deployment |
Trust, security and privacy | Deployment |
6.9.2 Design Choices Addressing Evolution and Interoperability
Desired quality | The ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility |
Tactics | Create extensible interfaces |
Apply design techniques that facilitate change | |
Apply metamodel-based architectural styles | |
Build variation points into the software | |
Use standard extension points |
-
Characterize the evolution needs: IoT-A has collected stakeholder and also internal requirements reflecting the actual and future needs in IoT systems (see IoT-A 2013);
-
Assess the current ease of evolution: Also through the stakeholder workshops and in addition the use cases from WP7 and the state of the art analysis from WP1 and all technical work packages, the current status was collected;
-
Consider the evolution trade-offs: The evolution trade-offs are heavily domain- and application-specific and are not part of the IoT-A work. Those trade-offs must of course be discussed when creating an architecture for a concrete application;
-
Build variation points into the software, Use standard extension points: By using standardised protocols and gateways, even legacy devices are able to be linked to IoT-A systems.
-
The IoT-A Reference Architecture is built out of modular blocks to allow changes and additions. When deriving the IoT-A work to a concrete architecture, this modularity and also the loose coupling between those blocks should be kept. This concept is also used in the ‘Dispatcher’ component (Hyttinen P ed et al. 2013) for the standardized processing of incoming requests without exposing the internal methods and functions;
-
Not all of the systems functionality can be defined in advance. Therefore, some additional spaces and extensions points, e.g. for upcoming functionality, should be reserved. This can for example be done in interface definitions or data models, like the reserved bits in the TCP header definition. This allows the designers and architects to update the system and to adapt it to new requirements.
Tactic | Reason |
---|---|
Contain change | Not possible for public IoT-systems, new devices will participate in the systems |
Achieve reliable change | Same as above |
Preserve development environments | Due to the multiplicity of developers and technology providers, a common development environment will not exist |
Desired quality | The ability of the system to predictably execute within its mandated performance profile and to handle increased processing volumes in the future if required |
Tactics | Optimize repeated processing |
Replication | |
Prioritize processing | |
Distribute processing over time | |
Minimize the use of shared resources | |
Reuse resources and results | |
Partition and parallelize | |
Scale up or scale out | |
Degrade gracefully | |
Use asynchronous processing | |
Reduce complexity | |
Make design compromises |
Tactic | Impact on views | ||
---|---|---|---|
Functional | Information | Deployment and operation | |
Replication | Replication of functional components (DC PS.1) | Replication of gathered Information (DC PS.2) | Replication of instances of Functional Components locally (DC PS.3) |
Replication of instances of functional components in the cloud (DC PS.4) | |||
Prioritize Processing | Functional component offer services for different priorities (DC PS.5) | Information holder for priority information necessary (DC PS.6) | Provide instances of different functional components for different priorities (DC PS.7) |
Priority-aware functional components with priority based processing and networking (DC PS.8) | |||
Partition and parallelize | Multi-thread/multiprogramming aware Functional components (DC PS.9) | Information flow needs to be parallelizable (DC PS.10) | Location-aware deployment of functional components (DC PS.11) |
Deployment of functional components need to be according to data flow (DC PS.12) | |||
Reduce computational complexity | No functional component (DC PS.13) | No Impact | Less functional component deployed (DC PS.15) |
Functional component with reduced capabilities (DC PS.14) | |||
Distribute processing over time | Design components to schedule processing (DC PS.16) | Information holder for deadline (DC PS.17) | No impact |
Minimize the use of shared resources | Design functional components to minimize use of shared resources (DC PS.18) | No impact | Minimize communication distances (DC PS.19) |
Deployment to minimize use of shared resources (DC PS.20) | |||
Reuse resources and results | History aware functional components (DC PS.21) | Cache results which are likely to be reused (DC PS.22) | Storage of information locally (DC PS.23) |
Storage of information remotely (DC PS.24) | |||
Storage of information local and remotely (DC PS.25) | |||
Scale up or scale out | Design functional Components in a replicable way (DC PS.26) | No impact | Provision of further resources (DC PS.28) |
Use services in the cloud (DC P.29) | |||
Design function components so that they can use cloud support (DC PS.27) | |||
Degrade gracefully | Functional Components need to be able to restart (DC PS.29) | Support of rollback points (DC PS.31) | Replication of components (DC PS.32) |
Redundancy of resources (DC PS.33) | |||
Functional components with rollback functionality (DC PS.30) | |||
Use asynchronous processing | Asynchronous-aware functional component (DC PS.35) | No impact | No impact |
6.9.3 Design Choices Addressing Performance and Scalability
6.9.3.1 Replication
6.9.3.2 Prioritize Processing
6.9.3.3 Partition and Parallelize
6.9.3.4 Reduce Computational Complexity
6.9.3.5 Distribute Processing Over Time
6.9.3.6 Minimize Used of Shared Resources
6.9.3.7 Reuse Resources and Results
6.9.3.8 Scale Up or Scale Out
6.9.3.9 Degrade Gracefully
6.9.3.10 Use Asynchronous Processing
6.9.4 Design Choices Addressing Trust
Tactic | Impact on views | ||
---|---|---|---|
Functional | Information | Deployment and operation | |
Harden root of trust | The security policy defines how the root of trust may be accessed. (DC T.1) | No impact | Integration of IoT-A trust and reputation component (DC T.2) |
Secure implementation for protecting a root-of-trust based on hardware implementation (DC T.3) | No impact | Integration of a physically unclonable function | |
(PUF) (DC T.4) | |||
Ensure high quality of data | Protects data integrity and freshness by using a secure network encryption protocol | Improvement of content dimension and intellectual dimension (DC T.6) | Integration of a secure network encryption protocol (DC T.7) |
(DC T.5) | |||
Infrastructural trust and reputation agents | Collects user reputation scores and calculates service trust levels (DC T.8) | Service description should include relevant aspects for what concerns trust evaluation (DC T.9) | Integration of IoT-A trust and reputation |
(DC T.10) | |||
Web of Trust system to establish the authenticity of the binding between a public key and its owner. (DC T.11) | No impact | Decentralized trust model (DC T.12) | |
Provide high system integrity | Evaluation of trust based on reputation (DC T.13) | No impact | Integration of a reputation framework for high integrity sensor networks (RFSN) (DC T.14) |
Avoid leap of faith | Utilizes one-way hash chain to provide effective and efficient authentication (DC T.15) | No impact | Usage of lightweight authentication protocol (DC T.16) |
6.9.4.1 Harden Root of Trust
6.9.4.2 Ensure High Quality of Data
6.9.4.3 Infrastructural Trust and Reputation Agents
6.9.4.4 Provide High System Integrity
6.9.4.5 Avoid Leap of Faith
Tactic | Reason |
---|---|
Ensure physical security and implement tampering detection | Pervasive deployment of IoT devices makes such devices accessible to malicious users |
Consider device security in the global system design | Devices that are not tamper-proof can be compromised. Although this aspect is related to the deployment view, it has impacts on the design of the overall system and trust evaluation |
Consider the impact of security/performance trade-offs on trust | This must be evaluated for each use case during the design phase by means of tests such as simulation. For that reason, no DC can be proposed |
Use security imprinting | Out of scope for IoT-A since devices are not covered in the IoT Reference Architecture |
Balance privacy vs. non-repudiation (accountability) | If system requirements include non-repudiation, these will necessarily impact the privacy feature of the designed system. Privacy can be granted by using an Identity Management. This component, run by a third party is trusted for what concerns both privacy protection and ability to track back malicious actions |
6.9.5 Design Choices Addressing Security
Tactic | Impact on views | ||
---|---|---|---|
Functional | Information | Deployment and operation | |
Subject authentication | Authentication over encrypted channel (DC S.1) | No impact | Integration of IoT-A authentication FC (DC S.2) |
Crypto-based authentication over open channel (DC S.3) | No impact | Peer-to-peer authenticated communications over an insecure channel must be possible (DC S.4) | |
Use access policies | Policy-based service access (DC S.5) | Stored information must be managed in a way to support access control mechanisms (DC S.6) | IoT-A Authorisation FC component (DC S.7) |
Unrestricted access to service (DC S.8) | Stored information is not protected (DC S.9) | No impact | |
Secure communication infrastructure | End-to-end encryption (DC S.10) | Information transmission channel between device and application is secured (DC S.11) | IoT-A end to end communication FC, Network communication FC and key exchange and management FC (DC S.12) |
Hop-to-hop encryption (DC S.13) | Information transmission channel between device and application is secured (DC S.14) | IoT-A hop to hop communication FC, network communication FC and key exchange and management FC (DC S.15) (Sect.7.7.2) | |
Cryptographic protocols ensuring confidentiality, integrity, authentication of subjects (DC S.16) | Communication channel between two subjects is secured (DC S.17) | End-to-end security protocol to ensure wireless communication security (DC S.18) | |
Secure peripheral networks (link layer security, secure routing) | Link-layer encryption and authentication, multipath routing (DC S.19) | No impact | Integration of secure routing protocols in the Network Communication component (DC S.20) |
6.9.5.1 Subject Authentication
6.9.5.2 Use Access Policies
6.9.5.3 Secure Communication Infrastructure
6.9.5.4 Secure Peripheral Networks (Link Layer Security, Secure Routing)
Tactic | Reason |
---|---|
Harden infrastructural functional components | Infrastructural functional components are critical components that can compromise the whole system if compromised |
Avoid wherever possible wireless communication | Wireless communication generally uses a shared medium for communication which, in turn, allows easy interception of link layer communication |
Physically protect peripheral devices | Pervasive deployment of IoT devices makes such devices accessible to malicious users. While how to protect these devices is outside the scope of the IoT Reference Architecture (devices not covered!), this vulnerability must be taken into account in secure designs |
Avoid OTA device management | No DC proposal possible as most of the devices connected in IoT must be managed over the air if at all possible |
6.9.6 Design Choices Addressing Privacy
Tactic | Impact on views | ||
---|---|---|---|
Functional | Information | Deployment and operation | |
Pseudonymisation | Creation of a fictional identity (root identity, secondary identity, pseudonym or group identity) (DC P.1) | No impact | Integration of IoT-A identity management FC (DC P.2) |
Avoid transmitting identifiers in clear | Encryption mechanisms for wireless connections (DC P.3) | No impact | Integration of a wireless security algorithm (DC P.4) |
Minimize unauthorized access to implicit information | Access control management (DC P.5) | Stored Information must be managed in a way to support access control mechanisms (DC P.6) | IoT-A authorisation FC (DC P.7) |
Enablement of a scalable and secure key distribution between communicating subjects (DC P.8) | No impact | Encrypt communication with Resolution Components and with Services (e.g. KEM FC) (DC P.9) | |
Enable the user to control the privacy settings | Addresses privacy questions so that a user can operate anonymously (DC P.10) | No impact | IoT-A identity management FC (DC P.11) |
Privacy-aware identification | Authentication of the responding host, the initiating host can stay anonymous (DC P.12) | No impact | Requires TLS and DTLS support (DC P.13) |
6.9.6.1 Pseudonymisation
6.9.6.2 Avoid Transmitting Identifiers in Clear
6.9.6.3 Minimize Unauthorized Access to Implicit Information
6.9.6.4 Enable the User to Control the Privacy Settings
6.9.6.5 Privacy-Aware Identification
Tactic | Reason |
---|---|
Validate against requirements | Too general, no DC proposal possible |
Consider the impact of security/performance trade-offs on privacy | This must be evaluated for each use case during the design phase. For that reason, no DC can be proposed |
Balance privacy vs. non-repudiation (accountability) | This must be evaluated for each use case during the design phase. For that reason, no DC can be proposed |
6.9.7 Design Choices Addressing Availability and Resilience
Desired quality | The ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability |
Tactics | Select fault-tolerant hardware |
Use high-availability clustering and load balancing | |
Log transactions | |
Apply software availability solutions | |
Select or create fault-tolerant software | |
Design for failure | |
Allow for component replication | |
Relax transactional consistency | |
Identify backup and disaster recovery solution |
Tactic | Impact on views | |||
---|---|---|---|---|
Functional | Information | Deployment and operation | ||
Use high availability clustering | VE resolution location-oriented (DC A.1) (De 2012) | Information model requires data type for defining scope for location of interest | VE resolution instances for each location cluster | |
VE resolution domain-oriented (DC A.2) (De 2012) | Information model needs data type for defining types of resources | Resolution framework is organised hierarchically | ||
VE resolution semantic web-oriented (DC A.3) (De 2012) | Information model needs to be encoded according to semantic web standards | Search space of resolution framework needs to be indexed by certain machine-learning technique | ||
VE resolution peer-to-peer-oriented (DC A.4) (De 2012) | No impact | No centralised server needed | ||
Use load balancing | Requires function that monitors load of components and triggers load balancing algorithm | Component descriptions need metric to measure current work load and defined load limits | “Scaling out” approach – additional clones of components need to be available (DC A.5) | |
Log transactions | Apply circular logging strategy (IBM 2012) (DC A.6) | Information model needs concepts for transactions with unique identifiers | Storage for transaction logs needed | |
Apply archive logging strategy (IBM 2012) (DC A.7) | Like above, but transactions need to be marked as either active or inactive additionally | External storage needed for large logs | ||
Design for failure | Provide functionality to reserve spare resources and replace failed ones (Newtelligence 2012) (DC A.8) | No impact | Spare resources are kept on hold until an operating resource needs to be replaced, requires higher amount of resources | |
Prefer service choreography FC over service orchestration FC (Sect. 8.2.2.3) | Identifiers in information model need to be unique for clones of FCs and across distributed system | No single FC or centralised FC (DC A.9) | ||
Provide FC that monitors latency (DC A.10) | Provide means to specify latency and timeout limits | No impact | ||
Allow for component replication | Provide FC that implements state-machine (active) replication (Wikipedia 2013d) (DC A.11) | FC needs to be modelled as state- machine | To support F failures you must have at least 2F+1 replicas of the component | |
Provide FC that implement transactional replication (Microsoft 2013) (DC A.12) | Also incremental changes of information can be replicated, leads to inconsistency, though, if not completed | Good performance, near real-time replication possible | ||
Provide FC that implements virtual synchrony (Wikipedia 2013e) (DC A.13) | Make replicated information indistinguishable non-replicated information | Very high performance | ||
Relax transactional consistency (DC A.14) | Requires conflict resolution functionality | No impact | Needs more resources through replication | |
Identify backup and disaster recovery strategy | Preventive measures (DC A.15) | Requires data-replication functionality | Requires consistency among replicated data | Replicated and archived data are stored off-site in the cloud |
Detective measures (DC A.16) | Requires monitoring of indicators for disastrous events | Requires modelling of disastrous events to be looked for and propagation of those | Disaster monitoring needs to be operated independently of components to be monitored | |
Corrective measures (DC A.17) | Requires restoring of previously back-upped configurations | Requires storage of configuration history | Disaster recovery needs to be operated independently of components to be recovered |
6.9.7.1 Use High Availability Clustering
6.9.7.2 Load Balancing
6.9.7.2.1 Logging Transactions
6.9.7.2.2 Design for Failure
6.9.7.2.3 Allowing Component Replication
6.9.7.2.4 Relaxing Transactional Consistency
6.9.7.2.5 Backup and Disaster Recovery Strategy
-
Select fault-tolerant hardware;
-
Apply software availability solutions;
-
Select or create fault-tolerant software.