w2 Securing the Internet of Things - Lecture 1: The Ten Security Principles & Smart Home Privacy

Lecture Overview and Learning Objectives

• Context and Significance: This lecture builds upon the foundational knowledge of Internet of Things (IoT) security established in the previous week. It transitions from understanding what IoT security is and why it matters (recalling attacks like Mirai, Verkada, and Target) to the fundamental rules that guide the design of security systems.

• The Ten Security Principles: These principles are time-tested rules developed over decades. They serve as the "building codes" for security, intended to be followed from the start of the design phase rather than patching problems after they occur.

• Smart Home Privacy: The lecture moves beyond basic security controls to examine how smart home devices can leak private activities through encrypted traffic, and how "traffic shaping" can mitigate these risks.

• Core Learning Outcomes:

  • Identify and explain the ten fundamental security design principles.

  • Apply these principles to real-world IoT scenarios and identify violations.

  • Distinguish between local and external network adversaries.

  • Describe how encrypted smart home traffic reveals private activities.

  • Compare privacy defense techniques and their associated trade-offs.

  • Explain the role of traffic shaping (specifically Stochastic Traffic Padding) in protecting user privacy.

The Ten Security Design Principles: Core Concepts

• Definition: Rules that guide every security decision. If a design violates even one principle, it creates a vulnerability for attackers.

• Summary Table of Principles:

  1. Economy of Mechanism: Keep security designs simple; complexity increases vulnerabilities.

  2. Fail-Safe Defaults: Start with access denied; only grant permissions explicitly.

  3. Complete Mediation: Check every access attempt every single time.

  4. Open Design: Security must depend on the secrecy of keys/passwords, not the secrecy of the design itself.

  5. Separation of Privilege: Require multiple conditions or markers before granting access.

  6. Least Privilege: Provide only the minimum permissions necessary for a task.

  7. Least Common Mechanism: Minimize shared resources or communication paths between different users/devices.

  8. Usable Security (Psycological Acceptability): Security must be intuitive; inconvenient security will be bypassed by users.

  9. Work Factor: Match the strength of security to the value of the protected asset.

  10. Compromise Recording: Maintain detailed logs to detect, understand, and prevent future attacks.

Principle 1: Economy of Mechanism

• Definition: Security systems should be as simple as possible in design and implementation.

• Rationale: Simple designs are easier to build, test, and verify. Complex systems hide bugs, and bugs eventually become security vulnerabilities.

• Simplicity vs. Complexity:

  • Simple Designs: Easier for developers to implement correctly, easier for security teams to verify, fewer user errors, and faster to patch.

  • Complex Designs: More places for bugs to hide, harder to verify every path, higher probability of user mistakes, and high risk that fixing one part will break another.

• IoT Example: Smart Lock Encryption:

  • Simple Approach: Using a well-tested method like $AES-128$ for all communications.

  • Complex Approach: Using three different encryption methods depending on connection type with custom switching logic. This introduces more code and logic where things can fail (e.g., a bug in the code that defaults to unencrypted communication).

• Key Lesson: Every additional feature is a potential hiding place for a bug. A lock supporting WiFi, Bluetooth, Zigbee, NFC, and a web API must secure each independently; a single bug in any one compromises the whole device.

Principle 2: Fail-Safe Defaults

• Definition: The default configuration should deny access. Permissions must be explicitly granted.

• Safe Failure: If a system fails, it should fail in a secure state (e.g., a door staying locked) rather than an open state.

• Comparison of Defaults:

  • Bad Defaults (Vulnerable): Default passwords like "admin/admin", all ports open by default, encryption turned off, and full admin rights for all users.

  • Good Defaults (Secure): Unique passwords per device required to be changed on first use, all ports closed by default, encryption enabled, minimal read-only access, and rejection of unknown connections.

• IoT Industry Reality: Many manufacturers prioritize usability over security (the "it just works" philosophy), leaving devices open out of the box. The Mirai botnet specifically exploited factory default passwords that were never changed.

• Smart Home Hub Example: Adding a new family member should start with zero access, with the administrator specifically granting access to specific cameras or locks.

Principle 3: Complete Mediation

• Definition: Every request to access a resource must be checked against security rules every time. The system must never assume that a previous approval is still valid.

• Risks of "Check Once":

  • A fired employee might still have an active session to company IoT systems.

  • A cached login on a stolen phone could give a thief unlimited access to a home.

  • A device might check permissions at boot; if permissions are revoked while running, the device would never notice.

