Come viene generato il segreto di Premaster in TLS?

Question

Come viene generato il segreto di Premaster in TLS?

#1 da (8 voti)
#2 da (4 voti)

4

Credo che usi una combinazione dei valori casuali inviati nei messaggi ciao. Da RFC 2246: (TLSv1.0)

 RSA encrypted premaster secret message

   Meaning of this message:
       If RSA is being used for key agreement and authentication, the
       client generates a 48-byte premaster secret, encrypts it using
       the public key from the server's certificate or the temporary RSA
       key provided in a server key exchange message, and sends the
       result in an encrypted premaster secret message. This structure
       is a variant of the client key exchange message, not a message in
       itself.

   Structure of this message:
       struct {
           ProtocolVersion client_version;
           opaque random[46];
       } PreMasterSecret;

       client_version
           The latest (newest) version supported by the client. This is
           used to detect version roll-back attacks. Upon receiving the
           premaster secret, the server should check that this value
           matches the value transmitted by the client in the client
           hello message.

       random
           46 securely-generated random bytes.

In che modo corrisponderà al valore che il cliente ha inviato in precedenza? Qualcuno può spiegare questo per favore? Grazie! C'è qualche API per calcolare questo valore?

client-side encryption tls rsa

posta previouslyactualname 25.07.2014 - 22:00

fonte

2 risposte

4

TLS supporta più schemi di scambio di chiavi e quindi ci possono essere diversi modi per ottenere un segreto pre-master. TLS può utilizzare lo scambio di chiavi basato su RSA che è stato spiegato molto bene nei commenti precedenti, può anche usare DH, DHE, ECDH, ECDHE (diffie-hellman, diffie-hellman con tasti effimeri, curva ellittica diffie-hellman ed ecdh con chiavi effimere rispettivamente).

Nella famiglia di algoritmi DH il segreto premaster viene generato da due gruppi di valori:

Primitive pubbliche scelte dal server
Chiavi private del mittente e del destinatario

Il server condivide le primitive pubbliche che il client usa insieme alla sua chiave privata per trovare un segreto pre-master. In caso di Diffie Hellman è qualcosa del genere:

Primitive pubbliche :

p - a large prime 

g - primitive root modulo p

Chiavi private:

a - client's private key

b - server's private key

Scambio di chiavi:

Server to Client  :  {g, p, (g^b mod p)}

Client Calculates :  (g^b mod p)^a = g^ab mod p

Client to Server  :  (g^a mod p)

Server Calculates :  (g^a mod p)^b = g^ab mod p

Se vedi attentamente, sia il server che il client ora hanno una chiave comune (g ^ ab mod p) che possono utilizzare come pre segreto principale.

Questo pre-segreto può essere inviato a un HKDF per estrarre più chiavi crittograficamente sicure. Queste chiavi possono quindi essere utilizzate come chiavi di crittografia di sessione, chiavi hmac (o IV basate sul codice di crittografia).

Curva ellittica DH invece di usare le primitive come p e g, usa le curve ellittiche denominate.

Per la tua altra domanda,

Is there any API to compute this value?

Se intendevi un valore casuale crittograficamente sicuro, allora sì, ha Python os.urandom (n)

che può essere utilizzato per generare una crittografia di n byte. sicuro valore casuale.

risposta data 03.10.2016 - 03:38

fonte

Leggi altre domande sui tag client-side encryption tls rsa

Segnaposto per cshtml - ASP.NET Crittografia con due chiavi

score 8 · Accepted Answer

Il client genera il segreto premaster a 48 byte concatenando la versione del protocollo (2 byte) e alcuni byte generati casualmente dal client (46 byte). Il client dovrebbe ottenere questi 46 byte da un PRNG protetto da crittografia ; in pratica, questo significa usare il PRNG offerto dal sistema operativo ( /dev/urandom , CryptGenRandom() ...).

Il client quindi crittografa il segreto premaster a 48 byte con la chiave pubblica RSA del server (che il server ha inviato in precedenza al client, nel messaggio Certificate ). Il risultato crittografato è ciò che il client invia al server come messaggio ClientKeyExchange . In virtù di RSA, beh, un algoritmo di crittografia asimmetrica, ciò che il server decrittografa è uguale a ciò che il client ha crittografato.

Il server decodifica il contenuto del messaggio ClientKeyExchange utilizzando la sua chiave RSA privata. A quel punto, sia il client che il server conoscono il segreto premaster. Quindi procedono a utilizzarlo per calcolare il master secret (utilizzando client_random e server_random , scambiati in precedenza nei messaggi ClientHello e ServerHello e mescolando il tutto con il PRF). Dal master secret, utilizzeranno nuovamente alcuni mix PRF per ottenere le chiavi di crittografia effettive per i dati successivi.