Passa al contenuto principale

5. Strutture Dati e Calcoli

Questa sezione specifica le strutture dati e i calcoli utilizzati dai meccanismi chiave basati su ECC specificati nelle tre sezioni precedenti. Il linguaggio di presentazione utilizzato qui è lo stesso utilizzato in TLS. Poiché questa specifica estende TLS, queste descrizioni dovrebbero essere unite a quelle nella specifica TLS e in qualsiasi altra che estenda TLS. Ciò significa che i tipi enum potrebbero non specificare tutti i valori possibili e le strutture con formati multipli scelti da una clausola select() potrebbero non indicare tutti i casi possibili.

5.1. Estensioni Client Hello​

Questa sezione specifica due estensioni TLS che possono essere incluse nel messaggio ClientHello come descritto in [RFC4366]: l'estensione Supported Elliptic Curves e l'estensione Supported Point Formats.

Quando vengono inviate queste estensioni:

Le estensioni DOVREBBERO (SHOULD) essere inviate insieme a qualsiasi messaggio ClientHello che propone suite di cifratura ECC.

Significato di queste estensioni:

Queste estensioni consentono a un client di enumerare le curve ellittiche che supporta e/o i formati di punto che può analizzare.

Struttura di queste estensioni:

La struttura generale delle estensioni TLS è descritta in [RFC4366] e questa specifica aggiunge due tipi a ExtensionType.

   enum {
       elliptic_curves(10),
       ec_point_formats(11)
   } ExtensionType;

  • elliptic_curves (Estensione Supported Elliptic Curves): Indica l'insieme di curve ellittiche supportate dal client. Per questa estensione, il campo opaco extension_data contiene una NamedCurveList. Vedere la Sezione 5.1.1 per i dettagli.

  • ec_point_formats (Estensione Supported Point Formats): Indica l'insieme di formati di punto che il client può analizzare. Per questa estensione, il campo opaco extension_data contiene una ECPointFormatList. Vedere la Sezione 5.1.2 per i dettagli.

Azioni del mittente:

Un client che propone suite di cifratura ECC nel suo messaggio ClientHello aggiunge queste estensioni (insieme ad altre eventuali), enumerando le curve che supporta e i formati di punto che può analizzare. I client DOVREBBERO (SHOULD) inviare sia l'estensione Supported Elliptic Curves sia l'estensione Supported Point Formats. Se l'estensione Supported Point Formats viene effettivamente inviata, DEVE (MUST) contenere il valore 0 (non compresso) come uno degli elementi nell'elenco dei formati di punto.

Azioni del destinatario:

Un server che riceve un ClientHello contenente una o entrambe queste estensioni DEVE (MUST) utilizzare le capacità enumerate del client per guidare la sua selezione di una suite di cifratura appropriata. Una delle suite di cifratura ECC proposte deve essere negoziata solo se il server può completare con successo l'handshake utilizzando le curve e i formati di punto supportati dal client (cfr. Sezioni 5.3 e 5.4).

NOTA: Un server che partecipa a uno scambio chiavi ECDHE_ECDSA può utilizzare curve diverse per la chiave ECDSA o EdDSA nel suo certificato e per la chiave ECDH effimera nel messaggio ServerKeyExchange. Il server DEVE (MUST) considerare le estensioni in entrambi i casi.

Se un server non comprende l'estensione Supported Elliptic Curves, non comprende l'estensione Supported Point Formats, o non è in grado di completare l'handshake ECC limitandosi alle curve e ai formati di punto enumerati, NON DEVE (MUST NOT) negoziare l'uso di una suite di cifratura ECC. A seconda delle altre suite di cifratura proposte dal client e supportate dal server, ciò potrebbe comportare un avviso di fallimento fatale dell'handshake a causa della mancanza di suite di cifratura comuni.

5.1.1. Estensione Supported Elliptic Curves​

