TLS 1.2 Handshake: come viene firmata la chiave pubblica ECDHE dal server?

Question

TLS 1.2 Handshake: come viene firmata la chiave pubblica ECDHE dal server?

#1 da (4 voti)

1

Ho a che fare con una situazione in cui un'opzione di cifratura, come ECDHE-ECDSA-AES128-SHA , viene scelta per stabilire una connessione TLS. In questo caso, un server, quando invia il messaggio ServerKeyExchange al client, è tenuto a firmare la chiave diffie hellman effimera (EC) utilizzando la sua chiave privata ECDSA (associata al certificato della chiave pubblica). La chiave pubblica viene prima sottoposta a hash prima che un'operazione di segno ECDSA possa essere una prestazione.

La mia domanda: come viene determinato l'algoritmo di hashing durante l'handshake?

L'RFC 4492 che descrive l'applicazione di ECC a TLS 1.2 presenta il seguente testo per indicare come viene determinato questo algoritmo:

"“All ECDSA computations MUST be performed according to ANSI X9.62 [7] or its successors. Data to be signed/verified is hashed, and the
result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [10], and sha_size (see Sections 5.4 and 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [10], may be used instead if the certificate containing the EC public key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)”

Tuttavia, se ci si riferisce ai requisiti NIST Suite-B per TLS 1.2 (RFC 5430), è chiaro sull'uso di SHA256 e SHA384 per il livello di sicurezza desiderato (poiché SHA1 è deprecato dal NIST).

Quindi, nell'handshake TLS, come si specifica l'uso di SHA256 nella procedura di firma sopra?

Grazie,

Hari Tadepalli

hash tls key-exchange

posta user13311 23.01.2015 - 18:16

fonte

1 risposta

Leggi altre domande sui tag hash tls key-exchange

Cyber Security Training v. Cyber Security Education per studenti di livello medio-alto [chiuso] I certificati revocati possono essere "persi" se il CRL di base viene aggiornato prima della scadenza?

score 4 · Answer 1

RFC 4492 specifica ECC per TLS1.0 e TLS1.1. Non copre TLS1.2 perché è stato scritto prima di TLS1.2; nota che 4492 è inferiore a 5246. RFC 5246 TLS1.2 modifica la struttura delle firme per tutti gli algoritmi di firma incluso ECDSA e aggiunge anche un'estensione Hello per negoziare gli algoritmi di firma supportati (incluso l'hash) in modo più flessibile.

RFC 5246 A.7 Modifiche a RFC 4492

RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section.

This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to
digital signatures formed using ECDSA as well, thus allowing ECDSA
signatures to be used with digest algorithms other than SHA-1,
provided such use is compatible with the certificate and any
restrictions imposed by future revisions of [PKIX].

As described in Sections 7.4.2 and 7.4.6, the restrictions on the
signature algorithms used to sign certificates are no longer tied to
the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document,
the restrictions on the keys in the end-entity certificate remain.

In particolare RFC 5246 4.7 Attributi crittografici

A digitally-signed element is encoded as a struct DigitallySigned:
  struct {
     SignatureAndHashAlgorithm algorithm;
     opaque signature<0..2^16-1>;
  } DigitallySigned;
The algorithm field specifies the algorithm used (see Section
7.4.1.4.1 for the definition of this field). Note that the
introduction of the algorithm field is a change from previous
versions. .... RSA .... DSA ....

Punti aggiuntivi:

il server firma la sua chiave pubblica ECDHE e la curva (che in pratica, soprattutto per la Suite B, è denominata forma piuttosto che esplicita, quindi piuttosto piccola) (modifica, grazie David) così come i nonces, con almeno il nonce del client che prova freschezza
I requisiti della suite B sono impostati dalla NSA e non dal NIST. IIRC Suite B richiesto SHA256 e SHA384 prima NIST "deprecato" SHA1.
La RFC 5430 era obsoleta da RFC 6460 che richiede TLS1.2 e GCM e ECDHE-ECDSA.