Kryptografische Löschung (Crypto-Shredding)

Ausführliche Erklärung

Bei der kryptografischen Löschung werden personenbezogene Daten von Anfang an mit individuellen Schlüsseln verschlüsselt gespeichert. Tritt eine Löschpflicht ein – etwa durch einen Antrag nach Art. 17 DSGVO oder den Ablauf von Aufbewahrungsfristen – wird nicht die verschlüsselte Datei entfernt, sondern ausschließlich der zugehörige Schlüssel vernichtet. Ohne diesen Schlüssel ist der verbleibende Chiffretext bei Verfahren nach dem Stand der Technik, etwa AES-256, praktisch nicht mehr zu rekonstruieren.

Interessant ist die Methode vor allem dort, wo eine physische Löschung technisch aufwendig oder unmöglich ist: in unveränderlichen Audit-Trails, in verteilten Backups, in Immutable-Storage-Systemen oder wenn Daten über mehrere Cloud-Regionen repliziert wurden. Sie ergänzt damit die reguläre Backup-Behandlung im Löschkonzept, ersetzt sie aber nicht: Für Sicherungskopien erlaubt § 4 Abs. 2 DSG ohnehin, die Verarbeitung bis zum nächsten technisch möglichen Löschzeitpunkt lediglich einzuschränken, mit der Wirkung des Art. 18 Abs. 2 DSGVO. Verbreitete Sekundärquellen zitieren hier fälschlich „§ 4 Abs. 4 DSG“; dieser regelt die Einwilligung von Kindern.

Technisch setzt Crypto-Shredding voraus, dass je Person oder je Datensatz ein eigener Schlüssel verwendet und in einem Key-Management-System verwahrt wird (verwandt: BYOK). Bei einer Löschung wird der Schlüssel unwiderruflich entfernt. Cloud-Dienste bieten dafür standardisierte Abläufe mit Wartefristen: AWS KMS plant die Schlüssellöschung mit einer Wartezeit von 7 bis 30 Tagen (Standard 30), in Azure Key Vault schiebt Soft Delete die endgültige Löschung um eine konfigurierbare Aufbewahrungszeit von bis zu 90 Tagen hinaus, die sich mit Purge Protection auch erzwingen lässt. Erst nach Ablauf dieser Frist ist die Vernichtung endgültig – bis dahin ist die Löschung datenschutzrechtlich nicht abgeschlossen.

Kryptografische Löschung ist kein Rechtsbegriff, sondern eine technische Maßnahme. In NIST SP 800-88 Rev. 1 ist Cryptographic Erase als anerkannte Sanitisierungstechnik der Kategorie „Purge“ beschrieben; die Publikation weist allerdings darauf hin, dass der Nachweis der Wirksamkeit im Einzelfall schwierig sein kann. Datenschutzrechtlich stützt sich die Praxis auf die Linie der österreichischen Datenschutzbehörde zur Anonymisierung: Im Bescheid DSB-D123.270/0009-DSB/2018 vom 5. Dezember 2018 hielt die Behörde fest, dass Art. 4 Z 2 DSGVO „Löschen“ und „Vernichten“ als unterschiedliche Verarbeitungsformen nennt, der Verantwortliche die Methode wählen darf und es genügt, wenn weder er selbst noch Dritte den Personenbezug ohne unverhältnismäßigen Aufwand wiederherstellen können. Eine ausdrückliche Entscheidung der DSB zum Crypto-Shredding liegt bislang nicht vor. Entscheidend ist daher, dass die Verschlüsselung dem Stand der Technik entspricht, keine Schlüsselkopien außerhalb des Key-Management-Systems bestehen, die Vernichtung dokumentiert wird (Löschnachweis) und das Verfahren als technische und organisatorische Maßnahme festgeschrieben ist. Fehleinschätzungen hier treffen den Kern einer Betroffenenanfrage – die Datenschutzbehörde kann Verstöße gegen Art. 17 DSGVO mit Geldstrafen ahnden.

Code-Beispiel

```python
# Beispiel: Crypto-Shredding mit per-user Schlüssel
from cryptography.fernet import Fernet
import boto3

kms = boto3.client('kms')

def encrypt_user_data(user_id: str, data: dict) -> bytes:
    """Verschlüsselt Daten mit benutzerspezifischem DEK"""
    dek = kms.generate_data_key(KeyId='alias/master-key',
                                  KeySpec='AES_256')
    cipher = Fernet(dek['Plaintext'])
    ciphertext = cipher.encrypt(str(data).encode())
    # Speichere verschlüsselten DEK mit user_id
    store_encrypted_key(user_id, dek['CiphertextBlob'])
    return ciphertext

def crypto_shred(user_id: str):
    """Löscht Schlüssel unwiderruflich"""
    key_id = get_key_id_for_user(user_id)
    kms.schedule_key_deletion(KeyId=key_id, 
                               PendingWindowInDays=7)
```