BSI-TR-02102-4

BSI-TR-02102-4 - Technische Richtlinie des BSI mit Empfehlungen zum Einsatz von Secure Shell (SSH)

Beschreibung

Secure Shell (SSH) kann einen sicheren Kanal durch ein unsicheres Netzwerk herstellen
Anwendungen

Anmelden auf einem entfernten System (remote command-line login)
Ausführen von Befehlen bzw. Applikationen auf entfernten Systemen

Abgrenzung

BSI-TR-02102-4 enthält Empfehlungen

für die zu verwendende Protokollversion
die kryptographischen Algorithmen
als Konkretisierung der allgemeinen Empfehlungen in Teil 1 dieser Technischen Richtlinie (siehe [TR-02102-1]).

Keine Empfehlungen für

konkrete Anwendungen
keine Risikobewertungen
keine Angriffsmöglichkeiten, die sich aus Fehlern in der Implementierung des Protokolls ergeben

Hinweis

Auch bei Beachtung aller Empfehlungen für die Verwendung von SSH können Daten in erheblichem Umfang aus einem kryptographischen System abfließen, zum Beispiel durch Ausnutzung von Seitenkanälen (Messung von Timing-Verhalten, Stromaufnahme, Datenraten etc.).

Daher sollte der Entwickler unter Hinzuziehung von Experten auf diesem Gebiet mögliche Seitenkanäle identifizieren und entsprechende Gegenmaßnahmen umsetzen.
Je nach Anwendung gilt dies auch für Fault-Attacken.

Hinweis: Definitionen kryptographischer Begriffe siehe Glossar in [TR-02102-1]

SSH-Protokolle

Protokoll	RFC	Beschreibung
Transport Layer Protocol	4253	Serverauthentisierung, Verschlüsselung, Integritätssicherung und optional Datenkompression, setzt auf dem TCP/IP-Protokoll auf.
User Authentication Protocol	4252	Benutzer gegenüber dem Server authentisieren, setzt auf dem Transport Layer Protocol auf.
Connection Protocol	4254	Erzeugung und Verwaltung logischer Kanäle innerhalb des verschlüsselten Tunnels, setzt auf dem User Authentication Protocol auf.

Für weitergehende Informationen über die Protokollarchitektur von SSH siehe [RFC 4251].

Empfehlungen

Empfehlungen für die Verwendung des SSH-Protokolls

Kryptografische Verfahren
SSH-Version

Verwendungszeiträume

Kennzeichnung	Beschreibung
Jahreszahl	Verfahren wird bis zum Ende des angegebenen Jahres empfohlen
+	Zeitraum könnte in einer zukünftigen Version der Richtlinie verlängert werden

Sicherheitsniveau

Das Sicherheitsniveau für alle kryptographischen Verfahren in dieser Technischen Richtlinie richtet sich nach dem in Abschnitt 1.1 in [TR-02102-1] angegebenen Sicherheitsniveau und liegt bei 120 Bit.

Als Übergangsregelung ist abweichend davon die Verwendung von RSA-basierten Signatur- und Verschlüsselungsverfahren mit einer Schlüssellänge ab 2000 Bit für das gesamte Jahr 2023 aber weiter konform zu dieser Technischen Richtlinie.
Siehe dazu auch Abschnitt 1.1 in TR-02102-1.

SSH-Versionen

Im Jahr 1995 wurde die erste Version des SSH-Protokolls von Tatu Ylönen, einem Forscher an der Helsinki University of Technology, entwickelt.

Diese Version wird heute SSH-1 genannt.
Im Jahr 2006 wurde eine überarbeitete Version des Protokolls als Internet Standard (RFC) durch die IETF verabschiedet; diese Version heißt SSH-2.

Empfehlungen zur SSH-Protokollversion

Die Verwendung von SSH-2 wird empfohlen
Der Einsatz von SSH-1 wird nicht empfohlen, da diese Protokollversion kryptografische Schwächen enthält.

Konformität zur SSH-Spezifikation

Die Spezifikation des SSH-Protokolls enthält kryptografische Algorithmen, die von standardkonformen Anwendungen unterstützt werden müssen

In der vorliegenden Technischen Richtlinie werden davon möglicherweise nicht alle empfohlen.
Der Grund dafür ist, dass die SSH-Spezifikation (siehe Liste der RFCs in Kapitel 2) im Wesentlichen aus dem Jahr 2006 stammt und daher mittlerweile einige Verfahren aus dieser Spezifikation veraltet sind oder möglicherweise keine ausreichende Sicherheit mehr bieten.

