Seminar Intensivseminar Mobile Wallet Security und Architektur

Seminarprofil

Die Veranstaltung liefert den umfassenden technischen Architekturpfad für sichere Mobile Wallets. Sie beginnt bei Schutzobjekten und Trust Boundaries und endet bei Build-Pipeline, Betrieb, Test und dokumentiertem Restrisiko.

Das Intensivformat fasst die Einzelseminare zu Grundlagen, Management, Bedrohungsmodellierung, Hardware, App-Härtung, Backend und Cloud, Secure SDLC sowie Red Teaming zusammen.

Inhaltsverzeichnis

• Seminarprofil
• Zielgruppe
• Voraussetzungen
• Lernziele
• Fachliche Schwerpunkte
• Wallet-Ökosystem, Rollen und Vertrauensbeziehungen
• Schutzobjekte, Sicherheitsziele und Assurance
• Trust Boundaries und Sicherheitsarchitektur
• Angreifermodelle und Missbrauchsszenarien
• STRIDE, LINDDUN und anwendungsbezogene Bedrohungsanalyse
• Sichere Architektur- und Bereitstellungsmuster
• Hardwarebasierte Roots of Trust
• Schlüssellebenszyklus und Gerätebindung
• Mobile Angriffsfläche und Schutzschichten
• RASP, Hooking-Erkennung und Laufzeitreaktionen
• Wallet-Backend und Vertrauensdienste
• API-Authentisierung und Autorisierung
• Cloud-Security, Mandantentrennung und Plattformhärtung
• Security Requirements und Definition of Done
• SBOM und Software-Supply-Chain-Security
• CI/CD-Sicherheit und Release Gates
• Statische Analyse und Reverse Engineering
• Dynamische Analyse und Laufzeitbeobachtung
• Risikobewertung und Maßnahmenplanung
• Architektur-Fallstudie: vollständiges Wallet-Sicherheitskonzept
• Praxisaufgaben
• Einordnung in das Seminarprogramm

Zielgruppe

• Security- und Lösungsarchitekten
• Mobile- und Backend-Entwickler
• Product-Security-Teams
• Technische Leiter und Penetrationstester

Voraussetzungen

Gute Kenntnisse in Softwarearchitektur, Mobile- oder Backend-Entwicklung und IT-Sicherheit. Erfahrung mit Threat Modeling ist hilfreich.

Lernziele

• Wallet-Schutzobjekte, Trust Boundaries und Angriffsketten systematisch modellieren.
• Hardware-, Schlüssel-, App-, Backend- und Cloud-Kontrollen konsistent entwerfen.
• Secure SDLC, Supply Chain und Release-Vertrauen in die Architektur integrieren.
• Penetrationstests und Security Gates aus dem Bedrohungsmodell ableiten.
• Restrisiken und Managemententscheidungen nachvollziehbar dokumentieren.

Fachliche Schwerpunkte

Wallet-Ökosystem, Rollen und Vertrauensbeziehungen

Der Einstieg ordnet Mobile Wallets als Zusammenspiel von App, sicherer Geräteplattform, Backend, Ausstellern, Prüfern und Vertrauensdiensten ein. Dadurch werden Zuständigkeiten und Sicherheitsgrenzen eindeutig.

1. Wallet-Typen, Geschäftsprozesse und Schutzbedarf voneinander abgrenzen.
2. Rollen wie Wallet-Anbieter, Herausgeber, Inhaber, Prüfer, Zahlungsdienst und Vertrauensanker zuordnen.
3. Daten-, Schlüssel- und Entscheidungsflüsse vom Onboarding bis zur Sperrung modellieren.
4. Verantwortlichkeiten, Haftungsübergänge und technische Vertrauensannahmen dokumentieren.

Schutzobjekte, Sicherheitsziele und Assurance

Sicherheitsmaßnahmen werden nicht aus einer Produktliste abgeleitet, sondern aus den zu schützenden Identitäten, Zahlungsdaten, Schlüsseln, Nachweisen und Entscheidungen. Der Baustein übersetzt Geschäftsrisiken in prüfbare Sicherheitsziele.

