Security, Privacy and Trust

Introduction

The Internet of Things (IoT) connects sensors, actuators, embedded controllers, mobile devices, gateways, cloud services and human users into cyber-physical systems. This connectivity creates value through automation, monitoring and data-driven decision-making, but it also expands the attack surface. A compromised temperature sensor may falsify industrial control data; a vulnerable medical device may endanger a patient; a poorly protected smart lock may enable physical intrusion. Security in IoT is therefore not merely an information-technology concern. It is a systems-engineering, safety, privacy, governance and risk-management concern.

IoT security protects devices, communications, software, data and services against unauthorized actions. Privacy governs the collection, use, disclosure, retention and inference of information relating to people. Trust concerns the justified confidence that an entity, device, measurement, platform or process will behave as expected. These ideas overlap but are not identical: an encrypted system may still collect excessive personal data, and a trusted device may become unsafe after a software update.

This chapter develops a lifecycle-oriented understanding of security, privacy and trust. It covers threat modelling, cryptography, identity, secure boot, communication protection, privacy engineering, trust models, risk analysis, governance and practical deployment considerations.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Distinguish security, privacy, safety, resilience and trust in IoT systems.
2. Analyse IoT assets, threats, vulnerabilities, attack paths and risks.
3. Explain the role and limitations of cryptography, identity, secure boot and trusted updates.
4. Apply privacy-by-design principles to sensor and embedded applications.
5. Compare centralized, distributed and reputation-based trust models.
6. Design a defensible security architecture for a constrained IoT deployment.
7. Evaluate governance, ethical, regulatory and professional implications.

1. Security Properties in Connected Embedded Systems

The classical security objectives are confidentiality, integrity and availability, often called the CIA triad.

• Confidentiality means that information is disclosed only to authorized parties. Encryption, access control and secure key management support confidentiality.
• Integrity means that data, code and configuration are not altered without authorization. Message authentication codes, digital signatures, secure boot and tamper detection support integrity.
• Availability means that authorized users and processes can access services when required. Redundancy, rate limiting, recovery procedures and denial-of-service protection support availability.

IoT systems require additional properties:

• Authenticity: an entity or message is genuine and originates from the claimed source.
• Accountability: actions can be associated with responsible identities or components through reliable logging.
• Freshness: a message is recent rather than a replay of an old valid message.
• Safety: failures do not cause unacceptable physical harm.
• Resilience: the system can resist, recover from and adapt to adverse events.
• Non-repudiation: a signer cannot plausibly deny a valid digital signature, subject to sound key protection and legal context.

Security and safety must be considered together. For example, disabling a networked emergency controller during an attack may protect confidentiality but reduce physical safety. Conversely, an emergency override may improve safety while creating a security weakness. Engineering decisions must therefore be based on system hazards and consequences, not on isolated security controls.

Security objectives and controls

2. Threat Modelling and Risk Analysis

A threat model is a structured account of what must be protected, from whom, by what means and under which assumptions. A useful analysis begins with an inventory of assets:

• device firmware, bootloaders and configuration;
• cryptographic keys and credentials;
• sensor readings and actuator commands;
• personal, location and behavioural data;
• gateways, cloud APIs and mobile applications;
• physical processes and safety functions; and
• logs, models and update infrastructure.

Threats are potential causes of harm, while vulnerabilities are weaknesses that allow threats to succeed. An attack is an intentional attempt to exploit a vulnerability. Risk combines the likelihood and consequence of an adverse event. A simple qualitative model is often adequate in early design. For quantitative analysis, expected loss can be represented as:

Here, EL is expected loss in monetary or utility units, p is the probability of the adverse event during a defined period, and I is its impact if it occurs. The model assumes that probability and impact are meaningfully estimated and that one event is being evaluated. It should not be mistaken for a precise prediction when data are sparse.

For multiple mutually exclusive events, an aggregate expected loss is:

where p_i and I_i are the probability and impact of event i. Correlated failures, cascading consequences and uncertainty require more advanced methods such as fault-tree analysis, attack trees, Bayesian networks or Monte Carlo simulation.

A practical threat-modelling process is:

