The gold standard for methodology.

Opening Framing

After ten weeks of breaking IoT devices, we shift perspective to building them securely. We know attacks work because developers make mistakes—buffer overflows, hardcoded keys, cleartext protocols.

The Shift Left: Traditional security testing happens at the end (Pen Testing). This is too late. Fixing a bug in design costs $1. Fixing it in code costs $10. Fixing it in production costs $10,000 (Recall). We must move security to the left of the timeline.

1) The Secure Boot Chain: Foundation of Trust

If you cannot trust the code running on the device, nothing else matters. Secure boot ensures that only Authorized code executes.

[ THE CHAIN OF TRUST ]

      (Power On)
          |
    [ BOOT ROM ] (Immutable, Hardware Root of Trust)
          |      Verifies Stage 1 Signature (Public Key Hash in Fuses)
          v
    [ STAGE 1 BOOTLOADER ] (SPL / FSBL)
          |      Verifies Stage 2 Signature (U-Boot/LittleKernel)
          v
    [ STAGE 2 BOOTLOADER ] (U-Boot)
          |      Verifies Kernel Signature (ITB/FIT Image)
          v
    [ LINUX KERNEL ]
          |      Verifies Root Filesystem (dm-verity)
          v
    [ USER SPACE ] (Application)
                    

Key Concepts

• Root of Trust (RoT): The component that is implicitly trusted. Usually Mask ROM + eFuse (OTP).
• eFuse (One-Time Programmable): Physical fuses burned during manufacturing. Contains the hash of the Public Key. If the firmware signature doesn't match this hash, the CPU halts.
• Anti-Rollback: An eFuse counter prevents downgrading to an older, vulnerable firmware version.

The Signing Ceremony

How do we actually sign firmware? We need an Off-Line Root CA.

# 1. Generate Private Key (Keep this OFFLINE/HSM!)
openssl genrsa -out private_key.pem 2048

# 2. Extract Public Key (Embed this in Device/Bootloader)
openssl rsa -in private_key.pem -pubout -out public_key.pem

# 3. Hash the Firmware
sha256sum firmware.bin > firmware.hash

# 4. Sign the Hash (Create Signature)
openssl dgst -sha256 -sign private_key.pem -out firmware.sig firmware.bin

# 5. Verify (On Device)
openssl dgst -sha256 -verify public_key.pem -signature firmware.sig firmware.bin
                    

2) Hardware Security Modules (HSM) vs TPM vs SE

Where do you store the secrets? (AWS Keys, Private Keys).

3) The DevSecOps Pipeline

Automating security checks into the CI/CD pipeline. Security scales only if it is automated.

A) Secret Scanning (Pre-Commit)

Stop developers from committing AWS keys.

# Tools: TruffleHog, GitLeaks
# Example Gitleaks config (.gitleaks.toml)
[[rules]]
description = "AWS Access Key"
regex = '''(A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}'''
                    

B) SAST (Static Application Security Testing)

Analyzes source code without running it.

rules:
  - id: ban-strcpy
    patterns:
      - pattern: strcpy(...)
    message: "Use strncpy or strlcpy instead. strcpy is unsafe."
    languages: [c, cpp]
    severity: ERROR
                    

C) Automated Pipeline Example (GitLab CI)

stages:
  - build
  - test
  - security

compile_firmware:
  stage: build
  script:
    - make all

static_analysis:
  stage: security
  image: returntocorp/semgrep
  script:
    - semgrep --config=p/c --error
  allow_failure: false  # Break build on security fail

secret_detection:
  stage: security
  image: zricethezav/gitleaks
  script:
    - gitleaks detect --source=. -v

dependency_scan:
  stage: security
  image: aquasec/trivy
  script:
    - trivy fs . --scanners vuln
                    

D) SCA & SBOM

Problem: Your code is 10% yours, 90% Open Source. The "Log4J" problem.

Solution: SBOM (Software Bill of Materials).

• Tool: `Syft` or `Trivy`.
• Usage: `syft . -o cyclonedx-json > sbom.json`
• Risk: Upload `sbom.json` to a vulnerability tracker (like Dependency-Track) to get alerts when a library you use has a new CVE.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "1.1.1t",
      "purl": "pkg:deb/debian/openssl@1.1.1t",
      "licenses": [
        {
          "license": {
            "id": "OpenSSL"
          }
        }
      ]
    },
    {
      "type": "library",
      "name": "cjson",
      "version": "1.7.15",
      "purl": "pkg:github/DaveGamble/cJSON@1.7.15"
    }
  ]
}
                    