L'RFC 4492 definiva 25 diverse curve nel registro NamedCurve (ora rinominato registro "TLS Supported Groups", sebbene l'enumerazione seguente sia ancora denominata NamedCurve) per l'uso in TLS. Solo tre hanno visto un uso diffuso. Questa specifica sta deprecando il resto (con i numeri 1-22). Questa specifica sta anche deprecando le curve esplicite con identificatori 0xFF01 e 0xFF02. Aggiunge anche le nuove curve definite in [RFC7748]. Il risultato finale è il seguente:

        enum {
            deprecated(1..22),
            secp256r1 (23), secp384r1 (24), secp521r1 (25),
            x25519(29), x448(30),
            reserved (0xFE00..0xFEFF),
            deprecated(0xFF01..0xFF02),
            (0xFFFF)
        } NamedCurve;

Si noti che altre specifiche hanno poi aggiunto altri valori a questa enumerazione. Alcuni di questi valori non sono affatto curve, ma gruppi di campi finiti. Vedere [RFC7919].

secp256r1, ecc.: Indica il supporto per la corrispondente curva o gruppo denominato. Le curve denominate secp256r1, secp384r1 e secp521r1 sono specificate in SEC 2 [SECG-SEC2]. Queste curve sono raccomandate anche in ANSI X9.62 [ANSI.X9-62.2005] e FIPS 186-4 [FIPS.186-4]. Il resto di questo documento si riferisce a queste tre curve come "Curve NIST" perché sono state originariamente standardizzate dal National Institute of Standards and Technology. Le curve x25519 e x448 sono definite in [RFC7748]. I valori da 0xFE00 a 0xFEFF sono riservati per uso privato.

Il predecessore di questo documento supportava anche curve prime ed esplicite char2, ma queste sono deprecate da questa specifica.

Il namespace NamedCurve (ora intitolato "TLS Supported Groups") è mantenuto dallo IANA. Vedere la Sezione 9 per informazioni su come vengono aggiunte le nuove assegnazioni di valore.

        struct {
            NamedCurve named_curve_list<2..2^16-1>
        } NamedCurveList;

Gli elementi in named_curve_list sono ordinati in base alla preferenza del client (la scelta preferita per prima).

Come esempio, un client che supporta solo secp256r1 (alias NIST P-256; valore 23 = 0x0017) e secp384r1 (alias NIST P-384; valore 24 = 0x0018) e preferisce utilizzare secp256r1 includerebbe un'estensione TLS composta dai seguenti ottetti. Si noti che i primi due ottetti indicano il tipo di estensione (Estensione Supported Elliptic Curves):

        00 0A 00 06 00 04 00 17 00 18

5.1.2. Estensione Supported Point Formats​

        enum {
            uncompressed (0),
            deprecated (1..2),
            reserved (248..255)
        } ECPointFormat;
        struct {
            ECPointFormat ec_point_format_list<1..2^8-1>
        } ECPointFormatList;

Tre formati di punto erano inclusi nella definizione di ECPointFormat sopra. Questa specifica sta deprecando tutto tranne il formato di punto non compresso. Le implementazioni di questo documento DEVONO (MUST) supportare il formato non compresso per tutte le loro curve supportate e NON DEVONO (MUST NOT) supportare altri formati per le curve definite in questa specifica. A fini di retrocompatibilità, l'estensione dell'elenco dei formati di punto PUÒ (MAY) ancora essere inclusa e contenere esattamente un valore: il formato di punto non compresso (0). L'RFC 4492 specificava che se questa estensione mancava, significava che era supportato solo il formato di punto non compresso, quindi l'interoperabilità con le implementazioni che supportano il formato non compresso dovrebbe funzionare con o senza l'estensione.

Se il client invia l'estensione e l'estensione non contiene il formato di punto non compresso, e il client ha utilizzato l'estensione Supported Groups per indicare il supporto per una qualsiasi delle curve definite in questa specifica, allora il server DEVE (MUST) interrompere l'handshake e restituire un avviso illegal_parameter.

Il namespace ECPointFormat (ora intitolato "TLS EC Point Formats") è mantenuto dallo IANA. Vedere la Sezione 9 per informazioni su come vengono aggiunte le nuove assegnazioni di valore.

Un client conforme a questa specifica che non supporta altre curve DEVE (MUST) inviare i seguenti ottetti; si noti che i primi due ottetti indicano il tipo di estensione (Estensione Supported Point Formats):

        00 0B 00 02 01 00

