Come implementare "Broadcast Encryption"?

Basta crittografare il simmetrico con la chiave pubblica di ciascun destinatario. C'è qualche ricerca su come fare meglio di così (in modo che il sovraccarico delle dimensioni sia inferiore a, ad esempio, cento byte per destinatario) ma al momento non c'è nulla di direttamente applicabile.

Se usi RSA (che è il più probabile), ecco le dimensioni: un messaggio cifrato ha sempre la stessa dimensione del modulo; per una chiave RSA a 1024 bit, significa 128 byte. Il processo di crittografia include alcuni padding, che aggiunge un overhead interno di almeno 11 byte. Pertanto, la dimensione massima di un blob di dati che deve essere crittografato con una chiave RSA a 1024 bit è 128-11 = 117 byte.

Non sono sicuro del motivo per cui desideri racchiudere la chiave simmetrica in un messaggio SOAP o JSON. Se è crittografato, il ricevitore deve decrittografarlo; dato che un messaggio RSA crittografato sembra davvero un mucchio di byte casuali senza struttura visibile, questo significa che il ricevitore sa già cosa aspettarsi. Cosa aggiungerebbe SOAP o JSON a quel punto? Forse ti piacerebbe farlo al contrario, vale a dire criptare (con RSA) la chiave simmetrica, e poi avvolgere il risultato (il messaggio crittografato a 128 byte) in un messaggio SOAP o JSON?

Esistono diversi schemi di codifica broadcast (BE) utilizzabili. Il più popolare tra questi è lo schema Differenza sottoinsiemi (SD) di Naor-Naor-Lotspiech (NNL) proposto nel 2001. Ecco un collegamento completo versione del documento che descrive lo schema: link . È stato suggerito per essere utilizzato dallo standard AACS per la gestione dei diritti digitali nei dischi ottici.

I due parametri più importanti (in termini di costi) di qualsiasi schema BE sono (a) la quantità di spazio di archiviazione richiesta per memorizzare le chiavi private di ciascun utente, (b) la quantità di ulteriori informazioni ( spese generali di comunicazione ) che devono essere inviate con ogni blocco di dati crittografato per la trasmissione.

Sono stati proposti diversi miglioramenti allo schema NNL-SD che intendono ridurre i requisiti di archiviazione delle chiavi del dispositivo e il sovraccarico della comunicazione. Eccone alcuni.

1. Riduzione dello spazio di archiviazione: (a) Schemi SD stratificati di Halevy e Shamir, Crypto 2002. (b) Archiviazione minima e altre ottimizzazioni dello schema SD: collegamento
2. Riduzione dei costi di comunicazione: (a) Schemi SD dell'albero k-ary: numero di archivio IACR ePrint: 2013/786 (b) Schemi di Augmented Binary Tree SD: numero di archivio IACR ePrint: 2014/577

Tutti questi schemi hanno le seguenti caratteristiche: R. Sono stateless e quindi le chiavi dell'utente non devono essere aggiornate di volta in volta. B. Questi schemi consentono inoltre a di revocare qualsiasi numero di utenti in qualsiasi momento . C. Consentono anche " tracciamento dei traditori black-box ". Questo è un meccanismo mediante il quale è possibile testare la capacità di decrittazione di una "casella di decifrazione dei pirati" per trovare le chiavi utente che sono state utilizzate al suo interno. Si può notare che questo non richiede l'apertura della scatola dei pirati. È sufficiente testare le sue capacità di decrittografia trattandolo come una casella nera.

Tuttavia presentano i seguenti svantaggi: R. Tutte le trasmissioni provengono da un centro che contiene tutte le informazioni sulle chiavi segrete degli utenti, come nella definizione standard di BE. B. Gli utenti non possono essere aggiunti dinamicamente al sistema. Quindi, il numero massimo di utenti nel sistema deve essere stimato e quindi fissato durante l'inizializzazione dello schema.