DE60133233T2 - Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden - Google Patents

Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden Download PDF

Info

Publication number
DE60133233T2
DE60133233T2 DE60133233T DE60133233T DE60133233T2 DE 60133233 T2 DE60133233 T2 DE 60133233T2 DE 60133233 T DE60133233 T DE 60133233T DE 60133233 T DE60133233 T DE 60133233T DE 60133233 T2 DE60133233 T2 DE 60133233T2
Authority
DE
Germany
Prior art keywords
data
decoder
certificate
date
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60133233T
Other languages
English (en)
Other versions
DE60133233D1 (de
Inventor
Jean-Bernard Beuque
Philippe Poulain
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Application granted granted Critical
Publication of DE60133233D1 publication Critical patent/DE60133233D1/de
Publication of DE60133233T2 publication Critical patent/DE60133233T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/167—Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675—Providing digital key or authorisation information for generation or regeneration of the scrambling sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving video stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26613—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6433—Digital Storage Media - Command and Control Protocol [DSM-CC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H04L2209/601—Broadcast encryption

Description

  • 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.

Claims (7)

  1. Verfahren zum Verifizieren von in einem digitalen Übertragungssystem übertragenen Daten, wobei die Daten eine Aktualisierung zuvor übertragener Daten sind, dadurch gekennzeichnet, daß das Verfahren die folgenden Schritte umfaßt: Empfangen der Daten, eines Datums, an dem die Daten (134) ausgegeben wurden, und mindestens zweier für mindestens einen Teil der Daten bestimmter verschlüsselter Werte, wobei jeder verschlüsselte Wert für dieselben Daten unter Verwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus bestimmt wird; Verifizieren (200), daß das Datum, an dem die Daten (134) ausgegeben wurden, später als das Datum ist, an dem zuvor übertragene Daten ausgeben wurden; Verarbeiten (204) jedes verschlüsselten Werts unter Verwendung eines gespeicherten Schlüssels des jeweiligen Verschlüsselungsalgorithmus; und Vergleichen (206) jedes nachfolgend resultierenden Werts mit mindestens einem Teil der Daten, um den mindestens Teil der Daten zu verifizieren.
  2. Verfahren nach Anspruch 1, ferner mit dem Schritt des Zurückweisens der Daten, wenn das Datum, an dem die Daten (134) ausgegeben wurden, nicht später als das Datum ist, an dem zuvor übertragene Daten ausgegeben wurden.
  3. Empfänger/Decoder (13), umfassend: ein Mittel (20) zum Speichern mehrerer Schlüssel; ein Mittel (31, 32, 30, 20) zum Empfangen von Daten, die eine Aktualisierung zuvor übertragener Daten sind, und eines Datums, an dem die Daten (134) ausgegeben wurden; ein Mittel zum Empfangen von mindestens zwei für mindestens einen Teil der Daten bestimmten verschlüsselten Werten, wobei jeder verschlüsselte Wert für dieselben Daten unter Verwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus bestimmt wird; ein Mittel (20) zum Verifizieren, daß das Datum der Daten später als das Datum der zuvor übertragenen Daten ist; ein Mittel (20) zum Verarbeiten jedes verschlüsselten Werts unter Verwendung eines gespeicherten Schlüssels des jeweiligen Verschlüsselungsalgorithmus; und ein Mittel (20) zum Vergleichen jedes nachfolgend resultierenden Werts mit dem mindestens Teil der Daten, um den mindestens Teil der Daten zu verifizieren.
  4. Empfänger/Decoder (13) nach Anspruch 3, ferner mit einem Mittel zum Zurückweisen der Daten, wenn das Datum, an dem die Daten (134) ausgegeben wurden, nicht später als das Datum ist, an dem zuvor übertragene Daten ausgegeben wurden.
  5. Verfahren zum Erzeugen von Authentifizierungsdaten (46, 60), die in einem digitalen Übertragungssystem (1) zu übertragen sind, wobei die Daten eine Aktualisierung zuvor übertragener Daten sind, dadurch gekennzeichnet, daß das Verfahren die folgenden Schritte vor der Übertragung umfaßt: Bestimmen von mindestens zwei verschlüsselten Werten (146) für mindestens einen Teil der Daten, wobei jeder entschlüsselte Wert für dieselben Daten unter Verwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus bestimmt wird; Bestimmen eines Datums, an dem die Daten (134) ausgegeben wurden; und Ausgeben der mindestens zwei verschlüsselten Werte (146) und des Datums (134) mit den Daten.
  6. Vorrichtung zum Erzeugen von Authentifizierungsdaten, die in einem digitalen Übertragungssystem zu übertragen sind, wobei die Daten eine Aktualisierung zuvor übertragener Daten sind, dadurch gekennzeichnet, daß die Vorrichtung folgendes umfaßt: ein Mittel zum Bestimmen mindestens zweier verschlüsselter Werte für mindestens bestimmte der Daten, wobei jeder verschlüsselte Wert für dieselben Daten unter Verwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus bestimmt wird; ein Mittel zum Bestimmen eines Datums, an dem die Daten (134) ausgegeben wurden; und ein Mittel zum Ausgeben mindestens zweier verschlüsselter Werte (146) und des Datums (134) mit den Daten.
  7. Digitales Signal, das Daten, die eine Aktualisierung zuvor übertragener Daten sind, und ein Datum, an dem die Daten (134) ausgegeben wurden, umfaßt, dadurch gekennzeichnet, daß es ferner zwei verschlüsselte Werte (146) für mindestens einen Teil der Daten umfaßt, wobei jeder verschlüsselte Wert für dieselben Daten unter Verwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus bestimmt wird.
DE60133233T 2000-04-03 2001-01-11 Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden Expired - Lifetime DE60133233T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP00400912 2000-04-03
EP00400912A EP1143658A1 (de) 2000-04-03 2000-04-03 Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten

Publications (2)

Publication Number Publication Date
DE60133233D1 DE60133233D1 (de) 2008-04-24
DE60133233T2 true DE60133233T2 (de) 2008-06-26

Family

ID=8173630

Family Applications (3)

Application Number Title Priority Date Filing Date
DE60133233T Expired - Lifetime DE60133233T2 (de) 2000-04-03 2001-01-11 Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden
DE60143326T Expired - Lifetime DE60143326D1 (de) 2000-04-03 2001-01-11 Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden
DE60114167T Expired - Lifetime DE60114167T2 (de) 2000-04-03 2001-01-11 Authentifizierung von in einem digitalen übertragungssystem übertragenen daten

Family Applications After (2)

Application Number Title Priority Date Filing Date
DE60143326T Expired - Lifetime DE60143326D1 (de) 2000-04-03 2001-01-11 Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden
DE60114167T Expired - Lifetime DE60114167T2 (de) 2000-04-03 2001-01-11 Authentifizierung von in einem digitalen übertragungssystem übertragenen daten

Country Status (16)

Country Link
US (6) US7437561B2 (de)
EP (6) EP1143658A1 (de)
JP (7) JP2003530013A (de)
KR (1) KR100726347B1 (de)
CN (5) CN1897526B (de)
AT (3) ATE307438T1 (de)
AU (1) AU2699501A (de)
BR (2) BR0109815A (de)
CY (2) CY1106061T1 (de)
DE (3) DE60133233T2 (de)
DK (2) DK1269681T3 (de)
ES (1) ES2250346T3 (de)
HK (3) HK1101235A1 (de)
MX (1) MXPA02009771A (de)
MY (5) MY146142A (de)
WO (1) WO2001076135A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015212037A1 (de) * 2015-06-29 2016-12-29 Siemens Aktiengesellschaft Überwachen eines Übertragungsstreckenabschnitts zur Übertragung von Daten zwischen zwei Teilnehmern einer Kommunikationsverbindung

Families Citing this family (106)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2259738C (en) 1999-01-20 2012-10-16 Certicom Corp. A resilient cryptographic scheme
EP1143658A1 (de) * 2000-04-03 2001-10-10 Canal+ Technologies Société Anonyme Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten
FR2832577B1 (fr) * 2001-11-16 2005-03-18 Cit Alcatel Acquisition adaptative de donnees pour systeme de gestion de reseaux ou de services
JP4054190B2 (ja) 2001-12-27 2008-02-27 松下電器産業株式会社 データ転送システム
KR100497336B1 (ko) * 2002-12-10 2005-06-28 한국전자통신연구원 공개키 기반 구조의 제한 수신 시스템에서의 자격관리메시지 변환 방법
US7366906B2 (en) * 2003-03-19 2008-04-29 Ricoh Company, Ltd. Digital certificate management system, digital certificate management apparatus, digital certificate management method, program and computer readable information recording medium
JP4504099B2 (ja) 2003-06-25 2010-07-14 株式会社リコー デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
US7900041B2 (en) * 2003-07-22 2011-03-01 Irdeto Canada Corporation Software conditional access system
CN100428667C (zh) * 2003-12-01 2008-10-22 中国电子科技集团公司第三十研究所 一种采用公开密钥密码算法数字签名模式的强鉴别方法
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
KR100556828B1 (ko) 2003-12-27 2006-03-10 한국전자통신연구원 디지털 케이블방송 시스템에서 공개키 암호 알고리즘을이용한 서비스 신청 및 암호화 키 분배 방법
US8429423B1 (en) * 2004-06-10 2013-04-23 Oracle America, Inc. Trusted platform modules
KR20070043783A (ko) * 2004-07-14 2007-04-25 마쯔시다덴기산교 가부시키가이샤 애플리케이션 프로그램 인증 및 실행 방법
US20060036627A1 (en) * 2004-08-06 2006-02-16 Roger Deran Method and apparatus for a restartable hash in a trie
FR2875977A1 (fr) * 2004-09-29 2006-03-31 France Telecom Systeme et procede cryptographique a cle publique et serveur de certification, memoires adaptees pour ce systeme
KR100709318B1 (ko) * 2005-02-01 2007-04-20 삼성전자주식회사 디지털 방송을 위한 수신제한서비스 키 할당 방법 및 시스템
US7549051B2 (en) * 2005-03-10 2009-06-16 Microsoft Corporation Long-life digital certification for publishing long-life digital content or the like in content rights management system or the like
US20060218392A1 (en) * 2005-03-25 2006-09-28 David Johnston Spectrum use authorization method, system and apparatus
US7889709B2 (en) * 2005-08-23 2011-02-15 Sony Corporation Distinguishing between data packets sent over the same set of channels
EP1765012A1 (de) * 2005-09-14 2007-03-21 Nagravision S.A. Verifikationsverfahren einer Tochtereinheit verbunden mit einer Muttereinheit
GB2431741B (en) * 2005-10-27 2010-11-03 Hewlett Packard Development Co A method of digitally signing data and a data repository storing digitally signed data
US20070124584A1 (en) * 2005-11-30 2007-05-31 Microsoft Corporation Proving ownership of shared information to a third party
US20070130462A1 (en) * 2005-12-06 2007-06-07 Law Eric C W Asynchronous encryption for secured electronic communications
WO2007106844A2 (en) 2006-03-14 2007-09-20 Divx, Inc. Federated digital rights management scheme including trusted systems
FR2909507B1 (fr) 2006-12-05 2009-05-22 Medialive Sa Procede et systeme de distribution securisee de donnees audiovisuelles par marquage transactionel
JP2008146601A (ja) * 2006-12-13 2008-06-26 Canon Inc 情報処理装置及び情報処理方法
TWI427374B (zh) 2006-12-27 2014-02-21 Fujifilm Corp 遲延度補償元件、垂直配向向列型液晶顯示裝置、及液晶投影機
JP4218724B2 (ja) * 2006-12-28 2009-02-04 船井電機株式会社 放送受信装置
EP1968316A1 (de) * 2007-03-06 2008-09-10 Nagravision S.A. Verfahren zur Steuerung des Zugangs zu Audio-/Video-Inhalten mit beschränktem Zugang
JP4594962B2 (ja) * 2007-06-04 2010-12-08 株式会社日立製作所 検証サーバ、プログラム及び検証方法
JP5096826B2 (ja) * 2007-07-26 2012-12-12 Ｋｄｄｉ株式会社 送信機、受信機、検証情報の埋め込み方法およびプログラム
US8155090B2 (en) * 2007-11-01 2012-04-10 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for efficient multimedia delivery in a wireless packet network
JP5513400B2 (ja) 2007-11-16 2014-06-04 ソニック アイピー， インコーポレイテッド マルチメディアファイルのための階層的で簡略なインデックス構造体
KR100923858B1 (ko) * 2007-12-04 2009-10-28 한국전자통신연구원 케이블 네트워크 시스템 및 케이블 네트워크 동적멀티캐스트 세션에서의 보안 제어 방법
US8997161B2 (en) 2008-01-02 2015-03-31 Sonic Ip, Inc. Application enhancement tracks
EP2088764B1 (de) * 2008-02-11 2010-10-06 Nagravision S.A. Methode zur Aktualisierung und Verwaltung einer Anwendung für die Verarbeitung von audiovisuellen Daten in einer Multimediaeinheit über ein Modul mit bedingtem Zugriff
WO2009157800A1 (ru) * 2008-06-25 2009-12-30 Федеральное Государственное Унитарное Предприятие Ордена Трудового Красного Знамени Научно-Исследовательский Институт Радио (Фгуп Ниир) Система защиты информации в абонентских сетях
US8850553B2 (en) * 2008-09-12 2014-09-30 Microsoft Corporation Service binding
DE102008042259A1 (de) * 2008-09-22 2010-04-08 Bundesdruckerei Gmbh Kraftfahrzeug-Elektronikgerät, Kraftfahrzeug, Verfahren zur Anzeige von Daten auf einer Kraftfahrzeug-Anzeigevorrichtung und Computerprogrammprodukt
US9621341B2 (en) * 2008-11-26 2017-04-11 Microsoft Technology Licensing, Llc Anonymous verifiable public key certificates
US20110281721A1 (en) * 2008-12-10 2011-11-17 Uop Llc Adsorbent media
US8285985B2 (en) * 2008-12-15 2012-10-09 Sap Ag Systems and methods for detecting exposure of private keys
CA2749170C (en) 2009-01-07 2016-06-21 Divx, Inc. Singular, collective and automated creation of a media guide for online content
US8997252B2 (en) * 2009-06-04 2015-03-31 Google Technology Holdings LLC Downloadable security based on certificate status
US9947299B2 (en) * 2009-06-11 2018-04-17 Gilad Odinak System and method for offline content delivery through an active screen display
JP5452099B2 (ja) * 2009-07-01 2014-03-26 株式会社日立製作所 証明書の有効性確認方法、証明書検証サーバ、プログラム及び記憶媒体
US8503456B2 (en) * 2009-07-14 2013-08-06 Broadcom Corporation Flow based path selection randomization
US8565239B2 (en) * 2009-07-14 2013-10-22 Broadcom Corporation Node based path selection randomization
EP2473926A4 (de) * 2009-08-31 2015-05-20 Vencore Labs Inc System und verfahren zur erkennung und entfernung von bösartigen fahrzeugen in einem fahrzeugkommunikationssystem
US8781122B2 (en) 2009-12-04 2014-07-15 Sonic Ip, Inc. Elementary bitstream cryptographic material transport systems and methods
US8473002B2 (en) 2010-04-23 2013-06-25 Qualcomm Incorporated Method and apparatus for network personalization of subscriber devices
US20120011542A1 (en) * 2010-07-12 2012-01-12 Comcast Cable Communications, Llc Linear Interactive Television Data Insertion
EP2437194A1 (de) * 2010-10-01 2012-04-04 Nagravision S.A. System und Verfahren zur Vermeidung der Manipulation von Videodaten übertragen auf HDMI Verbindung.
US9247312B2 (en) 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
WO2012161122A1 (ja) * 2011-05-20 2012-11-29 日本放送協会 放送通信連携受信装置およびリソース管理装置
US10708634B2 (en) 2011-07-01 2020-07-07 Nagravision S.A. Method for playing repeatable events on a media player
US8818171B2 (en) 2011-08-30 2014-08-26 Kourosh Soroushian Systems and methods for encoding alternative streams of video for playback on playback devices having predetermined display aspect ratios and network connection maximum data rates
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
KR102163151B1 (ko) 2011-08-30 2020-10-08 디빅스, 엘엘씨 복수의 최대 비트레이트 레벨들을 사용하여 인코딩된 비디오를 인코딩하고 스트리밍하기 위한 시스템들 및 방법들
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US20130061281A1 (en) * 2011-09-02 2013-03-07 Barracuda Networks, Inc. System and Web Security Agent Method for Certificate Authority Reputation Enforcement
US20130179199A1 (en) 2012-01-06 2013-07-11 Rovi Corp. Systems and methods for granting access to digital content using electronic tickets and ticket tokens
US9401904B1 (en) 2012-03-15 2016-07-26 Motio, Inc. Security migration in a business intelligence environment
US8812837B2 (en) * 2012-06-01 2014-08-19 At&T Intellectual Property I, Lp Apparatus and methods for activation of communication devices
CA2877451C (en) 2012-06-22 2020-11-10 Ologn Technologies Ag Systems, methods and apparatuses for securing root certificates
US9197685B2 (en) 2012-06-28 2015-11-24 Sonic Ip, Inc. Systems and methods for fast video startup using trick play streams
US9143812B2 (en) 2012-06-29 2015-09-22 Sonic Ip, Inc. Adaptive streaming of multimedia
US10452715B2 (en) 2012-06-30 2019-10-22 Divx, Llc Systems and methods for compressing geotagged video
WO2014015110A1 (en) 2012-07-18 2014-01-23 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear tv experience using streaming content distribution
US9804668B2 (en) 2012-07-18 2017-10-31 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear TV experience using streaming content distribution
US8914836B2 (en) 2012-09-28 2014-12-16 Sonic Ip, Inc. Systems, methods, and computer program products for load adaptive streaming
US8997254B2 (en) 2012-09-28 2015-03-31 Sonic Ip, Inc. Systems and methods for fast startup streaming of encrypted multimedia content
JP6022704B2 (ja) * 2012-11-09 2016-11-09 ▲ホア▼▲ウェイ▼技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． メッセージ検証のための方法および端末
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US9264475B2 (en) 2012-12-31 2016-02-16 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US9344517B2 (en) 2013-03-28 2016-05-17 Sonic Ip, Inc. Downloading and adaptive streaming of multimedia content to a device with cache assist
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9247317B2 (en) 2013-05-30 2016-01-26 Sonic Ip, Inc. Content streaming with client device trick play index
US9967305B2 (en) 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US9343112B2 (en) 2013-10-31 2016-05-17 Sonic Ip, Inc. Systems and methods for supplementing content from a server
US9621356B2 (en) * 2014-03-06 2017-04-11 Apple Inc. Revocation of root certificates
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
EP2996300B1 (de) * 2014-09-11 2018-11-07 The Boeing Company Computerimplementiertes verfahren zur analyse von x.509-zertifikaten in ssl/tls-kommunikationen und datenverarbeitungssystem
CN104270391B (zh) * 2014-10-24 2018-10-19 中国建设银行股份有限公司 一种访问请求的处理方法及装置
US9369287B1 (en) 2015-01-27 2016-06-14 Seyed Amin Ghorashi Sarvestani System and method for applying a digital signature and authenticating physical documents
WO2016129909A1 (ko) * 2015-02-10 2016-08-18 엘지전자 주식회사 방송 송신 장치, 방송 송신 장치의 동작 방법, 방송 수신 장치 및 방송 수신 장치의 동작 방법
US9893885B1 (en) 2015-03-13 2018-02-13 Amazon Technologies, Inc. Updating cryptographic key pair
US9674162B1 (en) 2015-03-13 2017-06-06 Amazon Technologies, Inc. Updating encrypted cryptographic key pair
US10003467B1 (en) * 2015-03-30 2018-06-19 Amazon Technologies, Inc. Controlling digital certificate use
US9479340B1 (en) 2015-03-30 2016-10-25 Amazon Technologies, Inc. Controlling use of encryption keys
US9774610B2 (en) * 2015-07-28 2017-09-26 Futurewei Technologies, Inc. Certificateless data verification with revocable signatures
US10075292B2 (en) 2016-03-30 2018-09-11 Divx, Llc Systems and methods for quick start-up of playback
US10148989B2 (en) 2016-06-15 2018-12-04 Divx, Llc Systems and methods for encoding video content
WO2018024545A1 (en) * 2016-08-04 2018-02-08 Smardtv S.A. Method and device for checking authenticity of a hbbtv related application
US10341327B2 (en) 2016-12-06 2019-07-02 Bank Of America Corporation Enabling secure connections by managing signer certificates
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
DE102018208201A1 (de) * 2018-05-24 2019-11-28 Siemens Aktiengesellschaft Anordnung und Verfahren zum Verändern des Inhalts eines Wurzelzertifikatsspeichers eines technischen Geräts
WO2020101506A1 (en) * 2018-11-13 2020-05-22 Apple Inc. Wireless power transfer device authentication
CN110536030B (zh) * 2019-08-16 2021-11-16 咪咕文化科技有限公司 视频彩铃的传输方法、系统、电子设备及存储介质
US20210111902A1 (en) * 2019-10-11 2021-04-15 Qualcomm Incorporated System information protection at a network function in the core network
CN116228508B (zh) * 2023-05-10 2023-07-21 深圳奥联信息安全技术有限公司 一种密码生成和认证系统及方法

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5261002A (en) * 1992-03-13 1993-11-09 Digital Equipment Corporation Method of issuance and revocation of certificates of authenticity used in public key networks and other systems
US5825880A (en) * 1994-01-13 1998-10-20 Sudia; Frank W. Multi-step digital signature method and system
GB2288519A (en) * 1994-04-05 1995-10-18 Ibm Data encryption
DE69523553T2 (de) * 1994-07-29 2002-06-20 Tokyo Gas Co Ltd Figuren-datenübertragungssystem
DE69534757T2 (de) * 1994-09-15 2006-08-31 International Business Machines Corp. System und Verfahren zur sicheren Speicherung und Verteilung von Daten unter Verwendung digitaler Unterschriften
NZ296340A (en) * 1994-10-28 2000-01-28 Surety Technologies Inc Digital identification and authentication of documents by creating repository of hash values based on documents
US5748738A (en) * 1995-01-17 1998-05-05 Document Authentication Systems, Inc. System and method for electronic transmission, storage and retrieval of authenticated documents
JP4083218B2 (ja) * 1995-06-05 2008-04-30 サートコ・インコーポレーテッド マルチステップディジタル署名方法およびそのシステム
US5625693A (en) * 1995-07-07 1997-04-29 Thomson Consumer Electronics, Inc. Apparatus and method for authenticating transmitting applications in an interactive TV system
US6907399B1 (en) * 1995-08-21 2005-06-14 Pitney Bowes Inc. Secure user certification for electronic commerce employing value metering system
US6487658B1 (en) * 1995-10-02 2002-11-26 Corestreet Security, Ltd. Efficient certificate revocation
US6097811A (en) * 1995-11-02 2000-08-01 Micali; Silvio Tree-based certificate revocation system
US5666416A (en) * 1995-10-24 1997-09-09 Micali; Silvio Certificate revocation system
US5699431A (en) * 1995-11-13 1997-12-16 Northern Telecom Limited Method for efficient management of certificate revocation lists and update information
US5680458A (en) * 1995-11-14 1997-10-21 Microsoft Corporation Root key compromise recovery
US5745574A (en) * 1995-12-15 1998-04-28 Entegrity Solutions Corporation Security infrastructure for electronic transactions
US5761306A (en) * 1996-02-22 1998-06-02 Visa International Service Association Key replacement in a public key cryptosystem
US6085320A (en) * 1996-05-15 2000-07-04 Rsa Security Inc. Client/server protocol for proving authenticity
KR100458843B1 (ko) * 1996-05-31 2005-06-08 톰슨 콘슈머 일렉트로닉스, 인코포레이티드 암호화된비디오데이터및암호화되지않은비디오데이터를처리하는적응디코딩시스템
US5937066A (en) * 1996-10-02 1999-08-10 International Business Machines Corporation Two-phase cryptographic key recovery system
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5818440A (en) * 1997-04-15 1998-10-06 Time Warner Entertainment Co. L.P. Automatic execution of application on interactive television
FI106605B (fi) * 1997-04-16 2001-02-28 Nokia Networks Oy Autentikointimenetelmä
AU7067398A (en) 1997-04-25 1998-11-24 British Telecommunications Public Limited Company Wireless communications network planning
US5948104A (en) * 1997-05-23 1999-09-07 Neuromedical Systems, Inc. System and method for automated anti-viral file update
JPH1127641A (ja) * 1997-07-07 1999-01-29 Toshiba Corp テレビジョン受信機
JPH1165904A (ja) * 1997-08-15 1999-03-09 Nec Corp データ管理システム、データ管理方法およびデータ管理プログラムを記録した媒体
US7017046B2 (en) 1997-09-22 2006-03-21 Proofspace, Inc. System and method for graphical indicia for the certification of records
US6298153B1 (en) * 1998-01-16 2001-10-02 Canon Kabushiki Kaisha Digital signature method and information communication system and apparatus using such method
EP0946019A1 (de) * 1998-03-25 1999-09-29 CANAL+ Société Anonyme Authentifizierung von Daten in einem digitalen Übertragungssystem
US6212633B1 (en) * 1998-06-26 2001-04-03 Vlsi Technology, Inc. Secure data communication over a memory-mapped serial communications interface utilizing a distributed firewall
EP1014620B1 (de) * 1998-07-14 2012-05-30 Sony Corporation Verfahren zur datenübertragungssteuerung, datenübertragungsverfahren, datensender und empfänger
CN100401272C (zh) * 1998-07-22 2008-07-09 松下电器产业株式会社 数字数据记录装置和方法
US7404077B1 (en) 1999-01-29 2008-07-22 International Business Machines Corporation Extension of X.509 certificates to simultaneously support multiple cryptographic algorithms
AU6097000A (en) 1999-07-15 2001-02-05 Frank W Sudia Certificate revocation notification systems
JP3725384B2 (ja) * 1999-11-24 2005-12-07 富士通株式会社 認証装置、認証方法及びその装置での処理をコンピュータに行なわせるためのプログラムを格納した記憶媒体
US7353209B1 (en) * 2000-01-14 2008-04-01 Microsoft Corporation Releasing decrypted digital content to an authenticated path
EP1143658A1 (de) * 2000-04-03 2001-10-10 Canal+ Technologies Société Anonyme Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten
US7047404B1 (en) * 2000-05-16 2006-05-16 Surety Llc Method and apparatus for self-authenticating digital records

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102015212037A1 (de) * 2015-06-29 2016-12-29 Siemens Aktiengesellschaft Überwachen eines Übertragungsstreckenabschnitts zur Übertragung von Daten zwischen zwei Teilnehmern einer Kommunikationsverbindung

Also Published As

Publication number Publication date
MY128376A (en) 2007-01-31
KR100726347B1 (ko) 2007-06-11
DE60143326D1 (de) 2010-12-02
ES2250346T3 (es) 2006-04-16
WO2001076135A1 (en) 2001-10-11
DK1269681T3 (da) 2005-11-07
US20040125959A1 (en) 2004-07-01
CY1106061T1 (el) 2011-06-08
HK1101233A1 (en) 2007-10-12
JP2010183588A (ja) 2010-08-19
DK1699165T3 (da) 2008-04-21
CN1897527A (zh) 2007-01-17
HK1117671A1 (en) 2009-01-16
CY1107958T1 (el) 2013-09-04
KR20030068395A (ko) 2003-08-21
CN101114908B (zh) 2012-07-18
EP1699164A2 (de) 2006-09-06
ATE485649T1 (de) 2010-11-15
MXPA02009771A (es) 2004-09-06
US7917746B2 (en) 2011-03-29
CN101114908A (zh) 2008-01-30
MY146142A (en) 2012-06-29
BRPI0117237B1 (pt) 2016-04-26
EP1269681A1 (de) 2003-01-02
CN1897527B (zh) 2012-08-22
US20060259771A1 (en) 2006-11-16
CN1276613C (zh) 2006-09-20
US20070025552A1 (en) 2007-02-01
CN1897526B (zh) 2012-07-04
EP1641212A3 (de) 2010-09-08
JP2006311621A (ja) 2006-11-09
DE60114167D1 (de) 2005-11-24
JP2006311620A (ja) 2006-11-09
US20070025553A1 (en) 2007-02-01
MY152592A (en) 2014-10-31
US20080263354A1 (en) 2008-10-23
EP1699165A3 (de) 2006-10-11
US7822975B2 (en) 2010-10-26
CN1897525A (zh) 2007-01-17
DE60114167T2 (de) 2006-07-13
EP1143658A1 (de) 2001-10-10
CN1897526A (zh) 2007-01-17
US7437561B2 (en) 2008-10-14
MY146128A (en) 2012-06-29
JP4936410B2 (ja) 2012-05-23
EP1622303B1 (de) 2017-07-26
JP4936402B2 (ja) 2012-05-23
HK1101235A1 (en) 2007-10-12
JP3962082B2 (ja) 2007-08-22
BR0109815A (pt) 2003-01-21
EP1269681B1 (de) 2005-10-19
JP2006314137A (ja) 2006-11-16
DE60133233D1 (de) 2008-04-24
ATE307438T1 (de) 2005-11-15
JP4873550B2 (ja) 2012-02-08
US20060256967A1 (en) 2006-11-16
EP1622303A1 (de) 2006-02-01
EP1641212A2 (de) 2006-03-29
CN1432230A (zh) 2003-07-23
EP1699165B1 (de) 2008-03-12
US7861084B2 (en) 2010-12-28
JP2009005416A (ja) 2009-01-08
JP2003530013A (ja) 2003-10-07
EP1699164A3 (de) 2006-11-02
JP3962083B2 (ja) 2007-08-22
MY156311A (en) 2016-01-29
US7809140B2 (en) 2010-10-05
EP1699165A2 (de) 2006-09-06
AU2699501A (en) 2001-10-15
ATE389272T1 (de) 2008-03-15
US8015401B2 (en) 2011-09-06
JP2007006520A (ja) 2007-01-11
EP1699164B1 (de) 2010-10-20

Similar Documents

Publication Publication Date Title
DE60133233T2 (de) Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden
DE69936156T2 (de) Authentifizierung von Daten in einem digitalen Übertragungssystem
DE60217931T2 (de) Vorrichtungen, verfahren und produkte zur signierung und authentifizierung, insbesondere für digitale dvb/mpeg-mhp-datenströme
DE60002754T2 (de) Durchführung der objektsicherung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition