Seminar Intensivseminar Attestation, Authentisierung und Laufzeitvertrauen

Seminarprofil

Die Veranstaltung behandelt die vollständige Vertrauenskette von hardwaregestützten Schlüsseln und App-Integrität über phishingresistente Authentisierung bis zur serverseitigen Geschäftsentscheidung.

Das Intensivformat fasst die Einzelseminare zu Android Attestation, Apple App Attest, Attestation-Architekturen und Passkeys zusammen und ergänzt sie um Laufzeitschutz, Backend-Bindung und einen realistischen Bypass-Test.

Inhaltsverzeichnis

• Seminarprofil
• Zielgruppe
• Voraussetzungen
• Lernziele
• Fachliche Schwerpunkte
• Attestation-Grundlagen: Evidence, Verifier und Policy
• Attestation hardwaregeschützter Schlüssel
• Android Key Attestation
• Google Play Integrity für Wallet-Transaktionen
• Apple App Attest
• Apple DeviceCheck und Gerätehistorie
• Freshness, Nonce, Request Binding und Replay-Schutz
• Passkeys und WebAuthn-Grundlagen
• Synchronisierte und gerätegebundene Passkeys
• Authenticator-Attestation und Gerätevertrauen
• RASP, Hooking-Erkennung und Laufzeitreaktionen
• Risikobasierte Attestation-Entscheidungen
• Attestation-Bypass und Policy-Angriffe
• Attestation-Fallstudie: Policy vom Gerät bis zur Geschäftsentscheidung
• Praxisaufgaben
• Einordnung in das Seminarprogramm

Zielgruppe

• Mobile- und Backend-Security-Engineers
• Android- und iOS-Entwickler
• Security-Architekten
• Fraud- und Identity-Teams

Voraussetzungen

Solide Kenntnisse in Mobile-Entwicklung, Web- und API-Sicherheit sowie Public-Key-Kryptografie. Programmiererfahrung ist für die Laborübungen erforderlich.

Lernziele

• Android- und Apple-Attestation-Endpunkte produktionsreif integrieren.
• Passkeys und lokale Nutzerverifikation in das Assurance-Modell einordnen.
• Attestation-Evidence mit Request Binding, Risk Policy und Backend-Autorisierung verbinden.
• Laufzeitmanipulation, Replay und fail-open Fallbacks systematisch testen.
• Eine vollständige Attestation- und Authentisierungsarchitektur dokumentieren.

Fachliche Schwerpunkte

Attestation-Grundlagen: Evidence, Verifier und Policy

Attestation ist kein einzelner Wahrheitswert, sondern eine Kette aus erzeugtem Nachweis, technischer Verifikation und geschäftlicher Entscheidung. Diese Trennung verhindert Fehlinterpretationen.

1. Zu attestierende Eigenschaften und ihren Sicherheitswert definieren.
2. Evidence-Erzeuger, Verifier, Trust Anchors und Policy Engine voneinander trennen.
3. Authentizität, Freshness, Kontextbindung und Replay-Schutz prüfen.
4. Technische Ergebnisse in gestufte Geschäftsentscheidungen übersetzen.

Attestation hardwaregeschützter Schlüssel

Hardware-Attestation liefert Nachweise über Schlüsselursprung, Sicherheitsniveau und Gerätezustand. Sie ist nur belastbar, wenn Zertifikatsketten, Erweiterungen und Richtlinien serverseitig korrekt geprüft werden.

1. Attestation-Evidence, Zertifikatskette und erwartete Root-of-Trust festlegen.
2. Schlüsseleigenschaften, Sicherheitsniveau und Geräteinformationen validieren.
3. Freshness und Bindung an Registrierung oder Transaktion sicherstellen.
4. Unsichere, veraltete oder nicht prüfbare Nachweise risikobasiert behandeln.

Android Key Attestation

Android Key Attestation weist Eigenschaften hardwaregestützter Schlüssel über eine Zertifikatskette nach. Behandelt werden Sicherheitslevel, Boot-Zustand, Patch-Informationen und App-Bindung.

