PERSONAL - IT-Sicherheit 2

Digitale Identität, Smartcards

Smartcard-Angriffe: passiv vs. aktiv
- passiv: Mikroprobing, Mikroskop, Seitenkanalanalyse
  - Mikroprobing: Abtasten von Bussignalen / IO
  - Mikroskop: gezielten Auslesen von Speicherzellen
  - Seitenkanalanalysen: Ausnutzen von Verhaltens-Charakteristika, um aus Beobachtungen vertrauliche Informationen zu erschließen
    - Timing-Angriffe: Messen von Ausführungszeiten von Operationen
    - Power-Analyse: Messen des Stromverlaufs pro Instruktion; kann von Daten abhängen
- aktiv: UV-Licht, Laser, Störimpulse
  - UV-Licht: EEPROM-Zellen entladen
  - Laser: Manipulation von Registerwerten / Speicher
  - Störimpulse: Manipulation des Kontrollflusses
Abwehrmaßnahmen: passiv vs. aktiv
- passiv: Obfuskation, zusätzliche Schutzschichten (z.B. Metallschicht), Speicherverschlüsselung
- aktiv: erkennen durch Sensorik (Spannung, Licht, Temperatur...)

Smartcards zur Authentisierung

Smartcard: speichert Credentials im Chip, führt Kommandos aus, wird erst nach Besitzer-Authentisierung entschlüsselt
- 2-Faktor: Besitz (physischer Besitz der Karte; Challenge-Response), Wissen (idR PIN, im EEPROM)

Personalausweis: hoheitliche Personenkontrolle (Biometrie \to $\to$ Missbrauch und Fälschung erschweren), Onlinefunkiton (eID, hoheitlich bestätigt)
- Hardware: RFID-Chip, max. 10cm Signalreichweite (geringe Sendeleistung), EAL 5+ zertifiziert
- Daten im PA: Name, Geburtsdatum, Alter, Geschlecht, Nationalität
- Daten auf dem Chip: digitalisiertes Gesichtsbild, 2 Fingerabdrücke, öffentlicher Chipschlüssel DH_{ec} $DH_{ec}$ , Chip Security Object h = H(DH_{ec}) $h = H(DH_{ec})$ , signiert von Bundesdruckerei sig=sig_{BDr}(h) $sig=sig_{BDr}(h)$ , BDr-Zertifikat e_{BDr} $e_{BDr}$ , Root-Zertifikat des BSI (Bundesamt für Sicherheit und Informationstechnik, signiert Herstellerkey e_{BDr} $e_{BDr}$ des PA)
  - Chain of Trust: Root-Zertifikat-BSI e_{BSI} \to $e_{BSI} \to$ BDr-Zertifikat e_{BDr} \to DH_{ec} $e_{BDr} \to DH_{ec}$
- Fälschungssicherheit: privater Chipkey DH_{dc} $DH_{dc}$ (sicher, statisch), public Key DH_{ec} $DH_{ec}$ mit h = H(DH_{ec}), sig = sig_{BDr}(h) $h = H(DH_{ec}), sig = sig_{BDr}(h)$ signiert von Bundesdruckerei (bestätigt Echtheit des Keys)
Onlineauthentisierung mit digitalem PA: Ausweisinhaber A $A$ , digitaler Personalausweis PA, Online-Dienst S $S$
- PKI: Anbieter von S $S$ beantragt Berechtigungszertifikat z $z$ (2-3 Tage gültig, beschreibt erlaubte PA-Daten) bei Vergabestelle für Berechtigungszertifikate (VfB); VfB prüft Sicherheitskonzept von S $S$ und gibt Liste zertifizierter Zertifikatsausteller BerCA an S $S$ zurück (Root: BSI, signiert BerCA-Zertifikate)

A $A$ stellt Nutzungsanfrage an S $S$
S $S$ sendet z $z$
A $A$ schaltet PA mit PIN frei, PA und eID-Server authentisieren sich
1. eID \leftrightarrow $\leftrightarrow$ PA: Terminal-Authentisierung
2. PA \leftrightarrow $\leftrightarrow$ eID-Server: 2-stufig
  1. DH_{ec}, CSO, sig $DH_{ec}, CSO, sig$ gesendet an eID-Server, wird geprüft
  2. DH-Exchange, Key-Generaton k_c $k_c$
verschlüsselte Kommunikation zwischen PA und S $S$ mit k_c $k_c$

Restricted Identification: pseudonymisiertes Login, H(DH(e_s, DH_{dc})) $H(DH(e_s, DH_{dc}))$
Password Authenticated Connection Establishment (PACE): 2-mal DH-Exchange, einmal anonym, einmal authentisiert
- Ableiten eines geheimen Schlüssels mit hoher Entropie, auch wenn die PIN eine niedrige Entropie besitzt
Sicherheitsfeatures: Anti-Cloning (privater DH_{dc} $DH_{dc}$ in sicherem Speicher), Authentizität (signiert von BDr \leftarrow $\leftarrow$ BSI, BSI-Root-Cert. auf dem Chip gespeichert), Authentisierung (PA-Besitzer mit PIN, PA gegenüber Dienst mit DH_{dc} $DH_{dc}$ ), Vertraulichkeit (kontrollierte Zugriffe)

eIDAS 2.0

electronic IDentification, Authentication and trust Services (eIDAS): EU-Verordnung über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen
- Ziele: verbindliche europaweite Regelungen, Förderung der Entwicklung und Nutzung sicherer und interoperabler digitaler Identitäten in der EU, grenzüberschreitende elektronische Transaktionen, Stärkung des Vertrauens in digitale Dienste
- Verordnungen sind sofort nach der Verabschiedung in jedem Mitgliedsstaat gültig
- drei Sicherheitsniveaus: niedrig, substanziell, hoch; die eID des PA ist als Sicherheitsniveau hoch notifiziert
- European Digital Identity (EUDI) Wallet: persönliche, vom Nutzer kontrollierbare (?), digitale Brieftasche mit digitalen Ausweisen zur Online-Identifikation; cloud-basiert
  - bis Ende 2026 umzusetzen; Verwaltung von Identitätsausweisen und amtlichen Dokumenten (z.B. Führerschein, Führungszeugnis, Zeugnisse, PA auf dem Smartphone)
  - im Kontext der EUDI Wallet: Person Identification Data (PID); grenzüberschreitende Anerkennung der IDs, attestierte ID-Attribute, sichere Authentisierung, qualifizierte Signatur
  - Umsetzung in Deutschland durch das BMDS, koordiniert durch die SPRIND; aktueller Umsetzungsstand: verteilte, cloud-basierte Lösung mit Key-Store in der Cloud (dort ist hohes Sicherheitsniveau umsetzbar), aber private Schlüssel sollen auch sicher auf den privaten Smartphones bereitgestellt werden (HSM kann man nicht postulieren, nur TEE!)
  - Architektur des EUDI-Wallet-Ökosystems: Device (z.B. Smartphone), Wallet (App, mehrere pro Device möglich), WSCA (Key-Store und sichere Umgebung, tamper-proof, Level high, z.B. HSM, Smartcard)

Fast Identity Online (FIDO)

Universal Second Factor (U2F): Ergänzung der Authentisierung beim Online-Dienst um einen echten zweiten Faktor, z.B. Token; ergänzt Passwort-Login
FIDO2 (WebAuthn, CTAP2): Bereitstellung passwortloser und Multifaktor Authentifikation für Online-Dienste; ersetzt Passwort-Login
Ziel FIDO: Protokolle für eine offene Nutzer-Authentisierung im Web; Berücksichtigung der Authentisierungsfähigkeiten lokaler Client-Geräte (z.B. Fingerprint, Gesichtserkennung bei MFA); einfache, nutzerfreundliche Umsetzung
FIDO-Systemarchitektur: Client-Rechner mit Authentisierungsverfahren (Authenticator) und Server/Relying Party (Online-Dienst)
Passkey-Verfahren (Recap): Login beim Server per Public-Key-Authentication, ersetzt das klassische Passwort-Login
- abgewandelte 2-Faktor-Authentisierung: Faktor 1 ist die lokale Authentisierung beim lokalen Authenticator F auf dem Nutzergerät (z.B. Fingerprint), Faktor 2 die signierte Response an den Server
- hoher Comfort: 2FA-artige Authentisierung mit wenig Aufwand
CTAP1 (früher U2F): Kommunikation zwischen FIDO2-fähigem Browser, BS und einem U2F-Device (z.B. USB- oder NFC-Dongle, ggf. mit integriertem Secure Element)
- U2F-Device ist nicht an ein Gerät und nicht an eine Person gebunden; Ziele: hoher Nutzungskomfort, hohe Sicherheit, Interoperabilität
- Basis: Standard-Krypto-Verfahren: ECDH-Schlüsselaustausch, ECC, AES-CBC, SHA-256, ECDSA/SHA-256
- Phase 1 Registrierung: Browser sendet Origin und Server-Key Y_S $Y_S$ ; Device generiert (X_D, Y_D) $(X_D, Y_D)$ neu, berechnet K_{ds} $K_{ds}$ mit X_D, Y_S $X_D, Y_S$ , generiert Schlüsselpaar (Priv_U, Pub_U) $(Priv_U, Pub_U)$ und speichert Origin und K_{ds} $K_{ds}$ ; Y_D $Y_D$ , Pub_U $Pub_U$ und ein Attest (signiert mit Hersteller-Key) gehen an den Server
  - Origin: Daten vom Browser, z.B. TLS-Zertifikat, als Evidence, dass S authentisch ist
  - Attest: erlaubt S zu prüfen, ob D ein genuines Device ist
- Phase 2 Wiederholtes Login: Server sendet Nonce r $r$ , Key-ID und c_1 = AES_{K_{ds}}(K_{db}) $c_1 = AES_{K_{ds}}(K_{db})$ ; Device entschlüsselt mit Nutzer-Präsenz, prüft den Origin, berechnet res = AES_{K_{db}}(r) $res = AES_{K_{db}}(r)$ und c_3 = Sig_{Priv_U}(res) $c_3 = Sig_{Priv_U}(res)$ ; Server prüft c_3 $c_3$
Sicherheitsbetrachtung: Origin-Bindung wehrt Phishing/Client-Spoofing ab; Server-, Dongle- und Browser-Authentisierung sind gegeben; kein Personenbezug (Unterschied zu eID des PA: kompakt und bequem, aber keine hoheitliche Identität)

Verteiltes ID-Management

Ziel: möglichst wenige Trusted Server \to $\to$ möglichst kleine Angriffsfläche (1:n $1:n$ )
Single-Sign-On (SSO): einmalige Authentisierung bei Trusted Third Party (TTP) / ID-Provider (IDP) und Zugriff ohne erneute Authentisierung auf n $n$ Services
Föderierte Identitäten: mit einer Identität hat ein Nutzer die Möglichkeit, auf Anwendungen unterschiedlicher Organisationen zuzugreifen

Single-Sign-On (SSO)

A $A$ möchte Dienst S1 $S1$ nutzen
A $A$ authentisiert sich gegenüber TTP, bitttet um Authentizitätsbescheinigung zur Vorlage bei S1 $S1$
TTP prüft Authentizität, erstellt Authentizitätsbescheinigung
A $A$ reicht Authentizitätsbescheinigung an S1 $S1$ weiter
S1 $S1$ prüft Gültigkeit der Authentizitätsbescheinigung

Kerberos-Protokoll

Key Distribution Center (KDC): TTP, besteht aus AS und TGS
- Authentication Service (AS): initialer Login, vergibt TGT
- Ticket-Granting Service (TGS): vergibt Service-spezifische Tickets via TGT

Föderierte Identitäten

Identitätsprovider (IDP): authentisiert Nutzer, verwaltet Nutzeridentitäten, unterhält Vertrauensbeziehungen zu Dienstanbietern

OAuth2, OpenID Connect

