# Betriebshandbuch: OTP-Kommunikator (Version 5.1.0)

Vorwort zur Sicherheit
Der OTP-Kommunikator ist kein gewöhnlicher Messenger. Es gibt keinen zentralen Server, kein Cloud-Backup für vergessene Passwörter und keinen Support. Dieses System gibt dir die absolute Kontrolle über deine Daten zurück – und damit auch die volle Verantwortung. Ein Fehler im Umgang mit den Schlüsseln oder der Hardware kompromittiert die gesamte Sicherheit. Halte dich strikt an die folgenden Protokolle.

## 1. Hardware-Voraussetzungen (Air-Gapping)
Für maximale Sicherheit darf die App nicht auf deinem alltäglichen Smartphone installiert werden.
* Beschaffe zwei ausgemusterte Android-Smartphones mit Android 8.0 (API 26) oder höher. Dies ist zwingend erforderlich, um eine verlässliche Hardware-Keystore-Implementierung (TEE) zu garantieren.
* Setze beide Geräte auf die Werkseinstellungen zurück.
* Entferne die SIM-Karten physisch und dauerhaft.* Deaktiviere WLAN und Bluetooth. Schalte den Flugmodus ein.
* Absolute Air-Gap-Fähigkeit: Diese beiden Geräte dienen ab sofort ausschließlich als isolierte, kryptografische Rechenmaschinen. Sie dürfen nie wieder mit einem Netzwerk verbunden werden.
* Cloud-Blockade: Android Auto-Backups sind auf Systemebene hart blockiert (allowBackup="false"), sodass niemals forensische Datenspuren in die Google-Cloud abfließen können.

## 2. Schlüsselerzeugung und Austausch
Um die maximale Sicherheit des One-Time-Pads zu gewährleisten, vertraut die App der Hardware des Smartphones grundsätzlich nicht. Betriebssysteme nutzen pseudo-zufällige Algorithmen, die theoretisch manipulierbar sind. Daher ist die Schlüsselerzeugung strikt an echten physikalischen Zufall (TRNG) gebunden, der zwingend von außen zugeführt werden muss.

