TLS - DHE_DSS: In che modo il client riconosce la chiave pubblica del server DSS?

Question

TLS - DHE_DSS: In che modo il client riconosce la chiave pubblica del server DSS?

#1 da (0 voti)

1

Mi chiedo dove la chiave del server pubblico g ^ x per l'autenticazione DSS sia comunicata al client quando viene utilizzata una suite di crittografia DHE_DSS in TLS 1.2. Precisamente:

Un certificato DSS contiene parametri crittografici (p_1, q_1, g_1). Questi valori sono noti al server (mediante l'installazione del certificato) e al client dal messaggio di certificato.

Per l'algoritmo DHE, il server sceglie i parametri di crittografia (p_2, g_2, y_2 = g_2 ^ s). Per l'autenticazione DSS di questi parametri, il server sceglie un valore casuale x e applica l'algoritmo di firma DSA e invia i dati autenticati tramite il messaggio di scambio chiave del server al client.

Per verificare i dati ricevuti, il client ha bisogno della chiave pubblica DSS del server g_1 ^ x. Per quanto posso vedere dalle specifiche TLS 1.2 (RFC5246), questa chiave pubblica DSS non fa parte del messaggio di scambio chiave del server. Quindi:

Domanda: come ottiene il cliente g_1 ^ x?

Nota: Nel link il mio g_1 ^ x è y = g ^ x nel sezione "Tasti per utente". E il messaggio m nella pagina wiki consiste qui dei parametri DHE (p_2, g_2, y_2).

tls diffie-hellman dsa

posta user120513 04.11.2017 - 17:20

fonte

1 risposta

Leggi altre domande sui tag tls diffie-hellman dsa

Interoperabilità di openssl smime, rsautl & dgst Sostituzione dei dati HEX con i filtri ettercap

score 0 · Accepted Answer

Espanso dal commento per la chiusura, anche se francamente mi sembra piuttosto il vecchio poser, "chi è sepolto nella tomba di Grant?"

TLDR: la chiave pubblica (statica) è nel certificato della chiave pubblica

SSL / TLS utilizza certificati X.509 per chiavi pubbliche statiche, o per essere precisi: riferimento SSL X.509v3, uno standard poi pubblicato di recente da quello che allora era CCITT e da allora è diventato ITU-T; le RFC per il riferimento TLK PKIX che è un sottoinsieme (formalmente un profilo) di X.509v3 definito da una serie di RFC attualmente diretti da rfc5280 .

Un certificato X.509 / PKIX contiene informazioni sulla chiave pubblica del soggetto in una struttura dati prosaicamente chiamata SubjectPublicKeyInfo definita in 5280 sezione 4.1 4.1.1.2 e 4.1.2.7 come:

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

che supporta una varietà di algoritmi specificando sia l'algoritmo stesso che i parametri dipendenti dall'algoritmo, così come la chiave pubblica dipendente dall'algoritmo 'wrapped' all'interno di BIT STRING.

SPKI (come chiamo io) è specificato in dettagli per diversi algoritmi, tra cui DSA (DSS impreciso nei nomi ciphersuite e keyexchange di SSL / TLS) in rfc3279 sezione 2.3.2 . La parte "algoritmo" è costituita dall'OID (Object Identifier) per DSA e dai parametri che normalmente consistono in p, q, g come una SEQUENZA ASN.1 di INTEGER - con un'opzione per omettere questi parametri da un certificato se sono "ereditati" dal certificato CA dell'emittente (un'opzione che non ho mai visto utilizzata). La parte "subjectPublicKey" è semplicemente il valore y (= g ^ x mod p) come INTEGER ASN.1 nel wrapper BIT STRING.

La firma DSA (sotto la chiave privata che corrisponde alla chiave pubblica nel cert) sui valori DHE (p, g, y) nel messaggio ServerKeyExchange utilizza un valore 'casuale' convenzionalmente notificato k (non x) per produrre una coppia di interi r, s che vengono trasportati (in ASN.1) nello stesso messaggio ServerKeyExchange. (Tecnicamente k non deve essere casuale a patto che non si ripeta per dati diversi, vedi rfc6979 per un'alternativa deterministica.)