­čçę­čç¬ Video­čÄ×´ŞĆ Microservice­čľą´ŞĆ Konzept­čôł (2018)­čÉ╗

4.5. Verschl├╝sselung und Sicherheit

Verschl├╝sselung spielt eine wichtige Rolle im Streaming. Sie gew├Ąhrleistet die Sicherheit der ├╝bertragenen Informationen im Internet, einem Informationsnetzwerk, das nicht sicher ist. Um entweder VoD-Verschl├╝sselung oder die Verschl├╝sselung von Live-Inhalten zu unterst├╝tzen, muss ein Streaming Server ÔÇ×Pre-EncryptionÔÇť- Verfahren (Vorverschl├╝sselung von statischen Inhalten) oder ÔÇ×Live-EncryptionÔÇť- Verfahren unterst├╝tzen. Des Weiteren muss ein Streaming Server in der Lage sein, den Content Key (Schl├╝ssel zum Lesen des Inhalts, nachfolgend auch Keyinfo genannt) sicher an den User zu transportieren, ohne diese Information selbst preis zu geben74.

4.5.1. AES-Cipher im HLS-Protokoll

Das HLS-Protokoll sieht in seiner Spezifikation die Verschl├╝sselung mit AES-128, AES-192 oder AES-256 ÔÇĽ einem Cipher Block Chaining -Mechanismus (CBC) vor. Je l├Ąnger der Schl├╝ssel, desto gr├Â├čer der Hauptspeicherbedarf beim Dekodieren. Der Algorithmus verschl├╝sselt das erste Paket mit einem Initialisierungsvektor IV und einem Schl├╝ssel und jedes weitere Paket mit dem n├Ąchstfolgenden Vektor IV und demselben Schl├╝ssel. Der Anfangsvektor kann frei gew├Ąhlt werden oder vom Algorithmus bestimmt werden75. Auf diese Weise entsteht ein verschl├╝sseltes HLS-Dateisystem, das ohne den richtigen Schl├╝ssel nicht gelesen bzw. nicht abgespielt werden kann.

Im Fall von VoD gibt es drei potentielle Verschl├╝sselungsstrategien76:

  1. ÔÇ×Pre-encryptionÔÇť ÔÇô Vorverschl├╝sselung aller Medien-Assets mit einem permanenten Key
  2. Periodische Neuverschl├╝sselung ÔÇô ÔÇ×re-encryptionÔÇť mit einem regelm├Ą├čig ablaufenden Key
  3. ÔÇ×on-the-flyÔÇť- Verschl├╝sselung ÔÇô je Session ein neuer, tempor├Ąrer Key
  1. Vorverschl├╝sselung ist ressourcenschonend, da der Stream nur ein Mal verschl├╝sselt wird. Dies legt jedoch das Problem zutage, dass sobald der Schl├╝ssel zum Stream bekannt wird, die Verschl├╝sselung dauerhaft au├čer Kraft gesetzt ist
  2. Deswegen ist periodische Neuverschl├╝sselung praktischer. Die Mediendateien liegen in ihrem Rohformat in einem Zwischenspeicher und werden regelm├Ą├čig mit einem neuen Schl├╝ssel versehen, ergo im Webstorage neu beschrieben
  3. Im Fall von Live-Video ist nur die ÔÇ×on-the-flyÔÇť- Verschl├╝sselung praktikabel. Sie kann bei relativ schnellen Videoservern auch zur ÔÇ×on-the-flyÔÇť- Verschl├╝sselung von VoD-Inhalten dienen

Im Fall eines HTTP GET- Zugriffs auf einen verschl├╝sselten HLS-Stream muss der Webserver entscheiden, ob der Key zum Stream freigegeben wird. Grunds├Ątzlich entscheidet ein Zugriffskontrollalgorithmus, ob es sich um einen legitimen Zugriff auf die Keyinfo-Datei handelt. Denn der direkte Zugriff des Users oder eines Angreifers auf die Keyinfo f├╝hrt zur Kompromitierung des Verschl├╝sselungsmechanismus. Deswegen muss die Keyinfo mit SSL an den Player verschickt werden.