1. Define system boundaries, trust boundaries and safety constraints.
2. Identify assets and their required security properties.
3. Enumerate adversaries, including remote attackers, malicious insiders, counterfeit-device suppliers and physically capable attackers.
4. Map attack surfaces: radio interfaces, debug ports, update channels, APIs, mobile applications, supply chains and administrative consoles.
5. Construct attack paths and identify preconditions.
6. Estimate likelihood, impact and uncertainty.
7. Select controls, assign residual risk and define monitoring.
8. Reassess after architectural, supplier or operational changes.

The STRIDE categories—spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege—are useful for software-oriented analysis. IoT projects should supplement them with physical tampering, sensor spoofing, unsafe actuation, privacy inference and supply-chain compromise.

3. Cryptographic Foundations for IoT

Cryptography supplies mechanisms, not complete security. Its effectiveness depends on correct algorithms, secure implementation, key generation, provisioning, storage, rotation and revocation.

Symmetric cryptography

Symmetric encryption uses the same secret key for encryption and decryption. Authenticated encryption with associated data (AEAD) is generally preferred because it provides confidentiality and integrity together. A typical conceptual operation is:

P is plaintext, K is the secret key, N is a unique nonce, A is authenticated but unencrypted associated data, C is ciphertext and T is an authentication tag. The receiver accepts the message only if tag verification succeeds. The nonce need not be secret, but for schemes such as AES-GCM it must not repeat with the same key. Nonce reuse can seriously undermine security.

Symmetric algorithms are computationally efficient and suitable for constrained devices. Their main distribution problem is that communicating parties must share keys securely. A system with many independently communicating devices also faces key-management complexity.

Asymmetric cryptography

Public-key cryptography uses a public key and a corresponding private key. It supports digital signatures, certificate-based authentication and key establishment. Private keys must remain secret; public keys may be distributed. Asymmetric operations generally require more computation, memory and energy than symmetric operations, although elliptic-curve methods reduce key sizes relative to traditional public-key systems for comparable security levels.

A digital signature provides a mechanism for origin authentication and integrity. It does not, by itself, provide confidentiality, prove that a sensor measurement is physically truthful or guarantee that the signer remains trustworthy.

Hash functions and message authentication

A cryptographic hash maps arbitrary input to a fixed-length digest. Secure hashes are designed to make finding collisions or recovering an input computationally difficult. A message authentication code (MAC) uses a shared key to authenticate a message. Hashes alone do not authenticate an attacker who can replace both message and digest; a keyed MAC or digital signature is required.

Key lifecycle

A professional key-management design addresses generation, provisioning, storage, use, rotation, backup, revocation, recovery and destruction. Keys should be generated using a suitable random source, stored in hardware-backed protected memory where feasible, and separated by purpose. A device identity key, firmware-signing verification key and data-encryption key should not automatically be the same key.

4. Device and Platform Security

Secure boot and measured boot

Secure boot establishes a chain of verification from an immutable or hardware-protected root of trust to the bootloader, operating system and application. Each stage verifies the next stage before execution. This prevents unauthorized firmware from running, provided the root keys and verification logic are protected.

Measured boot records cryptographic measurements of software rather than necessarily blocking execution. A remote verifier can use these measurements to assess platform state. Secure boot answers “may this code execute?”; measured boot helps answer “what code was executed?”

Hardware roots of trust

Trusted platform modules, secure elements, hardware security modules and processor security extensions can protect keys and perform cryptographic operations. They reduce exposure to software compromise but do not eliminate vulnerabilities in firmware, protocols or physical design. Hardware security must be evaluated against the attacker model, cost, performance and lifecycle.

Debug and physical interfaces

JTAG, UART, test pads, boot-select pins and removable storage are valuable during development but dangerous in production. Controls include disabling or authenticating debug access, locking boot modes, encrypting sensitive storage, detecting enclosure opening and applying least privilege. Physical protection is not absolute: a determined attacker with prolonged access may extract secrets through side channels, fault injection or invasive analysis.

Secure updates

Devices require a trustworthy update mechanism because vulnerabilities are discovered after deployment. A robust process includes signed firmware, version and rollback protection, authenticated update servers, failure recovery, staged deployment, audit records and a defined end-of-support policy. Update signing keys should be protected separately from ordinary development systems. Rollback protection must be balanced against emergency recovery; an irreversibly blocked device can become a safety and availability problem.

