DE60114167T2 - Authentifizierung von in einem digitalen übertragungssystem übertragenen daten - Google Patents

Authentifizierung von in einem digitalen übertragungssystem übertragenen daten Download PDF

Info

Publication number
DE60114167T2
DE60114167T2 DE60114167T DE60114167T DE60114167T2 DE 60114167 T2 DE60114167 T2 DE 60114167T2 DE 60114167 T DE60114167 T DE 60114167T DE 60114167 T DE60114167 T DE 60114167T DE 60114167 T2 DE60114167 T2 DE 60114167T2
Authority
DE
Germany
Prior art keywords
data
certificate
decoder
key
encrypted
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
DE60114167T
Other languages
English (en)
Other versions
DE60114167D1 (de
Inventor
Gerard Jean-Bernard BEUQUE
Philippe Poulain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
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
Publication of DE60114167D1 publication Critical patent/DE60114167D1/de
Application granted granted Critical
Publication of DE60114167T2 publication Critical patent/DE60114167T2/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 or manipulating encoded video stream scene graphs
    • H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream 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 or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)
  • Small-Scale Networks (AREA)
  • Storage Device Security (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Television Systems (AREA)

Description

  • Die vorliegende Erfindung betrifft ein Verfahren zur Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten.
  • Die Rundfunksendung von digitalen Daten ist auf dem Gebiet der Gebührengfernsehsysteme hinreichend bekannt, wo verwürfelte, audiovisuelle Informationen im Allgemeinen durch einen Satteliten oder eine Satteliten/Kabel-Strecke zu einer Zahl von Abonnenten gesendet werden, von denen jeder einen Decoder besitzt, der zur Entwürfelung des übertragenen Programms für die darauf folgende Betrachtung geeignet ist. Terrestrische digitale Rundfunksysteme sind ebenfalls bekannt. Neuartige Systeme haben die Rundfunkstrecke auch dazu benutzt, andere Daten zusätzlich oder als audiovisuelle Daten, wie Computerprogramme oder interaktive Anwendungen für den Decoder, oder zu einem angeschlossenen PC zu übertragen.
  • Ein besonderes Problem bei der Übertragung von Anwendungsdaten liegt in der Notwendigkeit, die Integrität oder Unversehrtheit und den Ursprung derartiger Daten zu prüfen. Da derartige Daten benutzt werden können, den Decoder neu zu konfigurieren, sowie für die Durchführung einer Zahl von interaktiven Anwendungen, ist es wesentlich, dass die empfangenen Daten vollständig und als von einer bekannten Quelle stammend identifiziert werden. Anderenfalls können Verarbeitungsprobleme bei dem Herunterladen von unvollständigen Daten auftreten, sowie die Gefahr, dass der Decoder für Angriffe durch dritte Parteien oder dergleichen offen wird.
  • Die Prüfung der Unversehrtheit derartiger Daten kann geführt werden durch die Prüfung des Paketstroms von direkt durch den Decoder empfangenen Daten. Vor der Übertragung werden Pakete im Allgemeinen bezeichnet durch Anwendung eines Hashalgorithmus auf wenigstens einigen der Daten in dem Paket. Der resultierende Hashwert wird in dem Paket gespeichert. Am Empfang des Datenpakets wendet der Decoder denselben Hashalgorithmus auf die Daten an und vergleicht den durch den Decoder berechneten Hashwert mit dem in dem empfangenen Paket gespeicherten Hashwert, um die Unversehrtheit oder Integrität der empfangenen Daten zu prüfen. Zum Beispiel ist in dem Fall eines Fehlers oder Einbruchs in der Übertragung der berechnete Hashwert nicht derselbe wie der empfangene Hashwert. Der Decoder wird dann für die Anwesenheit von möglichen Fehlern in dem herunter geladenen Datenpaket gewarnt und das fehlerhafte Datenpaket neu laden.
  • Ein Problem bei der Benutzung eines bekannten Hashalgorithmus, wie der Massage Digest algorithm MD5, besteht darin, dass die Berechnung des Hashwerts gemäß öffentlich bekannten Reihen von Berechnungsschritten erfolgt, mit dem Ergebnis, dass jeder den Hashwert eines Datenpakets berechnen kann. Daher ist es nicht möglich, den Ursprung eines durch den Decoder empfangenen Datenpakets zu prüfen. Das kann von besonderer Bedeutung sein, wenn die empfangenen Daten die Betriebsdatendateien des Decoders ändern.
  • Zur Lösung dieses Problems kann, anstelle der Benutzung eines Hashalgorithmus zur Berechnung eines Hashwerts für wenigstens einige der Daten, an einen Unterschriftswert eines Datenpakets durch Anwendung eines nur dem Sender bekannten Geheimschlüssels berechnet werden. Dieser Schlüssel kann gewonnen werden aus einem symmetrischen Schlüsselalgorithmus, wie dem Data Encryption Standard oder DES Algorithmus, wobei der Decoder einen äquivalenten Schlüssel speichert. Jedoch kann eine größere Bequemlichkeit gebildet werden durch Anwendung eines symmetrischen öffentlichen/privaten Schlüsselalgorithmus, wie der Rivest, Shamir und Adleman oder RSA Algorithmus, in dem der öffentliche und der private Schlüssel komplementäre Teile einer mathematischen Gleichung bilden.
  • Der für die Erzeugung der Datenpakete verantwortliche Sender speichert den privaten Schlüssel und berechnet den den privaten Schlüssel benutzenden Unterschriftswert. Der öffentliche Schlüssel wird in den Decodern gespeichert, die vorgesehen sind zum Empfang der Daten durch eine harte Codierung des öffentlichen Schlüssels in dem Speicher des Decoders während der Herstellung. Beim Empfang des Datenpakets prüft der Decoder den Signaturwert durch Anwendung des gespeicherten öffentlichen Schlüssels durch Vergleich der empfangenen Daten mit dem Ergebnis der Anwendung des öffentlichen Schlüsselalgorithmus auf dem empfangenen Signaturwert.
  • Selbst in derartigen Sicherheitssystemen kann für den Wert des privaten Schlüssels ein Kompromiss gefunden werden, indem er ungesetzlich öffentlich verteilt wird. In derartigen Fällen wird es für den Sender notwendig, die Anwendung des äquivalenten öffentlichen Schlüssels schnell zu widerrufen, um so den unberechtigten Empfang der Datenpakete zu verhindern. Zusätzlich wird es auch nötig, dass ein neues öffentliches/privates Schlüsselpaar benutzt wird. Daher muss der Sender den in den Decodern eines gesetzmäßigen Benutzers gespeicherten öffentlichen Schlüssel durch einen neuen öffentlichen Schlüssel ersetzen. Abhängig von der Empfindlichkeit des öffentlichen Schlüssels kann dieses erfordern, dass der Sender die kostenintensive und mühsame Rückkehr dieser Decoder zu dem Hersteller für die harte Codierung des neuen öffentlichen Schlüssels in die Speicher dieser Decoder organisiert.
  • Die GB 2 301 919 lehrt ein Mehrschritt-Unterzeichnungssystem, das mehrfachen Unterzeichnungsgeräten zur Festlegung einer einzelnen Unterschrift dient, die durch einen einzigen öffentlichen Überprüfungsschlüssel geprüft werden können. Jedes Markiergerät besitzt einen Anteil des Signaturschlüssels und bildet eine teilweise Signatur aufgrund der Autorisierung von mehreren Autorisierungsagenten. Die Sicherheit des Systems wird verbessert durch Verteilung der Fähigkeit zur Festlegung von Signaturen unter mehreren Markiergeräten und durch Verteilung der Autorität zur Anbringung einer teilweisen Signatur unter mehreren Autorisierungsagenten. Jedoch müssen im Fall einer Dissimulation des privaten Schlüssels alle Empfänger den öffentlichen Prüfschlüssel aktualisieren, was kostenintensiv und langweilig ist, insbesondere da, wie oben beschrieben, der Schlüssel zum Beispiel in einem Decoder hart codiert ist.
  • In wenigstens ihren bevorzugten Ausführungsformen versucht die vorliegende Erfindung dieses und andere Probleme durch eine Lösung zu lösen, die resistent ist zu der Dissimulation eines privaten Schlüssels.
  • Ein erster Aspekt der vorliegenden Erfindung bildet ein Verfahren zur Authentifizierung von Daten, die in einem digitalen Übertragungssystem übertragen werden, wobei das Verfahren vor der Übertragung folgende Schritte enthält:
    Bestimmung von wenigstens zwei verschlüsselten Werten für wenigstens einige der Daten, wobei jeder verschlüsselte Wert für dieselben Daten bestimmt ist durch An wendung eines Schlüssels eines bestimmten Verschlüsselungsalgorithmus und Ausgabe der wenigstens zwei verschlüsselten Werte mit den Daten.
  • Die vorliegende Erfindung ist insbesondere anwendbar, jedoch nicht darauf beschränkt, auf Situationen, wo es erwünscht ist, mit Sicherheit sensitive Daten zu aktualisieren, wie einen Schlüssel zur Anwendung in einem neuen Verschlüsselungsalgorithmus, um zu gewährleisten, dass die Daten "wie ausgegeben" empfangen werden. Zur Bildung einer derartigen Sicherheit werden wenigstens zwei verschlüsselte Werte für wenigstens einige, vorzugsweise die Mehrheit, noch bevorzugter aller Daten ermittelt werden. Jeder verschlüsselte Wert wird bestimmt durch Anwendung eines jeweiligen Verschlüsselungsalgorithmus. Wenn einer der Schlüssel einen Kompromiss bildet, kann es für einen "Hacker" möglich sein, die Daten aufzufangen und den Inhalt der Daten und den verschlüsselten Wert, berechnet durch den Kompromissschlüssel, zu ändern. Jedoch ist es für den Hacker nicht möglich, den durch den Schlüssel ohne Kompromiss berechneten verschlüsselten Wert zu ändern. Daher werden bei der Prüfung der verschlüsselten Werte durch Anwendung von äquivalenten Schlüsseln auf die Schlüssel zur Berechnung der verschlüsselten Werte zwei Werte, die die äquivalenten Schlüssel benutzen, nicht dieselben sind und dadurch anzeigen, dass die Daten beschädigt worden sind.
  • Daher betrifft die vorliegende Erfindung ein Verfahren zur Authentifizierung der in einem digitalen Übertragungssystem übertragenden Daten mit folgenden Schritten:
    Empfang der Daten bei wenigstens zwei verschlüsselten Werten für wenigstens einige der Daten, wobei jeder verschlüsselte Wert für dieselben Daten bestimmt wird durch Anwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus,
    Speicherung von mehreren Schlüsseln,
    Verarbeitung jedes verschlüsselten Werts durch einen gespeicherten Schlüssel des jeweiligen Verschlüsselungsalgorithmus und
    Vergleich jedes darauf folgenden resultierenden Werts mit den wenigstens einigen Daten zur Authentifizierung der wenigstens einigen Daten.
  • Die vorliegende Erfindung betrifft außerdem eine Vorrichtung zur Authentifizierung von in einem digitalen Übertragungssystem zu übertragenen Daten mit:
    Mitteln zur Bestimmung von wenigstens zwei verschlüsselten Werten für wenigstens einige der Daten, wobei jeder verschlüsselte Wert bestimmt wird für dieselben Daten durch Anwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus und
    Mitteln zur Ausgabe der wenigstens zwei verschlüsselten Werte mit den Daten.
  • Die vorliegende Erfindung betrifft einen Empfänger/Decoder mit:
    Mitteln zum Empfang einer Datendatei mit Daten und wenigstens zwei verschlüsselten Werten, bestimmt für wenigstens einige der Daten, wobei jeder verschlüsselte Wert für dieselben Daten durch Anwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus bestimmt ist,
    Mitteln zur Speicherung von mehreren Schlüsseln,
    Mitteln zur Verarbeitung jedes verschlüsselten Werts durch einen gespeicherten Schlüssel des jeweiligen Verschlüsselungsalgorithmus und
    Mitteln zum Vergleich jedes darauf folgenden resultierenden Werts mit den wenigstens einigen der Daten zur Authentifizierung der wenigstens einigen der Daten.
  • Der hier benutze Ausdruck "Empfänger/Decoder" oder "Decoder" kann gleichwertig sein mit einem Empfänger für den Empfang von codierten oder nicht codierten Signalen, zum Beispiel Fernseh- und/oder Hochfrequenzsignalen, die durch dieselben Mittel gesendet oder übertragen werden. Der Ausdruck kann auch gleichwertig sein mit einem Decoder zur Decodierung von empfangenen Signalen. Ausführungsformen von derartigen Empfängern/Decodern kann einen Decoder integral mit dem Empfänger für die Decodierung der empfangenen Signale enthalten, zum Beispiel in einer "Set Top Box", wie einem Decoder, der in Kombination mit einem räumlich getrennten Empfänger arbeitet, oder einem derartigen Decoder mit zusätzlichen Funktionen, wie ein so genannter Web Browser oder integriert mit anderen Geräten wie einem Videorecorder oder einem Fernsehgerät.
  • Wie hier benutzt, enthält der Ausdruck "digitales Übertragungssystem" jedes Übertragungssystem für die Übertragung oder Sendung für zum Beispiel primäre audiovisuelle oder multimedia-digitale Daten. Während die vorliegende Erfindung insbeson dere anwendbar ist auf ein digitales Rundfunkfernsehsystem, ist die Erfindung ebenso anwendbar auf ein festes Telekommunikationsnetz für Multimedia Internetanwendungen auf einem Kurzschlussfernsehen, usw.
  • Wie hier benutzt, enthält der Ausdruck "digitales Fernsehsystem" zum Beispiel ein Satteliten-, terrestrisches-, Kabel- und andere Systeme.
  • Geeignete Algorithmen für die Anwendung in dieser Erfindung zur Erzeugung von privaten/öffentlichen Schlüsseln können enthalten RSA, Fiat-Shamir oder Diffie-Hellman, und geeignete symmetrische Schlüsselalgorithmen können zum Beispiel einen Algorithmus vom Typ DES enthalten. Jedoch, wenn nicht obligatorisch in Anbetracht des Kontexts oder wenn nicht auf andere Weise geprüft, wird keine allgemeine Unterscheidung getroffen zwischen Schlüsseln für symmetrische Algorithmen oder denjenigen für öffentliche/private Algorithmen.
  • Die Ausdrücke "verwürfelt" und "verschlüsselt" und "Steuerwort" und "Schlüssel" wurden in verschiedenen Teilen in dem Text zum Zweck der Klarheit der Sprache benutzt. Es ist jedoch selbstverständlich, dass keine grundsätzliche Unterscheidung gemacht wird zwischen "verwürfelten Daten" und "verschlüsselten Daten" oder zwischen einem "Steuerwort" und einem "Schlüssel".
  • Außerdem wurden die Ausdrücke "verschlüsselt" und "markiert" und "entschlüsselt" und "geprüft" an verschiedenen Teilen in dem Text benutzt zum Zwecke der Klarheit der Sprache. Es ist jedoch verständlich, dass keine grundsätzliche Unterscheidung gemacht werden muss zwischen "verwürfelten Daten" und "markierten Daten" und "entschlüsselten Daten" und "geprüften Prüfdaten".
  • Auf ähnliche Weise dient der Ausdruck "äquivalenter Schlüssel" zur Bezeichnung eines Schlüssels für die Entschlüsselung der Daten, die durch einen ersten gewählten Schlüssel verschlüsselt wurden, oder umgekehrt.
  • Im Folgenden wird an einem Beispiel eine bevorzugte Ausführungsform der Erfindung anhand der beigefügten Figuren beschrieben. In den Figuren:
  • 1 zeigt einen schematischen Aufbau eines digitalen Fernsehsystems zur Anwendung mit der vorliegenden Erfindung,
  • 2 zeigt den Aufbau eines Decoders des Systems von 1,
  • 3 zeigt den Aufbau einer Zahl von Komponenten in dem MPEG-Rundfunk-Transportstrom,
  • 4 zeigt die Aufteilung einer Softwareanwendung in eine Zahl von MPEG Tabellen,
  • 5 zeigt den Zusammenhang zwischen DSM-CC Datendateien und den möglicherweise erzeugten MPEG-Tabellen,
  • 6 zeigt den Zusammenhang zwischen Clienten, Server, Netzverwalter, wie in dem Kontext von DSM-CC definiert,
  • 7 zeigt das authentifizierte Verzeichnis, Unterverzeichnis und Dateiobjekte,
  • 8 zeigt die Formate eines Senderzertifikats, eines Zertifikations-Autoritäts-Zertifikats und eines Root Certification Authority Zertifikats,
  • 9 zeigt das Format einer Zertifikats-Aufhebungsliste,
  • 10 zeigt das Format einer Root Certificate Management Message (RCMM),
  • 11 zeigt die Schritte in der Verarbeitung eines RCMM beim Empfang durch einen Decoder.
  • Eine Übersicht eines digitalen Fernsehsystems 1 gemäß der vorliegenden Erfindung ist in 1 dargestellt. Die Erfindung enthält ein weitestgehend bekanntes digitales Fernsehsystem 2, das das bekannte MPEG2 Komprimiersystem zur Übertragung der komprimierten digitalen Signale benutzt. Im Detail empfängt der MPEG2 Komprimierer 3 in einem Sendezentrum einen digitalen Signalstrom (im Allgemeinen einen Strom von Videosignalen). Der Komprimierer 3 ist durch eine Verbindung 5 mit einem Multiplexer und Verwürfeler 4 verbunden.
  • Der Multiplexer 4 empfängt mehrere, weitere Eingangssignale, stellt den Transportstrom zusammen und überträgt komprimierte digitale Signale zu einem Sender 6 über die Verbindung 7 zu dem Sendezentrum, das natürlich eine weite Vielfalt von Formen annehmen kann, einschließlich Telekommunikationsstrecken. Der Sender 6 überträgt elektromagnetische Signale über nach oben gerichtete Strecken 8 zu einem Sattelitentransponder 9, wo sie elektronisch verarbeitet und über eine nach unten gerichtete Strecke 10 zu einem erdgebundenen Empfänger 12 gesendet werden, in bekannter Weise in der Form einer Schüssel, die der Endbenutzer besitzt oder gemietet hat. Die durch den Empfänger 12 empfangenen Signale werden zu einem integrierten Empfänger/Decoder 13 übertragen, den der Endbenutzer besitzt oder gemietet hat, und sind mit dem Fernsehgerät 14 des Endbenutzers verbunden. Der Empfänger/Decoder 13 decodiert das komprimierte MPEG2 Signal in ein Fernsehsignal für das Fernsehgerät 14.
  • Andere Transportkanäle für die Übertragung der Daten sind natürlich möglich, wie eine terrestrische Sendung, Kabelübertragung, kombinierte Satelliten/Kabelstrecken, Telefonnetze, usw.
  • In einem Mehrkanalsystem verarbeitet der Multiplexer 4 Audio- und Videoinformationen von einer Anzahl von Quellen und arbeitet zusammen mit dem Sender 6 zur Sendung der Informationen über eine entsprechende Zahl von Kanälen. Zusätzlich zu audiovisuellen Informationen können Nachrichten oder Anwendungen oder eine andere Art von digitalen Daten in einige oder alle diese Kanäle eingeführt werden, die mit den übertragenen digitalen Audio- und Videoinformationen verschachtelt sind. In einem derartigen Fall wird ein Strom von digitalen Daten, zum Beispiel in der Form von DSM-CC (Digital Storage Media Command and Control) in Form von Softwaredateien und Nachrichten komprimiert und durch den Komprimierer 3 in das MPEG Format paktiert. Das Herunterladen der Softwaremodule wird später detaillierter beschrieben.
  • Ein System 15 für einen bedingten Zugriff ist mit dem Multiplexer 4 und dem Empfänger/Decoder 13 verbunden und liegt teilweise in dem Sendezentrum und teilweise in dem Decoder. Es ermöglicht dem Endbenutzer den Zugriff zu digitalen Fernsehsendungen von einem oder mehreren Sendeanbietern. Eine Smart Card, die Nachrichten für die kommerziellen Angebote entschlüsseln kann (das heißt ein oder mehrere durch den Sendeanbieter gekaufte Fernsehprogramme), kann in dem Empfänger/Decoder 13 eingefügt werden. Durch Anwendung des Decoders 13 und der Smart Card kann der Endbenutzer kommerzielle Angebote in einem Abonnementmodus oder einem Gebührenfernsehmodus kaufen. In der Praxis kann der Decoder dafür ausgebildet sein, Steuersysteme für einen mehrfachen Zugriff zu verarbeiten, zum Beispiel von dem so genannten Simulcrypt- oder Multicrypt-Aufbau.
  • Wie oben erwähnt, werden die durch das System übertragenen Programme bei dem Multiplexer 4 verwürfelt, und die Bedingungen und die Verschlüsselungsschlüssel einer bestimmten Übertragung zugeführt, die durch das System 15 für den bedingten Zugriff bestimmt ist. Die Übertragung von verwürfelten Daten auf diese Weise ist auf dem Gebiet der Gebührenfernsehsysteme hinreichend bekannt. Im Allgemeinen werden verwürfelte Daten zusammen mit einem Steuerwort übertragen zur Entwürfelung der Daten, während das Steuerwort selbst durch einen so genannten Auswertschlüssel verschlüsselt ist und in verschlüsselter Form übertragen wird.
  • Die verwürfelten Daten und das verschlüsselte Steuerwort werden dann durch den Decoder 13 empfangen, der einen Zugriff hat zu einem Äquivalent des Auswertschlüssels, der gespeichert ist auf einer in den Decoder eingefügten Smart Card zur Entschlüsselung des verschlüsselten Steuerworts und danach zur Entwürfelung der übertragenen Daten. Ein bezahlt habender Abonnent empfängt zum Beispiel in einer Sendung monatlich EMM (Entitlement Managemant Message) den Auswertschlüssel, der benötigt wird für die Entschlüsselung des verschlüsselten Steuerworts, um so die Betrachtung der Übertragung zu ermöglichen. Zusätzlich zu ihrer Anwendung in der Entschlüsselung von audiovisuellen Programmen, können ähnliche Auswertschlüssel erzeugt und für die Anwendung in der Prüfung von anderen Daten wie Softwaremodulen erzeugt werden, wie später beschrieben wird.
  • Ein interaktives System 16, das ebenfalls mit dem Multiplexer 4 verbunden ist, und der Empfänger/Decoder 13, der wieder teilweise in dem Sendezentrum und teilweise in dem Decoder liegt, ermöglicht dem Endbenutzer, über einen Modemrückkanal 17 mit den verschiedenen Anwendungen zusammen zu arbeiten. Der Modem-Rückkanal kann ebenso dienen für die Kommunikation, die in dem System 15 für den bedingten Zugriff benutzt wird. Ein interaktives System kann zum Beispiel benutzt werden, um es einem Betrachter zu ermöglichen, unverzüglich mit dem Übertragungszentrum zu kommunizieren zur Anforderung einer Berechtigung für das Betrachten eines bestimmten Ereignisses, Herunterladen einer Anwendung, usw.
  • Körperliche Elemente des Empfängers/Decoders
  • In 2 werden nunmehr die körperlichen Elemente des Empfängers/Decoders 13 oder der Set Top Box für die Anwendung in der vorliegenden Erfindung kurz beschrieben. Die in dieser Figur dargestellten Elemente werden anhand von funktionalen Blöcken beschrieben.
  • Der Decoder 13 enthält einen Zentralprozessor 20 mit zugehörigen Speicherelementen zum Empfang von Eingangsdaten von einer seriellen Schnittstelle 21, einer parallelen Schnittstelle 22 und einem Modem 23 (verbunden mit dem Modemrückkanal 17 von 1).
  • Der Decoder dient zusätzlich zum Empfang von Eingängen von einer Infrarot-Fernsteuereinheit 25 über eine Steuereinheit 26 und von Schaltkontakten 24 auf der Vorderseite des Decoders. Der Decoder besitzt außerdem zwei Smart Card Leser 27, 28 zum Lesen von Bank- bzw. Abonnements-Smart Cards 29 bzw. 30. Der Eingang kann auch über eine (nicht dargestellte) Infrarot-Tastatur empfangen werden. Der Abonnement-Smart Card Leser 28 arbeitet zusammen mit einer eingefügten Abonnement Card 30 und mit einer Einheit 29 für einen bedingten Zugriff, um das benötigte Steuerwort zu einem Demultiplexer/Entwürfeler 30 zu liefern, damit das verschlüsselte Rundfunksignal entwürfelt werden kann. Der Decoder enthält außerdem einen konventionellen Tuner 31 und Demodulator 32 zum Empfang und zur Demodulation der Satellitenübertragung, bevor es durch die Einheit 30 gefiltert und demultiplexiert wird.
  • Die Verarbeitung der Daten in dem Decoder erfolgt im Allgemeinen durch den Zentralprozessor 20. Der Software-Aufbau des Zentralprozessors entspricht einer virtuellen Maschine, die zusammen arbeitet mit einem Operationssystems eines niedrigeren Levels, das in den Hardwarekomponenten des Decoders ausgeführt wird.
  • Paketstruktur der übertragenen Daten
  • Im Folgenden wird, unter Bezug auf die 3 und 4, die Paketstruktur der Daten in dem Sende-MPEG-Transportstrom beschrieben, der von dem Sender zu dem Decoder übertragen wird. Es sei erwähnt, dass, während die Beschreibung sich auf das in dem MPEG Standard benutzte Tabulationsformat bezieht, dieselben Prinzipien ebenso anwendbar sind auf andere Formate von paktierten Datenströmen.
  • Insbesondere in Bezug auf die 3: ein MPEG Bitstrom enthält eine Programmzugriffstabelle ("PAT") 40 mit einer Paketidentifizierung ("PID") von 0. Die PAT enthält Hinweise auf die PIDs der Programmmaptabellen ("PMTs") 41 einer Anzahl von Programmen. Jede PMT enthält einen Hinweis auf die PIDs der Ströme von Audio-MPEG Tabellen 42 und Video-MPEG Tabellen 43 für dieses Programm. Ein Paket mit einer PID von null, d. h. die Programmzugriffstabelle 40, bildet den Eingabepunkt für alle MPEG-Zugriffe.
  • Zum Herunterladen von Anwendungen und Daten dafür werden zwei neue Stromtypen definiert, und die relevante PMT enthält außerdem Hinweise auf die PIDs der Ströme von Anwendungs- MPEG-Tabellen 44 (oder Abschnitte davon) und Daten MPEG Tabellen 45 (oder Abschnitte davon) und Daten MPEG Tabellen 45 (oder Abschnitte davon). Wenngleich es in manchen Fällen bequem sein kann, getrennte Stromtypen für die durchführbare Anwendungssoftware und Daten für die Verarbeitung durch diese Software zu definieren, ist dieses nicht wesentlich. In anderen Ausführungen können Daten und der Ausführungscode in einem einzigen Strom zusammengestellt werden, zu dem über die PMT ein Zugriff besteht, wie beschrieben.
  • In 4 ist für das Herunterladen zum Beispiel eine Anwendung in dem Strom 44, die Anwendung 46 in Module 47 aufgeteilt, von denen jedes durch eine MPEG Ta belle gebildet ist. Einige dieser Tabellen enthalten einen einzigen Abschnitt, während andere aus bis zu mehreren Abschnitten 48 bestehen. Ein typischer Abschnitt 48 enthält einen Header, der eine Ein-Byte-Tabellenidentifikation ("TID") 50, die Abschnittsnummer 51 dieses Abschnitts in der Tabelle, die Gesamtzahl 52 der Abschnitte in der Tabelle und eine Zwei-Byte-TID Erweiterungsreferenz 53 enthält. Jeder Abschnitt enthält ein Teil 54 und eine CRC 55. Für eine bestimmte Tabelle 47 haben alte Abschnitte 48, die die Tabelle 47 bilden, dieselbe TID 50 und dieselbe TID Erweiterung 53. Für eine bestimmte Anwendung 46 haben alle der die Anwendung 46 durchführenden Tabellen 47 dieselbe TID 50, aber unterschiedliche jeweilige TID Erweiterungen.
  • Für jede Anwendung 46 wird eine einzige MPEG-Tabelle als eine Verzeichnistabelle 56 benutzt. Die Verzeichnistabelle 56 hat in ihrem Header dieselbe TID wie die anderen, die Anwendung ausmachenden Tabellen 47. Jedoch hat die Verzeichnistabelle eine vorbestimmte TID Erweiterung von null für Identifizierzwecke, und aufgrund der Tatsache wird nur eine einzige Tabelle für die Informationen in dem Verzeichnis benötigt. Alle anderen Tabellen 47 haben normalerweise nicht-null-TID-Erweiterungen und bestehen aus einer Anzahl von zugehörigen Abschnitten 48. Der Header der Verzeichnistabelle enthält außerdem eine Versionsnummer der herunterzuladenden Anwendung.
  • Wieder zu 3: Die PAT 40, die PMTs 41 und die Anwendungs- und Datenstromkomponenten 44, 45 werden zyklisch übertragen. Jede Anwendung, die übertragen wird, hat eine jeweilige vorbestimmte TID. Zum Herunterladen einer Anwendung wird die MPEG Tabelle mit einer richtigen TID und einer TID Erweiterung von null zu dem Empfänger/Decoder heruntergeladen. Das ist die Verzeichnistabelle für die benötigte Anwendung. Die Daten in dem Verzeichnis werden dann verarbeitet, um die TID Erweiterungen der die benötigte Anwendung bildenden Tabellen zu bestimmen. Danach können jede benötigte Tabelle mit derselben TID wie die Verzeichnistabelle und eine aus dem Verzeichnis ermittelte TID Erweiterung heruntergeladen werden.
  • Der Decoder dient zur Prüfung der Verzeichnistabelle für jede Aktualisierung davon. Das kann wieder periodisch erfolgen durch Herunterladen der Verzeichnistabelle, zum Beispiel alle 30 Sekunden oder eine oder fünf Minuten und Vergleich der Versi onsnummer der vorher herunter geladenen Verzeichnistabelle. Wenn die frisch heruntergeladene Versionsnummer die einer späten Version ist, dann werden die Tabellen für die vorangehende Verzeichnistabelle gelöscht, und die Tabellen für die neue Version werden heruntergeladen und zusammengestellt.
  • In einer alternativen Anordnung wird der ankommende Bitstrom gefiltert durch Anwendung einer Maske entsprechend der TID, TID Erweiterung und Versionsnummer mit Werten für die TID einer Anwendung, einer TID Erweiterung von null und einer Versionsnummer um eins größer als die Versionsnummer des derzeit heruntergeladenen Verzeichnisses. Daher kann ein Inkrement der Versionsnummer gelöscht werden, und das Verzeichnis wird nach seiner Detektierung herruntergeladen, und die Anwendung wird aktualisiert, wie oben beschrieben. Wenn eine Anwendung abgeschlossen werden soll, wird ein leeres Verzeichnis mit der nächsten Versionsnummer übertragen, aber ohne jede in dem Verzeichnis aufgelisteten Module. Aufgrund des Empfangs eines derartigen leeren Verzeichnisses wird der Decoder 2020 dafür programmiert, die Anwendung zu löschen.
  • In der Praxis können Software und Computerprogramme zur Durchführung der Anwendungen in dem Decoder über verschiedene Teile des Decoders eingeführt werden, insbesondere in dem Datenstrom, der in der beschriebenen Weise über eine Satellitenstrecke empfangen wird, jedoch auch über einen seriellen Anschluss, die Smart Card-Strecke usw.. Eine derartige Software kann "high level"-Anwendungen enthalten zur Durchführung der interaktiven Anwendungen in dem Decoder, wie den Netbrowsern, Quizanwendungen, Programmführern usw.. Software kann ebenfalls heruntergeladen werden zur Änderung der Arbeits-Konfiguration, zum Beispiel durch sogenannte "patches" oder dergleichen.
  • Anwendungen können auch über den Decoder heruntergeladen und zu einem mit dem Decoder verbundenen PC oder dergleichen gesendet werden. In einem derartigen Fall arbeitet der Decoder als Kommunikationsrooter für die Software, die möglicherweise über das angeschlossene Gerät läuft. Zusätzlich zu dieser Rootingfunktion kann der Decoder auch dafür arbeiten, die MPEG paktierten Daten zu konvertieren, vor dem Routing zu der PC Eingangscomputer-Datensoftware, organisiert zum Beispiel gemäß dem DSM-CC Protokoll (siehe unten).
  • Organisation von Daten in Datendateien
  • 5 zeigt den Zusammenhang zwischen in einem Satz von DSM-CC U-U organisierten Daten (Benutzer zu Benutzer) Datendateien 60 in einer zusammengestellten Anwendung 46 und eingekapselt in eine Reihe von MPEG Tabellen 47. Ein derartiger Zusammenhang ist in der WO99/49614 beschrieben, deren Inhalt hier als Referenz eingeführt wird.
  • Vor der Übertragung werden die Datendateien in Anwendungen 46 zusammengestellt und danach durch einen MPEG Komprimierer in MPEG Tabellen oder Module 47 paketiert, wie oben beschrieben, mit einem Header 49 zur Prüfung des MPEG Paketstroms und mit einer ID Tabelle, Versionsnummer usw.. Es sei bemerkt, dass keine feste Beziehung zwischen den in den Datendateien und den möglichen MPEG Tabellen 47 stehen muss. Nach dem Empfang und der Filterung durch den Decoder werden die Paketheader 49 verworfen oder gelöscht und die Anwendung 46 aus den Nutzdaten der Tabellen 47 wieder hergestellt.
  • Das DSM-CC Format für die Datendateien ist ein Standard, der eingeführt wurde insbesondere für die Benutzung in Multimedianetzen und der eine Reihe von Nachrichtenformaten und Sitzungsbefehlen für die Kommunikation zwischen einem Clientenbenutzer 70, einem Serverbenutzer 71 und einem Netz-Ressourcenmanager 72 enthält, wie in 6 gezeigt. Der Netz-Ressourcenmanager 72 kann angesehen werden als eine logische Einheit zur Verwaltung der Zuordnung der Ressourcen in einem Netz.
  • Die Kommunikation zwischen einem Clienten und einem Server wird durch eine Reihe von Sitzungen aufgebaut, wobei eine erste Reihe von Nachrichten zwischen einem Benutzer (Client 70 oder Server 71) und dem Netzmanager 72 zur Ausbildung der Clienten und/oder Server für die Kommunikation ausgetauscht wird. Derartige Nachrichten werden entsprechend dem so genannten DSM-CC U-N (Benutzer zu Netz)-Protokoll formatiert. Ein Untersatz dieses Protokolls wurde insbesondere für das Sendeherunterladen von Daten definiert.
  • Sobald eine Kommunikationstrecke hergestellt worden ist, werden Nachrichten zwischen einem Clienten 70 und einem Server 71 entsprechend dem DSM-CC U-U Protokoll ausgetauscht. Eine Folge von Nachrichten dieser Art entspricht den Datendateien 60 von 5. In dem Fall von DSM-CC U-U Nachrichten sind die Daten in einer Reihe von Nachrichten 61 organisiert, die entsprechend dem BIOP oder Broadcast InterOrb Protocol gruppiert sind.
  • Jede Nachricht oder jedes Objekt 61 enthält einen Header 62, einen Unter-Header 63 und Nutzdaten 64 mit den Daten selbst. Entsprechend dem BIOP-Protokoll enthält der Header 62 unter anderem eine Anzeige des Typs von Nachrichten und der BIOP-Version, während der Unter-Header den Typ des Objekts und andere Informationen anzeigt, die durch den Systemarchitekten definiert werden sollen.
  • Die Datenobjekte 64 in den Nutzdaten der DSM-CC U-U Dateien können allgemein als einer von drei Typen definiert werden: Verzeichnisobjekte, Dateiobjekte und Stromobjekte. Verzeichnisobjekte definieren Rootverzeichnisse oder Unterverzeichnisse für eine Reihe von zugeordneten Dateiobjekten mit den aktuellen Anwendungsdaten.
  • Stromobjekte können benutz werden zur Ermöglichung eines zeitlichen Zusammenhangs, der zwischen den Daten in den Dateien und dem MPEG Paketstrom selbst hergestellt werden soll. Diese können zum Beispiel in dem Fall von interaktiven Anwendungen benutzt werden, die in den Datendateien enthalten sind und mit den elementaren Video- oder Audioströmen synchronisiert werden sollen, die durch den Decoder empfangen und verarbeitet werden. Wie oben erwähnt, kann es auf andere Weise keine direkte Korrelation zwischen den MPEG-paketierten Daten und den Datendateien geben.
  • Anders als die MPEG Tabellen, wo ein einziges Verzeichnis einem Satz von Tabellen mit nur einem einzigen Wert der Hierarchie entspricht, können die Datendateien 60 in einer wesentlich komplexeren hierarchischen Weise organisiert sein. Wie bei in einem PC oder Server gespeicherten Dateien kann sich ein Haupt- oder Rootverzeichnis auf ein oder mehrere Unterverzeichnisse beziehen, die wiederum sich auf einen zweiten Wert von Datendateien beziehen. Erwähnt werden kann ein zweites Rootverzeichnis zusammen mit einem anderen Satz von Anwendungsdaten.
  • Dateistruktur für einen Satz von Datendateien
  • In 7 ist ein Beispiel einer Dateistruktur für einen Satz von Datendateien dargestellt. Ein Rootverzeichnis DIR A0, dargestellt bei 75, bezeichnet eine Gruppe von Unterverzeichnissen A1 bis Objektdateien 77. Zum Zwecke der Klarheit ist nur eine einzige Gruppe von Objektdateien F1, F2, usw. für das Unterverzeichnis A4 dargestellt. In der Praxis kann eine Anzahl von Gruppen von Objektdateien durch jedes der Unterverzeichnisse A1 bis A4 bezeichnet sein.
  • In jedem Verzeichnis und Unterverzeichnis wird ein Satz von Authentifikationsschritten für die mit diesem Verzeichnis verbundenen Dateien eingeführt. Hinsichtlich der Rootdatei 75 enthält der Unter-Header 63 einen Hashwert, gewonnen durch Anwendung eines Hashalgorithmus auf einige oder alle die Daten, die in den bei 76 dargestellten Unterverzeichnis Dateien A1 bis A4 gespeichert sind. Der benutzte Hashalgorithmus kann von einem bekannten Typ sein, wie zum Beispiel der Message Digest Algorithmus MD5.
  • In einer Ausführung kann der Algorithmus auf jede zugehörige Datei oder jedes Unterverzeichnis und einer Liste der Hashwerte für jedes Unterverzeichnis 76 angewendet werden, das vor der Übertragung in dem Rootverzeichnis gespeichert wurde. Jedoch kann, während eine derartige Lösung ein erhöhtes Maß an Prüfauflösung für die Prüfung jedes Unterverzeichnisses dargestellt wird, diese Lösung ziemlich ineffizient sein hinsichtlich der Verarbeitungszeit, die für den Decoder benötigt wird, die entsprechenden Signaturen zu berechnen. Daher enthält der Unterheader 63 des Verzeichnisses 79 vorzugsweise einen kumulativen Hashwert 79, berechnet durch Anwendung des MD5 Hashalgorithmus auf den kombinierten Unterheader und Nutzdatenabschnitte 63 bis 64 der Unterverzeichnisse 76, das heißt ohne den Header 62. Insbesondere sind die Hashwerte 82, die in den Unterverzeichnissen 76 enthalten sind und sich auf die Schicht der Dateiobjekte 77 beziehen, in dieser Hashberechnung enthalten.
  • In dem Fall des in 7 dargestellten Unterverzeichnisses A4 betrifft dieses Unterverzeichnis selbst einen Satz von Objektdateien F1–Fn, gezeigt bei 77. In diesem Fall wird ein kumulativer Hashwert 82 für die kombinierten Inhalte der Objektdateien 77 erzeugt. Dieser Wert ist enthalten in dem Hashvorgang, der den Hashwert 79 ergibt. Es ist daher nicht möglich, eine der Objektdateien 77 zu ändern, ohne den Hashwert 82 des Unterverzeichnisses 76 zu ändern, was wiederum den Hashwert 79 des Verzeichnisses 75 ändern würde.
  • Im vorliegenden Fall wird für alle Unterverzeichnisse A1–A4 ein kombinierter Hashwert in dem Unterverzeichnis berechnet. Dieser Hashwert wird gespeichert zusammen mit einem Identifizierer der Gruppe von Unterverzeichnissen, aus der die Daten entnommen worden sind. In andern Ausführungsformen kann eine Reihe von kombinierten oder individuellen Hashwerten und entsprechenden Identifizierern in dem Unterheader des Verzeichnisses gespeichert werden.
  • Zum Beispiel kann ein zweiter Satz von Unterverzeichnissen, ebenfalls für das Root-Verzeichnis, jedoch für einen anderen Satz von Daten oder Durchführbarkeitscodes, ebenfalls zusammen mit einem kumulativen Hashwert gruppiert sein, der für diese Unterverzeichnisse berechnet und in dem Subheader-Rootverzeichnis gespeichert ist. Ein einziger Hashwert für ein einziges Verzeichnis kann ebenfalls in dem Unterheader des Rootverzeichnisses gespeichert sein.
  • Die Autorisierung von Gruppen oder individuellen Datendateien vermeidet natürlich nicht das Rootverzeichnis (oder, tatsächlich, jede andere Datei), auch eine Bezugnahme auf die nicht-validierten oder ungehashten Datendateien, jedoch muss die Abwesenheit der Validation einer derartigen Datei in jedem Betrieb mit dieser Datei berücksichtigt werden. In dieser Beziehung kann es zum Beispiel notwendig sein, Stromobjekte in der Echtheit zu bestätigen.
  • Die Anwendung einer Hashfunktion in diesem Fall ermöglicht primär, dass der Decoder die Integrität oder Vollständigkeit der heruntergeladenen Datendateien prüft. In diesem Fall, zum Beispiel eines Fehlers oder einer Unterbrechung in der Übertragung, ergibt der Betrieb eines kumulativen Hashalgorithmus auf den empfangenen abhängigen Dateien nicht dasselbe Ergebnis wie der Hashwert für diese in dem Rootverzeichnis gespeicherten Dateien. Der Decoder wird dann gewarnt vor der Anwesenheit von möglichen Fehlern in den heruntergeladenen Daten und wird die falschen Datendateien neu laden.
  • Signaturwert für das Rootverzeichnis
  • Für die verbesserte Sicherheit wird ein Signaturwert für das Rootverzeichnis 75 berechnet. In dieser Ausführungsform wird ein privater/öffentlicher Schlüsselalgorithmus, wie der Rivest, Shamir und Adleman oder RSA Algorithmus benutzt, wobei der für die Erzeugung der Datendateien verantwortliche Sender den privaten Schlüsselwert besitzt und der öffentliche Schlüsselwert durch die Decoder aufrechterhalten wird. Alternativ kann der Geheimschlüssel einem durch einen symmetrischen Schlüsselalgorithmus gewonnenen Schlüssel entsprechen, so wie der Data Encryption Standard oder DES-Algorithmus.
  • Wie in 7 gezeigt, enthält das Rootverzeichnis 75 einen Sender-Identifizierer 80, der zu dem Decoder den öffentlichen Schlüssel identifiziert, der in der Prüfstufe zusammen mit dem berechneten Signaturwert 81 durch Anwendung des privaten Schlüssels des Senders erzeugt wird. In diesem Fall wird der Signaturwert 81 erzeugt durch Anwendung des privaten Schlüssels, gehalten durch den Sender auf einige oder alle Daten in dem Verzeichnis 75, vorzugsweise enthaltend die Nutzdaten 64 und/oder den kumulativen Hashwert oder Werte 79. Der Decoder kann dann diesen Signaturwert 81 durch den entsprechenden öffentlichen Schlüssel, identifiziert durch den Sender-Identifizierer 80 prüfen.
  • In diesem Beispiel sind die Daten in dem Verzeichnis 75 unverschlüsselt, und der private Schlüssel dient einfach zur Bildung eines Signaturwerts, der durch den öffentlichen Schlüssel verifizierbar ist. In alternativen Ausführungsformen können einige oder alle 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 eines Blocks von verschlüsselten Codes durch Anwendung eines Geheimschlüssels, dass ein Decoder die Integrität und den Ursprung des Verzeichnisses 75 verifiziert und, durch An wendung, die Integrität den Ursprung der Dateien, die durch dieses Rootverzeichnis betroffen sind, zu prüfen. Da die kumulativen Hashwerte für die entsprechenden Dateien in der Berechnung der Signatur 81 enthalten sind, ist es nicht möglich, diese Werte zu ändern, ohne dass diese bei der Verifikationsstufe detektiert werden. Da jeder Hashwert im Allgemeinen einzigartig ist für einen bestimmten Datensatz, wäre es daher nicht möglich, den Inhalt eines der abhängigen gehashten Dateien ohne den charakteristischen Hashwert und daher den resultierenden Signaturwert dieses Verzeichnisses zu ändern.
  • Natürlich ist eine Anzahl von Variationen möglich, besonders die Verringerung der gehashten oder der bei jeder Stufe gehashten Daten. Insbesondere kann, in dem Fall einer Signatur, benutzt zur Prüfung eines wichtigeren Wertes der Dateidaten die Verzeichnis Signatur oder der Hashwert erzeugt werden, durch Anwendung nur des niedrigeren Hashwerts und keiner anderen Daten.
  • Zum Beispiel kann der kombinierte Hashwert 79 in dem A0 Verzeichnis 75 erzeugt werden, durch Anwendung der kombinierten Hashwerte 82, 83 jeder der bei 76 gezeigten A1–A4 Unterverzeichnisse. Da diese Werte so einzigartig sind wie die Daten in den Nutzsignalen des Unterverzeichnisses, ist der kombinierte Hashwert 79 weiterhin einzigartig für die in Frage kommenden Unterverzeichnisse. Außerdem kann die Integrität des niedrigeren Werts der Objekte und der Verzeichnisdateien 77, 78 weiterhin angenommen werden, da die Hashwerte 82 weiterhin in der Kalkulation benutzt werden.
  • Sender digitale Zertifikate
  • In 8 werden der öffentliche Schlüssel 91 in dem Sender-Identifizierer 80 in einem digitalen Zertifikat zu dem Benutzer des Decoders geliefert, vorzugsweise in der Form des hinreichend bekannten International Standards Organisation (ISO) X.509 Standard, während der Herstellung in dem Speicher des Decoders hart codiert. Derartige Zertifikate werden durch die getreuen dritten Parteien auf die Hersteller der Decoder verteilt, die im Allgemeinen bezeichnet werden als Certification Authorities (CAs). Die Anwendung derartiger Zertifikate wird immer weiter verbreitet, primär durch das Secure Socket Layer (SSL) Sicherheitstransportprotokoll, entwickelt und genormt durch Netscape Communications für die Sicherung der Kreditkartentransaktionen über die World Wide Web (WWW).
  • So wie der öffentliche Schlüssel 91 und der Senderidentifizierer 80 enthalten die digitalen Zertifikate für den Sender oder Sender-Zertifikat 90 außerdem:
    • • eine Versionsnummer 92 des Senderzertifikats 90,
    • • eine Seriennummer 93 des Senderzertifikats 90,
    • • eine CA Identität 94 des CA, die das Senderzertifikat 90 verteilt hat,
    • • die Prüfperiode 95 des Senderzertifikats 90 zur Anzeige des Starts und des Endes der Zeitperiode, über die die Zertifikate benutzt werden sollen, und
    • • ein Signaturwert 96 des Senderzertifikats 90.
  • Wie aus dem Obigen hervorgeht, enthält das Senderzertifikat zwei verschiedene Identifizierer, einen ersten Identifizierer "Name des Herausgebers (issuer name)" Identifizierer entsprechend der Identität 94 des Verteilers des Zertifikats und einen zweiten "Gegenstandsname (subject name)" Identifizierer entsprechend dem Identifizierer 80, der den öffentlichen Schlüssel 91 identifiziert.
  • Der CA berechnet den Signaturwert 96 des Senderzertifikats 90 durch Anwendung eines privaten Schlüssels des CA oder CA privaten Schlüssels auf wenigstens einige oder alle Daten in dem Senderzertifikat. Der Decoder kann dann diesen Signaturwert prüfen durch Verarbeitung der Signatur durch einen entsprechenden CA öffentlichen Schlüssel 101, identifiziert durch die CA Identität 94, zur Ermittlung, ob der Inhalt des Zertifikats nach der Signatur durch das CA modifiziert worden ist.
  • Der Decoder kann mehrere derartige Zertifikate für verschiedene jeweilige Sender speichern.
  • Root-Zertifikationsautorität digitale Zertifikate
  • Wieder zu 8: Der entsprechende CA öffentliche Schlüssel 101 und der CA Identifzierer 94 werden dem Benutzer des Decoders in einem CA Zertifikat 100 zugeführt, der ebenfalls während der Herstellung in dem Decoder hart codiert worden ist. Das CA Zertifikat enthält auch:
    • • eine Versionsnummer 102 des CA Zertifikats 100,
    • • eine Seriennummer 103 des CA Zertifikats 100,
    • • eine RCA Identität 104, die Root-Zertifikatautorität (RCA) sowie das European Telecommunications Standard Institute (ETSI), das das CA Zertifikat 100 verteilt hat,
    • • eine Validitätsperiode 105 des CA Zertifikats 100 und
    • • einen Signaturwert 106 des CA Zertifikats 100.
  • Wie aus dem Obigen hervorgeht, enthält ein CA Zertifikat außerdem zwei verschiedene Identifizierer, einen ersten "issuer name"-Identifizierer, entsprechend der Identität 104 eines Verteilers des Zertifikats, und einen zweiten "subject name"-Identifizierer entsprechend dem Identifizierer 94, der den öffentlichen Schlüssel 101 identifiziert.
  • Die RCA berechnet den Signaturwert 106 des CA Zertifikats 100 durch Anwendung eines privaten Schlüssels der RCA, oder RCA privater Schlüssel, auf wenigstens einige oder alle der Daten in dem CA Zertifikat. Der Decoder kann dann den Signaturwert 106 durch Verarbeitung des Zertifikats durch einen entsprechenden RCA öffentlichen Schlüssel 111 prüfen, der identifiziert wird durch die RCA Identität 104, um zu ermitteln, ob der Inhalt des Zertifikats nach der Signatur durch die RCA nicht geändert worden ist.
  • Der Decoder kann mehrere derartige Zertifikate für verschiedene jeweilige CAs speichern.
  • Root-Zertifikationsautorität digitale Zertifikate
  • Der entsprechende RCA öffentliche Schlüssel 111 und der RCA Identifizierer 104 werden zu dem Benutzer des Decoders in einer RCA oder einem Root-Zertifikat 110 geliefert, der während der Herstellung ebenfalls in dem Speicher des Decoders hart codiert worden ist. Jeder Decoder enthält im Allgemeinen einen Satz von zwei oder mehreren Root-Zertifikaten. Jedes Root-Zertifikat 110 enthält außerdem:
    • • eine Versionsnummer 112 des Root-Zertifikats 110,
    • • eine Seriennummer 113 des Root-Zertifikats 110,
    • • die Gültigkeitsperiode 114 des Root-Zertifikats 110 und
    • • einen Signaturwert 115 des Root-Zertifikats 110.
  • Wie aus dem Obigen zu entnehmen ist, enthält das Root-Zertifikat nur einen einzigen Identifizierer, nämlich die Identität 104 des Verteilers des Zertifikats. Diese Identität 104 identifiziert außerdem den öffentlichen Schlüssel 111. Somit kann ein Root-Zertifikat definiert werden als ein Zertifikat, in dem der "issuer name" derselbe ist wie der "subject name".
  • Da das Root-Zertifikat das endgültige Zertifikat in der Kette des Senderzertifikats 90-CA Zertifikat 100-Root-Zertifikat 110 ist, ist das Root-Zertifikat selbst signiert, das heißt der Signaturwert wird berechnet durch Anwendung des öffentlichen/privaten Schlüssels auf den öffentlichen Schlüssel 111. Daher ist es richtig, dass der Inhalt eines Root-Zertifikats nicht öffentlich verfügbar wird.
  • Natürlich ist es für die RCA möglich, direkt die Senderzertifikate 90 zu dem Hersteller des Decoders zuliefern. In diesem Fall enthält das Senderzertifikat den RCA-Identifizierer 111 und wird durch Anwendung des RCA privaten Schlüssels signiert.
  • Zertifikat-Aufhebungsliste
  • Jedes der Senderzertifikate 90 und der CA Zertifikate 100 kann aufgehoben werden, zum Beispiel durch Löschung vor dem Ablauf der hier angegebenen Validitätsperiode, zum Beispiel ein privater Schlüssel entsprechend dem öffentlichen Schlüssel gespeichert in dem Zertifikat ein Kompromiss geschlossen wird. Eine derartige Auf hebung kann bewirkt werden durch die Übertragung zu dem Decoder einer Zertifikat-Aufhebungsliste (CRL = Certificate Revocation List) mit einer Liste der Seriennummern 92, 102 der aufzuhebenden Zertifikate. Bei der Aufhebung wird ein Zertifikat inoperabel gemacht, vorzugsweise durch Löschung des Zertifikats von dem Speicher des Decoders und durch das Herunterladen jedes unautorisierten und möglicher Weise krankhaften Datenpakets, signiert durch den einem Kompromiss unterliegenden privaten Schlüssel.
  • CRLs werden verteilt entweder durch ein CA oder ein RCA zu dem Sender, der die CRLs entweder über den Modemrückkanal 17 oder durch Sendung der CRLs über den MPEG Transportstrom überträgt. Es ist nicht wesentlich, dass der Sender die CRLs in alle Transportströme einfügt, die von dem Sender zu dem Decoder gesendet werden. Es ist ausreichend, wenn der Sender die CRLs in die Transportströme einfügt, auf die wahrscheinlich durch die Decoder abgestimmt wird. Zum Beispiel kann eine CRL als Datendatei in ein Rootverzeichnis 75 oder Unterverzeichnis 76 eines Satzes von Datendateien eingefügt werden, die von dem Sender zu dem Decoder gesendet werden.
  • Gemäß 9 enthält eine CRL 120 im Allgemeinen:
    • • die Identität 94 oder 104 der CA oder RCA, die die CRL 120 verteilt hat,
    • • das Datenwort 122, auf dem die CRL 120 ausgegeben wurde,
    • • das Datenwort 124, bei dem erwartet wird, dass die nächste CRL ausgegeben wird,
    • • eine Liste 125 der Seriennummern der aufzuhebenden Zertifikate, enthaltend für jedes aufgehobene Zertifikat die Zeit und das Datum der Aufhebung dieses Zertifikats und
    • • ein Signaturwert 126 der CRL, berechnet durch Anwendung des privaten Schlüssels der CA oder RCA, der die CRL 120 verteilt hat.
  • Beim Empfang einer CRL vergleicht der Decoder das Datenwort 122, auf dem dieses CRL 120 erwartet wurde, wie angekündigt durch die vorher empfangene CRL.
  • Wenn das Datenwort 122 der neu empfangenen CRL nicht später ist als das Datenwort 124, auf dem diese CRL erwartet wurde, wird die CRL ignoriert.
  • Wenn das Datenwort 122 der neu empfangenen CRL später ist als das Datenwort 124, auf dem die CRL erwartet wurde, wird die Signatur der CRL durch Anwendung des öffentlichen Schlüssels des Herausgebers der CA geprüft, wie identifiziert durch Anwendung der in der CRL enthaltenen Identität 94 oder 104.
  • Wenn die Integrität der CRL derart geprüft ist, wird die CRL verarbeitet zur Hinzufügung des Datenworts 124 für die Speicherung in dem permanenten Speicher das Datenwort 124, auf dem die Ausgabe der nächsten CRL erwartet wird, und zur Speicherung der Liste 125 der Seriennummern der aufgehobenen Zertifikate. Die empfangene Liste 125 der aufgehobenen Zertifikate wird ebenfalls in dem ROM-Speicher des Decoders gespeichert. Aus Gründen der Leistungsfähigkeit wird vorgezogen, dass die CRL in dem Speicher des Decoders gruppiert ist. Es wird außerdem vorgezogen, dass der Cachespeicher des Decoders CRLs 120 in einer baumartigen Weise speichert, wobei die CRL der RCA's am oberen Ende des "Baums" und die CRLs der CAs, zu dem RCA Verteilerzertifikate überträgt, die am unteren Ende des Baums liegen.
  • Wenn zum Beispiel in dem Fall der Aufhebung eines Senderzertifikats 90 der private Schlüssel des Senders auf einem Kompromiss beruht, fügt die Zertifizierungsbehörde für den Sender die Seriennummer 93 des Senderzertifikats 90 ihrer CRL 120 hinzu. Die Zertifikatsbehörde verteilt danach die neue CRL 120 zu allen Sendern, zu denen sie Senderzertifikate 90 für die Sendung verteilt. Sobald ein Decoder die neue CRL 120 heruntergeladen hat, zum Beispiel durch Zappen auf einem Senderkanal, wird der CRL Cache aktualisiert, und es erfolgt eine Aufhebung jedes Zertifikats, so wie es identifiziert ist in der Liste 125 des CRL 120.
  • Die Ersatz-Senderzertifikate 90 werden durch die Zertifikatsbehörde 100 erzeugt und in einem Verzeichnis 75 oder 76 einer Datei zu dem Benutzer gesendet. Das Ersatz-Senderzertifikat enthält unter anderem einen neuen öffentlichen Schlüssel 91, eine aktualisierte Versionsnummer 92, eine aktualisierte Validitätsperiode 95 und einen neuen Signaturwert 96, der durch den privaten Schlüssel der CA berechnet wird. Der Senderidentifizierer 80 und der CA Identifizierer 94 bleiben unverändert. Beim Empfang des Ersatz-Senderzertifikats 90 prüft der Decoder das Zertifikat durch Verarbeitung des Zertifikats durch den entsprechenden CA öffentlichen Schlüssel, in der ein durch die CA Identität 94 identifiziertes CA Zertifikat enthalten ist.
  • Bei der Aufhebung eines CA Zertifikats 100 wird die CRL von derjenigen CA von dem Speicher des Decoders beseitigt. Daher kann es erwünscht sein, absichtlich ein CA Zertifikat 100 aufzuheben, wenn zum Beispiel die Größe dieser CRL oder dieser CA zu groß wird für die Speicherung in dem Cachespeicher des Decoders. In diesem Fall fügt die RCA, die das CA Zertifikat 100 zu dem CA verteilt, die Seriennummer 103 dieses CA Zertifikats 100 seiner CRL hinzu. Die Root Certification Authority verteilt danach die neue CRL zu allen Sendern, zu der die CAs, zu der diese RCA CA Zertifikate daraufhin verteilt zu den Senderzertifikaten zu den Sendungen. Sobald ein Decoder die neue CRL heruntergeladen hat, zum Beispiel durch Zappen auf einem Senderkanal, wird der CRL Cache aktualisiert, und die Aufhebung der CA Zertifikate wird so in der Liste 125 der CRL 120 stattfinden.
  • Bei der Aufhebung eines CA Zertifikats 100 einer Zertifikationsbehörde, zusätzlich zu der Speicherung eines neuen CA Zertifikats für diese Zertifikationsbehörde in dem Decoder, ist es notwendig, die Senderzertifikate 90 für alle Sender zu ersetzen, zu denen diese Zertifikatsbehörde Zertifikate verteilt, da, wenn das private Schlüsselpaar für diese Zertifikatsbehörde nicht mehr gültig ist, neue Senderzertifikate 90, signiert durch einen anderen oder aktualisierten privaten Schlüssel der Zertifikatsbehörde, erforderlich werden. Ein Ersatz-CA-Zertifikat 100 wird durch die Root-Zertifikatsbehörde 110 erzeugt und in einem Verzeichnis 75 oder 76 einer Datei zu dem Benutzer gesendet. Ähnlich zu dem Ersatz-Senderzertifikat enthält das Ersatz-CA Zertifikat unter anderem einen neuen CA öffentlichen Schlüssel 101, eine aktualisierte Versionsnummer 102, eine aktualisierte Validitätsperiode 105 und einen neuen Signaturwert, berechnet durch den privaten Schlüssel der RCA. Der CA Identifizierer 94 und der RCA Identifizierer 104 bleiben unverändert. Beim Empfang des Ersatz-CA Zertifikats 100 prüft der Decoder das Zertifikat durch Verarbeitung des Zertifikats mit Anwendung des entsprechenden RCA öffentlichen Schlüssels, der in dem durch die RCA Identität 104 identifizierten RCA Zertifikat 110 enthalten ist.
  • Root-Zertifikat Verwaltungsnachricht
  • Bei der Aufhebung eines RCA Zertifikats 110 einer Root-Zertifikatsbehörde ist es erforderlich, das aufgehobene RCA Zertifikat durch eine neue RCA zu ersetzen. Wie oben beschrieben, sind RCA Zertifikate selbst-signiert, und daher ist die Aufnahme eines RCA Zertifikats in eine CRL nicht erwünscht, da es für einen Hacker möglich ist, in den Besitz des Zertifikats zu gelangen, wenn er den privaten Schlüssel für die Signierung der CRL kennt. Daher war es bisher notwendig, den Decoder zu dem Hersteller zurückzugeben, jedes Mal, wenn ein RCA Zertifikat aktualisiert werden muss, zum Beispiel, wenn es überholt oder aufgehoben wird.
  • Zur Lösung dieses Problems wird eine Root-Zertifikat Verwaltungsnachricht (RCMM = Root Certificate Management Message) durch die Root-Zertifikatsbehörde für die Sendung durch die Sender zu den Decodern erzeugt. Wie im Folgenden detaillierter erläutert wird, enthält eine RCMM, ähnlich zu einer CRL, eine Liste 125 von Seriennummern der aufzuhebenden Root-Zertifikate, die für jedes aufgehobene Root-Zertifikat die Zeit und das Datum für die Aufhebung dieses Zertifikat enthält, zusammen mit einer oder mehreren Ersatz-Root-Zertifikaten für diejenigen Zertifikate, die überholt oder in der Liste 125 identifiziert worden sind.
  • Wie ersichtlich, ist es in Anbetracht der sensitiven Inhalte (neue Root-Zertifikate) des RCMM wichtig, zu bewirken, dass eine RCMM durch den Decoder "as issued" (wie herausgegeben) zu dem Sender empfangen ist, das heißt sicher zu stellen, dass der Inhalt der RCMM sich zwischen der Verteilung und dem Empfang geändert hat. Es ist außerdem wichtig, sicher zu stellen, dass die RCMM nur Zugriff von den Decodern hat, für die die RCMM adressiert ist.
  • Zur Verbesserung der Sicherheit enthält ein RCMM, anders als eine CRL, wenigstens zwei Signaturwerte für wenigstens einige, vorzugsweise alle darin enthaltenen Daten. Jeder Signaturwert wird durch einen Schlüssel eines jeweiligen Verschlüsselungsalgorithmus berechnet, so wie ein privater Schlüssel des öffentlichen/privaten Schlüsselpaars.
  • Wenn eine RCMM durch eine Root-Zertifkatsbehörde (RCA) ausgegeben wird und ein neues Root-Zertifikat 110 enthält, enthält die RCMM wenigstens zwei Signaturwerte. Jeder Signaturwert wird durch einen jeweiligen privaten Schlüssel berechnet, zum Beispiel eine Zertifikationsbehörde, zu der RCA Zertifikate geliefert werden (obwohl jeder Schlüssel, für den der Decoder einen äquivalenten Schlüssel speichert, gewählt werden kann). Wenn, unbekannt zu einem dieser Zertifikationsautoritäten für den privaten Schlüssel ein Kompromiss geschlossen wurde, kann es für einen "Hacker" möglich sein, den Sender oder die Sender abzufangen und, wenn er den privaten Schlüssel von beiden Sendern und der Zertifikationsbehörde kennt, den Inhalt der RCMM und den Signaturwert der RCMM zu ändern, berechnet durch den privaten Schlüssel der Zertifikationsbehörde. Jedoch ist es für den Hacker nicht möglich, den Signaturwert, berechnet aus dem privaten Schlüssel der anderen Zertifikatsbehörde, zu ändern, da für diese kein Kompromiss eingegangen wurde. Daher werden, bei der Verifikation der Signaturen durch den die öffentlichen Schlüssel der beiden Zertifikatsautoritäten die beiden Werte berechnet durch den Decoder, durch die jeweiligen öffentlichen Schlüssel nicht dieselben sein. Daher wird der Decoder gewarnt über den Mangel an Integrität des Inhalts des RCMM und wird andernfalls mit der Verarbeitung des RCMM nicht fortfahren.
  • Daher können Root-Zertifikate sicher aktualisiert werden, vorausgesetzt, dass die Zahl der einem Kompromiss unterliegenden Zertifikate kleiner ist als die Zahl der in der RCMM enthaltenen Signaturen. Daher ist die Zahl der Signaturen der RCMM eine Variable, bestimmt durch die die RCMMs verteilende Root-Zertifikationsbehörde.
  • Das Format einer RCMM wird nunmehr anhand der 10 detaillierter beschrieben.
  • Der RCMM 130 enthält:
    • • die Identität 132 der RCA, die das RCMM 130 verteilt hat,
    • • die Daten 134, auf denen die RCMM 130 ausgegeben wurde,
    • • die Zahl 136 von Signaturwerten, die die darauf folgende RCMM enthalten wird,
    • • ein Feld 138 mit einem oder mehreren aktualisierten oder Ersatz-Root-Zertifikaten zur Speicherung in dem Decoder,
    • • eine Liste 140 der Seriennummern der aufzuhebenden Root-Zertifikate, enthaltend, für jedes aufgehobene Root Zertifkat, die Zeit und das Datum der Aufhebung des Zertifikats, und
    • • wenigstens zwei Signaturfelder 142, die enthalten einen in dem Decoder gespeicherten Identifizierer 144 des Zertifikats, die den öffentlichen Schlüssel enthält, der zur Prüfung des Signaturwertes in dem Signaturfeld benutzt werden muss, und ein Signaturwert 146 des RCMM, berechnet durch den äquivalenten privaten Schlüssel zu dem öffentlichen Schlüssel in dem durch den Identifizierer 144 identifizierten Zertifikat.
  • Die Zahl der Signaturfelder 142 sollte gleich oder größer sein als die Zahl 136 von Signaturfeldern, wie in der vorangehend empfangenen RCMM empfohlen.
  • Es wird bevorzugt, dass die RCMMs über den MPEG Transportstrom übertragen werden, da der Modemrückkanal leicht abgeschaltet werden kann oder einfach nicht anwesend ist. Es wird außerdem bevorzugt, dass die RCMMs durch den Sender eingefügt werden als eine Datendatei in ein Rootverzeichnis 75, um zu gewährleisten, dass die RCMM durch den Decoder heruntergeladen wird.
  • Verarbeitung und Erzeugung der Root-Zertifikats-Verwaltungsnachrichten
  • Der Empfang und die Verarbeitung einer RCMM durch einen Decoder wird nunmehr anhand der 11 beschrieben.
  • Beim Empfang einer RCMM vergleicht der Decoder im Schritt 200 das Datum 134, an dem diese RCMM 130 ausgegeben wurde, auf dem die vorangehend ausgegebene RCMM ausgegeben wurde. Wenn das Datum 134 der neu empfangenen RCMM nicht später liegt als das Datum, an dem die vorangehende RCMM ausgegeben wurde, wird das RCMM unterdrückt.
  • Wenn das Datum 134 der neu empfangenen RCMM später ist als das Datum des Empfangs der vorangehenden RCMM wird, die Zahl 136 der Signaturwerte, die das neu empfangene RCMM enthalten soll, avisiert durch die vorangehend empfangene RCMM, wird verglichen im Schritt 202 mit der Zahl der Signaturwerte, die tatsächlich in dem neu empfangenen RCMM enthalten sind. Wenn die Zahl der in dem neu empfangenen RCMM kleiner ist als erwartet, wird das RCMM unterdrückt oder zurück gewiesen. Das kann verhindern, dass die RCMM auf andere Weise als ein Ergebnis eines Hackers verarbeitet wird, der die Signaturen für nicht einem Kompromiss unterliegende private/öffentliche Schlüsselpaare verarbeitet.
  • Wenn die Zahl der in der neu empfangenen RCMM gleich oder größer ist als die erwartete Zahl der Signaturen, wird im Schritt 204 der Unterschriftswert 146 in der RCMM durch den öffentlichen Schlüssel geprüft, identifiziert durch den Identifizierer 144, der in demselben Signaturfeld 142 wie dieser Signaturwert enthalten ist. Im Schritt 206 ermittelt der Decoder, ob wenigstens einer der durch öffentliche Schlüssel berechneten Werte anders ist als die anderen mit einem anderen öffentlichen Schlüssel berechneten Werte. Wenn wenigstens ein berechneter Wert abweichend ist von wenigstens einem der anderen berechneten Werte, wird die RCMM unterdrückt.
  • Wenn die Integrität des RCMM im Schritt 206 nachgewiesen wird, wird die RCMM im Schritt 208 verarbeitet, um die Liste 140 der Seriennummern der aufgehobenen Root-Zertifikate in dem permanenten Speicher (ROM) des Decoders zu löschen, so dass diese Zertifikate im Schritt 212 von dem Speicher des Decoders gelöscht werden, um jedes Root-Zertifikat in dem Feld 138 in dem permanenten Speicher (ROM) des Decoders zu speichern und im Schritt 212 das Datenwort 134 der RCMM zu speichern. Wenn ein Zeritifkat der Root-Zertifikationsbehörde gelöscht wird, werden alle durch die Behörde ausgegebenen CRLs ebenfalls gelöscht.
  • Es wird vorgezogen, dass die Integrität der permanenten Speicherung der in dem RCMM enthaltenen Daten aufrechterhalten wird, wenn der Decoder während der Verarbeitung der RCMM Nachricht abgeschaltet wird. Daher wird, wenn die Betriebsspannung tatsächlich während der RCMM-Verarbeitung abgeschaltet wird, die Liste 140 für die vorher verarbeiteten RCMM, die in dem Decoder gespeichert ist, so aufrechterhalten, als wenn die neu empfangene RCMM Nachricht überhaupt nicht verarbeitet worden wäre.
  • Wie früher erwähnt, hat die Root-Zertifikationsbehörde (RCA) im Allgemeinen wenigstens zwei RCA Zertifikate, RC0 und RC1, gespeichert in jedem Decoder. In dem Fall, wenn für eine dieser Zertifikate, zum Beispiel RC0, ein Kompromiss eingegangen wird, wird es notwendig, alle die in dem Decoder gespeicherten CA Zertifikate, die während des äquivalenten Schlüssels zu dem in dem RC0 gespeicherten Schlüssel signiert wird und ein neues RCA Zertifikat RC2 zum Ersatz des RC0 erzeugt wird.
  • Gemäß 12 wird zum Ersatz dieser CA Zertifikate zunächst im Schritt 300 eine geeignete CRL Nachricht zur Identifikation der Seriennummern der aufzuhebenden Zertifikate durch die RCA ausgegeben. Zweitens werden in dem die CA Zertifikate ersetzenden Schritt 302, signiert durch den privaten Schlüssel des keinem Kompromiss unterliegenden Zertifikat RC1, ausgegeben zu dem Sender für die Sendung zu dem Decoder.
  • Dann bleibt es, das einem Kompromiss unterliegende RCA Zertifikat RC0 zu löschen und dieses Zertifikat durch ein neues RCA Zertifikat RC2 zu ersetzen. Im Schritt 304 erzeugt die RCA ein neues öffentliches/privates Schlüsselpaar, fügt den neuen öffentlichen Schlüssel in das Zertifikat RC2 ein und signiert das Zertifikat durch den neuen privaten Schlüssel.
  • Im Schritt 306 erzeugt die RCA eine RCMM, die im Feld 138 ein Zertifikat RC2 und in der Liste 140 die Seriennummer des RC0 enthält. Die RCMM wird zu den Sendern für eine Übertragung im Schritt 308 an den Decoder verteilt, um das einem Kompromiss unterworfene Zertifikat RC0 zu löschen und dieses durch das neue Zertifikat RC2 zu ersetzen.
  • Die RCA Zertifikate RC1 und RC2 werden danach zu dem Decoderhersteller geliefert für eine harte Codierung in den Speicher der neuen Decoder.
  • Es ist selbstverständlich, dass die vorliegende Erfindung nur an einem Beispiel beschrieben wurde und Änderungen innerhalb des Schutzumfangs der Erfindung vorgenommen werden können.
  • Zum Beispiel kann das RCMM zusätzlich zu den neuen RCA Zertifikaten 110 neue RCA Zertifikate 100 und/oder neue Senderzertifikate 90 enthalten, und die Liste 140 kann Identifizierer der CA Zertifikate und/oder Senderzertifikate enthalten, die aufgehoben werden sollen. Dieses kann die Erzeugung von getrennten CRL Nachrichten durch eine zu vermeidende RCA ermöglichen.
  • Jedes in der Beschreibung genannte Merkmal wird frei und (wo angebracht) die Ansprüche und Zeichnungen können unabhängig oder in einer geeigneten Kombination durchgeführt werden.

Claims (10)

  1. Verfahren zur Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten (46, 60), dadurch gekennzeichnet, dass das Verfahren vor der Übertragung die folgenden Schritte enthält: Bestimmung von wenigstens zwei verschlüsselten Werten (146) für wenigstens einige dieser Daten, wobei jeder verschlüsselte Wert durch Anwendung eines Schlüssels eines jeweiligen Verschlüsselungsalgorithmus für dieselben Daten ermittelt wird und Ausgabe der wenigstens zwei verschlüsselten Werte mit den Daten.
  2. Verfahren nach Anspruch 1, wobei die Daten einen Schlüssel (91, 101, 111) enthalten.
  3. Verfahren nach Anspruch 2, wobei die Daten wenigstens ein digitales Zertifikat (90, 100, 110) mit einem öffentlichen Schlüssel (91, 101, 111) eines Verschlüsselungsalgorithmus für die Verarbeitung der Daten enthalten.
  4. Verfahren nach Anspruch 3, wobei die Daten wenigstens ein digitales Wurzelzertifikat (110) mit einem öffentlichen Schlüssel (111) eines Verschlüsselungsalgorithmus für die Verarbeitung der Daten enthalten.
  5. Verfahren nach einem der vorangehenden Ansprüche, wobei die Daten einen Identifizierer (94; 104) eines aufgehobenen öffentlichen Schlüssels enthalten.
  6. Verfahren nach Anspruch 5, wobei der Identifizierer einen Identifizierer eines digitalen Zertifikats mit dem aufgehobenen öffentlichen Schlüssel enthält.
  7. Verfahren nach Anspruch 6, wobei der Identifizierer einen Identifizierer eines digitalen Wurzelzertifikats mit dem aufgehobenen öffentlichen Schlüssel enthält.
  8. Verfahren zur Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten, gekennzeichnet durch folgende Schritte: Empfang der Daten und von wenigstens zwei verschlüsselten Werten, die für wenigstens einige der Daten bestimmt sind, jeder verschlüsselte Wert für dieselben Daten bestimmt ist durch einen Schlüssel eines jeweiligen Verschlüsselungsalgorithmus, Speicherung von mehreren Schlüsseln, Verarbeitung (204) aller verschlüsselten Daten durch einen gespeicherten Schlüssel des jeweiligen Verschlüsselungsalgorithmus, und Vergleich (206) jedes der aufeinander folgenden resultierenden Werte mit den wenigstens einigen Daten zur Authentifizierung der wenigstens einigen der Daten.
  9. Vorrichtung zur Authentifizierung von in einem digitalen Übertragungssystem zu übertragenden Daten, gekennzeichnet durch: Mittel zur Bestimmung von wenigstens zwei verschlüsselten Werten für wenigstens einige der Daten, wobei jeder verschlüsselte Wert durch einen Schlüssel eines jeweiligen Verschlüsselungsalgorithmus für dieselben Daten bestimmt ist, und Mittel zur Ausgabe der wenigstens zwei verschlüsselten Werte mit den Daten.
  10. Empfänger/Decoder (13) mit: Mitteln (20) zur Speicherung von mehreren Schlüsseln, gekennzeichnet außerdem durch: Mittel (31; 32; 30; 20) zum Empfang einer Datendatei mit Daten und wenigstens zwei verschlüsselten Werten, die für wenigstens einige der Daten bestimmt sind, wobei jeder verschlüsselte Wert für dieselben Daten durch einen Schlüssel eines jeweiligen Verschlüsselungsalgorithmus bestimmt ist, Mittel (20) zur Verarbeitung jedes verschlüsselten Werts durch einen gespeicherten Schlüssel des jeweiligen Verschlüsselungsalgorithmus, und Mittel (20) zum Vergleich jedes aufeinanderfolgenden resultierenden Werts mit den wenigstens einigen der Daten zur Authentifizierung der wenigstens einigen der Daten.
DE60114167T 2000-04-03 2001-01-11 Authentifizierung von in einem digitalen übertragungssystem übertragenen daten Expired - Lifetime DE60114167T2 (de)

Applications Claiming Priority (3)

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
PCT/IB2001/000103 WO2001076135A1 (en) 2000-04-03 2001-01-11 Authentication of data transmitted in a digital transmission system

Publications (2)

Publication Number Publication Date
DE60114167D1 DE60114167D1 (de) 2005-11-24
DE60114167T2 true DE60114167T2 (de) 2006-07-13

Family

ID=8173630

Family Applications (3)

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

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
DE60133233T Expired - Lifetime DE60133233T2 (de) 2000-04-03 2001-01-11 Authentifizierung von Daten welche in einem digitalen Übertragungssystem übertragen werden

Country Status (16)

Country Link
US (6) US7437561B2 (de)
EP (6) EP1143658A1 (de)
JP (7) JP2003530013A (de)
KR (1) KR100726347B1 (de)
CN (5) CN1897527B (de)
AT (3) ATE485649T1 (de)
AU (1) AU2699501A (de)
BR (2) BRPI0117237B1 (de)
CY (2) CY1106061T1 (de)
DE (3) DE60114167T2 (de)
DK (2) DK1699165T3 (de)
ES (1) ES2250346T3 (de)
HK (3) HK1101235A1 (de)
MX (1) MXPA02009771A (de)
MY (5) MY152592A (de)
WO (1) WO2001076135A1 (de)

Families Citing this family (107)

* 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
MXPA06014020A (es) * 2004-07-14 2007-02-08 Matsushita Electric Ind Co Ltd Metodo para autenticar y ejecutar un programa.
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
JP5200204B2 (ja) 2006-03-14 2013-06-05 ディブエックス リミテッド ライアビリティー カンパニー 高信頼性システムを含む連合型デジタル権限管理機構
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
US8233768B2 (en) 2007-11-16 2012-07-31 Divx, Llc Hierarchical and reduced index structures for multimedia files
KR100923858B1 (ko) 2007-12-04 2009-10-28 한국전자통신연구원 케이블 네트워크 시스템 및 케이블 네트워크 동적멀티캐스트 세션에서의 보안 제어 방법
US8997161B2 (en) 2008-01-02 2015-03-31 Sonic Ip, Inc. Application enhancement tracks
ES2351776T3 (es) * 2008-02-11 2011-02-10 Nagravision S.A. Método de actualización y de gestión de una aplicación de tratamiento de datos audiovisuales incluida en una unidad multimedia mediante un módulo de acceso condicional.
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
KR101635876B1 (ko) 2009-01-07 2016-07-04 쏘닉 아이피, 아이엔씨. 온라인 콘텐츠를 위한 미디어 가이드의 단일, 공동 및 자동 생성
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
WO2011026089A1 (en) 2009-08-31 2011-03-03 Telcordia Technologies, Inc. System and methods to perform public key infrastructure (pki) operations in vehicle networks using one-way communications infrastructure
JP5723888B2 (ja) 2009-12-04 2015-05-27 ソニック アイピー， インコーポレイテッド 基本ビットストリーム暗号材料伝送システムおよび方法
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.
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US20140096154A1 (en) * 2011-05-20 2014-04-03 Nippon Hoso Kyokai Integrated broadcasting communications receiver and resource managing device
WO2013004597A1 (en) 2011-07-01 2013-01-10 Nagravision S.A. A method for playing repeatable events on a media player
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
WO2013033458A2 (en) 2011-08-30 2013-03-07 Divx, Llc Systems and methods for encoding and streaming video encoded using a plurality of maximum bitrate levels
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
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
US8918908B2 (en) 2012-01-06 2014-12-23 Sonic Ip, Inc. Systems and methods for accessing 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
EP2875417B1 (de) 2012-07-18 2020-01-01 Verimatrix, Inc. Systeme und verfahren für schnelle umschaltung zwischen inhalten zur bereitstellung eines linearen fernseherlebnisses mittels inhaltsverteilung über streaming
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
WO2014071602A1 (zh) 2012-11-09 2014-05-15 华为技术有限公司 一种消息验证的方法和终端
US9264475B2 (en) 2012-12-31 2016-02-16 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
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
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
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
US9344517B2 (en) 2013-03-28 2016-05-17 Sonic Ip, Inc. Downloading and adaptive streaming of multimedia content to a device with cache assist
US9247317B2 (en) 2013-05-30 2016-01-26 Sonic Ip, Inc. Content streaming with client device trick play index
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
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 엘지전자 주식회사 방송 송신 장치, 방송 송신 장치의 동작 방법, 방송 수신 장치 및 방송 수신 장치의 동작 방법
US9674162B1 (en) 2015-03-13 2017-06-06 Amazon Technologies, Inc. Updating encrypted cryptographic key pair
US9893885B1 (en) 2015-03-13 2018-02-13 Amazon Technologies, Inc. Updating 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
DE102015212037A1 (de) * 2015-06-29 2016-12-29 Siemens Aktiengesellschaft Überwachen eines Übertragungsstreckenabschnitts zur Übertragung von Daten zwischen zwei Teilnehmern einer Kommunikationsverbindung
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
EP3494707B1 (de) * 2016-08-04 2022-06-01 SmarDTV S.A. Verfahren und vorrichtung zur überprüfung der authentizität einer hbbtv-verwandten anwendung
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
US20200154275A1 (en) * 2018-11-13 2020-05-14 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
EP0706275B1 (de) * 1994-09-15 2006-01-25 International Business Machines Corporation 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
BR9608416A (pt) * 1995-06-05 1998-12-29 Certco Llc Método e sistema em múltiplas etapas de assinatura digital
US5625693A (en) * 1995-07-07 1997-04-29 Thomson Consumer Electronics, Inc. Apparatus and method for authenticating transmitting applications in an interactive TV system
US6985888B1 (en) * 1995-08-21 2006-01-10 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
US5666416A (en) * 1995-10-24 1997-09-09 Micali; Silvio Certificate revocation system
US6097811A (en) * 1995-11-02 2000-08-01 Micali; Silvio Tree-based 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ä
GB2342538B (en) 1997-04-25 2002-03-06 British Telecomm 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
CN100382498C (zh) * 1998-07-14 2008-04-16 索尼公司 数据发送控制方法、数据发送方法和设备以及接收设备
EP1018733B1 (de) * 1998-07-22 2003-09-10 Matsushita Electric Industrial Co., Ltd. Digitale datenaufzeichnungsvorrichtung und verfahren zum urheberrechteschutz und zur leichteren wiedergabe von verschluesselten daten und rechnerlesbares aufzeichnungsmedium zur programmaufzeichnung
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

Also Published As

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

Similar Documents

Publication Publication Date Title
DE60114167T2 (de) Authentifizierung von in einem digitalen übertragungssystem übertragenen daten
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