Chapter 34: Mobile and IoT Security¶

iOS SECURITY LAYERS:

Hardware Security:
├── Secure Enclave Processor (SEP) — isolated co-processor
│   ├── Stores: Biometric templates (Touch ID, Face ID)
│   ├── Stores: Device encryption keys, passcode
│   └── Processes: Touch ID/Face ID verification (never leaves SEP)
├── Unique Device ID (ECID) — hardware burned identifier
├── Hardware UID (Unique ID) — per-chip unique key, inaccessible to software
└── Secure Boot chain: iBoot → iOS kernel (each stage signed by Apple)

Software Security:
├── App Sandbox: Each app isolated in own container
├── Mandatory code signing: All apps must be signed by Apple-trusted cert
├── App Store review: Vetting before distribution
├── Permission model: Explicit user consent for each capability
├── Pointer Authentication Codes (PAC): Prevents code pointer exploitation
└── Memory safety: Swift enforced memory safety

Data Protection:
├── Filesystem encryption: Every file encrypted with per-file key
├── Data Protection classes: NSFileProtectionComplete (locked when screen off)
├── Keychain: Encrypted credential storage
└── Full disk encryption: Active even when device is off

Updates:
└── 5-6 years of security updates; 0-day patches within hours/days

ANDROID SECURITY ARCHITECTURE:

Process Isolation:
├── Each app runs as unique Linux user (UID)
├── App Sandbox: DAC + SELinux enforced isolation
└── Inter-app communication only via explicit Intents

Hardware Abstraction:
├── TEE (Trusted Execution Environment) — ARM TrustZone
│   ├── StrongBox Keymaster (Pixel, Samsung) — dedicated security chip
│   └── Key material never leaves TEE
├── Verified Boot — cryptographic integrity of boot chain
└── Android Verified Boot (AVB) — prevents rollback attacks

Application Security:
├── Play Protect: ML-based malware scanning
├── Permission model: Runtime permissions (user can revoke)
├── Network Security Config: Force HTTPS in apps
└── SafetyNet / Play Integrity API: Device attestation for apps

Fragmentation Challenges:
├── 3+ Android versions widely deployed simultaneously
├── OEM modification introduces vulnerabilities
├── Some devices: 1-2 year security update support only
├── Enterprise: Android Enterprise Recommended (AER) for reliable support
└── Solution: Enforce MDM enrollment; block outdated OS versions

PEGASUS CAPABILITIES:
├── Zero-click delivery: No user interaction required
│   - iMessage, FaceTime, WhatsApp zero-click vulnerabilities
│   - Delivered via malicious GIF, PDF, or message
├── Persistence: Survives reboots (kernel-level implant)
├── Capabilities:
│   ├── Read all messages (iMessage, WhatsApp, Signal, Telegram, email)
│   ├── Camera: Activate front/back camera silently
│   ├── Microphone: Record ambient audio
│   ├── Location: Real-time GPS tracking
│   ├── Call log: All calls, contacts
│   └── Password stealing: Keylogging
├── Anti-forensics: Self-destructs if can't reach C2
└── Cost: ~$650,000 for 10 targets (nation-state pricing)

Detection (Amnesty International's MVT tool):
pip3 install mvt
mvt-ios check-backup --iocs pegasus.stix2 --output ./results ~/Library/Application\ Support/MobileSync/Backup/

ANDROID ENTERPRISE WORK PROFILE:
├── Work Profile: Managed by organization
│   ├── Corporate email, calendar, contacts
│   ├── Corporate apps with DLP policies
│   └── IT can wipe ONLY work profile data
├── Personal Profile: Employee-owned
│   ├── Personal apps, photos, data
│   └── IT cannot access or wipe personal data
└── Visual separation: Work apps have badged icon

iOS MANAGED OPEN-IN:
├── Corporate documents can only be opened in managed apps
├── Personal → Corporate: Blocked (paste restrictions)
├── Corporate → Personal: Blocked (managed app constraint)
└── Remote wipe: Only managed data/apps removed

Privacy Protection (CRITICAL for legal compliance):
├── MDM inventory: device model, OS version, compliance status
├── MDM CANNOT see: personal apps, messages, photos, location
└── This separation is legally required in EU (GDPR) and many US states

IoT NETWORK ARCHITECTURE:

1. Dedicated IoT VLAN (mandatory)
   - NEVER put IoT devices on corporate LAN
   - Rationale: IoT devices are often compromised (weak security, no patches)

2. Firewall Rules (default deny):
   IoT VLAN → Internet: Allow ONLY specific required services
   IoT VLAN → Corporate LAN: DENY (with very specific exceptions)
   Corporate LAN → IoT VLAN: Allow management IPs only
   IoT → IoT: DENY (prevent lateral movement within IoT segment)

3. DNS Resolution:
   - Separate DNS resolver for IoT VLAN
   - Protective DNS enabled
   - Log all DNS queries

4. Network Monitoring:
   - Passive monitoring (Claroty, Nozomi, Cisco Cyber Vision)
   - Alert on: new devices, port scans, unusual protocols, large data transfers

Example Network Policy (Cisco ASA):
access-list IoT_ACL extended permit tcp IoT_VLAN host cloud-api.vendor.com eq 443
access-list IoT_ACL extended permit udp IoT_VLAN host 8.8.8.8 eq 53
access-list IoT_ACL extended deny ip IoT_VLAN CORPORATE_LAN log
access-list IoT_ACL extended deny ip IoT_VLAN IoT_VLAN log
access-list IoT_ACL extended deny ip any any log

ETSI EN 303 645 REQUIREMENTS:

1. No Universal Default Passwords
   - Each device must have unique default password
   - Or: Require user to set password before activation

2. Implement Vulnerability Disclosure Policy
   - Publish security contact; respond within 6 months

3. Keep Software Updated
   - Support update mechanism; notify users; update automatically if possible

4. Securely Store Credentials and Security-Sensitive Data
   - No hardcoded credentials; secure storage

5. Communicate Securely
   - Encrypted communications (TLS 1.2+)

6. Minimize Exposed Attack Surfaces
   - Only necessary ports open; disable unused features

7. Ensure Software Integrity
   - Verify firmware using cryptographic signatures

8. Ensure Personal Data is Secure
   - GDPR compliance; data minimization

9. Make Systems Resilient to Outages
   - Handle network disruption gracefully

10. Examine System Telemetry Data
    - Anomaly detection; security-relevant telemetry