An ARM-Compliant Architecture for User Privacy in Smart Cities: SMARTIE—Quality by Design in the IoT

Table 1

IoT-A tactics for several perspectives and their associated IoT-A and SMARTIE design choices, identified by “DC” and “S-DC,” respectively, for different architectural views. Design choices for SMARTIE are highlighted in italic. The design choices in the Functional View impact the design choices in the Information View and the Deployment and Operation View. In the last view, the design choices indicate the deployment’s FCs that will be affected.

Perspectives	Tactics	Design choices (DC) for views
		Functional	Information	Deployment and Operation
Security (S)	Use access policies	Policy-based service access; (DC S.4)	Stored information must be managed to support access control mechanisms (DC S.6)	Authorization FC; (DC S.7)
			Stored information can be encrypted based on application-level attributes (S-DC S.1)	Key Exchange and Management FC (S-DC S.2) Deploy Authorization FC at end-devices; (S-DC S.3)
	Secure communication infrastructure	End-to-end encryption; (DC S.10)	Information transmission channel for devices or pull communication is secured (S-DC S.4)	End-to-End, Network Communication and Key Exchange and Management FCs (DC S.12)
			Application data is encrypted for push communication (S-DC S.5)	Authorization, DEM, Service Orchestration FCs (S-DC 6)
Evolution and interoperability (EI)	Apply design techniques that facilitate change	Access policies separated from application logic (S-DC EI.1)	Access policies must be in a standard, flexible format (XACML or JSON) (S-DC EI.3)	Authorization FC (S-DC EI.5)
		Access control in devices must not require synchronization from centralized servers (S-DC EI.2)	Authorization information is included in client requests (DCapBAC method) (S-DC EI.4)
Privacy (P)	Minimized unauthorized access to implicit information	Access control management; (DC P.5)	Stored information managed to support access control mechanisms (DC P.6)	Authorization, Key Exchange and Management FCs (S-DC P.2)
			Data is encrypted based on application attributes (CPABE method) (S-DC P.1)
		Enablement of a scalable and secure key distribution between communicating subjects (DC P.8)	Constrained services dynamically learns authorized client’s key based on authorization tokens (S-DC P.3)
	Enable the user to control their privacy settings	Support flexible privacy rules (S-DC P.4)	Privacy rules provided by a Policy Decision Point with a flexible data format (S-DC P.5)	Authorization FC (S-DC P.6)
		Enforce user’s privacy settings through authorization rules at edge devices (S-DC P.7)	Privacy rules translated to rules in authorization tokens for devices (S-DC P.8)
Scalability and performance (SP)	Reduce computation complexity	FC with reduced capabilities (DC SP.14)	No impact	Less functional component deployed (DC SP.15)
		Pushed information is not authorized (S-DC SP.1)	Implicit authorization for pushed information based on attributes (CP-ABE) (S-DC SP.2)	Authorization, Service Orchestration and Key Exchange and Management FCs (S-DC SP.3)
		Authorization server does not synchronize access policies at devices (S-DC SP.4)	No impact	Authorization FC devices (S-DC SP.5)
	Minimize the use of shared resources	Devices do not ask authorization servers for access control decisions (S-DC SP.6)	No impact	Authorization FC devices (S-DC SP.7)
	Optimized repeated processing	Lightweight cryptographic operations for constrained devices (S-DC SP.8)	Cryptography based on lightweight methods (e.g. elliptic curve) for devices (S-DC SP.9)	Authentication, Key Exchange and Management FCs (S-DC SP.10)