Videoüberwachung mit Ende-zu-Ende-Verschlüsselung

„Als Mitinhaber und Geschäftsführer eines Unternehmens, das selbst Cloud-Videoüberwachung anbot, habe ich die Kameras im Hof meines eigenen Landhauses nicht an die Dienste meiner Firma angeschlossen.

Ich wusste nur zu gut, dass Personen mit administrativem Zugriff auf die Medienserver technisch sehen könnten, was bei mir zu Hause geschieht. Ich wollte nicht, dass jemand potenziell mein Privatleben beobachten kann“, sagte Alexander Wassiljew, ehemaliger Geschäftsführer und Mitinhaber des Unternehmens „LANTA“.

Daraus entstand die Idee für ein System, in dem ein Cloud-Betreiber die Videos seiner Kunden speichern kann, ohne sie ansehen zu können.

Diese Möglichkeit gibt es jetzt in SesameDVR.

Eine kleine Box neben den Kameras

Für die Verschlüsselung müssen weder die Kameras ausgetauscht werden noch muss man auf einen neuen RTSP-Standard warten.

Im Heimnetzwerk wird ein kompakter Sesame Agent installiert. Es genügt, ihn an einen freien LAN-Port des Routers oder Switches anzuschließen.

Der Agent verbindet sich selbstständig mit den lokalen Kameras, empfängt deren RTSP-Streams, verschlüsselt das Video und sendet es erst danach an SesameDVR.

Alle Verbindungen werden vom Heimnetzwerk nach außen aufgebaut. Daher ist es nicht erforderlich:

eingehende Ports zu öffnen;
Kameras im Internet zugänglich zu machen;
der Cloud direkten Zugriff auf das lokale Netzwerk zu gewähren;
die Firmware der Kameras zu ändern.

Für SesameDVR sind die Kameras selbst praktisch nicht erreichbar. Die Cloud erhält ausschließlich den bereits verschlüsselten Stream.

Der Agent dekodiert oder transkodiert das Video nicht. Er verpackt den fertigen H.264- oder H.265-Stream neu, verschlüsselt ihn und sendet ihn an den Server. Deshalb sind die Anforderungen an den Prozessor deutlich geringer als bei einem vollwertigen Videoserver, der eine Transkodierung durchführt.

Je nach Modell kann ein Sesame Agent zwischen 16 und mehreren Hundert Kameras bedienen.

Die konkrete Leistung hängt ab von:

der gesamten Bitrate der Kameras;
der Leistung des jeweiligen Geräts;
der Geschwindigkeit des Speichers und der Netzwerkschnittstellen;
der Bandbreite der Internetverbindung;
den Verschlüsselungsparametern und der Systemkonfiguration.

So funktionieren die Schlüssel

Der Eigentümer des Streams erstellt lokal auf seinem eigenen Gerät ein kryptografisches Schlüsselpaar:

einen öffentlichen Schlüssel, mit dem Daten verschlüsselt werden können;
einen privaten Schlüssel, mit dem sie entschlüsselt werden können.

Der öffentliche Schlüssel wird in SesameDVR hochgeladen und an den Agent übermittelt. Mit ihm lassen sich Daten für den Eigentümer verschlüsseln, der umgekehrte Vorgang ist jedoch nicht möglich.

Der private Schlüssel verbleibt ausschließlich beim Eigentümer. Er wird nicht in SesameDVR erstellt, nicht an den Betreiber übermittelt und nicht auf dem Server gespeichert.

Anschließend erzeugt der Sesame Agent regelmäßig einen zufälligen Schlüssel zur Inhaltsverschlüsselung – den CEK, Content Encryption Key.

Mit genau diesem Schlüssel wird das Video verschlüsselt.

Standardmäßig wird jede Stunde ein neuer CEK erzeugt, das Intervall kann jedoch geändert werden. Die Schlüssel können deutlich häufiger gewechselt werden: Die praktische Grenze ergibt sich hauptsächlich aus der Anzahl verschlüsselter Schlüssel, die zusammen mit dem Archiv gespeichert werden müssen.

Jeder neue CEK wird mit dem öffentlichen Schlüssel des Eigentümers verschlüsselt.

Dadurch empfängt und speichert SesameDVR:

verschlüsselte Videosegmente;
verschlüsselte CEK, mit denen diese Segmente geschützt sind.

Der unverschlüsselte CEK befindet sich nur im Arbeitsspeicher des Agent und nur während seiner Gültigkeitsdauer. Nach einem Schlüsselwechsel verwirft der Agent den vorherigen CEK.

Während der Aufzeichnung wird der unverschlüsselte CEK niemals an den Server übertragen.