5. Network and Application Security

IoT architectures commonly contain device, edge, cloud and management planes. Each plane should have explicit identities, authorization rules and trust boundaries. Flat networks allow compromise of one device to spread laterally. Segmentation, gateway mediation, firewall policy and deny-by-default communication reduce this risk.

Mutual authentication is important where both endpoint and server must verify one another. Transport protection such as TLS or DTLS can provide confidentiality and integrity, but configuration matters: certificate validation must be enforced, obsolete algorithms disabled and credentials protected. Application-layer authorization remains necessary after a secure channel is established.

Access control should follow least privilege. Role-based access control assigns permissions to roles; attribute-based access control evaluates properties such as device type, location, time, risk state and command sensitivity. Actuator commands may require stronger authorization than ordinary telemetry. A policy should specify who may perform which operation, on which resource, under what conditions and with what audit requirement.

Logging and monitoring should capture authentication events, configuration changes, update outcomes, unusual traffic and safety-relevant commands. Logs should be time-consistent, protected against alteration and retained only as long as justified. Security monitoring must account for intermittent connectivity and constrained storage by using local buffering, event prioritization and secure forwarding.

6. Privacy in IoT Systems

IoT privacy is broader than secrecy. Even encrypted data can reveal routines through metadata, timing, location, device identifiers or traffic volume. Sensor fusion can infer health conditions, occupancy, relationships and habits from apparently harmless measurements.

Important privacy principles include:

• Purpose limitation: collect and use data for specified legitimate purposes.
• Data minimization: collect the least data needed for the function.
• Accuracy: correct data that could produce harmful decisions.
• Storage limitation: define retention and deletion rules.
• Transparency: explain data practices in an understandable form.
• User control: provide meaningful consent, access, correction and objection mechanisms where applicable.
• Privacy by design and default: incorporate safeguards from architecture through disposal.
• Accountability: document decisions, responsibilities, assessments and evidence.

Consent is not a universal solution. It may be invalid where users lack a genuine choice, where notices are incomprehensible or where data are repurposed later. Designers should distinguish directly identifying data, pseudonymized data and anonymized data. Pseudonymization reduces direct identification but does not make re-identification impossible; auxiliary datasets may restore identity.

Privacy-enhancing techniques include local processing, aggregation, access-controlled storage, differential privacy, secure multiparty computation and federated learning. Each involves trade-offs. Differential privacy introduces controlled randomness and protects aggregate disclosure under a formal privacy model, but excessive noise can reduce utility. Federated learning keeps raw data at local nodes but still requires protection against model inversion, poisoning and leakage through updates.

A privacy impact assessment should document data flows, purposes, stakeholders, legal basis where relevant, risks to individuals, controls, retention and residual risk. It should be repeated when sensors, analytics, vendors or purposes change.

7. Trust Models and Trust Management

Trust is a relational and context-dependent expectation, not merely a binary device label. A device may be trusted for temperature reporting but not for firmware installation. Trust should therefore be scoped by action, time, evidence and context.

Forms of trust

• Identity trust: confidence that an entity is who it claims to be.
• Platform trust: confidence in the device’s software and hardware state.
• Data trust: confidence in provenance, integrity, quality and freshness.
• Behavioural trust: confidence based on observed past conduct.
• Institutional trust: confidence in the organization operating a service.
• Social or user trust: confidence based on experience, transparency and perceived fairness.

A centralized trust model uses a certificate authority, identity provider or trusted service. It is administratively efficient but creates dependence on central infrastructure. A distributed model uses peer evidence, threshold decisions or distributed ledgers, but can increase communication, storage, governance and privacy costs. Reputation systems aggregate reports about behaviour. They are vulnerable to collusion, false reporting, Sybil identities and new devices that lack history.

Trust decisions should use evidence quality, not only numerical scores. Evidence may include attestation, signed firmware measurements, certificate status, recent behaviour, physical location and operator authorization. A trust score can assist prioritization, but it should not replace explicit safety constraints or policy decisions. In safety-critical applications, failure of the trust service should produce a defined safe state rather than arbitrary permission.

8. A Layered Security Architecture

A defensible IoT architecture uses defence in depth:

