5. Datenstrukturen und Berechnungen
Dieser Abschnitt spezifiziert die Datenstrukturen und Berechnungen, die von den in den vorangegangenen drei Abschnitten spezifizierten ECC-basierten Schlüsselmechanismen verwendet werden. Die hier verwendete Darstellungssprache ist dieselbe wie in TLS. Da diese Spezifikation TLS erweitert, sollten diese Beschreibungen mit denen der TLS-Spezifikation und aller anderen, die TLS erweitern, zusammengeführt werden. Dies bedeutet, dass enum-Typen möglicherweise nicht alle möglichen Werte angeben und Strukturen mit mehreren Formaten, die durch eine select()-Klausel ausgewählt werden, möglicherweise nicht alle möglichen Fälle anzeigen.
5.1. Client Hello Erweiterungen
Dieser Abschnitt spezifiziert zwei TLS-Erweiterungen, die wie in [RFC4366] beschrieben in die ClientHello-Nachricht aufgenommen werden können: die Supported Elliptic Curves Extension und die Supported Point Formats Extension.
Wann diese Erweiterungen gesendet werden:
Die Erweiterungen SOLLTEN (SHOULD) zusammen mit jeder ClientHello-Nachricht gesendet werden, die ECC-Cipher-Suites vorschlägt.
Bedeutung dieser Erweiterungen:
Diese Erweiterungen ermöglichen es einem Client, die von ihm unterstützten elliptischen Kurven und/oder die Punktformate, die er parsen kann, aufzuzählen.
Struktur dieser Erweiterungen:
Die allgemeine Struktur von TLS-Erweiterungen ist in [RFC4366] beschrieben, und diese Spezifikation fügt ExtensionType zwei Typen hinzu.
enum {
elliptic_curves(10),
ec_point_formats(11)
} ExtensionType;
-
elliptic_curves (Supported Elliptic Curves Extension): Gibt die Menge der vom Client unterstützten elliptischen Kurven an. Für diese Erweiterung enthält das undurchsichtige extension_data-Feld eine NamedCurveList. Siehe Abschnitt 5.1.1 für Details.
-
ec_point_formats (Supported Point Formats Extension): Gibt die Menge der Punktformate an, die der Client parsen kann. Für diese Erweiterung enthält das undurchsichtige extension_data-Feld eine ECPointFormatList. Siehe Abschnitt 5.1.2 für Details.
Aktionen des Absenders:
Ein Client, der ECC-Cipher-Suites in seiner ClientHello-Nachricht vorschlägt, fügt diese Erweiterungen an (zusammen mit anderen), in denen er die von ihm unterstützten Kurven und die Punktformate, die er parsen kann, aufzählt. Clients SOLLTEN (SHOULD) sowohl die Supported Elliptic Curves Extension als auch die Supported Point Formats Extension senden. Wenn die Supported Point Formats Extension tatsächlich gesendet wird, MUSS sie den Wert 0 (unkomprimiert) als einen der Elemente in der Liste der Punktformate enthalten.
Aktionen des Empfängers:
Ein Server, der ein ClientHello empfängt, das eine oder beide dieser Erweiterungen enthält, MUSS die aufgezählten Fähigkeiten des Clients verwenden, um seine Auswahl einer geeigneten Cipher Suite zu leiten. Eine der vorgeschlagenen ECC-Cipher-Suites darf nur ausgehandelt werden, wenn der Server den Handshake erfolgreich unter Verwendung der vom Client unterstützten Kurven und Punktformate abschließen kann (vgl. Abschnitte 5.3 und 5.4).
HINWEIS: Ein Server, der an einem ECDHE_ECDSA-Schlüsselaustausch teilnimmt, kann unterschiedliche Kurven für den ECDSA- oder EdDSA-Schlüssel in seinem Zertifikat und für den ephemeren ECDH-Schlüssel in der ServerKeyExchange-Nachricht verwenden. Der Server MUSS die Erweiterungen in beiden Fällen berücksichtigen.
Wenn ein Server die Supported Elliptic Curves Extension nicht versteht, die Supported Point Formats Extension nicht versteht oder den ECC-Handshake nicht abschließen kann, während er sich auf die aufgezählten Kurven und Punktformate beschränkt, DARF er die Verwendung einer ECC-Cipher-Suite NICHT aushandeln (MUST NOT). Abhängig von den anderen vom Client vorgeschlagenen und vom Server unterstützten Cipher Suites kann dies zu einem fatalen Handshake-Failure-Alert aufgrund fehlender gemeinsamer Cipher Suites führen.
5.1.1. Supported Elliptic Curves Extension
RFC 4492 definierte 25 verschiedene Kurven im NamedCurve-Register (jetzt umbenannt in Register "TLS Supported Groups", obwohl die Aufzählung unten immer noch NamedCurve heißt) zur Verwendung in TLS. Nur drei wurden häufig verwendet. Diese Spezifikation erklärt den Rest (mit den Nummern 1-22) für veraltet (deprecating). Diese Spezifikation erklärt auch die expliziten Kurven mit den Bezeichnern 0xFF01 und 0xFF02 für veraltet. Sie fügt auch die neuen Kurven hinzu, die in [RFC7748] definiert sind. Das Endergebnis ist wie folgt:
enum {
deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25),
x25519(29), x448(30),
reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02),
(0xFFFF)
} NamedCurve;
Beachten Sie, dass andere Spezifikationen seitdem weitere Werte zu dieser Aufzählung hinzugefügt haben. Einige dieser Werte sind überhaupt keine Kurven, sondern Finite-Field-Gruppen. Siehe [RFC7919].
secp256r1, etc: Zeigt Unterstützung für die entsprechende benannte Kurve oder Gruppe an. Die benannten Kurven secp256r1, secp384r1 und secp521r1 sind in SEC 2 [SECG-SEC2] spezifiziert. Diese Kurven werden auch in ANSI X9.62 [ANSI.X9-62.2005] und FIPS 186-4 [FIPS.186-4] empfohlen. Der Rest dieses Dokuments bezeichnet diese drei Kurven als die "NIST-Kurven", da sie ursprünglich vom National Institute of Standards and Technology standardisiert wurden. Die Kurven x25519 und x448 sind in [RFC7748] definiert. Werte 0xFE00 bis 0xFEFF sind für den privaten Gebrauch reserviert.
Der Vorgänger dieses Dokuments unterstützte auch explizit definierte Prim- und char2-Kurven, aber diese werden durch diese Spezifikation für veraltet erklärt.
Der NamedCurve-Namensraum (jetzt betitelt "TLS Supported Groups") wird von der IANA verwaltet. Siehe Abschnitt 9 für Informationen darüber, wie neue Wertzuweisungen hinzugefügt werden.
struct {
NamedCurve named_curve_list<2..2^16-1>
} NamedCurveList;
Die Elemente in named_curve_list sind nach der Präferenz des Clients geordnet (bevorzugte Wahl zuerst).
Als Beispiel würde ein Client, der nur secp256r1 (alias NIST P-256; Wert 23 = 0x0017) und secp384r1 (alias NIST P-384; Wert 24 = 0x0018) unterstützt und die Verwendung von secp256r1 bevorzugt, eine TLS-Erweiterung aufnehmen, die aus den folgenden Oktetten besteht. Beachten Sie, dass die ersten beiden Oktette den Erweiterungstyp (Supported Elliptic Curves Extension) angeben:
00 0A 00 06 00 04 00 17 00 18
5.1.2. Supported Point Formats Extension
enum {
uncompressed (0),
deprecated (1..2),
reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
Drei Punktformate waren in der obigen Definition von ECPointFormat enthalten. Diese Spezifikation erklärt alles außer dem unkomprimierten Punktformat für veraltet. Implementierungen dieses Dokuments MÜSSEN das unkomprimierte Format für alle ihre unterstützten Kurven unterstützen und DÜRFEN KEINE anderen Formate für die in dieser Spezifikation definierten Kurven unterstützen (MUST NOT). Aus Gründen der Abwärtskompatibilität DARF die Punktformatlisten-Erweiterung immer noch enthalten sein und genau einen Wert enthalten: das unkomprimierte Punktformat (0). RFC 4492 spezifizierte, dass das Fehlen dieser Erweiterung bedeutet, dass nur das unkomprimierte Punktformat unterstützt wird, so dass die Interoperabilität mit Implementierungen, die das unkomprimierte Format unterstützen, mit oder ohne die Erweiterung funktionieren sollte.
Wenn der Client die Erweiterung sendet und die Erweiterung nicht das unkomprimierte Punktformat enthält, und der Client die Supported Groups Extension verwendet hat, um Unterstützung für eine der in dieser Spezifikation definierten Kurven anzuzeigen, dann MUSS der Server den Handshake abbrechen und einen illegal_parameter Alert zurückgeben.
Der ECPointFormat-Namensraum (jetzt betitelt "TLS EC Point Formats") wird von der IANA verwaltet. Siehe Abschnitt 9 für Informationen darüber, wie neue Wertzuweisungen hinzugefügt werden.
Ein Client, der dieser Spezifikation entspricht und keine anderen Kurven unterstützt, MUSS die folgenden Oktette senden; beachten Sie, dass die ersten beiden Oktette den Erweiterungstyp (Supported Point Formats Extension) angeben:
00 0B 00 02 01 00
5.1.3. Die signature_algorithms Erweiterung und EdDSA
Die signature_algorithms-Erweiterung, definiert in Abschnitt 7.4.1.4.1 von [RFC5246], kündigt die Kombinationen von Signaturalgorithmus und Hashfunktion an, die der Client unterstützt. Die reinen (nicht-prehashed) Formen von EdDSA hashen Daten nicht vor dem Signieren. Aus diesem Grund macht es keinen Sinn, sie in der Erweiterung mit einer Hashfunktion zu kombinieren.
Für die Bit-Kompatibilität mit TLS 1.3 definieren wir einen neuen Dummy-Wert im "TLS HashAlgorithm"-Register, den wir "Intrinsic" (Wert 8) nennen, was bedeutet, dass das Hashing im Signaturalgorithmus inhärent ist.
Um ed25519 und ed448 in der signature_algorithms-Erweiterung darzustellen, sollte der Wert (8,7) bzw. (8,8) sein.
5.2. Server Hello Erweiterung
Dieser Abschnitt spezifiziert eine TLS-Erweiterung, die wie in [RFC4366] beschrieben in die ServerHello-Nachricht aufgenommen werden kann, die Supported Point Formats Extension.
Wann diese Erweiterung gesendet wird:
Die Supported Point Formats Extension wird in eine ServerHello-Nachricht als Reaktion auf eine ClientHello-Nachricht aufgenommen, die die Supported Point Formats Extension enthält, wenn eine ECC-Cipher-Suite ausgehandelt wird.
Bedeutung dieser Erweiterung:
Diese Erweiterung ermöglicht es einem Server, die Punktformate aufzuzählen, die er parsen kann (für die Kurve, die in seiner ServerKeyExchange-Nachricht erscheint, wenn der ECDHE_ECDSA-, ECDHE_RSA- oder ECDH_anon-Schlüsselaustauschalgorithmus verwendet wird).
Struktur dieser Erweiterung:
Die Supported Point Formats Extension des Servers hat dieselbe Struktur wie die Supported Point Formats Extension des Clients (siehe Abschnitt 5.1.2). Die Elemente in ec_point_format_list sind hier nach der Serverpräferenz geordnet (bevorzugte Wahl zuerst). Beachten Sie, dass der Server Elemente aufnehmen KANN (MAY), die nicht in der Liste des Clients gefunden wurden. Ohne Erweiterungen erlaubt diese Spezifikation jedoch genau ein Punktformat, so dass es keine wirkliche Möglichkeit für Diskrepanzen gibt.
Aktionen des Absenders:
Ein Server, der eine ECC-Cipher-Suite als Reaktion auf eine ClientHello-Nachricht auswählt, die eine Supported Point Formats Extension enthält, hängt diese Erweiterung (zusammen mit anderen) an seine ServerHello-Nachricht an und zählt die Punktformate auf, die er parsen kann. Die Supported Point Formats Extension MUSS bei Verwendung den Wert 0 (unkomprimiert) als einen der Elemente in der Liste der Punktformate enthalten.
Aktionen des Empfängers:
Ein Client, der eine ServerHello-Nachricht empfängt, die eine Supported Point Formats Extension enthält, MUSS die Wahl der Punktformate des Servers während des Handshakes respektieren (vgl. Abschnitte 5.6 und 5.7). Wenn keine Supported Point Formats Extension mit dem ServerHello empfangen wird, entspricht dies einer Erweiterung, die nur das unkomprimierte Punktformat erlaubt.
5.3. Server Certificate
Wann diese Nachricht gesendet wird:
Diese Nachricht wird bei allen nicht-anonymen, ECC-basierten Schlüsselaustauschalgorithmen gesendet.
Bedeutung dieser Nachricht:
Diese Nachricht wird verwendet, um den statischen öffentlichen Schlüssel des Servers authentisch an den Client zu übermitteln. Die folgende Tabelle zeigt den Serverzertifikatstyp, der für jeden Schlüsselaustauschalgorithmus geeignet ist. ECC-öffentliche Schlüssel MÜSSEN in Zertifikaten wie in Abschnitt 5.9 beschrieben kodiert werden.
HINWEIS: Die Server Certificate Nachricht kann eine Kette von Zertifikaten transportieren. Die in Tabelle 2 erwähnten Einschränkungen gelten nur für das Zertifikat des Servers (das erste in der Kette).
| Algorithmus | Server-Zertifikatstyp |
|---|---|
| ECDHE_ECDSA | Das Zertifikat MUSS einen zu ECDSA oder EdDSA fähigen öffentlichen Schlüssel enthalten. |
| ECDHE_RSA | Das Zertifikat MUSS einen öffentlichen RSA-Schlüssel enthalten. |
Tabelle 2: Server-Zertifikatstypen
Struktur dieser Nachricht:
Identisch mit dem TLS Certificate Format.
Aktionen des Absenders:
Der Server erstellt eine geeignete Zertifikatskette und übermittelt sie dem Client in der Certificate-Nachricht. Wenn der Client eine Supported Elliptic Curves Extension verwendet hat, MUSS der öffentliche Schlüssel im Zertifikat des Servers die Elliptische-Kurven-Wahl des Clients respektieren. Ein Server, der diese Anforderung nicht erfüllen kann, DARF KEINE ECC-Cipher-Suite in seiner ServerHello-Nachricht wählen (MUST NOT).
Aktionen des Empfängers:
Der Client validiert die Zertifikatskette, extrahiert den öffentlichen Schlüssel des Servers und prüft, ob der Schlüsseltyp für den ausgehandelten Schlüsselaustauschalgorithmus geeignet ist. (Ein möglicher Grund für einen fatalen Handshake-Fehler ist, dass die Fähigkeiten des Clients zur Verarbeitung von elliptischen Kurven und Punktformaten überschritten werden; vgl. Abschnitt 5.1.)
5.4. Server Key Exchange
Wann diese Nachricht gesendet wird:
Diese Nachricht wird bei Verwendung der Algorithmen ECDHE_ECDSA, ECDHE_RSA und ECDH_anon gesendet.
Bedeutung dieser Nachricht:
Diese Nachricht wird verwendet, um den ephemeren öffentlichen ECDH-Schlüssel des Servers (und die entsprechenden Elliptische-Kurven-Domainparameter) an den Client zu übermitteln.
Das ECCurveType-Enum hatte Werte für explizite Prim- und explizite char2-Kurven. Diese Werte sind jetzt veraltet, so dass nur noch ein Wert übrig bleibt:
Struktur dieser Nachricht:
enum {
deprecated (1..2),
named_curve (3),
reserved(248..255)
} ECCurveType;
Der Wert named_curve zeigt an, dass eine benannte Kurve verwendet wird. Diese Option ist nun das einzige verbleibende Format.
Werte 248 bis 255 sind für den privaten Gebrauch reserviert.
Der ECCurveType-Namensraum (jetzt betitelt "TLS EC Curve Types") wird von der IANA verwaltet. Siehe Abschnitt 9 für Informationen darüber, wie neue Wertzuweisungen hinzugefügt werden.
RFC 4492 hatte eine Spezifikation für eine ECCurve-Struktur und eine ECBasisType-Struktur. Beide werden nun weggelassen, da sie nur mit den jetzt veralteten expliziten Kurven verwendet wurden.
struct {
opaque point <1..2^8-1>;
} ECPoint;
point: Dies ist die Byte-String-Repräsentation eines Punktes auf einer elliptischen Kurve gemäß der Konvertierungsroutine in Abschnitt 4.3.6 von [ANSI.X9-62.2005]. Dieser Byte-String kann einen Punkt auf einer elliptischen Kurve im unkomprimierten, komprimierten oder hybriden Format darstellen, aber diese Spezifikation erklärt alles außer dem unkomprimierten Format für veraltet. Für die NIST-Kurven wird das Format der Bequemlichkeit halber in Abschnitt 5.4.1 wiederholt. Für X25519- und X448-Kurven ist die einzige gültige Darstellung die in [RFC7748] spezifizierte, d.h. eine 32- oder 56-Oktett-Darstellung des u-Wertes des Punktes. Diese Struktur DARF NICHT mit öffentlichen Schlüsseln von Ed25519 und Ed448 verwendet werden (MUST NOT).
struct {
ECCurveType curve_type;
select (curve_type) {
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
curve_type: Dies identifiziert den Typ der Elliptische-Kurven-Domainparameter.
namedCurve: Spezifiziert einen empfohlenen Satz von Elliptische-Kurven-Domainparametern. Alle NamedCurve-Werte, die sich auf eine Kurve beziehen, die Diffie-Hellman fähig ist, sind erlaubt. Mit der Veralterung expliziter Kurven umfasst dies nun alle NamedCurve-Werte.
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
curve_params: Spezifiziert die Elliptische-Kurven-Domainparameter, die mit dem öffentlichen ECDH-Schlüssel verbunden sind.
public: Der ephemere öffentliche ECDH-Schlüssel.
Die ServerKeyExchange-Nachricht wird wie folgt erweitert.
enum {
ec_diffie_hellman
} KeyExchangeAlgorithm;
- ec_diffie_hellman: Zeigt an, dass die ServerKeyExchange-Nachricht einen öffentlichen ECDH-Schlüssel enthält.
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
-
params: Spezifiziert den öffentlichen ECDH-Schlüssel und die zugehörigen Domainparameter.
-
signed_params: Ein Hash der params, auf den eine für diesen Hash geeignete Signatur angewendet wird. Der private Schlüssel, der dem zertifizierten öffentlichen Schlüssel in der Server Certificate Nachricht entspricht, wird zum Signieren verwendet.
enum {
ecdsa(3),
ed25519(7)
ed448(8)
} SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
case ed25519,ed448:
digitally-signed struct {
opaque rawdata[rawdata_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
ServerKeyExchange.signed_params.rawdata
ClientHello.random + ServerHello.random +
ServerKeyExchange.params;
HINWEIS: SignatureAlgorithm ist "rsa" für den ECDHE_RSA-Schlüsselaustauschalgorithmus und "anonymous" für ECDH_anon. Diese Fälle sind in TLS definiert. SignatureAlgorithm ist "ecdsa" oder "eddsa" für ECDHE_ECDSA.
ECDSA-Signaturen werden wie in Abschnitt 5.10 beschrieben generiert und verifiziert. SHA, in der obigen Vorlage für sha_hash, kann einen anderen Hash-Algorithmus als SHA-1 bezeichnen. Gemäß ANSI X9.62 besteht eine ECDSA-Signatur aus einem Paar von ganzen Zahlen, r und s. Das digital signierte Element wird als ein undurchsichtiger Vektor <0..2^16-1> kodiert, dessen Inhalt die DER-Kodierung entsprechend der folgenden ASN.1-Notation ist.
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
EdDSA-Signaturen sowohl im Protokoll als auch in Zertifikaten, die [RFC8410] entsprechen, werden gemäß [RFC8032] generiert und verifiziert. Das digital signierte Element wird als ein undurchsichtiger Vektor <0..2^16-1> kodiert, dessen Inhalt die Oktett-String-Ausgabe des EdDSA-Signaturalgorithmus enthält.
Aktionen des Absenders:
Der Server wählt Elliptische-Kurven-Domainparameter und einen ephemeren öffentlichen ECDH-Schlüssel, der diesen Parametern entspricht, gemäß dem ECKAS-DH1-Schema von IEEE 1363 [IEEE.P1363]. Er übermittelt diese Informationen an den Client in der ServerKeyExchange-Nachricht unter Verwendung des oben definierten Formats.
Aktionen des Empfängers:
Der Client verifiziert die Signatur (falls vorhanden) und ruft die Elliptische-Kurven-Domainparameter und den ephemeren öffentlichen ECDH-Schlüssel des Servers aus der ServerKeyExchange-Nachricht ab. (Ein möglicher Grund für einen fatalen Handshake-Fehler ist, dass die Fähigkeiten des Clients zur Verarbeitung von elliptischen Kurven und Punktformaten überschritten werden; vgl. Abschnitt 5.1.)
5.4.1. Unkomprimiertes Punktformat für NIST-Kurven
Das Folgende stellt das Wire-Format zur Darstellung von ECPoint in ServerKeyExchange-Datensätzen dar. Das erste Oktett der Darstellung zeigt die Form an, die komprimiert, unkomprimiert oder hybrid sein kann. Diese Spezifikation unterstützt nur das unkomprimierte Format für diese Kurven. Diesem folgt die binäre Darstellung des X-Wertes im "Big-Endian"- oder "Netzwerk"-Format, gefolgt von der binären Darstellung des Y-Wertes im "Big-Endian"- oder "Netzwerk"-Format. Es gibt keine internen Längenmarkierungen, so dass jede Zahlendarstellung die Anzahl der Oktette belegt, die durch die Kurvenparameter impliziert wird. Für P-256 bedeutet dies, dass X und Y jeweils 32 Oktette belegen, bei Bedarf links mit Nullen aufgefüllt. Für P-384 belegen sie jeweils 48 Oktette und für P-521 jeweils 66 Oktette.
Hier ist eine formalere Darstellung:
enum {
uncompressed(4),
(255)
} PointConversionForm;
struct {
PointConversionForm form;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
5.5. Zertifikatsanforderung
Wann diese Nachricht gesendet wird:
Diese Nachricht wird gesendet, wenn eine Client-Authentifizierung angefordert wird.
Bedeutung dieser Nachricht:
Der Server verwendet diese Nachricht, um akzeptable Client-Authentifizierungsmethoden vorzuschlagen.
Struktur dieser Nachricht:
Die TLS CertificateRequest Nachricht wird wie folgt erweitert.
enum {
ecdsa_sign(64),
deprecated1(65), /* was rsa_fixed_ecdh */
deprecated2(66), /* was ecdsa_fixed_ecdh */
(255)
} ClientCertificateType;
- ecdsa_sign: Zeigt an, dass der Server die entsprechende in Abschnitt 3 spezifizierte Client-Authentifizierungsmethode verwenden möchte.
Beachten Sie, dass RFC 4492 auch RSA- und ECDSA-Zertifikate definierte, die einen festen öffentlichen ECDH-Schlüssel enthielten. Diese Mechanismen wurden sehr wenig implementiert, weshalb diese Spezifikation sie für veraltet erklärt.
Aktionen des Absenders:
Der Server entscheidet, welche Client-Authentifizierungsmethoden er verwenden möchte, und übermittelt diese Informationen an den Client unter Verwendung des oben definierten Formats.
Aktionen des Empfängers:
Der Client bestimmt, ob er ein geeignetes Zertifikat für eine der angeforderten Methoden besitzt und ob er mit der Client-Authentifizierung fortfahren soll.
5.6. Client Certificate
Wann diese Nachricht gesendet wird:
Diese Nachricht wird als Antwort auf eine CertificateRequest gesendet, wenn ein Client ein geeignetes Zertifikat besitzt und beschlossen hat, mit der Client-Authentifizierung fortzufahren. (Beachten Sie, dass, wenn der Server eine Supported Point Formats Extension verwendet hat, ein Zertifikat nur dann als geeignet für die Verwendung mit der ECDSA_sign-Authentifizierungsmethode angesehen werden kann, wenn der darin angegebene öffentliche Schlüsselpunkt unkomprimiert ist, da dies das einzige noch unterstützte Punktformat ist.
Bedeutung dieser Nachricht:
Diese Nachricht wird verwendet, um den statischen öffentlichen Schlüssel des Clients authentisch an den Server zu übermitteln. ECC-öffentliche Schlüssel müssen in Zertifikaten wie in Abschnitt 5.9 beschrieben kodiert werden. Das Zertifikat MUSS einen zu ECDSA oder EdDSA fähigen öffentlichen Schlüssel enthalten.
HINWEIS: Die Client Certificate Nachricht kann eine Kette von Zertifikaten transportieren. Die oben genannten Einschränkungen gelten nur für das Zertifikat des Clients (das erste in der Kette).
Struktur dieser Nachricht:
Identisch mit dem TLS Client Certificate Format.
Aktionen des Absenders:
Der Client erstellt eine geeignete Zertifikatskette und übermittelt sie dem Server in der Certificate-Nachricht.
Aktionen des Empfängers:
Der TLS-Server validiert die Zertifikatskette, extrahiert den öffentlichen Schlüssel des Clients und prüft, ob der Schlüsseltyp für die Client-Authentifizierungsmethode geeignet ist.
5.7. Client Key Exchange
Wann diese Nachricht gesendet wird:
Diese Nachricht wird bei allen Schlüsselaustauschalgorithmen gesendet. Sie enthält den ephemeren öffentlichen ECDH-Schlüssel des Clients.
Bedeutung dieser Nachricht:
Diese Nachricht wird verwendet, um ephemere Daten in Bezug auf den Schlüsselaustausch zu übermitteln, die dem Client gehören (wie sein ephemerer öffentlicher ECDH-Schlüssel).
Struktur dieser Nachricht:
Die TLS ClientKeyExchange Nachricht wird wie folgt erweitert.
enum {
implicit,
explicit
} PublicValueEncoding;
- implicit, explicit: Für ECC-Cipher-Suites zeigt dies an, ob der öffentliche ECDH-Schlüssel des Clients im Client-Zertifikat enthalten ist ("implicit") oder als ephemerer öffentlicher ECDH-Schlüssel in der ClientKeyExchange-Nachricht bereitgestellt wird ("explicit"). Die implizite Kodierung ist veraltet und wird hier nur aus Gründen der Abwärtskompatibilität beibehalten.
struct {
ECPoint ecdh_Yc;
} ClientECDiffieHellmanPublic;
ecdh_Yc: Enthält den ephemeren öffentlichen ECDH-Schlüssel des Clients als Byte-String ECPoint.point, der einen elliptischen Kurvenpunkt im unkomprimierten Format darstellen kann.
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Aktionen des Absenders:
Der Client wählt einen ephemeren öffentlichen ECDH-Schlüssel aus, der den Parametern entspricht, die er vom Server empfangen hat. Das Format ist dasselbe wie in Abschnitt 5.4.
Aktionen des Empfängers:
Der Server ruft den ephemeren öffentlichen ECDH-Schlüssel des Clients aus der ClientKeyExchange-Nachricht ab und prüft, ob er sich auf derselben elliptischen Kurve wie der ECDH-Schlüssel des Servers befindet.
5.8. Certificate Verify
Wann diese Nachricht gesendet wird:
Diese Nachricht wird gesendet, wenn der Client ein Client-Zertifikat sendet, das einen für digitale Signaturen verwendbaren öffentlichen Schlüssel enthält.
Bedeutung dieser Nachricht:
Diese Nachricht enthält eine Signatur, die den Besitz des privaten Schlüssels nachweist, der dem öffentlichen Schlüssel in der Certificate-Nachricht des Clients entspricht.
Struktur dieser Nachricht:
Die TLS CertificateVerify Nachricht und der zugrundeliegende Signaturtyp sind in den TLS-Basisspezifikationen definiert, wobei letztere hier in Abschnitt 5.4 erweitert wird. Für die Fälle "ecdsa" und "eddsa" enthält das Signaturfeld in der CertificateVerify-Nachricht eine ECDSA- bzw. EdDSA-Signatur, die über alle bisher ausgetauschten Handshake-Nachrichten berechnet wurde, genau wie bei CertificateVerify mit anderen Signaturalgorithmen:
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
CertificateVerify.signature.rawdata
handshake_messages;
ECDSA-Signaturen werden wie in Abschnitt 5.10 beschrieben berechnet, und SHA in der obigen Vorlage für sha_hash kann entsprechend einen anderen Hash-Algorithmus als SHA-1 bezeichnen. Gemäß ANSI X9.62 besteht eine ECDSA-Signatur aus einem Paar von ganzen Zahlen, r und s. Das digital signierte Element wird als ein undurchsichtiger Vektor <0..2^16-1> kodiert, dessen Inhalt die DER-Kodierung [X.690] ist, die der folgenden ASN.1-Notation entspricht [X.680].
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
EdDSA-Signaturen werden gemäß [RFC8032] generiert und verifiziert. Das digital signierte Element wird als ein undurchsichtiger Vektor <0..2^16-1> kodiert, dessen Inhalt die Oktett-String-Ausgabe des EdDSA-Signaturalgorithmus enthält.
Aktionen des Absenders:
Der Client berechnet seine Signatur über alle Handshake-Nachrichten, die seit dem Client Hello gesendet oder empfangen wurden, bis zu dieser Nachricht, aber ohne diese. Er verwendet den privaten Schlüssel, der seinem zertifizierten öffentlichen Schlüssel entspricht, um die Signatur zu berechnen, die im oben definierten Format übermittelt wird.
Aktionen des Empfängers:
Der Server extrahiert die Signatur des Clients aus der CertificateVerify-Nachricht und verifiziert die Signatur unter Verwendung des öffentlichen Schlüssels, den er in der Certificate-Nachricht des Clients empfangen hat.
5.9. Elliptische-Kurven-Zertifikate
X.509-Zertifikate, die ECC-öffentliche Schlüssel enthalten oder mit ECDSA signiert sind, MÜSSEN [RFC3279] oder einem anderen RFC entsprechen, das dieses ersetzt oder erweitert. X.509-Zertifikate, die ECC-öffentliche Schlüssel enthalten oder mit EdDSA signiert sind, MÜSSEN [RFC8410] entsprechen. Clients SOLLTEN (SHOULD) die in ANSI X9.62, FIPS 186-4 und SEC 2 [SECG-SEC2] oder in [RFC8032] empfohlenen Elliptische-Kurven-Domainparameter verwenden.
EdDSA-Schlüssel, die den Ed25519-Algorithmus verwenden, MÜSSEN den ed25519 Signaturalgorithmus verwenden, und Ed448-Schlüssel MÜSSEN den ed448 Signaturalgorithmus verwenden. Dieses Dokument definiert nicht die Verwendung von Ed25519ph- und Ed448ph-Schlüsseln mit TLS. Ed25519-, Ed25519ph-, Ed448- und Ed448ph-Schlüssel DÜRFEN NICHT mit ECDSA verwendet werden (MUST NOT).
5.10. ECDH, ECDSA und RSA Berechnungen
Alle ECDH-Berechnungen für die NIST-Kurven (einschließlich Parameter- und Schlüsselerzeugung sowie Berechnung des gemeinsamen Geheimnisses) werden gemäß [IEEE.P1363] unter Verwendung des ECKAS-DH1-Schemas mit der Identitätsabbildung als Schlüsselableitungsfunktion (KDF) durchgeführt, so dass das Pre-Master-Secret die x-Koordinate des ECDH-Shared-Secret-Elliptische-Kurven-Punktes ist, dargestellt als Oktett-String. Beachten Sie, dass dieser Oktett-String (Z in der IEEE 1363 Terminologie), wie er von FE2OSP (Field Element to Octet String Conversion Primitive) ausgegeben wird, für jedes gegebene Feld eine konstante Länge hat; führende Nullen in diesem Oktett-String DÜRFEN NICHT abgeschnitten werden (MUST NOT).
(Beachten Sie, dass diese Verwendung der Identitäts-KDF eine Formalität ist. Das Gesamtbild ist, dass ECDH mit einer nicht-trivialen KDF verwendet wird, da TLS das Pre-Master-Secret für nichts anderes direkt verwendet, als das Master-Secret zu berechnen. In TLS 1.0 und 1.1 bedeutet dies, dass die auf MD5 und SHA-1 basierende TLS-Pseudozufallsfunktion (PRF) als KDF dient; in TLS 1.2 wird die KDF durch die Cipher Suite bestimmt, und es ist denkbar, dass zukünftige TLS-Versionen oder neue TLS-Erweiterungen, die in Zukunft eingeführt werden, diese Berechnung variieren könnten.)
Ein ECDHE-Schlüsselaustausch mit X25519 (Kurve x25519) läuft wie folgt ab: (1) jede Partei wählt einen geheimen Schlüssel d gleichmäßig zufällig und berechnet den entsprechenden öffentlichen Schlüssel x = X25519(d, G); (2) die Parteien tauschen öffentliche Schlüssel aus und berechnen ein gemeinsames Geheimnis als x_S = X25519(d, x_peer); und (3), wenn eine der Parteien x_S als lauter Nullen erhält, MUSS sie den Handshake abbrechen (wie durch die Definition von X25519 und X448 gefordert). ECDHE für X448 funktioniert ähnlich, wobei X25519 durch X448 und x25519 durch x448 ersetzt wird. Das abgeleitete gemeinsame Geheimnis wird direkt als Pre-Master-Secret verwendet, das immer genau 32 Bytes lang ist, wenn ECDHE mit X25519 verwendet wird, und 56 Bytes, wenn ECDHE mit X448 verwendet wird.
Alle ECDSA-Berechnungen MÜSSEN gemäß ANSI X9.62 oder dessen Nachfolgern durchgeführt werden. Die zu signierenden/verifizierenden Daten werden gehasht, und das Ergebnis wird direkt ohne weiteres Hashing durch den ECDSA-Algorithmus geleitet. Eine sichere Hashfunktion wie SHA-256, SHA-384 oder SHA-512 aus [FIPS.180-4] MUSS verwendet werden.
Alle EdDSA-Berechnungen MÜSSEN gemäß [RFC8032] oder dessen Nachfolgern durchgeführt werden. Die zu signierenden/verifizierenden Daten werden ohne Hashing durch den EdDSA-Algorithmus geleitet (EdDSA leitet die Daten intern durch die "Prehash"-Funktion PH). Der Kontextparameter für Ed448 MUSS auf den leeren String gesetzt werden.
RFC 4492 sah die Standardisierung eines Mechanismus zur Spezifizierung der erforderlichen Hashfunktion im Zertifikat vor, möglicherweise im parameters-Feld des subjectPublicKeyInfo. Eine solche Standardisierung fand nie statt, und folglich wird SHA-1 in TLS 1.1 und früher verwendet (außer für EdDSA, das die Identitätsfunktion verwendet). TLS 1.2 fügte einen SignatureAndHashAlgorithm-Parameter zur DigitallySigned-Struktur hinzu und ermöglichte damit Agilität bei der Auswahl des Signatur-Hashs. EdDSA-Signaturen MÜSSEN einen HashAlgorithm von 8 (Intrinsic) haben.
Alle RSA-Signaturen müssen gemäß Abschnitt 7.2 von [RFC8017] generiert und verifiziert werden.
5.11. Validierung öffentlicher Schlüssel
Bei den NIST-Kurven MUSS jede Partei den öffentlichen Schlüssel validieren, der von ihrem Peer in den ClientKeyExchange- und ServerKeyExchange-Nachrichten gesendet wurde. Eine empfangende Partei MUSS prüfen, ob die x- und y-Parameter aus dem öffentlichen Wert des Peers die Kurvengleichung y^2 = x^3 + ax + b mod p erfüllen. Siehe Abschnitt 2.3 von [Menezes] für Details. Geschieht dies nicht, können Angreifer Informationen über den privaten Schlüssel in einem Ausmaß erhalten, dass sie den gesamten privaten Schlüssel in wenigen Anfragen wiederherstellen können, wenn dieser Schlüssel nicht wirklich ephemer ist.
Bei X25519 und X448 MUSS eine empfangende Partei prüfen, ob das berechnete Pre-Master-Secret der Wert "alles Nullen" ist, und den Handshake abbrechen, wenn dies der Fall ist, wie in Kapitel 6 von [RFC7748] beschrieben.
Ed25519 und Ed448 führen intern eine Validierung des öffentlichen Schlüssels als Teil der Signaturüberprüfung durch.