← Tilbake

🎯 Introduksjon til Maskinvare og IoT-sikkerhet

Oversikt over kursinnholdet og læringsmål

Om kurset

Dette kurset dekker sikkerhet i innebygde systemer og IoT-enheter. Vi starter med grunnleggende hardware-konsepter og jobber oss opp gjennom protokoller, kryptering, og praktiske sikkerhetstrusler.

📚 Læringsmål

Programmere ARM mikrokontrollere (nRF52840)
Forstå og implementere SWD debug-protokoll
Implementere Bluetooth Low Energy (BLE) kommunikasjon
Utvikle IoT-applikasjoner med MicroPython og MQTT
Analysere og forstå side-channel angrep (DPA, power analysis)
Identifisere sårbarheter ved glitching og fault injection
Bygge og sikre IoT-nettverk

Kursplan - Kapitler og Temaer

Kurset er strukturert i 7 seksjoner som bygger på hverandre:

1. 🎯 Introduksjon (Du er her)

Oversikt over sikkerhetskonsepter som Chain of Trust og Threat Models.

2. 🔧 Hardware Basics

ARM Cortex-M arkitektur, nRF52840 spesifikasjoner, SWD protokoll, bootloader og firmware-programmering.

3. 📡 Wireless Security (BLE)

Bluetooth Low Energy protokoll, GAP/GATT, CircuitPython, BlueZ stack, device discovery og sikkerhetsmåling.

4. 💻 Embedded Software (MicroPython/MQTT)

SoC arkitektur, ESP8266 microcontroller, MicroPython implementasjon, MQTT protokoll, QoS nivåer, OTA-oppdateringer og nettverksstacks.

5. ⚡ Power Analysis

Simple Power Analysis (SPA), Differential Power Analysis (DPA), ChipWhisperer platform, ARM pipeline-leakage, strømmålingsteknikker og mottiltak.

6. 🎯 Attack Vectors (Fault Injection)

Voltage glitching, clock glitching, EMFI, CMOS transistor oppførsel, timing violations og mottiltak mot fault injection.

7. 🌐 IoT Hackers Handbook

Realverdens-casestudier, common IoT-sårbarheter, best practices for device og nettverk-sikkerhet.

Sikkerhetskonsepter

Chain of Trust

En sikkerhetskjede som starter fra bootloader og sikrer at bare legitim firmware kjører:

Secure Boot: Bootloaderen verifikerer firmware-signatur
Cryptographic verification: SHA-256 og digitale signaturer
Attestasjon: Enheten kan bevise at den kjører legitim firmware

Threat Model

Identifisere potensielle angripere og deres kapabilitetsnivå:

Casual attacker: Bruker kjente default-passord eller åpne porter
Skilled attacker: Analyserer firmware, finner sårbarheter
Well-resourced attacker: Har laboratory-utstyr for power analysis og glitching

🎯 Introduksjons-tips

Start med Hardware Basics for å forstå grunnleggende konsepter
BLE og MQTT er praktiske sider - prøv eksemplene
Power Analysis og Glitching krever laboratorieopsett, men er fascinerende
IoT Hackers casestudier viser reelle angrep fra forskningsmiljø

🔧 Hardware Basics og ARM Mikrokontrollere

nRF52840, SWD, UART og firmware-programmering

ARM Mikrokontroller - nRF52840

Nordic Semiconductor nRF52840 er en høyt integrert SoC (System on Chip) med ARM Cortex-M4 prosessor, BLE-radio, og ekstensive sikkerhetsfunksjoner.

Spesifikasjoner:

Prosessor: ARM Cortex-M4, 64 MHz
Minne: 1 MB flash, 256 KB RAM
Radio: Bluetooth 5.0, Thread, Zigbee-kompatibel
Sikkerhet: ARM TrustZone, Secure Boot, krypto-akselerator
I/O: GPIO, SPI, I2C, UART, PWM, ADC

Arkitektur:

CPU: ARM Cortex-M4 med FPU
Minne-hierarki: Flash → RAM → Register
Klock-system: LFCLK (32 kHz), HFCLK (64 MHz), HFINT
Strømforbruk: Ca 5 µA idle, 4 mA aktiv