OAuth2: Authorisierungs-Framework; erlaubt es einem Drittanbietern, die Ressourcen eines Nutzers (Owners) zu verwenden, ohne dass sich dieser authentisiert (also z.B. keine Passworteingabe); HTTP via TLS
- Resource-Owner (RO): Benutzer, delegiert Zugriffsrechte auf seine geschützte Ressource an Web-Anwendung (Client)
- Resource-Server (RS): verwaltet Ressourcen des ROs
- Client (C): fordert mit Authorization Grant (AG) einen Access Token (AT) beim Autorisierungs-Server (AS) an (C muss beim AS mit seinen Credentials registriert sein)
- Access Token (AT): Zugriffs-Autorisierung, enthält Gültigkeitsdauer, Anwendungsbereich, opt. Client-Bindung
- Autorisierungs-Server (AS): Client und RO sind beim AS mit ihren Credentials registriert, AS authentisiert RO, prüft AG und erstellt AT für Client
  - muss dafür sorgen, dass AT nicht von Dritten generiert, erraten oder manipuliert werden kann, muss Redirect-URIs prüfen, muss TLS benutzen
- Proof Key for Code Exchange (PKCE): „Geheimhandschlag“, der beweist, dass die App, die den Anmeldevorgang gestartet hat, auch diejenige ist, die ihn abschließt, ohne dass ein Client Secret erforderlich ist.
OpenID Connect (OIDC): OAuth2 + Nutzerattribute und Authentizitätsinformationen, AS dient als IDP
- Confidential Clients: können Credentials und secret Keys sicher speichern und sich gegenüber dem AS authentisieren
- Public Clients: untrusted, keine sichere Speicherung von Keys
- Claim: Menge von Attributen (wichtig: issuer, subject, audience, expiration, nonce)

Self-sovereign Identity (SSI)

Self-sovereign Identity (SSI): Nutzer verwalten ihre Identitäten und persönlichen Daten „selbstsouverän“ und haben die volle Kontrolle darüber, welche Dienste auf ihre Identitäten zugreifen können
- Vertrauen in Identitätsinformationen muss explizit hergestellt werden, z.B. durch X.509, Web-of-Trust oder Blockchain
- keine Abhängigkeiten von Dritten; kompatibel mit dezentralen Diensteplattformen (Blockchain etc.)
klassisches Modell (Trusted Third Party): zentrale Identitätsprovider (Google, Facebook, Verimi) verwalten die Nutzeridentitäten und setzen die Autorisierungsentscheidungen der Nutzer bzgl. des Zugriffs auf Identitäten durch
- Vertrauen in Identitätsinformationen wird implizit durch das Vertrauen in den IdP sichergestellt
- konzeptuell inkompatibel mit dezentralen Diensteplattformen
Decentralized Identifier (DID) (W3C-Standard): standardisierte Identität, die ohne IdP (Google, Facebook etc.) ausgestellt wird
- DID: String mit festgelegtem Format; verweist auf ein DID-Dokument, das u.a. Public Keys enthält, um den DID-Controller (Entität, die den DID ändern darf) zu authentisieren
- Erzeugung: Generierung eines Public-Key-Paares, lokale Verwaltung des Private Keys, Speicherung des Public Keys im DID-Dokument, Registrierung von DID und DID-Dokument in einer Registry
Verifiable Claims / Credentials: DIDs werden zusammen mit Verifiable Claims verwendet
- (semi-)hoheitliche Entitäten (Issuer, z.B. E-Mail-Provider, KVR) geben signierte Identitätsattribute (Verifiable Claims) an Nutzer aus
- Nutzer können von unterschiedlichen(!) Entitäten Claims vorlegen und sich auch selbst signierte Attribute ausstellen
- Vorlage bei Online-Dienste-Providern: Rollen Credential Repository, User Agent, Credential Consumer
  1. Nutzer navigiert zur Webseite des Anbieters (z.B. Anforderung: mindestens 21 Jahre)
  2. User Agent fordert einen Nachweis an, Repository liefert die relevanten Credentials
  3. Nutzer wählt ein Credential aus, das als Nachweis an den Consumer übergeben und dort verifiziert wird

Hardware-basierte Sicherheit

hardwarebasierte Sicherheit: Sicherheitskonzepte durch Hardwarekomponenten unterstützen
- spezielle Chips: HSM, z.B. TPM
- Hardware-Erweiterungen: Trusted Execution Environment (TEE), z.B. Intel SGX, AMD SEV, ARM TrustZone

Trusted Platform Module (TPM)

Trusted Platform Module (TPM): Hardware-Chip, standardisierter Krypto-Coprozessor
- Core Root of Trust for Measurement (CRTM): BIOS-Erweiterung, erster Schritt eines sicheren Boots
- Trusted Software Stack (TSS): TPM-API, Software für Zugriff auf TPM-Chip
- Trusted Network Connect (TNC): Integritäts-Checks von Geräten über das Netzwerk, vor einem Zugriff
- Platform Configuration Register (PCR): spezielle, geschützte Register
- Attestation Key (AIK): asymmetrische Keys, Pseudonyme zur Attestierung des Zustands des TPM

Features

Krypto-Primitive: Schlüsselgeneration, Signaturerstellung, Hashing, Ver- und Entschlüsselung
Eindeutige Chip-ID (Endorsement Key, EK): asym. 2048-bit RSA-Schlüsselpaar (e_{EK}, d_{EK}) $(e_{EK}, d_{EK})$ , bei Chip-Produktion generiert, nicht exportierbar; um festzustellen, dass ein bestimmtes TPM echt ist (von einem vertrauenswürdigen Hersteller gefertigt und konform mit den TCG-Spezifikationen), und als Vertrauensanker für die Identifizierung des TPM selbst zu dienen
Inbesitznahme durch einen Nutzer: take_ownership + Owner-Passwort \to $\to$ Owner-Authentication Key (OAK, Hash des Passworts)
Zugriffsgeschützte Daten / Befehle: sensitive Daten werden mit e_{EK} $e_{EK}$ verschlüsselt und benötigen d_{EK} $d_{EK}$ zum entschlüsseln (Nachweis des Owner-Passworts)
PCR-Register: Speicherung von Hashwerten von geladenen Systemmodulen \to $\to$ Zustand der Plattform
Integritätsmessung und Reporting: Systemzustand repräsentieren über Hashwerte von Daten (z.B. Code), u.a. Hashen der beim Booten geladenen Komponenten; auf Anfrage eines externen Dienstes erstellt der TPM einen Report (enthält Werte der angefragten PCR-Register \to $\to$ Systemzustand)
Attestierung: AIK benutzt, um Nonce zu signieren
(Un-)Sealing: Verschlüsselung mit einem internen TPM Public Key von Daten unter Einbeziehung von Werten aus PCR-Registern; Entschlüsselung wenn privater RSA-Schlüssel zugreifbar ist und PCR-Register korrekte Werte aufweisen

Storage-Root-Key (SRK): Wurzel der Schlüsselhierarchie (asym. Schlüsselpaar, bei Take-Ownership generiert, überschreibt alte Werte); benutzt, um zur Laufzeit weitere Schlüsselpaare zu generieren
Measured Boot: Vertrauenskette aufbauen; kombinierbar mit UEFI Secure Boot
- PCR(i)_{t+1}=H(PCR(i)_t\;||\;\text{neue Messung}) $PCR(i)_{t+1}=H(PCR(i)_t\;||\;\text{neue Messung})$

Implementierungsvarianten

Discrete TPM: separater Chip
Integrated TPM: Teil eines Chips, mit Logikeinheit verbunden, keine Tamper-Resistance (u.a. in Gateway-Komponenten)
Firmware TPM: läuft in CPU geschützter Umgebung (u.a. in Consumer Devices)
Virtual TPM: vom Hypervisor bereit gestellt (u.a. in Cloud-Umgebungen)

Trusted Execution Environment (TEE)

Trusted Execution Environment (TEE): sicherer, isolierter Bereich innerhalb eines CPUs, der die Vertraulichkeit und Integrität des darin geladenen Codes und der Daten schützt; Code und Daten innerhalb der TEE sind vor unbefugtem Zugriff oder unbefugter Änderung geschützt, bei einigen Designs sogar vor privilegierter Software oder dem Gerätebesitzer
Motivation: Privilegien-Stufen (Ringe, Domänen) schränken den nutzbaren Befehlssatz und Speicherbereich von Prozessen ein und schützen Prozesse gegeneinander und gegenüber dem Betriebssystem, aber nicht vor privilegierten Prozessen (problematisch u.a. in Cloud und Edge Computing, z.B. durch Hypervisor oder Cloud-Provider)
TEE-Konzept: Hardware-Erweiterung für sichere Code-Ausführung auf (remote) Rechnern; die Hardware etabliert einen sicheren Container, Code wird in den Container geladen und geschützt ausgeführt
- Trennung in Normal World (untrusted) und Secure World (trusted, TEE); Schutz auch vor OS und Hypervisor
- Idee: Trusted Hardware auf dem (remote) Rechner (z.B. Cloud-Plattform) attestiert (Signatur) den Container; Code/Daten werden nur geladen, wenn der Hashwert korrekt ist
- neues Paradigma: Confidential Computing basierend auf TEE (Schutz von Daten/Code in use)

Intel Software Guard Extensions (SGX)

Intel-CPU-Befehlssatzerweiterung, ermöglicht geschützte Verarbeitung in sicheren Containern, den Enclaves (in Ring 3)
- die User-level-Applikation muss in einen trusted/untrusted Teil aufgeteilt werden; für den trusted Bereich wird die Enclave erzeugt, der trusted Teil geladen und gehasht
- dedizierter Speicherbereich im DRAM für Enclaves: Memory Encryption Engine (MEE); schützt vor untrusted OS-Kern, Hypervisor, DMA, Firmware und Applikationen
- trusted: SGX-Microcode und spezielle Enclaves mit Zugriffen auf Hardware-Keys
Schlüssel: pro Enclave ein AES-Key, abgeleitet aus CPU-Keys und Enclave-Date (\to $\to$ Sealing); Ver-/Entschlüsselung und Hashen der Pages (4 KB) mit AES-GMAC (AEAD)
- pro Chip zwei fused Chip-Keys: Provisioning Key (für Remote Attestation) und Sealing Key RSK (für lokale Nutzung)
- pro Enclave: K_{S_i} = KDF(RSK, SHA\text{-}256(\text{Code}, \text{Daten}, \text{Location})) $K_{S_i} = KDF(RSK, SHA\text{-}256(\text{Code}, \text{Daten}, \text{Location}))$ , Blob: \text{AES-GMAC}_{K_{S_i}}(\text{Enclave-Daten}) $\text{AES-GMAC}_{K_{S_i}}(\text{Enclave-Daten})$
Enclave Page Cache (EPC): im MEE verwaltet, max. 128 MB (keine vollständige VM schützbar); Entschlüsselung von EPC-Seiten nur im Prozessor-Core zulässig; jede Enclave besitzt eigenen Stack/Heap sowie per-Enclave RSA-Attestierungs-Keys
- Integritätsmessung: SHA-256-Hashwert über Speicherinhalte (Merkle-Tree-Struktur); Enclave-ID: ID = SHA256(\text{Code}, \text{Daten}, \text{Seiten im EPC}, \ldots) $ID = SHA256(\text{Code}, \text{Daten}, \text{Seiten im EPC}, \ldots)$
Lokale Attestierung: Enclaves validieren, dass sie dieselbe Plattform nutzen \to $\to$ symmetrische Krypto
- Austausch der Enclave-IDs ID_A, ID_B $ID_A, ID_B$ ; A erstellt einen Report (enthält Daten, DH-Key für später, ID_A $ID_A$ , ID_B $ID_B$ ) und berechnet K_{report} = E_{REPORT}(ID_A, ID_B) $K_{report} = E_{REPORT}(ID_A, ID_B)$ sowie mac = SHA_{K_{report}}(report) $mac = SHA_{K_{report}}(report)$
- B berechnet mac' = SHA_{K_{report}}(report) $mac' = SHA_{K_{report}}(report)$ und vergleicht mit mac $mac$ ; anschließend führen die Enclaves DH durch und etablieren Keys für die Enclave-Kommunikation
Remote Attestation (stark angelehnt an die TPM-Attestierung): Nachweis, dass die attestierte Enclave auf einem genuinen Intel-Chip läuft, plus Signatur des Hashwertes der Enclave (Code, Firmware-Information, Application-Data)
- Basis: chip-globaler Attestierungs-Key (abgeleitet aus Hardware Sealing Key) mit Zertifikat für den Public-Part und Endorsement-Zertifikat (i.d.R. von Intel)
- der Requester prüft Endorsement-Zertifikat, Signatur und Hash-Validierung; Vertrauensanker ist Intel
Probleme: der Programmierer muss die Anwendung in trusted/untrusted aufspalten; anfällig gegen Seitenkanalangriffe (veröffentlichte Angriffe, z.B. Foreshadow, Nemesis)

