Unauthorized access to implicit information (e.g. deriving location information
from service access requests) must be restricted at all events. Access control
management as well as the enablement of a scalable and secure key
distribution between communication subjects can be considered to achieve this
objective. In the former case the information stored must be managed in a way
so that the access control mechanism is supported. For deployment of this
function the Authorisation FC (Section 3.7.2) can be considered. For the secure
key distribution the resolution components should be augmented by a Key
Exchange Management component such as the one from IoT-A.
Enable the user to control the privacy settings
Users should be given the opportunity to control their privacy settings. Hence,
one option is the control of acting anonymously. This function can be realised
by integrating the Identity Management FC which creates a fictional identity
(root identity, secondary identity, pseudonym, or group identity) along with the
related security credentials for users and services to use during the
authentication process.
Privacy-aware identification
In human-to-thing and thing-to-thing interactions, privacy-aware identifiers might
be used to prevent unauthorized user tracking. Similarly, authentication can be
used to prove membership of a group without revealing unnecessary
information about an individual. Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) provide the option of only authenticating the
responding host. This way, the initiating host can stay anonymous [Heer
2011].
For most of the tactics a design choice proposal is given, however for different
reasons it is not possible to provide appropriate design choices for all tactics.
The tactics not considered are presented in Table 27 with reasons for the
omission:
Tactic Reason
Validate against requirements Too general, no DC proposal possible.
Consider the impact of
security/performance tradeoffs
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.
Table 27 : Omitted tactics for the Privacy Perspective.5.2.10.7 Design Choices addressing Availability and Resilience
The chapter in this document concerned with the Availability and Resilience
Perspective (Section 4.3.4) lists tactics addressing the desired quality of the
system to be designed as shown in Table 29.