Systemarchitektur

Achtung

Diese Seite beschreibt sowohl den verifizierten Stand als auch die Zielarchitektur. Abschnitte sind jeweils klar als Verifiziert oder Zielarchitektur gekennzeichnet. Cloud Enrichment, Modell-Updates, Multi-Plattform-Agents, KI-Analyse und gehostete Produktumgebungen sind ausdruecklich Zielarchitektur und haben keinen Runtime-Nachweis im aktuellen Workspace.

Verifizierter Stand

Der aktuelle Workspace implementiert folgende Architektur, nachgewiesen durch Code, Tests und Tablet-Verifikation:

Verifizierte Komponenten:

Komponente	Status	Nachweis
Android-App mit DAU-Home-Screen	Verifiziert	Tablet-Lauf, UI-Tests
Geraeteregistrierung (RSA-Keypair, Signaturpruefung)	Verifiziert	Backend-Tests, Tablet-Lauf
Event-Einreichung mit X-Device-Signature	Verifiziert	Backend-Tests, Tablet-Lauf
App-Install-Erkennung (app.install.observed)	Prototyp	Stub-Collector, regelbasierte Bewertung
Alerts aus warn/block-Events	Verifiziert	Backend-Tests
Incidents aus High-Severity-Events	Verifiziert	Backend-Tests
Jobs/Traces/Artifacts (incident_triage_v1)	Verifiziert	Backend-Tests
Token-Lifecycle (mint, revoke, audit)	Verifiziert	Backend-Tests
Webhook-Dispatch mit HMAC-SHA256, DLQ, Replay	Verifiziert	Backend-Tests
Telemetrie-Korrelation (7 Gold-Flows)	Verifiziert	Tablet-Lauf, cmd/telemetrycompare
Sicherheitsheader, Rate-Limiting, Tenant-Scoping	Verifiziert	Backend-Tests

Nicht verifiziert im aktuellen Stand:

• Kein Cloud-Deployment, kein gehostetes Backend
• Keine KI-/ML-Modelle auf dem Geraet oder in der Cloud
• Keine Erkennung von Betrugsanrufen, Social Engineering, Deepfakes oder Fernsteuerung
• Keine Multi-Plattform-Unterstuetzung (nur Android)
• Keine Push-Benachrichtigungen, keine Hintergrund-Ueberwachung
• Keine Familienprofile oder geraeteuebergreifende Synchronisation

---

Architekturuebersicht (Zielarchitektur)

Achtung

Alles ab hier beschreibt die Zielarchitektur. Keine der folgenden Komponenten ist im aktuellen Workspace als Runtime implementiert oder verifiziert.

Die Zielarchitektur folgt dem Prinzip “Local First, Cloud Smart”: Schutzmassnahmen sollen direkt auf dem Geraet greifen, bevor sensible Daten das Netzwerk verlassen. Die Cloud soll als Quelle fuer Modell-Updates und anonymisierte Bedrohungsintelligenz dienen.

Das folgende Diagramm zeigt die angestrebten Kernkomponenten und ihre Beziehungen:

---

Device Guardian Agent (Zielarchitektur)

Der Device Guardian Agent soll ein leichtgewichtiger System-Dienst werden, der als erste Verteidigungslinie auf dem Gerät des Benutzers arbeitet. Er soll relevante Kommunikationskanäle — E-Mail-Eingänge, Messenger-Nachrichten, Browser-Aktivitäten und Datei-Downloads — in Echtzeit überwachen.

Geplante Kernaufgaben:

• Echtzeitüberwachung eingehender Nachrichten und Dateien
• Content Extraction aus verschiedenen Formaten (E-Mail, Chat, Dokumente)
• Vorfilterung offensichtlich unbedenklicher Inhalte zur Ressourcenschonung
• Benachrichtigungen bei erkannten Bedrohungen mit kontextbezogenen Handlungsempfehlungen