Wenn eine Anwendung vollständig konform zur SSH-Spezifikation sein muss, dann sollte wie folgt vorgegangen werden

Die Anwendung sollte die im vorliegenden Dokument empfohlenen Algorithmen und die in der Spezifikation festgelegten Verfahren unterstützen, aber so konfiguriert sein, dass die hier empfohlenen (kryptographisch starken) Algorithmen mit hoher Priorität und die (möglicherweise kryptographisch schwachen oder veralteten) Algorithmen aus der SSH-Spezifikation mit niedriger Priorität bzw. nach Möglichkeit nicht verwendet werden.

Schlüsseleinigung

Im Rahmen des SSH-Verbindungsaufbaus wird ein Schlüsselaustausch (Key Exchange) durchgeführt, um gemeinsame Sitzungsschlüssel für die Authentisierung und die Verschlüsselung zu erzeugen und auszutauschen.

Empfohlene Key Exchange Methods

Nr	Verfahren	Spezifikation	Verwendung
1	diffie-hellman-group-exchange-	Abschnitt 4.2 in [RFC4419]	2029+sha256
2	diffie-hellman-group14-sha256	Kapitel 3 in [RFC8268]	2022
3	diffie-hellman-group15-sha512	Kapitel 3 in [RFC8268]	2029+
4	diffie-hellman-group16-sha512	Kapitel 3 in [RFC8268]	2029+
5	rsa2048-sha256	Kapitel 4 und 6 in [RFC4432]	2022
6	ecdh-sha2-*	Abschnitt 6.3 in [RFC5656]	2029+

Bemerkung zu Key Exchange Method Nr. 1

Unter Verwendung der Bezeichnungen aus Kapitel 3 in [RFC4419]:

Die Länge der Primzahl p soll mindestens 3000 Bit betragen (siehe dazu auch Abschnitt 8.2.1 in [TR-02102-1] sowie [RFC8270]).
Die Ordnung des Erzeugers g soll mindestens 2250 groß sein (siehe dazu auch Abschnitt 8.2.1 in [TR- 02102-1]).
Gemäß Kapitel 3 in [RFC4419] soll p eine Safe Prime sein, das heißt mit p=2 q+ 1 sind sowohl p als auch q prim.

Da p eine Safe Prime ist, gilt p−1=2q , das heißt die Ordnung des Erzeugers g kann nur 2 oder q sein.

Beachtet man die Empfehlung in Punkt 2, so bleibt nur q als mögliche Ordnung übrig.

Aufgrund der zusätzlichen Forderung in Punkt 3 (Safe Prime) ist die Bitlänge von q viel größer als in Punkt 2 mindestens empfohlen wird.

Dieser Umstand ist zu akzeptieren, wenn die Implementierung konform zu [RFC4419], [TR-02102-1] und der vorliegenden Technischen Richtlinie sein soll.

Hinweis: Bei dieser Key Exchange Method muss SHA-256 auch für die key derivation pseudo-random function (PRF) verwendet werden.

Bemerkung zu Key Exchange Method Nr. 6: Das „*“-Zeichen wird ersetzt durch den Bezeichner einer elliptischen Kurve aus Abschnitt 10.1 in [RFC5656].

Zurzeit werden die folgenden elliptischen Kurven empfohlen:

nistp256, nistp384, nistp521

Die zugehörige Hashfunktion aus der SHA-2-Familie muss in Abhängigkeit der Bitlänge der Kurve gemäß Abschnitt 6.2.1 in [RFC5656] gewählt werden.

Key Re-Exchange

Es ist sinnvoll, das Schlüsselmaterial einer Verbindung nach einer bestimmten Zeit oder einer bestimmten Menge übertragener Daten zu erneuern, um einen Angriff auf die Sitzungsschlüssel zu erschweren.

Bei SSH kann das Erneuern der Sitzungsschlüssel durch das Senden der Nachricht SSH_MSG_KEXINIT erreicht werden.
Sowohl Client als auch Server können diesen Vorgang initiieren.

Es wird empfohlen, ein Key Re-Exchange gemäß Kapitel 9 in [RFC4253] durchzuführen, das heißt die Sitzungsschlüssel werden nach einer Stunde oder nach der Übertragung von einem Gigabyte (je nachdem, was zuerst eintritt) erneuert.

Verschlüsselungsalgorithmen

Während des Key Exchange einigen sich Client und Server auf einen Verschlüsselungsalgorithmus sowie einen gemeinsamen Verschlüsselungsschlüssel.