1. Schlüsselerzeugung mit geeigneten Parametern und Attestation-Challenge konfigurieren.
2. Zertifikatskette bis zum erwarteten Vertrauensanker verifizieren.
3. Attestation-Erweiterungen für App-Identität, Sicherheitslevel, Boot-Zustand und Schlüsselzweck auswerten.
4. Root-Wechsel, Gerätevielfalt, fehlerhafte Implementierungen und Rotation betrieblich berücksichtigen.

Google Play Integrity für Wallet-Transaktionen

Play Integrity liefert signierte Integritätsurteile zu App, Installation, Gerät und Nutzungskontext. Der sichere Einsatz erfordert serverseitige Verifikation und eine auf Geschäftsrisiken abgestimmte Reaktion.

1. Standard- oder Classic-Anfragen entsprechend Latenz und Schutzbedarf auswählen.
2. Anfrage an Sitzung oder Transaktion binden und serverseitig verifizieren.
3. App-, Geräte-, Lizenz- und optionale Risikosignale fachlich interpretieren.
4. Caching, Kontingente, Wiederholungen, Ausfälle und stufenweise Maßnahmen planen.

Apple App Attest

App Attest ermöglicht die serverseitige Prüfung, ob Anfragen von einer legitimen Instanz der eigenen App stammen. Behandelt werden Schlüsselregistrierung, Attestation-Objekt und Assertions.

1. App-Attest-Schlüssel erzeugen und die Unterstützung des Geräts prüfen.
2. Attestation-Objekt mit einmaliger Server-Challenge erstellen und validieren.
3. Schlüsselkennung, App-Identität, Zähler und kryptografische Bindungen prüfen.
4. Für Folgeanfragen Assertions erzeugen und gegen Replay sowie Kontextwechsel absichern.

Apple DeviceCheck und Gerätehistorie

DeviceCheck stellt eine knappe, gerätebezogene Zustandsinformation bereit und ergänzt App Attest bei Fraud- und Missbrauchsentscheidungen. Entscheidend sind Zweckbindung und sorgfältige Interpretation.

1. Geeignete Missbrauchsszenarien für die begrenzten Zustandsbits definieren.
2. Gerätetoken sicher an das Backend übertragen und serverseitig validieren.
3. Statusänderungen, Aufbewahrung und Zugriff streng kontrollieren.
4. DeviceCheck nur als ergänzendes Signal in eine mehrstufige Policy einbinden.

Freshness, Nonce, Request Binding und Replay-Schutz

Ein kryptografisch korrektes Attestation-Objekt kann wertlos sein, wenn es nicht an die aktuelle Sitzung oder Transaktion gebunden ist. Der Baustein entwickelt robuste Bindungsmuster.

1. Einmalige Challenges oder deterministische Request-Hashes erzeugen.
2. Nutzer-, Sitzungs-, Geräte- und Transaktionskontext eindeutig einbinden.
3. Zeitfenster, Zähler und serverseitige Replay-Speicher definieren.
4. Wiederholte, verzögerte oder kontextfremde Nachweise erkennen und behandeln.

Passkeys und WebAuthn-Grundlagen

Passkeys ersetzen geteilte Geheimnisse durch asymmetrische Schlüssel und phishingresistente Protokolle. Der Baustein ordnet Relying Party, Authenticator, Client und Nutzerfreigabe ein.

1. Registrierungs- und Authentisierungszeremonie als Nachrichtenfluss modellieren.
2. Challenge, Origin, Relying-Party-ID und Signaturzähler korrekt prüfen.
3. User Presence und User Verification nach Schutzbedarf unterscheiden.
4. Serverseitige Credential-Verwaltung und Mehrgeräteunterstützung planen.

Synchronisierte und gerätegebundene Passkeys

Synchronisierte Passkeys verbessern Komfort und Recovery, während gerätegebundene Passkeys höhere Kontrolle ermöglichen. Die Auswahl richtet sich nach Assurance und Betriebsmodell.

1. Sicherheits- und Recovery-Anforderungen des Wallet-Zugriffs bestimmen.
2. Synchronisierte und gerätegebundene Credentials anhand von Exportierbarkeit und Kontrolle vergleichen.
3. Mehrgeräte-, Ersatzgeräte- und Offline-Szenarien bewerten.
4. Eine kombinierte Strategie mit klaren Step-up-Regeln festlegen.