1. Governance layer: ownership, risk appetite, policies, procurement requirements and incident responsibilities.
2. Device layer: secure identity, protected keys, secure boot, minimized services, locked debug interfaces and tamper response.
3. Communication layer: authenticated encryption, replay protection, segmentation and traffic monitoring.
4. Edge layer: protocol translation, local authorization, filtering, buffering and safe operation during cloud loss.
5. Cloud and application layer: API security, tenant isolation, authorization, secure storage and anomaly detection.
6. Operations layer: vulnerability management, updates, inventories, backups, incident response and decommissioning.
7. Human layer: training, usable consent, administrator separation and clear accountability.

No layer is sufficient alone. Encryption cannot compensate for an exposed private key; strong authentication cannot compensate for unsafe actuator logic; a privacy notice cannot compensate for unnecessary collection.

9. Worked Application: Risk-Based Protection of a Smart Water Network

Consider an illustrative municipal water network containing pressure sensors, chlorine sensors, remotely controlled valves, wireless field gateways and a cloud dashboard. Operators use the dashboard to identify leaks and issue valve commands.

Background and problem

The operator initially installs identical passwords on field gateways, leaves maintenance ports enabled and sends telemetry without application-layer integrity protection. The cloud service accepts commands from any authenticated dashboard account. The system is functional but vulnerable to credential theft, replay, lateral movement and unsafe commands.

Analysis

Key assets are water quality data, valve control, gateway credentials, firmware and operator records. Threats include remote compromise, insider misuse, physical tampering, sensor spoofing and denial of service. The highest-impact event is an unauthorized valve command that disrupts supply. A replayed “close valve” message is possible even if the original message was authentic, so freshness is required.

Suppose a preliminary assessment estimates an annual probability of 0.02 for a major unauthorized actuation and an impact of £500,000. The simple expected annual loss is:

This estimate is not a complete investment justification. It excludes cascading effects, uncertainty, regulatory penalties and non-monetary harm. It nevertheless helps compare controls and prioritize engineering effort.

Approach and solution

The operator creates unique device identities using certificates and protects private keys in secure elements. Gateways establish mutually authenticated encrypted sessions. Every command includes a sequence number or nonce, an expiration condition and a command identifier; the receiver rejects duplicates and stale commands. Operators receive role-based permissions, and high-impact commands require dual authorization or an independent safety interlock.

The field network is segmented from corporate IT. Secure boot prevents unauthorized gateway firmware, while signed updates support vulnerability remediation. Local control logic places valves in a defined safe state when cloud connectivity fails. Sensor data are signed or authenticated at the gateway, and plausibility checks compare pressure, flow and valve state rather than trusting a single sensor.

Logs record identity, command, time, approval and result. Access to detailed operator activity is restricted and retention is limited. Incident procedures define isolation, manual operation, evidence preservation and public communication.

Outcome and learning points

The revised design reduces credential reuse, replay, lateral movement and uncontrolled actuation. It does not eliminate risk: insiders may misuse valid privileges, sensors may fail, and supply-chain compromise remains possible. The central lesson is that security controls must be connected to physical consequences, operational procedures and privacy governance. The system must remain safe when authentication services, networks or cloud analytics are unavailable.

10. Governance, Ethics and Regulation

IoT governance assigns responsibility across manufacturers, integrators, operators, cloud providers and users. Procurement contracts should require vulnerability disclosure, software bills of materials, update support periods, secure development evidence, incident notification and deletion or return of data. A software bill of materials improves visibility of third-party components and supports vulnerability response, although it does not prove that components are secure.

Security development should include requirements analysis, code review, static and dynamic testing, fuzzing, penetration testing, dependency management and independent assessment for high-risk systems. Compliance with a standard or certification can provide evidence of process, but it is not equivalent to security in every deployment.

Ethically, designers must consider surveillance, discrimination, unequal access, worker monitoring, environmental cost and the consequences of false alarms or automated decisions. A system that is technically secure but coercive or unjust is not socially trustworthy. Privacy and security decisions should be documented, reviewable and proportionate.

Legal requirements vary by jurisdiction and sector. Relevant obligations may concern data protection, critical infrastructure, medical devices, telecommunications, product liability, incident reporting and consumer protection. Engineers should obtain jurisdiction-specific advice rather than treating a general security framework as legal compliance.

