Mobile Verschlüsselung für Dateitransfer: sicher unterwegs teilen

Mobile Dateiverschlüsselung läuft in Safari auf iOS und Chrome/Firefox auf Android über die Web Crypto API — derselbe crypto.subtle.encrypt-Aufruf, der auf dem Desktop funktioniert. Dateien aus der Fotomediathek oder der Dateien-App werden mit AES-256-GCM verschlüsselt, bevor ein einziges Byte das Gerät verlässt. Der rechenintensivste Schritt ist die PBKDF2-Schlüsselableitung: Auf einem iPhone 14 Pro dauern 600.000 Iterationen etwa 350 ms. Bei einer 500-MB-.mov-Datei ist der echte Engpass die Upload-Bandbreite, nicht die Verschlüsselung. Mobile-First-Transferdienste brauchen keine nativen Apps — der Browser hat alles, was nötig ist.

Warum browserbasiert nativen Apps auf Mobilgeräten überlegen ist

Native iOS- und Android-Apps für Dateitransfer (Dropbox, WeTransfers App vor 2023) fordern weitreichende Berechtigungen an, bleiben nach der Nutzung im Arbeitsspeicher und schalten Werbung. Ein browserbasierter Workflow erfordert keine Installation, läuft einmalig und schließt mit dem Tab. Wichtiger noch: Apples App-Store-Ablehnung echter Zero-Knowledge-Apps (der Cryptee-Fall 2021 ist dokumentiert) macht die Browser-Auslieferung zum einzigen Weg, um sicherzustellen, dass die Verschlüsselungslogik nicht durch ein App-Store-Update stillschweigend ausgetauscht wird. Dasselbe JavaScript-Bundle läuft überall und ist gegen SHA-384-Hashes prüfbar.

Die Web Crypto API auf iOS und Android

Safari 17 auf iOS 17+ unterstützt crypto.subtle vollständig: deriveKey, encrypt, decrypt, sign, verify. Chrome auf Android unterstützt es seit Version 37 (2014). Beide Implementierungen delegieren an native OS-Primitiven — CommonCrypto auf iOS, BoringSSL auf Android — sodass die Kryptografie durch ARMs AES-Anweisungen hardwarebeschleunigt ist. Ein 5-MB-Chunk verschlüsselt auf einem Pixel 8 in etwa 15 ms. Die API gibt kein rohes Schlüsselmaterial an JavaScript preis (CryptoKey-Objekte sind opake Handles), was gegenüber schädlichen Erweiterungen hilft — mobile Browser haben davon aber ohnehin weit weniger.

Große Dateien ohne Speicher-Overflow verarbeiten

Mobile Safari begrenzt den JavaScript-Heap auf etwa 2 GB auf iPhones mit 6 GB RAM, weniger auf älteren Geräten. Ein naives „Datei in ArrayBuffer lesen, verschlüsseln, hochladen"-Muster bricht bei mehr als 1 GB zusammen. Streaming ist zwingend. Verwenden Sie File.slice(), um 5-MB-Chunks zu lesen, jeden mit einem per HKDF abgeleiteten Unterschlüssel zu verschlüsseln und per fetch() mit einem ReadableStream-Body hochzuladen. Progressives Uploading hält den Spitzenspeicher auch bei 10-GB-Videos unter 50 MB. Chrome auf Android unterstützt Streaming-Fetch-Requests seit Version 105; Safari fügte volle Unterstützung in 17.4 hinzu.

Akku und Wärmeentwicklung

AES-256-GCM ist hardwareseitig günstig — ARMv8's Cryptography Extensions lassen es nahezu auf DRAM-Geschwindigkeit laufen. 1 GB verschlüsseln auf einem iPhone 14 Pro verbraucht etwa 2 % Akku, hauptsächlich durch das Funk für den Upload, nicht die CPU. Hitze spüren Nutzer bei PBKDF2 mit hoher Iterationszahl; 1,2 Millionen Iterationen (OWASP-Empfehlung 2024) dauern 700 ms und treiben den A17 kurzzeitig auf 90 °C. 600.000 Iterationen balancieren Sicherheit und Wärme. Argon2id mit m=32 MB ist bei anhaltenden Workloads schonender, weil speichergebundene Hardness langsamer, aber weniger leistungsdicht ist.