Intel Trusted Domain Extensions (TDX)

seit 2/2025 Unterstützung durch Xeon-6-Prozessoren; hardwarebasierte Isolierung von VMs, den TDs (inklusive OS, Treibern etc. in der VM)
- Isolierung von VMM/Hypervisor und allen Nicht-TD-Komponenten; neuer CPU-Modus SEAM (Secure Arbitration Mode): das TD-Sicherheitsmodul läuft in reserviertem Speicher und wird von Intel signiert (aber nicht verschlüsselt)
- MKTME (Multi-Key Total Memory Encryption): zur Bootzeit generierter 128-Bit AES-Key, nicht auslesbar; AES-XTS-verschlüsselte Pages, SHA3-256 für Integrität
- Remote Attestation: ECDSA-Signaturen bestätigen die gehashte TD und einen genuinen Chip

AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging)

seit 2021 auf AMD EPYC Prozessoren verfügbar; nur dem AMD-Prozessor und der AMD-Firmware wird vertraut, alles andere ist untrusted (BIOS, OS, Treiber, Hypervisor etc.)
- pro VM ein AES-Key, mit TRNG generiert und in geschützten Registern gespeichert
- mit integriertem SEV-ES: Verschlüsseln der VM-Register beim Kontextwechsel zurück in den Hypervisor
- Integritätsschutz für die VM: Replay Protection, Zugriff nur durch den Owner-Prozess, Schutz vor malicious Hypervisor
- Remote Attestation: Hashen der Seiteninhalte der VM, Signieren mit internem Hardware-Key VCEK (signiert von AMD)

Fazit TEE

TEEs gewinnen für IoT sowie Edge- und Cloud-Computing stark an Bedeutung und unterstützen das wichtige Konzept des Confidential Computing (Schutz von Daten/Code während der Ausführung)
deutliche Erweiterung/Flexibilisierung der TPM-Ansätze; Hardware-Extensions werden von den großen Chip-Herstellern Intel, AMD und ARM entwickelt (Intel TDX, AMD SEV-Varianten, Arm CCA)
Vorgänger-Versionen waren teilweise zu restriktiv und mit Schwachstellen (z.B. AMD SEV-SNP: Performance-Counter-Attacks, unfixed); TEEs werden zukünftig breitflächig zur Absicherung verfügbar sein

iOS-Sicherheit

iOS-System: Closed World; Apple kontrolliert Hardware und Software
Secure Enclave Prozessor (SEP): eigener Security-Coprozessor, isoliert vom Application Prozessor (AP, untrusted) zum Schutz der Nutzerdaten, falls das System kompromittiert ist
- sepOS: eigenes OS des SEP; sicheres Update (Secure Update)
- Boot ROM: RoT für sicheres Boot (Secure Boot) für sepOS
- AES-Engine: AES-XEX; Schlüssel nicht für A-Prozessor (\to $\to$ iOS) zugreifbar
- Geräte-ID (UID): eindeutiger 256-bit AES-Schlüssel, in Silizium implementiert (nicht über JTAG lesbar), nur innerhalb der SEP nutzbar (\to $\to$ Bindung von verschlüsselten Daten an ein Gerät)
- Gruppen-ID (GID): gleich für alle Geräte einer Prozessorfamilie, 256-bit AES-Schlüssel, nur innerhalb der SEP nutzbar (\to $\to$ over-the-air sepOS-Updates)
- Speicherschutzschlüssel K_{eph} $K_{eph}$ : SEP nutzt DRAM des AP, muss also verschlüsselt werden mit ephemeral K_{eph} $K_{eph}$ (beim Boot neu erzeugt) \to $\to$ c=AES_{K_{eph}\;||\;UID}(Data) $c=AES_{K_{eph}\;||\;UID}(Data)$
- Encryption Controller Register (ECR): speichert K_{eph} $K_{eph}$ für die jetzige Boot-Session

Authentisierung und Entsperrung

Passcode: Zugangscode zur Authentisierung und Entschlüsselung von Schlüsselmaterial für Dateizugriff
- Master-Key (MS): abgeleitet aus Passcode, gebunden an UID \to $\to$ Brute-Force muss auf dem Gerät passieren; wird nicht gespeichert, sondern nach Nutzung verworfen
- (!) stets in wichtigen Situationen erforderlich (z.B. Secure Update)
Biometrie: Nutzerkomfort; Optic ID, Face ID, Touch ID
- Trennung: verschlüsselter Transfer der biometrischen Daten zwischen Sensor und SEP; Abgleich in SE mit gespeicherten Referenzdaten basierend auf ML

Datei-Schutz

Complete Protection: stärkste Schutzklasse, AES-Schlüssel CK nur bei entblockiertem Gerät nutzbar; beim Lock wird CK mit MK geschützt, in Flash gespeichert und aus SEP-RAM gelöscht
Protected Until First User Authentication: CK wird beim ersten Unlock entschlüsselt und beim Lock nicht aus SEP-RAM gelöscht (\to $\to$ Dateien können auch bei gelocktem Gerät beschrieben, geöffnet, erzeugt werden; default für Third-Party-Apps)
No Protection: CK nur mit UID verschlüsselt, Defaultklasse für alle Dateien
Protected Unless Open: zulässiger Schreib-Zugriff auf geöffnete Dateien, auch wenn Gerät gelockt ist (kein Schutz solange geöffnet, z.B. Download eines Mail-Anhangs), aber kein Zugriff auf geschlossene Dateien
- (!) SEP muss DK entschlüsseln können ohne Nutzer-Eingabe \to $\to$ Datei-spezifisches shared Secret s $s$ erzeugt via ECDH mit privatem Dateischlüssel und öffentlichem Klassenschlüssel, bleibt in SEP-RAM, erst nach Close gelöscht

Keybags: Verwaltung von Klassenschlüsseln CK
- User Keybag: Datei mit Attribut No Protection; enthält verschlüsselte CKs, die nach Eingabe des Passcodes im SEP entschlüsselt werden
- Backup Keybag: erzeugt, wenn iTunes ein verschlüsseltes Backup erstellt

Fallstudie: Telematikinfrastruktur (TI) und ePA

Telematikinfrastruktur (TI): sichere Infrastruktur für medizinische Fachanwendungen; die elektronische Patientenakte (ePA) ist eine solche Fachanwendung
- komplexe und heterogene Infrastruktur: u.a. 70 Mio Versicherte, 93k Praxen, 17k Apotheken, 95 Krankenkassen
- TI 2.0: föderiertes ID-Management basierend auf OpenID Connect; sektorale IDPs für Krankenversicherung und Ärztekammer; die zukünftige GesundheitsID wird durch den sektoralen IDP bereitgestellt
- diverse Authentifikationsmethoden: GesundheitsID, eID, ...
Stakeholder: Patient (besitzt eGK und GesundheitsID), Leistungserbringer LEI (besitzen HBA und SMC-B, stellen eRezepte/Arztbriefe aus und signieren diese), FDZ Forschungsdatenzentrum (anonymisierte Forschungsdaten), Krankenkassen KK (geben eGK und GesundheitsID aus)

Elektronische Gesundheitskarte (eGK)

die eGK dient als Versicherungsnachweis und wird von der Krankenkasse ausgestellt
- Versichertenstammdaten auf dem Chip: Name, Adresse, Krankenkasse, Notfalldaten
- asymmetrisches Schlüsselpaar für die CR-Authentisierung der eGK, CVC-Zertifikat, weitere Zertifikate (optional)
- PIN bei ePA 3.0 für den Online-Zugriff; später sollen auch weitere (medizinische) Daten abgelegt werden
Zugriff auf die Daten der eGK über den Konnektor (Heilberufler, Mitarbeiter)
- lesender Zugriff: Institutskarte bzw. SMC-B (Security Module Card Type B), eingesteckt in den Konnektor (in den Praxen versiegelt)
- schreibender Zugriff: HBA + PIN (Heilberufler)
- 2-Karten-Prinzip: eGK und HBA oder SMC-B müssen im Kartenlesegerät eingesteckt sein

Versichertenstammdatendienst (VSDD/VSDM)

Krankenkassen müssen die Versichertenstammdaten auf der eGK der Versicherten speichern; VSDD ist eine gesetzlich verpflichtende Anwendung auf der TI
- VSDM verwaltet die administrativen Daten des Versicherten: persönliche Daten, Krankenkasse, Krankenversichertennummer, Versichertenstatus, Infos zu Versicherungsschutz, Kostenerstattung
- Zugriff auf den VSDD über Konnektoren in der Praxis nur nach Authentifizierung mit SMC-B/HBA; automatischer Abgleich der Versichertenstammdaten in Praxis und eGK (erfordert die eGK des Patienten); verpflichtender Prozess für LEI beim ersten Kontakt im Quartal
- PoPP (Proof of Patient Presence): Nachweis der Authentizität des Versicherten, bestätigt, dass ein Versorgungskontext vorliegt; ab 2026 auch mit GesundheitsID

Elektronische Patientenakte (ePA)

seit 5/25 für 73 Mio gesetzlich Versicherte und für LEI verpflichtend
- das Aktensystem der ePA speichert und verwaltet medizinische Dokumente und Befunde der Patienten (u.a. Arztbriefe, Befunde, Diagnosen, Therapieberichte, Medikationspläne, Notfalldaten, Impfpässe, Organ- und Gewebespende)
- pro Patient eine ePA-Akte, zugeordnet zur eGK; es kann mehrere Aktensysteme geben, aber nur 1 Aktenkonto pro Patient
Hoheit des Patienten: die KK richtet die ePA ein, hat aber keinen Zugriff auf die Daten
- Widerspruchsrecht (opt-out) gegen die Einrichtung einer ePA, aber jederzeit rückgängig zu machen (opt-in)
- Löschen einzelner Dokumente; alle Daten werden zunächst gespeichert
- der Patient kann individuell Ärzten/Apotheken etc. Befugnisse erteilen (Zugriffsrechte geben/verweigern)

ePA-Architektur und Key-Management