Authenticator-Attestation und Gerätevertrauen

Authenticator-Attestation kann Aussagen über den eingesetzten Authenticator liefern, erzeugt aber Datenschutz- und Betriebsfolgen. Der Baustein entwickelt eine risikobasierte Nutzung.

1. Benötigte Authenticator-Eigenschaften und Assurance-Ziele festlegen.
2. Attestation-Formate und Vertrauensmetadaten serverseitig prüfen.
3. Datenschutz, Anonymisierung und Akzeptanzregeln berücksichtigen.
4. Unbekannte oder nicht attestierte Authenticatoren gestuft behandeln.

RASP, Hooking-Erkennung und Laufzeitreaktionen

Runtime Application Self-Protection kann Manipulationen erkennen, darf aber nicht als alleinige Vertrauensquelle dienen. Entscheidend sind robuste Signale und abgestufte Reaktionen.

1. Relevante Laufzeitindikatoren für Debugger, Hooking, Root oder Jailbreak auswählen.
2. Signale diversifizieren und gegen einfache Patch- oder Bypass-Techniken härten.
3. Reaktionen von Telemetrie über Step-up bis Funktionssperre staffeln.
4. Umgehungsversuche, False Positives und Plattformänderungen kontinuierlich testen.

Risikobasierte Attestation-Entscheidungen

Attestation-Signale sind probabilistische und kontextabhängige Eingaben. Eine gute Policy kombiniert mehrere Signale, berücksichtigt Ausfälle und vermeidet unnötige Nutzerausschlüsse.

1. Verdicts und technische Eigenschaften nach Vertrauensstärke klassifizieren.
2. Geschäftsaktionen nach Risiko und erforderlichem Assurance-Niveau staffeln.
3. Entscheidungen wie Zulassen, Step-up, Einschränken, Beobachten oder Blockieren definieren.
4. False Positives, Plattformausfälle und Ausnahmeprozesse kontrolliert behandeln.

Attestation-Bypass und Policy-Angriffe

Getestet werden Replay, Relay, Hooking, manipulierte Verdicts, schwache Fallbacks und Inkonsistenzen zwischen App, Verifier und Risk Engine.

1. Attestation-Nachrichtenfluss und alle Vertrauensannahmen erfassen.
2. Freshness, Binding und serverseitige Verifikation gezielt angreifen.
3. Fehler-, Timeout- und Nichtunterstützungsfälle auf fail-open Verhalten prüfen.
4. Policy-Kombinationen und Schwellenwerte gegen Umgehung testen.

Attestation-Fallstudie: Policy vom Gerät bis zur Geschäftsentscheidung

Eine vollständige Attestation-Pipeline für Android und Apple wird mit Passkeys, App-Härtung und Backend-Risikosteuerung verbunden.

1. Geschäftsaktionen und benötigte Assurance-Stufen definieren.
2. Evidence-Flows, Challenges, serverseitige Verifikation und Trust Stores entwerfen.
3. Policy-Matrix für zulassen, Step-up, einschränken und blockieren entwickeln.
4. Replay, Ausfall, nicht unterstützte Geräte und Bypass-Versuche testen.

Praxisaufgaben

• Gemeinsames Labor für Android- und Apple-Evidence mit serverseitiger Validierung.
• Entwurf eines passkey-basierten Wallet-Zugriffs mit mehreren Assurance-Stufen.
• Bypass-Tests gegen Replay, Hooking, manipulierte Verdicts und schwache Fallbacks.
• Aufbau einer Policy Engine mit abgestuften Reaktionen und Audit-Daten.
• Abschlusspräsentation der End-to-End-Architektur.

Einordnung in das Seminarprogramm

Das Intensivformat ist als komprimierter, zusammenhängender Qualifizierungspfad konzipiert. Es bündelt die zugehörigen Einzelseminare, ersetzt redundante Wiederholungen durch eine durchgängige Fallstudie und eignet sich für Teams, die innerhalb eines geschlossenen Programms Architektur-, Implementierungs- und Prüfkompetenz aufbauen müssen.