11. Contemporary Developments and Research Directions

Postgraduate practice must account for several evolving issues:

• Post-quantum cryptography: future quantum computers threaten widely used public-key schemes. Migration requires inventory, crypto-agility and attention to constrained-device performance.
• Artificial intelligence in defence: machine learning can detect anomalies and classify malware, but adversarial examples, biased data, model drift and opaque decisions require controls.
• AI-enabled attacks: attackers can automate vulnerability discovery, phishing, code generation and synthetic identities.
• Digital twins: virtual representations improve maintenance but create new confidentiality, integrity and model-manipulation risks.
• Zero-trust architectures: continuous verification and least privilege are useful for distributed IoT, but device constraints and intermittent links require adaptation.
• Confidential computing and remote attestation: protected execution and evidence of platform state may strengthen cloud-edge trust, although attestation semantics and supply chains remain difficult.
• Lifecycle sustainability: security updates, secure disposal and hardware replacement have environmental and economic consequences.

Research questions include how to quantify trust under uncertainty, how to preserve privacy in multimodal sensor fusion, how to secure collaborative learning, and how to verify AI-controlled cyber-physical systems.

12. Best-Practice Checklist

Before deployment, an engineering team should be able to answer “yes” or document an accepted exception to the following questions:

1. Are all devices, software components, data flows and owners inventoried?
2. Are safety, security and privacy requirements traceable to risks?
3. Does each device have a unique identity and protected credentials?
4. Are secure boot, signed updates and rollback policies implemented appropriately?
5. Are communication channels authenticated, encrypted and protected against replay?
6. Are privileges minimized and high-impact commands independently constrained?
7. Are debug interfaces and default credentials removed or controlled?
8. Are data collection, retention, access and deletion justified and documented?
9. Can the system operate safely during cloud, network or trust-service failure?
10. Are monitoring, incident response, vulnerability disclosure and end-of-life procedures tested?

Chapter Summary

IoT security, privacy and trust are interdependent system properties. Security protects confidentiality, integrity, availability, authenticity and accountability, while safety and resilience connect cyber events to physical consequences. Threat modelling identifies assets, adversaries, vulnerabilities and attack paths; risk analysis helps prioritize controls but must acknowledge uncertainty and cascading effects. Cryptography provides encryption, authentication and integrity only when keys, nonces, identities and implementations are managed correctly. Secure boot, hardware roots of trust, protected debug interfaces and signed updates establish device and software assurance.

Privacy requires purpose limitation, minimization, transparency, retention control and accountability because sensor data can reveal sensitive patterns even when encrypted. Trust is contextual and should be based on evidence, policy and defined consequences rather than an unexplained score. Layered architectures combine device protection, secure communications, segmentation, authorization, monitoring, governance and safe failure. Effective professional practice extends across the complete lifecycle—from procurement and design to operation, incident response and decommissioning—and must address ethics, regulation, supply chains and emerging technologies.

Key Terms

Authenticated encryption: Encryption that provides confidentiality and integrity authentication together.

Attack surface: The collection of interfaces and components through which a system may be attacked.

Availability: The property that authorized users can access a service when required.

Confidentiality: Protection against unauthorized disclosure of information.

Differential privacy: A formal privacy approach that limits the effect of one individual’s data on released results.

Firmware: Software stored in or closely associated with embedded hardware.

Freshness: Assurance that a message is recent and not a replay of an earlier message.

Integrity: Assurance that data or code has not been altered without authorization.

Least privilege: Granting only the permissions necessary for an authorized task.

Mutual authentication: A protocol process in which both communicating parties authenticate one another.

Nonce: A value intended for one-time use in a cryptographic operation.

Privacy by design: Integrating privacy safeguards throughout system design and lifecycle management.

Risk: The possibility of harm resulting from threats exploiting vulnerabilities, commonly assessed through likelihood and impact.

Secure boot: Verification of software before it is allowed to execute.

Security boundary: A point separating components with different trust or protection assumptions.

Threat model: A structured description of assets, adversaries, vulnerabilities, attack paths and assumptions.

Trust: Context-dependent confidence that an entity, process or measurement will behave as expected.