4) Threat Modeling: STRIDE in Action

Before writing code, we must understand what we are building and how it can be attacked.

Example: Smart Door Lock

5) Fuzzing: The Nuclear Option

Fuzzing involves throwing millions of random (malformed) inputs at a program to crash it. It is how 90% of memory corruption bugs are found today.

Types of Fuzzing

• Dumb Fuzzing: Random bit flipping.
• Generation Fuzzing: Understands protocol structure (Boofuzz).
• Coverage-Guided Fuzzing (AFL++): Instruments the binary. If an input hits a new code path, it saves it and mutates it further. Evolution in action.

# 1. Compile with Instrumentation
afl-gcc -o vulnerable_parser parser.c

# 2. Prepare Corpus (Valid seed inputs)
mkdir in; echo '{"key":"value"}' > in/seed.json

# 3. Run Fuzzer
afl-fuzz -i in -o out ./vulnerable_parser @@

# AFL UI:
# [total paths]: 120
# [crashes]: 5  <-- VICTORY
                    

6) Memory Safety: Rust vs C

70% of all vulnerabilities (Microsoft & Chrome stats) are Memory Safety issues (Buffer Overflows, Use-After-Free).

Recommendation: For new IoT development, prefer Rust (Embassy / TockOS) over C. If you must use C, use strict static analysis and sanitizers (ASan).

7) Secure Firmware Update (OTA)

You must be able to patch vulnerabilities. But the update mechanism itself is a huge attack vector.

The Update Triangle

1. Authenticity: Is this update from us? (Signature Verification).
2. Integrity: Is the file corrupted? (Hash Verification).
3. Anti-Rollback: Is this an old, buggy version? (Version Checking).

Guided Lab: Fuzzing with AFL++

Objective: Use AFL++ to find a buffer overflow in a simple C parser.

Prerequisites: Docker installed.

Step 1: The Vulnerable Code (`vuln.c`)

#include <stdio.h>
#include <string.h>

void process_data(char *input) {
    char buffer[50];
    if (input[0] == 'M') {
        // VULNERABILITY: Unbounded strcpy if input starts with 'M'
        strcpy(buffer, input); 
    }
}

int main(int argc, char **argv) {
    // Read from file or stdin
    FILE *f = fopen(argv[1], "rb");
    if (!f) return 1;
    char input[1024];
    fread(input, 1, 1024, f);
    process_data(input);
    return 0;
}
                    

Step 2: Fuzzing Setup

# Pull AFL++ Docker
docker run -it --rm aflplusplus/aflplusplus

# Compile
afl-clang-fast vuln.c -o vuln

# Seed
mkdir in; echo "Hello" > in/seed.txt

# Fuzz!
afl-fuzz -i in -o out ./vuln @@
                    

Observation: Within seconds, AFL will find that inputs starting with 'M' followed by >50 chars cause a crash. It will store the crashing input in `out/crashes/`.

Appendix A: Secure C Coding Standards

Appendix B: Crypto Implementation Checklist

Appendix C: Vulnerability Disclosure Policy (VDP)

Every company needs a SECURITY.md at the root of their repo. It tells researchers how to report bugs without getting sued.

# Security Policy

## Supported Versions

| Version | Supported          |
| ------- | ------------------ |
| 5.1.x   | :white_check_mark: |
| 5.0.x   | :x:                |

## Reporting a Vulnerability

We take the security of our systems seriously.

If you believe you have found a security vulnerability, please report it to us as described below.

**Please do not report security vulnerabilities through public GitHub issues.**

### Reporting Process
1. Email your findings to **security@example.com**.
2. Include steps to reproduce the issue.
3. We will acknowledge receipt within 48 hours.
4. We will provide an estimated timeline for the fix.

### Safe Harbor
We pledge not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.
                    

Appendix D: OWASP IoT Top 10 Mapping

How this course mapped to the top threats.

Appendix E: Incident Response Playbook

What happens when you do get hacked?

Resources