Umgesetzte Schutzmaßnahmen
E2EE v1
Pro Gruppe existiert ein zufälliger 256-Bit-Gruppenschlüssel. Nutzdaten werden in E2EE1-Envelopes mit AES/GCM/NoPadding, zufälligem 96-Bit-IV und AAD aus Gruppen-/Entitätskennungen verschlüsselt.
Schlüssel lokal geschützt
Gruppenschlüssel liegen clientseitig in einem durch Android Keystore geschützten SecureConfigStore.
Einladungen
HTTPS-Einladungen tragen den Gruppenschlüssel nur im URI-Fragment #k2=…. Frei registrierbare kalenduo://-Credential-Fallbacks wurden entfernt.
Recovery
Der KDR1-Master bleibt beim Nutzer. Der Server speichert nur einen abgeleiteten Authentisierungswert als Hash und opake, clientseitig verschlüsselte Gruppenschlüssel-Hüllen.
Portable Backups
Lokale Komplettbackups werden standardmäßig mit AES-256-GCM verschlüsselt und können sämtliche lokal bekannten Kalender-/Gruppendaten einschließlich vorhandener E2EE-Gruppenschlüssel enthalten.
Benachrichtigungen
Der Scheduler speichert statt eines Klartext-Termin-Fingerprints nur einen SHA-256-Digest; die zugehörigen Einstellungen sind vom Android-Cloud-Backup und Device-Transfer ausgeschlossen.
Serverseitig sichtbare Metadaten
Der Server kennt weiterhin technische IDs und Betriebsmetadaten: Gruppen-, Mitglieds-, Geräte- und Entitäts-IDs, Rollen und Aktivstatus, Revisionen und Löschstatus, Zeitpunkte, technische Gerätezugänge sowie technische Audit-Aktionen. E2EE bedeutet deshalb nicht Anonymität.
Noch offen
1. Historische Vor-E2EE-Backups
Früher erzeugte Produktionsbackups können Klartext aus der Zeit vor der E2EE-Migration enthalten. Codeänderungen entfernen solche historischen Kopien nicht automatisch. Vor einer öffentlichen E2EE-Zusage für den Produktionsbestand müssen Altbackups inventarisiert, nach der festgelegten Backup-/Datenschutzprozedur aus dem produktiven Bestand genommen und ein Restore der neuen verschlüsselten Baseline geprüft werden.
2. Re-Keying nach Entfernung anderer Mitglieder
Beim eigenen Austritt wird der lokale Gruppenschlüssel gelöscht und der serverseitige Zugriff widerrufen. Nach Entfernung eines anderen Mitglieds wird der gemeinsame Gruppenschlüssel für die verbleibenden Geräte derzeit jedoch nicht automatisch neu erzeugt und verteilt. Ein separates Re-Key-Protokoll ist noch nicht implementiert.
3. Bluetooth-Anwendungsschicht
Bluetooth verwendet die vorhandene bestätigte Sitzung und BLE-Linkverschlüsselung. Eine eigenständige kryptographisch authentisierte Anwendungsschicht – etwa PAKE-/Noise-artig – fehlt noch. Bluetooth wird daher nicht als gleichwertig zur E2EE-Sicherheitszusage von Servergruppen beworben.
4. Betrieb und Skalierung
Der aktuelle Server nutzt ThreadingHTTPServer und SQLite. Für eine Aussage wie „für 10.000 Nutzer belastbar“ fehlen reproduzierbare Lasttests sowie entsprechend dokumentiertes Monitoring, äußere Request-/Connection-Limits und Restore-Übungen.
5. Unabhängiger Audit
Für den hier beschriebenen Quellstand liegt noch kein unabhängiger externer Penetrationstest beziehungsweise Sicherheits- und Datenschutz-Audit vor. Die Website vermeidet deshalb Aussagen wie „vollständig sicher“ oder „audit-geprüft“.
Was „keine Tracker“ hier bedeutet
Im geprüften Android-Quellstand 5.4.56 sind keine Firebase-, Werbe- oder Analytics-SDKs eingebunden. Das ist keine Aussage, dass die App niemals Netzwerkverkehr erzeugt: Servergruppen, Einladungen, Wiederherstellung und Update-Prüfungen benötigen beziehungsweise können Netzwerkzugriffe auslösen.
Stand
Technische Grundlage: Kalenduo 5.4.56. Website-Stand: 11.08.2026.