-
Die
vorliegende Erfindung betrifft ein Verfahren zur Authentifikation
von in einem digitalen Übertragungssystem übertragenen
Daten.
-
Die
Ausstrahlungsübertragung
von digitalen Daten ist auf dem Gebiet der Bezahl-TV-Systeme wohlbekannt,
wobei verwürfelte
audiovisuelle Informationen gewöhnlich
per Satelliten- oder Satelliten-/Kabelverbindung zu einer Anzahl
von Teilnehmern gesendet werden, die jeweils einen Decoder besitzen,
der das übertragene
Programm zum nachfolgenden Betrachten entwürfeln kann. Es sind auch terrestrische
digitale Ausstrahlungssysteme bekannt. Neuere Systeme haben die
Ausstrahlungsverbindung auch zum Senden von anderen Daten zusätzlich zu
oder anstelle von audiovisuellen Daten, wie etwa Computerprogrammen
oder interaktiven Anwendungen, zu dem Decoder oder zu einem angeschlossenen
PC verwendet.
-
Ein
besondere Problem bei der Übertragung von
Anwendungsdaten ist in der Notwendigkeit begründet, die Integrität und den
Ursprung jeglicher solcher Daten zu verifizieren. Da Daten dieser
Art dazu verwendet werden können,
den Decoder umzukonfigurieren sowie eine beliebige Anzahl interaktiver
Anwendungen zu implementieren, ist es entscheidend, daß die empfangenen
Daten sowohl vollständig
sind als auch als aus einer bekannten Quelle stammend identifiziert
werden. Andernfalls können
Betriebsprobleme in Verbindung mit dem Herunterladen von unvollständigen Daten
entstehen, sowie das Risiko, daß der
Decoder gegenüber
Attacken durch Dritte oder dergleichen offen wird.
-
Das
Verifizieren der Integrität
solcher Daten kann durch Verifikation des Paketstroms von Daten, die
der Decoder direkt empfängt,
ausgeführt
werden. Vor der Übertragung
werden Pakete in der Regel durch Anwenden eines Hash-Algorithmus mindestens
auf einen Teil der Daten in dem Paket signiert. Der resultierende
Hash-Wert wird in dem Paket gespeichert. Beim Empfang des Datenpakets
wendet der Decoder denselben Hash-Algorithmus auf die Daten an und
vergleicht den durch den Decoder berechneten Hash-Wert mit dem in
dem verifizierten Paket gespeicherten Hash-Wert, um die Integrität der empfangenen
Daten zu verifizieren. Zum Beispiel im Fall eines Fehlers oder einer
Unterbrechung in der Übertragung
ist der berechnete Hash-Wert dann nicht derselbe wie der empfangene
Hash-Wert. Der Decoder wird dann auf die Anwesenheit möglicher Fehler
in dem heruntergeladenen Datenpaket hingewiesen und lädt das fehlerhafte
Datenpaket neu.
-
Ein
mit der Verwendung eines wohlbekannten Hash-Algorithmus, wie zum Beispiel dem Message
Digest Algorithm MD5, verbundenes Problem besteht darin, daß die Berechnung
des Hash-Werts gemäß einer öffentlich
bekannten Reihe von Berechnungsschritten ausgeführt wird, mit dem Ergebnis, daß beliebige
Personen den Hash-Wert eines Datenpakets berechnen können. Deshalb
wird es nicht möglich
sein, den Ursprung eines durch den Decoder empfangenen Datenpakets
zu verifizieren. Dies kann von besonderer Wichtigkeit sein, wenn
die empfangenen Daten die Betriebsdaten-Dateien des Decoders modifizieren.
-
Um
dieses Problem zu überwinden,
kann anstelle der Verwendung eines Hash-Algorithmus zur Berechnung
eines Hash-Werts für
mindestens einen Teil der Daten ein Signaturwert eines Datenpakets gemäß einem
Geheimschlüssel berechnet
werden, der nur der Sendeanstalt bekannt ist. Dieser Schlüssel kann
unter Verwendung eines symmetrischen Schlüsselalgorithmus erhalten werden,
wie zum Beispiel dem DES-Algorithmus (Data Encryption Standard),
wobei der Decoder einen äquivalenten
Schlüssel
speichert. Durch Verwendung eines asymmetrischen Algorithmus mit öffentlichen/privaten
Schlüsseln,
wie zum Beispiel dem RSA-Algorithmus
(Rivest, Shamir und Adleman), bei dem die öffentlichen und privaten Schlüssel komplementäre Teile
einer mathematischen Gleichung bilden, kann jedoch bessere Zweckmäßigkeit
bereitgestellt werden.
-
Die
für das
Produzieren der Datenpakete verantwortliche Sendeanstalt speichert
den privaten Schlüssel
und berechnet den Signaturwert unter Verwendung des privaten Schlüssels. Der öffentliche Schlüssel wird
in den Decodern, die die Daten empfangen sollen, durch Festcodieren
des öffentlichen Schlüssels in
den Speicher des Decoders während der
Herstellung gespeichert. Beim Empfang des Datenpakets verifiziert
der Decoder den Signaturwert unter Verwendung des gespeicherten öffentlichen Schlüssels durch
Vergleichen der empfangenen Daten mit dem Ergebnis des Anwendens
des Algorithmus mit dem öffentlichen
Schlüssel
auf den empfangenen Signaturwert.
-
Auch
in solchen sicheren Systemen ist es möglich, daß der Wert des privaten Schlüssels kompromitiert
wird, indem er zum Beispiel unrechtmäßig öffentlich verteilt wird. In
solchen Fällen
wird es notwendig, daß die
Sendeanstalt schnell die Verwendung des äquivalenten öffentlichen
Schlüssels
widerruft, um so einen unautorisierten Empfang von Datenpaketen
zu verhindern. Zusätzlich
wird auch notwendig, ein neues Paar aus öffentlichen/privaten Schlüsseln zu
verwenden. Deshalb wird die Sendeanstalt den in den Decodern rechtmäßiger Benutzer gespeicherten öffentlichen
Schlüssel
durch einen neuen öffentlichen
Schlüssel
ersetzen müssen.
Abhängig
von der Sensitivität
des öffentlichen
Schlüssels
kann dies erfordern, daß die
Sendeanstalt den kostspieligen und aufwendigen Rückruf dieser Decoder zum Hersteller
zur Festcodierung des neuen öffentlichen
Schlüssels
in die Speicher dieser Decoder organisiert.
-
GB 2301919 lehrt ein System
zur mehrschrittigen Signierung, das mehrere Signiereinrichtungen verwendet,
um eine einzige Signatur, die unter Verwendung eines einzigen öffentlichen
Verifikationsschlüssels
verifiziert werden kann, anzubringen. Jede Signiereinrichtung besitzt
einen Anteil des Signaturschlüssels
und bringt als Reaktion auf Autorisierung von mehreren Autorisierungsstellen
eine partielle Signatur an. Die Sicherheit des Systems wird durch
Verteilung der Fähigkeit
zum Anbringen von Signaturen auf mehrere Signiereinrichtungen und durch
Verteilen der Befugnis zum Anbringen einer partiellen Signatur auf
mehrere Autorisierungsstellen verbessert. Im Fall einer Verbreitung
des privaten Schlüssels
müssen
jedoch alle Empfänger
den öffentlichen
Verifikationsschlüssel
aktualisieren, was sowohl kostspielig als auch umständlich sein
kann, insbesondere weil wie oben beschrieben der Schlüssel z.
B. in einem Decoder fest codiert wird.
-
Aus
US 5,699,431 ist ein CRL
bekannt, das in regelmäßigen Intervallen
aktualisiert und durch eine Zertifizierungsautorität digital
signiert wird.
-
Mindestens
in ihren bevorzugten Ausführungsformen
versucht die vorliegende Erfindung, diese und andere Probleme zu
lösen,
indem eine gegenüber
Verbreitung eines privaten Schlüssels
beständige
Lösung
geschaffen wird.
-
Ein
erster Aspekt der vorliegenden Erfindung schafft ein digitales Signal
mit Daten und zwei verschlüsselten
Werten für
mindestens einen Teil der Daten, wobei jeder verschlüsselte Wert
unter Verwendung eines Schlüssels
eines jeweiligen Verschlüsselungsalgorithums
für dieselben
Daten bestimmt wird.
-
Bei
einer bevorzugten Ausführungsform
umfassen die Daten einen Schlüssel.
Die Daten können mindestens
ein digitales Zertifikat umfassen, das einen öffentlichen Schlüssel eines
Verschlüsselungsalgorithmus
zum Verarbeiten von Daten enthält.
Die Daten können
ferner mindestens ein digitales Wurzel-Zertifikat umfassen, das
einen öffentlichen Schlüssel eines
Verschlüsselungsalgorithmus
zum Verarbeiten von Daten enthält.
Das mindestens eine digitale Zertifikat kann ferner Anwendungen
umfassen, mit denen interaktive Anwendungen in dem Decoder, wie
zum Beispiel Netz-Browser, Quiz-Anwendungen, Programmanleitungen
usw., implementiert werden. Es kann auch Software heruntergeladen werden,
um die arbeitende digitale Signatur zu ändern, die unter Verwendung
eines privaten Schlüssels
des Verschlüsselungsalgorithmus
des in diesem Zertifikat enthaltenen öffentlichen Schlüssels berechnet
wird.
-
Bei
einer weiteren bevorzugten Ausführungsform
umfassen die Daten eine Kennung eines widerrufenen öffentlichen
Schlüssels.
Es ist vorteilhaft, daß die
Kennung eine Kennung eines den widerrufenen öffentlichen Schlüssel enthaltenden
digitalen Zertifikats umfaßt.
Es ist ferner vorteilhaft, daß die
Kennung eine Kennung eines den widerrufenen öffentlichen Schlüssel enthaltenden
digitalen Wurzel-Zertifikats umfaßt. Die Daten umfassen vorteilhafterweise
mehrere der Kennung, wobei jede Kennungen einen jeweiligen widerrufenen öffentlichen Schlüssel identifiziert.
-
Bei
einer weiteren bevorzugten Ausführungsform
werden die Daten und die zwei verschlüsselten Werte in einer Datendatei
organisiert.
-
Der
hier verwendete Ausdruck "Empfänger/Decoder" oder "Decoder" kann einen Empfänger zum
Empfangen entweder von codierten oder von nichtcodierten Signalen
wie zum Beispiel Fernseh- und/oder Rundfunksignalen bedeuten, die
ausgestrahlt oder durch bestimmte andere Mittel übertragen werden können. Der
Ausdruck kann auch einen Decoder zum Decodieren empfangener Signale
bedeuten. Ausführungsformen
solcher Empfänger/Decoder
können
einen mit dem Empfänger
integralen Decoder zum Decodieren der empfangenen Signale enthalten,
wie zum Beispiel in einem "Digitalreceiver", wobei ein solcher
Decoder in Kombination mit einem physisch getrennten Empfänger fungiert
oder ein solcher Decoder zusätzliche
Funktionen enthält, wie
etwa einen Web-Browser, oder mit anderen Einrichtungen, wie etwa
einem Videorekorder oder einem Fernsehapparat, integriert ist.
-
Im
vorliegenden Gebrauch umfaßt
der Ausdruck "digitales Übertragungssystem" jedes Übertragungssystem
zum Übertragen
oder Ausstrahlen zum Beispiel von primäraudiovisuellen oder Multimedia-Digitaldaten.
Obwohl die vorliegende Erfindung besonders für ein Ausstrahlungs-Digitalfernsehsystem
anwendbar ist, kann die Erfindung auch auf ein festes Telekommunikationsnetz
für Multimedia-Internetanwendungen,
auf Fernsehüberwachung
und so weiter anwendbar sein.
-
Im
vorliegenden Gebrauch umfaßt
der Ausdruck "digitales
Fernsehsystem" zum
Beispiel ein beliebiges Satelliten-, terrestrisches, Kabel- oder
anderweitiges System.
-
Geeignete
Algorithmen zur Verwendung bei der vorliegenden Erfindung zum Erzeugen
von privaten/öffentlichen
Schlüsseln
wären etwa
RSA, Fiat-Shamir oder Diffie-Hellman, und geeignete symmetrische
Schlüsselalgorithmen
wären zum
Beispiel Algorithmen des DES-Typs. Wenn es nicht im Hinblick auf
den Kontext obligatorisch oder anderweitig spezifiziert ist, wird
jedoch nicht zwischen mit symmetrischen Algorithmen assoziierten
Schlüsseln
und mit privaten/öffentlichen
Algorithmen assoziierten unterschieden.
-
Die
Ausdrücke "verwürfelt" und "verschlüsselt" und "Steuerwort" und "Schlüssel" wurden der Klarheit
der Sprache halber in verschiedenen Teilen im Text verwendet. Es
versteht sich jedoch, daß grundsätzlich nicht
zwischen "verwürfelten
Daten" und "verschlüsselten
Daten" oder zwischen
einem "Steuerwort" und einem "Schlüssel" zu unterscheiden
ist.
-
Außerdem wurden
in verschiedenen Teilen im Text der Klarheit der Sprache halber
die Ausdrücke "verschlüsselt" und "signiert" und "entschlüsselt" und "verifiziert" verwendet. Es versteht
sich jedoch, daß grundsätzlich nicht
zwischen "verschlüsselten Daten" und "signierten Daten" und "entschlüsselten Daten" und "verifizierten Daten" zu unterscheiden
ist.
-
Ähnlich soll
der Ausdruck "äquivalenter Schlüssel" einen Schlüssel bedeuten,
der dafür
ausgelegt ist, durch einen ersten erwähnten Schlüssel verschlüsselte Daten
zu entschlüsseln
oder umgekehrt.
-
Oben
beschriebene Merkmale in bezug auf Verfahrensaspekte der vorliegenden
Erfindung können
auch auf Vorrichtungsaspekte angewandt werden und umgekehrt.
-
Lediglich
als Beispiel wird nun eine bevorzugte Ausführungsform der Erfindung mit
Bezug auf die beigefügten
Figuren beschrieben. Es zeigen:
-
1 die
schematische Skizze eines digitalen Fernsehsystems zur Verwendung
mit der vorliegenden Erfindung;
-
2 die
Struktur eines Decoders des Systems von 1;
-
3 die
Struktur einer Anzahl von Komponenten in dem MPEG-Ausstrahlungstransportstrom;
-
4 die
Aufteilung einer Softwareanwendung in einer Anzahl von MPEG-Tabellen;
-
5 die
Beziehung zwischen DSM-CC-Datendateien und den letztendlich produzierten MPEG-Tabellen;
-
6 die
im Kontext von DSM-CC definierte Client-, Server-, Netzwerkmanagerbeziehung;
-
7 die
authentifizierten Verzeichnis-, Unterverzeichnis- und Dateiobjekte;
-
8 die
Formate eines Sendeanstalt-Zertifikats, eines Zertifizierungsautoritäts-Zertifikats
und eines Wurzel-Zertifizierungsautoritäts-Zertifikats;
-
9 zeigt
das Format einer Zertifikat-Widerrufliste;
-
10 zeigt
das Format einer Wurzel-Zertifikatverwaltungsnachricht
(RCMM – Wurzel
Certificate Management Message);
-
11 zeigt
die bei der Verarbeitung einer RCMM beim Empfang durch einen Decoder
beteiligten Schritte.
-
1 zeigt
eine Übersicht über ein
digitales Fernsehsystem 1 gemäß der vorliegenden Erfindung.
Die Erfindung umfaßt
ein größtenteils
herkömmliches
digitales Fernsehsystem 2, das das bekannte MPEG-2-Kompressionssystem
zum Übertragen
komprimierter digitaler Signale verwendet. Ausführlicher empfängt der
MPEG-2-Kompressor 3 in einer Ausstrahlungszentrale einen
digitalen Signalstrom (typischerweise einen Strom von Videosignalen).
Der Kompressor 3 ist durch die Verknüpfung 5 mit einem
Multiplexer und Verwürfler 4 verbunden.
-
Der
Multiplexer 4 empfängt
mehrere weitere Eingangssignale, assembliert den Transportstrom und
sendet komprimierte digitale Signale zu einem Sender 6 der
Ausstrahlungszentrale über
die Verknüpfung 7,
die natürlich
vielfältige
Formen annehmen kann, wie zum Beispiel Telekommunikationsverbindungen.
Der Sender 6 sendet elektromagnetische Signale über die
Aufwärtsverbindung 8 zu
einem Satellitentransponder 9, und dort werden sie elektronisch
verarbeitet und über
die angenommene Abwärtsverbindung 10 zu
dem Bodenempfänger 12 ausgestrahlt,
der gewöhnlich
in Form einer dem Endbenutzer gehörenden oder verliehenen Schüssel vorliegt.
Die von dem Empfänger 12 empfangenen
Signale werden zu einem dem Endbenutzer gehörenden oder verliehenen integrierten
Empfänger/Decoder 13 übertragen
und mit dem Fernsehapparat 14 des Endbenutzers verbunden.
Der Empfänger/Decoder 13 decodiert
das komprimierte MPEG-2-Signal zu einem Fernsehsignal für den Fernsehapparat 14.
-
Es
sind natürlich
andere Transportkanäle
für die Übertragung
der Daten möglich,
wie zum Beispiel terrestrische Ausstrahlung, Kabelübertragung,
kombinierte Satelliten-/Kalbelverbindungen, Telefonnetze usw.
-
In
einem mehrkanaligen System behandelt der Multiplexer 4 Audio-
und Videoinformationen, die aus einer Anzahl paralleler Quellen
empfangen werden, und interagiert mit dem Sender 6, um
die Informationen auf einer entsprechenden Anzahl von Kanälen auszustrahlen.
Zusätzlich
zu audiovisuellen Informationen können Nachrichten oder Anwendungen oder
eine beliebige andere Art von digitalen Daten in bestimmte oder
alle dieser Kanäle
mit dem übertragenen
digitalen Audio- und Videoinformationen verschachtelt eingeführt werden.
In einem solchen Fall wird ein Strom digitaler Daten zum Beispiel
in Form von Software-Dateien und Nachrichten des Formats DSM-CC
(Digital Storage Media Command and Control) durch den Kompressor 3 komprimiert
und in das MPEG-Format paketiert. Das Herunterladen von Softwaremodulen
wird später
ausführlicher
beschrieben.
-
Mit
dem Multiplexer 4 und dem Empfänger/Decoder 13 ist
ein System 15 mit bedingtem Zugang verbunden und befindet
sich teilweise in der Ausstrahlungszentrale und teilweise im Decoder.
Es ermöglicht
dem Endbenutzer den Zugang zu digitalen Fernsehausstrahlungen von
einem oder mehreren Ausstrahlungsanbietern. In den Empfänger/Decoder
kann eine Chipkarte eingefügt
werden, die in der Lage ist, Nachrichten in bezug auf kommerzielle Angebote
(das heißt,
eines oder mehrere von dem Ausstrahlungsanbieter verkaufte Fernsehprogramme)
zu dechiffrieren. Unter Verwendung des Decoders 13 und
der Chipkarte kann der Endbenutzer kommerzielle Angebote entweder
in einem Abonnementmodus oder in einem Pay-per-View-Modus erwerben.
In der Praxis kann der Decoder dafür ausgelegt sein, Mehrfachzugangs-Steuersysteme zu
handhaben, wie zum Beispiel das Simulcrypt- oder Multicrypt-Design.
-
Wie
bereits erwähnt,
werden durch das System übertragene
Programme in dem Multiplexer 4 verwürfelt, wobei die auf eine gegebene Übertragung angewandten
Bedingungen und Verschlüsselungsschlüssel durch
das Zugangssteuersystem 15 bestimmt werden. Die Übertragung
von verwürfelten Daten
auf diese Weise ist auf dem Gebiet der Bezahlungs-TV-Systeme wohlbekannt.
In der Regel werden verwürfelte
Daten zusammen mit einem Steuerwort zum Entwürfeln der Daten übertragen,
wobei das Steuerwort selbst durch einen sogenannten Ausnutzungsschlüssel verschlüsselt und
in verschlüsselter
Form übertragen
wird.
-
Die
verwürfelten
Daten und das verschlüsselte
Steuerwort werden dann durch den Decoder 13 empfangen,
der Zugang zu einem Äquivalent
des Ausnutzungsschlüssels
hat, das auf einer in den Decoder eingefügten Chipkarte gespeichert
ist, um das verschlüsselte
Steuerwort zu entschlüsseln
und danach die übertragenen
Daten zu entwürfeln.
Ein Teilnehmer, der bezahlt hat, wird zum Beispiel in einer ausgestrahlten
monatlichen EMM (Entitlement Management Message – Berechtigungsverwaltungsnachricht)
den Ausnutzungsschlüssel
empfangen, der notwendig ist, um das verschlüsselte Steuerwort zu entschlüsseln, um
so das Anschauen der Übertragung
zu gestatten. Zusätzlich
zu ihrer Verwendung beim Entschlüsseln
von audiovisuellen Fernsehprogrammen können ähnliche Ausnutzungsschlüssel für die Verwendung
bei der Verifikation anderer Daten, wie zum Beispiel von Softwaremodulen,
erzeugt und übertragen
werden, wie nachfolgend beschrieben werden wird.
-
Ein
interaktives System 16, das auch mit dem Multiplexer 4 und
dem Empfänger/Decoder 13 verbunden
ist und sich wieder teilweise in der Ausstrahlungszentrale und teilweise
im Decoder befindet, ermöglicht
dem Endbenutzer eine Interaktion mit verschiedenen Anwendungen über einen
Modem-Rückkanal 17.
Der Modem-Rückkanal
kann auch für
in dem System 15 mit bedingtem Zugang verwendete Übermittlungen
verwendet werden. Ein interaktives System kann zum Beispiel verwendet werden,
um es dem Zuschauer zu ermöglichen,
unmittelbar mit der Übertragungszentrale
zu kommunizieren, um eine Autorisierung für das Anschauen eines bestimmten
Ereignisses, das Herunterladen einer Anwendung usw. anzufordern.
-
Physische
Elemente des Empfängers/Decoders
Mit Bezug auf 2 werden nun die physischen Elemente
des Empfängers/Decoders 13 bzw.
Digitalreceivers, die für
die Verwendung in der vorliegenden Erfindung ausgelegt sind, kurz
beschrieben. Die in dieser Figur gezeigten Elemente werden als Funktionsblöcke beschrieben.
-
Der
Decoder 13 umfaßt
einen zentralen Prozessor 20 mit assoziierten Speicherelementen,
der dafür
ausgelegt ist, Eingangsdaten von einer seriellen Schnittstelle 21,
einer parallelen Schnittstelle 22 und einem Modem 23 (verbunden
mit dem Modem-Rückkanal 17 von 1)
zu empfangen.
-
Der
Decoder ist zusätzlich
dafür ausgelegt, über eine
Steuereinheit 26 Eingaben von einer Infrarot-Fernbedienung 25 und
von Schalterkontakten 24 auf der Vorderseite des Decoders
zu empfangen. Der Decoder besitzt außerdem zwei Chipkartenlaser 27, 28,
die dafür
ausgelegt sind, Bank- und Abonnement-Chipkarten 29 bzw. 30 zu
lesen. Eingaben können
auch über
eine (nicht gezeigte) Infrarot-Tastatur empfangen werden. Der Abonnement-Chipkartenleser 28 tritt
mit einer eingefügten
Abonnement-Karte 30 und einer Einheit 29 für bedingten
Zugang in Wechselwirkung, um einem Demultiplexer/Entwürfler 30 das
notwendige Steuerwort zuzuführen,
um die Entwürflung
des verschlüsselten
ausgestrahlen Signals zu ermöglichen.
Der Decoder enthält
außerdem einen
herkömmlichen
Tuner 31 und Demodulator 32 zum Empfangen und
Demodulieren der Satellitenübertragung
vor dem Filtern und Demultiplexen durch die Einheit 30.
-
Die
Verarbeitung von Daten in den Decoder wird im allgemeinen durch
den zentralen Prozessor 20 abgewickelt. Die Softwarearchitektur
des zentralen Prozessors entspricht einer virtuellen Maschine, die
mit einem Betriebssystem auf niedrigerer Ebene in Wechselwirkung
tritt, das in den Hardwarekomponenten des Decoders implementiert
wird.
-
Paketstruktur übertragener
Daten
-
Mit
Bezug auf 3 und 4 wird nun
die Paketstruktur von Daten in dem von dem Sender zum Decoder gesendeten
ausgestrahlten MPEG-Transportstrom beschrieben. Es versteht sich,
daß, obwohl sich
die Beschreibung auf das im MPEG-Standard verwendete
Tabulationsformat konzentriert, dieselben Prinzipien gleichermaßen für andere
paketierte Datenstromformate gelten.
-
Insbesondere
mit Bezug auf 3 enthält ein MPEG-Bitstrom eine Programmzugangstabelle ("PAT") 40 mit
einer Paketindentifikation ("PID") von 0. Die PAT
enthält
Verweise auf die PID der Programmabbildungstabellen ("PMTs") 41 einer
Anzahl von Programmen. Jede PMT enthält einen Verweis auf die PID
der Ströme
der Audio-MPEG-Tabellen 42 und Video-MPEG-Tabellen 43 für dieses
Programm. Ein Paket mit einer PID von null, das heißt, die
Programmzugangstabelle 40, stellt den Eintrittspunkt für jeglichen
MPEG-Zugang bereit.
-
Um
Anwendungen und Daten dafür
herunterzuladen, werden zwei neue Stromtypen definiert, und die
relevante PMT enthält
außerdem
Verweise auf die PID der Ströme
von Anwendungs-MPEG-Tabellen 44 (oder
Teile dieser) und Daten-MPEG-Tabellen 45 (oder
Teile dieser). Während
es in bestimmten Fällen
zweckmäßig sein
kann, separate Stromtypen für
ausführbare
Anwendungssoftware und Daten zur Verarbeitung durch solche Software
zu definieren, ist dies tatsächlich
nicht entscheidend. Bei anderen Realisierungen können Daten und ausführbarer
Code in einem einzigen Strom assembliert werden, auf dem wie beschrieben über die
PMT zugegriffen wird.
-
Mit
Bezug auf 4 wird, um zum Beispiel eine
Anwendung in einem Strom 44 herunterzuladen, die Anwendung 46 in
Module 47 unterteilt, die jeweils durch eine MPEG-Tabelle
gebildet werden. Bestimmte dieser Tabellen umfassen eine einzige
Sektion, während
andere aus mehreren Sektionen 48 bestehen können. Eine
typische Sektion 48 besitzt einen Kopfteil, der eine Ein-Byte-Tabellenidentifikation ("TID") 50 enthält, die
Sektionsnummer 51 dieser Sektion in der Tabelle, die Gesamtzahl 52 der
Sektionen in dieser Tabelle und eine Zwei-Byte-TID-Erweiterungsreferenz 53.
Jede Sektion enthält
außerdem
einen Datenteil 54 und einen CRC 55. Für eine bestimmte
Tabelle 47 besitzen alle Sektionen 48, aus denen
diese Tabelle 47 besteht, dieselbe TID 50 und dieselbe
TID-Erweiterung 53. Für
eine bestimmte Anwendung 46 besitzen alle Tabellen 47,
aus denen diese Anwendung 46 besteht, dieselbe TID 50,
aber verschiedene jeweilige TID-Erweiterungen.
-
Für jede Anwendung 46 wird
eine einzige MPEG-Tabelle als Verzeichnistabelle 56 verwendet. Die
Verzeichnistabelle 56 besitzt in ihrem Kopfteil dieselbe
TID wie die anderen Tabellen 47, aus denen die Anwendung
besteht. Für
Identifikationszwecke und aufgrund des Umstands, daß nur eine
einzige Tabelle für
die Informationen in dem Verzeichnis benötigt wird, besitzt die Verzeichnistabelle
jedoch eine vorbestimmte TID-Erweiterung von null. Alle anderen Tabellen 47 besitzen
normalerweise von null verschiedene TID-Erweiterungen und bestehen
aus einer Anzahl assoziierter Sektionen 48. Der Kopfteil der
Verzeichnistabelle enthält
außerdem
eine Versionsnummer der herunterzuladenden Anwendung.
-
Wieder
mit Bezug auf 3 werden die PAT 40,
die PMT 41 und Anwendungs- und Datenstromkomponenten 44, 45 zyklisch übertragen.
Jeder Anwendung, die übertragen
wird, besitzt eine jeweilige vorbestimmte TID. Um eine Anwendung
herunterzuladen, wird die MPEG-Tabelle mit der entsprechenden TID
und einer TID-Erweiterung von null in dem Empfänger/Decoder heruntergeladen.
Dabei handelt es sich um die Verzeichnistabelle für die erforderliche Anwendung.
Die Daten in dem Verzeichnis werden dann durch den Decoder verarbeitet,
um die TID-Erweiterungen der Tabellen zu bestimmen, aus denen die
erforderliche Anwendung besteht. Danach kann eine etwaige erforderliche
Tabelle mit derselben TID wie die Verzeichnistabelle und einer aus
dem Verzeichnis bestimmten TID-Erweiterung heruntergeladen werden.
-
Der
Decoder ist dafür
ausgelegt, die Verzeichnistabelle auf eine etwaige Aktualisierung
dieser zu prüfen.
Dies kann durch periodische erneutes Herunterladen der Verzeichnistabelle,
zum Beispiel alle 30 Sekunden oder eine oder fünf Minuten und Vergleichen
der Versionsnummer der zuvor heruntergeladenen Verzeichnistabelle
geschehen. Wenn die frisch heruntergeladene Versionsnummer die einer späteren Version
ist, werden die mit der vorherigen Verzeichnistabelle assoziierten
Tabellen gelöscht und
die mit der neuen Version assoziierten Tabellen heruntergeladen
und assembliert.
-
Bei
einer alternativen Anordnung wird der ankommende Bitstrom unter
Verwendung einer Maske gefiltert, die der TID, TID-Erweiterung und
Versionsnummer entspricht, mit Werten, die für die TID der Anwendung gesetzt
werden, einer TID-Erweiterung von null und einer Versionsnummer
von eins größer als
die Versionsnummer des gerade heruntergeladenen Verzeichnisses.
Folglich kann eine Vergrößerung der
Versionsnummer detektiert werden, und nach Detektion wird wie oben
beschrieben das Verzeichnis heruntergeladen und die Anwendung aktualisiert.
Wenn eine Anwendung zu beenden ist, wird eine leeres Verzeichnis
mit der nächsten
Versionsnummer übertragen,
aber ohne jegliche in dem Verzeichnis aufgelistete Module. Der Decoder
2020 ist dafür
programmiert, als Reaktion auf den Empfang eines solchen leeren
Verzeichnisses die Anwendung zu löschen.
-
In
der Praxis können
Software- und Computerprogramme zum Implementieren von Anwendungen
in dem Decoder über
beliebige der Teile des Decoders eingeführt werden, insbesondere in
dem über die
Satellitenverbindung wie beschrieben empfangenen Datenstrom, aber
auch über
den seriellen Port, die Chipkartenverbindung usw. Solche Software kann
eine Konfiguration auf hoher Ebene der Decodersoftware zum Beispiel
mittels "Patches" oder dergleichen
umfassen.
-
Anwendungen
können
auch über
den Decoder heruntergeladen und zu einem mit dem Decoder verbundenen
PC oder dergleichen gesendet werden. In einem solchen Fall wirkt
der Decoder als ein Kommunikationsrouter für die Software, die letztendlich auf
der verbundenen Einrichtung ausgeführt wird. Zusätzlich zu
dieser Routing-Funktion kann der Decoder auch wirken, um die MPEG-paketierten
Daten vor dem Routen zu dem PC in Computerdateisoftware zu konvertieren,
die zum Beispiel gemäß dem Protokoll
DSM-CC (siehe unten) organisiert wird.
-
Organisation von Daten in
Datendateien
-
5 zeigt
die Beziehung zwischen Daten, die in einer Menge von Datendateien
60 des
Typs DSM-CC U-U (user to user – Benutzer
zu Benutzer) organisiert sind, in einer assemblierten Anwendung
46 und
eingekapselt in einer Reihe von MPEG-Tabellen
47. Eine
solche Beziehung wird in
WO99/49614 beschrieben.
-
Vor
der Übertragung
werden die Datendateien zu der Anwendung 46 assembliert
und danach durch den MPEG-Kompressor
zu MPEG-Tabellen oder Modulen 47 paketiert, wie oben beschrieben
mit einem Kopfteil 49, der für den MPEG-Paketstrom spezifisch ist und Tabellen-ID,
Versionsnummer usw. enthält.
Es ist ersichtlich, daß möglicherweise
keine feste Beziehung zwischen den in den Datendateien 61 organisierten
Daten und den letztendlichen MPEG-Tabellen 47 besteht.
Nach dem Empfang und Filtern durch den Decoder werden die Paketkopfteile 49 verworfen
und die Anwendung 46 aus den Nutzinformationen der Tabellen 47 wieder
hergestellt.
-
Das
DSM-CC-Format für
Datendateien ist ein Standard, der insbesondere für die Verwendung in
Multimedianetzwerken ausgelegt ist und der eine Reihe von Nachrichtenformaten
und Sitzungsbefehlen für
die Kommunikationen zwischen einem Client-Benutzer 70,
einem Server-Benutzer 71 und einem Netzwerkressourcenmanager 72 (siehe 6) definiert.
Der Netzwerkressourcenmanager 72 kann als logische Entität betrachtet
werden, die wirkt, um die Zuordnung von Ressourcen in einem Netzwerk zu
verwalten.
-
Die
Kommunikation zwischen einem Client und einem Server wird durch
eine Reihe von Sitzungen hergestellt, wobei eine erste Reihe von
Nachrichten zwischen einem Benutzer (Client 70 oder Server 71)
und dem Netzwerkmanager 72 ausgetauscht wird, um den Client
und/oder Server für
Kommunikation zu konfigurieren. Solche Nachrichten werden gemäß dem Protokoll
mit dem Namen DSM-CC U-N (user to network – Benutzer zu Netzwerk) formatiert. Insbesondere
für das
Ausstrahlungs-Herunterladen von Daten wurde eine Teilmenge dieses
Protokolls definiert.
-
Nachdem
eine Kommunikationsverbindung hergestellt wurde, werden danach Nachrichten
zwischen Client 70 und Server 71 gemäß dem Protokoll DSM-CC
U-U ausgetauscht. Eine Nachrichtensequenz dieser Art entspricht
den Datendateien 60 von 5. Im Fall
von Nachrichten von DSM-CC U-U werden Daten in einer Reihe von Nachrichten 61 organisiert,
die gemäß dem BIOP
(Broadcast InterOrb Protocol) gruppiert werden.
-
Jede
Nachricht bzw. jedes Objekt 61 umfaßt einen Kopfteil 62,
einen Subkopfteil 63 und Nutzinformationen 64,
die die Daten selbst enthalten. Gemäß dem BIOP-Protokoll enthält der Kopfteil 62 u.
a. eine Indikation des Typs der Nachricht und der BIOP-Version,
während
der Subkopfteil den Typ des Objekts und andere durch den Systemarchitekt
zu definierende Informationen angibt.
-
Datenobjekte 64 in
den Nutzinformationen von DSM-CCU-U-Dateien können im allgemeinen als einer
von drei Typen definiert werden: Verzeichnungsobjekte, Dateiobjekte
und Stream-Objekte. Verzeichnisobjekte definieren Wurzelverzeichnisse oder
Unterverzeichnisse, die zum Referenzieren einer Reihe assoziierter
Dateiobjekte verwendet werden, die die eigentlichen Anwendungsdaten
enthalten. Stream-Objekte können
verwendet werden, um die Herstellung einer zeitlichen Beziehung
zwischen in den Datendateien enthaltenen Daten und dem MPEG-Paketstrom
selbst zu ermöglichen.
Dies kann zum Beispiel im Fall von interakiven Anwendungen verwendet
werden, die in den Datendateien enthalten und dafür ausgelegt
sind, mit den durch den Decoder empfangene und verarbeiteten elementaren Video-
oder Audioströme
synchronisiert zu werden. Wie bereits erwähnt, kann ansonsten keine direkte Korrelation
zwischen den MPEG-paketierten Daten und den Datendateien bestehen.
-
Im
Gegensatz zu den MPEG-Tabellen, bei denen ein einziges Verzeichnis
eine Menge von Tabellen mit nur einer einzigen Hierarchieebene referenziert,
können
die Datendateien 60 auf relativ komplexere hierarchische
Weise organisiert werden. Wie bei in einem PC oder Server gespeicherten
Dateien kann ein Haupt- oder Würfelverzeichnis
auf eines oder mehrere Unterverzeichnisse verweisen, die ihrerseits
auf eine zweite Ebene von Datendateien verweisen. Es kann sogar
auf ein zweites Würfelverzeichnis
verwiesen werden, das mit einer anderen Menge von Anwendungsdaten
assoziiert ist.
-
Dateistruktur für eine Menge
von Datendateien
-
Mit
Bezug auf 7 ist ein Beispiel für die Dateistruktur
für eine
Menge von Datendateien gezeigt. Ein bei 75 gezeigtes Wurzelverzeichnis
DIR AO referenziert eine Gruppe von Unterverzeichnissen AI auf Objektdateien 77.
Der Klarheit halber ist nur eine einzige Gruppe von Objektdateien
F1, F2 usw., die mit dem Unterverzeichnis A4 assoziiert ist, gezeigt.
In der Praxis können
durch jedes der Unterverzeichnisse A1 bis A4 eine Anzahl von Gruppen von
Objektdateien referenziert werden.
-
In
jedem Verzeichnis und Unterverzeichnis wird eine Menge von Authentifizierungsschritten
für die
mit diesem Verzeichnis verknüpften
Dateien eingeführt.
Mit Bezug auf das Wurzelverzeichnis 75 umfaßt der Subkopfteil 63 einen
Hash-Wert, der durch Anwenden eines Hash-Algorithmus auf bestimmte oder
alle der den bei 76 angegebenen Unterverzeichnisdateien
A1 bis A4 gespeicherten Daten erhalten wird. Der verwendete Hash-Algorithmus
kann von beliebiger bekannter Art sein, wie zum Beispiel der Message
Digest Algorithm MD5.
-
Bei
einer Realisierung kann der Algorithmus auf jede assoziierte Datei
oder jedes assoziierte Unterverzeichnis individuell angewandt und
einer Liste der Hash-Werte für
jedes Unterverzeichnis 76 vor der Übertragung in dem Wurzelverzeichnis 75 gespeichert
werden. Obwohl eine solche Lösung
im Hinblick auf das Verifizieren jedes Unterverzeichnisses einen erhöhten Grad
an Prüfauflösung ermöglicht,
kann diese Lösung
im Hinblick auf die Verarbeitungszeit, die der Decoder benötigt, um
die entsprechenden Signaturen zu berechnen, relativ ineffizient
sein. Folglich umfaßt
der Subkopfteil 63 des Verzeichnisses 79 vorzugsweise
einen kumulativen Hash-Wert 79, der durch Anwenden des
MD5-Hash-Algorithmus auf die kombinierten Subkopfteil- und Nutzinformationssektionen 63, 64 der
Unterverzeichnisse 76 berechnet wird, das heißt ohne
den Kopfteil 62. Insbesondere werden die Hash-Werte 82,
die in den Unterverzeichnissen 76 enthalten sind und auf
die Schicht der Dateiobjekte 77 verweisen, in diese Hash- Berechnung aufgenommen.
-
Im
Fall des in 7 gezeigten Unterverzeichnisses
A4 verweist dieses Unterverzeichnis selbst auf eine Menge von Objektdateien
FI-Fn, die bei 77 angegeben ist. In diesem Fall wird ein
kumulativer Hash-Wert 82 für die komibinierten Inhalte
der Objektdateien 77 erzeugt. Dieser Wert wird in den Hash-Prozeß aufgenommen
und führt
zu dem Hash-Wert 79. Es ist deshalb nicht möglich, irgendwelche
der Objektdateien 77 zu ändern, ohne den Hash-Wert 82 des
Unterverzeichnisses 76 zu ändern, wodurch wiederum der
Hash-Wert 79 des Verzeichnisses 75 geändert wird.
-
Im
vorliegenden Fall wird ein komibinierter Hash-Wert für alle in
dem Verzeichnis referenzierten Unterverzeichnisse A1-A4 berechnet.
Dieser Hash-Wert wird zusammen mit einer Kennung der Gruppe von
Unterverzeichnissen, woraus die Daten entnommen wurden, gespeichert.
Bei anderen Ausführungsformen
kann eine Reihe kombinierter oder individueller Hash-Werte und entsprechender
Kennungen in dem Subkopfteil des Verzeichnisses gespeichert werden.
-
Zum
Beispiel kann auch eine zweite Menge von Unterverzeichnissen, die
auch mit dem Wurzelverzeichnis. assoziiert ist, aber eine andere
Menge von Daten oder ausführbarem
Code betrifft, zusammengruppiert werden und es kann ein kumulativer Hash-Wert
für diese
Unterverzeichnisse berechnet und in dem Subkopfteil-Wurzelverzeichnis
gespeichert werden. Ein mit einem einzigen Verzeichnis assoziierter
einzelner Hash-Wert kann gleichermaßen in dem Subkopfteil des
Wurzelverzeichnisses gespeichert werden.
-
Die
Autorisierung von Gruppen oder individuellen Datendateien verhindert
natürlich
nicht, daß das
Wurzelverzeichnis (oder tatsächlich
jede andere Datei) auch auf nichtvalidierte oder nichtgehashte Datendateien
verweist, aber das Fehlen einer Validierung einer solchen Datei
wird bei jeglichen Operationen mit dieser Datei berücksichtigt
werden müssen.
In dieser Hinsicht kann es zum Beispiel nicht notwendig sein, Stream-Objekte
zu authentifizieren.
-
Die
Verwendung einer Hash-Funktion ermöglicht es in diesem Fall primär dem Decoder,
die Integrität
oder Vollständigkeit
der heruntergeladenen Datendateien zu verifizieren. Zum Beispiel
im Fall eines Fehlers oder einer Unterbrechung in der Übertragung
ergibt die Operation eines kumulativen Hash-Algorithmus an den empfangenen
abhängigen Dateien
nicht dasselbe Ergebnis wie der in dem Wurzelverzeichnis gespeicherte
Hash-Wert für
diese Dateien. Der Decoder wird dann auf die Anwesenheit möglicher
Fehler in den heruntergeladenen Daten hingewiesen und wird die fehlerhaften
Datendateien neu laden.
-
Signaturwert für das Wurzelverzeichnis
-
Für verbesserte
Sicherheit wird ein Signaturwert für das Wurzelverzeichnis 75 berechnet.
Bei dieser Ausführungsform
wird ein Algorithmus mit privaten/öffentlichen Schlüsseln verwendet,
wie etwa der RSA-Algorithmus (Rivest, Shamir und Adleman), wobei
die Sendeanstalt dafür
verantwortlich ist, die den Privatschlüsselwert, die von den Decodern
gehaltenen Werte des öffentlichen
Schlüssels,
besitzenden Datendateien zu produzieren. Als Alternative kann der
Geheimschlüssel
einem Schlüssel
entsprechen, der durch einen symmetrischen Schlüsselalgorithmus, wie etwa den
DES- Algorithmus
(Data Encryption Standard) erhalten wird.
-
Wie
in 7 gezeigt, umfaßt das Wurzelverzeichnis 75 eine
Sendeanstalt-Kennung 80, die dem Decoder den öffentlichen
Schlüssel
identifiziert, der in der Verifizierungsphase zusammen mit dem unter Verwendung
des privaten Schlüssels
der Sendeanstalt erzeugten berechneten Signaturwert 81 zu
verwenden ist. In diesem Fall wird der Signaturwert 81 erzeugt,
indem der von der Sendeanstalt gehaltene private Schlüssel auch
bestimmte oder alle der Daten in dem Verzeichnis 75 angewandt
wird, wobei vorzugsweise die Nutzinformationsdaten 64 und/oder der
kumulative Hash-Wert bzw. die kumulaten Werte 79 eingeschlossen
sind. Der Decoder kann dann diesen Signaturwert 81 unter
Verwendung des entsprechenden, durch die Sendeanstalt-Kennung sich
identifizierten öffentlichen
Schlüssels
verifizieren.
-
In
diesem Beispiel sind die Daten in dem Verzeichnis 75 nicht
verschlüsselt,
und der private Schlüssel
dient lediglich zum Bereitstellen eines durch den öffentlichen
Schlüssel
verifizierbaren Signaturwerts. Bei alternativen Ausführungsformen
können
bestimmte oder alle der Inhalte des Verzeichnisses durch den privaten
Schlüssel
verschlüsselt
und danach durch einen entsprechenden Schlüssel entschlüsselt werden.
-
In
jedem Fall ermöglicht
die Erzeugung eines Signaturwerts oder Blocks verschlüsselten
Codes durch Verwendung eines Geheimschlüssels einem Decoder, Integrität und Ursprung
des Verzeichnisses 75 und als Folge Integrität und Ursprung
der Dateien, auf die dieses Wurzelverzeichnis verweist, zu verifizieren.
Da die kumulativen Hash-Werte für
die referenzierten Dateien in der Berechnung der Signatur 81 eingeschlossen
sind, ist es nicht möglich,
diese Werte zu ändern,
ohne daß dies
in der Verifizierungsphase detektiert wird. Da jeder Hash-Wert im
allgemeinen für
eine gegebene Menge von Daten einzigartig ist, wäre es deshalb nicht möglich, den
Inhalt irgendwelcher abhängiger
gehashter Dateien zu ändern, ohne
ihren charakteristischen Hash-Wert und dadurch den resultierenden
Signaturwert eines Verzeichnisses zu ändern.
-
Es
versteht sich, daß eine
Anzahl von Varianten möglich
sein kann, wie etwa zum Reduzieren der Menge an in jeder Phase gehashten
oder signierten Daten. Insbesondere kann im Fall einer Signatur oder
eines Hash-Werts in einem Verzeichnis oder Unterverzeichnis, womit
eine Datendatei niedrigerer Ebene verifiziert wird, die Verzeichnissignatur
bzw. der Hash-Wert erzeugt werden, indem man nur den Hash-Wert der niedrigeren
Ebene und keine anderen Daten verwendet. Zum Beispiel kann der kombinierte Hash-Wert 70 in
dem AO-Verzeichnis 75 unter Verwendung der komibinierten
Hash-Werte 82, 83 jeder der bei 76 angegebenen
Unterverzeichnisse A1-A4 erzeugt werden. Da diese Werte genauso
einzigartig wie die Daten in den Nutzinformationen des Unterverzeichnisses
sind, ist der kombinierte Hash-Wert 79 immer noch einzigartig
für die
betreffenden Unterverzeichnisse. Weiterhin kann immer noch die Integrität der niedrigeren
Ebene von Objekt- und Verzeichnisdateien 77, 78 angenommen
werden, da die Hash-Werte 82 immer
noch in der Berechnung verwendet werden.
-
Digitale Zertifikate der Sendeanstalt
-
Mit
Bezug auf 8 werden der öffentliche Schlüssel 91 und
die Sendeanstalt-Kennung 80 dem Benutzer des Decoders in
einem digitalen Zertifikat gegeben, und zwar vorzugsweise in Form
des wohlbekannten Standards X.509 der ISO (International Standards
Organisation), das während
der Herstellung in den Speicher des Decoders fest codiert wird. Solche
Zertifikate werden von vertrauenswürdigen Dritten, die gewöhnlich als
Zertifizierungsautoritäten (CA)
bezeichnet werden, an die Hersteller verteilt. Die Verwendung solcher
Zertifikate wird hauptsächlich
wegen des von Netscape Communications zur Sicherung von Kreditkartentransaktionen über das World
Wide Web (WWW) entwickelten und standardisierten sicheren Transportprotokolls
der SSL (Secure Socket Layer) immer weiter verbreitet.
-
Neben
dem öffentlichen
Schlüssel 91 und der
Sendeanstalt-Kennung 80 enthält das mit
der Sendeanstalt assoziierte digitale Zertifikat bzw. Sendeanstalt-Zertifikat 90 außerdem folgendes:
- • eine
Versionsnummer 92 des Sendeanstalt-Zertifikats 90;
- • eine
Seriennummer 93 des Sendeanstalt-Zertifikats 90;
- • eine
CA-Identität 94 der
CA, die das Sendeanstalt-Zertifikat 90 verteilt
hat;
- • den
Validitätszeitraum 95 des
Sendeanstalt-Zertifikats 90 zur Angabe des Anfangs und
Endes des Zeitraums, über
den das Zertifikat verwendet werden soll; und
- • einen
Signaturwert 96 des Sendeanstalt-Zertifikats 90.
-
Wie
aus dem obigen ersichtlich sein wird, enthält das Sendeanstalt-Zertifikat
zwei verschiedene Kennungen, eine erste Kennung des "Ausgebenamens", die der Identität 94 des
Verteilers des Zertifikats entspricht, und eine zweite Kennung des "Subjektnamens", die der Kennung 80 entspricht,
die den öffentlichen
Schlüssel 91 identifiziert.
-
Die
CA berechnet den Signaturwert 96 des Sendeanstalt-Zertifikats 90 durch
Anwenden eines privaten Schlüssels
der CA bzw. CA-Privatschlüssels auf
mindestens einem Teil oder alle der Daten in dem Sendeanstalt-Zertifikat.
Der Decoder kann dann diesen Signaturwert 96 durch Verarbeiten
der Signatur unter Verwendung eines entsprechenden öffentlichen
Schlüssels 101 der
CA verifizieren, der durch die CA-Identität 94 identifiziert
wird, um zu bestimmen, daß die
Inhalte des Zertifikats nach der Signatur durch die CA nicht modifiziert
wurden.
-
Der
Decoder kann mehrere solcher Zertifikate für verschiedene jeweilige Sendeanstalten
speichern.
-
Digitale Zertifikate der Zertifizierungsautorität
-
Unter
weiterer Bezugnahme auf 8 werden der entsprechende öffentliche
Schlüssel 101 der CA
und die CA-Kennung 94 dem
Benutzer des Decoders in einem CA-Zertifikat 100 gegeben,
das auch während
der Herstellung in dem Decoder fest codiert wird. Das CA-Zertifikat 100 enthält außerdem folgendes:
- • eine
Versionsnummer 102 des CA-Zertifikats 100;
- • eine
Seriennummer 103 des CA-Zertifikats 100;
- • eine
RCA-Identität 104 der
Wurzelzertifikatautorität
(RCA), wie zum Beispiel des European Telecommunications Standard
Institute (ETSI), die das CA-Zertifikat 100 verteilt hat;
- • den
Validitätszeitraum 105 des
CA-Zertifikats 100; und
- • einen
Signaturwert 106 des CA-Zertifikats 100.
-
Wie
aus dem obigen ersichtlich sein wird, enthält ein CA-Zertifikat außerdem zwei verschiedene Kennungen,
eine erste Kennung des "Ausstellernamens", die der Identität 104 des
Verteilers des Zertifikats entspricht, und eine zweite Kennung des "Subjektnamens", die der Kennung 94 entspricht,
die den öffentlichen
Schlüssel 101 identifiziert.
-
Die
RCA berechnet den Signaturwert 106 des CA-Zertifikats 100 durch
Anwenden eines privaten Schlüssels
der RCA bzw. RCA-Privatschlüssels auf
mindestens bestimmte oder alle der Daten in dem CA-Zertifikat. Der
Decoder kann dann diesen Signaturwert 106 durch Verarbeiten
des Zertifikats unter Verwendung eines entsprechenden öffentlichen Schlüssels 111 der
RCA verifizieren, der durch die RCA-Identität 104 identifiziert
wird, um zu Bestimmen, daß die
Inhalts des Zertifikats nach der Signatur durch die RCA nicht modifiziert
wurden.
-
Der
Decoder kann mehrere solche Zertifikate für verschiedene jeweilige CA
speichern.
-
Digitale Wurzel-Zertifikate
der Zertifizierungsautorität
-
Der
entsprechende öffentliche
Schlüssel 111 der
RCA und die RCA-Kennung 104 werden dem Benutzer des Decoders
in einem RCA- oder Wurzelzertifikat 110 gegeben, das auch
während
der Herstellung in den Speicher des Decoders fest codiert wird. Jeder
Decoder enthält
in der Regel eine Menge von zwei oder mehr Wurzelzertifikaten. Jedes
Wurzelzertifikat 110 enthält außerdem folgendes:
- • eine
Versionsnummer 112 des Wurzelzertifikats 110;
- • eine
Seriennummer 113 des Wurzelzertifikats 110;
- • den
Validitätszeitraum 114 des
Wurzelzertifikats 110;
und
- • einen
Signaturwert 115 des Wurzelzertifikats 110.
-
Wie
aus dem obigen ersichtlich sein wird, enthält das Wurzelzertifikat nur
eine einzige Kennung, nämlich
die Identität 104 des
Verteilers des Zertifikats. Diese Identität 104 identifiziert
auch den öffentlichen
Schlüssel 111.
Somit kann ein Wurzelzertifikat als ein Zertifikat definiert werden,
in dem der Ausstellername derselbe wie der Subjektname ist.
-
Da
das Wurzelzertifikat das letzte Zertifikat in der Kette Sendeanstalt-Zertifikat 90,
CA-Zertifikat 100, Wurzelzertifikat 110 ist, ist
das Wurzelzertifikat selbstsigniert, das heißt, der Signaturwert wird unter Verwendung
des äquivalenten
privaten Schlüssels des öffentlichen
Schlüssels 111 berechnet.
Deshalb ist es wichtig, daß die
Inhalte eines Wurzelzertifikats nicht öffentlich verfügbar werden.
-
Es
ist natürlich
möglich,
daß die
RCA die Sendeanstalt-Zertifikate 90 direkt
dem Hersteller des Decoders gibt, wobei in diesem Fall das Sendeanstalt-Zertifikate
die RCA-Kennung 111 enthält und unter
Verwendung des RCA-Privatschlüssels zu
signieren ist.
-
Zertifikat-Widerrufliste
-
Beliebige
der Sendeanstalt-Zertifikate 90 und CA-Zertifikate 100 können vor
dem Ablauf des darin spezifizierten Validitätszeitraums zum Beispiel durch
Löschung
widerrufen werden, wenn zum Beispiel ein dem in dem Zertifikat gespeicherten öffentlichen
Schlüssel
entsprechender privater Schlüssel kompromitiert
wurde. Ein solcher Widerruf kann bewirkt werden, indem eine Zertifikat-Widerrufliste (CRL)
zu dem Decoder übertragen
wird, die eine Liste der Seriennummern 92, 102 der
zu widerrufenden Zertifikate enthält. Bei Widerruf wird ein Zertifikat
vorzugsweise durch Löschung
des Zertifikats aus dem Speicher des Decoders unwirksam gemacht,
wodurch das Herunterladen etwaiger unter Verwendung des kompromitierten
privaten Schlüssels
signierter unautorisierter und möglicherweise
bösartiger
Datenpakete verhindert wird.
-
CRL
werden entweder durch eine CA oder eine RCA an die Sendeanstalt
verteilt, die die CRL entweder über
den Modem-Rückkanal 17 oder
durch Ausstrahlen der CRL über
den MPEG-Transportstrom
zu den Decodern sendet. Es ist nicht entscheidend, daß die Sendeanstalt
die CRL in alle von dem Sender zum Decoder gesendeten Transportströme einfügt; es reicht
aus, daß die
Sendeanstalt die CRL in Transportströme einfügt, die sehr wahrscheinlich von
den Decodern eingestellt werden. Zum Beispiel kann eine CRL als
Datendatei in einem Wurzelverzeichnis 75 oder Unterverzeichnis 76 einer
Menge von vom Sender zum Decoder ausgestrahlten Datendateien eingefügt werden.
-
Mit
Bezug auf 9 enthält eine CRL 120 typischerweise
folgendes:
- • die
Identität 94 oder 104 der
CA oder RCA, die die CRL 120 verteilt hat;
- • das
Datum 122, an dem die CRL 120 ausgegeben wurde;
- • das
Datum 124, an dem erwartet wird, daß die nächste CRL ausgegeben wird;
- • eine
Liste 125 der Seriennummern der zu widerrufenden Zertifikate,
darunter für
jedes widerrufene Zertifikat Zeit und Datum des Widerrufs dieses Zertifikats;
und
- • einen
Signaturwert 126 der CRL, der unter Verwendung des privaten
Schlüssels
der CA oder RCA berechnet wird, die die CRL 120 verteilt
hat.
-
Beim
Empfang einer CRL vergleicht der Decoder das Datum 122,
an dem diese CRL 120 ausgegeben wurde, mit dem Datum 124,
an dem diese CRL 120 gemäß der Mitteilung durch die
zuvor empfangene CRL erwartet wurde. Wenn das Datum 122 der
frisch empfangenen CRL nicht später
als das Datum 124 ist, an dem diese CRL erwartet wurde,
wird die CRL ignoriert.
-
Wenn
das Datum 122 der neuempfangenen CRL später als das Datum 124 ist,
an dem diese CRL erwartet wurde, wird die Signatur der CRL unter
Verwendung des öffentlichen
Schlüssels
des Ausstellers der CA verifiziert, der unter Verwendung der in
der CRL enthaltenen Itentität 94 oder 104 identifiziert wird.
-
Wenn
die Integrität
der CRL auf diese Weise verifiziert wird, wird die CRL verarbeitet,
um das Datum 124 hinzufügen,
um das Datum 124, an dem die Ausgabe der nächsten CRL
erwartet wird, in dem permanenten Speicher zu speichern und die
Liste 125 der Seriennummer der widerrufenen Zertifikate zu
speichern. Die empfangene Liste 125 widerrufener Zertifikate
wird auch in permanentem Speicher des Decoders gespeichert. Aus
Leistungsgründen wird
es bevorzugt, daß die
CRL 120 in dem Speicher des Decoders cache-gespeichert
wird. Außerdem wird
bevorzugt, daß der
Cache-Speicher des Decoders CRL 120 auf dendritische Weise
speichert, wobei sich die CRL der RCA an der obersten Position des "Baums" befindet und sich
die CRL der CA, an die diese RCA Zertifikate verteilt, unten in
dem Baum befinden. Im Fall des Widerrufs eines Sendeanstalt-Zertifikats 90 zum
Beispiel wenn der private Schlüssel
der Sendeanstalt kompromitiert wird, fügt die Zertifizierungsautorität für diese
Sendeanstalt die Seriennummer 93 des Sendeanstalt-Zertifikats 90 zu ihrer
CRL 120 hinzu. Danach verteilt die Zertifizierungsautorität die neue
CRL 120 an alle Sendeanstalten, an die sie Sendeanstalt-Zertifikate 90 zur Ausstrahlung
verteilt. Sobald ein Decoder die neue CRL 120 heruntergeladen
hat (zum Beispiel beim Zappen auf den Kanal einer Sendeanstalt)
wird der CRL-Cache aktualisiert, und der Widerruf etwaiger, dergestalt
in der Liste 125 der CRL 120 identifizierten Zertifikate
findet statt.
-
Ersatz-Sendeanstalt-Zertifikate 90 werden von
der Zertifizierungsautorität 100 erzeugt
und in einem Verzeichnis 75 oder 76 einer Datei
an den Benutzer ausgestrahlt. Das Ersatz-Sendeanstalt-Zertifikat
enthält
u. a. einen neuen öffentlichen
Schlüssel 91,
eine aktualisierte Versionsnummer 92, einen aktualisierten
Validitätszeitraum 95 und
einen neuen Signaturwert 96, der unter Verwendung des privaten Schlüssels der
CA berechnet wird. Die Sendeanstalt-Kennung 80 und die
CA-Kennung 94 bleiben unverändert. Beim Empfang des Ersatz-Sendeanstalt-Zertifikate 90 verifiziert
der Decoder das Zertifikat durch Verarbeiten des Zertifikats unter
Verwendung des entsprechenden, in dem durch die CA-Identität 94 identifizierten
CA-Zertifikat enthaltenen öffentlichen
Schlüssels
der CA.
-
Beim
Widerruf eines CA-Zertifikats 100 wird die CRL dieser CA
aus dem Speicher des Decoders entfernt. Deshalb kann es wünschenswert
sein, freiwillig ein CA-Zertifikat 100 zu widerrufen, wenn
zum Beispiel die Größe der CRL
dieser CA zu groß wird, um
in dem Cache-Speicher des Decoders gespeichert zu werden. In diesem
Fall fügt
die RCA, die das CA-Zertifikat 100 an diese CA verteilt,
die Seriennummer 103 dieses CA-Zertifikats 100 zu
ihrer CRL hinzu. Die Wurzel-Zertifizierungsautorität verteilt
danach die neue CRL an alle Sendeanstalten, an die die CA, an die
diese RCA CA-Zertifikate verteilt, ihrerseits Sendeanstalt-Zertifikate zur Ausstrahlung verteilen.
-
Sobald
ein Decoder die neue CRL heruntergeladen hat (zum Beispiel beim
Zappen auf den Kanal einer Sendeanstalt), wird der CRL-Cache aktualisiert
und der Widerruf der dergestalt in der Liste 125 der CRL
identifizierten CA-Zertifikate
findet statt. Bei einem Widerruf eines CA-Zertifikats 100 einer Zertifizierungsautorität ist es
zusätzlich
zu der Speicherung eines neuen CA-Zertifikats für diese Zertifizierungsautorität in dem
Decoder notwendig, die Sendeanstalt-Zertifikate 90 für alle Sendeanstalten
zu ersetzen, an die diese Zertifizierungsautorität Zertifikate verteilt, weil,
da das Privatschlüsselpaar
für diese Zertifizierungsautorität nicht
mehr gültig
ist, neue Sendeanstalt-Zertifikate 90, die unter Verwendung eines
anderen oder aktualisierten privaten Schlüssels der Zertifizierungsautorität signiert werden,
erforderlich sein werden. Ein Ersatz-CA-Zertifikat 100 wird
von der Wurzel-Zertifizierungsautorität 110 erzeugt und
in einem Verzeichnis 75 oder 76 einer Datei an
den Benutzer ausgestrahlt. Ähnlich
wie bei einem Ersatz-Sendeanstalt-Zertifikat
enthällt
das Ersatz-CA-Zertifikat u. a. einen neuen öffentlichen Schlüssel 101 der
CA, eine aktualisierte Versionsnummer 102, einen aktualisierten
Validitätszeitraum 105 und
einen neuen Signaturwert 106, der unter Verwendung des
privaten Schlüssels
der RCA berechnet wird. Die CA-Kennung 94 und die RCA-Kennung 104 bleiben
unverändert.
-
Beim
Empfang des Ersatz-CA-Zertifikats 100 verifiziert der Decoder
das Zertifikat durch Verarbeiten des Zertifikats unter Verwendung
des entsprechenden öffentlichen
Schlüssels
der RCA, der in dem durch die RCA-Identität 104 identifizierten
RCA-Zertifkat 110 enthalten ist.
-
Wurzel-Zertifikatverwaltungsnachricht
-
Beim
Widerruf eines RCA-Zertifikats 110 einer Wurzel-Zertifizierungsautorität ist es
notwendig, das widerrufene RCA-Zertifikat mit einer neuen RCA zu
ersetzen. Wie oben beschrieben, sind RCA-Zertifikate selbst signiert
und die Aufnahme eines RCA-Zertifikats in eine CRL ist deshalb nicht
wünschenswert,
weil es für
einen Hacker möglich
ist, in den Besitz des Zertifikats zu kommen, wenn er den zum Signieren
der CRL benutzten privaten Schlüssel kennt.
Deshalb war es bisher notwendig, jedesmal, wenn ein RCA-Zertifikat zu aktualisieren
ist, zum Beispiel wenn es veraltet oder widerrufen worden ist, den
Decoder zum Hersteller zurückzusenden.
-
Um
dieses Problem zu überwinden,
erzeugt die Wurzel-Zertifizierungsautorität eine durch
die Sendeanstalten an Decoder auszustrahlende Wurzel-Zertifikatverwaltungsnachricht
(RCMM). Wie später
ausführlicher
erläutert
werden wird, enthält
eine RCMM ähnlich
wie eine CRL eine Liste 125 der Seriennummer von zu widerrufenden
Wurzelzertifikaten, einschließlich
der, für
jedes widerrufene Wurzelzertifikat, Zeit und Datum für den Widerruf
dieses Zertifikats, zusammen mit einem oder mehreren Ersatz-Wurzelzertifikaten
für diejenigen
Zertifikate, die veraltet sind oder in der Liste 125 identifiziert
werden.
-
Es
versteht sich, daß es
im Hinblick auf diese sensitiven Inhalte (neue Wurzelzertifikate)
der RCMM wichtig ist, sicherzustellen, daß eine RCMM von dem Decoder
so empfangen wird, wie sie an die Sendeanstalt ausgegeben wird,
das heißt,
sicherzustellen, daß die
Inhalte der RCMM zwischen Verteilung und Empfang nicht geändert wurden.
Auch ist es wichtig, sicherzustellen, daß nur die Decoder auf die RCMM
zugreifen können,
an die RCMM adressiert ist.
-
Um
die Sicherheit zu verbessern, enthält eine RCMM im Gegensatz zu
einer CRL mindestens zwei Signaturwerte für mindestens bestimmte und vorzugsweise
alle darin enthaltene Daten. Jeder Signaturwert wird unter Verwendung
eines Schlüssels eines
jeweiligen Verschlüsselungsalgorithmus,
wie zum Beispiel eines privaten Schlüssels eines Paars aus öffentlichen/privaten
Schlüsseln,
berechnet.
-
Wenn
eine RCMM von einer Wurzel-Zertifizierungsautorität (RCA)
ausgegeben wird und ein neues Wurzelzertifikat 110 enthält, enthält die RCMM mindestens
zwei Signaturwerte. Jeder Signaturwert wird unter Verwendung eines
jeweiligen privaten Schlüssels
zum Beispiel einer Zertifizierungsautorität, der diese RCA-Zertifikate
zuführt,
berechnet (obwohl jeder beliebige Schlüssel, für den der Decoder einen äquivalenten
Schlüssel
speichert, gewählt
werden kann). Wenn ohne Wissen einer der Zertifizierungsautoritäten ihr
privater Schlüssel
kompromitiert wurde, kann es für
einen "Hacker" möglich sein,
die Ausstrahlung der Sendeanstalt abzufangen und, wenn er die privaten
Schlüssel
sowohl der Sendeanstalt als auch der Zertifizierungsautorität kennt,
die Inhalte der RCMM und den unter Verwendung des privaten Schlüssels der
Zertifizierungsautorität
berechneten Signaturwert der RCMM zu ändern. Es wird dem Hacker jedoch
nicht möglich
sein, den Signaturwert zu ändern,
der unter Verwendung des privaten Schlüssels der anderen Zertifizierungsautorität berechnet
wird, weil dieser Schlüssel
nicht kompromitiert wurde. Deshalb werden nach Verifikation der Signaturen
durch den Decoder unter Verwendung der öffentlichen Schlüssel der
beiden Zertifizierungsautoritäten
die beiden vom Decoder unter Verwendung der jeweiligen öffentlichen
Schlüssel
berechneten Werte nicht gleich sein. Deshalb wird der Decoder auf
das Fehlen von Integrität
der Inhalte der RCMM hingewiesen und wird die RCMM zurückweisen
oder anderweitig nicht mit ihrer Verarbeitung fortfahren.
-
Folglich
können
Wurzelzertifikate sicher aktualisiert werden, solange die Anzahl
kompromitierter Zertifikate kleiner als die Anzahl der in der RCMM enthaltenen
Signaturen ist. Deshalb ist die Anzahl der Signaturen der RCMM eine
Variable, die durch die RCMM verteilende Wurzel-Zertifizierungsautorität bestimmt
wird.
-
Das
Format einer RCMM wird nun mit Bezug auf 10 ausführlicher
beschrieben.
-
Die
RCMM 130 enthält
folgendes:
- • die
Identität 132 der
RCA, die die RCMM 130 verteilt hat;
- • das
Datum 134, an dem die RCMM 130 ausgegeben wurde;
- • die
Anzahl 136 der Signaturwerte, die die nachfolgende RCMM
enthalten wird;
- • ein
Feld 138, das eines oder mehrere in dem Decoder zu speichernde
aktualisierte oder Ersatz-Wurzelzertifikate enthält;
- • eine
Liste 140 der Seriennummern der zu widerrufenden Wurzelzertifikate,
die für
jedes widerrufene Wurzelzertifikat Zeit und Datum des Widerrufs
dieses Zertifikats enthält;
und
- • mindestens
zwei Signaturfelder 142, die jeweils eine Kennung 144 des
in dem Decoder gespeicherten Zertifikats enthalten, das den zum
Verifizieren des in diesem Signaturfeld enthaltenen Signaturwerts
zu verwendenden öffentlichen Schlüssel enthält;
und
einen Signaturwert 146 der RCMM, der unter Verwendung des äquivalenten
privaten Schlüssels
des in dem durch die Kennung 144 identifizierten Zertifikat
enthaltenen öffentlichen
Schlüssels
berechnet wird.
-
Die
Anzahl der Signaturfelder 142 sollte größer oder gleich der in der
zuvor empfangenen RCMM mitgeteilten Anzahl 136 der Signaturfelder
sein.
-
Es
wird bevorzugt, daß RCMM über den MPEG-Transportstrom übertragen
werden, da der Modem-Rückkanal
leicht getrennt werden kann oder einfach nicht vorhanden sein kann.
Außerdem
wird bevorzugt, daß die
RCMM von der Sendeanstalt als eine Datendatei in ein Wurzelverzeichnis 75 eingefügt werden,
um sicherzustellen, daß der
Decoder die RCMM herunterlädt.
-
Verarbeitung und Erzeugung
von Wurzelzertifikat-Verwaltungsnachrichten
-
Der
Empfang und die Verarbeitung einer RCMM durch einen Decoder wird
nun mit Bezug auf 11 beschrieben.
-
Beim
Empfang einer RCMM vergleicht der Decoder im Schritt 200 das
Datum 134, an dem diese RCMM 130 ausgegeben wurde,
mit dem Datum, an dem die vorherige RCMM ausgegeben wurde. Wenn das
Datum 134 der frisch empfangenen RCMM nicht später als
das Datum ist, an dem die vorherige RCMM ausgegeben wurde, wird
die RCMM zurückgewiesen.
-
Wenn
das Datum 134 der frisch empfangenen RCMM später als
das Datum des Empfangs der vorherigen RCMM ist, wird die Anzahl 136 der
Signaturwerte, die die frisch empfangene RCMM enthalten soll, die
durch die zuvor empfangene RCMM mitgeteilt wird, im Schritt 202 mit
der Anzahl der Signaturwerte verglichen, die tatsächlich in
der frisch empfangenen RCMM enthalten sind. Wenn die Anzahl der
in der frisch empfangenen RCMM enthaltenen Signaturen kleiner als
erwartet ist, wird die RCMM zurückgewiesen.
Dies kann verhindern, daß andernfalls
eine RCMM verarbeitet wird, weil ein Hacker mit unkompromitierten
Paaren von privaten/öffentlichen
Schlüsseln
assoziierte Signaturen entfernt. Wenn die Anzahl der in der frisch
empfangenen RCMM enthaltenen Signaturen größer oder gleich der erwarteten
Anzahl von Signaturen ist, wird im Schritt 204 jeder in der
RCMM enthaltene Signaturwert 146 unter Verwendung des öffentlichen
Schlüssels
verifiziert, der durch die Kennung 144 identifiziert wird,
die in demselben Signaturfeld 142 wie dieser Signaturwert
enthalten ist. Im Schritt 206 bestimmt der Decoder, ob mindestens
einer der unter Verwendung eines öffentlichen Schlüssels berechneten
Werte von irgendwelchen der anderen unter Verwendung eines anderen öffentlichen
Schlüssels
berechneten Werte verschieden ist. Wenn mindestens ein berechneter
Wert von mindestens einem der anderen berechneten Werte verschieden
ist, wird die RCMM zurückgewiesen.
-
Wenn
die Integrität
der RCMM im Schritt 206 bewiesen wird, wird die RCMM im
Schritt 208 verarbeitet, um die Liste 140 der
Seriennummern der widerrufenen Wurzelzertifikate in dem permanenten Speicher
des Decoders zu speichern, so daß diese Zertifikate aus dem
Speicher des Decoders gelöscht werden
können,
um im Schritt 212 das oder jedes in dem Feld 138 enthaltene
Wurzelzertifikat in dem permanenten Speicher des Decoders zu speichern
und um im Schritt 212 in permanentem Speicher das Datum 134 der
RCMM zu speichern. Wenn ein Zertifikat einer Wurzel-Zertifizierungsautorität gelöscht wird, werden
auch jegliche von dieser Autorität
ausgegebene CRL gelöscht.
-
Es
wird bevorzugt, daß die
Integrität
der permanenten Speicher in der RCMM enthaltene Daten aufrechterhalten
wird, wenn der Decoder während der
Verarbeitung der RCMM-Nachricht
ausgeschaltet wird. Wenn der Strom tatsächlich während der RCMM-Verarbeitung
ausgeschaltet wird, bleibt deshalb die mit der zuvor verarbeiteten
RCMM assoziierte Liste 140, die in dem Decoder gespeichert
ist, so erhalten, als ob die neuempfangene RCMM-Nachricht überhaupt
nicht verarbeitet wurde.
-
Wie
bereits erwähnt,
besitzt eine Wurzel-Zertifizierungsautorität (RCA)
in der Regel mindestens zwei RCA-Zertifikate (RCO und RC1), die
in jedem Decoder gespeichert sind. Falls eines dieser Zertifikate,
etwa RCO, kompromitiert wird, wird es notwendig, alle in dem Decoder
gespeicherten CA-Zertifikate, die unter Verwendung des äquivalenten
privaten Schlüssels
des in RCO gespeicherten öffentlichen Schlüssels signiert
wurden, zu ersetzen und ein neues RCA-Zertifikat RC2 zum Ersetzen
von RCO zu erzeugen.
-
Um
diese CA-Zertifikate zu ersetzen, wird mit Bezug auf 12 zuerst
im Schritt 300 eine geeignete CRL-Nachricht, die die Seriennummern
der zu widerrufenden CA-Zertifikate identifiziert, von der RCA ausgegeben.
Im Schritt 302 werden zweitens Ersatz-CA-Zertifikate, die
unter Verwendung des privaten Schlüssels des unkompromitierten
Zertifikats RC1 signiert werden, zur Ausstrahlung an den Decoder
an die Sendeanstalt ausgegeben.
-
Es
verbleibt dann, das kompromitierte RCA-Zertifikat RCO zu löschen und
diese Zertifikat mit einem RCA-Zertifikat RC2 zu ersetzen. Im Schritt 304 erzeugt
die RCA ein neues Paar aus öffentlichen/privaten
Schlüsseln,
fügt den
neuen öffentlichen
Schlüssel
in das Zertifikat RC2 ein und signiert das Zertifikat unter Verwendung
des neuen privaten Schlüssels.
-
Im
Schritt 306 erzeugt die RCA eine RCMM, die in dem Feld 138 das
Zertifikat RC2 und in der Liste 140 die Seriennummer von
RCO enthält.
Die RCMM wird an die Sendeanstalten zur Übertragung im Schritt 308 an
die Decoder verteilt, um das kompromitierte Zertifikat RCO zu löschen und
dieses mit dem neuen Zertifikat RC2 zu ersetzen.
-
Die
RCA-Zertifikate RC1 und RC2 werden danach zur Festcodierung in dem
Speicher neuer Decoder dem Decoder-Hersteller zur Verfügung gestellt. Es versteht
sich, daß die
vorliegende Erfindung oben lediglich beispielhaft beschrieben wurde
und daß Modifikationen
an Details innerhalb des Schutzumfang der Erfindung vorgenommen
werden können.
-
Zum
Beispiel kann die RCMM zusätzlich
zu neuen RCA-Zertifikaten 110 neue
CA-Zertifikate 100 und/oder neue Sendeanstalt-Zertifikate 90 enthalten, und
die Liste 140 kann Kennungen von CA-Zertifikaten und/oder
Sendeanstalt-Zertifikaten,
die zu widerrufen sind, enthalten. Dadurch kann es möglich werden,
daß die
Erzeugung separater CRL-Nachrichten durch
eine RCA vermieden werden kann.