verschlüsselte ePA-Daten, individuell pro Versicherten verschlüsselt: K_{Akte} = KDF(\text{Masterkey 1}, KVNR) $K_{Akte} = KDF(\text{Masterkey 1}, KVNR)$
- HSM mit Masterkey 1 (Basis der Datenverschlüsselung) und Masterkey 2 (Basis der Befugnis-Verschlüsselung); geschützte Hardware-Keys, bei Herstellung des Prozessors erzeugt
- VAU (Vertrauenswürdige Ausführungsumgebung, TEE) im Aktensystem: sichere Verarbeitung der sensitiven Daten und Auslagern der Daten in unsicheren Speicher
- Dokumentenablage mit AES 256 Bit; individuelle Schlüssel werden on-demand im HSM abgeleitet (K_{Akte} = KDF(\text{Masterkey 1}, KVNR) $K_{Akte} = KDF(\text{Masterkey 1}, KVNR)$ , K_{entitlement} = KDF(\text{Masterkey 2}, KVNR) $K_{entitlement} = KDF(\text{Masterkey 2}, KVNR)$ ) und liegen im Klartext nur in der VAU vor (keine sichere Speicherung erforderlich); VAU-Kontexte sind voneinander isoliert
Geräteregistrierung und KVNR-Übergabe an den Versicherten (für den Zugriff auf die eigene ePA): Registrierung eines Geräts (z.B. Laptop) im VAU-Device-Management über den IdP
- die VAU generiert einen Gerätetoken (shared secret zwischen Gerät und ePA) und einen Freischaltcode (per E-Mail), Freischaltung über die ePA-App
- Authentisierung über den zentralen IdP oder den sektoralen IDP (z.B. eGK + PIN, oder PA + PIN); der IDP gibt ein ID-Token mit der KVNR zurück
Befugniserteilung (Autorisierung) zum Zugriff auf die ePA:
1. primär über Gesetzgeber, gematik und Betreiber (Zugriffe gem. §352)
2. durch den Versicherten für LEI (z.B. Arzt) über die ePA-App: Befugnis = (KVNR_{Versicherter} $_{Versicherter}$ , Telematik-ID_{Arzt} $_{Arzt}$ oder KVNR_{Vertreter} $_{Vertreter}$ , Gültigkeit); die ePA-App signiert die Befugnis mit dem TI-Signaturdienst, Weitergabe an die ePA; i.d.R. 90 Tage Gültigkeit für den Arzt (Stecken der eGK, Behandlungskontext)
Wechselseitige Authentisierung beim Zugriff: VAU mit VAU-Zertifikat und Remote Attestation; Nutzer über IdP + Gerätetoken und CR der eGK; TLS-basierte E2E-Kommunikation von Konnektor/Gerät zur VAU
Zum Entschlüsseln der Daten im Aktensystem: ID-Token eines IdP und Kenntnis der KVNR (das ID-Token des Versicherten enthält die KVNR) \to $\to$ die VAU leitet die Schlüssel für die ePA ab

Nutzung einer Befugnis für ePA-Zugriff durch LEI

der LEI möchte im Rahmen des Behandlungskontexts (Stecken der eGK) zugreifen und benötigt die VSDM-Prüfziffer des Versicherten (erhält er vom VSDM beim Stammdatenabgleich) sowie eine Befugnis (z.B. um einen Arztbrief zu speichern)
1. LEI authentisiert sich beim zentralen IDP mit SMC-B und erhält ein ID-Token
2. Aufbau eines E2E-sicheren Kanals zur VAU über den Konnektor mit SMC-B
3. LEI schickt ID-Token und VSDM-Prüfziffer an das ePA-Aktensystem, zusätzlich KVNR und HCV (HCV = SHA256(\text{Versicherungsbeginn}, \text{Straße})[0:5] $HCV = SHA256(\text{Versicherungsbeginn}, \text{Straße})[0:5]$ )
4. die VAU erstellt mit der KVNR den versicherten-individuellen Schlüssel für die ePA; die Akte wird in der User-Session in einen neuen Health-Record-Context geladen (mehrere Contexts/Sessions möglich) und ist damit zugreifbar

TI - Next Steps

ab 2026: Ausweis in der Praxis mit GesundheitsID-App, keine eGK mehr notwendig (§291 SGB V Abs. 8); dafür wird derzeit VSDM 2.0 auf Basis von Zero-Trust/GesundheitsID umgesetzt
- automatische Pseudonymisierung und Übertragung der ePA-Daten in das Forschungsdatenzentrum Gesundheit (§342 SGB V), Ermöglichen von Zugriff Dritter auf dessen Daten
- Erklärung zur Organ- und Gewebespende in der ePA; Anbindung an EU eHealth mittels National Contact Point for eHealth (NCPeH) Diensten
Übergang auf TI 2.0 (ongoing) mit Zero-Trust-Architektur: eGK, eHBA und SMC-B werden durch IDs und Zertifikate ersetzt; Konnektoren in den Praxen werden unnötig, Zugriff auf die TI über TI-Gateway-Services (VPN in die TI)
- PoPP über ID, keine physische Präsenz („Stecken“ der eGK) erforderlich \to $\to$ flexibler, weniger Hardware-Erfordernis; dafür muss jeder Zugriff geprüft werden
immer wieder massive Kritik an der ePA-Umsetzung: u.a. Umgang mit Karten, IT in den Praxen, zu lange „offene“ Behandlungskontexte

Funknetze im Nahbereich

Funknetze im Nachbereich: WLAN, Bluetooth; drahtlos, Layer 2, für infrastrukturlose, ad-hoc Kommunikation
- Anforderungen: wechselseitige Authentisierung, Integritätsschutz, Key-Management

WLAN (WPA3)

Wi-Fi Protected Access (WPA3): verschlüsselte, integritätsgeschützte Verbindung zwischen Client und Access Point (AP)
- Pairwise Transient Key (PTK): neuer Schlüssel pro Verbindungssession, 384- bzw. 768-Bit, aus PMK abgeleitet
- Pairwise Master Key (PMK): langlebig, 256- bzw. 384-Bit, Trust-Basis
- Group Transient Key (GTK): pro SSID
- 4-wege Handshake-Protokoll: Authentisierung und PTK-Erzeugung; PTK= TK\;||\;KCK\;||\;KEK $PTK= TK\;||\;KCK\;||\;KEK$ (Temporal Key, Key Confirmation Key, Key Encryption Key)
Simultaneous Authentication of Equals (SAE): Dragonfly Handshake
- Commit-Phase: Ableiten eines gemeinsamen Schlüssels mit hoher Entropie aus WLAN-Passwort
- Confirm-Phase: Authentisierung, Nachweis der Kenntnis des Schlüssels
Authentisierung: 4-wege Handshake
Angriffe: Downgrade auf WPA2, Seitenkanalangriffe möglich (iteratives Ausprobieren bis Gruppenelement gefunden)

Bluetooth

Bluetooth Classic: seit 1998 von einem Konsortium (u.a. Ericsson, Nokia, Intel, IBM, Microsoft) entwickelt; Name nach Harald Blåtand (Blauzahn), Wikingerkönig
- Identifikation: 48-Bit Bluetooth-Device-Address (BT_ADDR), zusätzlich Bluetooth Device Name für die Interaktion mit Nutzern
Bluetooth Low Energy (LE): ab 2010; Layer 1 und Verbindungsaufbau unterschiedlich zu BT Classic
- geringere Sendeleistung (10-50 m, BT Classic bis zu 100 m), schnellerer Verbindungsaufbau (3 ms vs. > 100 ms)
- 37 Kanäle + 3 Advertisement-Kanäle: Device sendet kurzes iBeacon über einen Advertisement-Kanal und lauscht dort auf Verbindungsanfragen

Schlüssel und Schlüsselvereinbarung bei BT

Link-Key (LK): 128 Bit, beim Pairing als shared secret zwischen zwei Geräten etabliert; persistente Speicherung auch nach Verbindungsende \to $\to$ schnelle Authentisierung der Devices bei erneutem Verbindungsaufbau
Secure Simple Pairing (SSP): Protokoll zur Vereinbarung des LK; Ziel: Abwehr von passivem Eavesdropping und MitM-Angriffen
- 4 Verfahren für unterschiedliche Security Level: OOB, Just Works, numerischer Vergleich, Passkey Entry
Kommunikationsschlüssel K_c $K_c$ : 128 Bit (ab BT 4.1), pro Verbindung; jedes Gerät definiert einen festen Minimal-/Maximalwert, der Master sendet seine Maximallänge, iterative Abstimmung bis Konsens
- Verschlüsselung des Payloads mit AES-CCM, jedes Bluetooth-Paket wird einzeln verschlüsselt
SSP-Protokollablauf (6 Phasen):
1. Pairing Feature Exchange: Festlegen von Anforderungen und Fähigkeiten für das Pairing (IO capabilities als Basis für die Verfahrensauswahl: numerische Eingabe, numerische Anzeige, Ja/Nein-Eingabe; Signalisierung, dass OOB genutzt werden soll; optional: authentifizierter MitM-Schutz gefordert)
2. ECC-DH-Public-Key-Exchange: jedes Gerät generiert sein eigenes Elliptic-Curve-Diffie-Hellman-Schlüsselpaar (SK_I, PK_I) $(SK_I, PK_I)$ bzw. (SK_R, PK_R) $(SK_R, PK_R)$ , Austausch der Public Keys, Durchführung des ECC-DH-Key-Exchanges
3. Authentifizierung Stufe 1: Verfahren abhängig von den IO capabilities (Just Works, numerischer Vergleich oder Passkey Entry)
4. Authentifizierung Stufe 2: Handshake, für alle Stufe-1-Verfahren gleich
5. Link-Key-Berechnung: K = f_2(DHK, N_I, N_R, addr_I, addr_R) $K = f_2(DHK, N_I, N_R, addr_I, addr_R)$ , f_2 $f_2$ ist eine KDF
6. Link-Key-Authentifizierung und Verschlüsselung
Numerischer Vergleich: Replay-Schutz durch 128-Bit Nonces N_I, N_R $N_I, N_R$ ; Commits der Nonces verhindern eine nachträgliche Änderung
- MitM-Abwehr: beide Geräte berechnen 6-stellige Anzeigewerte V_I, V_R $V_I, V_R$ , der Nutzer führt einen Sichtvergleich auf beiden Geräten durch
Passkey Entry: Eingabe eines k-stelligen Passworts auf beiden Geräten; in k-Runden wird jedes Bit des Passworts über Hashwert-Bildung bestätigt (Commit-Werte C $C$ ); nach Empfang der Commits wird die Korrektheit des Passworts auf beiden Geräten unabhängig überprüft \to $\to$ die Public DH-Keys sind bestätigt, das shared DH-Secret kann genutzt werden

Private Device Addressing (BT LE)

Ziel: Tracking von BT-Devices anhand der statischen BT-Adresse verhindern, gepaarte Geräte sollen sich aber wiedererkennen
Identity Resolving Key (IRK): statischer 128-Bit Key pro Device, Austausch beim Pairing-Protokoll
Resolvable Private Address (RPA): dynamisch erzeugte 48-Bit-Adresse (z.B. alle 15 Minuten)
1. Erzeugen einer 24-Bit Nonce prand
2. Padding von prand nach festgelegtem Padding auf 128 Bit
3. Hash-Berechnung: h = \text{AES128-CMAC}_{IRK}(prand) $h = \text{AES128-CMAC}_{IRK}(prand)$ (128 Bit)
4. RPA-Berechnung: RPA = prand \;||\; h_{24} $RPA = prand \;||\; h_{24}$ (erste 24 Bit von h)
- Adress-Auflösung beim Empfänger, der den IRK besitzt: Extrahieren von prand aus der RPA, Berechnen von h' = \text{AES128-CMAC}_{IRK}(prand) $h' = \text{AES128-CMAC}_{IRK}(prand)$ , Vergleich h'_{24} = h_{24} $h'_{24} = h_{24}$

BT-Sicherheitsmodi

Modus 1: unsicher, keine Sicherheitsfunktionen; Default, die Sicherheitsdienste des LMP werden ignoriert
Modus 3: Sicherheitsmechanismen auf Schicht 2; vor einer Dienstnutzung Geräte-Authentifizierung, Vereinbarung eines Link-Keys, Verschlüsselung der nachfolgenden Kommunikation
Modus 2/4: Sicherheitsdienste auf höherer Ebene; Autorisierung der Zugriffe durch Sicherheitsmanager, Verschlüsselung für alle Datendienste außer Discovery, fortgeschrittene Schlüsselvereinbarung (authentifiziertes Pairing)

Fallbeispiel: Find my ... (iOS und andere)