Trotzdessen kann ein man-in-the-middle (MitM)-Angriff auch eine ├╝ber HTTPS verschickte Information mitschneiden. Deswegen ist es notwendig, die Keyinfo mit einem Public Key System explizit an einen vertrauten Client zu binden, also einen, der die Keyinfo diskret behandelt und effektiv sowohl vor dem User als auch vor potentiell mitlesenden Parteien verbirgt77. Die URI zur Keyinfo auf dem Webserver muss tempor├Ąr sein und nach einem erfolgreichen Schl├╝sselkonsum entfernt werden.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-KEY:METHOD=AES-256,URI=ÔÇťhttps://bbc.com/TopGearSeries18/K62236250.keyÔÇť
#EXTINF:10, no desc TopGearSeries18_Layer2/TopGearSeries18_Layer2_00001.ts
#EXTINF:10, no desc TopGearSeries18_Layer2/TopGearSeries18_Layer2_00002.ts

Quellcode 2: Index-m3u8 eines verschl├╝sselten Streams mit Angaben zur Keyinfo unter dem Tag #EXT-X-KEY

C. DÔÇśOrazio und K. Choo haben 2015 ein Experiment durchgef├╝hrt um festzustellen, bei wie vielen namhaften VoD-Anbietern ein versierter Hacker die Keyinfo f├╝r ein bestimmtes (und ergo mehrere) Medienasset abfangen kann78.

Es wurden 3 Ziele verfolgt (Goals), deren Erfolgsquote in Tabelle 6 abgebildet wurde:

  1. Die Schl├╝ssel f├╝r ein Medienasset werden abgefangen
  2. Der Angreifer ergreift Besitz von Logindaten eines vertrauensw├╝rdigen Users
  3. Der Angreifer kann ein DRM-gesch├╝tztes Video ÔÇ×im KlartextÔÇť lesen (mit o. ohne Keyinfo)

Der gro├če Erfolg des Angriffs auf namhafte Streamingseiten wie bbc.com unter Berufung auf wissenschaftliche Erkenntnisse l├Ąsst auf Fahrl├Ąssigkeit im Umgang mit urheberrechtlich gesch├╝tzten Medien und ein Unverst├Ąndnis der technologischen M├Âglichkeit zur effektiven Absicherung seitens der verantwortlichen Softwarehersteller schlie├čen.

Tabelle 7: Erfolgsquote beim experimentellen Angriff auf bekannte VoD-Dienste und ihre Medienverschl├╝sselung, 2015

Da sich die URI zur Keyinfo in der Index-Datei des jeweiligen Profils befinden muss, damit er von einem Standardplayer korrekt gelesen werden kann, muss auch ein eingebauter Zugriffskontrollalgorithmus entscheiden, ob der anfragende Client den Schl├╝ssel erhalten darf. Die Transport Stream Dateien mit dem Medieninhalt liegen auf einem ├Âffentlichen Webspace und werden unkompliziert und stateless an jeden anfragenden Client ├╝ber HTTP GET geliefert. Doch ohne die Keyinfo sind diese MPEG-TS Dateien nicht lesbar. Deswegen muss diese Information vor unbefugtem Zugriff effektiv gesch├╝tzt sein.

Der Schl├╝ssel f├╝r die diversen Medien-Assets kann periodisch neu aufgesetzt werden, was das Problem von sporadisch entschl├╝sselten Inhalten aufhebt. Deswegen ist ein wiederholbares Konfigurieren der Keyinfo der Medien-Assets von erheblichem Vorteil. Wenn die Keyinfos jedoch grunds├Ątzlich oft kompromittiert werden, hilft die Neuverschl├╝sselung nur bedingt. Des Weiteren gibt es im ├Ąu├čersten Fall aller Raubkopierschemas das sog. Screen Scraping, wonach der Raubkopierer mit einem Framegrabber die Bildschirmausgabe (sei es ein VGA- oder HDMI-Signal) abf├Ąngt und im Endeffekt unter Umgehung jeglicher urheberrechtlicher Schutzma├čnahmen (Verschl├╝sselung und DRM) Besitz von einer hochqualitativen Version des Medien-Assets ergreifen kann79. Die Industrie hat es nicht durchgesetzt, DRM-aufger├╝stete Grafikkarten zum Standard zu machen80. Deswegen kann ein Desktop-PC Besitzer grunds├Ątzlich allen technischen M├Âglichkeiten nachgehen und im ├Ąu├čersten Fall die Bildschirmausgabe mitschneiden, um an eine hochwertige und unverschl├╝sselte Kopie eines Videos zu kommen.