Der Agent soll mit minimalen Systemrechten laufen und ausschließlich auf die Inhalte zugreifen, die der Benutzer explizit freigegeben hat.

Hinweis

Im aktuellen Workspace existiert kein Device Guardian Agent. Die Android-App registriert sich per RSA-Keypair und reicht signierte Events ueber POST /events ein. Eine Echtzeitueberwachung von E-Mail, Messenger oder Browser ist nicht implementiert.

---

Lokale Schutz-Engine (Zielarchitektur)

Die Lokale Schutz-Engine soll das Herzstück der On-Device-Analyse werden. Sie soll kompakte, optimierte ML-Modelle direkt auf dem Gerät ausführen.

Geplante Verfahren:

• NLP-Modelle zur Erkennung von Social-Engineering-Mustern in Textnachrichten
• Bild-Klassifikation für die Voranalyse verdächtiger Anhänge
• URL-Analyse mit Feature-Extraktion (Domain-Alter, Zertifikatsstatus, Ähnlichkeit zu bekannten Marken)
• Verhaltensanalyse zur Erkennung ungewöhnlicher Kommunikationsmuster

Hinweis

Im aktuellen Workspace ist keine lokale Schutz-Engine implementiert. Die Erkennung beschraenkt sich auf einen regelbasierten Stub-Collector fuer app.install.observed-Signale mit additivem Context-Risk-Scoring. Keine ML-Modelle, keine NLP-Analyse, keine Bild-Klassifikation und keine URL-Pruefung sind als Runtime vorhanden.

---

Erkennungs-Pipeline (Zielarchitektur)

Die geplante Erkennungs-Pipeline soll verdächtige Inhalte in drei aufeinander aufbauenden Stufen verarbeiten. Jede Stufe soll die Analysetiefe erhoehen.

Stufe 1 — Heuristik & Regeln (geplant): Schnelle Pattern-Matching-Prüfungen (bekannte Phishing-Domains, verdächtige Absender, offensichtliche Malware-Signaturen).

Stufe 2 — Lokales ML-Modell (geplant): Kompakte neuronale Netze sollen Textinhalt, Absenderverhalten und Metadaten analysieren.

Stufe 3 — Deep Analysis (geplant): Für Fälle, die das lokale Modell nicht mit ausreichender Konfidenz klassifizieren kann. Soll Deepfake-Erkennung und fortgeschrittene NLP-Analyse umfassen. Bei Bedarf anonymisierte Eskalation an ein Cloud AI Analysis Module.

Hinweis

Im aktuellen Workspace existiert nur Stufe-1-artige Logik: ein regelbasierter Stub-Collector mit additivem Context-Risk-Score fuer app.install.observed. Stufe 2 (ML) und Stufe 3 (Deep Analysis / Cloud-Eskalation) sind nicht implementiert.

---

Cloud Enrichment (Zielarchitektur)

Die geplanten Cloud-Komponenten sollen als Quelle fuer kollektive Threat Intelligence und aktualisierte Erkennungsmodelle dienen.

• Threat Database (geplant): Soll Indicators of Compromise (IoC), anonymisierte Bedrohungssignaturen und Reputationsdaten enthalten.
• Model Update Service (geplant): Soll aktualisierte ML-Modelle als signierte Pakete verteilen. Geplanter Rollback-Schutz mit Ed25519-Signaturen.
• AI Analysis Module (geplant): GPU-gestuetzte Analyse fuer komplexe Faelle (Deepfake-Erkennung, Social-Engineering-Analyse). Soll ausschliesslich anonymisierte Feature-Vektoren verarbeiten.

Hinweis

Im aktuellen Workspace existiert kein Cloud-Deployment. Das Backend laeuft lokal als cmd/server. Es gibt keine Threat Database, keinen Model Update Service und kein AI Analysis Module. Agent-Update-Verifikation nutzt RSA-PSS-Signaturen mit umgebungsbasiertem Trusted Key (IMPLEMENTATION_FACTS Abschnitt 8).