• Common Applications:

  • Online Banking: Forcing re-login after several minutes of inactivity.

  • Smart Door Locks: Checking ID cards every single time a person taps, even if they just entered the door a minute prior. It asks: "Is this person allowed right now?"

• Trade-off: The performance cost of re-checking is negligible compared to the risk of unauthorized access.

Principle 4: Open Design

• Definition: Security should rely on keeping keys and passwords secret, not on keeping the algorithm or design secret.

• Comparison of Security Philosophies:

  • Security by Obscurity (Ineffective): Reliance on the attacker not knowing how encryption works. Attackers eventually reverse-engineer the design, and because the design was the only protection, the entire system breaks.

  • Open Design (Effective): Designs are public and tested by experts. Weaknesses are found and fixed early. Knowing the design does not help an attacker break the system without the secret key.

• Comparison of Standards:

  • AES (Advanced Encryption Standard): Publicly documented and unbroken after decades because its security is key-dependent.

  • KeeLoq: A proprietary system used in car key fobs (Toyota, Volvo, Volkswagen). It was secret for nearly $20$ years. Once researchers discovered the algorithm, they broke the system within $2$ years. Expert quote: "If they had made it public they would have found out $20$ years ago that it is insecure."

Scenario Review: Hardware Constraints and Fail-Safe Logic

• Scenario 1: Hospital Patient Monitors: A low-power monitor cannot transmit data and perform encryption re-verification simultaneously, causing a $2\,s$ pause in vital signs. The medical team objects to the security team's demand for Complete Mediation every $30\,s$.

  • Solution: Option A - Replace the monitors with multi-thread processors. In IoT, if hardware cannot support a security requirement, the hardware must be upgraded. Principles do not override safety, but abandoning security (verifying only at startup) leaves the monitor vulnerable to hijacked sessions forever.

• Scenario 2: Smart Door Lock Fail-Soft: A lock is designed to unlock if the cloud server fails (to prevent lockouts).

  • Analysis: Option B - The real problem is design complexity (Economy of Mechanism). A door lock should not depend on a cloud server for basic functionality. It should use local methods (Bluetooth, keypad, physical key). A $99.9\%$ uptime results in roughly $9\,h$ of annual downtime where the home is unprotected. Conversely, "fail-locked" could trap people during fire emergencies.

Principle 5: Separation of Privilege

• Definition: Access to sensitive resources should require meeting multiple conditions (multi-factor authentication/multi-condition access).

• Examples:

  • Weak: Password only.

  • Strong: Password + SMS code; Physical key + fingerprint + security guard check; API key + device certificate + IP address verification.

• Industrial Scenario: A factory robot shutdown should require an operator account, a physical key turn, and supervisor confirmation. This prevents a single stolen password from stopping production.

Principle 6: Least Privilege

• Definition: Every user, program, and device should have only the minimum permissions needed to perform its specific task.

• IoT Examples:

  • Smart Thermostat: Needs to read temp/control HVAC; should not have access to camera feeds or door locks.

  • Guest WiFi: Needs internet access; should not see local smart home devices.

  • Target Breach Detail: The initial breach happened because an HVAC contractor had network access exceeding their maintenance needs, allowing attackers to reach payment systems.

Principle 7: Least Common Mechanism

• Definition: Minimize shared paths, channels, or interfaces between users/devices to prevent shared risks.

• Mitigation Strategies:

  • Unified Accounts: Avoid using one admin account; give each user unique permissions to track actions.

  • IoT Network Segmentation: Place security cameras, HVAC, and computers on separate VLANs (Virtual Local Area Networks). If a thermostat is compromised, the attacker cannot reach employee files.

  • App Passwords: Avoid using one master password for all smart home apps; use unique passwords per app.

Principle 8: Usable Security

• Definition: Security settings must be intuitive and easy to use. If security is annoying, people will find workarounds (e.g., writing passwords on sticky notes or disabling features).

• Effective Design: Fingerprint scans are faster and more secure than keys; background updates keep devices patched without user effort.

• Key Question: "Will a regular person actually use this correctly?"

Principle 9: Work Factor

• Definition: Compare the cost of breaking security to the resources of the attacker and the value of the asset.