Idee: Nutzung von Crowd-Finding, um ein verlorenes Gerät zu lokalisieren
- Lost Device (LD): das verlorene Gerät
- Owner Device (OD): Gerät des Besitzers, mit dem das LD gepaart ist
- eine Vielzahl von Finder Devices (FD), die verschlüsselte Aufenthaltsorte melden
- Apple Server (ApS): empfängt verschlüsselte Reports über die Aufenthaltsorte
Genutzte Konzepte: BLE-Advertisements (kein Pairing mit Empfänger-Devices erforderlich), ECC-Public-Key-Verschlüsselung/ECDH/Signatur, AES-GCM zum Verschlüsseln der Aufenthaltsreports, Rolling-Key-Konzept gegen Tracking, BLE-Resolvable Private Addresses für Advertisements
Offline-Finding-Schlüsselgenerierung: OD generiert Master Beacon Keys (d_0, e_0) $(d_0, e_0)$ und einen 256-Bit Schlüssel SK_0 $SK_0$ ; LD und OD leiten Rolling Advertisement Keys (d_i, e_i) $(d_i, e_i)$ , i > 0 $i > 0$ ab:
1. SK_i = KDF(SK_{i-1}, \text{„update“}, 32) $SK_i = KDF(SK_{i-1}, \text{„update“}, 32)$ (32 = Anzahl Ausgabe-Bytes)
2. (u_i, v_i) = KDF(SK_i, \text{„diversify“}, 72) $(u_i, v_i) = KDF(SK_i, \text{„diversify“}, 72)$ (288-Bit Anti-Tracking-Keys)
3. d_i = (d_0 \cdot u_i) + v_i $d_i = (d_0 \cdot u_i) + v_i$ und e_i = d_i \cdot G $e_i = d_i \cdot G$ (G: Generator der zugrundeliegenden ECC-Kurve)
Advertisements des LD (ohne Internetverbindung): alle 2 Sekunden ein Advertisement-Paket mit dem Public Key e_i $e_i$ ; Erneuerung des Public Keys alle 15 Minuten
Reports der Finder Devices: Erzeugen eines ephemeral Key-Paares (d', e') $(d', e')$ für das Advertisement, DH-Berechnung sk $sk$ mit e_i $e_i$ (vom LD) und d' $d'$ , Ableiten eines symmetrischen Keys k = SHA\text{-}256(sk \;||\; e_i) $k = SHA\text{-}256(sk \;||\; e_i)$
- die ersten 16 Byte von k $k$ bilden den Encryption Key k_{LF} $k_{LF}$ , die letzten 16 Byte den Initialisierungsvektor
- Verschlüsselung des Location Reports m $m$ : c = \text{AES-GCM}_{k_{LF}}(IV \;||\; m) $c = \text{AES-GCM}_{k_{LF}}(IV \;||\; m)$ ; FD laden signierte Reports in Batches (z.B. alle 30 Minuten) mit c $c$ , e' $e'$ und dem gehashten Public Key e_i $e_i$ des LD auf den ApS
Suche durch den Owner: OD sendet TLS-gesichert eine Liste der letzten Public Keys an den ApS (Authentisierung über die Apple ID des Nutzers), lädt die verschlüsselten Reports und entschlüsselt sie (Berechnen von sk $sk$ mit e' $e'$ und d_i $d_i$ , Ableiten von k $k$ , k_{LF} $k_{LF}$ )
Feature AirTag: Ultra WideBand (UWB) für präzisere Lokalisierung; Warnhinweis „AirTag Found Moving With You“, wenn sich ein AirTag längere Zeit mit dem eigenen Gerät mitbewegt (Tracking Detection inzwischen auch übergreifend mit Google-Geräten)

Trust-Etablierung in ad-hoc Szenarien

Anforderungen: sichere ad-hoc Kommunikation, wenn keine gemeinsame sichere Basis, kein pre-shared secret und keine PKI vorausgesetzt werden kann
Ansätze im Überblick:
- Evidenz der Authentizität der Partner über Messwerte: Resurrecting Duckling (in-band z.B. BT Just Works; out-of-band z.B. WPS Push Button), Zero-Interaction (Kontext über Zeitintervall), Distanz (ToF, noch nicht in BT LE)
- Evidenz der Authentizität von Schlüsseln: Key-Fingerprint (z.B. BT SSP numerischer Vergleich), passwortbasiert (PIN z.B. BT Classic; PAKE z.B. BT Passkey Entry, WPA3 Dragonfly)

Resurrecting Duckling Security Policy Model

Motivation (Stajano, 1999; Einsatzbereich z.B. IoT): mit Controller A besteht eine sichere Verbindung zum Öffnen eines Garagentors; kein Öffnen durch typgleiche Controller, aber ein kontrollierter Wechsel auf ein anderes Device soll möglich sein
Idee: Adaption des Imprinting-Konzepts aus der Biologie (nach K. Lorenz): ein frisch geschlüpftes Küken erkennt das erste sich bewegende Objekt, das ein Geräusch macht, als Mutter an
- Adaption: Master-Device ≙ Mutter (Controller A), Slave-Device ≙ Duck (Garagentor)
Zustände des Slave-Geräts: Imprintable (jedes andere Gerät kann eine Verbindung aufnehmen) vs. Imprinted (eine sichere Verbindung besteht nur zum Master)
Imprinting: Slave erkennt das Gerät als Master an, das ihm als erstes einen Secret Key SK sendet; der Versand erfolgt Out of Band
- mit dem shared secret wird eine sichere Verbindung etabliert; die Verbindung ist transient (kann gelöst werden), Master und Slave können andere Verbindungen eingehen
Umsetzungsvarianten:
- (a) in-band: Just Works-Variante des Bluetooth Simple Pairing (häufig bei BT LE, Austausch der Keys erfolgt ungeschützt); Vertrauen wird auf Basis physischer Nähe aufgebaut
- (b) OOB: WPS-Push-Button (Wi-Fi Protected Setup) am WLAN-Router
  - Idee: Schlüsselaustausch ohne Passworteingabe; der Nutzer betätigt eine Taste am AP und attestiert damit eine „Angreifer-freie“ Umgebung
  - innerhalb eines festen Zeitintervalls (2 Minuten) können Geräte im Funkradius den Schlüsselaustausch initiieren; der AP akzeptiert nur die erste Anfrage; Austausch von DH-Keys zwischen AP und Device
Problem 1: Manipulation über physischen Zugriff (Geräte z.B. in der Heimautomatisierung sind physischen Zugriffen ausgesetzt, z.B. SK modifizieren)
- Abwehr: Tamper-Proof-Geräte mit speziellen Schutzmaßnahmen im Hardware-Design (z.B. Sensorik, Schichten) oder Tamper-Evidence (z.B. integriertes TPM/SE, Remote Attestation) \to $\to$ beides zu aufwändig für preiswerte Geräte
Problem 2: Signal Tampering: der Angreifer nutzt u.a. destruktive Interferenz, um ein Signal zu verbergen/verändern (Wellen überlagern sich und heben sich auf); Abwehr: Tamper Evident Announcements (TEA)

Tamper Evident Announcements (TEA)

Ziel: Erkennen von aktiven Angriffen (Signal Tampering)
Vorgehen:
1. Senden eines langen randomisierten Signals zur Synchronisation (Erkennen des TEA-Starts); ein Angreifer kennt das Random nicht, ein Löschen des Signals ist nicht möglich
2. CTS_to_SELF: der Sender reserviert das Medium mit einer Folge von On/Off-Slots (z.B. bei WLAN beim Pairing: exklusives Senden)
3. Der Sender übermittelt als Payload z.B. einen Public Key; der Hash über die Payload wird balanciert in ON/OFF-Slots kodiert (|ON| = |OFF| $|ON| = |OFF|$ )
  - 1 ≙ ON-Slot: randomisiertes AM-Signal; 0 ≙ OFF-Slot: Funkpause
Wirkung: das Ändern des Payloads erfordert auch eine Änderung der On/Off-Folge; das Signal aus ON-Slots zu löschen ist kaum möglich (erforderliche Modulation nicht vorhersehbar), eine Umwandlung von OFF- zu ON-Slots würde das balancierte Gleichgewicht stören
- OFF-Slots sind Silent-Slots: sendet der Original-Sender in diese Slots, wird ein Mismatch erkannt; OFF-Slots verhindern den Capture-Effekt (gleichzeitiges Senden mit stärkerem Signal) \to $\to$ Tampering ist erkennbar
Tamper Evident Pairing (TEP): in-band-Lösung mit dem TEA-Protokoll für das Pairing; Ziel: Schutz vor aktiven Man-in-the-Middle-Angriffen ohne OOB-Kanal
1. Nutzer startet Pairing auf Gerät I (z.B. durch WPS-Push-Button)
2. Gerät I sendet TEP-Request mit sync | DH-Key_I | Hash-Slots; Push-Button bei R, Gerät R observiert den Kanal, prüft die Integrität des empfangenen TEA und sendet TEP-Reply mit sync | DH-Key_R | Hash-Slots
3. R und I observieren den Kanal weiterhin über einen festen Zeitraum
4. Abbruch, falls I oder R mehr Nachrichten empfangen oder ein Check fehlschlägt; ohne Störung im Zeitraum gelten die DH-Keys als authentisch

Zero-Interaction Protokolle