1. Schutzobjekte und deren Lebenszyklus vollständig erfassen.
2. Vertraulichkeit, Integrität, Authentizität, Verfügbarkeit, Unlinkability und Nachweisbarkeit priorisieren.
3. Missbrauchsfolgen und erforderliche Vertrauensniveaus bewerten.
4. Messbare Sicherheitsanforderungen und Abnahmekriterien formulieren.

Trust Boundaries und Sicherheitsarchitektur

Mobile Wallets verteilen Vertrauen über Betriebssystem, Hardware, App, Netzwerk, Cloud und externe Ökosysteme. Die Architekturarbeit macht diese Grenzen sichtbar und verhindert implizite, unprüfbare Annahmen.

1. Komponenten, Kommunikationsbeziehungen und Administratorpfade erfassen.
2. Trust Boundaries zwischen Gerät, App, Backend und Drittparteien markieren.
3. Für jede Grenze Authentisierung, Autorisierung, Integritätsschutz und Protokollierung festlegen.
4. Architekturrisiken priorisieren und kompensierende Kontrollen bestimmen.

Angreifermodelle und Missbrauchsszenarien

Die Bedrohungsanalyse berücksichtigt nicht nur klassische Malware, sondern auch manipulierte Geräte, betrügerische Nutzer, kompromittierte Lieferketten, Insider, organisierte Fraud-Gruppen und fehlerhafte Vertrauensdienste.

1. Angreifer nach Zugriff, Fähigkeiten, Motivation und Ressourcen klassifizieren.
2. Missbrauchsszenarien für Onboarding, Nutzung, Recovery und Zertifikatswechsel beschreiben.
3. Angriffsvoraussetzungen und realistische Angriffsketten herausarbeiten.
4. Detektions-, Präventions- und Wiederanlaufmaßnahmen je Szenario zuordnen.

STRIDE, LINDDUN und anwendungsbezogene Bedrohungsanalyse

Technische Sicherheitsrisiken und Datenschutzrisiken werden in einer gemeinsamen Methodik bearbeitet. So entstehen konsistente Anforderungen für Manipulationsschutz, Identitätsschutz und Datenminimierung.

1. Datenflussdiagramme mit Prozessen, Speichern, Akteuren und Schnittstellen erstellen.
2. STRIDE-Bedrohungen systematisch an jedem Element prüfen.
3. LINDDUN-Risiken für Verknüpfbarkeit, Erkennbarkeit und Offenlegung ergänzen.
4. Befunde in priorisierte Sicherheitsanforderungen und Testfälle überführen.

Sichere Architektur- und Bereitstellungsmuster

Der Baustein vergleicht gerätegebundene, cloudgestützte und hybride Wallet-Architekturen. Bewertet werden Sicherheitsgewinn, Portabilität, Recovery, Betriebsaufwand und Zertifizierbarkeit.

1. Sicherheits- und Betriebsanforderungen als Entscheidungskriterien gewichten.
2. Gerätegebundene, synchronisierte und servergestützte Modelle vergleichen.
3. Schlüsselhaltung, Attestation, Offline-Fähigkeit und Recovery pro Muster bewerten.
4. Eine begründete Zielarchitektur mit Ausweich- und Migrationspfaden festlegen.

Hardwarebasierte Roots of Trust

Secure Element, TEE, Secure Enclave, StrongBox und HSM liefern unterschiedliche Sicherheitsgarantien. Der Baustein trennt Marketingbegriffe von überprüfbaren Eigenschaften.

1. Sicherheitsdomänen und Isolationseigenschaften der verfügbaren Hardwareklassen vergleichen.
2. Schlüsselgenerierung, nicht exportierbare Speicherung und kryptografische Operationen zuordnen.
3. Angriffsmodelle für kompromittiertes Betriebssystem, physischen Zugriff und Seitenkanäle bewerten.
4. Geeignete Hardwareanker für Assurance, Recovery und Zertifizierung auswählen.

