Chiffre-Suite – Wikipedia

EIN Chiffre-Suite ist eine Reihe von Algorithmen, die helfen, eine Netzwerkverbindung zu sichern. Suites verwenden in der Regel Transport Layer Security (TLS) oder seinen inzwischen veralteten Vorgänger Secure Socket Layer (SSL). Zu den Algorithmen, die Cipher Suites normalerweise enthalten, gehören: ein Schlüsselaustauschalgorithmus, ein Massenverschlüsselungsalgorithmus und ein Message Authentication Code (MAC)-Algorithmus.^[1]

Der Schlüsselaustauschalgorithmus wird verwendet, um einen Schlüssel zwischen zwei Geräten auszutauschen. Dieser Schlüssel wird verwendet, um die Nachrichten zu verschlüsseln und zu entschlüsseln, die zwischen zwei Computern gesendet werden. Der Massenverschlüsselungsalgorithmus wird verwendet, um die gesendeten Daten zu verschlüsseln. Der MAC-Algorithmus bietet Datenintegritätsprüfungen, um sicherzustellen, dass sich die gesendeten Daten während der Übertragung nicht ändern. Darüber hinaus können Verschlüsselungssammlungen Signaturen und einen Authentifizierungsalgorithmus enthalten, um die Authentifizierung des Servers und/oder Clients zu unterstützen.

Insgesamt gibt es Hunderte verschiedener Verschlüsselungssammlungen, die verschiedene Kombinationen dieser Algorithmen enthalten. Einige Verschlüsselungssammlungen bieten eine bessere Sicherheit als andere.

Der Aufbau und die Verwendung des Cipher-Suite-Konzepts sind im TLS-Standarddokument definiert.^[2]TLS 1.2 ist die am weitesten verbreitete Version von TLS. Die nächste Version von TLS (TLS 1.3) enthält zusätzliche Anforderungen an Verschlüsselungssammlungen. TLS 1.3 wurde erst vor kurzem standardisiert und ist noch nicht weit verbreitet. Für TLS 1.2 definierte Verschlüsselungssammlungen können nicht in TLS 1.3 verwendet werden und umgekehrt, sofern in ihrer Definition nicht anders angegeben.

Eine Referenzliste benannter Verschlüsselungssammlungen finden Sie in der TLS-Verschlüsselungssuite-Registrierung.^[3]

Geschichte[edit]

Die Verwendung von Chiffren ist seit seiner Entstehung Teil des Secure Socket Layer (SSL)-Transitprotokolls. SSL wurde für die meisten Anwendungen von TLS abgelöst. Allerdings ist der Name Chiffre-Suite wurde im ursprünglichen SSL-Entwurf nicht verwendet. Stattdessen wurde die Möglichkeit für einen Client und einen Server genannt, aus einem kleinen Satz von Verschlüsselungen auszuwählen, um ihre Verbindung zu sichern Chiffre-Wahl.^[4][5] Erst mit SSL v3 (der letzten Version von SSL) wurde der Name Chiffre-Suite wurde benutzt.^[6] Jede Version von TLS hat seitdem verwendet Chiffre-Suite in seiner Standardisierung. Das Konzept und der Zweck von a Chiffre-Suite hat sich seit der ersten Prägung des Begriffs nicht geändert. Es wurde und wird immer noch als Struktur verwendet, die die Algorithmen beschreibt, die eine Maschine unterstützt, damit zwei Maschinen entscheiden können, welche Algorithmen sie verwenden, um ihre Verbindung zu sichern. Was sich geändert hat, sind die Versionen der Algorithmen, die in den Cipher Suites unterstützt werden. Jede Version von TLS hat die Unterstützung für stärkere Versionen der Algorithmen hinzugefügt und die Unterstützung für Versionen der Algorithmen entfernt, die als unsicher identifiziert wurden.

TLS 1.3 markiert eine Änderung in der Koordination von Verschlüsselungssammlungen zwischen Computern. Die für zwei kommunizierende Maschinen gewählte Verschlüsselungssammlung wird durch den Handshake-Prozess bestimmt. In TLS 1.3 wurden Änderungen am Handshake-Prozess vorgenommen, um die Anzahl der zu sendenden Nachrichten zu reduzieren. Dies ermöglicht eine geringere Verarbeitung, weniger Paketverkehr und mehr Effizienz im Vergleich zu früheren TLS-Versionen.

