Videosorveglianza con crittografia end-to-end

«Quando ero comproprietario e amministratore delegato di un’azienda che offriva servizi di videosorveglianza cloud, non ho collegato ai servizi della mia azienda le telecamere installate nel cortile della mia casa di campagna.

Sapevo fin troppo bene che le persone con accesso amministrativo ai media server avrebbero potuto tecnicamente vedere ciò che accadeva a casa mia. Non volevo che qualcuno avesse la possibilità di osservare la mia vita privata», afferma Aleksandr Vasiliev, ex amministratore delegato e comproprietario dell’azienda «LANTA».

Da qui è nata l’idea di un sistema in cui l’operatore cloud può conservare i video dei clienti senza avere la possibilità di guardarli.

Ora questa possibilità è disponibile in SesameDVR.

Una piccola scatola accanto alle telecamere

Per utilizzare la crittografia non è necessario cambiare le telecamere né attendere l’arrivo di un nuovo standard RTSP.

Nella rete domestica viene installato un piccolo Sesame Agent. È sufficiente collegarlo a una porta LAN libera del router o dello switch.

L’agente si collega autonomamente alle telecamere locali, ne riceve i flussi RTSP, cifra il video e solo dopo lo invia a SesameDVR.

Tutte le connessioni vengono stabilite dalla rete domestica verso l’esterno, perciò non è necessario:

• aprire porte in ingresso;
• esporre le telecamere su Internet;
• concedere al cloud l’accesso diretto alla rete locale;
• modificare il firmware delle telecamere.

Per SesameDVR, le telecamere stesse sono di fatto inaccessibili. Il cloud riceve soltanto il flusso già cifrato.

L’agente non decodifica e non transcodifica il video. Reimpacchetta il flusso H.264 o H.265 esistente, lo cifra e lo invia al server. I requisiti di elaborazione sono quindi molto inferiori rispetto a quelli di un video server completo che esegue la transcodifica.

A seconda del modello, un Sesame Agent può gestire da 16 a diverse centinaia di telecamere.

Le prestazioni effettive dipendono da:

• bitrate complessivo delle telecamere;
• prestazioni dello specifico dispositivo;
• velocità della memoria e delle interfacce di rete;
• larghezza di banda della connessione Internet;
• parametri di crittografia e configurazione del sistema.

Come funzionano le chiavi

Il proprietario del flusso crea localmente, sul proprio dispositivo, una coppia di chiavi crittografiche:

• una chiave pubblica, che consente di cifrare i dati;
• una chiave privata, che consente di decifrarli.

La chiave pubblica viene caricata in SesameDVR e trasmessa all’agente. Può essere usata per cifrare dati destinati al proprietario, ma non per eseguire l’operazione inversa.

La chiave privata rimane esclusivamente in possesso del proprietario. Non viene creata in SesameDVR, non viene trasmessa all’operatore e non viene conservata sul server.

In seguito, il Sesame Agent genera periodicamente una chiave casuale per la crittografia dei contenuti: la CEK, Content Encryption Key.

È proprio questa chiave a cifrare il video.

Per impostazione predefinita viene generata una nuova CEK ogni ora, ma l’intervallo può essere modificato. Le chiavi possono essere cambiate molto più spesso: il limite pratico dipende soprattutto dal numero di chiavi cifrate che devono essere conservate insieme all’archivio.

Ogni nuova CEK viene cifrata con la chiave pubblica del proprietario.

Di conseguenza, SesameDVR riceve e conserva:

• segmenti video cifrati;
• CEK cifrate che proteggono tali segmenti.

La CEK in chiaro si trova soltanto nella memoria RAM dell’agente e soltanto per il suo periodo di validità. Dopo il cambio della chiave, l’agente dimentica la CEK precedente.

Durante la registrazione, la CEK in chiaro non viene mai trasmessa al server.

Il codice sorgente dell’agente è aperto. L’utente del sistema può verificare personalmente che la gestione delle chiavi funzioni esattamente come dichiarato, controllare quali dati l’agente trasmette al cloud e come viene eseguita la crittografia. Può inoltre compilare autonomamente i file eseguibili dell’agente e utilizzare proprio quelli.

Protezione non solo dai dipendenti dell’operatore

Il problema della videosorveglianza cloud non consiste soltanto nel fatto che i dipendenti dell’operatore potrebbero potenzialmente guardare le registrazioni.

L’operatore può agire con correttezza, proteggere bene l’infrastruttura e controllare rigorosamente gli accessi. Ciò, tuttavia, non garantisce che i dati rimangano sempre all’interno del suo sistema e sotto il suo controllo.

L’archivio o una sua copia possono finire nelle mani di terzi:

• in caso di violazione dei media server;
• in caso di compromissione di un account amministratore;
• a causa della fuga di una copia di backup;
• a causa di un errore nella configurazione dello spazio di archiviazione cloud;
• dopo il furto di apparecchiature o supporti di memoria;
• in seguito alle azioni di un appaltatore o di un data center;
• in caso di sequestro di server, dischi o copie di backup durante una perquisizione o altre attività investigative.

In un sistema cloud tradizionale, chi ottiene un accesso sufficientemente completo all’infrastruttura dell’operatore può potenzialmente ottenere anche la possibilità di decifrare il video.

Nell’architettura di SesameDVR, la copia o il sequestro dello spazio di archiviazione lato server non rivela, di per sé, il contenuto delle registrazioni.

Dal lato dell’operatore si trovano soltanto:

• segmenti video cifrati;
• CEK cifrate;
• dati tecnici necessari per organizzare l’archivio e la riproduzione.

La chiave privata del proprietario non è presente.

Anche se qualcuno copiasse per intero lo spazio di archiviazione di SesameDVR — in seguito a una violazione, alla fuga di una copia di backup, al furto di apparecchiature o al sequestro dei server — otterrebbe soltanto video cifrati e chiavi cifrate.

Lo spazio di archiviazione cloud non contiene tutti i dati necessari per guardare le registrazioni.

Non ci limitiamo a restringere il numero di dipendenti autorizzati a guardare i video. Cerchiamo di fare in modo che, dal lato dell’operatore, non esista in linea di principio tutto ciò che serve per decifrarli.

Che cos’è CBCS 1:9 Partial

Il video viene conservato nel formato CMAF standard utilizzando SAMPLE-AES e lo schema di crittografia cbcs 1:9.

Non si tratta di un contenitore proprietario di SesameDVR né di un nuovo codec video proprietario.

I dati video vengono suddivisi in blocchi AES da 16 byte, quindi viene applicato uno schema ripetitivo:

1 blocco viene cifrato
9 blocchi vengono saltati
1 blocco viene cifrato
9 blocchi vengono saltati
...

In questo modo, circa il 10% della parte protetta del flusso video passa attraverso AES.

Ciò non significa, tuttavia, che senza la chiave sia possibile vedere il restante 90% dell’immagine. Un flusso video H.264 o H.265 non è composto da pixel indipendenti o da singoli frammenti dell’immagine.

È una sequenza di dati compressi e interdipendenti. I blocchi cifrati sono distribuiti all’interno dei campioni video, quindi senza la CEK corretta il decoder non può ricostruire correttamente i fotogrammi.

La crittografia parziale è una scelta di ottimizzazione consapevole. Riduce notevolmente il carico sul compatto agente hardware, mantenendo al contempo il formato CMAF standard e la compatibilità con i decoder multimediali integrati.

I dati audio, invece, vengono cifrati integralmente.

Come l’utente guarda il video

Sono previste due modalità di riproduzione.

Decifratura interamente lato client

Nella modalità principale, SesameDVR invia al browser:

• segmenti video cifrati;
• CEK cifrate per il periodo selezionato.

L’utente carica localmente la propria chiave privata. Il browser sul dispositivo dell’utente decifra le CEK necessarie e le passa a ClearKey.

