Zum Hauptinhalt springen

2. Schlüsselaustauschalgorithmen

Dieses Dokument definiert drei neue ECC-basierte Schlüsselaustauschalgorithmen für TLS. Sie alle verwenden Ephemeral ECDH (ECDHE), um das TLS-Pre-Master-Secret zu berechnen, und sie unterscheiden sich nur in dem Mechanismus (falls vorhanden), der zu ihrer Authentifizierung verwendet wird. Die Ableitung des TLS-Master-Secrets aus dem Pre-Master-Secret und die anschließende Generierung von Bulk-Encryption/MAC-Keys und Initialisierungsvektoren ist unabhängig vom Schlüsselaustauschalgorithmus und wird durch die Einführung von ECC nicht beeinflusst.

Tabelle 1 fasst die neuen Schlüsselaustauschalgorithmen zusammen. Alle diese Schlüsselaustauschalgorithmen bieten Forward Secrecy dann und nur dann, wenn frische ephemere Schlüssel generiert und verwendet werden und nach Gebrauch auch vernichtet werden.

AlgorithmusBeschreibung
ECDHE_ECDSAEphemeres ECDH mit ECDSA- oder EdDSA-Signaturen.
ECDHE_RSAEphemeres ECDH mit RSA-Signaturen.
ECDH_anonAnonymes ephemeres ECDH, keine Signaturen.

Tabelle 1: ECC-Schlüsselaustauschalgorithmen

Diese Schlüsselaustausche sind analog zu DHE_DSS, DHE_RSA bzw. DH_anon.

Mit ECDHE_RSA kann ein Server sein bestehendes RSA-Zertifikat wiederverwenden und die Elliptische-Kurven-Präferenzen eines eingeschränkten Clients leicht erfüllen (siehe Abschnitt 4). Die Rechenkosten, die einem Server bei ECDHE_RSA entstehen, sind jedoch höher als beim herkömmlichen RSA-Schlüsselaustausch, der keine Forward Secrecy bietet.

Der anonyme Schlüsselaustauschalgorithmus bietet weder Server- noch Client-Authentifizierung. Wie andere anonyme TLS-Schlüsselaustausche ist er anfällig für Man-in-the-Middle-Angriffe. Anwendungen, die TLS mit diesem Algorithmus verwenden, SOLLTEN (SHOULD) eine Authentifizierung auf andere Weise bereitstellen.

          Client                                        Server
          ------                                        ------
          ClientHello          -------->
                                                   ServerHello
                                                  Certificate*
                                            ServerKeyExchange*
                                          CertificateRequest*+
                               <--------       ServerHelloDone
          Certificate*+
          ClientKeyExchange
          CertificateVerify*+
          [ChangeCipherSpec]
          Finished             -------->
                                            [ChangeCipherSpec]
                               <--------              Finished
          Application Data     <------->      Application Data

               * Nachricht wird unter bestimmten Bedingungen nicht gesendet
               + Nachricht wird nicht gesendet, es sei denn, Client-
                 Authentifizierung ist gewünscht

Abbildung 1: Nachrichtenfluss in einem vollständigen TLS 1.2 Handshake

Abbildung 1 zeigt alle Nachrichten, die am TLS-Key-Establishment-Protokoll (alias Full Handshake) beteiligt sind. Das Hinzufügen von ECC hat nur direkte Auswirkungen auf das ClientHello, das ServerHello, das Certificate-Nachricht des Servers, das ServerKeyExchange, das ClientKeyExchange, das CertificateRequest, die Certificate-Nachricht des Clients und das CertificateVerify. Im Folgenden beschreiben wir die ECC-Schlüsselaustauschalgorithmen detaillierter hinsichtlich des Inhalts und der Verarbeitung dieser Nachrichten. Um die Darstellung zu erleichtern, verschieben wir die Diskussion der Client-Authentifizierung und der zugehörigen Nachrichten (in Abbildung 1 mit einem '+' gekennzeichnet) auf Abschnitt 3 und der optionalen ECC-spezifischen Erweiterungen (die sich auf Hello-Nachrichten auswirken) auf Abschnitt 4.

2.1. ECDHE_ECDSA​

Bei ECDHE_ECDSA MUSS das Zertifikat des Servers einen zu ECDSA oder EdDSA fähigen öffentlichen Schlüssel enthalten.

Der Server sendet seinen ephemeren öffentlichen ECDH-Schlüssel und eine Spezifikation der entsprechenden Kurve in der ServerKeyExchange-Nachricht. Diese Parameter MÜSSEN mit ECDSA oder EdDSA unter Verwendung des privaten Schlüssels signiert werden, der dem öffentlichen Schlüssel im Zertifikat des Servers entspricht.

Der Client generiert ein ECDH-Schlüsselpaar auf derselben Kurve wie der ephemere ECDH-Schlüssel des Servers und sendet seinen öffentlichen Schlüssel in der ClientKeyExchange-Nachricht.

Sowohl Client als auch Server führen eine ECDH-Operation durch (siehe Abschnitt 5.10) und verwenden das resultierende gemeinsame Geheimnis als Pre-Master-Secret.

2.2. ECDHE_RSA​

Dieser Schlüsselaustauschalgorithmus ist identisch mit ECDHE_ECDSA, außer dass das Zertifikat des Servers einen für die Signierung autorisierten öffentlichen RSA-Schlüssel enthalten MUSS und die Signatur in der ServerKeyExchange-Nachricht mit dem entsprechenden privaten RSA-Schlüssel berechnet werden muss.

2.3. ECDH_anon​

HINWEIS: Obwohl der Name mit "ECDH_" beginnt (kein E), ist der in ECDH_anon verwendete Schlüssel genau wie die Schlüssel in ECDHE_RSA und ECDHE_ECDSA ephemer. Die Benennung folgt dem Beispiel von DH_anon, wo der Schlüssel ebenfalls ephemer ist, der Name dies jedoch nicht widerspiegelt.

Bei ECDH_anon DÜRFEN die Nachrichten Server Certificate, CertificateRequest, Client Certificate und CertificateVerify NICHT gesendet werden (MUST NOT).

Der Server MUSS einen ephemeren öffentlichen ECDH-Schlüssel und eine Spezifikation der entsprechenden Kurve in der ServerKeyExchange-Nachricht senden. Diese Parameter DÜRFEN NICHT signiert werden (MUST NOT).

Der Client generiert ein ECDH-Schlüsselpaar auf derselben Kurve wie der ephemere ECDH-Schlüssel des Servers und sendet seinen öffentlichen Schlüssel in der ClientKeyExchange-Nachricht.

Sowohl Client als auch Server führen eine ECDH-Operation durch und verwenden das resultierende gemeinsame Geheimnis als Pre-Master-Secret. Alle ECDH-Berechnungen werden wie in Abschnitt 5.10 spezifiziert durchgeführt.

2.4. Algorithmen in Zertifikatsketten​

Diese Spezifikation legt keine Einschränkungen für die Signaturschemata fest, die irgendwo in der Zertifikatskette verwendet werden. Die frühere Version dieses Dokuments verlangte, dass die Signaturen übereinstimmen, aber diese Einschränkung, die aus früheren TLS-Versionen stammt, wird hier ebenso aufgehoben wie in RFC 5246.

Letztes Update am