IOT SECURITY INSEM NOTES

1. Security Requirements in IoT Architecture (6 Marks)

Answer:

 IoT follows 3-layer architecture (Perception/Network/Application) or 5-layer model;

security must be implemented at every layer.

 Confidentiality → Sensitive data (health metrics, location) hidden from unauthorised

users using encryption (AES/DTLS).

 Integrity → Data not altered by MITM; use hashing + MAC to detect tampering.

 Availability → Devices always accessible; protect against DDoS & jamming attacks.

 Authentication → Verify identity of device/user (digital certificates, passwords, MFA).

 Authorization → Grant specific rights after authentication (RBAC/ABAC model).

 Non-repudiation → Sender cannot deny action (digital signatures + timestamps).

Diagram tip: Draw 3-layer IoT stack & label security mechanisms on each layer.

2. Security in Enabling Technologies (6 Marks)

Answer:

 IoT depends on RFID/NFC, WSN, Cloud & protocols; each needs tailored security.

 RFID/NFC Security → Mutual authentication + cryptographic tags to prevent cloning

& relay attacks.

 Wireless Sensor Network (WSN) → Lightweight ECC encryption for resource-

constrained nodes.

 Cloud Computing → Secure APIs, encryption at rest, role-based access controls.

 Communication Protocols → Use TLS for MQTT & DTLS for CoAP to secure
transmission.

 Overall → End-to-end encryption + key management essential because devices are

heterogeneous & low-power. Keyword: Lightweight cryptography for enabling tech.

3. Security Concerns in IoT Applications (6 Marks)

Answer:

 IoT applications (smart home, healthcare, IIoT) face unique risks due to scale &
connectivity.

 Data Privacy Breaches → Personal data (wearables) exposed → identity theft.

 Physical Safety Risks → Hacked industrial machine or vehicle can cause real harm.

 Scalability & Patching Issues → Millions of headless devices → impossible to update

firmware.

 Resource Constraints → Low battery/CPU → cannot run heavy antivirus/firewall.

 Heterogeneous Devices → Different vendors → inconsistent security standards.

Example: Mirai botnet used weak IoT cameras for massive DDoS.

4. Access Control + Threats to Access Control (6 Marks)

Answer:

 Access Control is the security mechanism that decides “who can access what”
resources in IoT system (e.g., user or device accessing sensor data).

 Main models used in IoT: RBAC (Role-Based), ABAC (Attribute-Based), DAC

(Discretionary).

 It works in 3 steps: Authentication → Authorization Policy Check → Resource Grant.

 Threat 1: Privilege Escalation – normal user gains admin rights (e.g., via buffer
overflow).

 Threat 2: Password Cracking / Dictionary Attacks – weak or default passwords

guessed easily.

 Threat 3: Spoofing – attacker pretends to be legitimate device using fake MAC/IP.

 Threat 4: Bypassing via weak defaults – many IoT devices ship with “admin/admin”.

 Why critical in IoT? Devices are headless (no GUI), once one node is compromised,
entire network (gateway + cloud) falls. Diagram Tip: Draw flowchart – User/Device →
Authentication → Access Policy → Resource (with red cross on threats). Keyword:
Broken Access Control (OWASP Top 10 for IoT).

5. Insecure Access Control (with Example) (6 Marks)

  Insecure Access Control happens when rules are poorly designed or implemented →
attacker gains unauthorised entry easily.

 Common vulnerabilities: Hardcoded passwords, no separation of roles, missing

session timeouts, no rate limiting.

 No proper input validation on access tokens or API endpoints.

 Example (Classic IoT case): Smart door lock using factory default password
“admin123” (never forced to change). Attacker guesses it via brute force over
internet → remotely unlocks the physical door.

 Consequences: Data theft, physical intrusion, device becomes part of botnet (Mirai-
style).

 Another real impact: Attacker escalates to control all smart lights/cameras in home.

 Prevention: Enforce password change on first login + implement MFA + proper RBAC
+ regular access log auditing. Diagram Tip: Show insecure flow (Default Password →
Direct Access) vs secure flow (Change Password → MFA → RBAC). Keyword: Insecure
Direct Object Reference (IDOR).

6. Insufficient Authentication/Authorization (6 Marks)

Answer:

 Insufficient Authentication → System fails to properly verify “who you are” (e.g.,
weak passwords, single-factor only, no MFA).

 Insufficient Authorization → After successful login, no check on “what you are

allowed to do” (low-privilege user can run admin commands).

 These are two sides of Broken Access Control vulnerability.

 Impact in IoT: One compromised account allows attacker to control entire fleet (e.g.,
changing all thermostat settings across city).

 Real Case Example: Baby monitor app where any logged-in user could view any
camera feed because authorization check was missing (no user-device mapping).

 Leads to privacy breach, physical safety risk, and regulatory fines (GDPR).

 Keyword: OWASP Top 10 – Broken Authentication & Authorization (A01 & A02).

 Prevention: Use PKI certificates + MFA + role-based checks at every API call.

7. Secure Software & Secure Firmware (6 Marks)

Answer:

 Secure Software → Application-level code (mobile app, cloud backend, web

dashboard) developed with secure coding practices.

 Key practices: Input validation, no SQL injection/XSS, proper error handling, code
reviews.

 Secure Firmware → Low-level OS/bootloader code directly embedded in hardware

(e.g., ESP32 microcontroller).

 Must be cryptographically signed and verified before installation.

 Example: Smart thermostat receives OTA firmware update → device checks