Bootloader og Firmware-programmering

Bootloaderen er det første programmet som kjører. Det må initialisere hardware og laste hovedprogrammet.

Bootloader-sekvens:

Prosessoren starter fra reset-vektor
Bootloaderen initialiserer klokker og minne
Bootloaderen validerer firmware-signatur/hash
Bootloaderen laster firmware inn i RAM
Bootloaderen hopper til firmware entry point

Firmware-programmering-metoder:

SWD (Serial Wire Debug): FAST, standard for ARM
UART bootloader: Langsommere, men enklere
OTA (Over The Air): Via BLE uten fysisk tilgang

⚠️ Sikkerhetskonsideration

En kompromittert bootloader kan laste malware. Implementer Secure Boot med kryptografisk verifisering av firmware.

SWD (Serial Wire Debug) Protokoll

SWD er ARM sin debug-protokoll designet for enkel implementering og høy hastighet.

Fysisk grensesnitt:

Pinner: 2 (SWDIO + SWDCK)
GND: Felles jord
Optional: Reset (nRST), SWO (Serial Wire Output) for RTT

SWD-protokoll:

Clock line (SWDCK): Drevet av debugger
Data line (SWDIO): Bi-direktional (open-drain)
Hastighet: 1-50 MHz (typisk 10 MHz)
Preamble: 50 JTAG-klokker (0xFFFF...)

SWD-operasjoner:

Read memory: Les data fra RAM/Flash
Write memory: Skriv data til RAM
Read registers: Les CPU-registre
Write registers: Skriv CPU-registre (R0-R15, PSR, osv)
Halt/Resume: Pause og fortsett CPU-kjøring

💡 Picoprobe

Raspberry Pi Pico kan brukes som SWD debugger via Picoprobe firmware. Dette gir en billig debugger for ARM mikrokontrollere.

UART (Serial Communication)

Universal Asynchronous Receiver Transmitter - en enkel og robust kommunikasjons-protokoll.

UART-parametre:

Baudrate: 9600, 38400, 115200, 230400 bps
Data bits: 8 (standard)
Stop bits: 1 eller 2
Paritet: Ingen, Even, Odd

Bruksområder:

Debug-output (print-statements)
Bootloader-kommunikasjon
Firmware-oppdateringer
Sensor-data-innsamling

RS-232 nivåer:

UART er logisk nivå (0-3.3V). RS-232 krever levelshift IC (MAX3232) for spenningsnivåer (+/- 12V).

Clock Management

Effektiv klock-styring er kritisk for strømforbruk og ytelse.

Klock-kilder på nRF52840:

LFCLK (Low Frequency): 32 kHz, for RTC og sleep
HFCLK (High Frequency): 64 MHz, for CPU og radio
HFINT (Internal): Intern oscillator, mindre nøyaktig

Strømbesparing-teknikker:

Deaktivere HFCLK når ikke i bruk
Bruke sleep-modus (WFI) mellom events
Deep sleep med RTC-oppvåkning
GPIO interrupt-drevet design (event-basert)

📡 Bluetooth Low Energy (BLE) Protokoll

GAP, GATT, sikkerhet og praktisk implementering

BLE Arkitektur - CircuitPython

CircuitPython tilbyr lett Python-programmering for BLE på nRF52840 og andre enheter.

BLE Stack-lag:

Physical Layer: 2.4 GHz radio
Link Layer: Connection management, frequency hopping
L2CAP: Logical Link Control and Adaptation Protocol
GAP: Generic Access Profile (discovery, connection)
GATT: Generic Attribute Profile (data exchange)
Application: Custom services og characteristics

GAP (Generic Access Profile)

GAP definerer hvordan enheter blir oppdaget og knyttet sammen.

GAP Roller:

Advertiser: Sender annonseringer for å bli oppdaget
- Sender små pakker med annonsedata
- Scannable (lyttere kan spørre)
- Connectable (kan initialisere forbindelse)
Scanner: Lytter etter annonseringer
- Passive scanning (bare lytter)
- Active scanning (sender scan requests)
Central: Initierer forbindelser
Peripheral: Aksepterer forbindelser

Annonseringsmoduser:

Legacy advertising: 31 bytes annonsedata
Extended advertising: 254 bytes, lavere power
Periodic advertising: Repetitiv annonse

GATT (Generic Attribute Profile)

GATT definer hvordan data organiseres og utveksles i en BLE-forbindelse.

GATT-hierarki:

Service: Samling av relaterte funksjoner
- Identifisert med 16-bit eller 128-bit UUID
- Eksempel: Heart Rate Service (0x180D)
Characteristic: Individuell datapunkt
- Properties: Read, Write, Notify, Indicate
- Value: Faktiske data
- Descriptors: Metadata (CCCD, Unit, osv)

Characteristic Properties:

Read: Central kan lese verdi
Write: Central kan skrive verdi
Notify: Peripheral sender uoppfordret oppdateringer
Indicate: Notify med confirmation
Broadcast: I annonseringsdata

BLE Security og Pairing

BLE security baseres på pairing-prosessen som etablerer delte hemmeligheter.

Pairing-modi (LE Legacy Pairing):

Just Works: Ingen autentisering
- ❌ Sårbar for MITM-angrep
- Raskest, minst sikker
Passkey Entry: 6-sifret PIN
- En enhet viser, annen taster inn
- ✅ God MITM-beskyttelse
Numeric Comparison: Begge viser samme tall
- ✅ Moderat sikkerhet
- Enklere brukeropplevelse
Out of Band (OOB): Ekstern verifisering
- ✅✅ Sterkest sikkerhet
- NFC, QR-kode, eller fysisk bekreftelse

LE Secure Connections (ECDH):

BLE 4.2+ bruker ECDH for nøkkelutveksling i stedet for legacy metoder.

Elliptic Curve Diffie-Hellman (P-256)
Sterkere enn legacy pairing
Fortsatt trenger autentisering (Just Works eller passkey)

BlueZ Stack

BlueZ er Linux sin Bluetooth stack, brukt av de fleste Linux-systemer.

Komponenter:

Kernel driver: Bluetooth HCI driver
BlueZ daemon: bluetoothd prosess
D-Bus interface: IPC mellom applikasjoner
Tools: bluetoothctl, hcitool, gatttool

# Scan etter BLE-enheter (Linux)
hcitool -i hci0 lescan

# Connect via BlueZ D-Bus
bluetoothctl
> scan on
> connect AA:BB:CC:DD:EE:FF
> menu gatt
                    

Device Discovery

Prosessen hvor en enhet finner og kobler seg til en annen.

Discovery-sekvens:

Peripheral begynner å annonsere
Central skanner for annonseringer
Central ser annonser fra ønsket enhet
Central initierer connection request
Peripheral aksepterer forbindelsen
Link Layer forbindelse opprettet
GATT discovery starter

GATT Discovery:

Enumerate alle services
For hver service: enumerate characteristics
For hver characteristic: les descriptors
Cache resultater for raskere tilkobling neste gang

Security Tools og Testing

nRF Connect (app): Scan, connect, advertise BLE
GATT Browser: Visualiser service/characteristic-hierarki
Wireshark with PCAP: Sniffer BLE-trafikk (krever HCI mode)
Bluetooth Security Toolkit: Test for kjente sårbarheter

⚙️ Embedded Software & IoT (MicroPython/MQTT)

Embedded operativsystemer, firmware og IoT-protokoller

SoC Arkitektur (System-on-Chip)

En SoC integrer alle nødvendige komponenter (prosessor, RAM, ROM, I/O, kommunikasjon) på ett enkelt chip. Typisk for IoT-enheter.

Typiske SoC-komponenter:

CPU: ARM Cortex-M (lav strøm) eller ARM Cortex-A (høyere ytelse)
RAM: 256 KB - 512 MB (avhengig av applikasjon)
Flash: 1 MB - 2+ GB persistent minne
Peripherals: UART, SPI, I2C, ADC, GPIO
Radios: WiFi, BLE, Cellular, LoRa
Power Management: Sleep modes, voltage regulation

ESP8266 Microcontroller

ESP8266 er en populær, billig SoC med innebygd WiFi for IoT-applikasjoner.

Spesifikasjoner:

Prosessor: Tensilica 32-bit RISC (160 MHz)
RAM: 160 KB instruksjon RAM, 160 KB data RAM
Flash: Ekstern (typisk 4 MB)
WiFi: 802.11 b/g/n (2.4 GHz)
ADC: 1 kanal, 10-bit
Pins: GPIO0-GPIO15, UART, SPI, I2C
Power: 3.3V, ~80 mA aktiv, 10 µA sleep

Boot Sequence:

ROM bootloader initialiserer ekstern flash
Laster second-stage bootloader (SPIFFs eller firmware)
Laster og kjører applikasjons-firmware
Firmware initialiserer WiFi-stack

MicroPython på Embedded Systemer

MicroPython er en lightweight Python-implementering designet for microcontrollere med begrenset ressurser.

MicroPython Arkitektur:

Compiler: Kompilerer Python til bytecode
- Bytecode tolkes av VM
- Betydelig mindre enn full Python
Garbage Collection: Automatisk minne-cleanup
Module System: Importere ferdig-skrevne moduler
- machine (GPIO, ADC, UART)
- network (WiFi, socket)
- umqtt (MQTT client)
REPL: Read-Eval-Print Loop for interaktiv utvikling

# MicroPython eksempel på ESP8266
import network
from umqtt.simple import MQTTClient

# Koble til WiFi
sta_if = network.WLAN(network.STA_IF)
sta_if.active(True)
sta_if.connect('SSID', 'password')

# Oppdater GPIO
import machine
led = machine.Pin(2, machine.Pin.OUT)
led.on()
led.off()

# Les analog verdi
adc = machine.ADC(0)
voltage = adc.read()
                    

MQTT - Message Queuing Telemetry Transport

MQTT er en lett, publish-subscribe meldingsprotokoll optimalisert for IoT med begrenset båndbredde og strøm.

MQTT Arkitektur:

Broker: Central meldingsserver
- Populære: Mosquitto (open source), HiveMQ, AWS IoT Core
Publisher: Sender meldinger til topics
Subscriber: Lytter på topics for meldinger
Topic: Hierarkisk string-adresse (eks: "hjem/stue/temp")

MQTT Quality of Service (QoS):

QoS 0 (At most once): Fire and forget
- Minste overhead
- Melding kan gå tapt
QoS 1 (At least once): Garantert levering
- Duplikater mulig
- Bruker PUBACK acknowledgement
QoS 2 (Exactly once): Garantert en gang
- Mest sikker, høyest overhead
- 4-veis handshake (PUBREC, PUBREL, PUBCOMP)

MQTT Payload:

Format: Binær data (ofte JSON, XML, eller custom)
Størrelse: Opptil 256 MB (typisk MB eller KB)
Retain: Broker lagrer siste melding per topic
Will Message: Automatisk melding hvis klient kobler fra

# MQTT eksempel (MicroPython på ESP8266)
from umqtt.simple import MQTTClient

def on_message(topic, msg):
    print(f"Received: {topic.decode()} = {msg.decode()}")

client = MQTTClient("esp_client", "broker.mosquitto.org")
client.set_callback(on_message)
client.connect()

# Subscribe
client.subscribe(b"home/temp")

# Publish
client.publish(b"home/humidity", b"65", qos=1)

# Loop for å motta meldinger
while True:
    client.check_msg()
                    

OTA (Over-The-Air) Updates

OTA tillater fjernoppdatering av firmware uten fysisk tilgang til enheten.

OTA Prosess:

Enhet sjekker server for ny firmware versjon
Hvis ny versjon finnes: download over WiFi/LTE
Verifiser integritet (hash eller signatur)
Skrive til alternate flash partition
Reboot og load ny firmware
Rollback mulig hvis feil detekteres

Sikkerhetshensyn:

Signering: Bruk digitale signaturer for firmware-integritet
Kryptering: TLS/HTTPS for download
Versjon sjekking: Forhindrer downgrade-angrep
Rollback beskyttelse: Versjonsnummer i persistent storage

Network Stack (TCP/IP)

Embedded enheter bruker ofte en lightweight TCP/IP stack i stedet for full Linux TCP/IP.

Populære stacks:

lwIP: Lav minne-footprint, brukt i ESP8266/ESP32
uIP: Enda mindre, for veldig ressurs-begrenset enheter
RIOT OS: Fullt OS for IoT