Schlüssellebenszyklus und Gerätebindung

Die Sicherheit einer Wallet hängt nicht allein von der Schlüsselerzeugung ab. Entscheidend sind Registrierung, Bindung, Rotation, Verlustbehandlung, Sperrung und kontrollierte Migration.

1. Schlüsseltypen, Besitzer, Verwendungszweck und Lebensdauer inventarisieren.
2. Registrierung und Bindung an App, Gerät, Konto und Credential absichern.
3. Rotation, Algorithmuswechsel und Schlüsselersatz ohne Vertrauensverlust planen.
4. Verlust, Kompromittierung, Gerätewechsel und sichere Löschung operationalisieren.

Mobile Angriffsfläche und Schutzschichten

Wallet-Apps sind Reverse Engineering, Hooking, Repackaging, Debugging, Overlay-Angriffen und unsicherer lokaler Speicherung ausgesetzt. Schutzmaßnahmen werden als gestaffelte Kontrollen geplant.

1. Angriffsflächen in Binärdatei, Laufzeit, IPC, WebViews, Speicher und Netzwerk erfassen.
2. Schutzbedarf je Codepfad und Datenklasse priorisieren.
3. Präventive, detektive und reaktive Kontrollen kombinieren.
4. Wirksamkeit und Umgehbarkeit durch realistische Tests bewerten.

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.

Wallet-Backend und Vertrauensdienste

Das Backend verwaltet Gerätebindungen, Schlüsselmetadaten, Credentials, Policies, Recovery und Statusinformationen. Der Baustein entwickelt klare Servicegrenzen und minimiert hochprivilegierte Komponenten.

1. Domänen für Identität, Gerätebindung, Credential, Policy, Recovery und Audit trennen.
2. Daten- und Schlüsselzugriffe nach Least Privilege gestalten.
3. Konsistenz, Idempotenz und sichere Zustandsübergänge definieren.
4. Ausfall-, Wiederanlauf- und Mandantentrennungsszenarien testen.

API-Authentisierung und Autorisierung

Wallet-APIs benötigen eine mehrschichtige Bindung zwischen App, Gerät, Nutzer, Sitzung und konkreter Aktion. Bearer Tokens allein reichen für besonders kritische Vorgänge häufig nicht aus.

1. Client-, Nutzer- und Geräteidentität getrennt modellieren.
2. OAuth-, OpenID- und mTLS- oder Proof-of-Possession-Muster passend auswählen.
3. Scopes, Claims und objektbezogene Autorisierung serverseitig erzwingen.
4. Token-Diebstahl, Replay, Session Fixation und Cross-Tenant-Zugriff testen.

Cloud-Security, Mandantentrennung und Plattformhärtung

Cloud-Dienste werden nach Identität, Netzwerk, Daten, Workloads und Administration abgesichert. Besondere Aufmerksamkeit gilt der Trennung hochprivilegierter Wallet-Dienste.

1. Cloud-Konten, Projekte und Netzsegmente nach Vertrauensdomänen trennen.
2. Workload-Identitäten, Minimalrechte und administrative Break-Glass-Zugänge definieren.
3. Verschlüsselung, Schlüsselzugriff und Datenresidenz kontrollieren.
4. Fehlkonfigurationen, privilegierte Pfade und Wiederherstellung automatisiert prüfen.

Security Requirements und Definition of Done

Sicherheitsziele werden als umsetzbare und prüfbare Anforderungen in Backlog, Architektur und Abnahme verankert.

1. Geschäftsrisiken und Threat-Model-Befunde in konkrete Anforderungen übersetzen.
2. Akzeptanzkriterien, Missbrauchsfälle und Negativtests ergänzen.
3. Anforderungen Komponenten, Verantwortlichen und Release Gates zuordnen.
4. Erfüllung und Abweichungen revisionsfähig nachweisen.

SBOM und Software-Supply-Chain-Security

Wallets enthalten SDKs, Bibliotheken, Build-Tools und Plattformdienste. Eine SBOM schafft Transparenz, muss aber mit Herkunfts-, Signatur- und Schwachstellenprozessen verbunden werden.