5.1.3. L'estensione signature_algorithms e EdDSA​

L'estensione signature_algorithms, definita nella sezione 7.4.1.4.1 dell' [RFC5246], pubblicizza le combinazioni di algoritmo di firma e funzione hash supportate dal client. Le forme pure (non pre-hashed) di EdDSA non eseguono l'hash dei dati prima della firma. Per questo motivo, non ha senso combinarle con una funzione hash nell'estensione.

Per la compatibilità wire-level con TLS 1.3, definiamo un nuovo valore fittizio nel registro "TLS HashAlgorithm" che chiamiamo "Intrinsic" (valore 8), a significare che l'hashing è intrinseco all'algoritmo di firma.

Per rappresentare ed25519 e ed448 nell'estensione signature_algorithms, il valore dovrebbe essere rispettivamente (8,7) e (8,8).

5.2. Estensione Server Hello​

Questa sezione specifica un'estensione TLS che può essere inclusa nel messaggio ServerHello come descritto in [RFC4366], l'estensione Supported Point Formats.

Quando viene inviata questa estensione:

L'estensione Supported Point Formats è inclusa in un messaggio ServerHello in risposta a un messaggio ClientHello contenente l'estensione Supported Point Formats quando si negozia una suite di cifratura ECC.

Significato di questa estensione:

Questa estensione consente a un server di enumerare i formati di punto che può analizzare (per la curva che apparirà nel suo messaggio ServerKeyExchange quando viene utilizzato l'algoritmo di scambio chiavi ECDHE_ECDSA, ECDHE_RSA o ECDH_anon).

Struttura di questa estensione:

L'estensione Supported Point Formats del server ha la stessa struttura dell'estensione Supported Point Formats del client (vedere Sezione 5.1.2). Gli elementi in ec_point_format_list qui sono ordinati in base alla preferenza del server (scelta preferita per prima). Si noti che il server PUÒ (MAY) includere elementi che non sono stati trovati nell'elenco del client. Tuttavia, senza estensioni, questa specifica consente esattamente un formato di punto, quindi non c'è davvero alcuna opportunità per discrepanze.

Azioni del mittente:

Un server che seleziona una suite di cifratura ECC in risposta a un messaggio ClientHello che include un'estensione Supported Point Formats aggiunge questa estensione (insieme ad altre) al suo messaggio ServerHello, enumerando i formati di punto che può analizzare. L'estensione Supported Point Formats, quando utilizzata, DEVE (MUST) contenere il valore 0 (non compresso) come uno degli elementi nell'elenco dei formati di punto.

Azioni del destinatario:

Un client che riceve un messaggio ServerHello contenente un'estensione Supported Point Formats DEVE (MUST) rispettare la scelta dei formati di punto del server durante l'handshake (cfr. Sezioni 5.6 e 5.7). Se non viene ricevuta alcuna estensione Supported Point Formats con il ServerHello, ciò equivale a un'estensione che consente solo il formato di punto non compresso.

5.3. Certificato Server​

Quando viene inviato questo messaggio:

Questo messaggio viene inviato in tutti gli algoritmi di scambio chiavi basati su ECC non anonimi.

Significato di questo messaggio:

Questo messaggio viene utilizzato per trasmettere in modo autentico la chiave pubblica statica del server al client. La tabella seguente mostra il tipo di certificato server appropriato per ciascun algoritmo di scambio chiavi. Le chiavi pubbliche ECC DEVONO (MUST) essere codificate nei certificati come descritto nella Sezione 5.9.

NOTA: Il messaggio Certificate del server è in grado di trasportare una catena di certificati. Le restrizioni menzionate nella Tabella 2 si applicano solo al certificato del server (il primo nella catena).

AlgoritmoTipo di Certificato Server
ECDHE_ECDSAIl certificato DEVE (MUST) contenere una chiave pubblica in grado di eseguire ECDSA o EdDSA.
ECDHE_RSAIl certificato DEVE (MUST) contenere una chiave pubblica RSA.

Tabella 2: Tipi di Certificati Server

Struttura di questo messaggio:

Identico al formato del certificato TLS.

Azioni del mittente:

Il server costruisce una catena di certificati appropriata e la trasmette al client nel messaggio Certificate. Se il client ha utilizzato un'estensione Supported Elliptic Curves, la chiave pubblica nel certificato del server DEVE (MUST) rispettare la scelta della curva ellittica del client. Un server che non può soddisfare questo requisito NON DEVE (MUST NOT) scegliere una suite di cifratura ECC nel suo messaggio ServerHello.

Azioni del destinatario:

Il client convalida la catena di certificati, estrae la chiave pubblica del server e controlla che il tipo di chiave sia appropriato per l'algoritmo di scambio chiavi negoziato. (Un possibile motivo per un fallimento fatale dell'handshake è che le capacità del client di gestire curve ellittiche e formati di punto sono superate; cfr. Sezione 5.1.)