Mobilfunk, WLAN und Upload-Zuverlässigkeit

Mobile Uploads scheitern. Ein U-Bahn-Tunnel, ein Aufzug, ein Wechsel von WLAN zu LTE — all das unterbricht einen naiven fetch(). Zuverlässige mobile Übertragung nutzt wiederaufnehmbare Uploads mit Chunk-Bestätigung, Protokolle wie tus.io (tus 1.0-Spezifikation, weit verbreitet) oder S3 Multipart Uploads. Jeder 5-MB-Chunk wird unabhängig hochgeladen; bei einem Fehler wird nur dieser Chunk erneut gesendet. Der Client speichert den Chunk-Zustand in IndexedDB, sodass ein Tab-Reload oder iOS-Tab-Eviction den gesamten Vorgang nicht neu startet. HexaTransfer implementiert wiederaufnehmbare Uploads; WeTransfers mobiler Web-Flow tut dies nicht, weshalb 2-GB-Uploads über LTE dort häufig fehlschlagen.

Passwort-Eingabe und das UX-Problem auf der Tastatur

Ein 16-stelliges starkes Passwort auf einer mobilen Tastatur einzutippen ist mühsam. Bieten Sie Alternativen an: QR-Code vom Bildschirm des Absenders scannen, der das Passwort enthält; Einfügen aus dem nativen Passwort-Manager (iOS füllt aus dem Schlüsselbund über .well-known/apple-app-site-association-Äquivalente für Web); oder einen Passkey verwenden, der bei einem früheren Transfer registriert wurde. Für Einmaltransfers können Sie die Web Share Target API nutzen, um einer Begleit-App (zum Beispiel Signal) das Einschleusen des Passworts zu ermöglichen, ohne dass Sie es erneut eingeben müssen.

Barrierefreiheit und kleine Bildschirme

Ein 4,7-Zoll-iPhone SE bietet keinen Platz für einen Desktop-Drag-and-Drop-Uploader. Mobile Verschlüsselungs-UIs sollten den Viewport respektieren: Vollbild-Dateiauswahl, Fortschrittsbalken, die auch über der Bildschirmtastatur sichtbar bleiben, VoiceOver-Labels auf jedem Button (role="progressbar" mit aria-valuenow für Barrierefreiheit) und ein Mindest-Tippziel von 44×44 px gemäß Apple HIG. Verstecken Sie keine Steuerelemente hinter Hover-Zuständen — auf Touch gibt es kein Hover. Testen Sie mit iOS Low Power Mode, der Hintergrund-Timer drosselt und polling-basierte Fortschrittsaktualisierungen unterbricht.

iOS-Safari-Eigenheiten, die Uploads beeinträchtigen

Safari auf iOS hat einige Fallen. Die Upload-Progress-Events der Fetch-API feuern vor iOS 16.4 nicht zuverlässig. Die File System Access API wird nicht unterstützt, daher können Sie große Dateien nicht so aus dem lokalen Speicher streamen wie Chrome. Safari verwirft inaktive Tabs bei Speicherdruck aggressiv, was laufende Uploads abbricht. Abhilfen: XMLHttpRequest mit Progress-Events als Fallback verwenden (funktioniert noch einwandfrei), den Tab während des Uploads im Vordergrund halten und den Nutzer warnen, den Bildschirm bei großen Dateien nicht zu sperren. Bildschirm an verbraucht Akku, verhindert aber Tab-Eviction.

Androidsgerätevielfalt und ihre Folgen

Android reicht vom Pixel 8 Pro bis zu 80-€-Moto-e14-Geräten mit Android Go. Web Crypto funktioniert auf allen, aber die Leistung variiert stark — ein MT6762 mit 2 GHz braucht 1,8 Sekunden für 600.000 PBKDF2-Iterationen, wo ein Apple-M3-gleichwertiges Gerät 200 ms benötigt. Erkennen Sie das Gerät über die Device Memory API und Hardware Concurrency, skalieren Sie Iterationszahlen entsprechend (bis 300.000 für Go-Geräte) und warnen Sie Nutzer auf reinen Mobilfunk-Verbindungen, dass Uploads über 1 GB unzuverlässig sein können. Der Vorteil: Verschlüsselter Transfer funktioniert auf der Mehrheit der weltweiten Smartphones, ohne ein Flaggschiff zu erfordern.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.