Il segreto pre-master è crittografato e scambiato nell'handshake TLS. Questo valore viene utilizzato per derivare la chiave principale. La chiave master viene utilizzata per ricavare tutti gli altri materiali per la trasparenza passandoli in una funzione pseudo-casuale (PRF) e combinando altri dati dall'handshake.
Derivazione del segreto pre-master per un PSK
Da RFC427: Sezione 2
The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself.
Se utilizzi Diffie Hellman w / PSK, Sezione 3 :
The premaster secret is formed as follows. First, perform the Diffie-Hellman computation in the same way as for other Diffie-Hellman-based ciphersuites in [TLS]. Let Z be the value produced by this computation (with leading zero bytes stripped as in other Diffie-Hellman-based ciphersuites). Concatenate a uint16 containing the length of Z (in octets), Z itself, a uint16 containing the length of the PSK (in octets), and the PSK itself.
Se utilizzi RSA w / PSK, Sezione 4
The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [TLS]. The actual premaster secret is formed by both parties as follows: concatenate a uint16 with the value 48, the 2-byte version number and the 46-byte random value, a uint16 containing the length of the PSK (in octets), and the PSK itself. (The premaster secret is thus 52 octets longer than the PSK.)
Chiave master derivante
Tutto ciò che segue non solo si applica a TLS PSK; si applica a tutti i tipi di scambio di chiavi. Da RFC 2246: Sezione 8.1
For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed. The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
Il PRF è definito come combinazione di due diverse funzioni di hashing. Sezione 5 di RFC 2246:
First, we define a data expansion function, P_hash(secret, data) which uses a single hash function to expand a secret and seed into an arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...
Where + indicates concatenation.
A() is defined as:
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
La funzione sopra descritta è in realtà P_MD5 o P_SHA1 . Il PRS TLS è descritto come segue:
TLS's PRF is created by splitting the secret into two halves and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1, then exclusive-or'ing (XOR) the outputs of these two expansion functions together.
Quindi consenti quanto segue:
L_S = length in bytes of secret;
L_S1 = L_S2 = ceil(L_S / 2);
Il PRF è quindi:
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
P_SHA-1(S2, label + seed);
Ricava chiavi di crittografia
La derivazione della chiave è descritta nella RFC 2246: Sezione 6.3
L'intero keyblock è derivato come segue:
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
Una volta generato materiale sufficiente e memorizzato in key_block , key_block viene suddiviso nelle chiavi di crittografia / decrittografia. La crittografia o la decrittografia dipende dalla direzione. Poiché sono tutti referenziati come chiavi scrivi . key_block viene suddiviso sequenzialmente negli array:
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_IV[SecurityParameters.IV_size]
server_write_IV[SecurityParameters.IV_size]
Ci sono alcuni calcoli aggiuntivi eseguiti per cifrari a blocchi esportabili. Puoi leggere questi dettagli anche nella Sezione 6.3 di RFC2246. Sezione 6.3.1 fornisce un esempio di questi calcoli senza le descrizioni aggiuntive.