Ein Video muss jedoch nicht urheberrechtlich gesch├╝tzt sein, um f├╝r einen Raubkopierer von immenser Wichtigkeit zu sein. Falls sich eine mittlere oder gro├če Organisation f├╝r ein internes Videoportal entscheidet, muss sie davon ausgehen, dass ihre Konkurrenten potentiell in den Besitz von internen Aufzeichnungen gelangen k├Ânnen, wenn sie ÔÇĽ und davon ist auszugehen ÔÇĽ es lange genug probieren werden. Im Zeitalter der digitalen Industriespionage werden erhebliche Mittel verwendet, um Informationen geheim zu halten, die nicht f├╝r die ├ľffentlichkeit bestimmt sind. Videoaufnahmen mit Amateurkameras (Smartphones, usw.) sind schon heutzutage in jedem Nachrichtensender ein allt├Ągliches Stil- und Erz├Ąhlmittel. Eins der schockierenden Videos der letzten Jahre war der Abschuss des zivilen Fluges MH17 ├╝ber der Ukraine. Der Moment wurde von einem vorbeifahrenden PKW aus gefilmt81. Die Aufnahmen wurden anschlie├čend in Nachrichtensendern auf dem ganzen Erdball ausgestrahlt. ├ähnliche Videos werden t├Ąglich zur Dokumentation von Ereignissen bspw. in Krisengebieten gedreht. Falls eine Organisation sensible Assets auf einem privaten oder ├Âffentlichen Medienserver verwahrt, um Fakten, ihre Arbeit und historische Ereignisse zu dokumentieren, m├╝ssen die Medien vor dem Zugriff durch unbefugte Parteien, die Inhalte zweckentfremden oder anderweitig Kapital schlagen wollen, effektiv gesch├╝tzt werden.

In diesem Sinn ist Verschl├╝sselung ein relevantes Thema in allen Aspekten privater Videoserver, ergo Medienserver mit eingebautem Webencoder, die zur ad hoc-Distribution von Videoaufnahmen innerhalb einer politischen wie kommerziellen Organisation dienen.

4.5.2. Digital Rights Management

Digital Rights Management ist ein Industriestandard zur Sicherung von Verwertungsrechten im Internetverkehr. Im Fall vom HLS-Protokoll machen die jeweiligen DRM-Implementierungen Gebrauch vom vorgesehenen AES-Verschl├╝sselungsverfahren. Neben der reinen Verschl├╝sselung sieht DRM ein sicheres Verfahren zur Schl├╝ssel├╝bergabe vor.

E. Wu, S. Chuang und andere haben 2017 ihr Konzept eines ÔÇ×flexiblen und leichten DRM Systems f├╝r Multimediainhalte auf vielen mobilen HardwareplattformenÔÇť ver├Âffentlicht.

Abbildung 9: Media Content Delivery mit DRM-Unterst├╝tzung

Ihrem Konzept nach ist die Zugriffskontrolle auf den Schl├╝ssel zus├Ątzlich von einem Public Key Verfahren abh├Ąngig, das das Abgreifen der Keyinfo durch eine unbefugte Partei verhindern soll. Dar├╝berhinaus definieren DRM-Systeme die Verh├Ąltnisse der Userrechte zu den Inhalten.

Ein DRM System besteht grunds├Ątzlich aus zwei Hauptkomponenten82:

  1. Medienschutz (u.A. durch Verschl├╝sselung und Algorithmen zur Zugriffskontrolle); der effektive Schutz von urheberrechtlich gesch├╝tzten Medien vor unbefugten Konsumenten ist das Herzst├╝ck eines DRM Systems. Obwohl die Verschl├╝sselungsalgorithmen per se kein Bestandteil dieser Norm sind, legt sie dennoch die Voraussetzungen fest, die ein Verschl├╝sselungssystem unbedingt erf├╝llen muss, damit es in einem DRM System Anwendung finden kann.
  2. Rechteverwaltung im Sinne der Nutzungsrechte, die ein Benutzer f├╝r ein Medium zu bestimmten Konditionen erwerben kann. Der Medienanbieter kann die Einhaltung der Rechte durch den User z.T. mit technischen Mitteln (Verschl├╝sselung, Zugriffskontrolle) durchsetzen

