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
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)