5.4. Scambio chiavi server​

Quando viene inviato questo messaggio:

Questo messaggio viene inviato quando si utilizzano gli algoritmi di scambio chiavi ECDHE_ECDSA, ECDHE_RSA e ECDH_anon.

Significato di questo messaggio:

Questo messaggio viene utilizzato per trasmettere la chiave pubblica ECDH effimera del server (e i corrispondenti parametri di dominio della curva ellittica) al client.

L'enum ECCurveType aveva valori per curve prime esplicite ed esplicite char2. Tali valori sono ora deprecati, quindi rimane solo un valore:

Struttura di questo messaggio:

        enum {
            deprecated (1..2),
            named_curve (3),
            reserved(248..255)
        } ECCurveType;

Il valore named_curve indica che viene utilizzata una curva denominata. Questa opzione è ora l'unico formato rimanente.

I valori da 248 a 255 sono riservati per uso privato.

Il namespace ECCurveType (ora intitolato "TLS EC Curve Types") è mantenuto dallo IANA. Vedere la Sezione 9 per informazioni su come vengono aggiunte le nuove assegnazioni di valore.

L'RFC 4492 aveva una specifica per una struttura ECCurve e una struttura ECBasisType. Entrambe sono ora omesse, poiché venivano utilizzate solo con le curve esplicite ora deprecate.

        struct {
            opaque point <1..2^8-1>;
        } ECPoint;

point: Questa è la rappresentazione in stringa di byte di un punto della curva ellittica seguendo la routine di conversione nella Sezione 4.3.6 di [ANSI.X9-62.2005]. Questa stringa di byte può rappresentare un punto della curva ellittica in formato non compresso, compresso o ibrido, ma questa specifica depreca tutto tranne il formato non compresso. Per le curve NIST, il formato è ripetuto nella Sezione 5.4.1 per comodità. Per le curve X25519 e X448, l'unica rappresentazione valida è quella specificata in [RFC7748], una rappresentazione di 32 o 56 ottetti del valore u del punto. Questa struttura NON DEVE (MUST NOT) essere utilizzata con chiavi pubbliche Ed25519 e Ed448.

        struct {
            ECCurveType    curve_type;
            select (curve_type) {
                case named_curve:
                    NamedCurve namedcurve;
            };
        } ECParameters;

curve_type: Questo identifica il tipo dei parametri di dominio della curva ellittica.

namedCurve: Specifica un set raccomandato di parametri di dominio della curva ellittica. Sono consentiti tutti i valori NamedCurve che si riferiscono a una curva in grado di eseguire Diffie-Hellman. Con la deprecazione delle curve esplicite, questo ora include tutti i valori NamedCurve.

        struct {
            ECParameters    curve_params;
            ECPoint         public;
        } ServerECDHParams;

curve_params: Specifica i parametri di dominio della curva ellittica associati alla chiave pubblica ECDH.

public: La chiave pubblica ECDH effimera.