Namensschema[edit]

Jede Verschlüsselungssammlung hat einen eindeutigen Namen, der verwendet wird, um sie zu identifizieren und ihren algorithmischen Inhalt zu beschreiben. Jedes Segment im Namen einer Verschlüsselungssammlung steht für einen anderen Algorithmus oder ein anderes Protokoll. Ein Beispiel für den Namen einer Verschlüsselungssammlung: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Die Bedeutung dieses Namens ist:

• TLS definiert das Protokoll, für das diese Verschlüsselungssammlung bestimmt ist; es wird normalerweise TLS sein.
• ECDHE gibt den verwendeten Schlüsselaustauschalgorithmus an.
• RSA Authentifizierungsmechanismus während des Handshakes.
• AES Sitzungs-Chiffre
• 128 Sitzungsverschlüsselungsschlüsselgröße (Bits) für Verschlüsselung
• GCM Art der Verschlüsselung (Cipher-Block-Abhängigkeit und zusätzliche Optionen)
• SHA (SHA2)Hash-Funktion. Für einen Digest von 256 und höher. Signaturmechanismus. gibt den Nachrichtenauthentifizierungsalgorithmus an, der verwendet wird, um eine Nachricht zu authentifizieren.
• 256 Digest-Größe (Bits).

Voller Handshake: Koordinieren von Verschlüsselungssammlungen[edit]

Um Verschlüsselungssammlungen zu verwenden, müssen sich Client und Server auf die spezifische Verschlüsselungssammlung einigen, die beim Austausch von Nachrichten verwendet werden soll. Sowohl der Client als auch der Server müssen die vereinbarte Verschlüsselungssammlung unterstützen. Wenn Client und Server sich nicht auf eine Verschlüsselungssammlung einigen, wird keine Verbindung hergestellt.^[7] Dieser Auswahlprozess findet während des TLS Handshake Protocol statt. TLS 1.3 enthält ein TLS-Handshake-Protokoll, das sich von der früheren und der aktuellen Version von TLS/SSL unterscheidet.

Nach der Koordinierung der zu verwendenden Verschlüsselungssammlung haben der Server und der Client immer noch die Möglichkeit, die koordinierten Verschlüsselungen mithilfe der CipherSpec ändern Protokoll im aktuellen Handshake oder in einem neuen Handshake.

Um zu testen, welche TLS-Verschlüsselungen ein Server unterstützt, kann ein SSL/TLS-Scanner verwendet werden.[1]

TLS 1.0–1.2 Handshake[edit]

Visuelle Darstellung, wie ein Client und ein Server, die auf TLS 1.2 arbeiten, die zu verwendende Verschlüsselungssammlung koordinieren

Dieser Client startet den Prozess, indem er a KundeHallo Nachricht an den Server, die die verwendete TLS-Version und eine Liste der Verschlüsselungssammlungen in der vom Client bevorzugten Reihenfolge enthält. Als Antwort sendet der Server a serverHallo Nachricht Dazu gehören die ausgewählte Verschlüsselungssammlung und die Sitzungs-ID. Als nächstes sendet der Server ein digitales Zertifikat, um seine Identität an den Client zu überprüfen. Der Server kann bei Bedarf auch die digitale Zertifizierung eines Clients anfordern.

Wenn der Client und der Server keine vorinstallierten Schlüssel verwenden, sendet der Client dann eine verschlüsselte Nachricht an den Server, die es dem Client und dem Server ermöglicht, zu berechnen, welcher geheime Schlüssel während des Austauschs verwendet wird.

Nach erfolgreicher Überprüfung der Authentifizierung des Servers und ggf. Austausch des geheimen Schlüssels sendet der Client eine fertig Nachricht, um zu signalisieren, dass der Handshake-Prozess abgeschlossen ist. Nach Erhalt dieser Nachricht sendet der Server a fertig Nachricht, die bestätigt, dass der Handshake abgeschlossen ist. Jetzt sind sich Client und Server einig, welche Verschlüsselungssammlung sie verwenden sollen, um miteinander zu kommunizieren.

Visuelle Darstellung, wie ein Client und ein Server, die mit TLS 1.3 arbeiten, die zu verwendende Verschlüsselungssammlung koordinieren

