BSI: Hohe Anforderungen an RSA-Schlüssellängen bei TLS-Verbindungen

Das BSI fordert für TLS-Verbindungen äußerst große RSA-Schlüssellängen. Sprecher relativieren, es seien Empfehlungen. Checklisten widersprechen dem.

In Pocket speichern vorlesen Druckansicht 175 Kommentare lesen

(Bild: zffoto / Shutterstock.com)

Lesezeit: 6 Min.
Von

Mit seinen Veröffentlichungen, die sich mit Schlüssellängen bei kryptografischen Verfahren beschäftigen, hat das Bundesamts für Sicherheit in der Informationstechnik (BSI) zum Jahreswechsel für Verwirrung bei Serverbetreibern gesorgt. Die oberste IT-Sicherheitsbehörde Deutschlands schreibt ab diesem Jahr für TLS-Verbindungen von Webservern vor, dass diese sich mit mindestens 3000 Bit langen RSA-Schlüsseln auszuweisen hätten. Selbst erfüllt das BSI das auf seiner eigenen Website derzeit noch nicht, sondern wiegelt ab, dass es sich dabei um eine Empfehlung handele.

Die BSI-Webserver weisen sich entgegen der eigenen Empfehlungen mit 2048-Bit-RSA-Schlüsseln aus, im Januar 2024.

(Bild: Screenshot / dmk)

Konkret geht es um die Technische Richtlinie TR-02102-2, also den zweiten Teil der TR, die die Anforderungen des BSI an Transport Layer Security (TLS-Verbindungen) beschreibt. Die wurde zuletzt im Januar 2023 aktualisiert und empfiehlt auf Seite 18 die Verwendung von mindestens 3000-Bit-RSA-Schlüsseln ab spätestens dem vergangenen Jahr. Wörtlich heißt es: "Als Übergangsregelung ist außerdem die Nutzung von RSA-Schlüsseln mit einer Länge ab 2000 Bit bis Ende 2023 ebenfalls noch konform zu dieser Technischen Richtlinie."

Gegen ein mehr an Sicherheit ist selten etwas einzuwenden, jedoch ist die Formulierung missverständlich. Einerseits findet sich der gesamte Abschnitt im Kapitel 3 "Empfehlungen", andererseits ist von Konformität zur Technischen Richtlinie die Rede. Konformität müssen Behörden und Dienstleister sowie KRITIS-Betreiber sicherstellen, die für sichere Konfigurationen ihrer Systeme sorgen müssen. Auf Nachfrage von heise online erklärte ein Sprecher, es handle sich nur um eine Empfehlung und keine Forderung. Damit widerspricht das BSI einer anderen Veröffentlichung aus dem eigenen Haus: In der TLS-Checkliste für Diensteanbieter nach TR-03116-4 mit Stand vom 7.3.2023 findet sich die Forderungen nach einem 3072-Bit-RSA-Schlüssel direkt in der ersten Zeile. Dieses Dokument ist die Grundlage für die staatliche Auftragsvergabe an Dienstleister. Behörden und Dienstleister sowie KRITIS-Betreiber, die für sichere Konfigurationen ihrer Systeme sorgen, müssen dieser Veröffentlichung Folge leisten.

Das BSI selbst ist seiner Empfehlung und auch der TR-03116-4 nicht pünktlich zum Jahreswechsel gefolgt und nutzt für seine Website derzeit selbst noch 2048-Bit-RSA-Schlüssel. Ein BSI-Sprecher erklärte, dass der nächste turnusmäßige Zertifikatetausch im Februar dann solche mit über 3000 Bit Länge bringe.

Ein Wechsel auf ein Zertifikat mit längerem Schlüssel ist keine Formsache, sondern hat praktische Auswirkungen auf die Performance des Servers: Die benötigte Rechenzeit steigt mit der Schlüssellänge signifikant an. Webserver bauen viele Verbindungen immer wieder neu auf, bei der die Signaturen jeweils neu mit dem größeren Aufwand der längeren Schlüssel erstellt werden müssen. Für Clients wie Webbrowser ist das kein Problem, Server dürfte das jedoch signifikant belasten, weil sich bei ihnen die Arbeit für viele Clients sammelt. Auch das Risiko für DDoS-Attacken dürfte durch längere Schlüssel steigen.

Ob es sich nun um eine Empfehlung oder in der Praxis nicht doch um eine knallharte Anforderung handelt, bleibt Auslegungssache. Der Sprecher des BSI erläutert dazu: "Für TLS folgt die Verbindlichkeit der Empfehlungen der TR-02102 aus dem Mindeststandard TLS, sofern dieser (für den Betreiber des Servers) verpflichtend ist." Und weiter: "Die Technische Richtlinie TR-02102 spricht Empfehlungen für einen Zeitraum von 7 Jahren aus. Aktuell sind 2048 Bit RSA-Schlüssel noch nicht als unsicher anzusehen. Aus konservativer Sicht werden diese aber bereits jetzt nicht mehr empfohlen. Daher sollte aus Sicht des BSI frühzeitig auf ausreichend lange Schlüssel umgestellt werden."

Wichtig zur Einordnung ist, die Aufgabe von RSA im TLS-Verfahren zu verstehen: Das RSA-Schlüsselpaar kommt während des Verbindungsaufbaus zum Einsatz und hat als Signaturverfahren die Aufgabe, den Server gegenüber dem Client auszuweisen. Die Inhalte selbst werden nicht mit RSA verschlüsselt – selbst wenn RSA mit 2048 Bit in sieben oder zehn Jahren gebrochen wäre, könnte damit niemand heute aufgezeichneten verschlüsselten Verkehr entschlüsseln. Ein Signaturverfahren für TLS muss maximal so lange sicher sein, wie das Zertifikat gültig ist – in der Regel ein Jahr.

Lesen Sie dazu auch:

Von gebrochenem RSA mit 2048 Bit sind Angreifer heute noch sehr entfernt: Die aktuell längste faktorisierte RSA-Zahl ist 829 Bit lang (RSA-250), wofür 2020 etwa 2700 CPU-Jahre draufgingen; Ende 2019 gelang Forschern das Zerlegen von 795-Bit-RSA-Schlüsseln (RSA-240). Zehn Jahre davor gelang das mit 768-Bit langen RSA-Schlüsseln. Behauptungen, dass RSA durch Quantencomputer praktisch bereits zerstört sei, riefen Anfang vergangenen Jahres starke Zweifel von Kryptografie-Experten hervor. Durch die exponentielle Rechenzeitsteigerung bezüglich der Schlüssellänge sind nach derzeitige Lage 1024-Bit- und 2048-Bit-RSA-Schlüssel noch sehr weit davon entfernt, als unsicher zu gelten.

Auch international sind 2048 Bit bis heute Standard, auch Amazon und Microsoft nutzen ein Zertifikat mit 2048 Bit Schlüssellänge und das BSI ist in jedem Fall strenger als andere Organisationen. Das US-amerikanische NIST, das immerhin Verschlüsselungsstandards normiert und dementsprechend auf viele Kryptografie-Experten zugreifen kann, hat eigene Empfehlungen zu Schlüssellängen im September 2023 in einen Entwurf gegossen. Deren Experten sehen RSA ab 2048 Bit Schlüssellänge noch bis zum Jahr 2030 als ausreichend sicher für Signaturen an, wie auf Seite 7 des Dokuments nachzulesen ist. Die Standardisierungsbehörde der USA legt in den FIPS-Dokumenten fest, welche Anforderungen US-Behörden erfüllen müssen.

(dmk)