Idee: Etablieren eines shared Secrets über Messungen; Messen von lokal beobachtbaren, physikalischen Phänomenen (z.B. Beschleunigung, Phasenmodulation anderer Geräte) und Verwendung des Messwertes als shared Secret
- der Nachweis der Kenntnis der shared Secrets authentisiert die ausgetauschten DH-Public-Keys
- Problem: erfordert einen Mechanismus, um geringe Messtoleranzen zu erlauben und die notwendige Entropie zu gewährleisten
Context-Based Zero-Interaction Pairing (ohne Nutzer-Interaktion): Partner A, B bestätigen sich über einen längeren Zeitraum die Anwesenheit in einer räumlichen Umgebung
- Austausch nicht authentisierter DH-Keys \to $\to$ Shared-DH-Key K_0 $K_0$
- A und B bilden einen Fingerprint der Umgebungseffekte (Lichteinstrahlung, Umgebungsgeräusche) f_{A_i} $f_{A_i}$ bzw. f_{B_i} $f_{B_i}$ über einen Zeitraum
- A wählt s_i $s_i$ zufällig; Fuzzy-Commits zum Austausch von s_i $s_i$ :
  1. A erzeugt $r = $ Reed-Solomon-Encoding(s_i) $(s_i)$ und Fehlerkorrekturen
  2. A erzeugt Commit c = f_{A_i} - r \bmod 2^k $c = f_{A_i} - r \bmod 2^k$
  3. B berechnet r' = f_{B_i} - c \bmod 2^k = f_{B_i} - f_{A_i} + r \bmod 2^k $r' = f_{B_i} - c \bmod 2^k = f_{B_i} - f_{A_i} + r \bmod 2^k$
  4. B berechnet $s_i' = $ Reed-Solomon-Decoding(r') $(r')$
  5. s_i' = s_i $s_i' = s_i$ , falls Hamming-Distanz(f_{A_i}, f_{B_i}) < u $(f_{A_i}, f_{B_i}) < u$
  6. K_{i+1} = KDF(K_i, s_i) $K_{i+1} = KDF(K_i, s_i)$ , das Vertrauen steigt mit jeder Runde

Distanz-basierte Protokolle

Annahme: Kommunikation ist nur bis zu einer gewissen Distanz möglich, ein Angreifer kann nicht in diesen Bereich vordringen
Beispiel: Proximity/Keyless-Go, Time of Flight (ToF): $ToF \cdot c = $ Distanz zum Fahrzeug; Messen der Distanz/Zeit von Senden bis Empfang der Antwort
Distance-Bounding-Protokolle erfordern sehr genaue Zeitmessung, sind aber sicherer als die Signalstärkenmessung, da c $c$ (Lichtgeschwindigkeit) eine physikalische Konstante ist

Fingerprints der Public Keys

Idee: Abgleich durch den Nutzer durchführen lassen (ähnlich PGP oder SSH)
1. wechselseitiger Austausch der Public Keys
2. Fingerprint des empfangenen Public Keys erzeugen
3. Nutzer überprüft für beide Geräte den Fingerprint mit dem Referenzwert auf dem jeweils anderen Gerät
- Problem: erfordert ein Interface für den Nutzer (z.B. Display und Ja/Nein-Eingabe); die Nutzereinbindung ist fehleranfällig (z.B. beim Abgleich langer Strings)
Verbesserung: Reduktion der Hashlänge und Fingerprint über beide Public Keys \to $\to$ es ist nur noch ein Vergleich erforderlich
- Problem: ein zu kleiner Hashwert ermöglicht Angriffe wegen der schwachen Kollisionsresistenz (Erzeugen eines zweiten Public Keys mit gleichem Fingerprint ist möglich)
- Lösung: frische Nonce als Salt verwenden, Commitments berechnen, um Änderungen darüber erkennen zu können; Umsetzungsvariante: SSP-Variante numerischer Vergleich bei Bluetooth

Password-Authenticated Key Agreement (PAKE)

Ziel: besserer Schutz gegen Offline-Dictionary-Attacks, wenn ein Passwort als Basis verwendet wird (z.B. bei der WPA3-Personal-Version)
- der Angreifer soll zusätzliche Informationen nur durch mehr Interaktionen mit dem Server erhalten; Perfect Forward Secrecy muss gewährleistet sein
Lösungsansatz: interaktives Protokoll, um passwortbasiert einen gemeinsamen geheimen DH-Schlüssel abzustimmen; der Angreifer erhält keine Zusatzinformationen, schwache Passwörter können toleriert werden
Umsetzungsvarianten: Bluetooth SSP mit Passkey Entry, WLAN WPA3 SAE

Sicherheitsprotokolle

QUIC

Quick UDP Internet Connections (QUIC): modernes, sicheres Transport-Layer-Protokoll; läuft über UDP, integriert TLS 1.3 (kombiniert Verbindungsaufbau und Verschlüsselung \to $\to$ Latenzverringerung)
Motivation: Standard-Vorgehen ist TCP + TLS + HTTP; Probleme: TCP und TLS führen jeweils einen separaten Handshake durch (große Delays), TCP implementiert einen Bytestrom
- QUIC integriert TLS 1.3 und kombiniert den Verbindungsaufbau und die Verschlüsselung in einem Schritt (kein TCP-Handshake mehr) \to $\to$ Latenzminimierung, sogar 0-RTT möglich
- Multiplexing auf verschiedene Datenströme pro Verbindung: ein Kanalfehler stoppt nicht alle Streams (wie bei TCP)
- Versand redundanter Pakete \to $\to$ Fehlerkorrektur durch den Empfänger
- QUIC verschlüsselt auch Metadaten

DNSSEC

Domain Name System (DNS): hierarchisch strukturierter Namensraum, verteilt auf Server, in unabhängig administrierte Zonen unterteilt; setzt Domain-Namen in IP-Adressen um
- Problem: DNS prüft nicht, ob die Antwort tatsächlich vom auth. Server kam (siehe z.B. DNS spoofing / cache poisoning)
- Lösung: Authentizität und Integrität via DNSSEC
DNSSEC: Administrator einer Zone signiert DNS-Einträge; Empfänger prüft digitale Signatur der DNS-Antworten
- Zone Signing Key (ZSK): Schlüssel, der zum Signieren der eigentlichen DNS-Daten in der Zone verwendet wird
- Key Signing Key (KSK): Schlüssel, der ausschließlich zum Signieren der DNSKEY-Resource-Records selbst verwendet wird
- DNSKEY: DNS-Eintragstyp, der die öffentlichen Schlüssel der Zone (ZSK, KSK) veröffentlicht
- Resource Record Signature (RRSig): die eigentliche kryptografische Signatur, die einen Satz von Resource Records (ein RRset) desselben Typs und Namens abdeckt
- Delegation Signer (DS): Record, der in der übergeordneten Zone veröffentlicht wird und einen kryptografischen Hash (Digest) des KSK (oder des kombinierten Signaturschlüssels) der untergeordneten Zone enthält
Alternativen: DNS-over-TLS (DoT), DNS-over-HTTP(S) (DoH)

Tor (Onion Routing)

Onion Routing: Nachrichten werden in aufeinanderfolgende Verschlüsselungsschichten gehüllt (ähnlich den Schichten einer Zwiebel) und über eine Reihe von Zwischenknoten („Onion-Router“ oder Relays) geleitet; jeder Knoten entfernt nur eine Schicht, erfährt den nächsten Zielknoten und leitet die weiterhin verschlüsselte Nutzlast weiter; kein einzelner Knoten kennt sowohl den ursprünglichen Absender als auch das endgültige Ziel
Ziel: Privatsphäre/Anonymität der Nutzer stärken, Tracking erschweren; der Datenverkehr wird durch ein Overlay-Netzwerk von Relay-Knoten geleitet, die weltweit von Freiwilligen betrieben werden
- Tor-Zugang über einen Tor-Proxy (z.B. Tor-Browser); Wahl eines Relay-Servers aus einer signierten Liste eines Verzeichnisdienstes (dessen Public Key ist im Tor-Code integriert), Aufbau einer TLS-Verbindung zu diesem Eingangsserver, Wahl eines Multi-Hop-Pfades über mehrere Server (i.d.R. 3)
Schlüssel der Relay-Server: long-term Identity Key (asymmetrisch, für Signaturen, u.a. TLS-Zertifikate), short-term Onion Key (asymmetrisch, Wechsel alle 4 Wochen, für den sicheren Transfer von Client-Public-Keys), Link Keys (auf Basis von DH-Exchange)
Pfadaufbau (hop-by-hop): der Client etabliert mit jedem Relay des Pfades einen symmetrischen AES-Key (z.B. k_1, k_6, k_3 $k_1, k_6, k_3$ ); die Nachricht m $m$ wird schrittweise (Zwiebelschalen-Prinzip) verschlüsselt: c_2 = E_{k_3}(m) $c_2 = E_{k_3}(m)$ , c_1 = E_{k_6}(c_2) $c_1 = E_{k_6}(c_2)$ , c = E_{k_1}(c_1) $c = E_{k_1}(c_1)$ ; beim Weiterleiten entfernt jeder Node immer den äußeren Layer
Tor Onion Services: gehostete Services, anonym betrieben, Nachrichtenempfänger anonym, nur über das Tor-Netzwerk erreichbar (bilden das „Darknet“)
Probleme: durch Kontrolle über eine große Anzahl an Tor-Nodes ist es möglich, den Verlauf durch das Tor-Netzwerk nachzuvollziehen (Deanonymisierung!); Anonymität erfordert sehr viele Tor-Nodes; Nutzer müssen Tor sinnvoll anwenden (z.B. ein außerhalb von Tor eröffneter Mail-Account liefert keine Anonymität)
Tor Browser: modifizierte Version von Mozilla Firefox, verbindet sich automatisch zum Tor-Netzwerk, vermindert Tracking-Informationen (u.a. JavaScript deaktiviert, feste Fenstergröße, gespoofter User-Agent)

Mobilfunk (GSM, LTE, 5G)

Entwicklungsmeilensteine: 1991 2G GSM (Europa), 2006 3G UMTS (in Deutschland bereits abgekündigt), 2010 4G LTE, seit 2019 5G (DE); erste Aktivitäten zu 6G sind gestartet
- Übertragungsraten: GSM 9,6 kbit/s, LTE bis 300 Mbit/s, 5G bis 10 Gbit/s

GSM

pan-europäischer Standard (ETSI); zellular strukturiertes Funknetz mit unterschiedlichen Zellgrößen (jeweils eigene Frequenz) und Verfahren zur Zugriffsregulierung auf das Funkmedium

Subsysteme und Komponenten

Network Switching Subsystem (NSS): Vermittlung
- MSC (Mobile Switching Center): Vermittlungsstelle, Verbindungs- und Mobilitätsverwaltung
- HLR (Home Location Register): Speicherung der Kundendaten, auch Rufumleitungen und Billingdaten
- VLR (Visitor Location Register): Verwaltung von Gast-Nutzern, Location Area (LA), Rufzustellung
- AuC (Authentication Center): speziell gesichert, Verwaltung sicherheitsrelevanter Daten
- GMSC (Gateway MSC): Übergang in andere Netze
- Bem.: die Aufgaben von AuC, HLR, VLR wurden bis 5G weiter ausgebaut
Radio Subsystem (RSS): funktechnische Aspekte
- BTS (Base Transceiver Station): Versorgung der Funkzelle; 10-100 BTS sind an einem BSC angeschlossen, Kommunikation über die Luftschnittstelle (Um) mit dem MS
- BSC (Base Station Controller): BTS-Verwaltung, Auswahl eines Funkkanals, Entscheidung über Handover, Bündelung des Mobilfunkverkehrs
- MS (Mobile Station) mit SIM-Karte für den Zugang zum Netz; heutige Karten sind i.d.R. USIM-Karten (Basis: UICC), die GSM, LTE und 5G unterstützen
- SS7 (Signaling System Nr. 7): stammt aus dem Jahr 1970 (Telefonnetz PSTN, Closed-World, „jeder vertraut jedem“); Signalisierungskanal getrennt von den Datenkanälen, Management von Telefonverbindungen (Auf-/Abbau); noch im Einsatz, wird in 4G/5G schrittweise ersetzt; Bem.: SMS werden über den Signalisierungskanal übertragen
Operation & Maintenance Subsystem (OMSS): Betrieb & Wartung

GSM-Authentifizierung

symmetrisches Challenge-Response zwischen SIM und AuC des Providers
- Basis: 128-Bit Pre-Shared Key K_i $K_i$ zwischen SIM und AuC des Providers
- das AuC erstellt Authentifikations-Triplets: 128-Bit Challenge RAND und die vorberechnete Response SRES = A3(RAND, K_i) $SRES = A3(RAND, K_i)$ sowie den 64-Bit Kommunikationsschlüssel K_c = A8(RAND, K_i) $K_c = A8(RAND, K_i)$ ; A3 und A8 sind proprietär (vom Provider festgelegt)
- das AuC sendet das Triplet (RAND, SRES, Kc) an BTS/BSC; die SIM erhält über die BTS die Challenge RAND, berechnet SRES' = A3(RAND, K_i) $SRES' = A3(RAND, K_i)$ und sendet es zurück; BTS/BSC vergleicht SRES' == SRES $SRES' == SRES$ (keine Kenntnis von Ki erforderlich!)
- Daten in der SIM-Karte: IMSI (15 Ziffern), PIN und PUK, TMSI (Pseudonym, nur lokale Gültigkeit, mit LAI verknüpft), 128-Bit Ki, Algorithmus A3 (CR-Authentifikation), Algorithmus A8 (Generierung von Kc)
- Initiierung einer GSM-Authentisierung: beim Einbuchen, beim Update der Location (Wechsel der VLR), beim Call-Setup und beim Short-Message-Service (SMS)
- nach erfolgreicher Authentisierung: verschlüsselte Kommunikation auf der Luftschnittstelle (zwischen SIM und BTS) mit der A5-Stromchiffre (Varianten: A5/0 keine, A5/1 schwach, A5/2 verboten, A5/3 64 Bit)

GSM-Pseudonymisierung

Teilnehmer-Identifikation über die eindeutige IMSI, die mit der SIM verknüpft ist; Privacy-Problem: Tracken von Nutzern beim Handover ist möglich
- TMSI (Temporary Mobile Subscriber Identity) mit lokaler Gültigkeit; das HLR erzeugt die TMSI, protokolliert die Zuordnung IMSI ↔ (TMSI, LAI) und sendet (TMSI, LAI) an das VLR sowie LAI und TMSI mit Kc verschlüsselt über das VLR an die SIM
- Nutzung: bei Anruf/SMS-Paging ruft die BTS die TMSI der SIM an, nicht die IMSI; periodische Bestätigung (30 Minuten) der Anwesenheit
- TMSI-Update beim Wechsel der Funkzelle (neues VLR'): VLR' erzeugt eine neue TMSI' zur LAI' und sendet c = A5_{K_c}(TMSI' \;||\; LAI') $c = A5_{K_c}(TMSI' \;||\; LAI')$ an die SIM sowie ein Update (alte TMSI, TMSI', IMSI) an das HLR
- Frage: wer kennt am Ende die wahre Identität (IMSI)? \to $\to$ das Heimnetz (HLR/AuC)

GSM-Sicherheitsprobleme

nur einseitige Authentifikation (keine Netz-Authentisierung); IMSI-Catcher: Angreifer maskiert sich als BTS (sendet ein stärkeres Signal)
Verschlüsselung der Daten nur auf der Luftschnittstelle (danach Klartext)
SS7: unverschlüsselte Kommunikation über den Signalisierungskanal (z.B. SMS); Schlüssel in Triplets, Transport zwischen Netzbetreibern im Core-Netz
keine Datenintegrität (GSM-Fokus war Sprachkommunikation)
Fazit: positiv: skalierende Authentisierung vieler MS, Edge-Computing (Verschlüsselung in der BTS), nutzerfreundlich (Roaming, nur PIN-Eingabe erforderlich), Privacy durch Pseudonymisierungs-Konzept, Trennung von PDP (AuC) und PEP (BTS)
- negativ: keine Netz-Authentisierung (Spoofing), kein Integritätsschutz, zu kurze Schlüssellängen, unsicheres SS7 (Abgreifen von Kc), Bewegungsprofile mit IMSI-Catchern, zu große Trust-Domänen
GSM out-dated? Nein!: GSM-Modul im Fahrzeug (Kommunikation Auto ↔ OEM, z.B. Update); seit 31.3.2018 EU-Pflicht eCall (automatischer Notruf 112 bei Crash, eingebaute SIM plus GPS, Übermittlung von Unfallzeitpunkt, Auslöseart, 17-stelliger FIN, Antriebsart, Fahrzeugposition/-richtung, Insassenzahl; Sensoren zur Unfallerkennung); GSM-R (reservierte Frequenz, Zuglaufüberwachung, Notfall-Broadcast, Zugfernsteuerung, Bestandteil des European Train Control System ETCS 1/2)

UMTS (3G) - Sicherheitsarchitektur

LTE nutzt die verbesserte Sicherheitsarchitektur von 3G (UMTS)
- USIM mit pre-shared Key K (128 Bit, statt Ki); neu: das Heimatnetz/AuC authentifiziert sich gegenüber der USIM in der MS
- das AuC generiert Authentisierungsvektoren (AV): Erweiterung der Triplets auf 5 Teile: AV = RAND \;||\; XRES \;||\; CK \;||\; IK \;||\; AUTN $AV = RAND \;||\; XRES \;||\; CK \;||\; IK \;||\; AUTN$
  - Kommunikationsschlüssel CK (128 Bit), Integritätsschlüssel IK für Steuersignale
  - AUTN = (SQN \oplus AK) \;||\; AMF \;||\; MAC $AUTN = (SQN \oplus AK) \;||\; AMF \;||\; MAC$ mit MAC = f1(K, SQN \;||\; RAND \;||\; AMF) $MAC = f1(K, SQN \;||\; RAND \;||\; AMF)$ ; AMF: Authentication Management Field (z.B. Schlüssel-Lebenszeit), AK: Anonymitäts-Key (Verschleiern der Sequenznummer)
- der Provider leitet die AV an BSC/BTS weiter, diese leiten RAND und AUTN an die USIM; die USIM prüft AUTN (MAC und Sequenznummer)

LTE (4G)

Komponenten: User Equipment (UE), Mobility Management Entity (MME), Home Subscriber Service (HSS), Serving Gateway, Basisstation eNB
- SAE (System Architecture Evolution): Trennung von Control-Plane (Signale, Verbindungsmanagement) und User-Plane (Nutzdaten); neues Kernnetz EPC (Evolved Packet Core), neues Funkzugangsnetz LTE, erweiterte Funktionen der Basisstation (eNB)
- Backhaul-Schutz: sichere Anbindung der eNB; bei LTE viele kleine Zellen für hohe Datenraten, eNBs sind zugänglich; die LTE-Spezifikation fordert IPSec und IKEv2 (zertifikatbasierte Authentisierung) für Netzkomponenten (eNB, SGW, MME)

Schutzziele und Schlüssel

wechselseitige Authentisierung von UE und MME mit K_{ASME} $K_{ASME}$ (pro Gastnetz ein eigener K_{ASME} $K_{ASME}$ , abhängig von der Netzwerk-ID SN-ID)
Integrität & Vertraulichkeit der Signalisierungsdaten: im NAS mit K_{NASint}, K_{NASenc} $K_{NASint}, K_{NASenc}$ , auf der Luftschnittstelle (RRC) mit K_{RRCint}, K_{RRCenc} $K_{RRCint}, K_{RRCenc}$
Vertraulichkeit der Nutzdaten auf der Luftschnittstelle: K_{UPenc} $K_{UPenc}$
Schlüsselhierarchie: pre-shared Key K (128 Bit) \to $\to$ CK = f3(RAND, K) $CK = f3(RAND, K)$ , IK = f4(RAND, K) $IK = f4(RAND, K)$ (je 128 Bit, nicht verteilt) \to $\to$ K_{ASME} = KDF(SQN, SN\text{-}ID, CK, IK, RAND) $K_{ASME} = KDF(SQN, SN\text{-}ID, CK, IK, RAND)$ (256 Bit) \to $\to$ K_{NASenc}, K_{NASint} = KDF(K_{ASME}, \ldots) $K_{NASenc}, K_{NASint} = KDF(K_{ASME}, \ldots)$ sowie K_{eNB} = KDF(K_{ASME}, SN\text{-}ID, \ldots) $K_{eNB} = KDF(K_{ASME}, SN\text{-}ID, \ldots)$ \to $\to$ K_{RRCint}, K_{RRCenc}, K_{UPint} $K_{RRCint}, K_{RRCenc}, K_{UPint}$
- Verfahren: Verschlüsselung 128 Bit AES-CTR, Integrität 128 Bit AES-CBC-MAC, KDF HMAC-SHA256
- Vorteile: schnelle Handover möglich; nach Wechsel des eNB neue Keys \to $\to$ Beschränkung der Wirkung kompromittierter Keys
Trust-Domänen: UE/MME (K_{ASME} $K_{ASME}$ ), UE/HSS (IMSI, K), UE/eNB (K_{eNB} $K_{eNB}$ und abgeleitete Keys); pro Service-Netz ein eigener K_{ASME} $K_{ASME}$ in den AVs, Verteilung vom MME an die eNB
LTE-AKA (Authentication & Key Agreement): Attach Request (GUTI/IMSI) \to $\to$ MME fordert AVs beim HSS an (AV = (AUTN, XRES, Keys) $AV = (AUTN, XRES, Keys)$ ) \to $\to$ Auth Request (RAND, AUTN) \to $\to$ UE prüft AUTN \to $\to$ Auth Response (RES) \to $\to$ MME vergleicht RES == XRES, Key-Derivation (K_{ASME} $K_{ASME}$ , K_{NASenc} $K_{NASenc}$ , K_{NASint} $K_{NASint}$ , K_{eNB} $K_{eNB}$ , K_{RRCenc/int} $K_{RRCenc/int}$ )
Fazit LTE: bewährte 2G/3G-Konzepte übernommen bzw. adaptiert; aufgabenspezifische Schlüssel und Schlüsselhierarchie; Schlüsselerneuerung (Abwehr maskierter Basisstationen); Schlüssellängen 128 Bit (bereits für 256 Bit vorbereitet); Integritäts- und Vertraulichkeitsschutz für Signalisierungsdaten (Schutz vor Tracking und Tracing)
- Verbesserungspotential: verbindliche Absicherung der Nutzdaten im Kernnetz (Spec deckt nur den Zugang ab) und der Signalisierungs-/Managementdaten im Kernnetz, Integritätsschutz für Nutzdaten auf der Luftschnittstelle, Authentisierung auch des Gastnetzes, Tracking durch IMSI-Catching verhindern

5G

seit Dezember 2017 verabschiedeter Standard; hohe Investitionen in den Netzausbau erforderlich (5G-Chips, neue Funkschnittstellen und Antennentechnologie, neue Netzkomponenten u.a. Edge, Router)
- politische Entscheidung vom 10.7.24: bis 2026 müssen alle Komponenten chinesischer Hersteller (Huawei, ZTE) aus dem 5G-Core-Netz der deutschen Provider entfernt sein, bis 2029 aus dem Zugangsnetz
- Datenraten bis 20 Gbit/s, Latenz < 1 ms (taktiles Internet); flexible Konfigurierung (z.B. ultraschnelles mobiles Breitband, M2M)
- Software- und Service-Orientierung: Software-defined Network (SDN), Network Function Virtualisation (NFV), Mobile Edge Computing (MEC)

5G-Sicherheitsarchitektur

UDM: Kundendaten und AV-Erstellung: AV = (R, AUTN, XRES^*, K_{AUSF}) $AV = (R, AUTN, XRES^*, K_{AUSF})$ ; AVs werden an das Servicenetz (SName) mit K_{AUSF} $K_{AUSF}$ gebunden, K_{AUSF} = KDF(CK, IK, R, SName) $K_{AUSF} = KDF(CK, IK, R, SName)$ mit CK = KDF(K, \ldots), IK = KDF(K, \ldots) $CK = KDF(K, \ldots), IK = KDF(K, \ldots)$
ARPF: Verwaltung von Kunden-Credentials, pre-shared Key K
SIDF (neu): De-Anonymisierung von Identitäten, keine IMSI mehr
AUSF: Weiterleitung von AVs und Authentisierung von Servicenetzen
AMF: Authentisierung des Kunden (UE); SEAF: Wurzel des Schlüsselmanagements für die Funkzelle (gNB)
SEPP: Netzübergang, Proxy-Endpunkte einer sicheren, authentisierten Kommunikation im Kern-Netz zwischen unterschiedlichen Netzbereichen
Schlüsselhierarchie: ARPF: K_{AUSF} = KDF(CK, IK, R, SName) $K_{AUSF} = KDF(CK, IK, R, SName)$ \to $\to$ AUSF: K_{SEAF} = KDF(K_{AUSF}, SName) $K_{SEAF} = KDF(K_{AUSF}, SName)$ (Wurzel-Schlüssel für das Servicenetz) \to $\to$ SEAF: Session Key K_{AMF} $K_{AMF}$ \to $\to$ AMF: NAS- und gNB-Schlüssel \to $\to$ gNB: Schlüssel für Control- und User-Plane
- Aufteilung von Verantwortlichkeiten: kleine Trust-Domänen (Dienste), Schlüsselerneuerung beim Funkzellenwechsel, keine Weiterleitung nicht verbrauchter AVs an andere Service-Netze
Verschlüsselung (Vertraulichkeit): keine neuen Verfahren, 128 Bit (256 Bit muss unterstützt werden); das Packet Data Convergence Protocol in der gNB ist der Endpunkt der verschlüsselten Kommunikation; E2E-Sicherheit zwischen Teilnehmern muss zusätzlich etabliert werden (on-the-top Security, z.B. mit TLS)
erweiterter Integritätsschutz: Option Integritätsschutz für Nutzdaten zwischen UE und gNB mit K_{UPInt} $K_{UPInt}$

Privacy-Absicherung: SUPI und SUCI

SUPI (SUbscription Permanent Identifier) = (NAI, IMSI): permanente Identität, in der USIM gespeichert; NAI (Network Access Identifier) identifiziert Nutzer
die IMSI wird nicht mehr im Klartext gesendet: Verschleiern der ID durch Verschlüsselung mit einem ECDH-Key; Basis: statisches ECDH-Schlüsselpaar (d_{HN}, e_{HN}) $(d_{HN}, e_{HN})$ des Heimnetzes (in USIM und UDM genutzt, pre-shared, aber kein secret)
pro Authentisierungs-Request erzeugt das UE eine SUCI (SUbscription Concealed Identifier): ephemeres ECC-Schlüsselpaar (d_{UE}, e_{UE}) $(d_{UE}, e_{UE})$ , K_{UE\_HN} = ECDH(d_{UE}, e_{HN}) $K_{UE\_HN} = ECDH(d_{UE}, e_{HN})$ und SUCI = (E_{K_{UE\_HN}}([SUPI], \text{Refresh-Param}), e_{UE}, MMC, MNC) $SUCI = (E_{K_{UE\_HN}}([SUPI], \text{Refresh-Param}), e_{UE}, MMC, MNC)$
- das Heimnetz (SIDF) kann die SUCI de-anonymisieren: SUPI = D(SUCI, DHN) $SUPI = D(SUCI, DHN)$

Home Control (Authentication Confirmation)

Ziel: das Heimnetz vertraut der Nutzer-Authentisierung durch ein Servicenetz nicht mehr
1. ARPF berechnet AVs: AV = (R, AUTN, XRES^*, K_{AUSF}) $AV = (R, AUTN, XRES^*, K_{AUSF})$
2. AUSF ersetzt XRES*: AV^* = (R, AUTN, HXRES^* = SHA256(R, XRES^*)) $AV^* = (R, AUTN, HXRES^* = SHA256(R, XRES^*))$
3. SEAF erstellt einen Authentisierungs-Request an das UE: R, AUTN
4. UE berechnet die Response: RES^* = f(K, R, SName) $RES^* = f(K, R, SName)$ (Nachweis der Kenntnis von K)
5. SEAF berechnet HRES^* = SHA256(R, RES^*) $HRES^* = SHA256(R, RES^*)$ , prüft HRES^* == HXRES^* $HRES^* == HXRES^*$ und berechnet AC = (RES^*, SUCI, SName) $AC = (RES^*, SUCI, SName)$
6. AUSF prüft RES^* == XRES^* $RES^* == XRES^*$ : Netzzugang zulässig, wenn SName korrekt
- nach der Authentisierung: Bindung der Servicenetz-ID durch die AUSF an K_{SEAF} $K_{SEAF}$ , erst danach Schlüsselerzeugung für RAN etc.; Home Control prüft die Zulässigkeit des Netzzugangs des UE
Fazit 5G: Verbesserungen: Home Control: das Heimnetz überprüft die UE-Authentisierung selbst (Misstrauen gegenüber dem Servicenetz), Verschleiern der permanenten Identität durch SUCI, SEPP (sichere, authentisierte Kommunikation im Core), Integrität der Nutzdaten auf der Funkschnittstelle möglich
- aber: die 5G-Security-Spezifikation deckt auch nur die Kommunikation im RAN und im Core ab; erhebliche Vergrößerung der Angriffsvektoren durch 5G-Konzepte

Ausblick: 6G

Verstärkung von Trends: hoher Automatisierungsgrad (KI/ML), Spezialisierung (Extrem Slicing), Realtime/geringes Delay/hohe Datenrate; Trends u.a. Cognitive Netze, Network as a Service, Visible Light Communication (VLC), energiesparsam (10-mal weniger als 5G); Einführung ab 2030 geplant
Fragestellungen aus Sicht der Sicherheit:
- zukunftssichere Kryptografie: PQC-Protokolle für nachhaltige Sicherheit, sichere Interoperabilität und hybrider Betrieb
- offene, dezentrale, heterogene Multiclouds und Edge Computing: intelligente Zero-Trust-6G-Architektur (Trustdomänen fallen weg), sicheres Edge-Computing, TEE, sichere Containerisierung, Confidential Computing, kontinuierliches Monitoring, vertrauenswürdiges Zero-Touch-Management
- Cognitive Netze: KI/ML auf allen Ebenen (datenbasiert, robust, verlässlich)
- hohe Verarbeitungsgeschwindigkeit, sehr niedrige Delays: Physical-Layer-Security, sehr schnelle Krypto, Berechnungen auf verschlüsselten Daten, schnelle Verkehrsflussanalyse und Angriffserkennung
- Ultra Massive M2M (IoE mit unterschiedlichen Sicherheitsfähigkeiten): leichtgewichtiges, energieeffizientes Schlüsselmanagement, automatisiertes Zero-Touch-Sicherheitsmanagement, leichtgewichtige Authentisierungsverfahren (Ablösen der USIM)
- hohe Dynamik: schnelle Wechsel von Edge-Networks (Trust-on-first-use), Schutz von Profildaten spezialisierter/personalisierter Netze
- Energieeffizienz: energiesparende Verschlüsselungen, u.a. Energy-Harvesting-Verfahren

KI und Sicherheit

KI-System: approximiert eine Funktion f_\theta(x)=y $f_\theta(x)=y$ , wobei \theta $\theta$ gelernt ist; können selber komplexe Aufgaben lösen, Muster erkennen, planen, Entscheidungen treffen...
- regelbasierte KI: basierend auf if-then-else-Regeln
- Maschinelles Lernen (ML): das System lernt anhand von Beispielen selbstständig, Regeln und Muster zu erkennen, Vorhersagen zu treffen oder Probleme zu lösen
  - supervised: Labeling von Trainingsdaten (z.B. Regression, SVMs)
  - unsupervised: Lernen aus unstrukturierten Daten (z.B. k-Means-Clustering)
- Deep Learning (DL): basiert auf künstlichen neuronalen Netzen (NN)
- generative KI (GenAI): generiert völlig neue Inhalte (Texte, Bilder, Videos, Musik, Code...)
  - Transformer: Vektordarstellungen, um die Beziehungen zwischen Wörtern oder anderen Datenpunkten in großen Datensätzen zu analysieren und Muster zu erkennen

Sicherheit

Angriffe auf KI-Systeme
- Target Poisoning: spezielle Samples werden explizit falsch klassifiziert
- Prompt Injection: gezielte Manipulation von Eingabedaten
- Sensitive Information Disclosure: aus Antworten lassen sich Rückschlüsse auf die sensible Trainingsdaten ziehen
KI als Angriffswerkzeug: Phishing, Social Engineering, Malware, Deepfakes, Botnets, Coding-Agenten...
KI als Defensivwerkzeug: Bedrohungserkennung und -vorhersage, autonome Reaktionssysteme, Identitätssicherheit, E-Mail-Sicherheit...
Robustheit von KI-Systemen: Metriken zur Bestimmung der Robustheit eines Verfahrens (automatisierte Erzeugung von Störungen wie Rauschen, Drehungen; korrekte Klassifikation trotz Störung); Robustheit erhöhen u.a. durch robustes Trainieren, Alarmnetze, Preprocessing mit Detektoren
OWASP Top Ten für GenAI-/LLM-Anwendungen:
- LLM01 Prompt Injection (Umgehung von Sicherheitsregeln, Datenabfluss), LLM02 Sensitive Information Disclosure, LLM03 Supply Chain (unsichere Modelle, Plugins, Datenquellen), LLM04 Data & Model Poisoning, LLM05 Improper Output Handling (Code-Injection, XSS), LLM06 Excessive Agency (zu weitreichende Autonomie/Berechtigungen), LLM07 System Prompt Leakage, LLM08 Vector & Embedding Weaknesses (Angriffe auf Vektordatenbanken/Retrieval), LLM09 Misinformation (Halluzinationen), LLM10 Unbounded Consumption (Kostenexplosion, DoS)
KI als Angriffskoordinator: ein LLM entwickelt eine reale Angriffskampagne
- automatisierte Reconnaissance/Lagebilderstellung, Personalisierung (personalisierte Phishing-Nachrichten), Adaption an Reaktionen, Orchestrierung mehrerer Angriffsschritte über Prompts, Kontext und externe Tools \to $\to$ der Angriff wird wirksamer, schneller, skalierbarer und adaptiver
- Erkenntnis: der Hauptangriffsvektor ist nicht das Modell, sondern die Integration von KI in Datensysteme und Tools; der Kontext (Prompts, externe Quellen) wird Teil der Steuerlogik
Defense-in-Depth für KI-Systeme:
1. Vorbereitung/Pre-Processing: Input-Sanitization, Prompt-Shielding, Absicherung von RAG-Quellen (Allowlists, Content-Scanning)
2. Modell & Lieferkette: Robustheitstests, Red-Teaming, Poisoning-Detection, Signieren von Modellen und Datensätzen, Dokumentation von Training, Fine-Tuning und Datenquellen
3. Ausgabe-Nachbearbeitung/Post-Processing: Output-Moderation, Policy-Checks, Human-in-the-Loop, API-Hardening, Authentifizierung, Context-Isolation, Rate-Limiting, Monitoring, Logging, Erkennung und Bewertung von Halluzinationen

Agentic AI

Foundation Model: Sprachmodell ist der Kern für Reasoning und Entscheidungsfindung
Memory: speichert Informationen über Aufgaben und Interaktionen
Planning: komplexe Aufgaben werden in einzelne Schritte zerlegt
Tool Use: selbständiger Zugriff auf APIs, Datenbanken, Dienste
Control Loop: Ergebnisse bewerten und weitere Aktionen planen
Probleme: Agenten beziehen Wissen häufig aus externen Quellen und können (noch) nicht zwischen vertrauenswürdiger und manipulierter Information unterscheiden; Agentenverhalten führt zu erhöhten Risiken für IT-Systeme; Risiken durch Cross-Layer Threats; Model Context Protocol (MCP) Angriffe
Neue Sicherheitsmaßnahmen benötigt für Foundation Models (Input- & Output-Filter, Adversarial Training), RAG-Systeme (Provenance Tracking, Datenvalidierung), klassische Absicherungskonzepte (Secure Coding, sichere Agentenkommunikation, Netzwerksegmentierung, ID & Access Management)
Eigenschaften und Risiken agentischer Systeme:
- Nichtdeterminismus (probabilistisches Verhalten): identische Inputs führen nicht zwingend zu identischen Outputs \to $\to$ erschwert starre, signaturbasierte Regeln und Regressionstests
- Autonomie & Agency: Agenten treffen eigenständige Entscheidungen und rufen Tools/APIs autonom auf (OWASP LLM06 Excessive Agency); manipulierte Agenten können eigenständig Daten löschen/verändern
- Kaskadierende Kommunikation (Multi-Agenten-Effekt): Agenten interagieren ungeprüft und reichen Daten weiter \to $\to$ „Stille-Post“-Effekt, Infection Cascades
- Agent Identity (Rechte- und Rollen-Verschwommenheit): unklare Trennung zwischen Nutzeridentität und Systemrechten \to $\to$ Gefahr der Privilegieneskalation; Agenten benötigen eigene, isolierte Identitäten nach dem Principle of Least Privilege
Model Context Protocol (MCP): standardisiert den Zugriff von KI-Agenten auf externe Ressourcen und Werkzeuge (Dateisysteme, Datenbanken, Unternehmensanwendungen, APIs, Wissensquellen, weitere Agenten); zentrale Integrationsschicht für Agentensysteme
- Probleme u.a.: kompromittierte oder manipulierte Werkzeuge (MCP Server), fehlende Validierung von Antworten (MCP Client), manipulierte Wissensquellen (Ressourcen), ungewollte oder privilegierte Aktionen (Tools), Prompt Injection über externe Inhalte (Prompts)
Grenzen klassischer Schutzkonzepte: Frameworks wie STRIDE oder DREAD basieren auf Annahmen über die Software (deterministisches Verhalten, stabile Identitäten, klar definierte Kommunikationswege, vorhersehbare Abläufe), die Agentensysteme nicht erfüllen; neue Ansätze werden benötigt
Konkrete Sicherheitsmaßnahmen: KI-spezifisches Least Privilege (keine pauschalen API-Tokens; Sandboxing von Tool-Aufrufen, zeitlich begrenzte Tokens, Human-in-the-Loop-Freigaben für kritische Aktionen), Assume Breach & Isolation (strikte Trennung von System-Prompts und User-/Data-Prompts, Dual-LLM-Architekturen), Security by Design in der Orchestrierung (Guardrails, z.B. NeMo Guardrails, Llama Guard), Continuous Monitoring & semantisches Auditing (Überwachung semantischer Absichten, Anomalieerkennung auf Vektorebene)
Vertrauensprinzipien: Zulassung & Authentifizierung (zentrale Agentenregister, eindeutige Zertifikate z.B. mTLS, Blockieren unverifizierter „Shadow Agents“), dynamische Verhaltensbewertung (Reputation-Systeme, Telemetrie-Scoring, Baseline-Vergleiche), Transportsicherheit & Isolation (E2E-Verschlüsselung, Sandbox-Isolation z.B. Docker, gVisor, GyroidOS), granulares Vertrauensmanagement (Orchestrator-Agenten als Gatekeeper bzw. semantische Firewalls)

Summary by Flavius Schmidt, ge83pux, 2026.
https://flaviusschmidt.com