• Security Level Examples:

  • Grades Database: Standard encryption and audit logs; targets are students/amateur hackers.

  • Hospital Monitoring: Strong encryption and network isolation; targets are ransomware groups.

  • Power Grid: Air-gapped networks and $24/7$ monitoring; targets are nation-state actors.

• Comparison: A bank vault door belongs on a bank, not a bedroom. However, even a smart coffee maker needs some security to prevent it from being used as a launchpad for other network attacks.

Principle 10: Compromise Recording

• Definition: It is impossible to prevent every attack; therefore, you must record details to detect and analyze breaches.

• Vital Logs:

  • Login Attempts: Who, when, where (success/failure) to detect brute-force.

  • Configuration Changes: Old vs. new values to detect tampering.

  • Network Traffic: Destinations and volumes to detect data theft.

  • Firmware Updates: Source and success rates to detect malicious modifications.

• Breach Containment Stat: According to an IBM $2025$ report, the average breach takes $241$ days (roughly $8$ months) to contain. If logs are deleted after $30$ days, evidence of the breach is lost before it is even discovered.

Case Study: Smart Home Privacy Attack (2019)

• The Paradox: A system can implement encryption, authentication, and access control perfectly and still leak private behavior.

• Findings: An attacker can watch the amount of data and the timing of traffic (traffic patterns) to reconstruct daily routines without seeing the content of the data.

• The Scenario (Sara's Evening):

  • $7:00\,PM$: High camera data upload $\rightarrow$ Sara is home.

  • $7:05\,PM$: Upload/download burst on smart speaker $\rightarrow$ Sara asked a question.

  • $7:10\,PM$: Tiny spike from smart plug $\rightarrow$ Sara turned on a lamp.

  • $11:30\,PM$: Smart plug spike + steady data from sleep monitor $\rightarrow$ Sara went to bed.

  • $6:00\,AM$: Sleep monitor stops + speaker/plug bursts $\rightarrow$ Sara woke up and checked the weather.

Adversary Types in Traffic Analysis

• Local Adversaries: Neighbors or someone in range of WiFi signals. They see MAC addresses (device IDs), WiFi packet sizes, and timing.

• External Adversaries: Internet Service Providers (ISPs) or intelligence agencies. They see times, sizes, and IP headers. While they don't see MAC addresses, they can identify devices by the cloud servers they connect to (e.g., Nest, Ring, Philips).

• Vulnerability of IoT: Unlike laptops which do many things at once (mixing traffic), an IoT device does one thing. A sleep monitor sending data means one thing: the user is sleeping.

Privacy Defense Strategies

• Firewall Blocking: Perfect against external snooping, but most devices stop working without internet.

• VPN (Virtual Private Network): Hides device details but does not hide traffic volume spikes.

• ILP (Independent Link Padding): Force devices to send data at a constant rate. Excellent privacy but wastes massive bandwidth and causes latency.

• STP (Stochastic Traffic Padding): The proposed research solution. It inserts random fake traffic bursts that mimic real device activity.

Stochastic Traffic Padding (STP) Performance

• Mechanism: The attacker sees many bursts and cannot distinguish real activity from fake ones.

• Attacker Confidence Levels:

  • $50\%$ Confidence: Attacker is right half the time (coin-flip level).

  • $10\%$ Confidence: Attacker is right $1/10$ times (nearly useless).

• Bandwidth Costs (Extra Data for $50\%$ Confidence):

  • Sleep Monitor: $1.07\times$ ($7\%$ extra); $0.42\,bytes/sec$.

  • Smart Plug: $1.68\times$ ($68\%$ extra); $0.80\,bytes/sec$.

  • Smart Speaker: $1.63\times$ ($63\%$ extra); $3.2\,bytes/sec$.

• Bandwidth Costs (Extra Data for $10\%$ Confidence):

  • Sleep Monitor: $1.44\times$; $2.4\,bytes/sec$.

  • Smart Plug: $6.17\times$; $6.0\,bytes/sec$.

  • Smart Speaker: $4.72\times$; $19\,bytes/sec$.

• Industry Gap: Even though protection costs less than $20\,bytes/sec$ (smaller than a tweet), no major manufacturer has implemented this as of $2025$.

Summary of Security vs. Privacy

• Security principles (Principles 1-10) protect access and content.

• Privacy requires protecting behavior and patterns.

• Defense-in-depth is the best approach: Encryption + VPN + Traffic Padding.

• Core Message: "Complexity is the worst enemy of security."