Empfohlene Verschlüsselungsverfahren

Nr	Verfahren	Spezifikation	Verwendung
1	AEAD_AES_128_GCM	Abschnitt 6.1 in [RFC5647]	2029+
2	AEAD_AES_256_GCM	Abschnitt 6.2 in [RFC5647]	2029+
3	aes256-cbc	Abschnitt 6.3 in [RFC4253]	2023
4	aes192-cbc	Abschnitt 6.3 in [RFC4253]	2023
5	aes128-cbc	Abschnitt 6.3 in [RFC4253]	2023
6	aes128-ctr	Abschnitt 4 in [RFC4344]	2029+
7	aes192-ctr	Abschnitt 4 in [RFC4344]	2029+
8	aes256-ctr	Abschnitt 4 in [RFC4344]	2029+

Hinweis: Bei den Verfahren Nr. 1 und Nr. 2 ist durch den GCM-Modus schon eine MAC-Sicherung enthalten.

Bemerkung: Wenn möglich, sollten die Verfahren Nr. 1 und 2 aus obiger Tabelle eingesetzt werden, da es für den GCM-Modus beweisbare Sicherheitsaussagen bzgl. des Sicherheitsziels Authentisierte Verschlüsselung gibt.

Für die Verfahren Nr. 3 bis 8 sind vergleichbare Sicherheitsgarantien nicht verfügbar, weil SSH die Verschlüsselung und Authentisierung im Encrypt-and-MAC-Modus (statt der beweisbar sicheren Encrypt-then-MAC-Reihenfolge) kombiniert.

MAC-Sicherung

Empfohlene Verfahren zur MAC-Sicherung

Nr	Verfahren	Spezifikation	Verwendung
1	hmac-sha2-256	Kapitel 2 in [RFC6668]	2029+
2	hmac-sha2-512	Kapitel 2 in [RFC6668]	2029+

Server-Authentisierung

Der Server authentisiert sich gegenüber dem Client

Transport Layer Protocol

In Kapitel 7 von [RFC4253] wird dazu die Explicit Server Authentication beschrieben.

Dabei enthalten die Key Exchange-Nachrichten eine digitale Signatur des Servers (oder einen anderen Nachweis), um dessen Authentizität zu beweisen.
Der Client kann die Signatur mit dem Public Key des Servers überprüfen und somit die Authentizität des Servers feststellen.

Die Algorithmen für digitale Signaturen werden in [RFC4253] „Public Key Algorithms“ genannt (vgl. Abschnitt 6.6 in [RFC4253]).

Empfohlene Verfahren für die Server-Authentisierung

Nr	Verfahren	Spezifikation	Schlüssellänge	Verwendung
1	pgp-sign-dss2	Abschnitt 6.6 in [RFC4253], Abschnitte 9.1 und 9.4 in [RFC4880]	2000Bit/250Bit 3000Bit/250Bit	2022 2029+
2	ecdsa-sha2-*	Kapitel 3 in [RFC5656]	250 Bit	2029+
3	x509v3-ecdsa-sha2-*	Abschnitt 3.4 in [RFC6187]	250 Bit	2029+

Bemerkung: Die Verfahren ssh-dss, ssh-rsa (vgl. Abschnitt 6.6 in [RFC4253]) sowie x509v3-ssh-dss, x509v3-ssh-rsa (vgl. Abschnitte 3.1 und 3.2 in [RFC6187]) verwenden bei der Signaturerstellung die Hashfunktion SHA-1 und werden daher nicht empfohlen 1. Da die beiden erstgenannten Verfahren gemäß [RFC4253] erforderlich bzw. empfohlen sind, sei hier auf den Hinweis in Abschnitt 3.2.1 verwiesen.

Bemerkung zu den Verfahren Nr.2-3: Das „*“-Zeichen wird ersetzt durch den Bezeichner einer elliptischen Kurve aus Abschnitt 10.1 in [RFC5656].

Zurzeit werden die folgenden elliptischen Kurven empfohlen:

nistp256, nistp384, nistp521

Die zugehörige Hashfunktion aus der SHA-2-Familie muss in Abhängigkeit der Bitlänge der Kurve gemäß Abschnitt 6.2.1 in [RFC5656] gewählt werden. Für die Authentisierung innerhalb von Projekten des Bundes sind die Vorgaben der Technischen Richtlinie [TR-03116-4] in der jeweils aktuellen Fassung zu beachten.

Client-Authentication

