DTLS Session Keys tempo di vita

Question

DTLS Session Keys tempo di vita

#1 da (3 voti)

3

Ho un'applicazione client UDP di lunga durata: idealmente, continua a trasmettere su un server per sempre. Sto utilizzando Datagram Transport Layer Security (DTLS) per proteggere la comunicazione UDP.

Con quale frequenza DTLS aggiorna le chiavi di sessione stabilite durante l'handshake utilizzate per proteggere la comunicazione del livello record?
È necessaria una nuova stretta di mano per aggiornare le chiavi? Questo può essere fatto usando un altro metodo?

openssl tls

posta cdev 30.04.2014 - 13:43

fonte

1 risposta

Leggi altre domande sui tag openssl tls

Come posso rilevare se qualcuno sta usando un tunnel ssh come proxy per connettersi a una VPN? L'esecuzione di un servizio Windows come utente (standard) è un rischio?

score 3 · Answer 1

Non vi è alcuna nozione di "aggiornamento chiave", in DTLS o anche TLS , che sarebbe indipendente dall'handshake. Se vuoi aggiornare le tue chiavi per qualche motivo, allora lo fai richiedendo un nuovo handshake. Sia il client che il server possono attivare un nuovo handshake in qualsiasi momento (il client lo fa inviando un ClientHello , mentre il server invia un HelloRequest ).

Ci sono due tipi di chiavi in TLS (e DTLS):

Il master secret viene stabilito tramite crittografia asimmetrica (RSA, Diffie-Hellman) come parte di un "full handshake".
L'effettiva crittografia e le chiavi MAC sono prodotte dal segreto principale e dai "valori casuali" inviati dal client e dal server. Quando un client e un server eseguono una "stretta di mano abbreviata", viene riutilizzato un "master secret" precedentemente condiviso, ma vengono generate nuove chiavi di crittografia / MAC.

Non esiste alcun motivo intrinseco in TLS o DTLS che possa forzare un nuovo handshake, eccetto possibilmente esaurire numeri di sequenza distinti; ma dal momento che quel numero è un contatore a 64 bit, l'esaurimento non si verifica effettivamente nella pratica (da una ripresa molto lunga). Qualsiasi applicazione specifica potrebbe desiderare di eseguire un "aggiornamento" in qualsiasi momento e può farlo attivando una nuova stretta di mano (abbreviata o completa: una stretta di mano abbreviata si verifica solo se sia il client che il server sono d'accordo).

Va notato che ci sono pochissime ragioni razionali per "rinfrescare" le chiavi. Le persone che effettuano l'aggiornamento lo fanno in realtà per conformità formale ai requisiti normativi la cui base è stata persa nelle nebbie del tempo (di solito residui delle procedure che erano necessarie per la sicurezza con crittosistemi da prima dell'invenzione del computer). Il mito non detto al lavoro in questi casi è un'ipotesi che le chiavi in qualche modo si degradino in seguito all'uso, come i cuscinetti per una ruota, e devono essere sostituite regolarmente. Questo mito è, beh, un mito, ma strong, che alimenta ancora molti standard e documenti di "best practice".

(L'unico motivo razionale che ho visto per un "refresh" non riguardava affatto l'aggiornamento: era un server TLS utilizzato in un contesto in cui il client ha anche un certificato, la cui chiave privata era in una smart card. il server ha regolarmente forzato un nuovo handshake completo per assicurarsi che la smart card fosse ancora lì.)