1. Direkte und transitive Abhängigkeiten sowie eingebettete SDKs erfassen.
2. Herkunft, Integrität, Lizenz und Wartungsstatus bewerten.
3. SBOM automatisiert erzeugen und mit Schwachstelleninformationen abgleichen.
4. Austausch, Ausnahme und End-of-Life kritischer Komponenten steuern.

CI/CD-Sicherheit und Release Gates

Build- und Deployment-Pipelines sind hochprivilegierte Produktionssysteme. Identitäten, Artefakte und Freigaben werden gegen Manipulation abgesichert.

1. Pipeline-Identitäten, Secrets und privilegierte Runner inventarisieren.
2. Quellcode-, Build- und Artefaktintegrität kryptografisch absichern.
3. Security-Tests und Freigabekriterien risikobasiert automatisieren.
4. Produktionssignierung, Rollback und Notfallrelease kontrollieren.

Statische Analyse und Reverse Engineering

Binärdatei, Ressourcen, Konfiguration und Abhängigkeiten werden auf Geheimnisse, unsichere Pfade und manipulierbare Kontrollen untersucht.

1. Paketstruktur, Signaturen, Berechtigungen und eingebettete Komponenten erfassen.
2. Kritische Datenflüsse, Kryptografie und Backend-Endpunkte rekonstruieren.
3. Obfuskation und Anti-Tampering auf Umgehbarkeit bewerten.
4. Hypothesen für dynamische Tests und Angriffsketten ableiten.

Dynamische Analyse und Laufzeitbeobachtung

Die App wird bei realen Wallet-Abläufen beobachtet. Speicher, Netzwerk, IPC, lokale Dateien und Fehlersituationen liefern Hinweise auf verwertbare Schwächen.

1. Onboarding, Nutzung, Recovery und Sperrung als Testpfade instrumentieren.
2. Netzwerk, Dateisystem, Speicher und Systemaufrufe beobachten.
3. Manipulierte Eingaben, Fehlerzustände und unterbrochene Abläufe erzeugen.
4. Befunde reproduzieren und ihre geschäftliche Wirkung nachweisen.

Risikobewertung und Maßnahmenplanung

Befunde aus Threat Modeling und Tests werden in eine belastbare Maßnahmenplanung überführt. Der Fokus liegt auf nachvollziehbaren Entscheidungen statt auf pauschalem Blockieren.

1. Eintrittswahrscheinlichkeit, Ausnutzbarkeit und Schadensausmaß bewerten.
2. Risiken nach Geschäftsprozess und Assurance-Anforderung priorisieren.
3. Vermeidung, Reduktion, Übertragung oder Akzeptanz begründet auswählen.
4. Kontrollwirksamkeit, Restrisiko, Verantwortliche und Fristen dokumentieren.

Architektur-Fallstudie: vollständiges Wallet-Sicherheitskonzept

Die Inhalte werden in einer durchgängigen Fallstudie zusammengeführt. Ausgangspunkt ist ein neues Wallet-Produkt mit Gerätebindung, Credentials, Cloud-Backend und regulatorischen Anforderungen.

1. Schutzobjekte, Rollen, Trust Boundaries und Angreifermodelle gemeinsam festlegen.
2. Hardwareanker, Schlüsselarchitektur, App-Härtung und Backend-Kontrollen auswählen.
3. Recovery, Monitoring, Secure SDLC und Teststrategie integrieren.
4. Architekturentscheidungen, Restrisiken und Abnahmekriterien präsentieren.

Praxisaufgaben

• Durchgängiges Threat Model mit Datenflussdiagramm, STRIDE und Attack Trees.
• Architekturentscheidung für Hardwareanker, Schlüsselhaltung und Recovery-Grenzen.
• Härtungs- und Backend-Kontrollplan mit messbaren Security Gates.
• Mini-Red-Team gegen App-, API- und Zustandslogik.
• Abschlussreview der Zielarchitektur und Restrisiken.

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.