Client-Authentisierung findet mit dem User Authentication Protocol

setzt auf Transport Layer Protocol auf

Verfahren für die Client-Authentisierung

Public key authentication
Password authentication
Host-based authentication

Empfehlung

Für die Client-Authentisierung wird die „Public key authentication“ zusammen mit einem der Verfahren aus Tabelle 4, Abschnitt 3.6 empfohlen.

Anmerkung

Die Public key authentication muss gemäß [RFC4252] von jeder SSH-Implementierung unterstützt werden.
Der dazugehörige Authentication Method Name gemäß [RFC4250], Abschnitt 4.8 lautet „publickey“.
Die Authentisierungs-Methode wird in Kapitel 7 von [RFC4252] beschrieben.

Für die Authentisierung innerhalb von Projekten des Bundes sind die Vorgaben der Technischen Richtlinie [TR-03116-4] in der jeweils aktuellen Fassung zu beachten.

Schlüssel und Zufallszahlen

Schlüsselspeicherung

Private kryptographische Schlüssel, insbesondere statische Schlüssel und Signaturschlüssel, müssen sicher gespeichert und verarbeitet werden.

Dies bedeutet u. a. den Schutz vor Kopieren, missbräuchlicher Nutzung und Manipulation der Schlüssel.
Eine sichere Schlüsselspeicherung kann z. B. durch die Verwendung entsprechend zertifizierter Hardware (Chipkarte, HSM) gewährleistet werden.

Ebenso müssen die öffentlichen Schlüssel von als vertrauenswürdig erkannten Stellen (Vertrauensanker) manipulationssicher gespeichert werden.

Umgang mit Ephemer-Schlüsseln

Wenn eine SSH-Verbindung durch ein Verschlüsselungsverfahren gesichert ist, muss sichergestellt werden, dass alle Ephemer-Schlüssel nach ihrer Verwendung unwiderruflich gelöscht werden, und keine Kopien dieser Schlüssel erzeugt wurden.

Ephemer- bzw. Sitzungsschlüssel dürfen nur für eine Verbindung benutzt werden und sollten grundsätzlich nicht persistent abgespeichert werden.

Zufallszahlen

Für die Erzeugung von Zufallszahlen, z. B. für kryptographische Schlüssel oder die Signaturerzeugung, müssen geeignete Zufallszahlengeneratoren eingesetzt werden. Empfohlen wird ein Zufallszahlengenerator aus einer der Klassen DRG.3, DRG.4, PTG.3 oder NTG.1 gemäß [AIS20/31], vgl. auch Kapitel 10 in Teil 1 dieser Technischen Richtlinie.

Anhang

Siehe auch

Sicherheit

Dokumentation

Spezifikation SSH-2-Protokolls

RFC 4250: The Secure Shell (SSH) Protocol Assigned Numbers (Januar 2006)
RFC 4251: The Secure Shell (SSH) Protocol Architecture (Januar 2006)
RFC 4252: The Secure Shell (SSH) Authentication Protocol (Januar 2006)
RFC 4253: The Secure Shell (SSH) Transport Layer Protocol (Januar 2006)
RFC 4254: The Secure Shell (SSH) Connection Protocol (Januar 2006)
RFC 4256: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) (Januar 2006)
RFC 4335: The Secure Shell (SSH) Session Channel Break Extension (Januar 2006)
RFC 4344: The Secure Shell (SSH) Transport Layer Encryption Modes (Januar 2006)

Erweiterungen und Ergänzungen des SSH-Protokolls

RFC 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints (Januar 2006)
RFC 4419: Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol (März 2006)
RFC 4432: RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol (März 2006)
RFC 4462: Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (Mai 2006)
RFC 4716: The Secure Shell (SSH) Public Key File Format (November 2006)
RFC 4819: Secure Shell Public Key Subsystem (März 2007)
RFC 5647: AES Galois Counter Mode for the Secure Shell Transport Layer Protocol (August 2009)
RFC 5656: Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (Dezember 2009)
RFC 6187: X.509v3 Certificates for Secure Shell Authentication (März 2011)
RFC 6239: Suite B Cryptographic Suites for Secure Shell (SSH) (Mai 2011)
RFC 6594: Use of the SHA-256 Algorithm with RSA: Digital Signature Algorithm (DSA): and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records (April 2012)
RFC 6668: SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (Juli 2012)
RFC 8268: More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) (Dezember 2017)
RFC 8270: Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits (Dezember 2017)

Links

Projekt

Weblinks

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-4.pdf?__blob=publicationFile&v=5