Sicurezza su multi-streaming come SCTP

2

Mi riferisco a multi-streaming come la capacità di inviare due o più flussi di alcune unità di dati (blocchi, flussi di byte) in un'associazione / contesto stabiliti. SCTP è un esempio e il protocollo a cui stavo pensando quando mi è venuta in mente questa domanda. Come posso proteggere in modo efficiente i dati inviati su più stream?

Quello che vedo in molti documenti è qualcosa di equivalente a N strette di mano devono essere eseguite per N flussi. Questo sembra suggerire che ogni stream sia protetto in modo indipendente. Un esempio di contatore sarebbe quello di aggiungere il flusso multi-stream-over-one a TLS invece del TCP nudo. Ma ciò non includerebbe il recupero indipendente delle perdite / degli ordini.

Ciò che mi chiedevo è rendere la sicurezza più efficiente rispetto al multi-streaming (come SCTP ) prima assicurando un flusso e poi usando quel flusso per proteggere più flussi senza l'intero handshake. Se lo stream 0 è già sicuro e un mittente desidera iniziare a inviare alcuni dati tramite lo stream 1, la mia idea è di generare una chiave casuale e inviarla tramite lo stream 0 con informazioni che servono per proteggere il flusso 1. Ma questo è sicuro anche quando lo stream 0 è già sicuro?

Stavo pensando di usare SCTP (per altri motivi) e fare la gestione della sicurezza su stream 0 e dati su stream 1 e versioni successive. EDIT: L'idea è quella di accelerare l'avvio dell'invio di dati da parte del mittente che genera una chiave per un nuovo stream X (X > 0) e l'invio di tale chiave tramite lo stream 0 e quindi l'invio di dati crittografati tramite streaming X.

Questa domanda è l'inverso di Sono state ricercate reti che utilizzano più connessioni" non correlate "per condividere un flusso di dati crittografato? I flussi che voglio proteggere sono correlati facendo parte della stessa associazione senza alcun intento di collegarli (resterebbero indipendenti)

    
posta Skaperen 03.06.2015 - 12:24
fonte

1 risposta

2

[...] my idea is to generate a random key and send it over stream 0 with info that it is for securing stream 1. But is this safe even when stream 0 is already secure?

Puoi farlo da solo, ma non credo che dovrai farlo.

RFC 3436 dice che puoi fare un handshake TLS completo sul primo stream e poi una stretta di mano abbreviata (usando TLS ripresa della sessione con l'ID della sessione dall'handshake completo) sugli altri flussi.

Funzionerebbe per te?

Ulteriori letture

risposta data 05.06.2015 - 12:48
fonte

Leggi altre domande sui tag