Der Quellcode des Agent ist offen. Nutzer des Systems können selbst überprüfen, ob die Schlüsselverwaltung tatsächlich wie beschrieben funktioniert, welche Daten der Agent an die Cloud übermittelt und wie die Verschlüsselung ausgeführt wird. Darüber hinaus können Nutzer die ausführbaren Dateien des Agent selbst erstellen und genau diese verwenden.

Schutz nicht nur vor Mitarbeitern des Betreibers

Das Problem der Cloud-Videoüberwachung besteht nicht nur darin, dass Mitarbeiter des Betreibers die Aufzeichnungen potenziell ansehen könnten.

Der Betreiber kann gewissenhaft sein, seine Infrastruktur gut schützen und den Zugriff streng kontrollieren. Das garantiert jedoch nicht, dass die Daten immer innerhalb seines Systems und unter seiner Kontrolle bleiben.

Das Archiv oder eine Kopie davon kann in die Hände Dritter gelangen:

durch einen Angriff auf die Medienserver;
durch die Kompromittierung eines Administratorkontos;
durch das Abfließen einer Sicherungskopie;
durch eine fehlerhafte Konfiguration des Cloud-Speichers;
nach dem Diebstahl von Geräten oder Datenträgern;
infolge von Handlungen eines Dienstleisters oder Rechenzentrums;
bei der Beschlagnahme von Servern, Festplatten oder Sicherungskopien im Rahmen einer Durchsuchung oder anderer Ermittlungsmaßnahmen.

In einem herkömmlichen Cloud-System erhält jemand, der hinreichend umfassenden Zugriff auf die Infrastruktur des Betreibers erlangt, potenziell auch die Möglichkeit, das Video zu entschlüsseln.

In der Architektur von SesameDVR legt das Kopieren oder die Beschlagnahme des serverseitigen Speichers allein den Inhalt der Aufzeichnungen nicht offen.

Auf Seiten des Betreibers befinden sich nur:

verschlüsselte Videosegmente;
verschlüsselte CEK;
technische Daten, die für die Organisation des Archivs und die Wiedergabe erforderlich sind.

Der private Schlüssel des Eigentümers befindet sich dort nicht.

Selbst wenn jemand den gesamten Speicher von SesameDVR kopiert – infolge eines Angriffs, des Abflusses einer Sicherungskopie, eines Gerätediebstahls oder der Beschlagnahme von Servern –, erhält diese Person nur verschlüsselte Videos und verschlüsselte Schlüssel.

Der Cloud-Speicher enthält nicht alle Daten, die zum Ansehen der Aufzeichnungen erforderlich wären.

Wir beschränken nicht nur den Kreis der Mitarbeiter, die Videos ansehen dürfen. Wir wollen erreichen, dass auf Seiten des Betreibers grundsätzlich nicht alles vorhanden ist, was für die Entschlüsselung benötigt wird.

Was CBCS 1:9 Partial ist

Das Video wird im standardisierten CMAF-Format unter Verwendung von SAMPLE-AES und dem Verschlüsselungsschema cbcs 1:9 gespeichert.

Dabei handelt es sich weder um einen proprietären Container von SesameDVR noch um einen neuen proprietären Videocodec.

Die Videodaten werden in AES-Blöcke von je 16 Byte aufgeteilt. Anschließend wird ein sich wiederholendes Muster angewendet:

1 Block wird verschlüsselt
9 Blöcke werden übersprungen
1 Block wird verschlüsselt
9 Blöcke werden übersprungen
...

Somit durchlaufen etwa 10 % des zu schützenden Teils des Videostreams AES.

Das bedeutet jedoch nicht, dass man die übrigen 90 % des Bildes ohne Schlüssel sehen kann. Ein H.264- oder H.265-Videostream besteht nicht aus unabhängigen Pixeln oder einzelnen Bildfragmenten.

Er ist eine Folge komprimierter und voneinander abhängiger Daten. Die verschlüsselten Blöcke sind innerhalb der Videosamples verteilt, sodass der Decoder die Bilder ohne den richtigen CEK nicht korrekt rekonstruieren kann.

Die partielle Verschlüsselung ist hier eine bewusste Optimierung. Sie reduziert die Belastung des kompakten Hardware-Agent erheblich, behält aber das standardisierte CMAF-Format und die Kompatibilität mit integrierten Mediendecodern bei.

Audiodaten werden dabei vollständig verschlüsselt.

So sieht der Nutzer das Video an

Es sind zwei Wiedergabemodi vorgesehen.

Vollständig clientseitige Entschlüsselung

Im Hauptmodus sendet SesameDVR an den Browser:

verschlüsselte Videosegmente;
verschlüsselte CEK für den ausgewählten Zeitraum.

Der Nutzer lädt seinen privaten Schlüssel lokal. Der Browser auf dem Gerät des Nutzers entschlüsselt die benötigten CEK und übergibt sie an ClearKey.