TLS 1.3-Handshake[edit]

Wenn zwei Maschinen über TLS 1.3 korrespondieren, koordinieren sie die zu verwendende Verschlüsselungssammlung mithilfe des TLS 1.3-Handshake-Protokolls. Der Handshake in TLS 1.3 wurde im Vergleich zu den zwei Roundtrips, die in früheren Versionen von TLS/SSL erforderlich waren, auf nur einen Roundtrip reduziert.

Zuerst sendet der Client a KundeHallo Nachricht an den Server, die eine Liste der unterstützten Verschlüsselungen in der Reihenfolge der Präferenz des Clients enthält und eine Vermutung über den verwendeten Schlüsselalgorithmus angibt, damit er bei Bedarf einen geheimen Schlüssel zur gemeinsamen Nutzung senden kann.

Durch eine Vermutung, welcher Schlüsselalgorithmus verwendet wird, wird ein Roundtrip eliminiert. Nach Erhalt der KundeHallo, der Server sendet a ServerHallo mit seinem Schlüssel, einem Zertifikat, der gewählten Verschlüsselungssammlung und dem fertig Botschaft.

Nachdem der Client die Server- fertig Nachricht, dass es jetzt mit dem Server koordiniert ist, auf dem die Verschlüsselungssammlung verwendet werden soll.^[8]

Unterstützte Algorithmen[edit]

In TLS 1.0–1.2[edit]

Weitere Informationen zu den in TLS 1.0–1.2 unterstützten Algorithmen finden Sie auch unter: Transport Layer Security § Anwendungen und Einführung

TLS 1.3[edit]

In TLS 1.3 wurden viele Legacyalgorithmen, die in frühen Versionen von TLS unterstützt wurden, entfernt, um das Protokoll sicherer zu machen.^[9] Darüber hinaus werden alle Verschlüsselungs- und Authentifizierungsalgorithmen im Authentifizierten Verschlüsselungsalgorithmus (AEAD) kombiniert. Auch bei der HMAC-basierten Schlüsselableitung (HKDF) muss nun ein Hash-Algorithmus verwendet werden.^[10] Alle Nicht-AEAD-Chiffren wurden aufgrund möglicher Schwächen oder Schwachstellen entfernt und die Chiffren müssen einen kurzlebigen Schlüsselaustauschalgorithmus verwenden, damit für jeden Austausch neue Schlüsselpaare generiert werden.^[11]

DTLS mit Verschlüsselungssammlungen[edit]

Datagram Transport Layer Security (DTLS) basiert auf TLS, wird aber speziell für UDP-Verbindungen anstelle von TCP-Verbindungen verwendet. Da DTLS auf TLS basiert, kann es einen Großteil der für TLS beschriebenen Verschlüsselungssammlungen verwenden. Bei der Verwendung von TLS-Verschlüsselungssammlungen mit DTLS müssen Sonderfälle berücksichtigt werden. DTLS unterstützt die Stream-Chiffre RC4 nicht, was bedeutet, dass keine TLS-Chiffre, die RC4 verwendet, mit DTLS verwendet werden kann.^[12]

Um festzustellen, ob eine TLS-Verschlüsselungssammlung mit DTLS kompatibel ist, hilft es nicht, ihren Namen zu betrachten. Jede TLS-Verschlüsselungssammlung enthält weiterhin den TLS-Kennungsraum in ihrem Namen. z.B: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Stattdessen enthalten jetzt alle TLS-Parameterregister das Flag DTLS-OK um zu signalisieren, ob eine Verschlüsselungssammlung DTLS unterstützt.^[13]

Schwachstellen[edit]

Eine Verschlüsselungssammlung ist so sicher wie die darin enthaltenen Algorithmen. Wenn die Version des Verschlüsselungs- oder Authentifizierungsalgorithmus in einer Verschlüsselungssammlung bekannte Schwachstellen aufweist, können die Verschlüsselungssammlung und die TLS-Verbindung anfällig sein. Daher wird ein häufiger Angriff auf TLS und Verschlüsselungssammlungen als Downgrade-Angriff bezeichnet. Ein Downgrade in TLS tritt auf, wenn ein moderner Client eine Verbindung zu Legacy-Servern herstellt, die ältere Versionen von TLS oder SSL verwenden.