Der Datenflow, der auf der Abbildung gezeigt wurde, gew├Ąhrleistet die Sicherheit der Medien-Assets durch folgende Schritte in der Aufbereitung und schlie├člich w├Ąhrend des Konsums eines Videos:

  1. Der Originalinhalt wird mit einem Content-Key verschl├╝sselt (die Keyinfo).
  2. Die Keyinfo wird zusammen mit einem privaten RSA Schl├╝ssel sowie einem symmetrischen Schl├╝ssel zu einer Lizenz generiert, die
    1. den Produktschl├╝ssel (die Medien-ID),
    2. die Ger├Ąte-ID sowie
    3. das Ablaufdatum enth├Ąlt.
  3. Der Inhalt wird an den Client ├╝bertragen. Dieser fragt beim Lizenzserver nach dem Content-Key und erh├Ąlt ihn nur, wenn die Informationen in der Lizenz auf den Client zutreffen.
  4. Der Content-Key wird mit dem ├Âffentlichen RSA Schl├╝ssel gelesen.
  5. Der User kann das Medien-Asset auf seinem Player konsumieren.

Ein so konzipiertes DRM System kann in der Praxis in allen Medienservern eingesetzt werden, die urheberrechtlich gesch├╝tzte Musik (GEMA, RIAA, Zaiks, etc.) sowie Filmproduktionen vertreiben. Allen anderen Anbietern bleibt es ├╝berlassen, ob sie ihre eigene Implementierung einer effektiven Medienverschl├╝sselung benutzen, oder die L├Âsung eines offiziellen DRM Anbieters in ihren Server integrieren. Eine leichtere und sichere Medienverschl├╝sselung ohne die komplexe Nutzungsrechtekomponente kann jedoch durch einen versierten Webentwickler realisiert werden. Nischenproduzenten, wie Musiker und Podcaster, k├Ânnen auf diese Weise ein Werkzeug zur Autoreklame sowie zum direkten Verwerten ihrer Kulturg├╝ter bekommen, ohne dabei auf grunds├Ątzliche Sicherheit ihrer Assets zu verzichten. Denn sie k├Ânnen Schutzmechanismen einsetzen, die bis dato alleine Urhebern zustanden, die den Verwertungsgesellschaften zugeh├Ârig waren. Es k├Ânnen neue, von den Urhebern zur├╝ckeroberte Verwertungssysteme auf dieser Basis entwickelt werden.

Ein light Version eines DRM Systems, wodurch ich alleine die effektive Verschl├╝sselung der Medienassets verstehe, kann also auch in Eigenregie in einer VoD-Architektur implementiert werden.

Abbildung 10: Typische DRM-Implementierung f├╝r mobile Clients83

Digital Rights Management (DRM)-Plugins hingegen erm├Âglichen den legalen Einsatz eines Medienservers im Vertrieb von urheberrechtlich gesch├╝tztem Material. Ein Vertrag mit einem Rechteverwerter und weitere juristische Anspr├╝che sind jedoch nicht Bestandteil eines DRM-Plugins, sondern m├╝ssen separat erworben werden. Zu den g├Ąngigen Anbietern geh├Âren BuyDRM (www.buydrm.com), Verimatrix (www.verimatrix.com), EZDRM (www.ezdrm.com) und andere.

DRM-Clients werden oft in Streaming Apps f├╝r Smartphones, Tablets oder Desktop-Computer verbaut, da so eine L├Âsung ebenfalls eine h├Âhere Sicherheit f├╝r den Herausgeber bietet. Des Weiteren verf├╝gen Set-Top-Boxen sowie viele andere Endger├Ąte ├╝ber die DRM Funktionalit├Ąt, da sie sonst die Inhalte vieler kommerzieller Anbieter nicht ausstrahlen d├╝rften. Es ist also ein Standard, der von der huxleyÔÇśschen sch├Ânen neuen Medienwelt nicht wegzudenken ist, weil der Endverbraucher meistens nicht wahr nimmt, dass hinter dem Medienkonsum eines Films oder eines Songs ein Verschl├╝sselungs- und Verwertungsmechanismus steckt.