Il messaggio ServerKeyExchange è esteso come segue.

        enum {
            ec_diffie_hellman
        } KeyExchangeAlgorithm;
  • ec_diffie_hellman: Indica che il messaggio ServerKeyExchange contiene una chiave pubblica ECDH.
      select (KeyExchangeAlgorithm) {
          case ec_diffie_hellman:
              ServerECDHParams    params;
              Signature           signed_params;
      } ServerKeyExchange;

  • params: Specifica la chiave pubblica ECDH e i parametri di dominio associati.

  • signed_params: Un hash dei parametri, con la firma appropriata a quell'hash applicata. La chiave privata corrispondente alla chiave pubblica certificata nel messaggio Certificate del server viene utilizzata per la firma.

        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;

NOTA: SignatureAlgorithm è "rsa" per l'algoritmo di scambio chiavi ECDHE_RSA e "anonymous" per ECDH_anon. Questi casi sono definiti in TLS. SignatureAlgorithm è "ecdsa" o "eddsa" per ECDHE_ECDSA.

Le firme ECDSA vengono generate e verificate come descritto nella Sezione 5.10. SHA, nel modello sha_hash sopra, può denotare un algoritmo hash diverso da SHA-1. Secondo ANSI X9.62, una firma ECDSA è costituita da una coppia di interi, r ed s. L'elemento firmato digitalmente è codificato come un vettore opaco <0..2^16-1>, il cui contenuto è la codifica DER corrispondente alla seguente notazione ASN.1.

              Ecdsa-Sig-Value ::= SEQUENCE {
                  r       INTEGER,
                  s       INTEGER
              }

Le firme EdDSA sia nel protocollo che nei certificati conformi a [RFC8410] sono generate e verificate secondo [RFC8032]. L'elemento firmato digitalmente è codificato come un vettore opaco <0..2^16-1>, il cui contenuto include l'output della stringa di ottetti dell'algoritmo di firma EdDSA.

Azioni del mittente:

Il server seleziona i parametri di dominio della curva ellittica e una chiave pubblica ECDH effimera corrispondente a questi parametri secondo lo schema ECKAS-DH1 in IEEE 1363 [IEEE.P1363]. Trasmette queste informazioni al client nel messaggio ServerKeyExchange utilizzando il formato definito sopra.

Azioni del destinatario:

Il client verifica la firma (se presente) e recupera i parametri di dominio della curva ellittica del server e la chiave pubblica ECDH effimera dal messaggio ServerKeyExchange. (Un possibile motivo per un fallimento fatale dell'handshake è che le capacità del client di gestire curve ellittiche e formati di punto sono superate; cfr. Sezione 5.1.)

5.4.1. Formato punto non compresso per curve NIST​

Di seguito viene rappresentato il formato wire per rappresentare ECPoint nei record ServerKeyExchange. Il primo ottetto della rappresentazione indica la forma, che può essere compressa, non compressa o ibrida. Questa specifica supporta solo il formato non compresso per queste curve. Questo è seguito dalla rappresentazione binaria del valore X in formato "big-endian" o "network", seguita dalla rappresentazione binaria del valore Y in formato "big-endian" o "network". Non ci sono marcatori di lunghezza interni, quindi ogni rappresentazione numerica occupa il numero di ottetti implicato dai parametri della curva. Per P-256, ciò significa che X e Y utilizzano ciascuno 32 ottetti, riempiti con zeri a sinistra se necessario. Per P-384, occupano 48 ottetti ciascuno e per P-521, occupano 66 ottetti ciascuno.

Ecco una rappresentazione più formale:

             enum {
                 uncompressed(4),
                 (255)
               } PointConversionForm;

             struct {
                 PointConversionForm  form;
                 opaque               X[coordinate_length];
                 opaque               Y[coordinate_length];
             } UncompressedPointRepresentation;

5.5. Richiesta di certificato​

Quando viene inviato questo messaggio:

Questo messaggio viene inviato quando si richiede l'autenticazione del client.

Significato di questo messaggio:

Il server utilizza questo messaggio per suggerire metodi di autenticazione client accettabili.

Struttura di questo messaggio:

Il messaggio TLS CertificateRequest è esteso come segue.

           enum {
               ecdsa_sign(64),
               deprecated1(65),  /* was rsa_fixed_ecdh */
               deprecated2(66),  /* was ecdsa_fixed_ecdh */
               (255)
           } ClientCertificateType;
  • ecdsa_sign: Indica che il server vorrebbe utilizzare il metodo di autenticazione client corrispondente specificato nella Sezione 3.

Si noti che l'RFC 4492 definiva anche certificati RSA ed ECDSA che includevano una chiave pubblica ECDH fissa. Questi meccanismi hanno visto pochissima implementazione, quindi questa specifica li sta deprecando.

Azioni del mittente:

Il server decide quali metodi di autenticazione client desidera utilizzare e trasmette queste informazioni al client utilizzando il formato definito sopra.

Azioni del destinatario:

Il client determina se possiede un certificato adatto per essere utilizzato con uno qualsiasi dei metodi richiesti e se procedere con l'autenticazione del client.

5.6. Certificato Client​

Quando viene inviato questo messaggio:

Questo messaggio viene inviato in risposta a una CertificateRequest quando un client possiede un certificato adatto e ha deciso di procedere con l'autenticazione del client. (Nota che se il server ha utilizzato un'estensione Supported Point Formats, un certificato può essere considerato adatto per l'uso con il metodo di autenticazione ECDSA_sign solo se il punto della chiave pubblica specificato in esso è non compresso, poiché quello è l'unico formato di punto ancora supportato.

Significato di questo messaggio:

Questo messaggio viene utilizzato per trasmettere in modo autentico la chiave pubblica statica del client al server. Le chiavi pubbliche ECC devono essere codificate nei certificati come descritto nella Sezione 5.9. Il certificato DEVE (MUST) contenere una chiave pubblica in grado di eseguire ECDSA o EdDSA.

NOTA: Il messaggio Certificate del client è in grado di trasportare una catena di certificati. Le restrizioni di cui sopra si applicano solo al certificato del client (il primo nella catena).

Struttura di questo messaggio:

Identico al formato del certificato client TLS.

Azioni del mittente:

Il client costruisce una catena di certificati appropriata e la trasmette al server nel messaggio Certificate.

Azioni del destinatario:

Il server TLS convalida la catena di certificati, estrae la chiave pubblica del client e controlla che il tipo di chiave sia appropriato per il metodo di autenticazione del client.

5.7. Scambio chiavi client​

Quando viene inviato questo messaggio:

Questo messaggio viene inviato in tutti gli algoritmi di scambio chiavi. Contiene la chiave pubblica ECDH effimera del client.

Significato di questo messaggio:

Questo messaggio viene utilizzato per trasmettere dati effimeri relativi allo scambio chiavi принадлежащий al client (come la sua chiave pubblica ECDH effimera).

Struttura di questo messaggio:

Il messaggio TLS ClientKeyExchange è esteso come segue.

           enum {
               implicit,
               explicit
           } PublicValueEncoding;
  • implicit, explicit: Per le suite di cifratura ECC, questo indica se la chiave pubblica ECDH del client è nel certificato del client ("implicit") o è fornita, come chiave pubblica ECDH effimera, nel messaggio ClientKeyExchange ("explicit"). La codifica implicita è deprecata e viene mantenuta qui solo per retrocompatibilità.
           struct {
               ECPoint ecdh_Yc;
           } ClientECDiffieHellmanPublic;

ecdh_Yc: Contiene la chiave pubblica ECDH effimera del client come stringa di byte ECPoint.point, che può rappresentare un punto della curva ellittica in formato non compresso.

           struct {
               select (KeyExchangeAlgorithm) {
                   case ec_diffie_hellman: ClientECDiffieHellmanPublic;
               } exchange_keys;
           } ClientKeyExchange;

Azioni del mittente:

Il client seleziona una chiave pubblica ECDH effimera corrispondente ai parametri ricevuti dal server. Il formato è lo stesso della Sezione 5.4.

Azioni del destinatario:

Il server recupera la chiave pubblica ECDH effimera del client dal messaggio ClientKeyExchange e controlla che sia sulla stessa curva ellittica della chiave ECDH del server.

5.8. Verifica certificato​

Quando viene inviato questo messaggio:

Questo messaggio viene inviato quando il client invia un certificato client contenente una chiave pubblica utilizzabile per le firme digitali.

Significato di questo messaggio:

Questo messaggio contiene una firma che dimostra il possesso della chiave privata corrispondente alla chiave pubblica nel messaggio Certificate del client.

Struttura di questo messaggio:

Il messaggio TLS CertificateVerify e il tipo di firma sottostante sono definiti nelle specifiche di base TLS, e quest'ultimo è esteso qui nella Sezione 5.4. Per i casi "ecdsa" e "eddsa", il campo della firma nel messaggio CertificateVerify contiene una firma ECDSA o EdDSA (rispettivamente) calcolata sui messaggi di handshake scambiati finora, esattamente simile a CertificateVerify con altri algoritmi di firma:

           CertificateVerify.signature.sha_hash
               SHA(handshake_messages);
           CertificateVerify.signature.rawdata
               handshake_messages;

Le firme ECDSA vengono calcolate come descritto nella Sezione 5.10 e SHA nel modello sopra per sha_hash può indicare di conseguenza un algoritmo hash diverso da SHA-1. Secondo ANSI X9.62, una firma ECDSA è costituita da una coppia di interi, r ed s. L'elemento firmato digitalmente è codificato come un vettore opaco <0..2^16-1>, il cui contenuto è la codifica DER [X.690] corrispondente alla seguente notazione ASN.1 [X.680].

           Ecdsa-Sig-Value ::= SEQUENCE {
               r       INTEGER,
               s       INTEGER
           }

Le firme EdDSA sono generate e verificate secondo [RFC8032]. L'elemento firmato digitalmente è codificato come un vettore opaco <0..2^16-1>, il cui contenuto include l'output della stringa di ottetti dell'algoritmo di firma EdDSA.

Azioni del mittente:

Il client calcola la sua firma su tutti i messaggi di handshake inviati o ricevuti a partire dal client hello e fino a ma non includendo questo messaggio. Utilizza la chiave privata corrispondente alla sua chiave pubblica certificata per calcolare la firma, che viene trasmessa nel formato definito sopra.

Azioni del destinatario:

Il server estrae la firma del client dal messaggio CertificateVerify e verifica la firma utilizzando la chiave pubblica ricevuta nel messaggio Certificate del client.

5.9. Certificati a curva ellittica​

I certificati X.509 contenenti chiavi pubbliche ECC o firmati utilizzando ECDSA DEVONO (MUST) essere conformi a [RFC3279] o un altro RFC che lo sostituisce o estende. I certificati X.509 contenenti chiavi pubbliche ECC o firmati utilizzando EdDSA DEVONO (MUST) essere conformi a [RFC8410]. I client DOVREBBERO (SHOULD) utilizzare i parametri di dominio della curva ellittica raccomandati in ANSI X9.62, FIPS 186-4 e SEC 2 [SECG-SEC2], o in [RFC8032].

Le chiavi EdDSA che utilizzano l'algoritmo Ed25519 DEVONO (MUST) utilizzare l'algoritmo di firma ed25519 e le chiavi Ed448 DEVONO (MUST) utilizzare l'algoritmo di firma ed448. Questo documento non definisce l'uso di chiavi Ed25519ph e Ed448ph con TLS. Le chiavi Ed25519, Ed25519ph, Ed448 e Ed448ph NON DEVONO (MUST NOT) essere utilizzate con ECDSA.

5.10. Calcoli ECDH, ECDSA e RSA​

Tutti i calcoli ECDH per le curve NIST (inclusa la generazione di parametri e chiavi nonché il calcolo del segreto condiviso) vengono eseguiti secondo [IEEE.P1363] utilizzando lo schema ECKAS-DH1 con la mappa identità come funzione di derivazione della chiave (KDF) in modo che il segreto pre-master sia la coordinata x del punto della curva ellittica del segreto condiviso ECDH rappresentato come una stringa di ottetti. Si noti che questa stringa di ottetti (Z nella terminologia IEEE 1363), come emessa da FE2OSP (Field Element to Octet String Conversion Primitive), ha una lunghezza costante per ogni dato campo; gli zeri iniziali trovati in questa stringa di ottetti NON DEVONO (MUST NOT) essere troncati.

(Si noti che questo uso della KDF identità è una tecnicità. Il quadro completo è che ECDH è impiegato con una KDF non banale perché TLS non utilizza direttamente il segreto pre-master per nient'altro che per calcolare il segreto master. In TLS 1.0 e 1.1, ciò significa che la TLS Pseudo-Random Function (PRF) basata su MD5 e SHA-1 funge da KDF; in TLS 1.2, la KDF è determinata dalla suite di cifratura ed è ipotizzabile che le future versioni TLS o nuove estensioni TLS introdotte in futuro possano variare questo calcolo.)

Uno scambio chiavi ECDHE utilizzando X25519 (curva x25519) è il seguente: (1) ciascuna parte sceglie una chiave segreta d uniformemente a caso e calcola la chiave pubblica corrispondente x = X25519(d, G); (2) le parti scambiano le chiavi pubbliche e calcolano un segreto condiviso come x_S = X25519(d, x_peer); e (3), se una delle parti ottiene x_S tutto zeri, DEVE (MUST) interrompere l'handshake (come richiesto dalla definizione di X25519 e X448). ECDHE per X448 funziona in modo simile, sostituendo X25519 con X448 e x25519 con x448. Il segreto condiviso derivato viene utilizzato direttamente come segreto pre-master, che è sempre esattamente di 32 byte quando si utilizza ECDHE con X25519 e 56 byte quando si utilizza ECDHE con X448.

Tutti i calcoli ECDSA DEVONO (MUST) essere eseguiti secondo ANSI X9.62 o i suoi successori. I dati da firmare/verificare vengono sottoposti a hash e il risultato viene eseguito direttamente attraverso l'algoritmo ECDSA senza hashing aggiuntivo. DEVE (MUST) essere utilizzata una funzione hash sicura come SHA-256, SHA-384 o SHA-512 da [FIPS.180-4].

Tutti i calcoli EdDSA DEVONO (MUST) essere eseguiti secondo [RFC8032] o i suoi successori. I dati da firmare/verificare vengono eseguiti attraverso l'algoritmo EdDSA senza hashing (EdDSA eseguirà internamente i dati attraverso la funzione "prehash" PH). Il parametro di contesto per Ed448 DEVE (MUST) essere impostato sulla stringa vuota.

L'RFC 4492 prevedeva la standardizzazione di un meccanismo per specificare la funzione hash richiesta nel certificato, forse nel campo parameters di subjectPublicKeyInfo. Tale standardizzazione non ha mai avuto luogo e, di conseguenza, SHA-1 viene utilizzato in TLS 1.1 e versioni precedenti (tranne per EdDSA, che utilizza la funzione identità). TLS 1.2 ha aggiunto un parametro SignatureAndHashAlgorithm alla struttura DigitallySigned, consentendo così agilità nella scelta dell'hash della firma. Le firme EdDSA DEVONO (MUST) avere un HashAlgorithm di 8 (Intrinsic).

Tutte le firme RSA devono essere generate e verificate secondo la Sezione 7.2 di [RFC8017].

5.11. Convalida della chiave pubblica​

Con le curve NIST, ciascuna parte DEVE (MUST) convalidare la chiave pubblica inviata dal proprio peer nei messaggi ClientKeyExchange e ServerKeyExchange. Una parte ricevente DEVE (MUST) verificare che i parametri x e y dal valore pubblico del peer soddisfino l'equazione della curva, y^2 = x^3 + ax + b mod p. Vedere la Sezione 2.3 di [Menezes] per i dettagli. La mancata esecuzione di ciò consente agli aggressori di ottenere informazioni sulla chiave privata al punto da poter recuperare l'intera chiave privata in poche richieste se tale chiave non è veramente effimera.

Con X25519 e X448, una parte ricevente DEVE (MUST) verificare se il segreto pre-master calcolato è il valore tutto zeri e interrompere l'handshake in tal caso, come descritto nel capitolo 6 di [RFC7748].

Ed25519 e Ed448 eseguono internamente la convalida della chiave pubblica come parte della verifica della firma.

Ultimo aggiornamento il