Beim Einleiten eines Handshakes bietet der moderne Client das höchste Protokoll an, das er unterstützt. Wenn die Verbindung fehlschlägt, wird es automatisch erneut mit einem niedrigeren Protokoll wie TLS 1.0 oder SSL 3.0 versucht, bis der Handshake mit dem Server erfolgreich ist. Der Zweck des Downgrades besteht darin, dass neue Versionen von TLS mit älteren Versionen kompatibel sind. Es ist jedoch möglich, dass ein Angreifer diese Funktion ausnutzt und ein Client automatisch auf eine Version von TLS oder SSL herunterschaltet, die Verschlüsselungssammlungen mit Algorithmen unterstützt, die für schwache Sicherheit und Schwachstellen bekannt sind.^[14] Dies hat zu Angriffen wie POODLE geführt.

Eine Möglichkeit, diese Sicherheitslücke zu vermeiden, besteht darin, die Fähigkeit eines Servers oder Clients zu deaktivieren, auf SSL 3.0 herunterzustufen. Der Nachteil dieses Fixes besteht darin, dass auf einige Legacy-Hardware nicht mit neuerer Hardware zugegriffen werden kann. Wenn SSL 3.0-Unterstützung für Legacy-Hardware benötigt wird, gibt es eine genehmigte TLS_FALLBACK_SCSV-Verschlüsselungssammlung, die überprüft, dass Downgrades nicht für böswillige Absichten ausgelöst werden.^[15]

Verschlüsselungssammlungen für eingeschränkte Geräte[edit]

Verschlüsselungs-, Schlüsselaustausch- und Authentifizierungsalgorithmen erfordern normalerweise viel Rechenleistung und Speicher. Um Sicherheit zu bieten eingeschränkte Geräte mit begrenzter Rechenleistung, Speicher und Akkulaufzeit, wie sie das Internet der Dinge antreiben, gibt es speziell ausgewählte Verschlüsselungssammlungen. Zwei Beispiele sind:

1. TLS_PSK_WITH_AES_128_CCM_8 (Geteilter Schlüssel)^[16]
2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (roh Öffentlicher Schlüssel)

Jede dieser Verschlüsselungssammlungen wurde für die Ausführung auf Geräten mit Einschränkungen bei Verarbeitungsleistung und Speicher implementiert. Beide sind im Open-Source-Projekt implementiert TinyDTLS. Der Grund dafür, dass sie mit diesen eingeschränkten Geräten arbeiten können, liegt darin, dass sie leicht implementiert werden können. Implementierungen der Pre-Shared-Key-Verschlüsselungssuite verwendeten nur 1889 Byte RAM und 38266 Flash-ROM, was im Vergleich zu den meisten Verschlüsselungs- und Sicherheitsalgorithmen sehr ressourcenschonend ist.^[17] Diese geringe Speicherauslastung ist darauf zurückzuführen, dass diese Verschlüsselungssammlungen bewährte effiziente Algorithmen verwenden, die sicher sind, aber möglicherweise nicht so sicher wie ressourcenintensivere Algorithmen. exp: Verwendung von 128-Bit-Verschlüsselung vs. 256-Bit-Verschlüsselung. Darüber hinaus verwenden sie Pre-Shared Key oder roh Public Key, der im Vergleich zur Verwendung einer herkömmlichen Public-Key-Infrastruktur (PKIX) weniger Speicherplatz und Rechenleistung benötigt.^[18]

Programmierreferenzen[edit]

In der Programmierung wird auf eine Verschlüsselungssammlung sowohl im Plural als auch im Nicht-Plural Bezug genommen. Jeder hat unterschiedliche Definitionen:

CipherSuite cipher_suites

eine Liste der vom Client unterstützten kryptografischen Optionen.^[19] Ein Beispiel dafür, wie cipher_suites wird normalerweise während des Handshake-Prozesses verwendet:

   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;

CipherSuite cipher_suite

die Verschlüsselungssammlung, die der Server aus dem des Clients ausgewählt hat cipher_suites.^[20] Ein Beispiel dafür, wie chiffre_suite wird normalerweise während des Handshake-Prozesses verwendet:

      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;

Siehe auch[edit]

Verweise[edit]