ClearKey fa parte dello standard per browser Encrypted Media Extensions — EME. È un’interfaccia standard attraverso la quale un’applicazione web può fornire le chiavi al sottosistema multimediale integrato del browser per riprodurre un flusso CMAF cifrato.

In questo caso, ClearKey non viene utilizzato come sistema DRM commerciale né come strumento per limitare l’utente. Funge da ponte standard tra le CEK decifrate localmente e il decoder video hardware o software del dispositivo.

Con questa modalità di riproduzione:

• la chiave privata rimane sul dispositivo dell’utente;
• le CEK in chiaro non vengono trasmesse a SesameDVR;
• il server non riceve il video in chiaro;
• la decifratura avviene direttamente durante la riproduzione.

Questa modalità è destinata principalmente ai moderni browser basati su Chromium e a Firefox. La possibilità di riprodurre uno specifico flusso dipende inoltre dal codec, dal sistema operativo e dalle capacità hardware del dispositivo.

La proprietà fondamentale dell’architettura rimane invariata: l’operatore trasmette i dati, ma non riceve le chiavi che gli consentirebbero di guardarli.

Modalità di compatibilità

Safari, iOS e alcuni lettori integrati presentano limitazioni nell’uso di ClearKey e dello schema di riproduzione scelto.

Per questi dispositivi è prevista una modalità di compatibilità che richiede una conferma separata.

L’utente decifra localmente soltanto le CEK necessarie per l’intervallo di registrazione selezionato e le trasmette temporaneamente al server nell’ambito di una sessione di breve durata.

SesameDVR decifra nella memoria RAM soltanto i frammenti richiesti e li invia al dispositivo in un formato riproducibile da un normale lettore.

Il video in chiaro e le chiavi temporanee non vengono salvati:

• su disco;
• in uno spazio di archiviazione permanente;
• in una cache CDN condivisa;
• in una cache del server a lungo termine.

Questa è l’unica modalità in cui il server ottiene temporaneamente la possibilità tecnica di decifrare la parte dell’archivio selezionata dall’utente.

La modalità di compatibilità è quindi meno rigorosa della decifratura interamente lato client. Deve essere attivata soltanto con il consenso esplicito dell’utente e per un periodo limitato.

In compenso, questa modalità consente di visualizzare l’archivio su dispositivi che non supportano lo schema interamente lato client.

È possibile condividere l’accesso

Il proprietario del flusso può creare coppie di chiavi separate per utenti diversi:

• per sé;
• per i familiari;
• per il personale di sicurezza;
• per i dipendenti;
• per un destinatario temporaneo;
• per un sistema esterno.

Quando viene concesso l’accesso, le CEK selezionate vengono ulteriormente cifrate con la chiave pubblica del destinatario.

Ogni destinatario le decifra con la propria chiave privata. Non è quindi necessario trasmettere a nessuno la chiave privata del proprietario.

In questo modo è possibile concedere l’accesso:

• all’intero archivio;
• soltanto a determinate telecamere;
• soltanto a un determinato periodo;
• soltanto alle nuove registrazioni;
• a più utenti con chiavi indipendenti.

Per revocare l’accesso è sufficiente smettere di cifrare le nuove CEK con la chiave pubblica del destinatario interessato.

È importante indicare con chiarezza un limite naturale di qualsiasi sistema di accesso: se una persona ha già salvato una registrazione decifrata o ha ottenuto le chiavi in chiaro per un determinato periodo, non è possibile obbligarla a cancellare quei dati retroattivamente.

La revoca dell’accesso impedisce di ottenere nuove registrazioni, ma non può annullare una trasmissione di informazioni già avvenuta.

Cosa potrà fare l’operatore

In un’architettura di questo tipo, l’operatore di videosorveglianza cloud potrà:

• ricevere il flusso cifrato;
• registrarlo nell’archivio;
• costruire una sequenza temporale;
• conservare i metadati tecnici;
• controllare il periodo di conservazione;
• eliminare i segmenti meno recenti;
• trasmettere le registrazioni cifrate al proprietario;
• fornire l’infrastruttura per la gestione degli accessi.

Senza la chiave privata del proprietario, tuttavia, l’operatore non potrà guardare autonomamente il video.

Anche un amministratore con accesso completo ai media server e allo spazio di archiviazione vedrà soltanto segmenti cifrati e chiavi cifrate.

Lo stesso vale per un aggressore che abbia ottenuto una copia del database, per un appaltatore con accesso ai supporti di memoria o per una persona entrata in possesso dell’infrastruttura server sequestrata.

Questo non significa sicurezza assoluta

Questa architettura risolve un problema specifico: protegge il contenuto dell’archivio dalla visualizzazione da parte dell’operatore cloud e dalla compromissione dello spazio di archiviazione lato server.

Non elimina, tuttavia, la necessità di proteggere gli altri elementi del sistema.

Un aggressore potrebbe, ad esempio, tentare ancora di:

• accedere direttamente alla telecamera prima della crittografia;
• violare la rete domestica;
• sostituire o compromettere il Sesame Agent;
• rubare la chiave privata del proprietario;
• accedere a un dispositivo dell’utente già sbloccato;
• registrare il video dallo schermo durante la riproduzione.

Inoltre, la crittografia del flusso video non nasconde necessariamente tutti i metadati.

L’operatore può comunque sapere:

• che esistono delle telecamere;
• quando arrivano i segmenti;
• qual è la durata dell’archivio;
• qual è il volume dei dati trasmessi;
• quali azioni compiono gli utenti nell’interfaccia.

SesameDVR non rende il video invulnerabile in qualsiasi circostanza. Elimina uno dei problemi più significativi della videosorveglianza cloud tradizionale: la presenza, dal lato dell’operatore, di una possibilità tecnica permanente di visualizzare l’archivio del cliente.

Perché soluzioni simili sono rare

Sul mercato esistono alcuni prodotti aziendali con chiavi gestite dal cliente.

Nei sistemi di videosorveglianza cloud di massa, tuttavia, viene generalmente utilizzato un modello diverso: la piattaforma gestisce autonomamente le chiavi e, se necessario, può decifrare i dati del cliente.

La particolarità dell’approccio di SesameDVR non consiste nell’invenzione di un nuovo algoritmo di crittografia, bensì nella combinazione di diverse caratteristiche:

• funzionamento con normali telecamere RTSP;
• agente locale separato, senza transcodifica;
• nessun accesso diretto del cloud alle telecamere;
• formato CMAF standard con cbcs;
• riproduzione tramite i meccanismi standard del browser;
• conservazione locale della chiave privata;
• possibilità di concedere l’accesso mediante la crittografia aggiuntiva delle CEK;
• codice sorgente aperto dell’agente.

Conservare non significa possedere la chiave

Nel corso degli anni di sviluppo della videosorveglianza cloud ci siamo abituati a pensare che, se un video è conservato sul server dell’operatore, quest’ultimo possa inevitabilmente guardarlo.

Ma non è affatto una condizione necessaria.

Un server può conservare terabyte di registrazioni, indicizzarle, eliminarle alla scadenza del periodo di conservazione e trasmetterle al proprietario senza disporre della chiave necessaria per guardarle.

L’operatore non dovrebbe limitarsi a promettere che i suoi dipendenti non guarderanno i vostri video.

Non basta neppure proteggere bene i server: in teoria, qualsiasi server può essere violato, copiato, rubato o sequestrato.

È possibile costruire un sistema in modo che né un normale amministratore, né un aggressore che abbia ottenuto una copia dello spazio di archiviazione, né una persona entrata in possesso dei dischi del server ricevano insieme all’archivio anche la possibilità di decifrarlo.

Conservare un video non significa necessariamente avere accesso al suo contenuto.

È proprio questo il modello che stiamo implementando in SesameDVR.