1. Starte einen Offline-Rechner mit einem TAILS-Live-USB-Stick (Download: https://tails.net/).
2. Stecke eine leere MicroSD-Karte ein und öffne das Terminal.
3. Generiere die Entropie-Datei (bewege dabei die Maus wild):
   # Formel für N Schlüssel: count = ceil((32 + N * 380) / 1048576) + 1
   # (Für 1.000 bis 10.000 Schlüssel ist 'count=5' der ideale, sichere Standardwert)
   dd if=/dev/random of=/media/amnesia/NAME_SD_KARTE/entropy.bin bs=1M count=5
4. Lege die SD-Karte in Gerät A ein, starte die Schlüsselerzeugung und wähle die entropy.bin aus.

Der weitere Ablauf:
* Zufalls-Salt: Jede Datenbank erhält einen 16-Byte Zufalls-Salt für die Argon2-Härtung, der fest im Dateinamen verankert wird.
* Doppel-Index: Sende- und Empfangsschlüssel erhalten exklusive IDs, um Metadaten-Lecks beim Nachrichtenaustausch zu verhindern.
* Einlesen auf Gerät A: Nach der Erstellung liegen zwei Datenbank-Dateien (Gerät A und Gerät B) in dem App-spezifischen Verzeichnis auf der SD-Karte (Android/data/com.example.otp_kommunikator/files/). Importiere nun zwingend zuerst die für Gerät A bestimmte Datei. Du vergibst hierbei ein Pseudonym (z.B. "Alice").
* Chip-Off-Schutz (In-Place-Verifizierung): Zur Abwehr von Wear-Leveling-Artefakten auf dem internen Speicher wird die Datenbank direkt auf der SD-Karte kryptografisch verifiziert und erst bei Erfolg in das System kopiert. Die Quelldatei auf der SD-Karte wird nach dem erfolgreichen Einlesen vom Dateisystem gelöscht. Da Software-Löschbefehle auf Flash-Speichern wegen des Wear-Levelings keinen sicheren Chip-Off-Schutz bieten, ist die SD-Karte am Ende zwingend physisch zu zerstören.
* Übergabe an Gerät B: Entnimm erst danach die SD-Karte und lege sie in Gerät B ein. Importiere dort die verbleibende Datei für Gerät B unter dem gleichen oder einem anderen Pseudonym.
* ACHTUNG OPSEC: Der unverschlüsselte Master-Schlüssel (entropy.bin) liegt nach der Generierung noch auf dem Flash-Speicher. Wegen des Wear-Levelings MUSS die SD-Karte nach dem erfolgreichen Import auf beiden Geräten zwingend physisch zerstört (geschreddert) werden.

## 3. Der blinde Login und Kontakt-Verwaltung
Um die Existenz deiner Kommunikation zu verschleiern, zeigt die App beim Start niemals vorhandene Kontakte an. Du siehst lediglich einen neutralen "Systemzugriff"-Bildschirm.
* Master-Zugang: Erst die korrekte Eingabe deines Master-Passworts im blinden Startbildschirm entschlüsselt den internen Index und zeigt deine echten Kontakte (z.B. "Alice", "Bob") an.
* Kompartimentierung: Jeder Kontakt ist einzeln mit einem weiteren, spezifischen Passwort verschlüsselt. Es gibt kein zentrales Master-Passwort, das alle Tresore gleichzeitig öffnet.

## 4. Nachrichten, Übertragung und Padding
Die App versendet selbst keine Daten. Sie berechnet lediglich Chiffre-Texte und stellt diese optisch dar.
* Manipulationsschutz (HMAC): Jede Nachricht wird mit einer individuellen HMAC-SHA256 Signatur versiegelt. Der Schlüssel hierfür wird für jede Nachricht neu aus dem OTP-Material abgeleitet.
* PKCS#7 Padding: Nachrichten werden immer auf eine feste Länge (150 Bytes) nach dem kryptografischen Standard PKCS#7 aufgefüllt. Dies verbirgt die tatsächliche Textlänge vor Metadaten-Analysen.
* Sparse Keyspace (DoS-Schutz): Jeder Schlüssel erhält einen 16-stelligen Hex-Index. Eingehende Codes werden mathematisch auf die korrekte Byte-Länge geprüft. Plump gefälschte Codes oder zufälliges Raten prallen an einem Adressraum von 18 Trillionen Kombinationen ab, BEVOR die Datenbank kontaktiert wird. Deine echten Schlüssel bleiben geschützt.
* Fail-Secure Transaktionen (Anti-Replay & Anti-DoS): Beim Einlesen eines Codes wird der OTP-Schlüssel in einer atomaren Datenbank-Transaktion aufgerufen. Die kryptografische HMAC-Prüfung findet strikt innerhalb dieses gesperrten Zustands statt. Ist das Siegel manipuliert (z. B. durch gefälschte QR-Codes), greift ein sicheres Rollback und der Schlüssel bleibt erhalten. Nur bei 100%iger Gültigkeit wird der Schlüssel physisch vernichtet. Dies verhindert Replay-Angriffe und Denial-of-Service (DoS) Sabotage durch Schlüsselverbrennung endgültig.
* Übertragung: Scanne den generierten QR-Code von Gerät A mit der Kamera von Gerät B ab. Alternativ kann der Text abgetippt oder per unsicherem Messenger übertragen werden. Die Sicherheit liegt ausschließlich im Chiffretext.

## 5. Passwörter und Notfälle (OpSec)
Die Datenbank ist mit SQLCipher (AES-256) verschlüsselt. Ohne das Passwort ist der Speicherinhalt forensisch wertlos.
* Hardware-Keystore: Die App speichert keine unverschlüsselten Konfigurationsdateien. Passwort-Hashes und Salts werden durch EncryptedSharedPreferences (AES-256 GCM) im Hardware-Chip (TEE) geschützt. Die Zugriffe sind durch Threadsperren (Mutex) gegen schnelle Brute-Force-Angriffe abgesichert.
* Safe-Passwort: Nutze starke Passwörter. Das System nutzt zur Härtung Argon2 mit einem kryptografischen Zufalls-Salt. Anschließend sorgt eine HKDF (HMAC-based Key Derivation Function) für die strikte mathematische Trennung zwischen Datenbank- und Authentifizierungsschlüssel.
* Spezifisches Panic-Passwort: Die Eingabe dieses spezifischen Passworts beim Login für "Alice" löscht sofort und unwiderruflich nur die Datenbank von "Alice".
* Glaubhafte Abstreitbarkeit (Decoy-Modus): Bei der Ersteinrichtung kannst du optional ein Decoy-Passwort vergeben. Wirst du gezwungen, die App zu entsperren, gibst du dieses Passwort im blinden Startbildschirm ein. Es öffnet sich ein voll funktionsfähiges, isoliertes Fake-System. Ein Ermittler kann mathematisch nicht beweisen, dass noch ein versteckter Master-Container existiert.
* Globales Panic-Passwort (Nuke-Schalter): Dieses ebenfalls optionale Passwort kann direkt im blinden Startbildschirm eingegeben werden. Es löscht in Millisekunden das gesamte System (alle Datenbanken, Indizes und den Keystore).
* Tabula Rasa (Nach dem Nuke): Anders als bei vorherigen Versionen stürzt die App nach einem globalen Wipe nicht mehr ab. Sie bereinigt sich selbst lautlos und startet direkt wieder im initialen Einrichtungs-Bildschirm. Für einen Prüfer sieht es so aus, als wäre die App frisch installiert und noch nie benutzt worden.
* Brute-Force-Schutz: Nach dem 5. Fehlversuch bei einem Kontakt wird dessen Datenbank automatisch gelöscht.
* RAM-Hygiene (Zero-Footprint): Die App verzichtet konsequent auf unveränderliche Java-Strings für sensible Daten. Sowohl Passwörter als auch Nachrichten-Klartexte werden über native UI-Bypässe direkt als CharArray verarbeitet. Alle Puffer werden nach der Nutzung aktiv mit Nullen überschrieben. Sobald die App in den Hintergrund rückt, wird entschlüsselter Text sofort aus dem Speicher genullt.

## 6. Notfall-Schlüsselvernichtung (Emergency Burn)
Wenn eine Nachricht auf dem Transportweg nachweislich abgefangen wird oder verloren geht, bleibt der dazugehörige Empfangsschlüssel auf dem Zielgerät ungenutzt. Um Replay-Angriffe oder eine spätere Entschlüsselung bei Geräteverlust zu verhindern, muss dieser "Geisterschlüssel" gezielt vernichtet werden.
Ablauf:
    Der Sender notiert sich die Schlüssel-ID (wird beim Erzeugen des QR-Codes als Erfolgstext angezeigt).
    Der Sender teilt dem Empfänger über einen alternativen, unsicheren Kanal mit, dass die Nachricht mit dieser spezifischen ID kompromittiert ist.
    Der Empfänger öffnet den Bildschirm für den Nachrichtenempfang und gibt die ID exakt in das Feld "Gezielte Schlüsselvernichtung" ein.
    Durch Bestätigung wird der Schlüssel unwiderruflich aus der AES-verschlüsselten Datenbank und dem Arbeitsspeicher (RAM) getilgt.