---

Datenfluss & Sicherheitsgrenzen

Verifizierter Datenfluss (aktueller Stand)

Datenkategorie	Verarbeitung	Verlässt das Gerät?
RSA-Keypair (Geraeteidentitaet)	Lokale Erzeugung, Public Key wird bei Registrierung uebermittelt	Public Key: Ja — bei POST /devices
Signierte Events	Lokal erzeugt, an Backend uebermittelt	Ja — POST /events mit X-Device-Signature
Telemetrie-Metadaten (Run-ID, Flow, App-Version)	Als Request-Header an Backend	Ja — Korrelations-Header
App-Install-Signale	Lokal beobachtet, als Event ans Backend	Ja — als strukturiertes Event

Geplanter Datenfluss (Zielarchitektur)

Datenkategorie	Verarbeitung	Verlässt das Gerät?
Nachrichteninhalte (E-Mail, Chat)	Lokale Analyse durch Schutz-Engine	Nein — niemals (geplant)
Absender- und Empfängerinformationen	Lokale Auswertung	Nein — niemals (geplant)
Dateien und Anhänge	Lokaler Scan und Klassifikation	Nein — niemals (geplant)
Anonymisierte Feature-Vektoren	Cloud-Eskalation bei unklaren Fällen	Ja — nur anonymisiert (geplant)
Bedrohungssignaturen (IoC)	Download aus Threat Database	Ja — eingehend (geplant)
ML-Modellgewichte	Download vom Model Update Service	Ja — eingehend (geplant)

Hinweis

Die aktuelle Workspace-Runtime nutzt TLS-gesicherte Verbindungen; der Agent kann zusaetzlich optionales SPKI-Pinning ueber SUPERHELD_CLOUD_PIN_SHA256 erzwingen. Die geplanten Cloud-Datenfluesse (Feature-Vektoren, Threat-Database, Modell-Updates) sind nicht implementiert.

---

Datenschutz-Garantien

Verifizierte Datenschutz-Eigenschaften (aktueller Stand)

1. Geraeteidentitaet per RSA-Keypair. Private Key bleibt auf dem Geraet. Public Key wird einmalig bei Registrierung uebermittelt.
2. Signierte Events. Alle Events werden mit X-Device-Signature (RSA-PSS) signiert. Das Backend verifiziert die Signatur.
3. Token-basierte Autorisierung. Secure-Mux-Tokens sind tenant-scoped. Token-Hashes (SHA-256) werden gespeichert, nicht die Tokens selbst.
4. Hash-verketteter Audit-Trail. Token- und Job-Review-Aktionen sind manipulationsresistent protokolliert.
5. Tenant-Isolation. Alle API-Zugriffe sind per Tenant-Scope isoliert.

Geplante Datenschutz-Garantien (Zielarchitektur)

Die folgenden Garantien sind als Architekturziele definiert, aber nicht implementiert:

1. Keine Rohdaten in der Cloud (geplant). Nachrichteninhalte, Dateien und personenbezogene Metadaten sollen das Gerät nicht verlassen.
2. Rekonstruktionsresistenz (geplant). Feature-Vektoren sollen durch PCA, Random Projection und INT8-Quantisierung (128 Dimensionen) transformiert werden. Kein formales Differential Privacy geplant. Details: Privacy-Model-Spezifikation.
3. Signierte Modell-Updates (geplant). ML-Modelle sollen als kryptografisch signierte Pakete verteilt werden (Ed25519, Rollback-Schutz).
4. Opt-out (geplant). Alle Cloud-Funktionen sollen deaktivierbar sein.

Hinweis

Da im aktuellen Workspace kein Cloud-Deployment existiert, sind die Cloud-bezogenen Datenschutzgarantien (Feature-Vektor-Transformation, Threat-Database-Abfragen, Modell-Updates) gegenstandslos. Sie werden relevant, sobald Cloud-Komponenten implementiert sind.