Sto tentando di decrittografare manualmente i pacchetti DTLS inviati da OpenSSL.
La suite di crittografia utilizzata tra il server e il client è TLS_RSA_WITH_AES_256_CBC_SHA256 e la mia comprensione è che l'IV utilizzato dal cifrario è anteposto ai dati delle applicazioni crittografate. Conosco anche il master secret usato dal server.
Ora, alla mia domanda, come OpenSSL ricava la chiave di crittografia dal segreto principale?
Meta: non aggiunge molto a the dupe ma rileggendo ho notato che mi mancava la" D ".
I processi di definizione e crittografia / decrittografia e autenticazione per TLSv1.2 sono specificati in RFC 5246 TLSv1.2 plus per Scambio di chiavi ECC (non qui) RFC 4492 TLS ECC modificato dall'appendice A.7 di 5246. Questi processi si applicano anche a DTLSv1.2 RFC 6347 DTLSv1.2 , sebbene le intestazioni dei record, la trasmissione effettiva e alcuni errori di gestione differiscono per DTLS rispetto a TLS.
Lo stato della chiave SSL / TLS / DTLS ha due parti: una che varia in base (solo) all'algoritmo di scambio di chiavi utilizzato e produce un "segreto premaster", e una che varia in base (solo) alla cifratura e Algoritmo MAC / modalità selezionata e utilizza il segreto premaster per produrre un master secret e quindi le diverse chiavi di lavoro, IV e nonce. I processi di crittografia / decrittografia e autenticazione variano in modo simile.
Per TLS_RSA_WITH_AES_256_CBC_SHA256 l'algoritmo di scambio di chiavi è RSA. Il segreto premaster viene scelto dal client, RSA crittografato sotto la chiave pubblica del server e inviato al server che RSA lo decrittografa e lo controlla. Vedi in 7.4.2 l'articolo per RSA , 7.4.7.1 e 8.1.1 . Per eseguire questa operazione all'esterno del server è necessaria (una copia della) chiave privata del server.
Il segreto premaster viene quindi utilizzato con i nonces per derivare il master secret come specificato in 8.1 utilizzando la PRF (funzione PseudoRandom) definita in sec 5 ; questo viene quindi usato di nuovo con i nonces per derivare le chiavi di lavoro come specificato in 6.3 usando lo stesso PRF per taglie in appendice C . Per TLS_RSA_WITH_AES_256_CBC_SHA256 il codice è AES_256_CBC che richiede una chiave di 32 ottetti in ogni direzione e il MAC è HMAC-SHA256 con una chiave di 32 ottetti in ciascuna direzione.
Ogni record di dati è MAC e crittografato dal mittente e decrittografato e verificato dal ricevitore. Il processo MAC / verifica è specificato da 6.2.3.1 (per tutte le crittografie / suite non-AEAD e questa suite non è AEAD) e il processo di crittografia / decrittografia per il cifrario in modalità CBC (blocco) è specificato da 6.2.3.2 ; in effetti sceglie un IV per record e lo antepone ai dati dei record crittografati.
Per un'altra cipheruite la struttura è la stessa, ma in alcuni punti si applicano diverse sezioni specifiche di RFC 5246 e per lo scambio di chiavi basato su ECC (ECDH, ECDHE o ECDH_anon) RFC 4492.
Leggi altre domande sui tag openssl key-generation aes