ClearKey ist Bestandteil des Browserstandards Encrypted Media Extensions – EME. Dies ist eine standardisierte Schnittstelle, über die eine Webanwendung Schlüssel an das integrierte Mediensystem des Browsers übergeben kann, um einen verschlüsselten CMAF-Stream wiederzugeben.

In diesem Fall wird ClearKey weder als kommerzielles DRM-System noch als Mittel zur Einschränkung des Nutzers verwendet. Es dient als standardisierte Brücke zwischen den lokal entschlüsselten CEK und dem Hardware- oder Software-Videodecoder des Geräts.

Bei dieser Art der Wiedergabe:

verbleibt der private Schlüssel auf dem Gerät des Nutzers;
werden unverschlüsselte CEK nicht an SesameDVR übertragen;
erhält der Server kein unverschlüsseltes Video;
erfolgt die Entschlüsselung unmittelbar während der Wiedergabe.

Dieser Modus ist in erster Linie für moderne Chromium-basierte Browser und Firefox vorgesehen. Ob ein bestimmter Stream wiedergegeben werden kann, hängt zusätzlich vom Codec, vom Betriebssystem und von den Hardwarefähigkeiten des Geräts ab.

Die wichtigste Eigenschaft der Architektur bleibt erhalten: Der Betreiber überträgt die Daten, erhält aber keine Schlüssel, mit denen er sie ansehen könnte.

Kompatibilitätsmodus

Safari, iOS und einige integrierte Player sind bei der Arbeit mit ClearKey und dem gewählten Wiedergabeschema eingeschränkt.

Für solche Geräte ist ein separat zu bestätigender Kompatibilitätsmodus vorgesehen.

Der Nutzer entschlüsselt lokal nur diejenigen CEK, die für das ausgewählte Aufzeichnungsintervall erforderlich sind, und übermittelt sie im Rahmen einer kurzlebigen Sitzung vorübergehend an den Server.

SesameDVR entschlüsselt ausschließlich die angeforderten Fragmente im Arbeitsspeicher und übergibt sie dem Gerät in einem Format, das von einem gewöhnlichen Player wiedergegeben werden kann.

Das unverschlüsselte Video und die temporären Schlüssel werden dabei nicht gespeichert:

auf einem Datenträger;
in einem permanenten Speicher;
in einem gemeinsam genutzten CDN-Cache;
in einem langfristigen Server-Cache.

Dies ist der einzige Modus, in dem der Server vorübergehend die technische Möglichkeit erhält, den vom Nutzer ausgewählten Abschnitt des Archivs zu entschlüsseln.

Der Kompatibilitätsmodus ist deshalb weniger strikt als die vollständig clientseitige Entschlüsselung. Er darf nur mit ausdrücklicher Zustimmung des Nutzers und nur für begrenzte Zeit aktiviert werden.

Dafür ermöglicht dieser Modus die Wiedergabe des Archivs auf Geräten, die das vollständig clientseitige Verfahren nicht unterstützen.

Zugriff kann geteilt werden

Der Eigentümer des Streams kann separate Schlüsselpaare für verschiedene Nutzer erstellen:

für sich selbst;
für Familienmitglieder;
für den Sicherheitsdienst;
für Mitarbeiter;
für einen temporären Empfänger;
für ein externes System.

Bei der Freigabe des Zugriffs werden die ausgewählten CEK zusätzlich mit dem öffentlichen Schlüssel des Empfängers verschlüsselt.

Jeder Empfänger entschlüsselt sie mit seinem eigenen privaten Schlüssel. Der private Schlüssel des Eigentümers muss dabei an niemanden weitergegeben werden.

Auf diese Weise kann Zugriff gewährt werden:

auf das gesamte Archiv;
nur auf einzelne Kameras;
nur auf einen bestimmten Zeitraum;
nur auf neue Aufzeichnungen;
für mehrere Nutzer mit voneinander unabhängigen Schlüsseln.

Um den Zugriff zu widerrufen, genügt es, neue CEK nicht mehr mit dem öffentlichen Schlüssel des betreffenden Empfängers zu verschlüsseln.

Dabei muss eine natürliche Einschränkung jedes Zugriffssystems klar benannt werden: Hat eine Person bereits eine entschlüsselte Aufzeichnung gespeichert oder unverschlüsselte Schlüssel für einen bestimmten Zeitraum erhalten, kann sie nicht nachträglich dazu gezwungen werden, diese Daten zu löschen.

Der Widerruf des Zugriffs verhindert den Erhalt neuer Aufzeichnungen, kann eine bereits erfolgte Datenübermittlung jedoch nicht rückgängig machen.

Was der Betreiber tun kann

In einer solchen Architektur kann der Betreiber der Cloud-Videoüberwachung:

