Security: E2EE Private Key – AndroidKeysetManager statt CleartextKeysetHandle #105

New issue

Closed

opened 2026-05-17 22:22:03 +00:00 by jreinemann-euris · 1 comment

jreinemann-euris commented

2026-05-17 22:22:03 +00:00

(Migrated from github.com)

Hintergrund

Aus dem Code Review von #96 (E2EE): Die aktuelle Implementierung serialisiert den Tink KeysetHandle (Private Key) via CleartextKeysetHandle.write() in einen JSON-String, bevor dieser in EncryptedSharedPreferences abgelegt wird.

Risiko: Der Klartext-JSON des privaten Schlüssels existiert kurz im JVM-Heap (Crash-Dumps, Heap-Dumps, Profiler könnten ihn exponieren).

Ziel

CleartextKeysetHandle + JsonKeysetWriter für den privaten Key ersetzen durch AndroidKeysetManager.Builder, der den Tink-Keyset direkt mit einem Android-Keystore-backed AEAD-Wrapper schützt – ohne den Schlüssel je als cleartext-String zu materialisieren.

Scope

E2EEKeyManager.kt: Private Key via AndroidKeysetManager.Builder speichern und laden
Migration: Bestehende Geräte mit altem Format müssen erkannt und migriert werden (einmalige Re-Generierung + Server-Upload)
Tests anpassen

Nicht im Scope

Änderung des kryptografischen Verfahrens (bleibt HPKE X25519/ChaCha20-Poly1305)
UI-Änderungen

Referenz

Tink Android Key Storage Guide: https://developers.google.com/tink/generate-plaintext-keyset#android

Part of: #96 (E2EE)

## Hintergrund Aus dem Code Review von #96 (E2EE): Die aktuelle Implementierung serialisiert den Tink KeysetHandle (Private Key) via CleartextKeysetHandle.write() in einen JSON-String, bevor dieser in EncryptedSharedPreferences abgelegt wird. **Risiko:** Der Klartext-JSON des privaten Schlüssels existiert kurz im JVM-Heap (Crash-Dumps, Heap-Dumps, Profiler könnten ihn exponieren). ## Ziel CleartextKeysetHandle + JsonKeysetWriter für den privaten Key ersetzen durch AndroidKeysetManager.Builder, der den Tink-Keyset direkt mit einem Android-Keystore-backed AEAD-Wrapper schützt – ohne den Schlüssel je als cleartext-String zu materialisieren. ## Scope - [ ] E2EEKeyManager.kt: Private Key via AndroidKeysetManager.Builder speichern und laden - [ ] Migration: Bestehende Geräte mit altem Format müssen erkannt und migriert werden (einmalige Re-Generierung + Server-Upload) - [ ] Tests anpassen ## Nicht im Scope - Änderung des kryptografischen Verfahrens (bleibt HPKE X25519/ChaCha20-Poly1305) - UI-Änderungen ## Referenz Tink Android Key Storage Guide: https://developers.google.com/tink/generate-plaintext-keyset#android Part of: #96 (E2EE)

jreinemann-euris commented

2026-05-18 07:51:35 +00:00

(Migrated from github.com)

Umgesetzt in commit 8e7352d.

Änderungen:

Private Key wird jetzt via \AndroidKeysetManager\ + Android Keystore-backed AEAD geschützt
\CleartextKeysetHandle\ wird nur noch für Public Keys verwendet (nicht geheim)
Bestehende Geräte mit Legacy-Klartext-Key werden bei App-Start migriert (Key gelöscht → Re-Generierung + Server-Upload via EnsureKeyPairUseCase)
Neue Architektur: \PrivateKeysetStore-Interface für Testbarkeit ohne Robolectric

Testabdeckung:

Alle bestehenden Unit Tests angepasst + neuer Migrationstest
Build + Tests: ✅

Umgesetzt in commit 8e7352d. **Änderungen:** - Private Key wird jetzt via \AndroidKeysetManager\ + Android Keystore-backed AEAD geschützt - \CleartextKeysetHandle\ wird nur noch für Public Keys verwendet (nicht geheim) - Bestehende Geräte mit Legacy-Klartext-Key werden bei App-Start migriert (Key gelöscht → Re-Generierung + Server-Upload via EnsureKeyPairUseCase) - Neue Architektur: \PrivateKeysetStore\-Interface für Testbarkeit ohne Robolectric **Testabdeckung:** - Alle bestehenden Unit Tests angepasst + neuer Migrationstest - Build + Tests: ✅

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: bollwerkadmin/bollwerk#105

No description provided.