Trusted update: An update process that authenticates, authorizes and safely installs new software.

Vulnerability: A weakness that can be exploited to violate a security, privacy or safety requirement.

Review Questions

Short Answer Questions

1. Distinguish confidentiality, integrity and availability in an IoT system.
2. Why is nonce reuse dangerous in authenticated encryption?
3. What is the difference between secure boot and measured boot?
4. Explain why pseudonymized data are not necessarily anonymous.
5. State two reasons why trust in IoT should be context-dependent.

Long Answer Questions

1. Explain a complete threat-modelling process for a connected medical device.
2. Discuss the cryptographic and operational requirements of an IoT key lifecycle.
3. Compare centralized, distributed and reputation-based trust models, including their limitations.
4. Develop a privacy-by-design architecture for a smart-home sensing application.
5. Explain how security, safety and resilience should be integrated in a cyber-physical system.

Analytical / Application Questions

1. A fleet contains 10,000 sensors, each with an estimated annual compromise probability of 0.001. Assuming independent events, calculate the expected number of compromised sensors and discuss why independence may be an unrealistic assumption.
2. Design an authorization and replay-protection scheme for a remotely controlled industrial actuator. Identify the identity, authorization, freshness, logging and safe-failure mechanisms.
3. A city wants to use Wi-Fi occupancy data to optimize public transport. Analyse the privacy risks, propose minimization and aggregation measures, and identify residual risks that cannot be removed completely.

Multiple Choice Questions with Answers

Question 1

Which property ensures that an IoT message has not been altered during transmission?

A. Integrity

B. Availability

C. Anonymity

D. Redundancy

Correct Answer: A. Integrity

Question 2

In authenticated encryption, why must a nonce generally not repeat with the same key?

A. Nonce repetition can undermine the security guarantees of the scheme

B. A repeated nonce makes the key public by definition

C. Nonce repetition prevents any receiver from decrypting data

D. A nonce must always be kept secret

Correct Answer: A. Nonce repetition can undermine the security guarantees of the scheme

Question 3

What is the main purpose of secure boot?

A. To verify software before allowing it to execute

B. To compress firmware before storage

C. To increase wireless bandwidth

D. To anonymize sensor data

Correct Answer: A. To verify software before allowing it to execute

Question 4

Which statement about pseudonymization is correct?

A. It reduces direct identification but does not guarantee irreversibility of identification

B. It permanently destroys all links to an individual

C. It provides encryption without requiring keys

D. It eliminates the need for access control

Correct Answer: A. It reduces direct identification but does not guarantee irreversibility of identification

Question 5

An event has probability 0.02 and impact £500,000. What is its simple expected loss?

A. £1,000

B. £10,000

C. £25,000

D. £100,000

Correct Answer: B. £10,000

Question 6

Which control most directly addresses replay of an old valid actuator command?

A. A larger display

B. A nonce, sequence number or freshness check

C. Data compression

D. A longer device name

Correct Answer: B. A nonce, sequence number or freshness check

Question 7

What does least privilege require?

A. Every device should have administrator access

B. Users and processes receive only the permissions needed for authorized tasks

C. All services should use the same account

D. Access permissions should never be reviewed

Correct Answer: B. Users and processes receive only the permissions needed for authorized tasks

Question 8

Which statement best describes measured boot?

A. It records measurements of loaded software for later assessment

B. It automatically encrypts every network packet

C. It deletes firmware after every restart

D. It prevents all physical attacks

Correct Answer: A. It records measurements of loaded software for later assessment

Question 9

Why can a trusted device still produce untrustworthy sensor data?

A. Cryptographic authenticity does not prove that the physical measurement is truthful

B. Trusted devices cannot use encryption

C. Trust automatically disables calibration

D. Sensor data never require integrity protection

Correct Answer: A. Cryptographic authenticity does not prove that the physical measurement is truthful

Question 10

Which is an appropriate privacy-by-design practice?

A. Collect every available sensor stream indefinitely

B. Collect only data necessary for a specified purpose and define retention limits

C. Publish raw identifiers to improve transparency

D. Treat consent as unnecessary in every application

Correct Answer: B. Collect only data necessary for a specified purpose and define retention limits