Socket Programmering (MicroPython):

import socket

# TCP klient
s = socket.socket()
s.connect(("example.com", 80))
s.send(b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")
response = s.recv(1024)
s.close()

# UDP (enveis)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto(b"ping", ("192.168.1.100", 5000))
                    

Firmware Security Best Practices

Minimalisme: Inkluder bare nødvendige funksjoner
- Mindre kodemengde = færre sårbarheter
Secure Boot: Verifiser firmware før kjøring
- Bruk RSA eller ECDSA signaturer
Memory Protection: Bruk MPU for å isolere kritisk kode
Kryptering: Krypter sensitiv data i Flash
Debug Disable: Deaktiver debug-interfaces i produksjon

Signatur: Digitale signaturer for å verifisere opprinnelse

Versjonskontroll: Tillat bare oppdatering til nyere versjoner

Rollback-proteksjon: Forhindre downgrade til gamle, sårbare versjoner

💡 Secure Boot

Implementer Secure Boot for å sikre at bare signert firmware kan kjøre. Dette forhindrer at en angriper installer malware.

🎯 Attack Vectors - Fault Injection & Glitching

Timing, voltage, clock glitching og fault attack metodologi

Glitching og Fault Injection - Fundamentaler

Et "glitch" er en kort, kontrollert avvik fra normal operasjon. En angriper kan forstyrre prosessoren ved å påføre strøm- eller klokke-uregelmessigheter som får enheten til å utføre utenforventet oppførsel.

Glitching Attack Kategorier:

Skip instruksjon: Kort strømspenningsstøt eller klokke-forstyrrelsre får prosessoren til å hoppe over en instruksjon
- F.eks: hoppe over autentiseringskontroll
- Pipeline-stadiene blir usynkronisert
- Instruksjon blir ikke hentet, dekodet eller utført
Endre beregning: Forstyrre ALU-operasjoner til å gi feil resultat
- 2 + 2 blir 3 eller 5
- Kryptografiske operasjoner gir invalid cipher
Memory flip: Endre en eller flere bits i RAM/Flash
- authenticated = true blir false
- PIN sjekk-flag blir oversjekket
Jump til vilkårlig adresse: Endre program counter
- Hopp over sikkerhetskritisk kode
- Direkte til payload
Timing violation: Få instruksjon til å kjøre for tidlig
- Bypass visse cache-sjekker
- Endre låsemekanismer

⚠️ Realistisk scenario

En angriper bruker ChipWhisperer eller homemade EMP generator. Enhet kjører:

if (pin_correct == true) {
    authenticated = true;
}

// Med glitch: authenticated settes til true selv om pin_correct = false
                        

Voltage Glitching

Reduksjon av strømforsyningsspenningen under kort periode forstyrrer prosessorfunksjonen.

Mekanisme:

Normal operasjon: Processor kjører ved 3.3V (eller 1.8V)
- Transistorer åpner/lukker pålitelig ved spenningsforholdene
Glitch: Spenningen faller til 2.0V eller lavere for 10-100 ns
- Dårlige timing betingelser
- Noen transistorer åpner ikke som forventet
- Logiske tilstander blir korrupte

Voltage Glitch Setup:

Strøm-forsyning: Programmable PSU eller MOSFET-kontrollert strøm
- Kan endres innenfor µs timescale
Trigger: Vanligvis GPIO-pinne eller oscilloskop-signal
- Detekterer når enhet gjør interessant kryptografi
Timing: Må vite eksakt instruksjon-timing
- ChipWhisperer måler og logger instruksjon-sekvens
- Trial-and-error eller firmware-analyse for å finne target instruksjon

Eksempel - AES Glitch:

# Glitch under first round SubBytes
# Glitch offset: instruksjon #47, varighet: 50ns
# Resultat: En av de 16 bytes blir korrumpert
# Angriper har nå partial-ciphertext for analyze

# Med 16 ganger glitching (en gang per byte) får angriper full
# ciphertext for alle 16 bytes med hver byte korrumpert
# Bruker fault analysis for å gjenskape nøkkelen
                    

Clock Glitching

Manipulering av klokk-signalet forstyrrer tidstakten for instruksjonsskifter, noe som fører til synkroniserings-feil og operasjons-korrupsjon.

Clock Glitch Mekanisme:

Normal klokk: Stabil 160 MHz (6.25 ns periode)
- Instruksjon fetches/executes på hver clock edge
Glitch: Kort ekstra klokk-puls eller glitch
- Prosessor ser ~161 MHz i kort periode
- Instruksjon fetches for tidlig før forrige instruksjon ferdig
- Pipelinestadiene blir usynkronisert

Clock Glitch Fordeler vs Voltage:

✅ Finere temporal kontroll (ns-nivå)
✅ Mindre avhengig av spenningsmargin
❌ Krever tilgang til klokk-signalet
❌ Kan trigge watchdog timere

Eksempel - Skip instruksjon med Clock Glitch:

// Original firmware
0x1000: LDR R0, [R1, #0]    // Load authentication flag
0x1004: CMP R0, #1          // Compare with 1
0x1008: BEQ allow_access    // Branch if equal
0x100C: LDR R1, deny_label  // Access denied (SKIP THIS)
0x1010: B end

// Med clock glitch ved instruksjon 0x100C:
// - Instruksjon hoppes over (eller fetches feil byte)
// - Program counter hopper til 0x1010 eller feil adresse
// - Sikkerhetskontroll bypasses
                    

Electromagnetic Fault Injection (EMFI)

Et kort EM-puls (fra antenna eller EM coil) induserer strømmer i chip som forstyrrer operasjon.

EMFI Setup:

EM pulse generator: 5-15 V, 10-100 ns pulse i antenna
- Induserer strømmer via elektromagnetisk induksjon
- Ikke-invasiv (ikke trenger fysisk kontakt med chip)
Antenna: Spiral eller flat coil nær target chip
- Typisk 1-10 cm fra target
Posisjonering: Precise X-Y-Z justering
- Automatisert stage for scanning

EMFI Fordeler:

✅ Helt ikke-invasiv
✅ Kan brukes på pakket/innkapslet enhet
✅ Ikke destruktivt
❌ Mindre presist enn voltage glitching
❌ Krever høy puls-spenning

Timing Constraint Violations

Selv uten fullstendig fault-injection, å forstyrre timing kan påvirke logikk som avhenger av tidsinformasjon.

Eksempler:

Cache timing: Gjør cache-sjekk feile ved å endre klokke
- Cache lookup-timing for adresser blir uventet
Watchdog bypass: Føre watchdog til timeout ved spennings-dip
- Stopper reboot som skulle forebygge angrep
Loop counter overflow: Gjør counter-basert sikkerhetskontroll feil
- "Gjenta sjekk 3 ganger" blir 1 gang

CMOS Transistor Oppførsel Under Stress

For å forstå hvorfor glitching virker, må vi forstå CMOS-transistor-fysikken.

Normal CMOS:

NMOS transistor: Åpner når gate = VDD (høy spenning)
- Threshold voltage: typisk 0.5V
- Hvis gate < Vth: transistor åpner ikke
PMOS transistor: Åpner når gate = GND (lav spenning)
- Threshold voltage: typisk -0.5V

Under Voltage Glitch:

VDD faller fra 3.3V til 2.0V
NMOS gate-spenning blir mindre vs Vth
Transistor åpner ikke fullt eller sleit senere enn forventet
Logiske signaler blir underspente (0.5V i stedet for 3.3V)
Neste transistor-lag tolker signal som 0 i stedet for 1 (eller vice versa)
Resultat: bitflip eller instruksjon-skip

// CMOS inverter (oversimplifisert)
Input ---[PMOS]---+--- Output
                  |
              [GND]-
                  |
Input ---[NMOS]---+
                  
// Normal: VDD = 3.3V
Input = 3.3V -> NMOS ON, PMOS OFF -> Output = 0V

// Med glitch: VDD = 2.0V
Input = 3.3V -> NMOS åpner sent -> Output = ~1.5V (undefined!)
                    

Mottiltak mot Fault Injection

1. Redundans og Error Detection:

Triple Modular Redundancy (TMR): Kjør kode 3 ganger, voter resultat
- Selv to glitches trenger eksakt samme resultat
- Høy overhead (3x ressurser)
CRC/Checksum: Kontroller dataen
- Detekterer bit-endringer
- Må ikke lagres samme sted som data
ECC: Error-Correcting Code
- Kan korrigere enkle feil
- Brukes for RAM

2. Timing Monitoring:

Timing checks: Sikker at kode tar forventet tid
- Indre timer-loop som detekterer abnormal hastighet
- Hvis kode kjører for raskt: glitch detektert
Watchdog timer: Oversikt på prosessen
- Hvis prosess ikke feeder watchdog: reset

3. Masking:

Boolean masking: XOR verdier med tilfeldig tall
- Selv om ene blir byttet, maskert verdi blir usannsynlig

4. Cryptographic Firmware Signing:

Secure Boot: Verifiser firmware-signatur før kjøring
- Hvis glitch endrer kode i minne: signatur sjekk feiler på reboot

5. Fysisk Beskyttelse:

Faraday-bur: Blokkerer EM-angrep
Epoxy conformal coating: Gjør probing vanskeligere
Metal shields: Blokkerer interferens
Potting: Fylle chips-område med harpiks

🎯 Eksamen-relevante poenger

Glitching er en praktisk, reell trussel
Voltage og clock glitching er de vanligste metodene
ChipWhisperer gjør fault injection mulig for studenter
Redundans, timing-sjekker, og fysisk beskyttelse er kritisk
Selv "sikker" kryptografi kan bypasses med glitching

🔧 Pensum

🎯 Introduksjon til Maskinvare og IoT-sikkerhet

Om kurset

📚 Læringsmål

Kursplan - Kapitler og Temaer

1. 🎯 Introduksjon (Du er her)

2. 🔧 Hardware Basics

3. 📡 Wireless Security (BLE)

4. 💻 Embedded Software (MicroPython/MQTT)

5. ⚡ Power Analysis

6. 🎯 Attack Vectors (Fault Injection)

7. 🌐 IoT Hackers Handbook

Sikkerhetskonsepter

Chain of Trust

Threat Model

🎯 Introduksjons-tips

🔧 Hardware Basics og ARM Mikrokontrollere

ARM Mikrokontroller - nRF52840

Spesifikasjoner:

Arkitektur:

Bootloader og Firmware-programmering

Bootloader-sekvens:

Firmware-programmering-metoder:

⚠️ Sikkerhetskonsideration

SWD (Serial Wire Debug) Protokoll

Fysisk grensesnitt:

SWD-protokoll:

SWD-operasjoner:

💡 Picoprobe

UART (Serial Communication)

UART-parametre:

Bruksområder:

RS-232 nivåer:

Clock Management

Klock-kilder på nRF52840:

Strømbesparing-teknikker:

📡 Bluetooth Low Energy (BLE) Protokoll

BLE Arkitektur - CircuitPython

BLE Stack-lag:

GAP (Generic Access Profile)

GAP Roller:

Annonseringsmoduser:

GATT (Generic Attribute Profile)

GATT-hierarki:

Characteristic Properties:

BLE Security og Pairing

Pairing-modi (LE Legacy Pairing):

LE Secure Connections (ECDH):

BlueZ Stack

Komponenter:

Device Discovery

Discovery-sekvens:

GATT Discovery:

Security Tools og Testing

⚙️ Embedded Software & IoT (MicroPython/MQTT)

SoC Arkitektur (System-on-Chip)

Typiske SoC-komponenter:

ESP8266 Microcontroller

Spesifikasjoner:

Boot Sequence:

MicroPython på Embedded Systemer

MicroPython Arkitektur:

MQTT - Message Queuing Telemetry Transport

MQTT Arkitektur:

MQTT Quality of Service (QoS):

MQTT Payload:

OTA (Over-The-Air) Updates

OTA Prosess:

Sikkerhetshensyn:

Network Stack (TCP/IP)

Populære stacks:

Socket Programmering (MicroPython):

Firmware Security Best Practices

💡 Secure Boot

⚡ Power Analysis og Side-Channel Angrep

Simple Power Analysis (SPA)

SPA Prinsipper:

SPA på AES:

Differential Power Analysis (DPA)

DPA Metodologi: