Öffentliche und private Schlüssel

Public-Key-basierte Authentifizierung

Werden zum Schutz von unberechtigten Zugriffen Public-Key-Kryptosysteme eingesetzt, so kann aufgrund eines unzureichenden Schlüsselmanagements der gewünschte Schutz unterlaufen werden, wenn

• die kryptographischen Schlüssel in einer ungesicherten Umgebung erzeugt oder aufbewahrt werden,
• ungeeignete oder leicht zu erratende Schlüssel eingesetzt werden oder
• die eingesetzten Schlüssel die Gegenstelle nicht auf einem sicheren Weg erreichen.

Qualitativ hochwertige Verfahren und Schlüssel

Für die Schlüsselerzeugung geeignete Schlüsselgeneratoren müssen kontrollierte, statistisch gleichverteilte Zufallsfolgen unter Ausnutzung des gesamten möglichen Schlüsselraums produzieren. Wenn die verwendete Zufallsquelle ungeeignet ist, können Schlüssel erzeugt werden, die unsicher sind. Einige Kryptomodule, insbesondere solche, die keinen integrierten Zufallszahlengenerator besitzen, greifen auf Benutzer*inneneingaben zur Schlüsselerzeugung zurück. Solche Benutzer*inneneingaben sollen auch möglichst zufällig, also schlecht vorhersagbar, sein.

Bei der Wahl geeigneter kryptographischen Verfahren und Schlüssellängen kann auf die Empfehlungen der BSI TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ oder anderer vertrauenswürdiger Stellen (wie der BNetzA) zurückgegriffen werden. Derzeit (Stand: Juli 2016) können RSA (n min. 2048 Bit) und ECDSA (q min. 250 Bit) empfohlen werden.

Besteht der Verdacht, dass ein verwendeter Schlüssel offengelegt wurde, so ist dieser Schlüssel nicht mehr zu verwenden und alle Beteiligten sind zu informieren. Bereits mit diesem Schlüssel verschlüsselte Informationen sind zu entschlüsseln und mit einem anderen Schlüssel zu verschlüsseln.

Sichere Speicherung und Verwaltung

Generell dürfen Schlüssel nicht in unverschlüsselter Form gespeichert werden. Ausnahmen bilden technisch bedingte Notwendigkeiten durch die Anwendung, in denen sie zumindest zeitweise in Klarform vorliegen müssen. Bieten das IT-System oder der für einen Transport verwendete Datenträger keinen ausreichenden Zugriffsschutz für die Schlüssel, sollten diese nicht auf diesem gespeichert werden. 

Gängige Browser bzw. Betriebssysteme bieten die Möglichkeit der Verschlüsselung der im Zertifikatsspeicher abgelegten Zertifikate mittels eines „Masterpasswortes“. 

Alternativ kann die Verschlüsselung des gesamten Datenträgers (bspw. mit VeraCrypt oder BitLocker. Zu Letzterem und dessen sicherer Nutzung gibt es im Grundschutzkatalog M4.337 nähere Informationen) in Erwägung gezogen werden, um einen unberechtigten Zugriff auf das Zertifikat zu erschweren. Diese Verschlüsselung ist für die Nutzer*innen nahezu transparent: Lediglich beim Booten erfolgt eine Authentifizierungsaufforderung. 

Aus Sicherheitsaspekten ist jedoch der Einsatz von Hardware-Verschlüsselungskomponenten (Tokens oder Chipkarten) vorzuziehen, bei denen die Schlüssel verschlüsselt auf direktem Weg in die Verschlüsselungskomponente geladen werden und diese zu keiner Zeit in Klarform verlassen. Damit diese Token (bspw. bei Verlust) nur durch eine autorisierte Person verwendet werden, muss der Zugriff mit einem geeigneten Passwort geschützt sein. (Diese Konstellation sollte nicht als Zwei-Faktor-Authentifizierung missverstanden werden, da hierfür die notwendige serverseitige Prüfung des Passwort-Faktors fehlt.)

Es muss sehr genau überlegt werden, ob und wie die benutzten kryptographischen Schlüssel gespeichert werden sollen, da jede Schlüsselkopie eine potentielle Schwachstelle ist. Dennoch kann es aus verschiedenen Gründen notwendig sein, bspw. bei langlebigen Schlüsseln, um sie als Vorbeugung gegen Schlüsselverlust zu archivieren. 

Für Archivierungszwecke sollte das kryptographische Schlüsselmaterial in seinerseits verschlüsselter Form, d.h. mit einem sogenannten KEK (Key-Encryption-Key: Überschlüsselungsschlüssel), auf einen externen Datenträger gesichert werden. Der KEK und die Sicherung müssen entsprechend sicher aufbewahrt werden.