den verschlüsselten Stream empfangen;
ihn im Archiv aufzeichnen;
eine Zeitleiste erstellen;
technische Metadaten speichern;
die Aufbewahrungsdauer steuern;
alte Segmente löschen;
verschlüsselte Aufzeichnungen an den Eigentümer übertragen;
die Infrastruktur für die Zugriffsverwaltung bereitstellen.

Ohne den privaten Schlüssel des Eigentümers kann der Betreiber das Video jedoch nicht selbst ansehen.

Selbst ein Administrator mit vollständigem Zugriff auf die Medienserver und den Speicher sieht nur verschlüsselte Segmente und verschlüsselte Schlüssel.

Dasselbe gilt für einen Angreifer, der eine Kopie der Datenbank erlangt hat, einen Dienstleister mit Zugriff auf die Datenträger oder eine Person, in deren Besitz die beschlagnahmte Serverinfrastruktur gelangt ist.

Das bedeutet keine absolute Sicherheit

Diese Architektur löst eine konkrete Aufgabe: Sie schützt den Inhalt des Archivs vor der Einsicht durch den Cloud-Betreiber und vor der Kompromittierung des serverseitigen Speichers.

Sie hebt jedoch die Notwendigkeit nicht auf, die übrigen Komponenten des Systems zu schützen.

Ein Angreifer könnte beispielsweise weiterhin versuchen:

vor der Verschlüsselung Zugriff auf die Kamera selbst zu erhalten;
in das Heimnetzwerk einzudringen;
den Sesame Agent auszutauschen oder zu kompromittieren;
den privaten Schlüssel des Eigentümers zu stehlen;
Zugriff auf ein bereits entsperrtes Gerät des Nutzers zu erlangen;
das Video während der Wiedergabe vom Bildschirm aufzuzeichnen.

Außerdem verbirgt die Verschlüsselung des Videostreams nicht zwangsläufig sämtliche Metadaten.

Der Betreiber kann weiterhin wissen:

dass Kameras vorhanden sind;
wann Segmente eingehen;
wie lang das Archiv ist;
welches Datenvolumen übertragen wird;
welche Aktionen Nutzer in der Benutzeroberfläche ausführen.

SesameDVR macht Videos nicht unter allen Umständen unangreifbar. Es beseitigt eines der schwerwiegendsten Probleme herkömmlicher Cloud-Videoüberwachung: die dauerhafte technische Möglichkeit des Betreibers, das Archiv eines Kunden einzusehen.

Warum solche Lösungen selten sind

Auf dem Markt gibt es einzelne Unternehmensprodukte mit kundenseitig verwalteten Schlüsseln.

In Cloud-Videoüberwachungssystemen für den Massenmarkt wird jedoch üblicherweise ein anderes Modell eingesetzt: Die Plattform verwaltet die Schlüssel selbst und kann die Daten des Kunden bei Bedarf entschlüsseln.

Die Besonderheit des Ansatzes von SesameDVR besteht nicht in der Erfindung eines neuen Verschlüsselungsalgorithmus, sondern in der Kombination mehrerer Eigenschaften:

Nutzung gewöhnlicher RTSP-Kameras;
separater lokaler Agent ohne Transkodierung;
kein direkter Zugriff der Cloud auf die Kameras;
standardisiertes CMAF mit cbcs;
Wiedergabe über standardisierte Browsermechanismen;
lokale Speicherung des privaten Schlüssels;
Möglichkeit, Zugriff durch zusätzliche Verschlüsselung der CEK zu gewähren;
offener Quellcode des Agent.

Speichern heißt nicht, den Schlüssel zu besitzen

Im Laufe der Entwicklung der Cloud-Videoüberwachung haben wir uns daran gewöhnt anzunehmen, dass der Betreiber ein auf seinem Server gespeichertes Video zwangsläufig auch ansehen kann.

Das ist jedoch keineswegs zwingend.

Ein Server kann Terabytes an Aufzeichnungen speichern, indexieren, nach Ablauf der Aufbewahrungsfrist löschen und an den Eigentümer übertragen, ohne über den für die Wiedergabe erforderlichen Schlüssel zu verfügen.

Der Betreiber muss nicht lediglich versprechen, dass seine Mitarbeiter Ihr Video nicht ansehen werden.

Auch ein guter Schutz der Server allein reicht nicht aus: Jeder Server kann theoretisch angegriffen, kopiert, gestohlen oder beschlagnahmt werden.

Ein System lässt sich so aufbauen, dass weder ein regulärer Administrator noch ein Angreifer mit einer Kopie des Speichers noch eine Person, in deren Besitz die Serverfestplatten gelangt sind, zusammen mit dem Archiv die Möglichkeit zu dessen Entschlüsselung erhält.

Video zu speichern bedeutet nicht zwangsläufig, Zugriff auf seinen Inhalt zu haben.

Genau dieses Modell setzen wir in SesameDVR um.