manufacturer’s digital signature using public key → only then flashes the update
(prevents malicious firmware).

 Comparison Table (Draw in exam – extra weightage!)

Feature Secure Software Secure Firmware

Layer Application / Cloud Hardware / Embedded

Protection Method Secure coding + WAF Code signing + Secure Boot

Update Method App store / API OTA with signature verification

patches

Risk if Compromised Data leakage Full device takeover (bricking possible)

 Additional practices: Secure boot, memory protection, regular patches. Keyword:

Code Signing + Secure Boot for IoT.
8. Transport Encryption (6 Marks)

 Transport Encryption protects data while it is moving (in transit) so eavesdroppers

see only unreadable ciphertext.

 Main protocols in IoT: TLS 1.3 for TCP-based (MQTT, HTTP) and DTLS for UDP-based
(CoAP).

 Process steps: 1) Handshake, 2) Key exchange (ECDHE), 3) Symmetric encryption of

payload (AES-GCM).

 Why mandatory in IoT? Data travels over insecure Wi-Fi/Internet → vulnerable to

packet sniffing & MITM.

 Example: Temperature sensor sends reading “25°C” → DTLS encrypts it before

reaching gateway → gateway decrypts only after verification.

 Benefits: Confidentiality + Integrity + Replay protection.

 Without it: Attacker can read/change commands (e.g., fake “open door” signal).
Diagram Tip: Show Data Flow – Sensor → Encrypted (DTLS) → Gateway →
Decrypted. Keyword: End-to-End Encryption in Transit.

9. How Security is Provided to Smart Devices (6 Marks)

 Step 1: Force change of factory default passwords on first boot (mandatory policy).

 Step 2: Implement Multi-Factor Authentication (MFA) + biometric pairing

(fingerprint/face ID).

 Step 3: Embed Digital Certificates (X.509 via PKI) during manufacturing for mutual
authentication.

 Step 4: Enable Secure Boot + firmware signing to prevent tampering.

 Step 5: Regular OTA updates with integrity checks.

 Example: Smart bulb pairs with app → bulb presents its X.509 certificate to cloud
server → both verify each other → only then commands (on/off) are accepted. No
certificate = no access.

 Additional: Device isolation (sandboxing) & anomaly detection. Diagram Tip: Draw
Mutual Authentication Flow – Device (Cert) ↔ Cloud (Cert) → Secure Session.
10. Security to Physical Layer (6 Marks)

 Physical Layer security protects the actual hardware from tampering & side-channel
attacks.

 Technique 1: Tamper-evident seals + self-destruct cryptographic keys on case

opening.

 Technique 2: Integrate Hardware Security Modules (HSM) or TPM for secure key
generation & storage.

 Technique 3: Permanently disable debug ports (JTAG, USB, UART) after

manufacturing.

 Technique 4: Add environmental sensors to detect fault-injection attacks (voltage

glitches, temperature spikes, clock tampering).

 Technique 5: Use physically unclonable functions (PUF) for unique device fingerprint.

 Example: Industrial sensor in factory – if enclosure is opened, keys are wiped

instantly → attacker gets nothing.

 Protects against node capture attacks common in outdoor IoT deployments. Diagram
Tip: Draw Hardware with labels – Tamper Seal, HSM Chip, Disabled Ports. Keyword:
Tamper Resistance & Side-Channel Protection.

11. Secure Cloud/Web Interface (with Example) (6 Marks)

 Secure Cloud/Web Interface protects the dashboards, APIs & portals used to
monitor/control IoT devices.

 Key Mechanisms: HTTPS everywhere, Web Application Firewall (WAF), OAuth 2.0
tokens, API keys, automatic session timeouts.

 Input sanitization to prevent command injection/SQL injection.

 Role-based access at cloud level.

 Example: Home CCTV cloud portal – homeowner logs in with MFA → only encrypted
HTTPS video stream is shown → API restricted via short-lived token → unauthorised
person cannot view live feed or change camera settings.

 Additional: Rate limiting & audit logging of all cloud actions.

 Without security: Attacker can take over entire fleet via web dashboard. Keyword:
Secure Web Interface (prevents injection & session hijacking). Diagram Tip: Cloud
Dashboard Flow – User (MFA) → OAuth Token → Encrypted API → Device Control.
12. Private Key Cryptography vs Public Key Cryptography (6 Marks)

Tabular Format

Feature Private Key (Symmetric) Public Key (Asymmetric)

Keys Used Single shared secret key Public key (encrypt) + Private key
(decrypt)

Speed Very fast, low computation (ideal Slower, high computation

for IoT)

Key Distribution Difficult (must share secretly) Easy (public key can be shared
openly)

Algorithms AES, DES, ChaCha20 RSA, ECC, Diffie-Hellman

Main Use in IoT Bulk data encryption Key exchange & digital signatures

Resource Perfect for low-power devices Used only for initial handshake
Suitability

13. Encryption vs Decryption (with Example) (6 Marks)

Tabular Format (Draw this table)

Feature Encryption Decryption

Definition Plaintext → Ciphertext Ciphertext → Plaintext

Objective Secure data before Recover original data

transmission/storage

Key Uses encryption key + algorithm Uses corresponding decryption key

Usage

Example “HELLO” → “KHOOR” (Caesar +3) “KHOOR” → “HELLO” (Caesar -3)

IoT Use Sensor data before sending to cloud Cloud/gateway recovers readable
data