176
Internet of Things (IoT)
have a high interest that no single one of them controls access to S, or could prevent it from
working. This requirement will be discussed in detail in the next chapters.
9.2.1.2.3 Integrity
S shall offer data integrity, including authenticity of data origin. All unauthorized
changes to the data stored in S should be detectable by a client via means integrated
into S. S should also prevent spamming and pharming attacks, which aim to add arbitrary, non-authorized data entries to S. All of those also will be assumed common
requirements of all stakeholders.
In addition, there are special cases where data integrity may need to be enforced by
system integrity in lower-level design steps; for example, to deliver authentic messages
on non existence of records or during the publishing phase, where the system node that
is contacted for publishing needs to be authentic. Data integrity should also include a
measure to assess the age of data, as well as provide nonrepudiation, i.e., the fact that a
provider published exactly these data should be provable to third parties, for example, for
auditing or legal purposes.
9.2.1.2.4 Confidentiality
In classical security engineering, confidentiality requirements usually have been considered only for the information provider or server side of an Internet service, such as confidentiality enforced by access control for the data offered by a Web server. This provider
perspective also applies to ubiquitous computing environments and the IoT, but is far from
complete. Clients of IoT services are also stakeholders whose security requirements need
to be accounted for.
Stakeholder confidentiality requirements on the client side of S, however, usually do not
only refer to data processed in a system, but also to high-level information (e.g., turnover
or lifestyle) inferable from using the system, and multiple entities (persons, organizations,
competitors, criminals, the public) from whom that information must be kept confidential
(counter-stakeholders).
As an example, consider the use of RFID, IoT, and the name service S in a smart home
owned by an individual, Bob Concerned, and on a shop floor (Figure 9.5). Bob Concerned
practices a lifestyle he wants to keep confidential from others (Figure 9.5a). These others are the counter-stakeholders of his confidentiality requirements, including neighbors,
marketing companies, and governments, or other entities who adopt functional roles in
the IoT (Table 9.1). The shop has confidentiality goals that have a similar structure to Bob’s
goals (Figure 9.5b). For example, the shop produces turnover that it wants to keep confidential from competing shops.
Many of those high-level information assets may be inferable—simply from the observation of queries to S, by using query data analysis and mining from content, location,
time, frequency, clusters of queries, and changes over time. For example, lifestyle can be
inferred by analyzing which item brands are in regular use at Bob’s home and are creating
periodic query patterns to the IoT, or how often new and potentially expensive or cheap
items are detected by his RFID readers, while EPCs are resolved to retrieve item information for smart home services. Similarly, the shop’s turnover can be inferred by observing
periodic inventory queries to the IOT, watching for specific brands, items missing, returns,
or new arrivals. However, Bob Concerned or the shop may not even be aware of the data
traces that they are producing in their smart environments equipped with RFID readers, and across IOT name and information servers, simply by querying and retrieving
item-related information. Therefore, it will become very difficult for security engineering
Internet of Things (IoT)
have a high interest that no single one of them controls access to S, or could prevent it from
working. This requirement will be discussed in detail in the next chapters.
9.2.1.2.3 Integrity
S shall offer data integrity, including authenticity of data origin. All unauthorized
changes to the data stored in S should be detectable by a client via means integrated
into S. S should also prevent spamming and pharming attacks, which aim to add arbitrary, non-authorized data entries to S. All of those also will be assumed common
requirements of all stakeholders.
In addition, there are special cases where data integrity may need to be enforced by
system integrity in lower-level design steps; for example, to deliver authentic messages
on non existence of records or during the publishing phase, where the system node that
is contacted for publishing needs to be authentic. Data integrity should also include a
measure to assess the age of data, as well as provide nonrepudiation, i.e., the fact that a
provider published exactly these data should be provable to third parties, for example, for
auditing or legal purposes.
9.2.1.2.4 Confidentiality
In classical security engineering, confidentiality requirements usually have been considered only for the information provider or server side of an Internet service, such as confidentiality enforced by access control for the data offered by a Web server. This provider
perspective also applies to ubiquitous computing environments and the IoT, but is far from
complete. Clients of IoT services are also stakeholders whose security requirements need
to be accounted for.
Stakeholder confidentiality requirements on the client side of S, however, usually do not
only refer to data processed in a system, but also to high-level information (e.g., turnover
or lifestyle) inferable from using the system, and multiple entities (persons, organizations,
competitors, criminals, the public) from whom that information must be kept confidential
(counter-stakeholders).
As an example, consider the use of RFID, IoT, and the name service S in a smart home
owned by an individual, Bob Concerned, and on a shop floor (Figure 9.5). Bob Concerned
practices a lifestyle he wants to keep confidential from others (Figure 9.5a). These others are the counter-stakeholders of his confidentiality requirements, including neighbors,
marketing companies, and governments, or other entities who adopt functional roles in
the IoT (Table 9.1). The shop has confidentiality goals that have a similar structure to Bob’s
goals (Figure 9.5b). For example, the shop produces turnover that it wants to keep confidential from competing shops.
Many of those high-level information assets may be inferable—simply from the observation of queries to S, by using query data analysis and mining from content, location,
time, frequency, clusters of queries, and changes over time. For example, lifestyle can be
inferred by analyzing which item brands are in regular use at Bob’s home and are creating
periodic query patterns to the IoT, or how often new and potentially expensive or cheap
items are detected by his RFID readers, while EPCs are resolved to retrieve item information for smart home services. Similarly, the shop’s turnover can be inferred by observing
periodic inventory queries to the IOT, watching for specific brands, items missing, returns,
or new arrivals. However, Bob Concerned or the shop may not even be aware of the data
traces that they are producing in their smart environments equipped with RFID readers, and across IOT name and information servers, simply by querying and retrieving
item-related information. Therefore, it will become very difficult for security engineering